Original source:Tweets by @protolambda
Original Author: Protolambda
From "Block" to "Blob", the meaning is profound.
Executable "shard chains" with "crosslinks" are out: EVM implementation in beacon chain; rollup-centric Ethereum roadmap using "data availability sampling", scaling Ethereum base layer without Increase the complexity of the application environment. But how do you invoke shard content without block metadata?
Well, this is where "blobs" come in handy. "Blobspace" is a nice name!
Let me share some history of Ethereum sharding design:
Sharding (or "Phase 1") was supposed to launch in "Phase 2" (the Beacon Chain Execution Environment) as previously planned. But before "phase 0" (beacon chain launch), it becomes clear that the mainnet EVM has priority, while the rollout of "phase 2" execution layer (ewasm?) is nowhere in sight.
The "Phase 1" specification has been rewritten several times before the Beacon Chain:
Fewer shards (1024 -> 64)
Ride free with ideal cross-shard communication (crosslinks)
New escrow proof design (remove the escrow part in favor of rare intentional proof loss)
Not to mention the earlier sharding research work, to be honest, those researches are very abstract and ambitious: cross-domain message passing, execution environment with ewasm, stateless dynamic access, sharding committees, etc. L1 gets more complicated. And L1 has begun to ossify.
However, if L1 is only focused on solving data problems, then most of the problems mentioned above translate into L2 development problems. And sampling (sampling) just solves the L1 data problem. What if we could support additional functionality at the network layer...?
So on October 14, 2020, the developers had a conference call regarding "Phase 1 network connectivity issues (networking)". After discussion, it can be concluded: gossipsub is very hot + DHTs seem to be slow. But at the time, it was early days - every web developer was still busy preparing for the beacon chain launch (December 1st!), and due to the latest developments at the time, there was an obvious gap in the network layer. biased.
The bias at the time:
Gossipsub = hot, mainnet ready (not much problem except for some DoS issues. And these issues were also discovered/disclosed before mainnet launch)
Discv5 = incomplete, needs live network migration from 5.0 -> 5.1 before mainnet launch
(https://github.com/protolambda/discv5-catdog)
But the direction seems clear: reduce L1 complexity, the beacon chain is already complex enough. Improve scalability only through data, use the "data availability sampling" scheme in the long run, and embrace L2 expansion solutions. Therefore, Vitalik described it as "Ethereum Roadmap Centered on Rollup" (Chinese version).
However, while implementers were busy with the release of the beacon chain, researchers were already busy with post-launch work: Vitalik/Dankrad was working on some early data availability design drafts, trying to make the principles easier for implementers to understand.
At the same time, we launched Zinken, Toledo, and Pyrmont testnets + check more launch items (check for bugs, etc.). And we try to keep up with the research and start adding design documentation for things on the network layer. At the time, it was too early to focus on these issues, but DAS (Data Availability Sampling) was too good to ignore.
Based on some stuff from gossipsub, I did write some ideas to use it for DAS. In hindsight, I now think DHTs are a better fit for DAS than Gossipsub, except perhaps for initial distribution.
At the time I expected some DAS specifications to be implemented and simulated. I think this is the first time "blob" is mentioned? We did use it in contexts like "sharded data blobs", and that term didn't appear in the spec for sharding back then.
After the beacon chain was released, I had more time, and then I wrote a draft that added more typing and network layer content to the sampling specification draft written by Vitalik and Dankrad. Bring blob naming into the specification of shards :)
Some things changed in 2021: the ideal p2p structure designed for it was too complicated, so I instead tried contributing tools to it (go-kzg) and participating in early merge efforts (rayonism). Then try again in the summer to join the research work on sharding instead of working on the development of the Altair/London upgrade.
Blobs are at it again, this time with a more PBS-like structure - aggregating the BLS signatures of the blob-builder and blob-proposer. Still too complex: thus, the sharding design evolved to be primarily "beacon proposer-centric", such that it is "only" a network-layer problem.
This is like a fifth design for sharding in a way? Minimalism is about giving up a lot, but the result is beautiful and powerful: more modular design, packaging, and optional complexity. Rollup caught my attention, especially Optimism.
End of 2022, EIP 4488 (not to be confused, not 4844!) and 4490: People are starting to get impatient, and the cost of calldata must come down fast to stay competitive! Discussions on these topics also became lively at All Core devs after the upgrade in London. But this is unsustainable in my opinion because calldata comes with legacy overhead that L2 doesn't need.
Meanwhile, Vitalik and Dankrad continue to work on some new sharding designs: more beacon chain-centric, scaling only through data, and focusing on sampling schemes. I think "danksharding" really came out late 21/early 22? Not sure what the first version was, Dankrad has been working on sharding.
At the beginning of 22, Vitalik proposed two ways that we can develop towards full darksharding without using sampling: a simple version and a complex version. Although in my opinion, this is actually the difference between "heavy EL (execution layer)" and "separation of EL and CL for easier and future compatibility".
I like the second option, and then during EthDenver 2022 we implemented EIP-4844: me and @lightclients working on Geth; @asn_d6 helping with KZG; @adietrichs working on fee markets; and both with Vitalik/Dankrad Draft an EIP. The Prysm team built the first CL prototype.
4844 is now named"proto-danksharding": A prerequisite for achieving complete sharding. But "blobspace" is the real meme: after many design iterations of sharding, this is a version that comes closer to Ethereum's vision than any other sharding design.
For me, this stage of Serenity is all about PoS and shard design and iterative updates. We've made some progress on the beacon chain and developments like off-protocol PBS, giving us a good start on PoS. I think it's time for the first shard upgrade: 4844!
There are also some hotspots for future darksharding:
The impact of L1 data inclusion latency on L2 is overestimated.
The design space tradeoff is worthwhile for more bandwidth for data availability.
Gossip and TCP DHTs are bad, UDP DHT class coverage is good: it's all about counting light nodes (when does discv5 scale out?)
More hotspots of danksharding:
Sampling relies heavily on good peers, would like to see more score-first but robust designs.
Prefer lightweight communication and more Sybil than lack of validator privacy over p2p.
ZK can become the future p2p anti-witch technology, but it seems to be far away now.
