COSMOS IBC EVERYWERE with Karel Kaiser of Union

Transcript

welcome to the interrupt today my guest is Carell kubat AKA Kaiser Carell he's a CEO of Union they're building zero knowledge infrastructure for inability that will enable permissionless and Trust minimized message passing between the interchain and ethereum this is a fascinating conversation and we'll be discussing Carrel background as CEO of composable we'll talk about the union stack and the architecture of the protocol we'll discuss Comet BLS it's their BLS implementation of tenament we'll discuss galwa it's the ZK prover that they've built as well as Voyager their stateless relayer we'll talk about fixing the fungibility problem and also

the use cases for a union and one that I'm particularly interested in which is renting ethereum security for Cosmos chains we'll also talk about their plan to bridge Bitcoin over IBC which is incredible and so much more I'm also D to find out why he thinks Cosmos is making a huge comeback before we get started make sure to hit the like button hit notification Bell And subscribe to get notified when new episodes drop every week and remember that none of what we discuss here on the interop is investment advice and if you enjoy this content please consider staking with us we're validating on OS Quicksilver osmosis Juno and noas just look for the interrupt in the active set my guest Carell is coming up next right here on

the interrupt [Music] Carell thanks for joining me on the podcast yeah great to be here we've been talk talking about interruptibility on this show for as long as there's been the interrupt and I think we've covered like pretty much every interruptibility protocol out there maybe with the exception of layer zero um for some reason but um May maybe because it's it's it's a little bit not not so trust minimized as I like it uh but but um but basically that there's like a a wide array of different

interoperability Solutions and I think you guys are really trying to position yourselves as a highly trust minimized and highly permissionless interoperability solution for crypto um but yeah before we get dive into Union and how it works and the different parts of the architecture uh yeah I would love to hear a little bit about your background so previously you were CTO at composable you you left the company I believe last year um yeah tell us a bit about like what that experience taught you as uh in terms of like the the complex problem of bridging blockchains and you know how it better equi you to to be the CEO of uh of Union exactly so iig joined composable as a senior

engineer and actually climbed my way up to uh C CTO um I had different teams there including the originally interoperability team brid team um where we hadn't actually settled at the time on IBC so we realized the need for a trust minimized solution based on life clients and right as we got started with this was actually before like the first CK rollups launched uh so ZK life clients and switch were also really far away and actually uh quite theoretical in their performance um so we setled around a light plan based model um and then started implementing the actual protocol and thinking about like besides being able to send State proofs across chains what else do you need to build on

top of this to uh avoid Eclipse attacks and other types of attacks and there we kind of realized that we were started to reimplement IBC because if you want to do it with the least amount of onchain operations uh with taking all these different Tech factors into account you're going to either do IBC or something that's less efficient than that um that's actually the moment when composable decided to bring IPC to PKA dot to different ecosystems uh experience was around like a that whole Tex te so I worked a lot with Jack samplin and the ICF uh to basically dig through what we need to do to Port it a to completely new code base right like a rust substrate based uh code base as

well as a different consensus model using Grandpa finality and later b instead of tenament um and that kind of build a lot about what we're doing with Union because there as well you encounter the circle of basically only being able to use like the core IBC protocols and the specifications and needing to build an entire system from scratch to be able to handle ethereum and other rups so yeah we focus a lot on uh building out these uh kind of core infrastructure uh Solutions uh relaying uh onchain contracts um and basically got to know like the real ecosystem around IBC which is a very varied ecosystem as well with parties like informal Strange Love the ICF all

working in different modes for us that was really getting used to it because at the time in poad to kind of have parity which is a god emperor of tech that guides the entire parain group forward and obviously Cosmos is very very different in the way that parties collaborate with each other I think fundamentally a stronger way like having this God emperor of tech makes it seem initially like they're going to move quicker it's probably easier to raise a lot of VC funding which PA obviously did the saw with parity letting go of 300 developers it's actually not a really strong way to scale an ecosystem and actually having individual Builders try to compete with each other and raise to the Finish to a first implementation

leads to a much more diverse and stronger ecosystem so going into Union we basically took those technical lessons with us but also the kind of political lessons as well as the Eda lessons of seeing it as a really competitive space and focusing a lot on this idea of what can we bring to the space that is immediately going to be useful to protocols what do people actually want to use yeah that's always been one of the things that attracted me to Cosmos is this Market approach to building Tech you know a lot of times I've described it as the cathedral and the bizaar uh when comparing it to polka dot and I mean I'm not the only one who who's used this analogy uh but it sounds like you're a pretty big Cosmos bull uh what what um what are your thoughts on the

cosmos system right now and like where it's heading I think we kind of see the pay off of years of building now obviously when when token prices go up community members are happy uh when teams are raising they are happy throughout the bare Market everyone gets extremely unhappy you might even see uh influen start complaining about Builders uh are the death stumping what's actually happening here I think cosos we're seeing a really great pay off of teams that actually continue to build that's all coming to fruition right now look at Celestia look at ydx uh I think injective is doing great um I think overall like actually teams were kind of outside of the Inner Circle that have been building relentlessly are now

really uh going to production or are production and really successful with what they're doing um and to me that's going to be like a massive combination of uh factors that will basically I think allow the entirety of Cosmos to out compete uh certain rollup ecosystems as well think we saw a lot of hype with new rollups and once again like copy clones of the same ethereum contracts going everywhere but I think in Cosmos we're going to see some actually really interesting products that end users want to use right when you control your block times when you control your actual consensus that's when you can build really nice good stuff yeah we we'll talk a little bit about that later on but I think one of the major shifts that's that's coming to Cosmos or at least the you we can see is

is the utilization of eat Security in Cosmos and that I think will uh play a big role in in uh in making the ecosystem a lot better and just securing the ecosystem in a way that hasn't been possible up till now so let's shift to Union so what is the union product and what's the main problem that you're trying to solve with this protocol yes so I guess if you were to like draw a v diagram then Union wants to be to app chains for up separate State machines what Celestia is to them for the da but for interoperability um relatively similar to High plane in the sense that we want to be like plug and play and permissionless but it's all built around IBC so in our case we don't

rely on teams to deploying us to run their own multi- validator set or rely on the Wormhole Guardian sets instead uh we rely on light client proofs uh to actually facilitate this bridging um the big problem I see with IBC right now is the fragmentation as well as the need to do governance proposals to open these channels so we haven't yet really created a product product that allows us to spawn 100,000 chains and actually get all of them connected well like regular web 2 we can obviously easily spawn 100,000 servers out connect to the internet and start communicating that way and what I really want to see why I went into interoperability is this world where uh everything's on chain everything is a blockchain it's all

communicating with each other and it's all verifiable so with Union we're really setting out to build that our initial product is very much focused on adding something new to the ecosystem because I think in the kind of tender in Cosmos Cas space we figured out how to open IBC channels between these These Chains themselves use osmosis as a router Hub and but I think what like provides the most interesting new uh Avenue for tvl as well as new products is the ability to do IBC back and forth to ethereum um there you encounter a few issues obviously verification on ethereum Ultra expensive so if you go with the naive implementations of doing it without any ZK Tech you're going to spend and somewh between 5 to 10 million gas depending on the amount of

validators you have for last 's updates perhaps for like a really big chain with massive tvl willing to throw 30 million USD against the C year you could actually do it and operate the IBC channel that way but you want something more elegant and so that's what we set out to build with Union and what we have live right now in testnets IBC channel that uses our prover gwa to generate CK proof smart chain and sub those on ethereum as well as on the way back doing asset transfers and playing P so we've talked a lot about this on the podcast and like we just had hyperlane on last week so it's interesting you mentioned them um but yeah let's let's just remind everyone and get a refresher on like why

verifying State between ethereum and tender and ethereum and you know other uh maybe like you know Avalanche or other consensus mechanisms why is that hard and why does it require another solution than just being able to verify the state between the chains as tenament chains do yeah so for tenament chains they have been partially like really welld designed for inability because you've got single slot finality so you kind of know if you see a block it's going to be finalized you can generate proof for it and so that that to another chain what's uh a real kind of issue with it right now is the way that validators vote and sign blocks of the finalization process it uses signature schemes which there's

no pre-c compiles available on ethereum they vote on uh technically different payloads which means that you cannot aggregate these signatures cheaply in a ZK circuits and so I would say that like the core ABCI is kind of like 2019 Tech itself whereas in cryptography and consent design we've got a lot of better designs right now which can apply to it which also make tender to Tender Min IBC a lot more efficient and lower the state growth and make verification cheaper um going from ethereum to two other chains the real issues that you're running is obviously ethereum as is a massive validator set so actually keeping track of that part of the consensus is extremely expensive luckily ethereum has

this concept of signing committees so they basically aggregate in stages to perform this finalization process which still a lot you need to keep track of but in this case they did apply some really good thinking where they uh use BLS signatures uh to sign the payloads which makes ethereum verification very feasible at the moment and also quite CK friendly um so you kind of want to when you do ic2 ethereum the real problem is the light lines updates that you put on ethereum itself and kind of see with for example Su sync Labs solutions they got telepathy great products that they mainly focus on uh L1 ethereum to other chains because that stage generation Works still takes fight a long time if

you look at their ZK tendin uh I think they do updates about every 100 minutes so you already see kind of like if you just take attend the mint and build your product around that it's going to work okay for a product like glob stream where your latency requirements are very different but if you want to do asset transfers something that's much closer to the help path of user interactions then wait another 100 minutes for a bridge settlement to uh be finalized at least me as a bridge user wouldn't really want to use that I don't want to set a timer and go back to my dashboard 100 minutes later to see uh the transaction being bridged um so with Union what we did was we a um had a look at 10 minutes to optimize it for

verification on ethereum apply like the latest cryptography and consent engineering that's Comm BLS and that's actually like turned out to be massively successful in this approach so um proving times are at the moment for v2 sub 10 seconds uh can run on an M2 MacBook um Can scale to 128 validators we benchmarked it but because of BLS signatures you can scale to many many more validators U and so basically we managed to create a system where a you have this state verification full IBC stack uh all compressed in zero knowledge proof B you can actually produce these proofs on consumer Hardware um once we started building Union we didn't want to create a system

where we would need to burn 400k US dollars a month on cloud infrastructure where we had these like massive build farms to generate the CK proof that's kind of what you run into when you're in a z rollup um and why like sequence of decentralization is so hard there um and we didn't want that for biring system because we really want Union to be a system that could be run by anyone because then it's truly decentralized system and you're allowed to make it permissionless if we as a centralized party are the only ones that could feily produce proofs we would become a financial institution and we would have to stop surfing American users we would have to gu by all of the new laws that they are creating which is much better

to create a system where we ourselves don't have an off switch and don't have a sensorship switch at all and where even if Union Labs were to disappear Larry or gikan might just spin up a server and start continue improving to keep the IPC Channel operating uh so we managed to kind of achieve that in the first six months that we're building and and so that's when we came out of Step uh willing to to share this with the wider audience So when you say that proofs can be generated on a on on consumer Hardware what what does that unlock like practically speaking you know for for a user or in terms of uh like censorship resistance or uh or liveness

safety yeah so it's like considered an edge case issue right that the entity that build the protocol disappears supposed to design protocal situ way that it doesn't matter but we have seen this happen before with Bridges where the death team might be out partying while a heck happens or the CEO might be involved with some shady operations and be arrested in Shanghai Bridge goes fully offline 500 million in Valu is locked protocols that hold their wrapped assets are currently completely decked and you got an ecosystem wide crash um so you totally want to avoid this situation and with the way we've built this and built upon IBC even if after 10 years the union team calls it a day or

we were Al to die in a a plane crash all these IBC channels that are operational um and relaying assets plus controlling assets and different faults can be operated by a new relayer so as an end user uh the real risk that you have when uh using our protocol is that you might need to read the docs and a Rel layer for an end User it's it's less interesting uh right like your regular crypto user might not do this there's a protocol integrating this is really valuable so in the end when you're protocol on another chain accepting uh assets from a bridge protocol you have to realize the risk of holding these reped assets the original protocal gets hacked on ethereum you're going to deal with impact assets your tvl goes from 100 million to zero your

Revenue toly drops your existing treasury might drop to zero so you want to avoid all these risks and one of those risks is can I keep operating this myself without doing a massive migration and in our case you can so i' I'd like to maybe talk about the architecture little bit and and and start by just pointing out that Union is in fact it's it is a chain right so different from like succinct or or electron where there is no there is no intermediary chain that um uh that either generates or verifies proofs between the two chains you know the destination chain and the and the receiving chain um there there is a chain for Union what

is the role of that chain what does it do and like where does it sit in the transaction flow yeah we set out to do a similar model as we did with composable where we have a bridging Hub chain um to Route traffic um that is basically because as I said like even with the ZK live clients we still paying gas for IBC Channel updates so if you want to connect a th clal chains to ethereum you ideally don't want to do a th000 individual channels because for 99% that's still going to be too expensive to keep operational and we already have a lot of complaints kind of the IC space the relayer space about incentivization funding Etc so massively increasing thatb is is not a good approach if you want to go to market in the next two

years um another reason we chose that is because we could apply those optimizations um that we uh did with com BLS what it does add is a almost majority assumption on the union chain itself um so the model that we designed I think you read about this in the white paper was that basically as long as you can still create a ZK proof for the chains that you're connected to you you can basically do ZK fraud proofs so your hot path goes through the virtual fast Union channel that uses Comm BLS um with the ability to uh show that fraud has occurred in the case the entire Union validator set itself has become compromised and the chain is in a Fubar State and switch to the slower Channel um in this case the only bridging risk

that you have is the IBC rate limit times uh the amount of seconds it takes to generate the ZK proof for the counterparty chains and so this usually results in about IBC rate limit times 5 minutes which is a very acceptable bridging risk now you've produced it from 300 million to 15K or whatever you find acceptable with the rate limits okay so so so Union the chain like the chain serves to to do proof verification uh essentially for for tokens moving or messages moving between between chains if that chain were to disappear um someone else could spin up infrastructure to do this this is where that fallback mechanism uh yeah exactly

so basically we make use of stuff like proxy light clients multihop routing so two chains connecting Union that want to interact with ethereum or later R other chains it is like a channel directly to that chain itself with a secure fallback mechanism in case the intermediate chain gets into foar States for us that's also why we early on started exploring shared security uh for us became really interesting to see if Union could be partially secured by mesh partially by IG layer because obviously then you're secured by the two major ecosystems that you're bridging in between which makes a lot of sense overall if your underly interest assumption is on these two ecosystems being honest um we' definitely chosen a solution that's

somewhere in between a trustless and uh like a NPC validator set right that we do add the chain in between so I refer to it as stress minimized um but for us at least that's one that basically gets you to a really good product in time that also opens up new products that require this hybrid model so if you look at rips for example that have maybe a complicated Fork Cho rule or Integrations necessary with a DST Network you're probably not going to be able to do all of that inside the light flight uh chain uh contract itself and so you probably want like an L1 to actually be properly able to integrate with those infr layers cool um so when um when you're talking about the

the chain itself so we mentioned this a little bit while you talk about Comet BLS uh which is um another implementation of tendermint that uses BLS signatures instead of ecdsa right can you describe like what that like why did you do this and and I guess my other question when I was reading the the paper is um would would other Cosmos chains benefit from switching to Comet BLS would they is there like some some um unintended sort of like benefits to using that over you know regular tender or is this something that basically is only useful in the case of uh of union or some edge cases no it's it's uh I won't say drop in replacement because

the tenin tech is very monolitic at the moment but there's a lot of effort being done by the ICF and strange love to make this a lot more modular so we're kind of playing into this and probably will be kind of providing P BLS as a plugin once that rewies as CS uh it's more efficient for regular IBC between tening chains as well uh so you already benefit immediately from using this you get less State grow less block space allocated to light client verification um it works really well for browser light clients too so overall like you get a much better consensus that's like truly geared for interoperability and we have some additional changes to this as well so the way we lay out like the storage treats themselves different the hashing

algorithms we use are different all geared towards making verification a lot more efficient and cheaper to do um ideally like we'd actually love if all Cal chain were to switch to Comm BLS or you could Upstream common BLS into tournament the problem is upgrading is a consensus breaking change so if osmosis were to do this they would need to coordinate this with validators there would need to be a way to keep uh existing IBC channels live so there would need to be a specification for how to upgrade IBC channels to a completely different consensus across chains um alternatively you can close them all uh do the upgrades reopen them but that would mean that you have different denoms so a all hold headache to deal with so all of the reasons why these

changes really aren't present in ten minutes as well is because once you're in production it's almost impossible to get this in place for brand new chains do talk with us it's a a super interesting way especially if you want to have that direct channel to ethereum yourself C can you explain then why like why BLS signatures are important in this context taex or why they they're Superior or better suited for interoperability than ecdsa like specifically when talking with ethereum yeah they basically just allow for aggregating the signatures themselves so if you and I both have a BLS key and we both sign exactly the same data you can kind of visualize that we uh just add both our signatures to each other so if

your signatures number three minus number four that becomes seven and if we do the same operation with our public Keys We add them together then that new public key that we derive matches the addition of the signatures and this kind of unlocks this idea that you can scale to 100,000 200,000 300,000 validators because you simply add all of their public Keys together and all of their signatures and then it's the same as if you were verifying a single validator Network so with Comm BLS that's why like in our benchmarks we skill so well basically uh they uh reduce to a single validator Network if you want to do the bare minimum verification after aggregation on top of that uh here there's more Z friendly so doing these

irrigation operations in a ZK circuit is relatively efficient there's pre-c compiles available on ethereum to perform these operations as well so I think like a regular like BLS verifying ethereum is going to outshine uh like regular signature verification after about 25 signatures on the top of my head which means that for almost all CL out there it's a more efficient implementation to do so okay so so practically speaking if we just bring this back down to to the chain right so the the the the validators on the Chain are are performing um uh are checking are checking the these these ZK proofs and so you want to have an honest majority

that that is signing this proof uh attesting that the proof is valid and so by having a way to aggregate those signatures into one signal signature it's much easier and much quicker to verify that final signature rather than having to do this sort of like in series or or in parallel or verifying like maybe 25 or how however many end signatures all like in in a batch approximately yeah so if you were to like write a ZK circuit um the like Baseline like if you start just tinkering around with do cons sens verification is you're just going to verify 100 signatures in a list and and if you were to do that for regular tend what you'd realize is that your map to curve operation is going to be different

for every single validator so you can't actually do that once in the circuit you need to do that 100 times then you're going to realize that the signature algorithm that you're using it's actually not ZK friendly at all so it has a really large Baseline cost for every validator you add you're going to be paying that Baseline cost which is going to dominate uh what you're doing same for basically destructuring the storage proofs that you're using because when you do block header verification you do use storage proof tech there as well to verify that the current set of validators at this height is like the signatures you could access to and with BLS you avoid a lot of these issues and so by by using that you basically only do one aggregation uh verification and then you get a really fast proof that

you can generate um if you then want to fall back to Native verification as well you basically benefit from exactly the same benefits right like native verification just regular go and code doing live client stuff is the same as the CK surface in their business logic what's a storage proof and how is it used by Union so I've heard this term before but I'm not like exactly sure what it is I mean the term is like used very widely in the Space Storage proof State proof uh but basically the block header contains Merkel trees that uh point to different data so one of the trees it will contain is the validator routs which contains the kind of current set of validators and how much voting Powers happen to them this is just a

simple hash but by providing a path of hashes to the actual validator you can show that validator is part of the current set so when you're doing this uh ZK proof you basically provide for 100 validators their inclusion proofs and that way in the circuit you can show at block number 10 these are the 100 validators that are going to be signing now if this operation is quite expensive uh doing these inclusion proofs then you're going to be spending a lot of proving time just showing that at this block these are the validators on top of that these storage proofs inclusion proofs are used in icq so when you do these interesting queries they're used in uh the sending of packets so they're Baseline for isis2 so you see them

everywhere where you're in inter uh and that's why it's so important to try to really optimize this part of your pipeline cool okay and so one of the other things that I learned here is that uh through reading your your docs is that BLS enables um much much larger validator sets specifically in the context of tendermint which usually um is optimized for like a a small is number of validators that's like 150 to 200 validators uh after that it starts um it starts being inefficient H how does BLS enable um having lots more validators and one of the one would be the Practical

benefits yeah so um basically that's same aggregation mechanism that you can use for aggregating p keys and signatures you can use that to shart a validator so the network might think that there are only 128 validators validating this chain but each validator can be one 10 100 a thousand validators that are each aggregating their BLS signatures before submitting the final vote to the chain itself and so this is really interesting for parties like obal or other decentralized validator networks because they don't NE need to change the core consensus to still implement this sharding now if you combine that with kind of what you're looking for with I layer then you can

end up with these hyb type models where perhaps you got validator notes that don't verify all transactions but only prevent double signing from happening so let's say let's say 10 validators cooperate five of them verify the full block five of them only verify the double signing now you've got five that run a much more lightweight process they might be running like as an IG layer module itself an AVS module and because you don't want to have too high infrastructure requirements for running those and so then you can start actually going above 150 validators to scaling it to a much larger set where perhaps in case of validators dropping out or becoming unresponsive in these smaller pools other notes picking up their work as well without the main chain being

aware that it's actually going on um you can only do this um with BLS signatures unless you want to like adjust the core consensus of a chain so in the case of Union for example if a third party protocol would want to come along and implement this then they wouldn't necessarily need to like talk with us at all or make any changes or do a governance proposal they could implement this mechanism in full themselves and I think it's super interesting as a solution to kind of what IC is struggling with uh where you don't really want to like have every single validator that's running an Aton validator spin up entirely new server for a new chain they're validating something that polked really well where like new power chains can be permissionless added and you don't

actually need to interact with the polad do validator set to have your blocks be verified as well and ICS really needs like a type of technology that can bring this as well lower the basically just allot exponential scalability instead of linear okay now that's interesting so I mean you could also do this with like I mean this is sort of like a threshold signature scheme or it's similar right CU I think obal I don't know if Obel did they use BLS or they use like some ecsa signatures I think they use Thal signatures um I would say like it's similar the problem with current threshold signature algorithms which works well if only sh int validators but they uh don't scale that well if you go over the set because I think for the

current state-ofthe-art algorithms for every party that you add to the set for the signing itself it's like um um o o squ complexity but don't take my word for it I would need to read a back on this for the current state of the Arts but so it doesn't skill us nicely while with BLS signatures it's once again that simple Edition that you're doing which is why ethereum chose for BLS instead of perels okay very cool wow I'm learning a lot about BLS here this is this is great U so so part of the the architecture there there's two other parts of the architecture that's mentioned in the docs one is is gwa uh which which gave me some really bad memories of my uh my my dorm my dorm

uh when I was a student in north of France and living in the gaha residence which was a terrible terrible place to live uh but but also a great mathematician um and and also um and also Voyager um which is the the relayer um architecture so yeah which one which one's it best to start with I think I already touched upon GW can kind of GRA that so that's that's the magic sauce right like a common BLS is very well designed and the test Nets as well like operational about pass I think 900k blocks maybe million even um but uh like the real magic is can you actually translate that into Z proes and you can

generate them quickly and with G we can do that U right now it's a CPU back end uh V1 sb1 we run that on I think right now at 324 machine so relatively pricey but still very feasible to to buy I think a um thread Ripper is about 3K at the moment um with V2 it's actually reable on m2s we have an experimental GPU back end as well which increases the performance even further so that's really where kind of the lowlevel coding stuff comes into in the end for people that want to run it it's just a grpc server so deploy another server make sure it's on the correct Hardware you get an endpoint that can generate the CK proofs for you that you use in your IBC

relayer and Voyager was like very nice to build a little bit mathematical nice optimizations works very nice in it sandbox flawlessly voyagers where we deal with the nitty-gritty stuff of inability and relaying um when you IBC relay between tenament based chains you've got single finality which means when you submit a transaction you know you've handled the packet when you interact with ethereum there's sometimes short running Forks there's a gas price increases there's a lot of stuff that can go wrong while even though you submitted the IBC packet and a note said that they accepted it you might even see it in the block two blocks later it might be disappeared if it was on a fork and now you need to resubmit it so

that's where we basically integrate with the ethereum rpcs where we deal with all of the Integrity of retri forks Etc um it's a competitor to Hermes and the gayer Brit and rust we chose not to like continue working with the her code base itself because at the time they were already planning or even undergoing a rewrite um so that has been in a lot of flux at the time itself um and the entire model of Hermes is very different Hermes is very stateful if you're a programmer that does a lot of like uh RPC mixing IO coding kind of realize how difficult it is to figure out a real estate for application while Voyager is stateless and built on the message queue

so that's much more similar for the technical people out there as if it's an internal CF Q where we have like a stream of messages which are processed by individual workers handled retried stored etc for us has been really beneficial so far it was much much easier to debug than the go relay or Hermes which um when we start developing U most ethereum uh RPC implementations barely supported the beacon chain had broken RPC and points uh we encountered so many internal books working on that so having a really good relayer to catch all issues was crucial so so the relayer I think I read somewhere you said in your talk that

that Voyager um was it can connect to any counterparty chain so I guess I guess like from from the from the cosmos this is where always were like it gets it gets funy for me so like from the cosmos perspective I understand then like what um like where the relayer sits with regard ards to the chain um when messages are sent to ethereum what's happening there like who's running the the relayer infrastructure there to receive those messages and to send them to the ethereum chain and and also from the perspective of of Union um are you deploying sort of general

purpose um contracts that are meant to send and receive messages or are applications integrating Union directly within their sort of like stack uh to to perform this function yeah so um obviously like the union team will be running an IBC relayer like we're doing a test net right now we're doing that for our next demo um that that's part of maintaining the product we're not really optimizing the infra that we're rning it on so the way we're designing this is that a large portion of the transaction fees go to the relayer that actually submits the uh transfers to other chains which means you create a market Dynamic right because every single relayer like an me Searcher going to them to sit on packets

that still need to be sent out do a computation how much can I earn from this at some point they going to buy the bullet and actually transfer this batch of messages to take that fee if you have only the one party doing it they'll basically be quite unoptimized and wait a relatively long period of time to capture this fee while if you have multiple parties looking at this obviously they're going to start competing with each other because the one that just first gets the p and this going to cve our philosophy where we want to create a system where there's a really healthy Market dynamic because a healthy Market Dynamic Self optimizes for me as a like developer as well if I see a protocol and I think I can make some money here by developing stuff that's the biggest draw for me to

actually develop on a protocol it's not a uh third party Grant it's not the fact that they've got an SDK in 10 different languages it's the idea that there's an opportunity to enter this market and out compete all the players so Parts like cisc or the de Foundation can integrate their proving markets so more professional ZK proof generators can basically make use of this um the technically the way we designed is that the proving and relaying are separate components although if you want to capture the maximum amount of Revenue you could earn here you want to run both ideally like in the next couple of years we'd love to see parties like skip protocol evolve into parties that both

Capture Me protect from me deal with proof gener ation packet relaying Etc because all of that is the same problem right it's ordering transactions to generate revenue and cross domain muv is already an issue for parts like and quazar and I think it's only going to become both a bigger issue but also a way to actually fund bridging transfers if you can make some money of relaying a bridging transfer you can make them feel as for the end user um and you can incentivize Rel layers by doing that and for current parties like different validators that run them we think voy is going to be quite popular uh because instead of relaying between just two chains you can relay between many chains at the same time and it's really fitted

for us to add support for new ecosystems on top some ecosystems we been talking about talks with Avalanche we're looking at different Ro of ecosystems and kind of observing right now after we launch ethereum what's going to be the next one and basically expand this stack so our infrastructure providers we're looking for ways to make them more money by serving the infrastructure needs okay but I don't I mean maybe I didn't I didn't quite understand here but like go going back to uh applications on ethereum um are are are Rel layers just I mean are are they interacting with a contract there that that is built by by Union or

how how are they interacting with the chain yeah yeah so ethereum will have a contract that verifies Lifeline States and it accept CK proofs and that's the first ENT the relayer so the relayer needs to obtain the ZK proof from somewhere can be that they're running the hardware themselves can be that they integrate with a proving Market can be that this is a relayer that has specific hardware fpgas and so generates its proofs even faster than the rest maybe they have a uh massive GPU um and so they're basically the ones that submit these proofs first every single time and with this proof they can basically clear out the entire package PE itself so once you look like proofs all those packets can be sent as well and for each of

these packets you earn a fee some are BPS fees some are message based fees um and so for relaying it's it's a raise to the finish for generating CQ approv because then you open up a que for yourself to submit all of these packets um then contracts and protocols themselves they integrate with these contracts that they uh that the relays interact with so basically they fill up this queue such that uh the PS are going to be sent on the other side Rel layers can then decide are they just going to forward every single packet forwarding every single packet from ethereum to Cosmos makes sense because Cosmos gas fees are low it's quite cheap so probably the moment the packet is available you just want to send it out um for cers 2 ethereum because ethereum is slightly more expensive you probably

want some logic to say I need to at least make 30% on this that's where the market or or or is this transaction even valid like I mean yeah but yeah if I see that you're waiting on a 30% profit I'm just going to set mine on 29% and uh get the profit every single time so that's a market Dynamic but for end protocols integrating with it it's an onchain world it's smart contracts that they're integrating with okay yeah that's clear um you said something early I want to come back to and that is that with Union you don't require um Union will not require governance proposals to set up um to set up relays between between chains C can you maybe just explain like

why that is like why why would Union not have to run uh have governance proposals because I mean Union will have to set up relays with all the cosmos chains or at least all the IBC chains correct yeah so so in essence like for the security of the system you don't need to do a governance proposal to open these channels like that should be permissionless should be just accomplished you can think of model where perhaps they need to put down a certain stake or pay a fe for the bites that it costs to put the St on chain but the union L1 is basically block space pure allocated for this right it's not like osmosis which wants to allocate trading Union is specialized to this what's really cool is kind of we're not going to have that in rv1 but this

once you start thinking about this world where all bridging is light clim based and IBC based is uh can you do some type of aggregated CK proof right right now you got this liquidity fragmentation because you have like the diamond uh transfer problem if you start at one chain you do the same as two different chains you end up in the final one they're going to be a different asset can you generate a CK proof to show that these two intermediate chains have the same light flying State and handled the assets correctly because if that's the case there's really no need on this final chain to have them as two separate assets inste you're allowed to Mint to a single asset and that's kind of this like future of permissions interoperability we want to head into is where like the routing starts to matter

less they creates space for parts like skip protocol to do routing efficiently Plus that means as an end user you really stop caring about like how you transfer in and out of things and instead just a network you send it out into so this just I mean this just solves the fungibility problem so so essentially you're saying that um if you can prove that the origin of the token uh comes from the same origin right that like but but that the the the intermediary chains have the same like client verification then the destination token is the same I mean why wouldn't that be not be the case currently for for Cosmos tokens I mean like you're

moving atom across uh like osmosis and Juno to I don't know like agoric right um why why would not not be is that the technical implementation issue or is there yeah exactly because right now it adds an increased complexity in how much block space you elevate for verification because now for not just the intermediate tops but for the origins your also start doing verification so you basically create direct IBC channels to everything but because with like ZK proofs you can do a bigger proof longer computation time but same verification cost you basically can do what you ideally want to do an IBC channel to every single chain from every single chain for the same cost as just having

one single IBC Channel open um it's like I think in the experimental specs like if you look back in the history on GitHub of um that that's cool no that's that's really

interesting um does does packet for does packet forward middleware somehow play a role in this as well and um I mean do if you solve the the fungibility problem this way then you don't really need packet forward middleware anymore exactly it's Technic competing products packet forward middleware puts an increased trust assumption on the chain that you're used for uh hopping at the time right and which like to be honest like we don't really see a lot of chains have 2third of their validator set bitions right so I still consider it quite a small risk overall but from like a technical mathematical perspective it's an incomplete solution and really what you want and if you're interested

in this you should read on spre modules which is an experimental Tech that they theorized in polka do ecosystem you kind of want a spre module which is part of the block transition function that kind of lives outside consent so could live on the atom hub for example or they to generate a ZK proof or that's like really tied down in how to process this so that you don't need to trust the intermediate chain to handle packet forward middleware correctly so I could of course like if I write my own chain and have that be the middle points between uh two other chains I could forward my chain code and just make back and forward middleware misbehave and the two connecting chains right now wouldn't be aware of that and you end up with some issues here and which is why like

you can't introduce f ibility on this and so if you remove those issues you open up visibility so in the end like this whole pability issue in IBC is an original design right they had to launch it they had to make it secure and by doing this like Dome system you make it secure but less usable and by adding these new security Primitives we can get it to a level where then we can actually introduce visibility cool what's the what do you think is the the timeline to having uh perfect fungibility um between tokens that have you know passed through different uh chains yeah so um like after our initial launch that's going to be the primary focus for us and that's combined with uh

bridging new networks bridging new networks is kind of application of tech we've already built um well this uh hecking on disability issue is kind of the next Hing Grill to add on top of this um I think myself with now s CK T being present uh Comm BLS being there with we use Nar ourself but in general like ZK sdks ZK Tech itself has progressed a lot I'm really hoping to see that in 2024 um I'm kind of like hoping to be honest that we didn't start uh the boom market yet with Celestia and dydx launching and that actually all those Builders have another full year to implement this so that when we get the next influx of users all of this can

actually be ready that would be Terri so I do want to talk about Celestia and and and dydx and and uh the next Cosmos bull cycle I mean specifically I think I want to talk about Celestia because I like to understand how uh Union what role Union plays there but but before before we go there well actually you know let's let's let's dive into that a little bit and we can talk about Shar security a little bit later so yeah in the context of Celestia um which layer of the stack does uh does Union inter intervene I mean do applications have to integrate directly with Union or does interruptibility happen at the lower layer of the

stack so a let's let's start out by seeing like modu development as a s solution where you need to pick like different Legos to put together data availability is there because you can verify SEC proof right you can you can show that you you did something for gain a rollup without ever showing people the original transactions which means that that if the centralized sequencer were to disappear you wouldn't be able to start up a new sequencer by someone else um so Celestia solves this issue by basically being able to provide you proof to say the original data that you need to Kickstart a new sequencer is available with us and that's how you prevent like data with holding attacks and such so

this one building block and another building block is extra verification itself so SL plays in and say like if you're able to verify yourself someone else will be able to boot up a new sequencer to continue verification in case you disappear they don't make assumptions on are you able to verify yourself are you able to um do you use like are Z rollup or optimistic rollup or whatever they're just they're saying if you need to promise that you're able to get some data we provide it as a rer or app chain you're basically providing this like verification guarantee right like you define your rules on if you have the data how can other parties verify that you are transitioning blocks correctly which is light Line Tech Cosmos Tech SEC Ro Tech Etc then where

interoperability really comes in is saying okay can we take these models that different teams are providing how to verify their state and can we tie them together as a baseline to allow them to communicate with each other now in Ideal World everyone be on exactly the same consensus uh because that would make our lives easier in reality they're not they're all very different types of consensus with different gues it's an interoperability protocol that's what you're most focused on with integrating it another portion is why we kind of discussed it's pre-module parts right like if we can verify their consensus can we also verify part of how they handle transactions because if we know that they handle bridging transactions correctly and they don't um misappropriate back for middleware ETC

then they can become a permissions part of this cluster so Union really wants to be like another building block that you can pick when you're building a new rollup or when you're protocol on a rollup where you go I'm going to pick I da or Celestia for my da I'm going to pick IBC with Union for my interoperability Union supports H step consensus nice that's what I'm building on um and so you kind of connect all of this together and then you launch your chain and for me what I want to see then is obviously that you just start producing blocks and can immediately send funds to ethereum to osmosis to injective Etc right and basically immediately be integr this St that's the dream right so yeah that's that's uh I mean that would be ideal

right you just like launch a chain and you can just send tokens between any ecosystem uh so you you mentioned I a little bit and um so yeah I was talking to the electron team early this week and and um they they they sort of open my eyes to this really interesting use case um which which this sort of enables is being able to leverage ethereum stake uh for for Cosmos chain so essentially being able to use interchain security across ethereum and Cosmos and that just like blew my mind um because I didn't know that this was possible right and didn't know that that uh that ZK enabled

this so I'd like you to explain how that works and what are the what are the potential ramifications for Cosmos you know I think if we take a step back a little bit like Cosmos Ali Co Cosmos alignment is like a dividing issue in the space and some people think that Cosmos should align with ethereum there's a few people think that Cosmos should align with Bitcoin I've heard some people say that right um but uh and other those think that like Cosmos just remain its own sort of sovereign ecosystem that doesn't align with anything and that uh derives value and sort of like grows its value by by building great applications in particularly you know being like a governance hub for the for the ecosystem

or the broader blockchain ecosystem um so yeah I'm curious to think to to to hear like what you think this unlocks and what it enables for the cosmos ecosystem like if we were able to use e security yeah so um a I think it gives e kind of a kick and the buts to start building developing and upgrading right because uh this provides like ethereum alignment and basically what what at could provide Cosmos chains and which I think is a really strong proposition for new chains building ethereum is lot liquidity a lot of users um if on the tech perspective it can out compete atom itself then you get the best of all worlds you get your Cosmos CK chain you get to pick uh IG layer Asda but you get

to pick share security with ethereum and have close connection to that um for me like I'm not necessarily like a single chain H Hub Maxi like I don't necessarily think we're going to get one Hub alt together I don't think it's going to completely outcompete at them as well I do think it puts to question if like atam itself like is overvalued if this becomes an option right what they did with ethereum is is amazing they meant to create a network where you want to stake the token uh it's deflationary or very close to it uh you're willing to pay the fees because there's enough value on the Chain itself and now with IG layer you can even buy more functionality there and hopefully actually benefit from a disproportion

set of security than you're paying for um with etham at the moment we kind of fig figured out that security portion but we didn't figure out the rest of the fly there which I think is the biggest uh kind of handicap it has right now where you question like why do you all have is the only income you're going to get from chains that security if there's other options out there that's going to be an issue for you um on the other hand I think atam is much better positioned to capitalize on being the forr here basically doing all this Tech first and doing it better right like it's already built for that it's designed for that but with this unlock um well we saw like Stu like Atomic IBC right which is a great candidate for capturing cost

domain M for intense settlement Etc which I think building that on top of IG layer is going to take many more years before we going to see anything like that arrive uh when I was exploring i l myself like this the specialized operators the avss ETC they were all very much early stage you could run security you can run security from I layer but not dis proportion set yet what you can limit is still relatively what you can build is still relatively limited so I don't think we're going to see that out compete yet for Union like what's interesting is to see if we can leverage both at the same time and I think that might be really interesting for a lot of chains connecting is basically not take the gamble on either ecosystem but be able to move with each

ecosystem as they technically progress um I do think that uh with the new kind of uh designs for atom and atomic IBC is going to be like an really interesting counterparty to ig layer and for me at least more competition is better right like so kind of stopped a bit of their development or slowed down and quazer arrived and then all of a sudden they went aping again and now they they got massive tvl growth in the bare markets so putting I layer as potential competitor to at can be a really really good way to uh push forward the technical limitations yeah and I I I just real realiz I I didn't ask you about this uh but in your cosmoverse talk you you were

talking about how um Union will also enable Bitcoin transfers into IBC how does that work yeah I'm actually really bed about bit VM because this is some research Miss and I did like five months ago where we had like a similar design for verifying CK proofs on bitcoin Etc and basically trm I don't know if you saw that on Twitter you us should check this out it's kind of smart on bitcoin it's still like computationally uh way too expensive to run but basically allows for general purpose programming on bitcoin and we had a simplified version specific for like IBC transfers which is going to be initially like the next ecosystem we

were going to do uh after ethereum now noric has been doing a great job babyon as well so we might reconsider this and kind of see if rollups are actually more of an interesting Target and just publish BTC IBC as a a uh research paper before we pursue it but at least the way I see it as kind of an INT protocol and as a like inability cluster you're are valued uh in the assets that you give your protocols access to right you do a partnership with deck with certain protocols what new assets can you bring in that the users will want to use and Bitcoin is immensely interesting because there's obviously so much techn liquidity there right assets that are not earning any Revenue that could be

doing something at this time obviously there's like rep BTC and Trust BTC and ibtc rep BTC is managed by company R if something goes wrong there then we have a massive issue which given Murphy's Law like anything you mention like will go wrong it will bite you in DS at some points I BTC is collateralized by other assets so it's like quite Capital inefficient because you're not technically like bridging over Bitcoin you're locking it you're looking an additional amount equal to the value of BTC and you're minting a derivative that represents that value so it's not Capital efficient so you're not really going to touch it too much and Trust BC kind of has those same issues where you need to like load up vaults to actually be able to maintain these Bitcoin ballets themselves so for me at least

IBC is a really cool solution to solving this and actually get Capital efficiency and then the question of course remains can we convince the Bitcoin crowd to actually do something with their coins or are they just going to refuse to participate in Defi and sit on it forever um really depends we've spoken with loads uh half of them is willing and the other half is uh gonna basically sit on it until they die and say one Bitcoin is always one Bitcoin I'll never spend it yeah I'm looking at this paper I mean I I haven't read it but it's like what's impressive here is that it's only eight pages so basically the same length as the Bitcoin wi paper so um I'll have to read this later um so so but but in the case of Union like how how will

those uh transfers work specifically are like are the validators holding some sort sort of a multi or like what what's the so so so basically what we're doing is kind of like implementing the mechanism that bit VM uses to uh verify proofs on the Bitcoin sites you probably wouldn't get many Channel support probably just be a single channel that you can do so you're kind of getting close to IBC semantics but not in full but right acceptable enough and and then on the other side going from Bitcoin to other networks what you'll be doing is basically verifying proof of work in ZK proof and then the amount of work to the security level because Bitcoin of course never finalizes right um there can always be competing chain but luckily it's so expensive to mind Bitcoin that

if you wait for a sufficient amount of confirmations you can be certain that there's not going to be a competing chain out there and so that would be fundamental mechanism powering uh doing these transfers and and with tech like bit VF you basically can do arbitrary logic lock up of tokens uh consensus upgrades validate rotations Etc so that that's super interesting space a bit VMS limitations like if you read the paper um so it's like really early on for us we didn't need to do general purpose programming right for us we we're looking for something way simpler to uh bills um so that's like super interest too I think that's going to take a while by the way like building on bitcoin is an absolute pain in the ass uh very different stack again um all the stuff

we explored um we have a design for doing cardano that was more of a meme thing we built in the weekend um one of our lead developers is a big fan of hll and so we were like can we do IBC to the ghost chain still a lot of value lock there to be honest Tech very interesting so could add a lot of value to existing CMOS chains right they're looking to broaden their products and the user base yeah this is cool thanks for sharing this I'm gonna read this paper later um so what what's the um what's on the road map like what you guys just sort of came out of Stealth at at uh um at cosmoverse like I remember seeing your deck circulating sometime in

July but then like we were organizing nebular Summit and it totally like went to the to to the side and then and then you guys like popped out of cosmoverse and uh and announced this this demo and sort of came out steth so um what's what's next for you guys what's on the road map and um where can people like get involved and start um thinking about building on Union yeah so so the next thing we have for the community to share is uh transfers so I have on my PC here right now we were doing some final RPC hardening today um so hopefully we're actually going to be publishing that tomorrow that will includes like uh integrating metam mask with Union test net acquiring test unit

tokens um and basically uh like the first play around with everything that's going to be like a bit scared too because our initial demo R like Ping Pong but that doesn't really like stress test the rpcs right and it doesn't expose too much about the endpoints we running so someone wants to try dsing our test net or my cor validate notes then they can do that from the next demo on um and then really focus on public test net um right now we've basically decided on the first 10 validators that were're on boarding um with public test that we're immediately rolling out com blv2 with the uh like even more efficient proving itself so we're hoping to actually bootstrap that Network work either end of this week or next week

what's kind of U stopping us from doing at this week is our CTO is getting married this Friday so actually the entire team is here in the Netherlands on the Retreats and ready to to celebrate his wedding so uh that might like delay our timeline by a week for testnet um and from that moment on teams can start building so we've been working a lot with quazer ideating on their ethereum product sets on the icq that they build and basically getting them ready to immediately leverage this product um we've been talking with loads of teams from the ecosystem um teams I'm superh for bar chain injective uh I'm actually really hoping to build something cool when we launch with goric and IST I think that's going to be a really interesting opportunity because

the way I see it is this is going to be a chance for us to kind of reshow the cosmos ecosystem to ethereum and get in an influx of users and tvl H so it has to be like a combination of different chains and different products all working together over I C uh with skip with gfm with 42 with squids to show like a unified experience across These Chains instead of this fragmented charted uh experience I think if we can do that well then there can be a massive influx for TV and revenue for almost all CHS super exciting uh Carell thanks so much for coming on the podcast today and and sharing all this knowledge and uh yeah I'm really looking forward to

seeing um all this like really Innovative stuff I mean I think think I think a lot of this infrastructure that you're building unlocks so many use cases but also just improves user experience all around I mean like just the fungibility aspect like that just blows my mind but the the ability to be able to use um you know ethereum stake uh to SEC your Cosmos that's like a massive unlock for the space and you know token transfers like or like message passing that that that it in itself being able to do that in a trust minimized and permissionless way is going to be massive for the ecosystem so we'll be following uh very closely as you guys uh continue to build and ship per thank you so much thank you