The stated goal of the eCash project is to achieve 5M transactions per second, or 50 transactions per day for 10B humans on the planet.
For comparison, Visa handles about 1700 transactions per second with claims that it can theoretically handle over 24,000 transactions per second. Basically, eCash is aiming for ~200x Visa’s theoretical limit.
My goal over the next couple of articles is to explain in laymen’s terms how eCash will achieve 5M transactions per second. Let me be clear that I am not a software engineer, I don’t speak for the eCash project, and this is simply my understanding as someone without a technical background.
I believe there are two different bottlenecks to scaling eCash. The first one being data storage, and the second being block validation and propagation. We will start with the first one, which I think is the easier of the two.
As eCash scales, what it will mean is that the network will eventually have to support upwards of terabyte size blocks. With a block mined every ten minutes (on average), this means 144 terabytes of data in a day, or 50 petabytes of data in a year.
This is one of the main reasons why the Bitcoin Core developers chose not to increase the block size limit from 1 MB. They argued that raising it once could open the door for raising it even further down the line, and they feared that eventually the blockchain would grow so large that not just anyone would be able to run a full node, leading to centralization pressures that could doom the network.
The eCash project has a different perspective. We see decentralization as a means to an end, not the end itself. We believe in sufficient decentralization, not maximum decentralization. The same way we believe in sufficient mining power, not maximum mining power.
What the eCash project does want to maximize is value creation, and we believe a purely peer-to-peer version of electronic cash will add an enormous amount of value to the world. We believe that the best way to achieve peer-to-peer electronic cash is through massive on-chain scaling. This doesn’t mean eCash isn’ interested in layer two solutions for the right use cases, but that in order to take advantage of layer two solutions first requires scaling layer one.
But back to the data storage problem. The fear is that if the blockchain grows too large because the blocks are so big, it will mean not everyone will have the disk space to store a copy of the ledger. Another issue is how long it will take for anyone joining the network to complete the initial block download (IBD).
Before we get into potential solutions, I feel the biggest advantage we have in dealing with the data storage problem is time. The total amount of on chain activity across all blockchains today is nowhere near 5M transactions per second. As for eCash itself, we’re barely doing 1000 transactions per day so it will be years before this becomes a major issue. But when it does, there are potential solutions such as blockchain pruning and UTXO commitments.
Blockchain pruning allows nodes to free up storage space by removing older and unnecessary data. While there will still be nodes that retain all historical information, it will not be necessary for every node on the network to do so. Instead most nodes will only include a snapshot of the blockchain’s current state, and the set of unspent transaction outputs (UTXOs).
UTXO commitments, on the other hand, will provide a cryptographic summary of the UTXO set at a specific point in time. It will serve as a compact representation of all unspent outputs and their state, lowering the amount of data that needs to be stored even further.
Already in today’s world, there are thousands of enterprise data centers that can handle hundreds of petabytes of data. In the future, I imagine these numbers will only increase. And with eCash still trying to fill 1 megabyte blocks, let alone gigabyte or even terabyte size blocks, I’m confident that when the time does come, both the solutions mentioned above as well as advances in data storage technology will allow eCash to remain both sufficiently decentralized and censorship resistant.