Evaluation and comparison of various Ethereum Layer 2 expansion solutions
Editor's Note: This article comes fromDenglian CommunityEditor's Note: This article comes from
Denglian Community
, Author: Alex Gluchowski, reprinted with permission by Odaily.
These claims should not be taken simply as fact, but thorough due diligence should be done to explore the inevitable trade-offs each solution is making.
overview
first level title
overview
In order to simplify the problem, our evaluation will start from the following four aspects, namely:
1. Security 2. Performance/economics 3. Usability 4. Others
first level title
1. Security
1. Security
secondary title
Online assumptions (eg: watchtowers)
In some cases, online delegation can be delegated to trusted parties with incentives aligned with users of their services (e.g., through vouching). However, it is important to note that if a trusted representative misbehaves, the amount lost is always the size of the security deposit.
One should consider whether a trusted representative has the opportunity to steal more value than the security deposit, and to what extent this risk can be tolerated.
mass exit hypothesis
implement
Does the security assumption of the expansion solution include that all users can successfully withdraw to the L1 layer within a short period of time (user withdrawal withdrawal)?
implement
This happens when all users of the L2 scaling solution need to exit L2 within a short period of time for security reasons. If they choose to stay, the operator may perform some operations to drain the funds still in L2. For example, in the Matic scheme, the window for all users to log out is 1 week.
This can be very problematic due to network congestion and DoS attacks. For example, with large-scale exits within a given time frame, the Ethereum network may be highly congested, which may result in transactions not being packaged in a timely manner. Even when there is no congestion, attackers can still try to manipulate the gas price so that transactions cannot be processed in a timely manner. This is an attack vector worth considering.
secondary title
Will a quorum of L2 validators make users unable to access funds for an indeterminate amount of time? Can they take user funds?
This is especially important if you want your project to remain uncensorable.
secondary title
Disadvantages of hot wallet keys
And the key must be online at all times to keep the system up and running?
Hot wallets are notoriously difficult to get real protection.
secondary title
Vulnerable to Cryptoeconomic Attacks
There are various attacks involving cryptoeconomic incentives, including: framing L2 validators[1] (or their operators), bribing miners on L1[2], creating dark DAOs[3], etc. These attack methods are developing rapidly, and it is difficult to prove that these attacks can be eradicated by scaling systems that rely on game theory assumptions.
Also included are scenarios that aren't technically theft but are practically equivalent. For example, for Validium's double-spending attack [4], the attacker cannot steal other people's funds by design, but can still double-spend.
Password principle
first level title
performance/economy
secondary title
What is the maximum possible throughput of a scaling solution on Ethereum 1.0? What about Ethereum 2.0?
While the throughput of a solution today may be satisfactory, it is reasonable to look to the future and predict the need for additional throughput and whether the planned solution will be future-proof.
secondary title
How capital efficient is the scaling solution? Does it require a lot of capital to operate?
A less capital efficient system would be more costly for users and could result in operational disruption due to lack of immediate liquidity. Payment channels, for example, are relatively inefficient use of funds because channel operators must lock in multiples of their average number of channels to ensure channels do not reach capacity.
secondary title
To start using new users in L2, do they need to submit transactions on the L1 chain?
first level title
ease of use
withdrawal time
How long does it take to withdraw funds to L1? Withdrawals in some settlements may have to wait a week or more in order to resolve disputes. In order to alleviate this long waiting time, are there liquidity providers who provide users with liquidity in exchange for a risk premium? If such liquidity providers exist, how reliable and costly are they? Since there is a price to pay for fast withdrawals, what is the real cost of using this solution?
secondary title
Under the security assumptions of the protocol, how long does it take for a transaction to reach a state where it cannot be reverted on L1?
By subjective finality, we mean that an external observer can be convinced of the irreversibility of the transaction even though the L1 smart contract still cannot rely on this state. For example, in Optimistic Rollups, it takes 1 confirmation on Ethereum to reach L1 finality, and full finality takes about 1 week.
secondary title
Can a light client (browser/mobile wallet) verify when subjective certainty is reached (see previous question)?
Continuing with the example above, in Optimistic Rollups, 1 confirmation is enough to reach L1 finality, but to confirm that a transaction is final, you must download the entire Rollup state and execute all transactions from the last week to ensure that all Optimistic Rollups blocks are is correct.
secondary title
Instant transaction confirmation
other aspects
other aspects
smart contract
smart contract
Does the L2 layer support arbitrarily programmable smart contracts, or only a limited subset implemented using certain predicates?
EVM bytecode portability
Can existing Ethereum contracts be ported with almost no changes?
secondary title
Does the protocol provide native support for privacy?
Without low-cost shielded transactions by default, privacy is not very well protected [5], as this is eloquently demonstrated by multiple studies on deanonymization conducted on various platforms (ref 1, 2).
first level title
