HackMD
Notes on Danksharding
Danksharding aims to make transactions on Layer 2 as affordable as possible by creating ways for Layer 2 networks to publish data to Ethereum's Layer 1 cheaply. Proto-Danksharding is an intermediate step towards achieving Danksharding.
Increasing the volume of data that can be processed through the network is often referred to as data sharding. Another type of sharding, known as 'full sharding,' scales the network by also enhancing its execution capacity.
The original full sharding model, which involved splitting the chain into multiple segments, has been removed from the roadmap due to its complexity and the extended time it would take to implement. However, as data sharding is a necessary prerequisite for full sharding, the possibility of its future implementation has not been entirely eliminated.
Proto-Danksharding
For a rollup to be secure, it needs to send data to layer 1. Provers take that data and verify the transactions made on the rollup. There needs to be a window of opportunity for provers to verify the transactions, but it doesn't have to be forever.
Proto-Danksharding, a.k.a EIP-4844, allows rollups to send data to layer 1 in blobs, instead of calldata, making it cheaper. To not overload the nodes, the data in the blobs is deleted after 1-3 months.
Danksharding
After Proto-Danksharding, complete Danksharding is the next goal. This expands the number of blobs from 1 in Proto-Danksharding to 64. This requires various changes to the consensus clients, changes that are useful on their own, not only for Danksharding. For example, Proposer Builder Separation and Data Availability Sampling.
Proposer builder separation
Under Danksharding, the block builder will have to make an expensive computation to generate the commit mentioned previously. If the block builder and the proposer were the same validator, this could become a centralization factor because all validators would need to be entities with a lot of computing resources.
Proposing the block is a simpler, cheaper process. The proposer would only have to pick the most profitable block (that was already built by someone else) and verify the commitment. Verifying a proof/commitment is much cheaper than generating it.
As the proposer would check if the block is valid, builders would have to behave honestly if they want their blocks to be broadcasted. And since proposing can be done on inexpensive/home hardware, this would eliminate the centralization factor.
Progress
Full Danksharding is years away, but Proto-Dansharding is already being tested by the client teams.
There's a readiness checklist with the progress of all clients regarding Proto-Danksharding.
After checking the readiness checklist for Lighthouse, I see that most of the work left is fixing bugs.
