Original title: " An article to understand the development status of the data availability track "
Original author: 0x1, IOBC Capital
Data Availability (Data Availability) mainly exists in the language of light client nodes relative to full nodes environment. For the data availability problem of light client nodes, the industry has reached a consensus - use erasure codes (erasure codes) to solve it.
Not only light client nodes have data availability problems, but also the narrative of Layer1+Layer2 and the narrative of Modular Blockchain will exist Data availability issues.
At present, there are three main solutions for data availability in the industry:
Ethereum uses Rollup to expand capacity There are three main types of fees: execution fee (the fee for all nodes in the network to execute the transaction and verify its validity), storage/state fee (the fee for updating the new state), and data availability fee (the fee for publishing data to L1) . Among them, data availability costs account for the bulk.
At present, Rollup uploads data to L1 in the form of Calldata, which is very expensive. Therefore, EIP-4488 is proposed, which can reduce the cost of each non-zero byte Calldata from 16Gas to 3Gas, but in fact, this cost is still quite high.
Then, the EIP-4844 proposal, Proto-Danksharding, was proposed. A transaction format called Blob carrying Transactions was introduced. Compared with the normal transaction format, this transaction format has one more Blob location that can be used to store L2 data. Moreover, the blob data will be deleted by the node after one month, which greatly saves storage space.
Blob is a transaction format that provides cheaper data availability than Calldata. There are two main reasons: On the one hand, Callda exists in the Execution Payload, while Blob data is stored in the Prysm node or Lighthouse node (not in Geth), compared to the resources consumed when Calldata needs to be read by the contract Much more; blob data, on the other hand, is short-term storage, and nodes delete blob data after a month.
All in all, this can be understood as a solution for Ethereum to reduce the cost of data availability on the L1 chain.
In addition, a matching scheme for verifying data availability - Data Availability Sampling (DAS, Data Availability Sampling) is also proposed. Download some randomly selected blocks to verify that a block has been published. Since DAS can perform parallel verification on block data, even if the number of future data sharding (Data Sharding) is large, it will not increase the burden on a single verification node, but will stimulate more verification nodes to join, thereby ensuring the verification nodes. fully decentralized. In order to realize DAS, the erasure code technology is introduced; at the same time, in order to ensure that the erasure code is correctly encoded, KZG polynomial commitments (KZG Polynomial Commitments) are introduced.
After the above series of solutions, the Ethereum node (or light client) only needs to randomly download some data blocks to verify All data are available.
The execution layer of the current head Rollup also has its own data availability solutions, taking StarkEx, zkSync2.0, Polygon zkEVM, etc. as examples.
StarkEx is an application-specific extension for creating licenses Solution framework. At present, projects including dYdX, Immutable, Sorare, DeversiFi, Reddio, etc. adopt StarkEx solutions.
StarkEx has multiple data availability modes: Rollup, Validium, Volition. All three modes are based on proof of validity. In Rollup mode, all data is submitted on the chain (data on-chain); in Validium mode, data is kept off-chain (data off-chain), and only the commitment to the most recent state and the validity of the state are submitted to the chain; the Volition mode is a hybrid mode, in which users can choose whether the data storage mode of a single transaction granularity is on-chain or off-chain.
Because Validium's data is kept outside the chain, only the commitment and proof of the latest state need to be submitted to the chain, so Validium's transaction costs are lower, and TPS is also faster High, but at the cost of StarkEx Validium Operators (Operators) can freeze users' funds. StarkEx introduced a permissioned Data Availability Committee (DAC, Data Availability Committees), and the DAC must confirm that it has received the data by signing every update of the state through its quorum. Currently in StarkEx, the DAC consists of 8 participants.
zkSync2.0 introduces a new overall architecture, providing zkRollup and zkPorter A mix of both accounts. But these two parts are also composable and interoperable: contracts and accounts on the zkRollup side can seamlessly interact with accounts on the zkPorter side, and vice versa. From a user perspective, the only noticeable difference is that zkPorter accounts are 100x cheaper in fees.
zkRollup state has on-chain data availability, zkPorter uses off-chain data availability. Specifically, the data availability of zkRollup is at L1, and the data availability of zkPorter is at L2. Among them, the transaction data of zkRollup is published to Ethereum through Calldata, which is a routine operation, and the unique feature is the data availability solution of zkPorter.
zkPorter handles data availability through a hybrid approach combining zkRollup and sharding ideas. It can support any number of shards, each with its own data availability policy, defined by the shard's smart contract. Shard selection is controlled at the individual account level. It is equivalent to delegating data availability to individual shards, and these shards are free to choose different solutions.
The shards of zkPorter mainly include: Shard 0, Guardians Shard and Protocol X Shard.
Other fragments are Define your own on your own smart contract Data Availability Policy. zkPorter's shards exchange data availability on the chain, which further reduces transaction costs by 10-100 times, and the TPS increase exceeds that of basic shards. zkPorter introduces an optional validator mechanism — zkPorter Guardians — which enables the protocol to invite protocol stakeholders to act as guarantors of data availability on protocol shards.
The data availability of zkPorter is protected by zkSync Token holders (Guardians). They track the state of the zkPorter side by signing blocks to confirm the data availability of the zkPorter account. Guardians use zkSync Token Participate in Proof of Stake (PoS). This is the so-called cryptoeconomic guarantee of data availability.
Polygon zkEVM is a cryptographic proof-based decentralized Ethereum Layer2 expansion solution can provide verification and fast finality for transactions. Like Polygon Avail, it is an expansion solution launched by Polygon, with a different focus. Although they introduced Polygon Avail, a general data availability scheme, Polygon zkEVM has set up its own data availability scheme.
Polygon zkEVM also adopts mixed mode data availability, you can choose Validium or Volition. In Validium mode, data is stored off-chain, and only validity proofs are published on-chain; in Volition mode, for some transactions, data and validity proofs are kept on-chain, and for other transactions, only proofs are on-chain.
Of course, there are also zkRollups that have not yet designed their own data availability solutions, such as Scroll .
In an interview with Chain Catcher, its CTO Ye Zhang said, "Scroll has not designed a special data availability solution for the time being. The timeline of Ethereum technology is still relatively optimistic. Yes, whether it is Danksharding or Proto-Danksharding. Secondly, the introduction of additional data availability solutions will compromise the overall security of the system, so we think it is best to use Ethereum as the native data availability layer in the long run.”
In addition to Ethereum L1 and Rollup L2 In addition to data availability issues and reducing the cost of data availability, some projects are also trying to introduce general solutions for data availability. Such projects are expected to take on the important role of the data availability layer in future modular blockchains. Currently there are two main projects, Celestia and Polyon Avail.
Celestia is a modular blockchain focused on the data availability layer. The Celestia DA layer has two key features: Data Availability Sampling (DAS) and Namespaced Merkle Trees (NMT). DAS enables light nodes to verify data availability without downloading entire blocks; NMT enables execution and settlement layers on Celestia to download only transactions relevant to them.
Celestia publishes all this data on its network;
Ethereum confirms that Celestia has stored and published this data and can access it at any time. All in all, Celestia realizes this general data availability solution through erasure code (Erasure Code) + fraud proof + economic constraints and incentive mechanism.
Polygon is a project with strong vitality, its team planning and development Very capable. Polygon has experienced the evolution of expansion technology solutions from state channels, Plasma to Optimstic Rollup, zk Rollup. The Polygon team has also explored various expansion directions, and it still maintains the advancement of multiple expansion directions, such as: Polygon Avail, Polygon Zero , Polygon Miden, Polygon zkEVM, etc. Polygon is like a Layer2 aggregator, aggregating multiple expansion solutions.
Polygon Avail is a project that aims to solve the data availability of Ethereum expansion scheme. The official website defines Polygon Avail as a modular blockchain corresponding to the data availability layer.
Avail can provide high data availability guarantee for any light client. High DA Guarantee".
Avail focuses on proving block data by leveraging KZG polynomial commitments, erasure coding and other techniques to allow light clients to efficiently and randomly sample small samples Available without downloading all blocks to verify their full availability.
Like Celestia, Polygon Avail is a general purpose data availability solution. Unlike Celestia, which uses fraud proofs to ensure erasure coding is correct, Polygon Avail uses KZG commitments. Celestia is relatively simple to implement, but requires a slightly higher communication bandwidth due to its erasure code and the large scale of light node sampling data. Avail involves a relatively complex encryption implementation, which is slightly more difficult. Its advantage is that the scale of erasure correction code is small, the amount of data sampled by light nodes is small, and the bandwidth requirement is low.
< img677px" alt="image" src="https://image.blockbeats.cn/upload/2022-11-10/ea75ca351cba98b39caa431320cd61213c81444e.png?x-oss-process=image/quality,q_50/watermark,image_d2F0ZXJ tYXJrbmV3LnBuZz94LW9zcy1wcm9jZXNzPWltYWdlL3Jlc2l6ZSxQXzIw,g_center/ format,webp">
At the same time , I hope to see more outstanding entrepreneurial teams exploring in the field of data availability. These existing data availability solutions are pathfinders, but I always feel that these solutions are still less exciting.
Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia