jakiro
Author: Vitalik, founder of Ethereum; Translation: Bitchain Vision xiaozhou
The most common criticism about increasing the L1 Gas cap is besides network security concerns that make full node operation more difficult.Especially in the context of the roadmap with “unbinding full nodes” as the core, to solve this problem, we need to first understand the significance of the existence of full nodes.
The traditional view is that full nodes are used to verify on-chain data.If this is the only problem, then ZK-EVM can unlock L1 expansion: the only limitation is to keep the block construction and proof costs low enough so that both can maintain 1 of n censorship resistance and form 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, allowing you to read on-chain data in a trustless, censorship-resistant and privacy-protected manner.This article will discuss how to adjust the current L1 expansion roadmap to achieve this goal.
1. Why are you not satisfied with the trustlessness and privacy implemented by ZK-EVM+PIR?
My privacy roadmap released last month advocates: TEEs+ORAM solutions are adopted in the short term, and PIR technology is turned in the long term.Combined with Helios and ZK-EVM verification, users can fully convince when connecting to external RPCs that (i) the acquired chain data is correct and (ii) the data privacy is protected.This raises the question: Why not stop there?Do these advanced cryptography solutions make self-hosted nodes obsolete?
I have a few responses to this:
—Fully trusted cryptography solutions (such as single-server PIR) are expensive.The current overhead is unrealistic, and even after multiple efficiency optimizations, it may still maintain high prices.
—Metadata privacy issues.Metadata such as the request time, request mode, and other metadata of the IP address will themselves expose a large amount of user information.
—Review of vulnerability:The market structure dominated by a few RPC suppliers will face strong user bans or scrutiny pressure.Many RPC providers have begun to completely block certain countries.
Therefore, it is still valuable to continue to ensure the convenience of personal nodes.
2. Short-term priorities
Priority to the full deployment of EIP-4444, and finally realizes that each node only stores data for about 36 days.This will significantly reduce the demand for hard disk space – the primary obstacle that is currently preventing people from running nodes.After that, the node storage requirements will only include: (i) status data, (ii) status Merkel branch, (iii) 36-day historical data.
Building a distributed historical storage solution, so that each node can store a small amount of historical data that expires.Maximize reliability through erasure coding technology.This not only ensures the “blockchain permanent preservation” feature, but also does not need to rely on centralized suppliers or put heavy burdens on node operators.
Adjust Gas pricing strategy to increase storage costs and reduce execution costs.Focus on increasing the Gas cost of the following operations: (i) execute SSTORE for the new storage slot, (ii) create a contract code, and (iii) transfer ETH to the zero balance/zero nonce account.
3. Medium-term goal: stateless verification
After stateless verification is implemented, running nodes that support RPC (i.e. nodes that store state) will not need to save state Merkel branches.This can reduce storage requirements by about 50%.
4. New nodes: some stateless nodes
This innovative concept will become the key to maintaining personal node operation after the L1 Gas cap is increased by 10-100 times.
We have added a new node type: verify the block in a stateless manner, verify the entire chain through stateless verification or ZK-EVM, but only maintain some of the state data.As long as the data required for RPC requests are within that subset of state, the node can respond; other requests will fail (or need to be rolled back to an externally managed cryptography solution—whether the fallback should be chosen by the user).
The specific maintenance status depends on the user configuration, for example:
–Exclude all states outside known garbage contracts.
–Status related to all EOA, SCW accounts and commonly used ERC20/ERC721 tokens and applications.
–The active EOA/SCW account status in the past two years + some commonly used ERC20 token status + selected swap/DeFi/privacy application status.
Configuration can be managed through on-chain contracts: when the user runs a node, use the “–save_state_by_config 0x12345…67890” parameter, which will define the address list, storage slot or status filtering rules that the node needs to save and update in real time in a specific language.Note that the user does not need to save the Merkel branch, only the original value is required.
These nodes provide local direct access to critical states and ensure full access privacy.
