Addressing The Scaling Issue In Crypto.
Part 2 of 3.
What seems to unify the team is an indomitable ambition to become net positive movers in the industry, and they have arguably already achieved this through successfully launching Delegated Proof of Stake on top of Cryptonote V8, while solving DPOS primary weakness– cartels– all while open-sourcing their code.
Their first goal post delivery of DPoPS is to address a problem which will make or break the decentralization principle for the entire crypto industry in the near-future if left to the methods proposed by other coins– the scaling issue.
Dreams and reality collide
If crypto was a race towards who becomes the everyday coin for the mainstream user, cryptonote coins are at an overwhelming advantage in that, their block sizes expand and contract based on how many transactions the block holds and how big each transaction is. This dynamic nature compared to a fixed block means scaling can mainly be handled on-chain before a second-layer becomes a necessity– but this only offsets the problem.
Mainstream adoption as a payment medium is a desirable outcome, and to ensure this, a coin must match visa’s throughput during peak demand of 4,000 tps as a bare minimum. This far exceeds cryptonote’s maximum capabilities of between 50-70 tps, but XCASH has a solution to this, through their use of side chains their method of delivery enhances decentralization opposed to scaling down or in.
The high theoretical transactions per second some coins propose are impressive, but impractical as storage costs and bandwidth allowances make these theoretical numbers unworkable in the real world. If bitcoin can process 7 transactions per second, at a size of (the average from 27th feb 2020 – 27 feb 2021) 0.7189 kb per transaction, and there are 86400 seconds in a day, the sum total transaction size would equal ~434.14 MB per day, but what happens when we increase tps to 1000, or 4000 or 1 million? ~62.1 GB, ~248.4 GB and ~496.9 TB respectively.
This scenario could only work in a centralized system where wallet users use web wallets, opposed to owning their own keys, and payments were processed via dedicated servers– which is indeed the case for Visa, and how much of the bitcoin network has evolved in pursuit of adoption.
Mutually assured dominance
There is a security cost/reward tradeoff when considering scalability. If sharding, or a second layer are solutions at the expense decentralization, are they even worth considering? If sharding favours some nodes over others, does this method lead to a centralized system in the long-term?
The current state of side chains enable side chain operators to set their own consensus, which can vary depending on the operator’s personal disposition, which is an inherent weakness of itself as it opens the door to questionable judgments, and centralization (intentional or not) in the pursuit of speed and cost reduction (scaling down).
So how can XCASH keep its network decentralised, and have a competitively high tps while making the block size debate non-applicable?
XCASH uses the scaling up method, as the base layer’s (mainchain) integrity is maintained, but unlike other solutions, its side chains have no impact on consensus whatsoever. Consensus is built into the mainchain and all XCASH nodes enforce consensus, and must act in accordance with it or risk losing their position. So when a delegate hosts a side chain, they are already fully, and continuously verified as, acting in accordance with the mainchain’s consensus. As a result, high level features inherit security and side chains don’t require their own validation protocols, therefore maintaining decentralization and subsequently security in the long-term.
Liberty and bandwidth
So how does XCASH deal with bloated blocks while keeping decentralization as a priority? This will be a whole industry issue regardless of how dynamic or big a block size can be. Sidechains offer XCASH the ability to off-load less important data at speeds in the magnitude of a second, while the main chain processes all high-level data that will be better suited to a 5 minute block time. Anyone can download the high level database, while conversely anyone who wants to just send payments can download the regular blockchain which will be kept at a size minimum.
While no exact figures can be found at the time of writing this article, it has been stated that delegates should upgrade their VPS’ to accommodate the extra bandwidth up to a maximum of 1 Gbps, while the minimum to run a delegate node without the possibility of running a sidechain– or at least not one of any meaningful size– at 100mbps.
This system would certainly benefit the end-user as on the surface level, their method of payment will function indistinguishably to legacy (centralized) systems, while keeping the principle of decentralization uncompromised. More information will be made available on side-chains and other second layer solutions in the future.
Modern problems require modern solutions
A problem with the POW algorithm is at any time a large hash rate could take control of the chain and 51% attack it, double-spend, or at worse force a consensus change, which will cause severe disruption for all participants, especially risky for POW chains with adoption from high-profile entities and organisations.
It would be ludicrous to assume a POW chain of significant hashrate could have a successful 51% attack launched against it by contemporary capabilities, however, it would be naive to assume tomorrow’s technology won’t outperform the technology of today. State-actors and legacy fiat authorities are expressing clear commitment to blockchain technology and it stands to reason that, it’s a matter of time before a batch of ASICS (or their successor tech) are manufactured on an industrial scale by a state actor, NGO, or national intelligence service– in secret– that outperform the sum of the miners of the time and launch 51% attacks on unprepared POW chains.
DPOS, not without its shortcomings, addresses various vulnerabilities that exist in the POS algorithm. One such example– similar to POW– a large stake holder on a POS chain could launch a 51% attack, whereas this could not happen on a DPOS chain, let alone XCASH’s DPoPS chain.The main issue DPOS faces is delegates forming cartels who choose to put validation into a small number of hands. XCASH addresses this issue using verifiable random functions (VRFS) meaning the delegate who verifies the block out of the list of elected delegates can’t be anticipated, and a mandatory 67% consensus thus ensuring cartels would need a requirement of at least 67% of all elected delegates before the consensus protocol can be disrupted. It would be prohibitively expensive and painfully slow for such an attack to happen on a DPOS chain, as the attacker would need to market-buy the total circulating supply in sell orders from all listed exchanges.