Evaluating Ethereum L2 Scaling Solutions: A Comparison Framework
We provide a guide for evaluating various alternative Ethereum Layer-2 scaling solutions across a number of factors. ZK rollup, optimistic rollup, sidechains, payment channels, plasma, validium: which one is right for you?
The Ethereum Layer-2 scaling ecosystem has become tricky to navigate for builders as an increasing number of scaling solutions have seen the light of day. The trickiness resides in the inescapable lack of nuance behind every solution’s promise to be trustless, secure, economical and easy to use. We encourage builders to avoid taking these attributes as fact and instead conduct a comprehensive due diligence to dig into the inevitable tradeoffs that each solution is making.
To make this task easier we’ve put together a list of questions to help builders evaluate different scaling solutions and adopt the one most suited to their needs. The questions are grouped into the following categories:
- Security
- Performance / economics
- Usability
- Other
Alongside these questions, we’ve put together a comparison table to give you a starting point for conversations with solution providers. While we did our best to keep the comparison neutral and fair, it remained a difficult task to succinctly express the nuances of different approaches in the form of a table. We hope the extended list of questions with added context will make up for it.
Many thanks to Georgios Konstantopoulos (independent L2 researcher), John Adler (Fuel), Ben Jones (Optimism), JD Kanani (Matic), Patrick McCorry (any.sender), Justin Drake (Ethereum Foundation) and Brecht Devos (Loopring) for their review and corrections of this table.
Security
Liveness assumption (e.g. watch-towers)
Does the protocol require user liveness? In other words: do users need to be monitoring all on-chain (i.e. L1) activity of the scaling solution by themselves or via trusted representatives (watch-towers)?
In some cases, the liveness can be delegated to trusted parties with incentives aligned with the users they serve (i.e. bonded). However, it’s worth noting that the amount such trusted representatives can lose in case of misbehavior is always limited to the size of the corresponding ‘deposit’ (i.e. security bond) they’ve put in to be a trusted representative. One should consider if an opportunity to steal more value than what is in the deposit is possible and how comfortable they are with such a risk.
The mass exit assumption
Do the security assumptions of the scaling solution include the ability for all users to successfully perform exit transactions (withdrawals) to L1 within a short period of time?
A mass exit in L2 occurs when all users of a particular L2 solution need to leave L2 within a short period of time for security reasons. If they choose to stay, the operator might perform some manipulation and drain the funds still left in L2. For example in Matic, the window that is left open for all users to withdraw is 1 week.
This might be very problematic because of network congestion and DoS attacks. For example in the window of time given for mass exit, the Ethereum network could be highly congested and transactions might therefore not get mined in time. Even in case of no congestion, an attacker could try to manipulate gas prices or eclipse nodes to make sure the transactions don’t get mined in time. This is an attack vector worth considering.
Custody
Can a quorum of L2 validators make funds inaccessible to users for indefinite periods of time? Can they seize user funds?
This is particularly important if you want your project to remain censorship-resistant.
Vulnerability to hot-wallet key exploits
Does the safety of funds in this L2 solution depend on the operator’s ability to secure the keys that MUST be kept on online machines to keep the system operational (i.e. hot-wallet keys)?
Hot-wallets are notoriously difficult to secure.
Vulnerability to crypto-economic attacks
How vulnerable is the solution to crypto-economic attacks and does it rely on game-theoretic assumptions?
There are various kinds of attacks involving crypto-economic incentives, including compromising the L2 validators (or their operating staff), bribing miners on L1, creating dark-DAOs, and so on. These attack vectors are evolving rapidly and are difficult to provably eliminate in a system that relies on game-theoretic assumptions.
This also includes scenarios that are not technically theft but are practically equivalent. For example this double-spend attack on Validium where an attacker cannot steal everyone else’s funds by design but can still double-spend their own.
Cryptographic primitives
Does the solution rely on standard cryptography or makes use of novel cryptographic research, such as SNARKs or STARKs?
Generally, the longer a cryptographic construction has been out in the world, the longer it has had a chance for someone to break it. The more advanced and recent primitives used are, the more competency and scrutiny should be required from teams implementing and auditing them.
Performance / economics
Max throughput
What is the maximum possible throughput of the solution within the boundaries of Ethereum 1.0? What about in Ethereum 2.0?
While a solution’s throughput might be satisfactory today, it makes sense to look to the future and anticipate your project’s needs for additional throughput and whether the solution you are planning to adopt is future-proof.
Capital-efficiency
How capital efficient is the scaling solution? Does it require a substantial amount of capital to be locked in order to operate?
Systems that are less capital efficient will be more costly to the users relative to other solutions and might experience disruption of operations due to lack of immediate liquidity. Payment channels for example are relatively capital inefficient since channel operators have to lock up a multiple of the average volume of their channel to ensure it won’t reach capacity.
Cost to open new account
Is a L1 on-chain transaction required for a new user to start using an account in L2?
In the comparison chart we indicate the best-case scenario for each system, but individual implementations might be less efficient. For example, both zkSync and Loopring use zkRollups, but Loopring requires users to make a L1 transaction to open an account before they can receive a payment while zkSync doesn’t.
Usability
Withdrawal time
How long do withdrawals to L1 take?
To allow for dispute resolution, withdrawals in some solutions can take up to a week or more. To mitigate this long waiting time, are there liquidity providers who provide users liquidity in exchange for a risk premium? If such liquidity providers exist, how reliable and expensive are they? Since fast withdrawals come at a price, what is the true price of using such a solution?
Time to subjective finality
How quickly can a transaction reach a state where it cannot be reverted on L1 anymore under the security assumptions of the protocol?
By subjective finality, we mean that external observers can be persuaded in the irreversibility of a transaction, even if L1 smart contracts cannot yet rely on it. For example in Optimistic Rollups, you need 1 confirmation on Ethereum in order to reach L1 finality, while full finality takes ~1 week.
Client-side verifiability of subjective finality
Can the time to subjective finality (see previous question) be verified with light clients (browsers/mobile wallets)?
Continuing the example above with optimistic rollups, while you need 1 confirmation on Ethereum in order to reach L1 finality, to verify your transaction is final you’d have to download the entire rollup state and execute all the transactions of the last week to ensure that no optimistic rollup block is invalid.
Instant tx confirmations
Can the solution provide full or only bonded instant transaction confirmations?
“Instant apparent finality” can be implemented on top of most of the L2 protocols, i.e. transactions will appear to be instantly confirmed in the UX. Only payment channels (state channels) offer full security guarantees for these confirmations, while in other protocols these transactions can still be reverted for a period before they are confirmed in L1. Reverting them isn’t free though and validators of such solutions will lose their security bonds (i.e. deposit) regardless whether they succeed in doing so.
This feature depends on the details of the specific implementation of the scaling solution.
Other aspects
Smart contracts
Does the L2 support arbitrarily programmable smart contracts or only a limited subset that can be implemented using predicates?
EVM-bytecode portability
Can you port the EVM-bytecode of existing Ethereum contracts almost without changes?
Native privacy support
Does the protocol offer native support for privacy?
Without low-cost shielded transactions by default, privacy protection will be highly ineffective, as multiple studies on deanonymization in various platforms have eloquently demonstrated (1, 2).
P.S. A side-note on zkRollups
There are two scaling solutions that use zkRollups and live on mainnet: Loopring and zkSync. The major difference between them is the choice of the underlying proof system. Loopring uses Groth16 SNARK which has an application-specific trusted setup, while zkSync uses PLONK, a newer proof system with a universal trusted setup. Taking into account the recent breakthroughs in the design space of this proof system, we believe that PLONK will be a major accelerator of the adoption of zkRollups, and will detail this in an upcoming post.
***
We hope this post is helpful in your exploration of scaling solutions and gets you excited for what the future holds. Should you have any questions or would like to discuss any of the points above, feel free to reach out via email at hello@matter-labs.io, on Twitter, and on Telegram.
Matter Labs is on a mission to accelerate the mass adoption of public blockchains. We are building zkSync, a secure and fast scaling platform for Ethereum.
