This article comes from: Ethereum co-founder Vitalik
Compiled by | Odaily Planet Daily ( @OdailyChina )
Translator | Ethan ( @ethanzhang_web3 )
In addition to concerns about network security, the most common criticism of increasing the L1 gas limit is that it will make it more difficult to run a full node. Especially in the context of the roadmap focusing on full node splits , to address this issue, it is necessary to understand the role of full nodes.
Historically, people have assumed that full nodes are used to verify on-chain data; see here for my own articulation of what might happen if regular users can’t verify. If that were the only problem, then ZK-EVM would unlock L1 scaling: the only limitation would be keeping block construction and proof costs low enough that both remain 1-of-n censorship-resistant and market-competitive.
But in reality, that’s not the only problem. Another major issue is that it’s extremely valuable to have a full node so that you can have a local RPC server that can be used to read the chain in a trustless, censorship-resistant, and privacy-friendly way. This document will discuss the adjustments to the current L1 scaling roadmap to achieve this goal.
Why continue to achieve trustlessness and privacy through ZK-EVM + PIR?
The privacy roadmap I published last month outlined TEE + ORAM as a short-term fix, plus PIR as a long-term solution. This, combined with Helios and ZK-EVM verification, will allow any user to connect to an external RPC with complete confidence that (i) the chain they are getting is the correct one, and (ii) the privacy of their data is preserved. So, we cant help but ask: why cant we stop here? Wont these advanced cryptographic solutions make self-hosted nodes obsolete relics?
Here, I can give a few answers:
A completely trustless encryption solution (i.e. 1-server PIR) would be prohibitively expensive. The current overhead is impractical and will likely remain expensive even after many efficiency improvements.
Metadata privacy. Which IP address made a request at what time, and the pattern of the requests, can reveal a lot about a user.
Censorship loopholes: Market structures dominated by a small number of RPC providers will face strong pressure to deplatform or censor users. Many RPC providers already exclude entire countries.
For these reasons, there is value in continuing to ensure that it is easier to run a personal node.
Short-term priorities
Prioritize full rollout of EIP-4444, leading to a final end state where each node only stores ~36 days of data. This will significantly reduce disk space requirements, which is the main issue preventing more people from running nodes. From now on, a nodes 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 ensures the blockchain is eternal feature without relying on centralized providers or placing a heavy burden on node operators.
Adjust gas pricing to make storage more expensive and execution cheaper. A particular priority is to increase the gas cost of creating new state: (i) SSTORE for a new storage slot, (ii) contract code creation, (iii) sending ETH to an account that does not yet have a balance or nonce.
Mid-term priority: stateless authentication
Once we enable stateless validation, it will be possible to run RPC-capable nodes (i.e. nodes that store state) without storing state Merkle branches. This will further reduce storage requirements by about 2x.
A new type of node: partially stateless node
This is a new idea and is key to allowing individual nodes to run as L1 gas limits increase 10-100x.
We added a node type that can statelessly validate blocks, validate the entire chain (either through stateless validation or ZK-EVM), and keep a subset of the state up to date. As long as the required data is within that subset of the state, the node will be able to respond to RPC requests; other requests will fail (or have to fall back to an externally hosted cryptographic solution; whether to do this is user-selectable).
The exact portion of the state to be preserved depends on the configuration selected by the user. For example:
All states except for known junk contracts
Status related to all EOAs and SCWs and all commonly used ERC 20 and ERC 721 tokens and applications
Status related to all EOAs and SCWs accessed in the past two years and some commonly used ERC 20 tokens, plus a limited set of exchanges, defi, and privacy applications
Configuration can be managed via an on-chain contract: users can run their node with --save_state_by_config 0x 12345...67890 , which specifies in some language the list of addresses, storage slots, or other filtered areas that the node will save and keep up to date with state. 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 the state of interest locally and maximizes the privacy of access to that state.
