Vitalik: New solution to solve Ethereum L1 scalability issues

This article is from: Ethereum co-founder Vitalik

Compiled | Odaily Planet Daily (@OdailyChina)

Translator | Ethan (@ethanzhang_web3)

Aside from concerns about network security, the most common criticism of raising L1 Gas limits is that it will increase the difficulty of running full nodes. Particularly in the context of a roadmap focusing on full node segmentation, understanding the role of full nodes is essential to address this issue.

Historically, it has been believed that full nodes are used to validate on-chain data; please refer here for my explanation of what might happen if ordinary users cannot validate. If this is the only issue, then ZK-EVM can unlock L1 scalability: the only limitation is to keep the costs of block construction and proof low enough to maintain both 1-of-n censorship resistance and market competitiveness.

But in reality, this is not the only issue. Another major problem is that having a full node is very valuable, as it allows you to have a local RPC server to read the chain in a trustless, censorship-resistant, and privacy-friendly manner. This document will discuss the adjustments made to the current L1 expansion roadmap to achieve this goal.

Why continue to achieve trustlessness and privacy through ZK-EVM + PIR?

In the privacy roadmap I published last month, I proposed TEE + ORAM as a short-term patch, along with PIR as a long-term solution. This way, along with Helios and ZK-EVM verification, any user can connect to external RPCs and be fully assured that: (i) the chain they receive is correct; (ii) their data privacy is protected. Therefore, we can't help but ask: why stop here? Won't these advanced cryptographic solutions render self-hosted nodes obsolete?

Here, I can provide several replies:

• Fully trustless cryptographic solutions (i.e., 1-server PIR) will be extremely expensive. The current overhead is impractically high, and even after multiple efficiency improvements, it will likely still be costly.
• Metadata privacy. Which IP address made a request at what time, and the pattern of the request, this data alone is enough to reveal a large amount of information about the user.
• Censorship Vulnerabilities: A market structure dominated by a small number of RPC providers will face strong pressure to delist platforms or censor users. Many RPC providers have already excluded entire countries.

For these reasons, it is valuable to continue ensuring that personal nodes run more conveniently.

Short-term Priorities

• Increase the priority of the comprehensive promotion of EIP-4444 until each node only stores the final end state data for about 36 days. This will significantly reduce the disk space requirements, which is the main issue preventing more people from running nodes. Thereafter, the disk space requirements for nodes will be: (i) state size; (ii) state Merkle branch; (iii) 36 days of history.
• Build a distributed historical storage solution where each node can store a small portion of historical data that predates the deadline. Use erasure codes to maximize robustness. This ensures the characteristic that "the blockchain is eternal" without relying on centralized providers or placing a heavy burden on node operators.
• Adjust the Gas pricing to make storage costs higher and execution costs lower. The top priority is to increase the Gas cost for creating new states: (i) SSTORE for new storage slots, (ii) contract code creation, (iii) sending ETH to accounts that do not yet have a balance or nonce.

Mid-term Priorities: Stateless Verification

Once we enable stateless validation, it becomes possible to run nodes with RPC functionality (i.e., nodes that store state) without storing the state Merkle branches. This will further reduce storage requirements by approximately 2 times.

A New Type of Node: Partial Stateless Node

This is a new idea and is key to allowing individual nodes to operate under the condition that L1 Gas limits grow by 10-100 times.

We have added a type of node that can validate blocks without state, verify the entire chain (through stateless validation or ZK-EVM), and keep parts of the state up to date. As long as the required data is within this subset of state, the node can respond to RPC requests; other requests will fail (or must revert to externally hosted cryptographic solutions; whether to do this should be up to the user to decide).

The specific parts of the state to be maintained depend on the configuration chosen by the user. An example is as follows.

• All states except those known as junk contracts
• Related status with all EOA and SCW as well as all commonly used ERC 20 and ERC 721 tokens and applications.
• Status related to all EOAs and SCWs visited in the past two years, along with a selection of commonly used ERC 20 tokens, plus a limited set of exchange, DeFi, and privacy applications.

Configuration can be managed through on-chain contracts: Users can run their nodes using --save_state_by_config 0x 12345...67890 where the address specifies in some language the address, storage slots, or other filtered areas that the node will save and keep up to date. Note that users do not need to save the Merkle branch; they only need to save the raw values.

This type of node allows users to directly access the states they need to pay attention to locally, while maximizing the privacy of accessing that state.