Vitaliks radical new article: Nothing can be done without breaking things to expand the execution layer, and EVM must be

This article comes from: Ethereum co-founder Vitalik

Odaily Planet Daily에서 편집( @오데일리차이나 )

아즈마(Azuma) 번역 ( @아즈마_에스 )

In this post, I will propose a radical idea for the future of Ethereum’s execution layer, which is as ambitious as the Beam Chain plan for the consensus layer. The goal of this plan is to greatly improve the efficiency of Ethereum’s execution layer, solving one of the main scaling bottlenecks, while also greatly simplifying the complexity of the execution layer – in fact, this may be the only way to achieve simplicity.

The core idea of this article is to replace EVM with RISC-V as the virtual machine language for smart contracts.

Important Notes:

• Concepts such as accounts, cross-contract calls, and storage will be fully preserved. These abstract mechanisms work well and developers are used to using them. Opcodes such as SLOAD, SSTORE, BALANCE, and CALL will become RISC-V system calls.

• Developers can still choose Solidity or Vyper. Although Rust can theoretically be used to write smart contracts, it is expected that most developers will continue to use Solidity (or Vyper) , which will be adapted to RISC-V as the backend compilation target – this is because smart contracts written in Rust are less readable, while Solidity and Vyper are easier to understand. The development experience will hardly change, and developers may not feel the difference at all.

• The old and new contracts will be bidirectionally interoperable. Traditional EVM contracts will continue to run and fully interact with the new RISC-V contracts. The specific implementation will be detailed later.

• There is already a precedent: Nervos CKB VM is essentially a RISC-V-based implementation.

Why is this change needed?

In the short term, the main bottlenecks of Ethereum Layer 1 expansion will be solved through upcoming EIPs (such as block-level access lists, delayed execution, distributed history storage, and EIP-4444); in the medium term, we will solve more problems through statelessness and ZK-EVM; but in the long term, the main factors limiting Ethereum Layer 1 expansion will become:

1. Data availability sampling and stability of historical storage protocols;

2. The need to maintain a competitive market for block production;

3. The proving capabilities of the ZK-EVM.

This article will demonstrate that replacing ZK-EVM with RISC-V can break through the key bottlenecks in points 2 and 3.

The following is a statistical table of the number of cycles required by Succinct ZK-EVM to prove each link of the EVM execution layer:

The four main time-consuming links are: deserialize_inputs (data deserialization), initialize_witness_db (witness database initialization), state_root_computation (state root calculation) and block_execution (block execution).

“Witness database initialization” and “state root calculation” are both related to the state tree, while “data deserialization” refers to the process of converting block and witness data into internal representation. Therefore, more than 50% of the time is actually related to the size of the witness data.

These steps can be significantly optimized by replacing the current keccak 16-ary Merkle patricia tree with a binary tree that uses a proof-friendly hash function. If we use Poseidon, we can prove 2 million hashes per second on a laptop (compared to about 15,000 hashes per second for keccak). There are many other options besides Poseidon. Overall, there is an opportunity to significantly reduce the time spent on these steps. In addition, we can further simplify the process by removing accrue_logs_bloom.

Now only block execution remains, which takes up about half of the current proof cycle. If we want to increase the overall proof efficiency by 100 times, we must increase the EVM proof efficiency by at least 50 times. There are two current paths: one is to try to create a more efficient EVM implementation to reduce the proof cycle; the other is to directly let developers use the RISC-V virtual machine that has been adopted at the bottom of ZK-EVM.

Some data show that efficiency can be improved by more than 100 times in certain scenarios:

In practice, the remaining proof time will be mainly consumed by precompiles. If RISC-V is set as the main virtual machine, the gas fee mechanism will reflect the actual proof time, and economic pressure will prompt developers to reduce the use of high-cost precompiles . Although the actual benefits may not be as good as the theoretical value, it is expected to be very significant.

It’s worth noting that a similar 50/50 split of “EVM” and “other links” exists in regular EVM execution, and we intuitively believe that removing the EVM as a “middle layer” should yield a similar efficiency improvement.

Implementation

There are several ways to implement the above proposal.

The least disruptive approach is to support both virtual machines, allowing contracts to be written in either virtual machine. Both types of contracts can access the same functionality: persistent storage (SLOAD/SSTORE), ETH balance management, making and receiving calls, etc. EVM and RISC-V contracts can be freely interoperable: calling an EVM contract from a RISC-V perspective will be treated as a system call (syscall) with special parameters, while the EVM contract receiving the call will parse it as a normal CALL instruction.

A more radical solution would convert existing EVM contracts to call an EVM interpreter contract written in RISC-V to execute its original EVM code. Specifically, assuming an EVM contract contains code C and the EVM interpreter is located at address X, the contract will be replaced with top-level logic: when an external call is made with call parameter D, the logic will send a (C, D) request to X, wait for the return value and forward it. If the EVM interpreter itself needs to call a contract to perform operations such as CALL, SLOAD or SSTORE, the contract will respond directly.

The compromise is to build on the second solution and explicitly support the concept of virtual machine interpreter through the protocol layer – that is, the interpreter logic must be written in RISC-V. EVM will be the first official interpreter, and other types (such as Move language interpreter) may be introduced in the future.

The core advantage of the second and third options is that they greatly simplify the execution layer specification. Considering that even incremental simplifications such as removing SELFDESTRUCT are difficult, such changes may be the only realistic way to achieve simplification. The Tinygrad project strictly stipulates that the amount of code will never exceed 10,000 lines, and the ideal blockchain base layer should pursue more extreme simplicity. The Beam Chain plan points the way to the simplification of the Ethereum consensus layer, and the execution layer may only achieve similar breakthroughs through such fundamental changes.

This article is sourced from the internet: Vitaliks radical new article: Nothing can be done without breaking things to expand the execution layer, and EVM must be iterated in the future

Related: This weeks featured interactive projects: Momentum mainnet interaction, Solix on-hook mining, Hana Network card draw to

Original | Odaily Planet Daily ( @OdailyChina ) Author | Asher ( @Asher_0210 ) Momentum: Move centralized liquidity engine Reasons to participate Momentum is the centralized liquidity engine of Move. Its predecessor was Momentum Safe, which provides solutions such as Multi-Sig Treasury Management, Token Vesting and Liquidity Provisioning. Currently, Momentum has more than 35,000 active wallets, $ 500 million in TVL and $1.8 billion in trading volume. Currently, Momentum has completed $10 million in financing. Recently, the ve (3, 3) decentralized exchange (DEX) and token issuance platform was launched on the Sui blockchain. ChefWEN, CEO and co-founder of Momentum, said, We believe that BTCFi is about to drive the Sui chain into an exponential growth phase. We are very happy that Momentum can start a new stage of DeFi on…