Vitalik: An Optimization Plan for a Local Node-Focused Scalability Roadmap

Author: Vitalik, founder of Ethereum; Translator: 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 “unbonded full nodes,” addressing this issue requires first understanding the significance of full nodes.

Traditional views hold that full nodes are used to validate on-chain data. 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 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: 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 features achieved by ZK-EVM+PIR?

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

I have a few responses to this:

–Completely trustless cryptographic solutions (such as single-server PIR) are costly. The current overhead is unrealistically 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 Review: The 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 running personal nodes.

2. Short-term Priorities

Prioritize the comprehensive deployment of EIP-4444, ultimately achieving that each node stores only about 36 days of data. This will significantly reduce the hard drive space requirements—the primary obstacle currently preventing people from running nodes. After that, the node storage requirements 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 not only ensures the “permanent storage” characteristic of the blockchain but also does not rely on centralized vendors or impose 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 a new storage slot, (ii) creating contract code, (iii) transferring ETH to accounts with zero balance/zero nonce.

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 save state Merkle branches. This can further reduce storage requirements by about 50%.

4, New node type: Some stateless nodes

This innovative concept 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 type of node: it verifies blocks in a stateless manner, validating the entire chain through stateless verification or ZK-EVM, but only maintaining a partial set of state data. As long as the data required by the RPC request is within this subset of states, the node can respond; other requests will fail (or need to fallback to an externally hosted cryptographic solution - whether to fallback should be chosen by the user).

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

–Exclude all states outside of known garbage contracts.

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

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

Configuration can be managed through on-chain contracts: when users run nodes, they use the “–save_state_by_config 0x12345…67890” parameter, which will define the 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.

These types of nodes provide the advantage of local direct access to critical states while ensuring complete access privacy.