Thanks to @teddyjfpender @rpanic @SebastienGllmt for your replies. As there is a long thread of discussions on twitter, mainly from @rpanic, I’ll try to categorise them here using the sub-discussions outlined by @SebastienGllmt. The initial post of this thread here was about data storage, not DA, so not continuing below). Also note that @rpanic 's comments on twitter may have not covered How, but more on why and discussions on the pros and cons of the approaches.
Integrate existing DA layers with Mina (Celestia, Avail, EigenDA). Notably, I believe this requires writing a groth16 verifier in Mina.
@rpanic: “tbh, bridging attestations over from celestia through some quorum of validators is a horrible idea. It removes all the properties of why we built DA in the first place resulting in really bad guarantees. But that is something that I find concerning with current DA archs anyways.”
Is there a way to use existing products to achieve so eg Celestia (prob no?), Avail, Eigenlayer?
“Afaik, no. They semm to all rely on some sort of state-root attestation on a L1 contract, that is done by some quorum of validators (how that works in detail I don’t know). What we can instead do on mina is prove the consensus of the DA layer itself (like the Mina L1).
This enables us to remove that trust assumption and at the same time reduce settlement cost.
EigenDA does it best, because they provide signatures of all the attesting validators so that is pretty strong. Still not as strong as proving consensus itself though.
So they problem with integrating existing solutions is: 1. Prove the state inclusion inside kimchi (most of them are KZG-based => difficult) 2. Have that attested stateroot coming from the DA-solution on the Mina L1 (either they collaborate on that or we bridge it from ETH).”
A Mina-aligned DA layer instead of using one of these other DA layers (Cardano is going through the same discussion at the moment and they also use Ouroboros so anybody interested in this may want to check out their new paper on this topic https://twitter.com/rom1_pellerin/status/1719318640498241980 )
“The DA I specced out and envision allows appchains to verify availability by simply merging in another proof, settlement cost stays constant. This also means that devs mostly don’t have to change any of their existing appchain-design patterns.”
@teddyjfpender: " What@rpanic46 is saying about the transaction cost must not go lost here. Running an app-chain, bespoke computation layer, L2, etc. need not pay more than anyone else to settle a transaction on the L1 ledger. Transactions need not be replayed, only verified, no gas or wasted computation."
@rpanic: "And we don’t want to add extra cost for proving DA as well. If we follow the traditional architectures that don’t utilize zk, that would be the case, so we can improve that by building a zk-native DA layer. ",
what’s the difficulty and limitation of settling on Mina L1 then, and how would you do it?
@rpanic: “The difficulty is not in the settlement itself, but in what you want to settle. Every Mina smartcontract is it’s own mini-rollups in the end. Problem with DA is that we have quite low limits on events and actions. But this is by design and DA should always be seperated imo.
But, the external DA layer has to have good guarantees, which DACs don’t have. Therefore we need a strong, well-designed, L1-aligned DA layer that integrates seemlessly in the current DX”
@teddyjfpender: “Couldn’t agree more with @rpanic46 he speaks eminent sense. What I would like to know more about, and study, is how a DA-layer can be optimized to specific applications & use-cases; gaming and DeFi might be quite different but perhaps there is a root of common requirements.”
