At Dharma, we share the same dilemma faced by many projects that rely on cryptocurrency — how can we effectively scale? It’s been two weeks since we launched peer-to-peer payments, and the feature’s quick growth and corresponding resource usage took this theoretical problem and made it a practical, pressing concern.
In collaboration with Hypervisor Labs, we’ve put together a specification for feedback that outlines our proposed approach in detail. Add a comment or get in touch with us if you’ve got suggestions for improvement!Layer One
Based on the current gas limit, Ethereum can only handle ~15 transactions per second. Even staying under that limit, the gas required to process numerous transactions can get quite expensive, especially during periods of network congestion. Whether the cost is passed along to the user or covered by the project (like we do), it still must be reckoned with.
These are the realities of working with the base layer of the Ethereum blockchain, or “L1” in scalability parlance. Providing strong security guarantees on layer one requires that miners have enough time to perform the computation and resultant state changes for each transaction that they include in a block — if too much time is spent processing transactions, another miner will be able to “uncle” the greedy miner by submitting their own valid block more quickly.Layer Two
This brings us to “L2” solutions, designed to speed up this computation or even to eliminate it entirely. In the former camp, novel mathematics like zero-knowledge proofs can be used to enable faster verification of computation at the expense of increased time required to generate proof of said computation. While we are big fans of the work being done on this front, it introduces a great deal of complexity and requires appreciable domain-specific expertise.
Therefore, we’ve set out to build our own L2 system, based on the Optimistic Roll-Up scaling paradigm, that ...