Thread by @mt_1466

1/ 🧵
How and why "data availability (DA)" became the sexiest topic in #Ethereum land, the #l222 space, and for #rollups

2/ Pre-2021 (roughly speaking), DA for most #blockchains wasn't a concern for 2 reasons:
1) most blockchains did not have enough usage to warrant any concern
2) the monolithic approach meant that each (full) node downloaded the entire block to check for availability no problemo

3/ However, this approach has its limitations/drawbacks, and, thus, new solutions like light clients, rollups (RUs), and the modular approach were implemented.
@BanklessHQ @TrustlessState @RyanSAdams

4/ As a reminder, full nodes download and validate every transaction that has ever occurred on the chain since its genesis. Light nodes (typically) only check block headers. This means light clients are “light weight” nodes that require less computing resources than a full node.

5/ This makes them more egalitarian bc they are cheaper/easier to run, further decentralizing the L1.
However, bc light nodes follow what the majority commits to as a valid tx (vs verifying for itself), light nodes must have a way to ensure that valid blocks are being published

6/ Data availability is critical in this regard because as long as all the execution data is made available on the mainnet, the chain does not require every node to execute every transaction in order to validate transactions and reach consensus.
@pseudotheos @RyanBerckmans

7/ Because rollups can cryptographically guarantee (via a proof) that the transactions are valid, these transactions can now be executed by just a single node and posted to the L1 where it can be cross-checked by L1 nodes.
@GuthL @0xEther @EliBenSasson

8/ All L1 nodes download the rollup’s data but only a certain portion of them execute the transactions/construct the rollup state, thereby reducing overall resource consumption.

9/ Additionally, the data within a batch is highly compressed prior to being submitted to the L1, further decreasing the resource burden. This is how rollups help trustlessly scale a blockchain without requiring an increase in node resources.
@prateek_jain321 @Swagtimus

10/ However, a RU's #TPS is dependent on the data capacity of their L1 for throughput. The more data capacity on L1, the higher the (theoretical) throughput for RUs. Once an L1 runs out of data capacity for the RU, the limit has been reached and no additional txs can be processed

11/ Therefore, now the limiting factor for a blockchain’s scalability is its data availability.

This is huge! Make more space, get more scalability!

12/ To address this issue, new specialized DA chains have launched/are being built. These chains are built to serve solely as a DA/shared security layer for RUs by maximizing the DA capacity. Examples such as @CelestiaOrg and @0xPolygon Avail only provide high data capacity.

13/ In summary, DA is extremely impt for new #modular chains for 2 reasons:
- adequate DA is required to ensure a RU sequencer’s submissions can be cross-checked & challenged
- DA is now the bottleneck for scalability. Maximizing DA on L1 is critical for a RU's full potential.

14/
*Bonus content* Data Availability Sampling (#DAS)

Currently, RUs need to download an entire block to verify DA. This is resource-intensive.

Therefore, Data Availability Sampling (DAS) has been proposed as a solution.
@epolynya @VitalikButerin

15/ DAS is a way to verify availability on L1 without downloading an entire block (merkle roots used to find what/where to sample).
This is more efficient bc it enables nodes to download only a portion of a block of data on the L1 & still have (essentially) the same guarantees.

16/ #Ethereum plans to tackle this through data #sharding after the #MERGE. This means not all validators will download the same transaction data as every node currently does.

17/ With DAS, rather than all network nodes downloading all of the data from every shard, each node only downloads a fraction because there are assurances that a minority of nodes can come together to reconstruct all shard chain blocks if needed.
@odin_free @j0hnwang

18/ This is essentially a shared security model across the network shards where any individual shard node can raise a dispute to be resolved by all nodes on-demand, similar to the @NEARProtocol implementation.
@jadler0 @AlexSkidanov @ilblackdragon

#Sharding will significantly increase the on-chain data capacity & help create room for even more and even cheaper rollups. A rollup’s TPS and fees are no longer restricted by the data capacity of a single shard but, now, in the case of Ethereum, 4-64 shards in the near future.

20/ The #Surge, a step on the Ethereum roadmap, consists of multiple upgrades that are designed to improve RUs like #EIP-4488 or #blob transactions. These will reduce transaction fees by ~5x or more.
@HenriLieutaud @litocoen @Darrenlautf

21/ This then leads to #danksharding - a data layer built specifically to accelerate RUs. This integrates DAS, meaning the more decentralized the L1, the more capacity there is for RUs. As bandwidth improves & #ETH decentralizes, capacity will continue to increase to 1M+ TPS.

22/ Fin.
I cover all this plus most rollup implementations, their pros/cons, sidechains, scaling, Merge, sharding, PoW vs PoS, modular vs monolithic architecture, bridges, and more with resources and links here

drive.google.com/file/d/14QJuTi…

@bitsplaining @cyber_hokie @QwQiao @RyanWatkins_ @LefterisJP @Route2FI @hasufl @spencernoon