Original author: @VitalikButerin
Translation: Peggy, BlockBeats
Editor's note: As the Ethereum ecosystem continues to grow, how to achieve network scalability without sacrificing security and decentralization has become a core issue. In this article, Vitalik Buterin further outlines the scalability path for Ethereum: in the short term, improve execution efficiency through technical advancements such as gas mechanism optimization and parallel block verification; in the long term, drive network scale enhancements through ZK-EVM and blobs data architecture.
Overall, this approach provides a phased expansion plan aimed at laying the foundation for Ethereum to continuously increase network capacity in the coming years.
The following is the original text:
Now let’s talk about scaling. It mainly divides into two parts: short-term scaling and long-term scaling.
Short-Term Scaling
I have written about short-term scaling elsewhere. The core ideas are roughly as follows:
· Block-level access lists (which will be introduced in the Glamsterdam upgrade) can allow parallelization of block verification.
· ePBS (also to be launched in Glamsterdam) has several features, one of which is: it enables us to safely use a larger proportion of time in each slot to verify blocks, rather than just a few hundred milliseconds as we do now.
· Gas repricing will ensure that the gas costs of various operations align with their actual execution times (along with other costs they incur). We are also exploring a multidimensional gas mechanism, allowing different resources to set separate limits. Together, these two can enable us to use a larger proportion of slot time during block verification without worrying about extreme situations arising.
Regarding multidimensional gas, we have established a phased roadmap. The first phase will separate "state creation costs" from "execution and calldata costs" in the Glamsterdam upgrade.
For example, currently: a SSTORE operation, if shifting the storage slot from non-zero to non-zero, costs 5000 gas; if shifting from zero to non-zero, costs 20000 gas.
In a gas repricing during Glamsterdam, this additional cost will be significantly increased (for example, raised to 60000). The goal is to raise the gas limits while ensuring the speed of execution capacity scaling greatly exceeds the speed of state scale scaling.
Regarding the reasons, I have written about it before: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
Therefore, in Glamsterdam: this SSTORE operation will consume 5000 "regular gas," for example, 55000 "state creation gas."
It should be noted that: state creation gas will not count towards the cap of about 16 million transaction gas.
This means: it will become possible to create contracts larger than currently.
How to Implement Multidimensional Gas in EVM?
Here arises a question: the design of the EVM presumes that gas has only one dimension, for example, GAS, CALL, etc., opcodes are based on this assumption.
Our solution is to maintain two invariants:
If you initiate a call with X gas, then this call will have X gas available, which can be used for "regular operations," or "state creation," or other dimensions that may be added in the future.
If the GAS opcode tells you that you currently have Y gas, then if you initiate a call that consumes X gas, after the call returns, you still have at least Y − X gas available for subsequent operations.
The specific implementation is: we introduce N+1 gas dimensions. By default, N = 1 (state creation), and the additional dimension is called reservoir.
The execution logic of the EVM is:
If possible, prioritizing the consumption of dedicated dimension gas
If insufficient, then consume from the reservoir.
For example, if you have: (100000 state creation gas, 100000 reservoir)
If you use SSTORE to create three new states, the gas change process is: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
In this design:
The GAS opcode returns from the reservoir
CALL will pass a specified amount of gas from the reservoir and simultaneously pass all non-reservoir gas
Multidimensional Gas Pricing
Subsequently, we will further introduce multi-dimensional pricing, allowing different resource dimensions to have different floating gas prices.
This will lead to:
Better long-term economic sustainability
Superior resource allocation efficiency
See more details: https://vitalik.eth.limo/general/2024/05/09/multidim.html
And the reservoir mechanism perfectly addresses the sub-call issue mentioned at the end of that article.
Long-Term Scaling
Long-term scaling mainly includes two directions: ZK-EVM and Blobs.
Blobs
For blobs, we plan to continue iterating on PeerDAS, ultimately hoping to reach a data throughput capacity of about 8 MB/sec.
This scale:
Is sufficient to meet Ethereum's own needs
And is not intended to become a "global data layer."
Currently, blobs are mainly used for L2. Future plans are to allow Ethereum block data itself to be written directly into blobs.
The purpose of this is to enable people to verify a highly scalable Ethereum network without downloading and re-executing the entire chain:
ZK-SNARKs eliminate the need for re-execution
PeerDAS + blobs allow verification of data availability without downloading all data
ZK-EVM
For ZK-EVM, our goal is to gradually increase the network’s reliance on it.
2026: Clients supporting ZK-EVM will emerge, allowing nodes to participate in attestation using ZK-EVM. However, they will not be secure enough for the entire network to depend on them. Still, it is acceptable for about 5% of the network to use them. (If there are issues with ZK-EVM, you won’t be penalized for your stake, but you may build on invalid blocks resulting in loss of rewards.)
2027: We will begin recommending a larger proportion of nodes run ZK-EVM, while focusing on formal verification and improving security. Even if only 20% of the network uses ZK-EVM, we can significantly raise the gas limit, as this provides a low-cost verification path for solo stakers, whose proportion is less than 20% themselves.
When the technology matures: we will introduce a 3-of-5 proof mechanism. This means a block must contain at least 3 proofs from 5 different proof systems to be considered valid. By then, we expect that most nodes will rely on ZK-EVM proofs, except for those that need to index.
Long-term: Continue improving ZK-EVM to make it more robust and undergo stricter formal verification. This phase may also involve changes at the virtual machine level, such as towards RISC-V, among others.
See more details: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
