Vitalik: An optimization plan for the expansion roadmap focusing on local nodes

Author: Vitalik, founder of Ethereum; Translation: Golden Finance Xiaozhou

The most common criticism of raising the L1 Gas limit, in addition to concerns about network security, is that it will make it more difficult to run a full node. Especially in the context of a roadmap centered on "unbinding full nodes", solving this problem requires understanding the significance of the existence of full nodes.

The traditional view is that full nodes are used to verify on-chain data. If this were the only problem, then ZK-EVM would unlock L1 expansion: the only limitation is to keep the cost of block construction and proof 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, which can read on-chain data in a trustless, censorship-resistant and privacy-preserving way.This article will discuss how to adjust the current L1 expansion roadmap to achieve this goal. 1. Why not settle for trustlessness and privacy with ZK-EVM+PIR? The privacy roadmap I published last month advocates the adoption of TEEs+ORAM in the short term and PIR in the long term. With Helios and ZK-EVM verification, users can be fully confident that (i) the chain data they are getting is correct and (ii) the privacy of the data is protected when connecting to an external RPC. This begs the question: why not stop there? Do these advanced cryptographic schemes make self-hosted nodes obsolete? I have a few responses to this: -- Fully trustless cryptographic schemes (such as single-server PIR) are expensive. The current overhead is impractical and will likely remain high even after multiple efficiency optimizations.

--Metadata privacy issues. Metadata such as the request time and request pattern of the IP address itself will reveal 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 begun to completely block certain countries.

Therefore, it is still valuable to continue to ensure the convenience of running personal nodes.

2. Short-term priorities

Prioritize the full deployment of EIP-4444, and ultimately achieve that each node only stores about 36 days of data. This will significantly reduce the demand for hard disk space, which is currently the primary obstacle that prevents people from running nodes. After that, the node storage requirements will only include: (i) state data, (ii) state Merkel branch, and (iii) 36 days of historical data.

Build a distributed historical storage solution so that each node stores a small amount of overdue historical data. Maximize reliability through erasure coding technology. This can ensure the "permanent preservation of blockchain" feature without relying on centralized suppliers or placing a heavy burden 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) executing SSTORE for a new storage slot, (ii) creating contract code, and (iii) transferring ETH to a zero balance/zero nonce account.

3. Mid-term goal: stateless verification

After implementing stateless verification, running nodes that support RPC (i.e. nodes that store state) will no longer need to save the state Merkel branch. This can reduce storage requirements by about 50%.

4. New Node: Partially Stateless Node

This innovative concept will be the key to keeping personal nodes running after the L1 Gas limit is increased by 10-100 times.

We have added a new node type: verifying blocks in a stateless manner, verifying the entire chain through stateless verification or ZK-EVM, but only maintaining partial state data. As long as the data required by the RPC request is within this state subset, the node will respond; other requests will fail (or need to fall back to an externally hosted cryptographic solution - whether to fall back should be selected by the user).

Specific statuses to be maintained depend on user configuration, for example:

--All statuses except known junk contracts.

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

--Status of active EOA/SCW accounts in the past 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 address list, storage slot 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 the original values.

This type of node can provide the advantages of local direct access to key states while ensuring complete access privacy.