This article is from: Ethereum co-founder Vitalik

Translation | Odaily Planet Daily (@OdailyChina)

Translator | Ethan (@ethanzhangweb3)_

Aside from concerns about network security, the most common criticism of increasing the L1 Gas limit is that it makes running full nodes more difficult. Particularly in the context of a roadmap focused on decoupling full nodes, addressing this issue requires an understanding of the role of full nodes.

Historically, full nodes have been viewed as essential for validating on-chain data; see here for my own elaboration on what could happen if ordinary users cannot validate. If this were the only issue, then ZK-EVM could unlock L1 scalability: the only limitation would be keeping the costs of block construction and proof low enough to maintain both 1-of-n censorship resistance and market competitiveness.

But in reality, this is not the only issue. Another major concern is that having a full node is very valuable, as it allows 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 scalability roadmap to achieve this goal.

Why continue to achieve trustlessness and privacy through 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. This, combined with Helios and ZK-EVM verification, allows any user to connect to external RPCs with complete confidence that: (i) the chain they are accessing is correct; (ii) their data privacy is protected. Therefore, we must ask: why stop there? Wouldn't these advanced cryptographic solutions render self-hosted nodes obsolete?

Here, I can provide several responses:

• Fully trustless cryptographic solutions (i.e., 1-server PIR) would be extremely expensive. The current overhead is impractically high, and even with multiple efficiency improvements, it is likely to remain costly.

• Metadata privacy. The IP address that made a request at what time, and the patterns of those requests, can reveal a significant amount of information about the user.

• Censorship vulnerabilities: A market structure dominated by a few RPC providers will face strong pressures to delist platforms or censor users. Many RPC providers have already excluded entire countries.

For these reasons, it is valuable to continue ensuring that running personal nodes is more convenient.

Short-term Priorities

• Prioritize the full rollout of EIP-4444 until each node only stores the final state of about 36 days of data. This will significantly reduce disk space requirements, which is the main issue preventing more people from running nodes. After this, the disk space requirements for nodes 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 prior to the cutoff date. Use erasure coding to maximize robustness. This can ensure the characteristic that "blockchain is eternal" without relying on centralized providers or placing a heavy burden on node operators.

• Adjust gas pricing to make storage costs higher and execution costs lower. A particular priority is to increase the gas cost for creating new states: (i) SSTORE for new storage slots, (ii) contract code creation, (iii) sending ETH to accounts that do not yet have a balance or nonce.

Medium-term Priority: Stateless Verification

Once we enable stateless verification, it will be possible to run nodes with RPC functionality (i.e., nodes that store state) without storing state Merkle branches. This will further reduce storage requirements by about half.

A New Type of Node: Partially Stateless Nodes

This is a new idea and is key to allowing personal nodes to operate in the context of a 10-100x increase in L1 gas limits.

We introduce a new type of node that can statelessly verify blocks, validate the entire chain (through stateless verification or ZK-EVM), and keep part of the state up to date. As long as the required data is within that subset of state, the node can respond to RPC requests; other requests will fail (or must revert to externally hosted cryptographic solutions; whether to do so should be up to the user).

The specific parts of the state to be maintained depend on the configuration chosen by the user. Examples include:

• All states except those known to be junk contracts

• States related to all EOAs and SCWs, as well as all commonly used ERC20 and ERC721 tokens and applications

• States related to all EOAs and SCWs accessed in the past two years, along with some commonly used ERC20 tokens, plus a limited set of exchanges, DeFi, and privacy applications

Configurations can be managed through on-chain contracts: users can run their nodes with --save_state_by_config 0x12345…67890, where that address specifies a list of addresses, storage slots, or other filtered 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 raw values.

This type of node allows users to directly access the states they need to focus on locally while maximizing the privacy of accessing that state.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。