Huhuu Hey from uniFires… we are pulling some folks & skills together to start a Cardano ↔ Polkadot light client bridge for the more serious part and a Cardano ↔ Polkadot NFT Swap on the more fun part.
We submitted proposals in Cardano and have the idea to also submit proposals at OpenGov as well to fund that from both ecosystems… our plan is to go with a phased approach, where each phase building upon the previous one and comes with its own proposal…
Phase 1 - Feasibility Study… if completed →
Phase 2 - MVP. if completed →
Phase 3 - Product
uniFires main job would be to connect the dots and to help in getting the right people & skills together along the way and we’d build open source… so looking to get builders from both ecosystems engaged for the development… On that, we checked in with several Cardano Entities & Projects and we had a check in with Tommi & Jeeper from OpenGovWatch as well (who actually kinda sparked that whole thing with a tweet XD) to help connecting well to the people & skills at the Polkadot ecosystem.
What do folks here think about the idea… happy for feedback, ideas, critic etc
As a Cardano->DOT bridge side, you need to write a parachain that understand whatever the Cardano concensus exports. If they have mo concensus signatures, then your bridge will just be slow as it waits for enough blocks on the Cardano side. If for example I were building a bitcoin bridge, then I’d wait 24 hours, not merely the 1 hour bitcoiners wait. If you’ve some concensus signatures then you can go much faster, just wait for their 2nd round 2/3rd majority.
As a DOT->Cardano bridge side, you need the reverse. We’ve two DOT->ETH bridge designs from W3F for this, respectively based on sampling and a snark.
If you want to deploy the sampling one, then you should discuss parameters with Barghav at W3F, or maybe Alfonso Cevallos, or read their paper. Cardano has the same poor randomness problem as everything that employs Praos randomness collection, like Ethereum, Polakdot, etc. Cardano waiting times might by much worse than ETH, which maybe makes the bridge slow.
If you want the a snark one, then you should check which elliptic curves Cardano supports for generic usage, and maybe talk to Syed or Robert Hambrook, or just look at our code. Appears CIP-0381 never got accepted? If no then no snarks for you.
Yep, thats a bunch of valid points and very much nailing some of the topics we have to figure out for such a bridge… Will definitely look to get in contact with Barghav & Cevallos then, thanks a lot for the hint.
Ye, not sure about CIP 381… doesnt seems that it is actively worked on right now, so maybe something we can push a bit
Happy to see this! Will be supportive of this endeavor! I have strong feeling that we’re stronger together and this is how mainstream adoption long term will work. I will be watching to see if there is anyway I can be of service, as this unfolds.
Hey Hope
Glad that you like it, and even more glad to check in with you to see where you could jump in and where we could collaborate to make the thing happen… helping hands are much needed on many sides
Sharing some learnings from my side. Felix set up a call with Sebastian Bode (LinkedIn), Director of Engineering at the Cardano Foundation.
Sebastian is currently building a Cosmos<>Cardano bridge and we discussed the bridge topics and I clarified some differences between IBC & XCM.
The most conservative/developed approach for the Cardano->Polkadot direction seems to be Mithril. Mithril(Paper, Github) is a research project of the Cardano foundation, which provides stake-based threshold multisignatures. A subset of Cardano validators opt-in to provide those signatures. In my simple monkey understanding, this is a light client(-ish?) protocol. Cardano transaction finality is achieved after one day. If I understand correctly, Mithril has shorter times to create state proofs, so this means that their light client protocol runs ahead of finality.
For the Polkadot->Cardano direction, I believe the most straightforward approach would be to verify Beefy proofs on a contract on Cardano L1.
Please do! Hopeioum on X and Hope_Clary on Telegram. Just let me know here when you’re ready to reach out, as I get DM’s from random people and I want to make sure I know its you.
P.S. I believe I follow you on X, but you may not be following me. So if you’re CatalystSwarm there, feel free to message me there when ready.
We always need fresh epoch randomness in the sampling bridge. We typically wait two-ish epochs for fresh epoch randomness in Praos protocols, so likely 1-2 days according to Cardano’s security arguments. You might optimize this somewhat, like 1.2 epochs or whatever.
You explore more interactive protocols between the chains too, but only so much you could do without real authoritative finality.
It’ll be fun working on this with you and uniFires Felix!
@burdges makes a good point, linking the two transactions live where each has different signature requirements might be a pain in the ass… could there be a way that we create some standalone nodes/gears that interact between both blockchains, so that each/any blockchain added to the bridge can continue to function at their own pace, but use the central node for a consensus mechanism?
As in, one person sells an NFT from Cardano, it might take 5 minutes for signature completion, then another 10 minutes for it to be properly displayed onto Polkadot, and vice versa. But if we have a central node between the two, we display the NFT instantly, then create a mechanism that shows when the required signatures for the transaction have been completed from Cardano. Then the central node immediately can be viewed from Polkadot + Cardano chains (or a website that displays it?), then people interact and purchase from the central node, then finalizing and stamping the transaction on both blockchains at the time singatures are finalized?
I think this would essentially reduce the time it takes for people to interact between the two chains, from 5 minutes on one side, and 10 minutes on another side (for example), to seconds, then letting the users/developers interact freely, while having the central node finalizing the transaction in the background, so they don’t have to see the friction of the blockchains.
It’s nothing to do with transaction signatures, but consensus signatures.
If Cardano uses Praos alone, with slow enough block times, then you must wait a long enough for enough consensus signatures, and Praos already defines “long enough” aka two epochs, either 24 or 48 hours. This is the real transaction finalization time too, so you cannot really even be faster if you permit large transactions. Mithril could be faster, but maybe not serious enough yet. Polkadot makes parachains into byzantine roll ups, so a polkadot bridge parachain can efficently read another chain’s concensus signatures and validator set changes.
Polkadot must prove itself to other chains too though, which becomes expensive because no other chains besides polkadot have efficent roll ups. We have a specilized third round (beefy) of polkadot’s concensus designed to simplify export to other chains. These run every polkadot epoch to export validator set changes, so that’s 50kb of key data every 4 hours. We’ve two bridge protocols that “roll up” beefy signatures from a concise commitment:
The web3sum specilized snark bridge proof, roughly a zk roll up of beefy signatures. Cardano does not support pairing friendly elliptic curves yet.
The sampling bridge proof, roughly a byzantine-like roll up of beefy signatures. This requires good randomness from the other chain, which takes this same 24 to 48 hours.
Ecosystems like Cosmos have fast bridges because they simply assume both chains are honest. In theory, you can create a Cosmos zone, initially earn people’s trust by being nice, but then later send birdge messages that steal everything the whole ecosystem has in any Cosmos-ETH or Cosmos-BTC bridges. That’s allowed in their threat model because they make chains trust one another without some basis for that trust.
Sounds like I will certainly need to learn more about the consensus signatures - I am reading this right now to get started: https://eprint.iacr.org/2019/269.pdf, do you have any resources/sites I can read more from this about on the Cardano side?
I’ll also take a look into Cosmos, do they have any review based mechanisms that allow for potential threats for starting off nice? Anything off chain correlated?
Cosmos’ primary defense is that new chains airdrop to existing ones, which gives some alignment of the avalidator sets. An attacker couild defeate this in various ways, like by making it annoying to run the nodes, or having honest nodes crash, or having “prefered” tokens, or making it hard to claim the airdrop. And they need not defeat this perfectly, just enough so they can exclude the honest ones.
Actually, the funniest would be first doing annother chain where the airdrop claim code compromized the recipient’s secret key, like by using bad randomness, so then nobody trusts the airdrops anymore.
Also, the best attack would simply be having something that did not respect the Cosmos airdrop conventions, but was something people wanted to use, and thus force other zones to connect. Of course if you can write that then you can make more money than you can steal anyways.
You might want to have a look at the Cardano partner chain Midnight - a polkadot to Midnight bridge is probably a lot easier to code given they both are based on substrate (for a start Midnight has finality, which is I hear coming to Cardano but I don’t know the timelines).
Yup well aware of Midnight, we had some Calls with them and keep in contact there, but Midnight is still in development and might take some time for it to go live. So, we prefered to move ahead already and not to wait for Midnight development.
Hey from uniFires… we are pulling some folks & skills together to start a Cardano ↔ Polkadot light client bridge for the more serious part and a Cardano ↔ Polkadot NFT Swap on the more fun part.
