"The Beacon Chain has life." On May 11th and 12th, 2023, Ethereum faced two temporary loss of finality events that tested its resilience. Despite these challenges, the network maintained its vitality, autonomously recovering from both incidents. We're about to delve into these noteworthy events, scrutinizing their impact and the subsequent enhancements implemented to prevent similar incidents in the future.

The Incidents

May 11 and 12, 2023, will be marked as significant dates in Ethereum's history, where its resilience was put to the test. On May 11, around 20:19 UTC, Ethereum's Mainnet network witnessed a significant drop in block production, causing a four-epoch delay in finalization - a first for Ethereum. The following day, a similar incident occurred, this time stretching the delay to nine epochs and leading to an inactivity penalty.

During these incidents, a substantial dip in network participation was observed. The first drop occurred in epoch 200,551, resulting in a temporary halt in finalization until epoch 200,555. The second participation drop was seen in epoch 200,750, causing another pause in finalization until epoch 200,759.

Despite the initial concerns, Ethereum's network showcased its inherent robustness by autonomously recovering from both incidents. These events not only affirmed the resilience of Ethereum's Beacon Chain but also highlighted areas for potential enhancements. As we progress through this article, we'll explore these areas in greater detail.

Inactivity Leak

During periods of non-finality, the Ethereum network deploys a crucial mechanism called the "inactivity leak.” This feature is ingrained in Ethereum 2.0's proof-of-stake protocol, engineered to sustain network functionality amidst significant disturbances - from events like World War III to large-scale natural disasters - that could result in a sizable number of validators going offline, thereby obstructing block finalization.

In the event that the network fails to finalize blocks for four consecutive epochs (~16 minutes), it triggers the inactivity leak mode. Under this regime, validators failing to attest to blocks start to lose a part of their staked Ether (ETH). This penalty intensifies quadratically over time until block finalization resumes.

This mode wields a dual deterrent. Firstly, it negates rewards for validators' attestations. Secondly, it imposes escalating penalties on non-participating validators proportionate to the duration of their inactivity. This mechanism incentivizes validators to stay actively involved, accelerating network recovery. It is a cornerstone feature that safeguards network integrity during major disruptions.

You can read more about this in the comprehensive guide on Ethereum 2.0 incentives and mechanisms at Eth2Book here.

The Impact

For Network Participants (Validators):

As per the estimates provided by Ben Edgington, assuming an 8 epoch leak with 65% of validators offline, the inactivity leak led to approximately 28 ETH being burned. This equates to about 0.0006 ETH per offline validator.

Furthermore, during the duration of the outages, attestation rewards were reduced to zero, resulting in an additional loss of around 50 ETH that could have been otherwise issued. Taken together, the estimated total loss for the validators, in terms of both inactivity penalties and lost attestation rewards, is around 78 ETH.

For Users:

Contrarily, end users experienced minimal impact. Despite the decline in available block space leading to reduced transaction processing capacity, there was no dramatic surge in gas prices, which stayed below the daily peak. More significantly, the network maintained liveness throughout these incidents.

This meant that Ethereum continued to process transactions without any major disruptions, demonstrating its resilience. Consequently, users could maintain their operations on the Ethereum network largely uninterrupted, underscoring the robustness of the system even in the face of challenges.

The Causes

At the heart of the issue with Prysm was an absent caching mechanism for block replays. This absence escalated the system load, generated excessive go routines, and heightened CPU stress. In some instances, new replays commenced even before the previous ones concluded, further straining the system.

Another compounding factor was Prysm's improper processing of attestations from previous epochs - data that should have been disregarded, but wasn't. This inefficiency, coupled with the suboptimal use of the head state, stressed the system particularly in the face of a deposit surge and a growing validator registry.

The incidents also unveiled key differences in the strategies adopted by different Ethereum clients. While Lighthouse chose to drop attestations to maintain network liveness, Prysm and Teku, among others, defaulted to generating blocks using old attestations when faced with execution client issues.

Despite the challenges, these incidents were critical in providing insights into software inefficiencies, design choices, and network conditions, making the Ethereum network more robust. This series of events has not led to any permanent damage, but rather has reinforced the resilience and versatility of Ethereum's network design.

The Recovery

The resilience of Ethereum's Beacon Chain was truly tested during these incidents, and it passed with flying colors. The Ethereum Beacon Chain seems to be alive, healing itself.

A key factor in the successful recovery was the diversity of clients on the Ethereum network. The existence of multiple clients, each with their unique ways of handling the network, proved to be a boon. For instance, while Prysm and Teku clients struggled under the load of old attestations, Lighthouse's strategy of dropping attestations ensured that part of the network stayed live and functional.

In essence, Ethereum's resilience comes from its client diversity, a factor that played a crucial role in helping the network recover on its own, thereby negating the need for any manual intervention.

Lessons Learned

• Testnet vs Mainnet: The incidents underscored the discrepancies between testnet environments and the Mainnet. With over 600,000 validators and a significant volume of withdrawal operations on the Mainnet, it's clear that the complexities and unpredictability of a live network often exceed those of test environments. This signals the need for more rigorous stress testing to better prepare for real-world network conditions.

• Inactivity Leak Penalties: The effectiveness of inactivity leak penalties on the Mainnet was reinforced during the incidents. These penalties play an essential role in promoting active validator participation, maintaining network liveness, and enabling network recovery.

• The Importance of Liveness: The incidents underscored the vital role of liveness in a blockchain network. Under the design of the LMD Ghost protocol, Ethereum maintained its liveness throughout the process, ensuring users experienced minimal impact. Unlike certain blockchains that may face downtime during network issues, Ethereum prioritizes liveness over throughput. This approach safeguards users and the proper functioning of the network, emphasizing that without liveness, network functionality and user security are compromised, regardless of throughput.

• Importance of Client Diversity: The recovery process emphasized the value of having a diverse client base. Different Ethereum clients have unique responses to network incidents, contributing to the overall resilience and robustness of the network.

• Network Resilience: The incidents served as a powerful testament to the Ethereum network's resilience. Despite significant challenges, the network self-recovered and bounced back stronger, embodying the concept of antifragility in complex systems. This resilience sets a strong precedent for the broader crypto ecosystem and signifies the robustness of Ethereum's underlying architecture and design principles.

The incidents on May 11 and 12, 2023, served as pivotal moments in Ethereum's journey. They provided tangible proof of the Beacon chain's vitality, even amidst challenging circumstances. As Ethereum continues to evolve, it builds upon these experiences, growing not only more robust but also more antifragile - ready to forge ahead in its journey of decentralization and beyond.

Have to say, the name Dankshard is cool.

In the process of scaling, there are two problems:

1. Scalable verification of computation:

   Efficiently verify the results of computations instead of re-executing them by full nodes. In the Rollup-centric Roadmap of Ethereum, roll up is responsible for using fraud proofs or ZK proofs to implement high-throughput secure transaction processing capabilities.

   Of course, there is no denying that such a system will be used in the L1 system to add "native" high-throughput execution in the future, just like what PSE and Scroll are doing now.

2. Scalable verification of data Availability:

   Efficiently verify data availability instead of downloading all data by full nodes. While ensuring consensus, L1 also needs to provide a "data availability engine" to ensure that rollup data is available, usually to ensure that Batch + State is available.

   If L1 DA cannot guarantee, it will result in:

   1. OPR: Challenge cannot be submitted (State + Batch data is invalid)

3. ZKR: Unable to get current state (State)

Scalable verification of data Availability is usually more complex, and fraud proofs cannot be used directly because it is difficult to judge who is wrong when a challenge happens - the fisherman's dilemma.

Fortunately, technologies such as DAS, Polynomial Commitments, Erasure Code, etc. can help us with scalability verification for data availability problems.

Against this background, the following solutions emerged:

Native: Danksharding

Others: Validium\zkPorter\Celestia\Polygon Avail

This article will mainly analyze Danksharding.

Danksharding - all for the future

1. Traditional Sharding and Danksharding

The Traditional Sharding design divides validators into different committees, and different committees verify different parts of data on independent subnets.

Danksharding has innovated. Unlike the previously fixed number of shards, where each block has different proposers, danksharding adopts the PBS mechanism(proposer/builder separation). Only one proposer chooses the transactions and data that enter the slot and hand them over to the block builder.

The main transaction type of Danksharding is the "blob-carrying transaction" which refers to a transaction that carries additional blob data (~125kb/blob). Compared with calldata, blobs are cheaper, and EVM executes but cannot access blobs (only commitment can be accessed).

Since the execution block and the sharding block are built together, there is no delay in shard block confirmation, and there is no need to track shard blob confirmations – making data immediately visible to L1s.

Old:

1. Data shards

2. DAS(Erasure Code + KZG Commitments)

New:

1. PBS + Crlist

2. KZG 2D scheme

2. Proto-Danksharding

Proto-danksharding (aka. EIP-4844) is a proposal to implement most of the logic and “scaffolding” (e.g transaction formats, verification rules) that make up a full Danksharding spec but not yet actually implementing any sharding. In a proto-danksharding implementation, all validators and users still have to directly validate the availability of the full data. - Vitalik Buterin

EIP-4844 will be implemented in the Shanghai hard fork.

Proto-Danksharding adds a new transaction type - "Blob Transaction"

Blobs have 128 KiB of storage space:

1. A transaction contains up to 2 blobs, i.e. 256 KiB

2. A block contains up to 16, i.e. 2 MiB; the target is 8, i.e. 1 MiB

Under Proto-Danksharding, 2.5TB of historical data will be added every year, and 40TB will be added after full sharding. The EIP-4444 proposal is essential; after the node synchronizes the blob TX, the blobs part will be deleted after a while and only the blob_versioned_hash will be retained.

Note: Data availability does not equal data retrievability. To maintain blockchain consensus, we only need to ensure data availability, and data retrievability is unnecessary. For historical data storage issues, see A step-by-step roadmap for scaling rollups with calldata expansion and sharding.

Blob data no longer occupies data storage permanently, and "cache space" is usually cheaper. Based on this, the multi-dimension gas market (EIP-1559) is created. The transaction fees will be determined by both Gas and Blob.

Proto-danksharding (does a lot of work for full sharding) vs. Full Danksharding. All remaining work is consensus layer changes that don't require any additional work by client teams, users, or rollup developers.

This is why I wrote "all for the future" in the subtitle. The underlying architecture does not require significant changes regardless of the subsequent ZK verification or PBS design upgrade.

Proto-danksharding lays an open foundation for the future of Ethereum.

3. Full Danksharding

Full Danksharding will implement PBS + Crlist + DAS.

First, the blob space has increased: Max 2 MiB, Target 1 MiB → Max 32 MiB, Target 16 MiB.

The node bandwidth will be challenging to support because the data becomes larger, so we use PBS + Crlist to build blocks and DAS to verify data availability.

Step by step in depth.

PBS + Crlist - Reduce block builder bandwidth

In Danksharding, the bandwidth requirements for building blocks are relatively high. Firstly, you need to download 32MB of blob TX, and secondly, you need to broadcast blocks for validators to sample.

The core idea of PBS is to separate Builder and Proposer:

Proposers = Validators

1. Select transaction list, create and broadcast Block Header.

2. Honest majority assumption. With a small amount of data and low bandwidth requirements. Ideally, the validator can be completely stateless.

Builders = Separate role

1. Create and broadcast a list of transactions i.e. Block Body

2. Honest minority assumption. With a large amount of data and high bandwidth requirements. More centralized

The resource-intensive work is left to the Builders to complete and make the MEV more democratic. For decentralization, we implement a hybrid PBS design (there may be a better design in the future). The following are the steps to produce blocks:

1. Proposer publishes a crList (censorship resistance List) to Builders. The list consists of all transactions in the Proposer Mempool.

2. Each Builder selects transactions from crList, sorts and extracts MEV until the Block Gas Limit is filled, and creates an exec block body.

3. Builders publish their transaction list hash to the Proposer; the Proposer accepts the highest bid exec block body, builds it into a Block Header, and broadcasts it; the Proposer (and everyone else) does not learn the contents of any exec block body until after they select the header (and hence the body) that wins the auction.

4. The network synchronizes the block header from the Proposer and the block body from the selected Builder.

DAS - Reduce validator bandwidth

DAS is an issue that has been discussed for years. Ensuring data availability without nodes downloading all the data is key to blockchain scale.

This involves erasure coding and KZG commitment, which are common techniques in DA solutions.

Erasure coding

Specific principle:

https://twitter.com/ChrisYicheng/status/1523676986299748353

By quadrupling the original data through 2D coding, any 75% of the data can reconstruct 100% of the data. This turns the 100% data availability problem into a 75% problem.

If miners want to hide data of any size, they need to hide at least 25% of the data. Each node only needs to sample a fixed number of samples to ensure that 75% of the data is available, and then the entire block can be reconstructed.

With Erasure coding, validators can verify blocks more efficiently. However, it is also necessary to ensure that miners encode the data correctly.

KZG Commitment

The function of KZG Commitment is similar to the Merkle root. The difference between KZG Commitment is that all points are guaranteed to be on the same polynomial, and Erasure Coding can be achieved by adding Point, which is very friendly.

Note: KZG Commitment is 48 bytes, and EVM uses 32-byte values more naturally, so convert KZG Commitment to versioned hash:

All for the future, in the long term, for quantum-safety reasons, if we switch from KZG to something else (e.g. Merkle trees + STARKs), roll up will not require EVM-level changes; just switch the sequencers to the new Transaction Type.

At the same time, add a new OPcode OPcode GET_VERSIONED_HASH_OPCODE, which is input as a stack argument index.If index < len(tx.header.blob_versioned_hashes returns tx.header.blob_versioned_hashes[index], otherwise returns 0.

Generating ZKG Proofs is very time-consuming. If correct, it takes 100s to generate KZG Proofs for 32MB Data, and if it takes 1s to complete, it takes 100 Codecores. Currently, the Ethereum team is investigating CPU implementation.

Research to validate acceleration is also underway: Optimizing EIP-4844 transaction validation (using KZG proofs) #5088

Now the execution client can only access the blob versioned hash but not the blob data at execution time, which is an exciting innovation.

Polygon Avail also uses KZG Commitment, and Celestia uses Merkel tree + fraud-proof verification.

There will be a trade-off between cost and time rate here, but I'm personally optimistic about the mass adoption of Proof-of-Validity in DA in the long term. There may also have some upgrades in the future of Celestia.

💡 The DAS-based design is still being optimized, and you can submit your ideas here: requests-for-proposals

Learn more about DAS and Erasure code:

Learn more about DA and Erasure code

Lazy Validator Problem

This is an open question. If a node just signs the proof of all shard blobs without actually downloading the data, it will still receive rewards and save storage and bandwidth costs, requiring some penalty mechanisms. But how to balance the relationship between decentralization and node sampling still needs further improvement.

4. Roll up and Danksharding

Danksharding added two precompiles: Blob verification precompile and Point evaluation precompile.

It is simple for OPR; just use the blob verification function and the previously submitted Versioned hash for fraud proof verification at the time of fraud proof.

It will be tricky for ZKR because a submission transaction needs to provide a proof that operates directly over the data. Using ZK-SNARKs to prove that the data in the shard matches the commitment on the beacon chain would be very expensive.

A more ingenious solution is commitment proof of equivalence protocol; the principle is straightforward. Use point evaluation precompile to prove that KZG commitment and ZK rollup's own commitment point to the same data.

This is what Danksharding is all about, Danksharding is not just an optimization of sharding, but innovation, and countless "adjacent possibilities" will be opened.

5. The future of Modular

The design of Roll up and sharding makes the monolithic blockchain gradually obsolete. Modular architecture has become more mainstream. We solve the scale problem of the blockchain by modularizing the consensus layer, DA layer, and execution layer.

I like this article from Polynya: Processors & blockchains: modular is revolutionary.

The modular stack opens up the imagination of blockchain design. There are also many new solutions for DA.

For example, Celestia is similar to an open modular component; any chain can use it to ensure DA; Celestia has its nodes and consensus, but does not process transactions, only ensures data availability through data availability sampling. (Celestia's article will be published recently)

Roll up can use Ethereum as settlement layer and Celestia as DA layer, publish TXdata to Celestia instead of Ethereum. Celestia will return the verification result through the DA bridge contract on L1.

Many new components can also be created based on Celestia, such as Sovereign Rollup and Settlement Rollup. Celestia will become a plug-and-play open component (not only in the Ethereum ecosystem).

Many other solutions have also appeared in L2, such as Validium, zkPorter, Polygon Avail, and the Permissionless DAC that Starkware is researching. How to safely coordinate these solutions in a system is now being tried and broken.

I think Ethereum will be the best choice for settlement and DA in the long term. It provides a highly decentralized base layer on which any project can be built, including centralized-production systems. With the development of Volitions, different data solutions will emerge. The choice of future DA solutions will be handed over to users, and users can choose the data solutions they need by themselves - modularization will bring infinite possibilities.

The monolithic blockchain narrative is fading, and Modular Blockchain will be the future.

Record learning, welcome to DM🍻

https://twitter.com/ChrisYicheng

If you want to see the current Calldata size situation, my friend made this dashboard on dune:

https://dune.com/luozhu/zk-Rollup-by-Luozhu

I was drawn to the concept of Celestia when I first saw it. I thought it would bring about a massive paradigm shift. The multi-chain ecosystem became incredibly clear.

What appeals to me most is that Celestia will bring permissionless innovation, which is a very open component. From the evolution of biology to the development of science and technology, there will always be some open components and some building blocks in a system, which increase the network's connection and support the network to burst out more complex innovations. Celestia is such a component that it will promote the further explosion of innovations and components, like a positive feedback loop, to promote the more prosperous and more complex evolution of the entire blockchain system.

1. What is Celestia

Celestia is the first modular blockchain network. Unlike traditional monolithic blockchains, it does not execute any transactions; it only provides a consensus data network.

It provides a particular execution environment - Data Availability (DA) service. By separating the DA layer, the consensus and execution layers are decoupled - the blockchain becomes more modular.

Before everything starts, we first need to understand a few concepts.

2. Consensus and Execution

Blockchain is essentially a distributed network that runs State Machine Replication (SMR). SMR has three primary stages: data, consensus, and execution; the blockchain is also divided into these three layers. The key to creating currency on the Internet is to introduce a consensus system that cannot be interfered with by outsiders. The solution proposed by Satoshi is to introduce the "Nakamoto Consensus" so that people worldwide can maintain and operate Bitcoin.

Here's how Bitcoin's consensus protocol works:

• Bitcoin nodes receive transactions from peers.

• Nodes verify signatures and check transactions against consensus rules.

• If validity fails, the node rejects the transactions. If the verification passes, add them to the memory pool.

• Miners then create candidate blocks and populate them with transactions from the mempool.

• Under the POW mechanism, some miner eventually finds a valid nonce for their candidate block.

• Broadcast, the nodes check the block's validity and extend the chain by building this new block.

During this process, the nodes perform various tasks:

1. Data Availability (DA) — Nodes receive every transaction in the network, store it locally, and ensure that those transactions are available to any other node that may request it.

2. Execution — Nodes will check the validity of a new transaction against the protocol rules after receiving it. Also, they will execute them sequentially in a block to compute the new network state.

3. Consensus — Nodes will jointly agree on which transactions will be included in the new block and the chronological order in which they will be stacked (Transaction ordering). Nodes then attest to the block by imposing some economic weight on the integrity of the block.

A modular blockchain is a blockchain that separates the DA layer, the execution layer, and the consensus layer. Celestia acts as the DA layer to verify the integrity of the data. For validators, this occurs during consensus. For non-consensus nodes, this happens when blocks pass consensus and are propagated throughout the network.

In a monolithic blockchain, these three layers of work are all done by a network, from data verification to transaction execution are all done by network nodes. Since the blockchain is a distributed globally Replicated State Machine, the more complex we push execution onto this global state machine, the higher the cost and complexity for the system to maintain synchronization.

Roll-up solves part of the problem, separating the execution layer to handle complex transactions, and they use Ethereum as their DA and consensus layers. Publishing data (by "calldata") on ETH L1 is much cheaper than executing on L1, but it's still essentially competing for the highly scarce block space on L1, so it's still going to cost a lot.

Two problems will result:

1. The cost of "call data" is fixed, at least for now; no matter how powerful L2 performance is, the cost of L1 call data (16 Gas / Byte) cannot be changed, which is why the current Roll-up cost is still very high s reason.

2. L1 is limited by resource pricing. As long as the block space is written on L1, the gas cost problem will continuously attack users.

We can solve this problem with Celestia, Celestia can provide DA, and finally return the verification result to Ethereum (of course, this is only one of the use cases of Celestia, which will be described in Section 7).

3. The dilemma of Scaling

There are usually two aspects to blockchain scaling: Scalable verification of computation and Scalable verification of data Availability. In simple terms, it refers to increasing the number of transactions processed without increasing the cost of verification.

Nodes essentially limit how many transactions and gas fees the blockchain can process per second. Since the hardware's processing power is limited, we can almost estimate the computing power of the public chain.

This is true of all blockchain networks (except Solana). When demand exceeds supply, transaction fees go up. Blockchain can only guarantee storage and computation, not cheap transaction fees, which can skyrocket once network capacity is hit. Solana doesn't get into this issue because it doesn't care about the cost of running a full node, supply is always greater than demand, and of course, something is sacrificed.

Bitcoin averages 4 megabytes per block, and the reason why the block cannot be expanded is that the block expands -> the threshold for full nodes increases -> the number of full nodes in the network decreases, and the number of light nodes increases -> the network security cannot be guaranteed, and it becomes more centralized.

Satoshi Nakamoto proposed the concept of SPV when designing Bitcoin. That is, the network can be used without running a full node. The light node only downloads the data of the block header and not all the data. The execution of the transaction is run by the download code of the full node, and the integrity of the data is verified at the same time.

Reducing full nodes weakens decentralization because light nodes have an honest majority assumption. By default, light nodes believe that the transaction behind the block is valid.

Resisting data withholding attacks is the main security gap between light and full nodes.

Data Withholding Attacks:

When miners produce a block, they hash the formatted TX data. These hash digests are grouped into pairs, and the resulting hashes are hashed until compiled into a single root, called a Merkle root. By Merkel root, we prove the integrity of the hashed data structure.

There is a problem here: due to the nature of the hash function (Trapdoor Function), using only Merkle roots, we cannot unroll the sequence to access all TXs. We can only check if the structure is complete. The light node is the node that only downloads block headers and does not download all transactions.

By default, Light nodes trust other full nodes in the network that the transactions behind these Merkel roots are available and valid. As a result, light nodes may fork unknowingly with honest full nodes if the block header is invalid (such as being misled by malicious nodes).

Verifying that data is in a block is easy. Proving that data is not in a block is difficult. Therefore, DA is guaranteed by the full node downloading all data. Because full nodes do not assume that the consensus is honest (light nodes have this assumption and only download block headers), malicious consensus can never deceive full nodes into accepting invalid blocks.

However, to ensure the decentralization of the blockchain, we cannot raise the operating threshold of full nodes, and in current blockchain networks, a marginal increase in nodes will not contribute to the scalability of the system and will actually make producing blocks more expensive.

This is the blockchain trilemma, which can be well solved by modularizing the monolithic architecture.

4. Celestia - Data Availability Sampling Light Node

Recommended reading: Principles of Sampling

Celestia is designed to provide consensus and data availability without executing any transactions, unlike most other blockchains. Likewise, Celestia light nodes do not verify transactions (whether this transaction can be executed or not). They only check each block for consensus and whether the block data is available to the network.

Data Availability Sampling (DAS) is a cryptographic technique that solves the above challenges by allowing light nodes to generate security properties close to full nodes without downloading the entire block.

While research into DA sampling has been going on for several years, Celestia is the first blockchain to implement it directly into the protocol.

Briefly explain:

DAS mainly applies erasure coding technology. Using erasure coding to data is a method of expanding data. That is, all data can be reconstructed by having a small part of the data.

One use case for erasure codes is in CD-ROMs. If the disc is scratched and the original data is damaged, we can use erasure coding to recover the entire data.

Celestia applies erasure coding to blocks, allowing light nodes to randomly sample pieces of data belonging to a block, probabilistically guaranteeing that other pieces of data are available. The number of nodes participating in the sampling process is vital for this probabilistic guarantee. Block producers propagate the headers to the network. According to the data routing belonging to the header, each light node requests a random piece of data. If all samples are available, this can prove that the entire block is available. By sampling random data from a block, it can be probabilistically verified that the block is complete.

Celestia can verify that 100% of the data is available by sampling 75% of the data in the block. As long as there are enough light nodes to ensure that the probability threshold is 99.9999%, each node only needs to extract 16 TXs to verify the integrity of the data (the specific principle). This reduces the amount of data a single node needs by a square root.

Due to the nature of Celestia nodes that do not execute transactions, transactions posted to Celestia will never pay high transaction fees to compete for computing power like other blockchains. Furthermore, since nodes do not perform dual roles as in monolithic L1, they do not require high-performance processors, and a light client such as a mobile phone can complete a sample verification of 16 TXs. This enables light nodes and honest full nodes to follow the same chain, maximizing the functionality of light node verification.

As mentioned above, in traditional blockchains, the marginal increase of nodes will not contribute to the system's scalability and will increase the cost of block production; not so with Celestia. The key to DAS is that the more data you sample, the more data available you can determine.

In Celestia, it is safe to increase the block size (which can provide higher TPS) as the number of nodes participating in the data sampling increases.

5. The Birth of Great Ideas

The idea of Celestia can be traced back to a white paper written by Satoshi, in which Satoshi mentioned that light nodes could become more secure if full nodes send an "alert" to light nodes when they find the invalid block.

“One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency” — Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System.

Vitalik also came up with this concept in his early years when he designed Plasma. The original Plasma paper described a mechanism to build a "blockchain tree". Each node in the tree will represent a unique blockchain connected to its parent node, all of which are arranged in a hierarchy of chains with the Data Availability Layer (DA) at its core.

By: The Celestia Thesis - Rain and Coffee

Great ideas are always built on "adjacent possibilities", and Celestia finally did it.

6. Cost

Recommended reading: Ethereum Rollup Call Data Pricing Analysis

L2 costs are divided into two parts:

Fixed cost:

• Proof cost (in case of zk rollups) = ranges in gas, typically based on rollup provider

• State Write cost = 20,000 gas

• Ethereum Base transaction cost = 21,000

Variable costs:

• Call Data: 16 gas per byte of data. (Roll up collects data from multiple transactions into a batch transaction published to Ethereum. The batch transaction includes the aggregated transaction data as calldata, i.e. data that is published to Ethereum but not executed directly)

• L2 Gas: Usually quite cheap.

The current limitation on L2 is the Call Data cost, which is the lingering 16 gas/byte.

Here is a data dashboard for rollup Call Data:

https://dune.com/luozhu/zk-Rollup-by-Luozhu

Ethereum is also solving this problem:

EIP - 4488: Reduce gas fee from 16 per byte to 3 gas per byte

EIP - 4844: Shard Blob Transaction reduces Call Data fee by changing L2 call data mode

I am very optimistic about Danksharding. Celestia is diversified, and it is not a zero-sum game with Ethereum. I think Celestia will be the most secure and efficient Validium solution.

I don't know what the end is like, I can only imagine all the possibilities as I can, and finally, I tell myself: I have no reason not to embrace this new thing because Celestia will bring more possibilities of innovation and combination.

7. Possible combinations

Peter's tweet inspired me.

Celestia centric:

• Sovereign Rollup: Built on Celestia, it has its P2P network for OPR or ZKR. There is no need to publish proofs and data to the L1 contract but to verify in an independent P2P network. The requirements for the ecological expansion and developer experience are high.

• Settlement Rollup: Roll up built on the settlement layer. Cevmos is a good settlement layer, which can be well compatible with the Ethereum ecosystem. Modular settlement is usually limited to only running the roll up environment of the execution layer to prevent other computing from competing for space.

• Celestium: Through the quantum gravity bridge, Celestia will serve as a DA off-chain solution for Ethereum roll-up, providing data availability for rollups on Ethereum, which is currently the safest low-cost Ethereum Validium design I've seen. Roll up publishes the Batch to Celestia, and Celestia publishes the verification result to Ethereum through Quantum Gravity Bridge.

8. Advantages of Modular Innovation

1. Efficient technical iteration

If you look at the history of EIPs, many are related to execution. But the upgrade involves a unified upgrade of consensus and execution, so development is slow. In a modular blockchain, Celestia realizes the decoupling of consensus and execution, making technology upgrades more convenient, encouraging experimentation, and paving the way for innovation.

Modularity opens the door to permissionless innovation.

2. Sovereignty

Because the Celestia network itself is only responsible for verifying data integrity and does not involve a complete consensus mechanism, the rollup on Celestia is essentially a self-sovereign blockchain. Nodes are free to hard/soft fork their software.

In L1, the fork will mean the fork of the execution and consensus layers. If the roll-up on Ethereum is vulnerable or attacked, it needs to be redeployed or the entire network fork to complete the state update. But Celestia allows chain forks without fear of losing security because the DA layer used after the fork is the same.

Updates become easier, technology iterates faster, and the execution layer can focus on optimizing the environment and rate of execution.

3. Easy to deploy

Deploying a chain requires establishing consensus and incentivizing nodes to join the network, which requires high resources and costs. With the development of PoS, tools such as the Cosmos SDK make it easier to create new blockchains, but developers still need to find validators to join.

Optimint introduced by Celestia will help developers deploy chains more efficiently because Celestia provides consensus and security.

4Cross-chain interoperability

Multi-chain adopts the same DA layer, which realizes the trust-minimized bridge between blockchains in the same cluster. It improves the security that multiple blockchains can communicate with each other.

Celestia combines the open ecology of Cosmos and the shared security of Ethereum, providing the possibility of multi-chain openness and shared security.

Future

We are on the verge of a massive paradigm shift, the crypto ecosystem is developing and iterating in an unprecedented way, and all efforts and attempts are approaching the end of the winding road for this goal. Celestia brings more possibilities to the network ecology, and the evolution of the network requires such components to support more possibilities.

Before entering the door that Celestia opened for us, it was hard to see how many doors there were behind it for me to explore - the space of adjacent possibilities expanded.

Maybe Celestia is not the best solution, but it will bring more innovation to the ecology.

I hope this article can help you.

Thanks for reading, and if you like my articles, feel free to chat with me on Twitter.

https://twitter.com/ChrisYicheng