Vitalik: A step-by-step roadmap for extending Rollups
原文标题：《 A step-by-step roadmap for scaling rollups with calldata expansion and sharding 》
原文作者： Vitalik Buterin，以太坊联合创始人
South Wind, Unitimes
For Ethereum, Rollups In the short to medium term, it may be the only untrusted scalable solution for the long term. Transaction fees on Ethereum L1 have been high for months now, and it's even more urgent to take whatever action is necessary to help drive the entire ecosystem to Rollups. Rollups has significantly reduced fees for many Ethereum users: L2fees.info Websites often show that the cost of Optimism and Arbitrum networks is about 3-8 times lower than that of the ethereum base layer itself, while zK-Rollups has better data compression and can avoid including signatures, so its cost is about 40-100 times lower than that of the Ethereum base layer.
However, even these fees are too expensive for many users. Eg. For a long time, Data sharding & NBSP; (Data Sharding) is considered as a solution to the chronic deficiencies of Rollups in its current form, and data sharding is expected to add approximately 1-2MB/s of dedicated data space to Rollups on the Ethereum chain. This article describes a practical path to implement this solution to unlock data space for Rollups as quickly as possible and add more additional space and security over time.
Step 1: expand calldata
The existing Rollups use transaction CallData. Therefore, if we want to increase Rollups capacity and reduce costs in the short term without requiring any additional work on the part of the individual Rollups teams, we should reduce the Gas cost of trading CallData. The current average block size is nowhere near a size that threatens the stability of the Ethereum network, so it is possible to be safe to do so, although some extra logic may be required to prevent very insecure edge cases.
See & have spent Eip-4488, or another (simpler but more modest). The EIP - 4490 proposals.
The EIP - 4488:
https://github.com/ethereum/EIPs/pull/4488
The EIP - 4490:
https://github.com/ethereum/EIPs/pull/4490
EIP 4488 should be able to transfer each slot&NBsp; The data space available for Rollups increases to a theoretical maximum of about 1 MB and reduces the cost on Rollups by about 5 times. This can be done much faster than the later steps.
Step 2: Several pieces & NBSP;
In the meantime, we can start doing some work to roll out "proper" shards. It will take a long time to implement sharding in its full (functional) form, but what we can do is we can implement it step by step and benefit from each step. The first step, of course, is to implement the "business logic" of the sharding specification, but keep the number of shards that come online first very low. (say 4 shards) to avoid most of the difficulties surrounding sharding networks. Each shard is broadcast on its own sub-network. By default, verifiers will trust the committee, but they can choose to be in each sub-network if they wish, but they will only receive a beacon block if they see the full data of any shard block that the beacon block confirms.
The sharding specification itself is not particularly difficult; It has boilerplate code changes of a similar scale to the recently released Altair hard fork (The Altair beacon change specification file is 728 lines, the sharded Beacon change specification file is 888 lines), so it is reasonable to expect that it can be implemented in a similar timeframe to Altair's implementation and deployment.
In order for Sharded data to actually be usable by Rollups, Rollups will need to be able to prove it. Proofs) into the shard data. There are two options:
1. Increase & have spent BEACONBLOCKROOT Operation code; Rollups will add code to verify merkle proofs rooted in the block roots of the historical beacon chain. (Merkle proofs);
2. Add future-oriented state and history access precompilation so that Rollups don't need to change their code when commitment schemes change in the future.
This will make every slot Rollup data space increased to about 2 MB (Each fragment is 250 kB * 4 fragments, plus the calldata expanded in Step 1 above).
Step 3: N fragments, protected by the committee & NBSP;
Increase the number of active shards from 4 to 64. At this point the shard data will enter the sub-network, so the P2P layer must be strong enough by then to make it feasible to split it into a larger number of sub-networks. The security of data availability will be based on the assumption that most (verifiers) are honest and will depend on the security of the committee.
This will make every slot Rollup data space increased to about 16 MB (each fragment is 250 kB * 64 fragments); We assume that the Rollups will have migrated from the Ethereum execution chain at this point.
Step 4: Data availability sampling (DAS)& NBSP;
Add data availability sampling & NBSP; (DAS) to ensure a higher level of security, so that users can be protected even from most dishonest attacks. Data availability sampling can be done in stages: first, in a non-binding manner to allow the network to test it, and then as a prerequisite for receiving beacon blocks, perhaps even on some clients first.
Once data availability sampling is fully introduced, sharding is rolled out.
Optimistic Rollups and ZK Rollups& NBSP based on fragmentation;
One major difference between current Ethereum and post-sharding Ethereum is that in a sharding world, Rollup data can't actually be part of a transaction that submits a Rollup block to a smart contract. Instead, the publication of Rollup data and the submission of Rollup blocks will have to be separate: first, the publication will put the data on the chain (that is, in the shard chain), and then the submission will submit the block header and a proof to the underlying data.
Optimism and Arbitrum already use a two-step design for submission of the Rollup block, so this would be a small code change for both.
For ZK Rollups, things are a little trickier because submitting a transaction requires a proof of working directly on the data. They can be passed. ZK-SNARK To prove that the data in the shard matches the promise on the beacon chain, but this operation is very expensive. Fortunately, there are cheaper alternatives.
If the ZK-SNARK is a BLS12-381 based & NBSP; PLONK showed that they could simply package the shard data promise directly as input. Bls12-381 Sharding data commitment is a KZG commitment, and PLONK Is of the same type and can therefore be passed directly into the proof as common input.
If zK-SNARK uses a different mechanism (or even blS12-381 PLONK with a larger trust setting), then it can include its own data commitments, And a proof of equivalence is used to verify that the commitment in the proof and the commitment in the beacon chain is the commitment to the same data.
In a sharding world, who will store historical data?
A necessary condition for increasing data space is to remove the attribute that the Ethereum core protocol is responsible for permanently maintaining all agreed upon data. Because there's so much data. Such as:
· IP-4488 theoretically brings a maximum chain size of approximately 1,262,861 bytes of slot per 12 seconds, which is approximately 3.0 TB per year, but in practice is more likely to be approximately 250-1000 GB per year, especially at the beginning.
· 4 shards (1 MB for each slot) add an additional approximately 2.5 TB per year.
· 64 shards (16 MB per slot) will result in a total of about 40 TB of storage per year.
Most users have hard drives between 256 GB and 2 TB in size, with 1 TB seeming to be the middle number. Here are the results of an internal survey conducted among a group of blockchain researchers on the size of a computer's hard drive:
This means that the user can currently run a node, but if any part of the roadmap is implemented without modification, the user will not be able to run the node. Larger drives are available, of course, but users will have to struggle to buy them, which greatly increases the complexity of running nodes. The main current solution is Ip-4444, this proposal eliminates the responsibility of node operators to store blocks or receipts that are more than 1 year old. In the case of sharding, this one-year duration will most likely be reduced further, and nodes will only be responsible for sharding on the subnetworks in which they actively participate.
This raises the question: if the Ethereum core protocol doesn't store this data, who will?
First, it's important to remember that even with sharding, the amount of data is not that large. Yes, 40 TERabytes per year is indeed beyond the capabilities of individuals running "default" consumer hardware (in fact, even 1 terabyte per year is still true). However, for someone willing to invest some resources and figure out a way to store this data, it's within their comfort zone. A 48-TERabyte HDD (hard disk drive) currently costs $1,729, and a 14-terabyte one costs about $420. Someone running a slot of 32 ETH verifier might be willing to pay and store the entire chain after sharding is implemented for the pledge reward. So, in practice, it seems impossible that "no one will store some historical data for a shard so that it is completely lost."
So who will store this data? Some of my thoughts: & NBSP;
· Individual and institutional volunteers;
· Block browsers (Etherchain.org, EtherScan. IO, Amberdata. IO, etc.) will definitely store all data because providing data to users is their business model.
· Rollup DAOs specifies and pays participants to store and provide historical data related to their Rollup.
· Historical data can be uploaded and shared torrents.
· Clients can voluntarily store 0.05% of the blockchain's historical data randomly (using erasure codes so that only a small piece of data is lost when many clients are offline at the same time).
· Portal Network The client can randomly store a portion of the blockchain history data, and the Portal Network automatically directs the data request to the node that stores the data.
· The storage of historical data can be incentivized in the protocol.
Like, & have spent The Graph Such agreements could create incentive markets in which clients pay servers for access to historical data and Merkel-proof proofs of its correctness. This gives people and organizations an incentive to run servers that store historical data and make it available on demand.
Some of these solutions (individual and institutional volunteers, block browsers) are already available. The current P2P seed scenario is a great example of an ecosystem driven primarily by volunteers and storing vast amounts of content. Other protocol-based solutions are more powerful because they provide incentives, but they can take longer to develop. In the long run, access to historical data through these L2 protocols is likely to be more efficient than through the current Ethereum protocol.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
