Union: Interoperability Accelerated | Karel

Transcript

I do think that we're going into this era soon also where kind of apps will almost be like like pult original vision of like having on demand rollups with par chains and Par threats I think that's something really cool that we could move into in the Moder space right now that's very much underexplored at the moment nothing said on zerox Research is a recommendation to buy or sell Securities or tokens this podcast for informational purposes only and any views expressed by anyone on the show are solely our opinions not Financial advice pachio Ryan and our guests May hold positions in the company's funds or projects discussed what's up guys

welcome back to another episode of zerox research as a disclaimer today's episode is sponsored by Union I'm joined by Carell the founder and a core contributor at Union um thanks for coming on Carell yeah thanks so much for having me uh before we get started do you mind running over what union is and what you guys are building yeah of course course so Union is an interoperability and settlement layer so for kind of the regular user what this means is again a project that connects different blockchains what we focused on is a being really fast in doing this so messages and transfers get sent really quickly between blockchains but as well as being extremely secure and decentralized so we don't rely on like oracles or some service that we are running that could potentially be hacked

by any group and that's especially important if you're doing bridging that makes sense and what's the motivation behind it what apart from not being reliant on other protocols what are the problems you guys are trying to solve yeah so a obviously everyone's kind of building like app chains app specific rollups they're following in hyper liquids footsteps of if you have like your own environment you can build a really cool product so this idea that like the L2 Centric road map of ethereum is kind of what everyone is doing in crypto is very real um with that you get a majorly complex like architecture for how these blockchains need to interact and communicate with each other extremely knowing for users like you want to do bridging um but also actually really annoying for developers because you don't want to like rebuild an entire ecosystem you want to rely on like

already products that are on someone else's blockchain but if you actually look at like the current landscape there's not really like I would say like bridging apis that would work if you contract does like a thousand Bridge calls every minute to interact with the decks on another chain there's like no infrastructure really that handles that all of the infrastructure that we have right now is to kind of like most Bridge protocols do like a th Bridge operations per per day most on a really busy day right like it's almost like the post that's being sent uh so that was what we were trying to like solve have like that first Pine that is indeed kind of suitable for high traffic uh interoperability the other thing and that's more like really philosophical that I was seeing personally is we spend so much time like in the early days of

crypto designing blockchains that were like secure thinking of like Byzantine fall tolerance and such if you look at lot of intro protocols they're like multi sick to relayer kind of setup um and if we build like The Wider blockchain landscape around this idea that everything is connected by just a bunch of multi6 then we lose that portion of decentralization and security right like we've got a bunch of middlemen that are basically just running a single server in the US subject to all regulations and such so we wanted something that even if I personally as like the founder of Union decide to pull the plug like the network itself could not be pulled by me uh so our second biggest objective to

achieve perfect that makes sense um and how does it achieve or aim to achieve this objectives what does the backend architecture look like so basically in designing this the first thing like if you're not going to use like a multi or Oracle or something means that you need different like security mechanism to verify that a transfer occurred uh in our case we use light clients for that and like clients are kind of like the the best that you can do at the moment basically what it means is like we gener these certain mathematical proofs about like validator sets or the consensus algorithms of the different chains that we connect to so in the case of ethereum that is tracking the sying committee in the case of Bitcoin that's basically verifying the P that's occurring um and uh allowing anyone to like provide those

proofs so it's not just that the union team runs like a relayer and approver no like we have this network of solvers that basically monitor different chains that have like transfers going in and out of them and they will see hey there's this batch of transfers that could go to this other chain let me generate approve right now and settle these transfers because with light clients are smart contracts kind of guarantee that you cannot like create fraudulent proofs anyone can like boot up a relayer or a solver right now and start serving traffic and that is what keeps it so decentralized because basically if there's like traffic going on anyone can make money with it and as long as you can make money with it someone on Earth will be willing to like boot up a relayer and either compete

against existing ones or keep serving the network uh so there's no like Reliance necessarily on us having like a server somewhere securely like facilitating all the transfers right now and actually like if Union Labs at some point disappears as long as people are using Union there's always the room for relayer to be operating on top of that we have our L1 our L1 access is proof aggregation layer for all of the work that occurs so that is what Rel layers connect to and use to orchestrates and over that we generate one big ckp that has another like quite nice advantage to it um because we don't only like aggregate multiple transfers in one single ckp we aggregate multiple chains in each ckp um and that gives us a

really nice gas profile compared to for example XLR or layer zero where they don't aggregate over multiple chains and so what you see is um it doesn't matter for Union if you have let's say 10 transfers going from ethereum to Solana or one transfer from barain to to Solana one from ethereum to Solana one from um osmosis to salana like the aggregation behavior is exactly the same and the verification cost stays the same and that skill allows you to get like really low gas prices so if you have about 20 transfers occurring at the same time Union becomes about as cheap as across like slightly more expensive but I think it's only like 5K gas more expensive and that's actually quite amazing with all

of the cryptography happening under the hoood the zero knowledge proofs like at not even that many transfers to be honest it already becomes like one of the most gas efficient protocols out there um so that's a really cool uh behavior that actually is because we chose to be this decentralized and secure it's coming from the fact that we chose CK yeah that is cool um and talking about ZK one thing you guys mentioned is that you have a ZK powered consensus verification can you run over what that um exactly entails yeah so this ties into those light clients right and light clients already known to be like the most secure way to do bridging verification but the downside is light clients usually are on chain a lot more expensive um for the

more technical people like the light clients basically is a reimplementation of the consensus algorithm of a specific chain so you might reimplement kind of tendermint in solidity um and you have the relayer provide like the next block the smart contract runs through the logic and verifies yeah and these like this is still the uh the correct block um you can really imagine this gets really expensive right you're going to spend millions of gas on each light CLI update and so the bridge transfers just become way too expensive so the key solution here is actually generating a zkp for your uh consensus update instead of doing it in the contract itself you have a circuit that performs all this

computation cool thing is now like the cost stay is constant so if a network has 100 validators a thousand or a million doesn't really matter because the ckp has a constant cost associated with it you always know like a life client update is 220k gas uh give or take um and the cool thing with ckps of course is you can aggregate them arbitrarily right like you can combine multiple into new ones for those that are familiar with like the cryptography behind this and so it has a really good scaling Behavior once you can get into like serving thousands of blockchains right like it still stays the same constant cost I think I all like interal providers right now Union is the only one that has that behavior like as you

start adding more chains there's no additional cost to it interesting how does that batching or I guess aggregation mechanism um work uh more specifically yeah so I'm afraid like I'm not our lead cryptographer so I can't go too deep into those details but basically what we do at the moment is we actually generate snarks and uh snarks you can aggregate those arbitrarily and still verify them as a snark uh the input size does increase of course if you were to do something like that but uh in the end like you still get a major gas benefits we have a couple of different modes actually in the architecture too so one of our partners that we work with is aligned layer what

they do is ckp at a station um but depending on like the type of connection that you open through Union you can choose to use aign layer as well and then you aggregate them when they at a station service you can use nibra um and then instead it's actually properly like cryptographically aggregated what we see here happening is that there's a latency trade of occurring so basically just generating the zkp settling it directly on chain low is latency and so a solver will choose to do that if there's a lot of money to be made with that specific uh batch of transfers if people have set like really low fees in their slider they're cheaping out that day then a solver basically will feel secure that no other solver will go with the fast

path and so we'll just submit the zkp to be aggregated with Alliance or nebra um weight 30 extra seconds and uh save massively in gas and it can do this for multiple ckps right it can decide like this one batch just doesn't have enough fees at all but maybe three batches in total have enough fees uh collectively to be settled that way so there a really nice dynamic system like if ethereum gas prices suddenly Spike massively then basically solvers will decide to increase transfer Times by a minute or two to leverage aggregation mechanisms to still be able to settle these transfers that makes sense and in terms of have you guys run analysis on what you think um solver fees will or like

what solvers will demand or do you think often we hear that with intents for example that it's going to be a race to the bottom do you think it's going to be a similar case um yeah I think on the one end raise to the bottom that is doable for solver to still operate so we specifically chose this design because if I'm going to be honest solvers are usually Rich sophisticated market makers so I wasn't looking to give them a way to make insane amounts of money I was looking for a way to create a system that would cost optimized for the user so ideally commoditize for the solvers until they make just enough that's basically the best price a user can ever get and that ties into this vision of like we want to be in a world where tens of thousands of bridge operations are

happening like every minute between thousands of blockchains and for that you want it to be like really cheap in the end instead of extremely expensive so have a system that can do high volume and make money of that instead of high value transactions but only a few that makes sense and um I guess how does the comet BLS work how's it different to the comet bft and why is it different yeah so for kind of our aggregation chain we decided to redo a big portion of comet bft and and it has to do with that we include the consensus of this relay chain into the final ckp as well um so we made a few design choices to make it much more ZK friendly overall One is using BLS signatures really good for

like reduced State growth over time really good for verification um as well as we figured out some cool tricks with like ethereum pre- compiles that actually made like verifying R zkps even cheaper by going down that approach other things we Implement is uh we use mimc hashing instead of regular sha 256 U we actually have like a slightly adjusted uh storage drive format and the cool thing with this is like this all made like the prover even faster overall so um in the end I think right now like consumer Hardware can kind of generate approve in about 30 seconds uh maybe 20 by now and our biggest thing that we're working on right now is GPU acceleration for this that'll be the biggest win I

think that we can get out of this Tech at the moment uh and so that to be honest puts like the theoretical latency for Union at around well right now 20 seconds on consumer hardware and with GPU acceleration probably two to four seconds which means that we're mainly waiting on other chains and not on ourselves which is technically the best you can do as a interro provider is if you're like faster than uh the the chains that you connect and that's what we to be on this kind of see right now on testnet we did a I think the fastest transf for we facilitated was between stri and bar chain and that took about 23 24 seconds in total with regard to that if a chain has faster block times

if a chain is just faster overall does that um also lower your latency yeah with that it does need to have like um faster finality that's what matters for us but what you see right now is that is kind of the case like hyper liquid and suchar they all finalize really quickly too so with this like single slot fast finality chains with like up one second block times that's actually what I think is the future for like all blockchains out there because that just provides everyone the best ux including us like we love that on the back ends with engineering team that makes sense and um I guess lastly on the architecture side how does um galoa work what what is it what does it exactly do yeah so our original like

cryptographic St we implemented that ourselves about two years ago like the vzer um using narc so that's still the kind of I won't say Legacy ZK stxs because you actually build the most performance ZK stxs with this but these days everyone is kind of using sp1 risk zero um maybe Bas and such but when you handw write the circuits at the moment you still get the highest performance and that's what we did specifically because we didn't need to do like a very general compute we knew exactly what our problem space was um narc uh at the moment like is still what we're running and allows us to also Endeavor into GPU acceleration and all of that we fold it into galwa which is the like prover that

we use that's compatible with FMA with cindry the different Pro backends can at the moment serve for us long term I'm not sure if we're going to stick with that we have a few experimental projects right now to actually switch away to a new Pro backend um the main reason for that actually is that there's just this like obviously cber an explosion of of new blockchains out there with different consensus mechanisms out there and so we're moving at the moment to make it easier for other ecosystems to make themselves Union compatible instead of us writing the circuit writing the cryptographic backends to do these light line proofs make it easy for third party developers to actually write this deploy the code and start generating proofs and

for that you to be honest want to have them be able to use vanilla rust no circuits but uh basically just do like the same code that they write in their smart contracts or their regular backends uh so for that we're looking at potentially using a zkm that makes sense um in terms of integrating other uh chains you said you want them to start handling that but what does the process look like on your end right now um and I guess more specifically let's say like bar chain or a Bitcoin L2 um what would it look like for these versus Solon a hyper liquid yeah um so at the moment all are like relatively similar um basically the

big thing to do is that light clients the code that generates the zkp that's the uh hardest portion at the moment for new developers coming in to code out and that requires like the most I would say fundamental blockchain knowledge as well right that requires understanding the underlying consensus like what does this chain specifically do funny enough we always joke about this like everything turns out to kind of be a reimplementation of tender mint with a couple of changes to it um especially hyper liquid for example but Solana is actually the big outlier here that is very different from all other blockchains because it chooses to uh for example not meriz State at all which for us actually makes it a bit more

challenging because now you cannot easily generate like storage proofs anymore which is what in the end at the core uh we do we generate storage proofs to secure these different asset transfers um for let's say if you're building a new Bitcoin L2 using the cosmos SDK at the moment we actually just have like contract Stacks that you can immediately deploy so for 99% of developers out there it's actually like go through the tutorial use our deployer CI um and and you're good to go because we have so many like pre-configuration at the moment that all just kind of works out of the book interesting um I guess what are some of the tradeoffs that come with Union as opposed to other interoperability

protocols yeah so um one thing that's really cool I think at the moment moment is how we beat like other General message passing Bridges right now is Union is not based on a hardcoded set of confirmations which XLR and layer zero are so XLR for specific chain might wait for 30 confirmations but if a chain finalizes let's say every uh 15 blocks that means that on average XLR overshoots by 15 blocks waiting for too many confirmations then is theoretically possible sorry theoretically necessary Union always like hits that exact theoretical one where it's safe to do the bridge operation like always mathematically that's really cool the

downside is intent based bridges are technically faster because intent based Bridges can YOLO and say like we don't even wait for the one where you theoretically need to wait for for it to be secure we just take the reor risk and Union at the moment like we choose not to take that reor risk because obviously we're all like smart contract based and you can't handle such a risk in the system you want to maintain one-on-one backing uh which means that for chains where you need to wait quite a long time for finality you uh are faster off with an intent based Bridge downside with an intent based Bridge of course is like not all assets are supported you cannot do General message passing Etc so uh Union in that case does support them really well um other downsides I would say at the moment but I think that's

kind of an upside is um indeed that because Union is so decentralized uh you cannot really shut Union down we do do have contracts to do like circuit breaking rate limiting for specific assets but that's more up to the asset issuers themselves to decide like what is the bridging behavior that I want by default like Union will just allow any traffic to always keep on going and we don't like Blacklist or Whit list specific users interesting that is good I think that's also a positive as opposed to a negative to not be able to Blacklist and just like have um circuit breaks Etc just to slow stuff down if needed yeah I think it's better Cas layer is like open for anyone to use and then you

just leave like developers building on top of you to add their own custom Behavior yeah how do you see um in intents and general messaging General messaging protocols um play over the next few years or over the next because like you said I personally use intents because if I'm bridging I just Bridge big asset to Big asset and it's much faster but I know there are risks involved how do you see that Chang here um yeah so I like the final like solution to be honest is like intense at some point go away and everything is ZK based light client based and we can just mint any asset because that means that solvers need to no longer manage inventory anywhere if we're in this

world for like every chain is like sub one second finality right they're all insanely fast then there's really like no reason to to operate over intents anymore um cheaper for users to be honest easier for Developers ERS to reason about too because right now with intents in your smart contract code you kind of have to handle like can this actually be sent over right like what's the asset IDE that I'm dealing with you need to like store supported asset lists and they always turn out to be basically usdc and maybe two or three more but that's kind of it that we can do intent based um so the final solution really is like something that's based on proofs and the cool thing there is like you can have different Bridge providers still all use the same proving mechanism basically have it all be block hash

based and that way you can basically aggregate the block hashes they provide if they're like in unison about like what's the the hash of the origin chain then you can allow all of them to mint freely so that kind of makes Bridge providers more like security providers in the end and aggregation layers and not really um asset custodians anymore that would be like the best Final Solution uh for crypto that's kind of what we're working towards but uh that solution like is still like at least two years away I think Fair makes sense uh one more thing this is kind of related to the earlier section but you mentioned that Solana makes it difficult because they don't really have State hashes versus that's what you mer hash they don't meriz it um versus that's what you guys really need

can you um I guess like my line of reasoning is on ethereum you can just take that and you know that it's correct that's the good state but on Solana how do you access the good State or the verified State yeah exactly so for those listening basically the way ethereum and a lot of blockchains work is if you have like the block header with the block hash and you know that that one is correct you can create what we call Storage proofs which are these really tiny proofs to show that this smart contract has these values in it or that this transaction previously was successful um and that's really useful for example to prove that there's uh 1K USD in this pool or in this fault and that's kind of how Bridge providers work

because what you do is you do a proof that someone deposited one 1K in a vault and that means that now you can like subtract 1K from another Vault on another chain um now because salana doesn't meriz State you cannot generate these tiny proofs that these events have occurred um what it forces you to do actually is to meriz state in the SL smart contract itself so you don't rely on the notes doing this work for you you actually perform this in the contract there you can be clever with it two so you can use RSA accumulators which are like a different cryptographic principle that kind of allows you to do the same generate like inclusion proofs as well um and so like actually all of the logic that normally was handled by the blockchain itself you're now doing

inside the smart contract and so that again like if you're implementing this from scratch it requires you to just understand a little bit better what the tools are available to you luckily for us like Solana is obviously like really fast and um they're like if you're transaction can be paralyzed and doesn't like touch any states that's uh contended with then it's cheap if you were doing merization in contract on ethereum you'd be paying quite a lot but on salana in all in practice actually don't pay that much for it interesting I assume it's still um heavy on the computation side or no it well heavy like it it turns out to still be just a few cents so really not

that much um but definitely on the heavier side uh it's I think something that misses but the thing is it's part of sana's philosophy right like it's also hard to set a note and just keep up with the actual validators um but light lines normally actually make this much easier for others to keep up because you have to like process less data to know your data is still valid so I'm hoping that salana at some point adds these things on top of the uh road map uh no right now they're partnership with suin and search that they're a bit more open to actually making like the base layer more provable interesting um what can uniquely be built on Union that can't be built on um other General messaging protocols yeah so one thing that I think

is extremely cool at the moment and this ties a bit into like how we saw how cool intents are and what they enable you right now if you build a protocol on top of Union you basically use like our packets API which is very much similar to like using TCP like packet comes in and such but you can actually opt into to have your packet be intent F delivered as well um by basically adding like one extra entry point point to your smart contract and solvers will kind of automatically figure out these specific like data packets I can use the intense route to fill them provide assets myself um and for these I need to actually generate a proof which you as a developer like don't need to implement two different protocols you're not

actually implementing like intents on top of a message passing Bridge you're not importing like two different API standards they're basically for certain entry points for example swaps or um uh uh providing LP saying this can be provided by someone else and then using our acknowledge mechanism to repay the solver so we saw someone for example Implement a cross chain Dex in kind of like 150 lines of code because they realized like hey because you have this like solver kind of transparently built into the system you get access to whatever asset you want um and I think that's kind of like outside almost the ZK portion that we do and the

cryptography that we do just to really cool effect of how we designed like the core protocol itself to be like to have all the lessons from like layer Z V2 from across from exlar and combine all of them in just a really cool API to work with and what we see people build right now with that so we have the fluon team who's combining that with FH to do uh private intents one I think is really cool about that is obviously like if you do everything intentful you always get the worst price right silver is always going to front on you sandwi with you Etc so the whole objective is like art can we like indeed like built an L2 using FH and try to keep this like

private for as long as possible make it harder for solvers to actually uh front from the end user uh that's a really cool one uh another team right now settle X they're building a confidential clearing layer together with arum uh so that basically has this property right now like solvers are rebal ing across various networks exchanges as well right like exchanges like binance need to make sure that they have assets on every single chain available for people to withdraw but anyone can monitor this at the moment they can see that these positions are being placed and so that leaks like certain strategic info right like you know where outflows are going ahead of time and if you think about it like in in trfi uh clearing and uh rebalancing is is always private like

you don't let your competitors know what the positions are that you're taking um so by combining like Union and a confidential compute you can build a layer that basically does all of this rebalancing uh completely privately the intent comment about people front running you that's another um tradeoff for them I think I I noticed it recently is that it's anything you put on the Chain if there's a like you said these are sophisticated market makers it makes sense that they would want to front run you um how do you we already kind of touched up on this but how do you see a modularity change over the next few years yes so I think we're going to see more high performance mod chains that do quite a lot of functionality so maybe

rely on da still for SL child another the chain but I think still like have a lot of the stack actually in their own notes because that just allows you to build like a really high performance environment at the moment um I do think that we're going into this era soon also where kind of apps will almost be like like pol's original vision of like having OnDemand rollups with par chains and Par threats I think that's something really cool that we could move into in the modular space right now that's very much underexplored at the moment and that's something that uh rup as a service providers and I mean interro providers really need to jump in on uh if indeed like the experience for

deploying your app is as simple as super base right where in like 20 seconds you have like a postgress instant your dashboard and you can start building some cool stuff that's really the same with setting up your own like high performance L2 um for that like all of the peripherals need to come into place really nicely right now like you do have some Bridge support right like you could get I think like relay included um or hyperlane but there you still have the issue that you're connected to like one or two networks when you set this up um especially like within all of these different Ro that people spawn you still see like very limited connectivity so I think that's like the big thing that needs to be solved before we actually see these like swarm of microservice

blockchain succeed and I think until then it's still going to be a little bit monolithic that makes sense and what would you say are the um the key issues not in just modularity but also interoperability like what is something that you think you need to fix over the next one year yeah I think in to be honest it's both fees and speed um we all of seen tweets from certain interprotocol saying like how shape this one route was but to be honest if you look at many routes you're still SP pending like 90 bucks to do a medium-sized transfer uh sure like the fastest they did that day was 50 seconds but in reality usually you're still waiting uh five to six minutes uh I think right now some people might say

like yeah but do you need to you don't do it that often and that again it's reminiscent of like uh 30 years ago online shopping where people say yeah but how often do you do online shopping it's fine waiting 30 minutes for bank transfer right like Well turns out to actually just be like fundamentally limiting an entire Market sector and if indeed like you could do an online payment in one second people do more and and shops become more successful so I think it's very much the same with like blockchain and Ma thesis and having multiple chains out there people kind of Wonder like do we need the second one is the advantage big enough but if interrup is like extremely fast extremely cheap then as a user you don't get annoyed by it at all and then it's super obvious to go your own route and build your own L2

for your app yeah that makes sense and on top of that what are some key things that you guys are focused like what should we expect from Union this year yeah so uh basically expect main net uh this year uh test net 9 is uh coming out extremely soon that's our final test net has all of our latest features in it our new proving back end um that also means that we're close to the conclusion of our uh trst setup ceremony so we've been running one of the largest um ceremonies right now to generate the verification keys for CK circuit so uh we've had like thousands of people participate now and the actual payload I think is about 600 gabyt I think with that we we've found it as the largest one at the moment um

and so that's like actually the the first bit that people can use to contribute is participating in that ceremony getting in the queue and contributing some RNG to ensure that our underlying algorithm is secure perfect that's exciting and uh before we end it do you want to tell our you uh our listeners where they should had to to find out more about Union yeah just go to our website union. build and uh check out our Twitter Union build uh that's where I do most of my ideation and thinking um obviously join our Discord uh participate uh next couple of weeks is kind of a new moment with our next test net uh for users to become active and as well for uh people

to interact with the projects building on top of us like uh Asher fluon and settle X kind of the first era of truly modular multi-chain projects fantastic this was great Carl thank you for coming on thank you so much have a nice day [Music]