Vitalik: An optimization plan for a scaling roadmap focusing on local Nodes.

Written by: Vitalik, founder of Ethereum

Compiled by: Golden Finance xiaozhou

The most common criticism of raising the L1 Gas limit, aside from concerns about network security, is that it will make running full nodes more difficult. Especially in the context of a roadmap centered around "unbinding full nodes," addressing this issue requires first understanding the significance of full nodes.

The traditional view holds that full nodes are used to validate on-chain data. If this is the only issue, then ZK-EVM can unlock L1 scaling: the only limitation is to keep the costs of block construction and proof low enough so that both can maintain 1 of n censorship resistance while forming a competitive market.

But in reality, this is not the only consideration. Another important factor is that running a full node allows you to have a local RPC server, enabling you to read on-chain data in a trustless, censorship-resistant, and privacy-preserving manner. This article will discuss how to adjust the current L1 scaling roadmap to achieve this goal.

1. Why not be satisfied with the trustless and privacy achieved by ZK-EVM+PIR?

The privacy roadmap I released last month advocates for the short-term adoption of TEEs + ORAM solutions, and in the long term, a shift towards PIR technology. Combining Helios and ZK-EVM verification, users can be completely assured when connecting to external RPCs: (i) that the chain data obtained is correct, and (ii) that data privacy is protected. This raises a question: why not stop here? Do these advanced cryptographic solutions render self-hosted nodes obsolete?

I have a few responses to this:

Fully trustless cryptographic schemes (such as single-server PIR) are costly. The current overhead is impractically high, and even after multiple efficiency optimizations, it may still maintain a high price.

Metadata privacy issues. The request time, request patterns, and other metadata of IP addresses can expose a large amount of user information.

Vulnerability to censorship: A market structure dominated by a few RPC providers will face strong user bans or censorship pressures. Many RPC providers have begun to completely block certain countries.

Therefore, it is still valuable to continue ensuring the convenience of personal node operation.

2. Short-term priorities

Prioritize the comprehensive deployment of EIP-4444, ultimately achieving that each node only stores data for about 36 days. This will significantly reduce hard drive space requirements—the primary obstacle currently preventing people from running nodes. After this, the storage requirements for nodes will only include: (i) state data, (ii) state Merkle branches, (iii)36 days of historical data.

Build a distributed historical storage solution that allows each node to store a small amount of expired historical data. Maximize reliability through erasure coding technology. This can ensure the "permanent storage of blockchain" feature while not relying on centralized vendors or placing a heavy burden on node operators.

Adjust the Gas pricing strategy to increase storage costs and reduce execution costs. Focus on increasing the Gas costs for the following operations: (i) executing SSTORE for new storage slots, (ii) creating contract code, (iii) transferring ETH to zero balance / zero nonce accounts.

3. Mid-term goal: Stateless verification

After implementing stateless verification, nodes that support RPC (i.e., nodes that store state) will no longer need to maintain the state Merkle branch. This can reduce storage requirements by approximately 50%.

4. New type of node: Some stateless nodes

This innovative idea will be key to maintaining the operation of individual nodes even after the L1 Gas limit is increased by 10-100 times.

We have added a new node type: verifying blocks in a stateless manner, validating the entire chain through stateless verification or ZK-EVM, but only maintaining partial state data. As long as the data required for the RPC request is within this subset of state, the node can respond; other requests will fail (or may revert to an externally hosted cryptographic solution – whether to revert should be chosen by the user).

The specific statuses maintained depend on user configuration, for example:

Exclude all states except known junk contracts.

Status related to all EOA, SCW accounts and commonly used ERC20/ERC721 tokens and applications.

The status of active EOA/SCW accounts in the past two years + the status of some commonly used ERC20 tokens + the status of selected swap/DeFi/privacy applications.

Configuration can be managed through on-chain contracts: when users run a node, they use the parameter "--save_state_by_config 0x12345...67890", which will define a list of addresses, storage slots, or state filtering rules that need to be saved and updated in real-time in a specific language. Note that users do not need to save the Merkle branch; only the original values need to be saved.

This type of node not only provides the advantage of local direct access to critical states but also ensures complete access privacy.