Alright, I’m compelled to do this. I don’t have much time, so this will be an oversimplified introduction to danksharding (featuring PBS + crLists).
Danksharding turns Ethereum into a unified settlement and data availability layer.
Neither settlement, nor data availability sampling, are new concepts. What is brilliant is unifying them, so to rollups it appears as one grand whole. All rollup proofs and data confirm in the same beacon block.
We know how rollups work — it’s all about computation and data compression. Rollups need space to dump this compressed data, and danksharding offers massive space — to the tune of millions of TPS across rollups long term. By that I mean real TPS, not Solana TPS. (PS: Of course, TPS is a pointless metric anyway. But once again, remember, one single rollup will necessarily have higher TPS potential than Solana. And there can be hundreds of them. I bet someone forks Solana and deploys it as a rollup, and it is far superior than Solana in every respect.)
Builders are a new role which aggregates all Ethereum L1 transactions as well as raw data from rollups. There can be many builders, of course, but it still posed some censorship risks. What if all builders choose to censor certain transactions? With crList, block proposers can force builders to include transactions.
There are many fascinating possibilities that may be enabled by danksharding. Please note that these are totally my semi-informed speculation, I’m not a blockchain researcher or an engineer, and could be talking out of my arse:
- You can have synchronous calls between ZKRs and Ethereum L1 — as they confirm in the same block. You can see how this can be interesting for stuff like dAMM!
- Opens the possibility for upgrading the current Ethereum execution layer to an enshrined rollup. First as an optimistic rollup with statelessness and fraud proofs, eventually as an enshrined zk rollup with zkEVM.
- With crLists, you could potentially have immediate pre-confirmations for L1 transactions. (No more waiting for blocks to confirm!)
- So, considering all of the above, you get to showerthink about the various new possibilities that you hadn’t considered before. Here’s one that’s out there: could this open the possibility of cross-rollup atomic composability between multiple ZKRs?! This is certainly possible between multiple chains in the same ZKR network (e.g. StarkNet L3s) — but what about between a StarkNet L3 and a zkSync L2? Could crList pre-confirmations allow ZKRs to chain transactions on top of each other, all confirming within the same block?
- PBS + crList feels like a natural way to decentralize sequencing for rollups. Just have a lead sequencer, have attesters to force the lead sequencer to include transactions, if the lead sequencer goes offline attester can double up as the lead sequencer. Could be bolstered by having a reserve sequencer track where anyone can participate.
- There are the MEV implications, which I’ll leave to MEV experts.
To be clear, there’s a lot of work to be done, but I feel this is genuinely the most exciting thing to have happened in the blockchain protocols since I learned about rollups and data availability sampling.
Learn more about it here:
WIP implementation of Danksharding by dankrad · Pull Request #2792 · ethereum/consensus-specs (github.com)
PBS censorship-resistance alternatives — HackMD (ethereum.org)
New sharding design with tight beacon and shard block integration — HackMD (ethereum.org)
PS: How is danksampling for an alternate name? Just to separate it from “sharding” as too many people still think it means “multiple parallel chains execution transactions”.
