From: Ethereum Co-founder Vitalik
Compiled | Odaily (@OdailyChina）
Translator | Ethan (@ethanzhang_web3）
Besides network security concerns, the most common criticism of increasing L1 gas limits is that it would increase the difficulty of running full nodes. Especially in the context of a roadmap focusing on full node splitting, understanding the role of full nodes is crucial to addressing this issue.
Historically, people have believed that full nodes are used to verify on-chain data; please refer here for my own explanation of what might happen if ordinary users cannot verify. If this were the only issue, ZK-EVM could unlock L1 expansion: the only limitation would be keeping the block construction and proof costs low enough to maintain both 1-of-n censorship resistance and market competitiveness.
But in reality, this is not the only problem. Another major issue is that having a complete node is extremely valuable, allowing you to have a local RPC server to read the chain in a trustless, censorship-resistant, and privacy-friendly manner. This document will discuss adjustments to the current L1 scaling roadmap to achieve this goal.
Why Continue with Trustlessness and Privacy via 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. With this, plus Helios and ZK-EVM verification, any user can connect to an external RPC and be fully confident that: (i) the chain they obtain is correct; (ii) their data privacy is protected. So we can't help but ask: why not stop here? Won't these advanced cryptographic solutions make self-hosted nodes an obsolete relic?
Here, I can provide several responses:
Fully trustless cryptographic solutions (i.e., 1-server PIR) would be very expensive. The current overhead is impractically high, and even after multiple efficiency improvements, it will likely remain expensive.
Metadata privacy. Which IP address makes a request at what time, and the pattern of requests, can reveal a lot of user information by themselves.
Censorship vulnerabilities: A market structure dominated by a few RPC providers would face strong pressure to delist or censor users. Many RPC providers have already excluded entire countries.
For these reasons, continuing to ensure easier personal node operation remains valuable.
Short-term Priorities
Prioritize comprehensive EIP-4444 promotion until the final state where each node stores only about 36 days of data. This will significantly reduce disk space requirements, which are the main obstacle to more people running nodes. Afterward, node disk space requirements will be: (i) state size; (ii) state Merkle branches; (iii) 36 days of history.
Build a distributed historical storage solution where each node can store a small portion of historical data older than the deadline. Use erasure coding to maximize robustness. This can ensure the "blockchain is eternal" feature without relying on centralized providers or imposing a heavy burden on node operators.
Adjust gas pricing to make storage costs higher and execution costs lower. Particularly prioritizing increasing the gas cost of creating new states: (i) SSTORE for new storage slots, (ii) contract code creation, (iii) sending ETH to accounts without balance or nonce.
Medium-term Priority: Stateless Verification
Once we enable stateless verification, it becomes possible to run nodes with RPC functionality (i.e., nodes storing state) without storing state Merkle branches. This will further reduce storage requirements by about 2 times.
A New Type of Node: Partially Stateless Nodes
This is a new idea and key to allowing personal nodes to run when L1 gas limits grow 10-100 times.
We add a node type that can stateless verify blocks, verify the entire chain (via stateless verification or ZK-EVM), and maintain a partial state update. As long as the required data is within this state subset, the node can respond to RPC requests; other requests will fail (or must fall back to externally hosted cryptographic solutions; whether to do so should be user-selected).
The specific part of the state to maintain depends on the user's chosen configuration. Examples include:
All states except known garbage contracts
States related to all EOAs and SCWs, and all common ERC 20 and ERC 721 tokens and applications
States related to all EOAs and SCWs accessed in the past two years, some common 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 node with --save_state_by_config 0x 12345...67890, which will specify in some language a list of addresses, storage slots, or other filter areas that the node will save and keep updated. Note that users do not need to save Merkle branches; they only need to save the original values.
This type of node allows users to directly access locally the states they care about while maximizing privacy in accessing those states.
