KUDA: Karak Universal Data Availability

As the rollup landscape continues to evolve, the shift towards data availability layers introduces new benefits, as well as new challenges, particularly the complexity of integrating with various DA providers and lacking the optionality to leverage multiple solutions.

Enter KUDA, Karak’s Universal Data Availability, the first DA marketplace designed to seamlessly connect rollups with any DA layer. KUDA removes the burden of managing multiple DA implementations, allowing rollup teams to concentrate on building and enhancing their core functionalities. KUDA also offers a streamlined experience with its aggregator and orderbook 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. Ultimately, developers just want access to DA that’s the cheapest, the most secure, and that’s the easiest to integrate with. KUDA provides just that.

Status Quo

As rollup developers look across the market today, they are faced with the following problems:

1. No flexibility. Rollups don’t want vendor lock-in. They want to be able to pick and choose which DA they can post to but also have the option to change this easily in the future if they so may choose. Currently, there’s no easy way to do this.
2. Difficult to maintain. Integrating more and more DAs with every rollup stack becomes difficult which results in a) teams having to write different custom implementations and b) rollups or DA creators having to maintain different versions of their implementation for the other’s various versions.
3. No backups. Rollups have no way to express fallback preferences, except for Ethereum calldata, which is expensive.
4. No optionality. No way for rollups to express cost vs. security preferences.
5. Difficult to coordinate. No way for small rollups to coordinate 4844 blob sharing.
6. Too much operational overhead. Having to hold, refill, and monitor tokens needed to pay for DA.

KUDA

Introducing KUDA: Karak Universal Data Availability, the first marketplace for DA making it easier for developers to build a rollup than ever before. KUDA itself is a Distributed Secure Service, or DSS, built on top of Karak. The participants are:

1. Aggregator: Responsible for interacting with rollups and registering tasks. Rollups send their blob data as task requests including the list of DAs where the data can be posted and the price the caller is willing to pay for the task
2. Operators: Responsible for posting the data to DAs (posters) and invalidating challenges by building inclusion proofs for challenges (provers).
3. Challengers: This can be anyone who wants to challenge a particular data post as long as it is within the period claimed for data availability. This can also be the rollups that are sending data to be posted, where they can choose which DA’s they’d like to post to, and the amount they are willing to pay for the task.

With KUDA it’s now possible where:

• Each data post becomes its own separate task
• Rollups can pay in a single token and specify how much they want to pay for each task
• Data is only posted to a DA that is whitelisted by the rollup
• Proving data availability per task without any additional configuration
• Data is assumed to be available only as long as the minimum persistence provided among the DA providers (if the whitelisted DAs are Celestia & EIP-4844, with Celestia offering 30 days & EIP-4844 18 days, the assumption is that the data will be available for at least 18 days
• Sharing 4844 blobs among smaller rollups

KUDA makes it easy for developers to build a rollup easier than ever before. With KUDA, rollups can now just integrate one application and get access to all DAs which reduces vendor lock-in, reduces costs since they can optimize for costs if they so may choose, and provides them with a turnkey, SaaS-like developer experience. It’s also significantly easier for rollups to have to run less infrastructure while being able to upkeep any DA updates. Finally, KUDA provides rollups with inclusion proving out of the box.

Security Assumptions

How this affects the security assumptions of a rollup depends on how a rollup defines its DA preferences. One argument is that the rollup is only as good as its weakest DA in its preferred subset. But challenging any data posted is limited to the amount of time that operators are open to slashing, which is 7 days. However, if the primary DA is used most of the time then it’s not quite true. Having a pre-defined fallback is better than none. If a rollup is built with very little or no gas assumptions, it may not have the means to automatically fallback on Ethereum calldata for more than a few batches. Challenging and proving adds extra security guarantees as long as the underlying DA provider is secure. Initially, the only centralized entity in this setup is the aggregator itself, but this doesn’t affect the data integrity as long as the operators are acting in good faith.

Data Posting

Creating data posting tasks

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

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

Bids & Lottery

This task gets posted to an order book, which operators can decide to pick up by responding affirmatively. If operators don’t respond to a task, it is assumed that they’re not interested in picking up the task.

The aggregator will then use a stake-weighted lottery on operators that expressed interest in the particular order and pick a winner. This winning operator will be assigned the task of posting the data. Operators who are on their withdrawal period cannot be picked for a data posting task.

Posting to a DA provider

When an operator gets assigned a task, they must post to a DA from the list of DAs the rollup specified in the task. Operators are free to choose a whitelisted DA which suits them. The aggregator will also precompute the commitment according to the DA that the winning operator picks. We do this to make sure there’s no tampering with the data by the operators.

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, e.g. 0xce for Celestia. This makes 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.

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

Challenging & Proving

KUDA introduces a challenge system to ensure that operators don’t misbehave. Anyone can challenge a task, i.e. whether a specific piece of data has been posted correctly. A challenger needs to put up a bond, which will be returned in case the challenge is successful, i.e. the data is indeed missing or incorrect. As mentioned previously, the challenge window is one week max because operators are open to slashing within a week of them withdrawing from KUDA. The challenge can be picked up by any operator in the system, and they will need to provide an inclusion proof to win the challenge. A challenge can only live as long as the data is assumed to be persisted.

KUDA uses the registration contract as a gateway to different verifiers corresponding to each DA verification system. Since the available DAs either use Merkle proofs (Celestia) or KZG proofs (Avail, EIP-4844, EigenDA) as inclusion proofs, KUDA will be supporting these 2 proving mechanisms.

1. For Celestia, KUDA follows the proving mechanism as given here.
2. For Eigen/4844, KUDA has a verifier contract that accepts the KZG proof and calls the point evaluation precompile to perform the verification. For more information on how KZG verification works, you can refer to this article.

Again, for EIP-4844, KUDA only supports proving for a single blob at the moment, but it can support multiproofs for the entire data on multiple blobs.

Slashing

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

1. When a challenger challenges a particular data commitment that turns out to be missing or incorrect, meaning a successful challenge, the data poster gets slashed a significant percentage of the time the data is supposed to be available.
2. On the other hand, if a challenger challenges and the commitment turns out to be okay, the challenger gets slashed, meaning they lose a portion of their bond.

Conclusion

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. 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. As the first marketplace for data availability, KUDA enables rollup developers to build and maintain their infrastructure with unprecedented ease and confidence. KUDA simply makes it easier and more secure to build a rollup than ever before.

If you’re a rollup builder, RaaS provider, or just a developer considering building a rollup, please get in touch with us today.

About Karak

Karak is the universal, verifiable cloud platform that makes it easy to provide universal security with any asset on any network, and unlocks a new design space for developers to seamlessly and securely create innovative distributed networks. Karak is designed to be inherently flexible, extensible, and scalable, making it the only platform for any distributed service to be secured with any asset on any network.

Website | X (Twitter) | Discord | Telegram | Documentation