Data Availability and Decentralization: New Techniques for zk-Rollups in Layer 2 Blockchain Networks

Chengpeng Huang,Rui Song,Shang Gao,Yu Guo,Bin Xiao
2024-03-16
Abstract:The scalability limitations of public blockchains have hindered their widespread adoption in real-world applications. While the Ethereum community is pushing forward in zk-rollup (zero-knowledge rollup) solutions, such as introducing the ``blob transaction'' in EIP-4844, Layer 2 networks encounter a data availability problem: storing transactions completely off-chain poses a risk of data loss, particularly when Layer 2 nodes are untrusted. Additionally, building Layer 2 blocks requires significant computational power, compromising the decentralization aspect of Layer 2 networks.
Cryptography and Security
What problem does this paper attempt to address?
This paper attempts to solve two main problems in Layer 2 (L2) blockchain networks: **data availability** and **decentralization**. Specifically: 1. **Data availability problems**: - After adopting Danksharding, zk - rollups face the "lazy validator" problem and the historical data loss problem. The lazy validator problem means that L1 nodes directly accept batches without conducting sampling checks, which may lead to data unavailability. The historical data problem is that the data in the temporary storage space (blob) will be deleted after a period of time, resulting in permanent loss of historical transaction data. - In addition, L2 nodes may be unwilling to download and save historical data due to high bandwidth and storage costs, and may even maliciously withhold the data requested by users. 2. **Decentralization problems**: - zk - rollups require L2 nodes to generate zero - knowledge proofs (zk - SNARK), which have high requirements for hardware resources, so that only a few high - performance nodes can participate, reducing the degree of decentralization of the network. - At the same time, in order to ensure data availability, L2 nodes need to download and store a large amount of data, which also increases the bandwidth and storage burden, further limiting the number of participants. ### Solutions proposed in the paper 1. **Data availability**: - Introduce "Proof of Download" to ensure that L2 nodes must download complete historical transaction data before generating new batches. - Design a "Proof of Storage" scheme to punish nodes that maliciously delete historical data. - Propose a "Hidden State" mechanism. Calculate the transaction data of the previous batch through a hash function and include it in the header of the new batch to ensure that all L2 nodes must download the transaction data of the previous batch. 2. **Decentralization**: - Design a new role - separation scheme, dividing L2 nodes into "Proposers" and "Builders". Proposers are responsible for selecting transactions, and Builders are responsible for generating compressed transactions and corresponding proofs. This division of labor reduces the hardware requirements, enabling more nodes to participate in the L2 network. - Introduce a "Proof of Luck" mechanism to prevent collusion between nodes and effectively resist the maximum extractable value (MEV) attack. ### Summary The main contribution of the paper lies in proposing a series of novel technologies to enhance the data availability and decentralization degree of the L2 network. Through these technologies, not only the data availability and decentralization challenges in the existing zk - rollup schemes are solved, but also the efficiency and security of the entire network are improved, demonstrating the feasibility and potential of these technologies in practical applications. ### Formula examples - **KZG commitment**: \[ C \leftarrow \text{Commit}(\text{srs}, \phi(x)) = g^{\phi(\alpha)} = \prod_{i = 0}^{k}(g^{\alpha^i})^{\phi_i} \] where \(\phi(x)\) is a polynomial, \(g\) is an element in group \(G\), \(\alpha\) is a secret value, and \(\text{srs}\) is a structured reference string. - **ZK - SNARK proof**: \[ \pi \leftarrow \text{Prove}(pk, x, w) \] \[ b \leftarrow \text{Verify}(vk, x, \pi) \] where \(pk\) and \(vk\) are the proof key and verification key respectively, \(x\) is a public statement, \(w\) is a private witness, and \(\pi\) is a succinct proof. These formulas are used to ensure data integrity and the security of the verification process.