Sharding was once considered a primary method for blockchain scaling, but the issue of atomicity in cross-shard transactions has never been fundamentally solved. During the sharding process, the emerging concept of modular blockchains has become a more feasible approach. Modular blockchains are still in a very early stage and have not been rigorously defined. The basic idea is to decouple monolithic blockchains into different domains such as the messaging layer, consensus layer, and data availability layer, and to safely achieve scaling by invoking different domains. The most widely applied architectural designs currently are Rollups and inscriptions.
Although inscriptions are not widely regarded as modular blockchains, from a technical perspective, they treat the monolithic blockchain as a message queue service, which aligns with the concept of modular blockchains. The advantage of inscriptions is that all nodes can reach consensus without the need for communication, greatly expanding the throughput of blockchains. However, the downside is also obvious: the messaging service layer can only transmit very limited information, making it difficult for inscription systems to expand, such as in smart contract functionalities. If we securely store data in another module and only publish pointers to the data in the messaging layer, ensuring that all nodes can maintain consistency on data availability at any time, we can greatly expand the inscription system. This is very useful for monolithic blockchains such as Bitcoin and Ethereum.
The core idea of Rollups is to shift computation off-chain and verify it on-chain, with cross-Rollup transactions facilitated by some communication protocol. Although the Ethereum ecosystem considers Rollups as a transitional solution or a Layer 2 solution, Rollups themselves have irreplaceable value. Different application types have different price elasticity and security requirements. In a blockchain design with unified consensus, diverse security requirements and price elasticities cannot be met. That is, increasing TPS and reducing transaction fees do not optimize resource allocation, as "accelerating one transaction necessarily slows down another" has already reached Pareto optimality.
Different segments of transactions also have different price elasticity. Applications like punks and Bored Apes have price elasticity similar to luxury goods, while social interaction and DAO-type applications are the opposite. This determines their sensitivity to gas fees. Sensitive applications that are partly moved off-chain, upon further study, reveal that they have different security assumptions and consensus requirements. For example, applications like Ceramic assume security based on "users will not attack their own data," while Snapshot-type voting applications assume "every relevant user can simply verify." By moving data production off-chain, they save costs but also introduce additional attack vectors, such as data withholding attacks. Moreover, to use these data on-chain, additional security assumptions are required. Another approach is to use cheaper sidechains, but as transaction volume on sidechains increases, transaction fees also rise, and transactions from sensitive applications will be the first to be abandoned by users, and this model also requires additional cross-chain security assumptions.
Consider a design pattern where Rollups on the same settlement layer have different security models and interact with each other through some protocol, allowing Rollups to achieve adaptive security at the same cost. For example, users expect interactions in social network applications to be free, which requires "consensus" to be as light as possible. However, the social relationships generated by social networks have protocol value, relied upon by many other applications, requiring "consensus" to be as secure as possible. To resolve this contradiction, we can utilize the fact that most protocol applications only need "read-only" features, designing a "read-only" cross-Rollup protocol, where applications that depend on a challenged application are reduced in the same way. Therefore, even if the social network is based on a permissioned blockchain, for security considerations, applications that depend on it will also verify it. Thus, the more widely used an application is, the higher its security, bringing about a transaction paradigm that is security adaptive without increasing user costs, while also ensuring on-chain data availability (on the same settlement layer).
Additionally, to make the "read-only protocol" more flexible, applications should be allowed to dynamically add dependencies. This poses new design requirements for the settlement layer, in other words, it brings diversity to the settlement layer. This diversity will eventually be fixed into the underlying protocol, without the need for smart contract support.
There is extensive literature on the importance of data availability in blockchain scaling, ensuring the feasibility of fraud proofs for optimistic Rollups, providing guarantees for transaction ordering and censorship resistance for zk-Rollups, and greatly expanding the design space for modular blockchains.
Ethereum and Celestia are currently committed to providing data availability solutions, but they ultimately rely on full nodes or storage nodes to store data, which actually deviates from the original intent of scaling. Our main achievement is introducing farmers to solve the dependence on the smallest set of honest participants, addressing the issues of "who reconstructs the data, who stores it, and for how long," and enabling validators to work like light clients, which is very friendly to future sharding.
In optimistic Rollup, the block producers of Rollup compute off-chain and submit an assertion to the chain after a certain period. Malicious block producers can withhold some data, preventing other users from recomputing the state root and thus unable to generate fraud proofs. In a blockchain environment, any malicious transaction can be fatal, such as the ability to mint a large amount of currency for oneself. We need to ensure that the data used to compute the final state is complete.
For zero-knowledge proof-driven Rollups, data withholding attacks prevent other validators from computing the current state, leading to severe consequences. Moreover, they also need to ensure the robustness of transaction ordering and require the transaction data to be fully disclosed.
To achieve this, one straightforward way is to download the complete data to verify its availability, but this goes against the original purpose of Rollup technology. Another approach is sampling, but directly sampling from the original data can only probabilistically guarantee the availability of most of the data. A more feasible approach is to use erasure codes. Erasure codes extend data of length $k$ to data of length $n(n>k)$ and can recover the original data from any $k$ out of the $n$ data.
Assuming the data is correctly encoded, a light client can probabilistically confirm the availability of the data by randomly sampling a set of data. And this does not require the assumption of majority honesty. Even in the event of a "51% attack," the sampled results of the light client are still secure. We adopt and expand the secure framework from the original paper on data availability.
Definition 1 (robustness): If an honest light client accepts a block as available, nodes can obtain the complete block data within a delay of no more than $t_d$, where $t_d$ is the maximum network delay.
Definition 2 (Consistency): If an honest light client accepts a block as available, all other honest light clients will also accept the block as available within a delay of no more than $t_d$, where $t_d$ is the maximum network delay.
Definition 3 (Persistence): Anyone can obtain complete data at any time within $t_p$, where $t_p$ is the data persistence time.