A Scalability Plan for Ergo

We need to think how to tackle with scalability issues even when blockchain is not full at all like now. However, it is hard to predict what applications will have demand for, so it is better to understand for now what is doable for the Ergo Platform protocol (with no breaking changes), and start implementations only when needed.

So let’s consider solutions on different levels:

  1. L0 (networking protocol): Networking protocol in Ergo is done naively and not optimized at all. I think to start commenting and documenting it, and around August-October do optimized version (would be good to have a help here for sure). I think bootstrapping time and traffic consumed (when a node is synced) can be reduced by few times pretty easily.

  2. L1 (blockchain level): Ergo Platform is one of the most sophisticated protocols here with stateless clients (for real full-nodes), NiPoPoWs (for light clients), possibility for bigger blocks (when miners okay to vote for them) and so on.

But also an Ergo block has extension section with mandatory and arbitrary key-value data, By putting certain anchors there it is possible to do BitcoinNG-style microblocks, Aspen-like service-chains or generic sidechains with just velvet or soft forks.

  1. L2 (offchain protocols): Ergo has possibility to support Lightning Network, also Rainbow network ( http://research.paradigm.xyz/RainbowNetwork.pdf ) , Zero-Knowledge Contingent Payments, and likely FairSwap/FastSwap protocols ( e.g. https://eprint.iacr.org/2019/1296 ), likely some other state channel constructions possible as well. It would be good to apply offchain techniques to certain applications, such as mixer maybe.

So Ergo Platform has the scalability plan, but its implementation will depend on applications.


CoinPools, another L2 solution for the UTXO model to consider: https://discrete-blog.github.io/coinpool/



  • A lot of improvements in the node are done (starting from 4.0.8), some going on. We are going to count every memory allocation and every operation. I guess 20-50x improvements are still possible by just optimizing the node code.

  • Implementations for bootstrapping with NiPoPoW proofs and UTXO set snapshots are planned.

Then we can think about sub-block confirmation protocols and L2.