Vitalik Buterin’s new article: What is the difference between Ethereum L2 and execution layer sharding?

원본 기사: How do layer 2s really differ from execution sharding?

편집자: Od일체 포함리 플래닛 데일리 애셔

One of the points I made two and a half years ago in my “ Endgame ” article was that , at least technically, different paths forward for blockchain looked strikingly similar.

In both cases, there are a large number of transactions on the chain, and processing these transactions requires: (i) a lot of computation; (ii) a lot of data bandwidth. Ordinary Ethereum nodes, such as the 2 TB reth archive node running on the laptop used to write this article, are not powerful enough to directly verify such a huge amount of data and computation, even with excellent software engineering work and Verkle trees . Instead, in the L1 sharding and rollup-centric world, ZK-SNARKs are used to verify computation and DAS are used to verify data availability. In both cases, DAS are the same and ZK-SNARKs are the same technology, except that in one case they are smart contract code and in the other they are a sacred function of the protocol. In a real technical sense, Ethereum is doing sharding, and rollups are sharding.

This naturally leads to the question: what is the difference between these two worlds? One answer is that the consequences of coding errors are different: in the rollup world, coins are lost, while in the sharded world, you have consensus failures.

But it is expected that as protocols solidify and formal verification techniques improve, the importance of bugs will decrease. So what are the differences between these two visions, and can we expect them to persist in the long term?

Diversity of execution environments

One idea that was briefly discussed in Ethereum in 2019 was execution environments . Essentially, Ethereum would have different “zones” that could have different rules for how accounts work (including completely different approaches like UTXO), how the virtual machine works, and other features.

This allows for diversity of approach across various parts of the stack, which would be difficult to achieve if Ethereum tried to do everything on its own.

In the end, some of the more ambitious plans were abandoned, leaving only the EVM. However, Ethereum L2 (including rollups, valdiums, and Plasmas) can be said to have ultimately served as an execution environment.

Today, the focus is often on L2 equivalents to the EVM, but this ignores the diversity of many alternative approaches:

• Arbitrum Stylus : adds a second WASM-based virtual machine to the EVM;

• Fuel : uses a UTXO-based architecture similar to Bitcoin (but more comprehensive);

• Aztec : Introduces a new language and programming paradigm designed around privacy-preserving smart contracts based on ZK-SNARKs.

UTXO-based architecture Source: Fuel document

Trying to make the EVM a super virtual machine that covers all possible paradigms would compromise the implementation of each concept, and it would be better to let these platforms specialize.

Security Tradeoffs: Scale vs. Speed

Ethereum L1 provides really strong security guarantees. If certain data is inside a block finalized on L1, the entire consensus (including social consensus in extreme cases) works to ensure that this data cannot be edited to violate the rules of the application that put this data inside the block, ensure that any execution triggered by this data cannot be undone, and ensure that this data remains accessible.

To achieve these guarantees, Ethereum L1 is willing to accept high costs. At the time of writing, transaction fees are relatively low: L2 transactions cost less than 1 cent each , and even L1 costs less than $1 for a basic ETH transfer. If technology advances quickly enough and the growth of available block space keeps up with demand, then these fees may remain low in the future, but they may not.

And for many non-financial applications, like social media or games, even $0.01 per transaction is too high. But social media and games don’t need the same security model as L1. It doesn’t matter if someone can revert their lost chess game for a million dollars, or make one of your tweets look like it was posted three days after it was actually posted.

Therefore, these applications should not pay the same security costs. L2-centric approaches enable this by supporting a range of data availability methods from rollups 에게 plasma 에게 validiums .

Different L2 types are suitable for different use cases ( click here to read more )

Another security tradeoff arises around the problem of asset transfer from L2 to L2 . It is expected that in the future (5-10 years), all rollups will be ZK rollups, and super-efficient proof systems with lookup functions such as Binius 그리고 Circle STARKs , coupled with a proof aggregation layer, will make it possible for L2 to provide final state roots in each time slot. But currently it can only be a complex mixture of optimistic rollups and ZK rollups under various proof time windows.

If execution layer sharding had been implemented in 2021, the security model for keeping the shards honest would have been optimistic rollups, not ZK — so L1 would have had to manage systemically complex fraud proof logic on-chain, and have a week-long withdrawal period when moving assets between shards. But like the code bug, this issue was ultimately temporary.

Transaction speed is the third and more permanent aspect of the security tradeoff. Ethereum has a block every 12 seconds and is reluctant to go faster because it would over-centralize the network. However, many L2s are exploring block times of a few hundred milliseconds.

12 seconds isn’t too bad: users submitting transactions have to wait about 6-7 seconds on average for them to be included in a block (not just 6 seconds, because the next block might not include them). This is comparable to the time you have to wait when paying with a credit card. But many applications require higher speeds, and L2 can provide that.

To provide this higher speed, L2 relies on a pre-confirmation mechanism: L2s own validators digitally sign a promise to include the transaction at a certain time, and if the transaction is not included, they will be punished. A mechanism called StakeSure takes this a step further.

L2 Pre-confirmation

Now one could try to implement all of this at L1. L1 could include a system of fast pre-confirmations and slow final confirmations. It could include different shards with different levels of security. However, this would increase the complexity of the protocol. Additionally, doing all the work at L1 would risk overloading consensus , because many approaches to greater scale or faster throughput have higher risks of centralization or require stronger forms of governance, and if done at L1, the impact of these stronger requirements would ripple through to other parts of the protocol. By providing these trade-offs at Layer 2, Ethereum can largely avoid these risks.

What challenges does Ethereum’s L2-centric ecosystem face?

Ethereum’s L2-centric approach faces a key challenge that L1-centric ecosystems don’t face nearly as much: coordination. In other words, while there are many forks of Ethereum, the challenge is to maintain its fundamental property that all of Ethereum feels like “Ethereum” and has Ethereum’s network effects, rather than N independent chains. Today, this situation is unsatisfactory in many ways:

• Moving tokens from layer 2 to another typically requires centralized bridge platforms and is very complex for the average user. If you have tokens on Optimism, you can’t just paste someone else’s Arbitrum address into your wallet and send them funds.

• Cross-chain smart contract wallet support is not very good for both personal smart contract wallets and organizational wallets (including DAOs). If you change the key on one L2, you also need to change the key on every other L2.

• Decentralized validation infrastructure is generally lacking. Ethereum is finally starting to get decent light clients, such as Helios . But it doesn’t make sense if all activity happens on L2, which all requires its own centralized RPC. In principle, it’s not hard to make light clients for L2 once you have an Ethereum headchain; but in practice, too little attention has been paid to this.

Efforts are underway to improve all three. For cross-chain token swaps, the ERC-7683 standard is an emerging option that, unlike existing “centralized bridges,” does not have any fixed central operator, token, or governing body.

For cross-chain accounts, most wallets take the approach of using cross-chain replayable information to update keys in the short term and keystores in the long term. Light clients for L2 are beginning to appear, such as Beerus for the Starknet network. In addition, recent efforts to improve the user experience through next-generation wallets have solved some more fundamental problems, such as users no longer needing to manually switch to the correct network to access dapps.

Rabby displays a comprehensive view of asset balances on multiple chains (something that wallets didn’t have until recently)

But it is important to recognize that an L2-centric ecosystem does swim upstream to some extent when trying to coordinate.

Individual L2 institutions have no natural economic incentive to build infrastructure to coordinate: small L2 institutions do not, because they can only gain a small portion of the benefits from their contributions; large L2 institutions do not, because they can gain just as much or more from strengthening their own local network effects.

It’s not like there’s a magical perfect solution to this problem. It’s just that the ecosystem needs to more fully recognize that cross-L2 infrastructure is a type of Ethereum infrastructure, just like L1 clients, 개발 tools, and programming languages, and should be valued and funded. Currently, there is the Protocol Guild , and perhaps the Basic Infrastructure Guild.

요약

In public discussions, Ethereum L2 and execution layer sharding are often described as two opposing strategies for how to scale blockchains. However, when looking at the underlying technology, a conundrum emerges: the actual underlying scaling methods are exactly the same, with the main difference being: who is responsible for building and updating the corresponding components, and how much autonomy do they have?

The Ethereum L2-centric ecosystem is sharding in the true technical sense, but within sharding, you can create your own shard with your own rules. This approach is very powerful and allows for a lot of creativity and autonomous innovation. But it also presents some key challenges, especially in terms of coordination.

For an L2-centric ecosystem like Ethereum to succeed, it must understand these challenges and address them head on to gain as many benefits as possible from an L1-centric ecosystem and get as close to the best of both worlds as possible.

This article is sourced from the internet: Vitalik Buterin’s new article: What is the difference between Ethereum L2 and execution layer sharding?

Related: Base is up, BSC is down: In-depth discussion of the on-chain gap between Base and BSC

Source: CapitalismLab Aerdromes price has gone through a round, and Base has single-handedly supported the peak 1 B Mcap, 2B FDV, a hundred times coin, showing off its muscles. The positive externalities it brought also further revitalized the Base ecosystem. On the other hand, BSC has not made any progress even after the shoe dropped this round. Where is the gap? This thread will use this as a starting point to discuss and comment on the gap between the two CEXs on the chain in this round. The reason why Coinbase pulled Aero is very simple. As shown in the figure below, in the past, projects incentivized DeFi miners with direct incentives. For example, for a project token worth $2, a miner might get an additional $1 from the DEX…