New applications of DA layer

New applications of DA layer

Background

The Data Availability (DA) layer ensures consensus on the presence and accessibility of transaction data within a blockchain network.

Traditionally, the data stored in the DA layer can be utilized by potential block producers to reconstruct the state of the chain and start producing new blocks. This prevents potential issues like Layer 2 operators arbitrarily freezing the chain or censoring rollup users. Leveraging the DA layer for security allows rollups to optimize for scalability. For instance, a rollup might choose larger blocks and faster block times to enhance performance.

Radius

Radius uses the DA layer to store order commitments, serving a different purpose than the traditional method of storing transaction data. To delve deeper into this concept, let’s see how Radius works.

Sequencers are responsible

for ordering transactions and building blocks. They have the power to censor and extract MEV (Maximal Extractable Value) through front-running and sandwiching. Radius is a shared sequencing layer for decentralizing sequencing and block building in rollups.

To eliminate harmful MEV and censorship, Radius utilizes an encrypted mempool and a ZKP scheme called PVDE (Practical Verifiable Delay Encryption). This ensures that the sequencing process is trustless.

  1. The user sends an encrypted transaction to the sequencing layer.

  2. The sequencer orders the transaction.

  3. The sequencer sends an order commitment (order, signature) to the user.

  4. The sequencer decrypts the transaction and builds the block.

  5. The block is submitted to the rollup.

  6. The rollup executes the transactions in the order provided by the sequencer.

  7. The rollup submits the transactions to the settlement layer.

Storing Order Commitments on DA

Radius sequencers submit an order commitment upon ordering user transactions. This commitment guarantees transaction inclusion and provides users with fast pre-confirmation. The order commitment ensures that the sequencer has ordered the encrypted transaction without decrypting it.

To ensure that sequencers or subsequent entities (e.g., rollups) do not violate the committed order, we use the DA layer to store the ordered list of encrypted transactions, where the index of each element represents the promised order. Users can verify transaction inclusion and order, and make a claim in case it’s violated.

Use Case: Madara

We utilized DA for order validation in Madara, which involved creating a separate mc-sync-block crate. This crate instantiates a local database where blocks of encrypted transactions are stored. It reads encrypted transactions from the sequencer’s local database and stores them in the DA, parallel to the main thread of transaction flow. This approach ensures lower coupling and greater control over error handling and gas optimizations. Additionally, the time required for rollup block requests is shorter than the DA storage time, necessitating such modularization.

Conclusion

By using the Celestia DA layer to store order commitments, Radius not only enhances the security and reliability of transaction sequencing but also lays the foundation for a more equitable and censorship-resistant blockchain environment.

4 Likes

Intersting post. I had a question on the Design.

What is posted on the DA Layer, and by whom?

  • encrypted transactions
  • decrypted transactions
  • order commitment

In the DA layer, the list of encrypted transactions is posted. This list serves as the order commitment, or more precisely, as a collection of order commitments. The position of each encrypted transaction in the list indicates its order in the block, promised to the user. Madara posts this list, specifically through its mc-sync-block crate, which was implemented by Radius team as a contribution to Madara.

1 Like

Do you also post the decryption keys so the user can only use the DA-Layer for the canonical truth ?

We post the encrypted transactions along with the time-lock puzzles. Solving these puzzles yields the decryption keys.

The integration of encrypted transactions with time-lock puzzles, as clarified above, strikes me as a valiant strategy to balance transparency and security. I’m curious about the user experience implications of this system, particularly the wait times associated with solving time-lock puzzles for decryption. How do you see this impacting overall user satisfaction, and are there any measures in place to ensure that this does not become a bottleneck?