As I said in part 1, I’m not an expert, I don’t have a technical background, but what follows is my understanding of some of the technical aspects of how eCash plans to scale from ~100 transactions per second, to 5 million transactions per second.
It can only happen with huge blocks, of course, potentially even terabyte size blocks.
In the last article we talked about the data storage bottleneck caused by such big blocks of data. Here in part 2, we will discuss the bottleneck caused by block validation and propagation.
What is block validation and propagation? Block validation is the process by which nodes in a blockchain network verify the integrity of a newly mined block. This means checking to ensure the block adheres to the consensus rules of the network. If the block passes all validation checks, it’s considered valid and is added to the blockchain. If it fails, it’s rejected.
Block propagation, on the other hand, is the process of spreading the data from the newly created block to other nodes on the network. Once a receiving node successfully validates a block, it then broadcasts that block to its neighboring nodes, and this process continues until the block has been disseminated to the entire network.
As one might imagine, the bigger the block, the longer it will take to validate and propagate the data. With centralized payment networks, you don’t have this issue because you don’t have to propagate data to multiple nodes in the same way decentralized blockchains do.
The presence of a central authority eliminates the need for consensus mechanisms. But the tradeoff is that users are forced to trust this central entity, that it isn’t one day going to suddenly lock you out of your money.
This is why permissionless blockchain technology like the one being developed by the eCash project are so important. They aim to make it so that everyone has access to a global payment network that can’t be weaponized, because it can’t be controlled by any central authority.
But to build a network that can serve up to 50 transactions per day for 10 billion humans on the planet, we must first solve the block validation and propagation bottleneck.
Why is it bad if it takes too long to propagate a block? If it doesn’t happen very quickly, different parts of the network can receive different blocks at different times. This can lead to temporary splits in the blockchain, where there are two (or more) competing branches, eventually leading to chain reorganizations.
Imagine if a user sends a transaction to an exchange, the transaction gets confirmed in a block and the exchange credits them, but later there is a chain reorganization and the deposit transaction effectively disappears. In this scenario, the exchange could be out of pocket if the user has already withdrawn their funds from their account while their deposit was basically reversed. This is what can happen in a 51% attack.
And while eCash has Avalanche to prevent 51% attacks, we still want blocks to get validated and propagated across the network as fast as possible.
So how does eCash propose to remove this bottleneck? The same way they do everything, by making incremental improvements. For example, the implementation of Avalanche pre-consensus will reduce the amount of data that nodes need to send when a block is found. Without pre-consensus, nodes might need to validate an entire block before forwarding it to their peers. With pre-consensus, nodes are constantly communicating in between blocks, allowing them to have already done most of the work that goes into building a block before the next block is announced.
Another optimization the eCash team made was to change the method by which transactions are ordered in a block. Whereas Bitcoin uses what’s known as topological transaction ordering (TTOR), eCash relies on canonical transaction ordering (CTOR) based on transaction IDs. By using CTOR, nodes no longer have to transmit ordering data related to a block the way you do with TTOR. Since ordering data makes up a significant amount of the block data that gets transmitted, this drastically improves block propagation efficiency.
But there is also another benefit provided by CTOR, which is that it improves parallelization, or parallel processing. This is where you can divide the work between multiple CPU cores to process the block data more efficiently.
Parallelization is not to be confused with sharding, which is the last improvement I’m going to mention. Sharding is a data partitioning technique used in distributed databases. In sharding, a dataset is divided into smaller fragments, or “shards.” Each shard contains a subset of the data, and these shards are distributed across multiple nodes to divide the overall block validation into pieces. The results from each shard are then aggregated to finalize the validation.
By no means is this article meant to be comprehensive, or technical with regard to eCash scaling. But I wrote it to demonstrate why I believe in the eCash project. I wanted to explain from a layman’s perspective my understanding of the roadmap, and that while it may seem difficult, it also seems quite feasible.