Owner: @Álvaro Castro-Castilla

Preliminary

Q&A on RS + KZG Danksharding with Leonardo Bautista

2D Reed Solomon Encoding + KZG Commitments benchmarking

Base designs

Architecture 1: Ethereum Design (without DA committees)

1. Delivery of data blob from EZ proposer to Base Layer
2. Encoding of BL block (alongside other blobs) in BL leader (or in a distributed manner in BL)
3. Dispersal in BL
4. Consensus

Step 1: The EZ posts the data to the BL

After the EZ chain has produced enough blocks, the EZ decides to post them as data to the BL (this decision is EZ-dependent). The purpose is to:

• Guarantee to the EZ users that the data will be available by a larger and more decentralized network than the EZ provides by itself (which could be a really small network).
• Commit to this state with the full economic security of the Base Layer (although the BL does not execute or care about anything in the data blobs)
• If the EZ is a validity-rollup, it will post a ZK proof of the state in this blob.
• Native asset withdrawal transactions will also be posted with the blob.

The EZ won't do the encoding, that will be responsibility of the BL. All that the EZ does is send data blobs.

<aside> ❗ Important note on privacy An important aspect to consider here is that if data blobs are disseminated to the entire network through the mempool, the benefits of reduced bandwith usage will be lost. At the network level, we need to ensure that the data is somehow delivered as directly as possible to the block builder(s) through some smart mechanism™️ (TBD). This is a serious privacy concern that we would need to solve, since the leader is secret. This looks like a hard problem.

</aside>

Step 2: The BL performs 2d RS Encoding + KZG commitments

A single block builder, or a decentralized coalition of them (to be determined), will perform the following:

1. Aggregate the data blobs for the block, as they were received from the multiple EZs.