Dharma is working on a Layer Two solution to enable fast, scaleable payments. Check out our spec today!
3 min read
Published on March 30, 2020
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!
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.
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 lets us avoid performing this computation on L1 unless strictly necessary.
This approach involves collecting a batch of transactions into L2 “blocks” and publishing the set of transactions along with a merkle root of the updated state. Then, a 24-hour challenge period begins where anyone independently verify the block and submit a “fraud proof” if an invalid transaction is included or the merkle root for the state is incorrect. If the proof succeeds in demonstrating a fraudulent block, the submitter is rewarded and the L2 state is rolled back to the last valid block.
So why are we building this ourselves? Many talented minds have been hard at work leveraging various flavors of this technique to build next-generation L2 systems.
However, most of these systems are designed to support a wide variety of different projects and use-cases, whereas this way we can tailor the L2 system directly to our needs. More broadly, the groups developing these systems still need more time to prepare, audit, deploy, and battle-test them before they’ll be ready for production use.
While we look forward to moving to a more full-featured L2 system when the time is right, we need something that works for our particular use-case — token transfers at scale — and we need it as soon as possible!
In order to quickly ship a secure L2 system that lets us scale out token transfers, we’ve aligned on a set of guiding principles. Our L2 must be:
– Simple — it needs to support deposits and withdrawals of a single ERC20 token (Dharma Dai) using the Dharma Smart Wallet, as well as transfers using a signing key on a user’s device, but does not require any additional functionality.
– Non-custodial — All users must remain in control of their tokens, with any transfer requiring their authorization via a valid signature, and with the ability to exit the system of their own volition.
– Transparent — Observers must be able to locally recreate the current state of the system based on publically available data and roll back an invalid block during a challenge period by submitting a proof of an invalid state transition.
– Scalable — The system should be able to scale out to support a large user base, allowing for faster L2 transactions and reducing gas costs by approximately an order of magnitude compared to L1.
Equally important are the features we do not need to include. Our L2 is not designed to be:
– Censorship Resistant — as long as unprocessed deposits and exits remain uncensorable, we can act as the sole block producer, thereby simplifying many aspects of the system.
– Generic — Full EVM support (indeed, even support for any functionality beyond token transfers) is not required, which greatly simplifies the resultant state, transaction, block production, and fraud proof mechanics.
– Massively Scalable — As long as throughput is sufficient to support usage in the near-term under realistic scenarios, we only need to hold out until more efficient L2 systems become production-ready.
We are extremely excited to build out our L2 solution and are looking forward to receiving feedback to help get our proposal ready for prime time. Check out the specification for all the nitty-gritty and we’ll see you in layer two!
Want to chat with us?
Tweet at us: https://twitter.com/Dharma_HQ
Join our Discord: https://discord.gg/mxDJwju
Check out the spec: https://ethresear.ch/t/simple-fraud-proof-l2-for-scalable-token-transfers/7216