Will Danksharding, the killer feature of expansion, be the future of Ethereum sharding?
By Gokhan Er, IOSG Ventures
finale"finale"The picture has been widely discussed, and we roughly distilled this grand roadmap into the following three points:
Centralized Block Producer
Trustless and decentralized block verification
Anti-censorship mechanisms that remove the incentive for these block producers to censor transactions.
image description
(Image source: https://vitalik.ca/)
Vitalik even goes a step further and believes that today's "big block" type blockchains (such as Solana, BCH, etc.) need to follow a similar architecture if they want to achieve decentralization, avoid censorship, and achieve expansion at the same time. Considering the network effect that rollups or cross-domain MEV can bring,The centralization of block producers is largely unavoidable, so accepting this fact and making adjustments at the protocol level to ensure that block producers do not interfere with the security and censorship resistance of layer1 should be our best best optionsecondary title
PBS: Separation of block proposers and builders
If centralized block production has become an unavoidable reality, the most feasible solution to prevent further centralization is to separate block production from block validation (proposals).
We know that in the current architecture, generally only one party is doing block production work (miners), and they will directly choose which transactions they undertake from the memory pool Mempool, and create blocks by undertaking these transactions. In addition, the more complex the tasks of these miners, the more value they can extract, which in turn leads to the centralization of miners.
In the design of PBS, the role of the builder is separately distinguished. They will select transactions from the mempool and order them with the goal of maximizing profit. Once they create a list of transactions they want to undertake, they submit their bids to validators (block proposers). In this case, the validator (block proposer) task is to choose the highest bidder to create the block. The block proposer just collects transactions from the mempool and creates a crList, which is simply a list containing block transaction information. The block proposer passes this crList to the block builder. Block builders reorder transactions in crList at their will to maximize their MEV extraction. therefore,Block proposers have no say when it comes to how transactions are ordered, but by providing builders with a list (crList) that includes block transaction information, they ensure that all transactions from the mempool enter the block without censorship.
It can be seen that the design of PBS is actually to establish a firewall and a market between proposers and builders. Although the work of block producers will become complex and centralized, it is critical to ensure that the requirements for running validator nodes, so that they can be run by general-purpose servers at very low cost (compared to those run by block producers for sophisticated servers). And this is achieved thanks to the PBS program.
After understanding the above content, we return to Danksharding.
What is Danksharding? Why is the whole world talking about it?image description
(Image source: Dude, What's the Danksharding situation?)
However, as the MEV problem becomes more and more intractable, separating block builders from their proposers is a big need right now. This separate structure of block creators and block proposers (PBS) is the only solution to democratize the MEV problem and prevent it from further compromising the security of the protocol.
image description
(Image source: Dude, What's the Danksharding situation?)
In this new design, the beacon block will contain all shard blocks, and all beacon blocks and shard data will be uniformly certified by a Committee composed of validators. In this way, transactions in the same beacon block can access shard data, and even obtain synchronous transactions between rollup and layer1, which greatly simplifies the structure of rollup, and problems like confirmation delays will no longer exist.So what about Danksharding’s anti-censorship situation? Can centralized block creators still censor specific transaction records by participating in the same block? The innovation of crLists can solve the problems mentioned above.It is the block proposer's job to list all transactions they have seen in the mempool. Then the block builder will extract a hash value based on this list and prove that all the data in the list are included. However, recent discussions have shown that the design of proposers and verifiers and the tooling of crList have yet to be finalized. The upgraded version of data sampling is also another important design of danksharding, which can ensure that when the beacon node provides data, it is not necessary to store all the data, so I won’t repeat it here.
Generally speaking, Danksharding still has many advantages worthy of attention:
With increasingly simple sharding design, the new model will reduce the original workload by a hundred times.
Based on the PBS model, neither complex nor advanced block creators will be a problem for the security of Ethereum. It is guaranteed that Ethereum will increase the block size without worrying about centralization.
The merging of shard data and beacon chain data will speed up the synchronization between layer1 and zk rollup, thus simplifying the structure of rollup.
crLists can ensure that L1 can achieve instant transaction verification (similar to the same concept on layer2).
MEV across shards will be democratized (like Flashbots did) and potential centralization of validators can be prevented.
Danksharding is a brand-new model proposed by the core researchers of Ethereum a month ago. The idea is still in its infancy, and there will be more innovations and optimizations in the future. However, it can be seen from this that the sharding plan of Ethereum will move forward steadily step by step. let us wait and see!
