Skip to content
Blog

Karak Universal Data Availability (KUDA)

As the rollup landscape continues to evolve, the shift towards data availability (DA) layers introduces new benefits as well as new challenges. Integrating with various DA providers and lacking the flexibility to leverage multiple solutions can be complex and limiting.

KUDA, Karak's Universal Data Availability, is the first DA marketplace designed to seamlessly connect rollups with any DA layer. KUDA eliminates the burden of managing multiple DA implementations, allowing rollup teams to focus on enhancing their core functionalities. KUDA also offers a streamlined experience with its aggregator and order book system, enabling submissions to be paid for in a single currency and fostering efficient coordination among rollups. This not only future-proofs data availability but also unlocks new levels of scalability and decentralization.

For developers, KUDA simplifies operations by handling complex DA processes declaratively, ensuring a trust-minimized and efficient approach to data availability. KUDA provides access to the most cost-effective, secure, and easily integrated DA solutions.

With KUDA, developers gain access to a flexible, cost-effective, and scalable platform that minimizes the need for extensive infrastructure while maximizing data integrity and security. KUDA makes it easier and more secure to build a rollup than ever before.

Current Challenges

Rollup developers today face several problems:

  • No flexibility: Rollups want the ability to choose and switch between DA providers easily. Currently, there’s no straightforward way to do this.
  • Difficult maintenance: Integrating multiple DAs with each rollup stack requires custom implementations and maintenance of various versions.
  • No backups: Rollups lack fallback options except for expensive Ethereum calldata.
  • No optionality: Rollups cannot easily express cost vs. security preferences.
  • Coordination challenges: Smaller rollups struggle to coordinate 4844 blob sharing.
  • Operational overhead: Managing and refilling tokens needed to pay for DA adds complexity.

Architecture

KUDA Architecture

Participants

  • Aggregator: Interacts with rollups and registers tasks. Rollups send their blob data as task requests, including the list of DAs where the data can be posted and the price they are willing to pay.
  • Operators: Responsible for posting the data to DAs (posters) and building inclusion proofs for challenges (provers).
  • Challengers: Anyone who wants to challenge a particular data post within the claimed data availability period. This can include rollups specifying preferred DAs and the amount they are willing to pay.

Data Posting Process

  • Creating Data Posting Tasks

Rollups need to specify three things when making a DA post request:

  1. Price they are willing to pay for storing the blob.
  2. List of preferred DAs.
  3. The data itself.

  • Bids & Lottery

Task requests are posted to an order book, and operators can express interest by responding affirmatively. The aggregator then uses a stake-weighted lottery to pick a winning operator, who is assigned the task of posting the data.

  • Posting to a DA Provider

The assigned operator posts the data to a preferred DA from the list specified by the rollup. The aggregator precomputes the commitment to ensure data integrity. After posting, the operator writes the receipt, along with the commitment and the aggregator’s signature, to the KUDA contract.

Verification and Aggregation

Writing Receipts to the KUDA Contract After posting, the operator should get a commitment from the DA for the blob data it posted. The operator writes the receipt to the KUDA contract, along with the commitment computed by the aggregator, the task ID, and the aggregator’s signature. The commitment will have a prefix corresponding to the DA provider the data was posted to, making it easy to differentiate between the different DA providers.

The rollup’s batcher can listen to events in the KUDA contract to know when there has been a successful post. It can then use this data to write to its own inbox contract.

Handling Larger Data

Since EIP-4844 has a blob size of 32 bytes each, any data larger than this size has to be split. KUDA can batch commitments so that it has a single commitment for the entire piece of data.

Challenging & Proving

  • Challenge System

KUDA introduces a challenge system to ensure that operators don’t misbehave. Anyone can challenge a task by posting a bond. If the challenge is successful, the operator gets slashed; otherwise, the challenger loses their bond.

  • Proving Mechanisms

KUDA uses the registration contract as a gateway to different verifiers corresponding to each DA verification system. Since the available DAs use either Merkle proofs or KZG proofs as inclusion proofs, KUDA supports these two proving mechanisms.

Slashing Mechanism

To disincentivize bad actors, KUDA has slashing which occurs in the following scenarios:

  • When a challenger successfully challenges a data commitment that is missing or incorrect, the data poster gets slashed.
  • If a challenger challenges and the commitment is correct, the challenger loses a portion of their bond.

Ensuring Integrity and Reliability

By addressing critical challenges such as vendor lock-in, maintenance complexity, and operational overhead, KUDA offers a comprehensive solution that simplifies and enhances the rollup development process. Its approach to task management, flexible payment options, and robust challenge and proving mechanisms ensure that rollups can operate more efficiently and securely than ever before.