Author: Vitalik, Ethereum Founder; Translation: Jinse Finance xiaozhou
Besides network security concerns, the most common criticism of raising the L1 Gas limit is that it would make running full nodes more difficult. Especially in the context of a roadmap centered on "unbundling full nodes", solving this problem requires first understanding the significance of full nodes.
Traditional views hold that full nodes are used to verify on-chain data. If this were the only issue, ZK-EVM could unlock L1 expansion: the only limitation is keeping block construction and proof costs low enough to 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 trustless, censorship-resistant, and privacy-preserving ways of reading on-chain data. This article will discuss how to adjust the current L1 expansion roadmap to achieve this goal.
1. Why Not Be Satisfied with Trustlessness and Privacy Achieved by ZK-EVM+PIR?
My privacy roadmap published last month advocated: short-term adoption of TEEs+ORAM solutions, long-term transition to PIR technology. Combined with Helios and ZK-EVM verification, users connecting to external RPCs can be completely confident that: (i) the obtained chain data is correct, (ii) data privacy is protected. This raises a question: why stop here? Do these advanced cryptographic schemes make self-hosted nodes obsolete?
I have several responses to this:
--Fully trustless cryptographic solutions (such as single-server PIR) are costly. Current overhead is impractically high, and even after multiple efficiency optimizations, it may remain expensive.
--Metadata privacy issues. Metadata such as IP address request times and request patterns themselves can expose a lot of user information.
--Censorship vulnerability: A market structure dominated by a few RPC providers will face strong pressure to ban or censor users. Many RPC providers have already begun completely blocking certain countries.
Therefore, continuing to ensure the convenience of running personal nodes still has value.
2. Short-term Priorities
Prioritize full deployment of EIP-4444, ultimately achieving each node storing only about 36 days of data. This will significantly reduce hard disk space requirements - currently the primary obstacle preventing people from running nodes. Afterwards, 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 so that each node stores a small amount of expired historical data. Maximize reliability through erasure coding technology. This ensures the "blockchain permanent preservation" characteristic without relying on centralized providers or imposing a heavy burden on node operators.
Adjust gas pricing strategy to increase storage costs and reduce execution costs. Specifically increase gas costs for: (i) SSTORE for new storage slots, (ii) creating contract code, (iii) transferring ETH to zero balance/zero nonce accounts.
3. Medium-term Goal: Stateless Validation
After achieving stateless validation, RPC-supporting nodes (i.e., nodes storing state) will no longer need to save state Merkle branches. This can further reduce storage requirements by about 50%.
4. New Node Type: Partial Stateless Nodes
This innovative concept will be key to maintaining personal node operation even after L1 Gas limit increases by 10-100 times.
We introduce a new node type: validating blocks in a stateless manner, verifying the entire chain through stateless validation or ZK-EVM verification, but only maintaining partial state data. As long as the data required by RPC requests is within this state subset, the node can respond; other requests will fail (or need to fall back to externally hosted cryptographic solutions - whether to fall back should be user-selected).
Specifically which states are maintained depends on user configuration, for example:
--Exclude all states except known garbage contracts.
--States related to all EOA, SCW accounts, and common ERC20/ERC721 tokens and applications.
--States of EOA/SCW accounts active in the past two years + some common ERC20 token states + selected swap/DeFi/privacy application states.
Configuration can be managed through on-chain contracts: when users run nodes, they use the "--save_state_by_config 0x12345...67890" parameter, and this address will define the list of addresses, storage slots, or state filtering rules that the node needs to save and update in real-time in a specific language. Note that users do not need to save Merkle branches, only original values.
Such nodes can provide the advantages of local direct access to critical states while ensuring complete access privacy.
