Episode 226: Interoperability with Axelar

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week i catch up with sergey gorbanov from axillar we revisit the topic of bridges and chat about what led him to work on interoperability we then talk about the problems that axelr is trying to solve how it compares to existing solutions and what's next for the project this is one in a series of bridge and interoperability episodes

that i plan to do for the next few months so i hope you enjoy before we kick off i want to just highlight the zk jobs board for you if you are looking to jump into zk professionally i want to remind you to head over to the zk jobs board to find job posts from some of the top teams working in zk find the next project or team you want to work with i also want to encourage teams who are hiring to use the jobs board to find your next hires we have great teams like elio anoma and mina already there so be sure to add your jobs as well you should also check out our link tree we have put together a list of a lot of the channels that we have we are adding to it but if you want to jump into zk this is

probably a good place to start so now tanya the podcast producer will tell you a little bit about this week's sponsor today's episode is sponsored by polygon zero polygon zero is a layer two scaling solution for ethereum what separates polygon zero from other zk scaling solutions is the power of planky ii a groundbreaking prover system which generates zk proofs faster than any other existing tech plancky 2 supports efficient recursive proof generation allowing polygon 0 to scale horizontally meaning the throughput of the protocol is not limited by the weakest nodes on the network but only by the total compute available visit polygon.technology to learn more about polygon zero and other polygon solutions so thank you again polygon zero now here

is anna's interview with xlr [Music] today i'm chatting with sergey gorbanov from xlr welcome to the show sergey hey anna great being here i do want to share this the zk validator is an investor in xlr and what is interesting about uh when we actually did that investment for me at least that was i think the first time i saw a project that talked about this like multi-asset bridging technology and i know you don't call yourself a bridge so we'll get to the difference there but it back then like or when i first heard about it it was for me the first time i even had like really heard that concept um i know since then there's been a few more that have kind of like entered the

space with a similar thing i want to get into sort of the competitive landscape and just generally i'm actually doing like multiple episodes right now on these types of solutions so i'm planning on doing like one a month so i'm very very excited to be digging into this one to axler especially since i think this will be the first time i revisit since we spoke like some time ago what about you where are you coming from originally like what ecosystem did you start from good so i guess i started from a technologist ecosystem how about that okay in a cryptographer did you come from math then you came more from academia potentially so i did a lot of things i would say you know prior to getting to blockchain

full-time i originally was very passionate about security and uh kind of practical security um so kind of concentrated on that during my undergrad i loved networking so i worked on software defined networking we're building like distributed controllers kind of 10 12 years ago with a couple of professors and students at the university of toronto and then i wanted to study formal cryptography right so i went to grad school you know did my phd at mit um and then by the end of it i was a little bit bored from doing again pure theoretical research so i wanted to do something more applied started to play with blockchains you know some of the

early designs behind our grand and um with the silvio and a couple other students we helped to uh take that project from you know research to the market and uh taking uh the platform live well wait so you were one of the early al goran folks then you like were there like were you part of that original team then so yeah originally the project started at me and silvio doing some research at mit um you know when i was finished in my grad school then i joined the university of waterloo for a couple of years so um the research around our ground continued so sylvia involved a lot of other students kind of a faculty to help design uh continue shaping the protocol i think it's been through like four or five iterations and uh you know eventually we got together

as a small technical team in early i believe 2018 um that's when initial funding was attracted to the project and um yeah we kind of took that to the market what was the impetus to break out of there like you'd been working in this project you know now you're doing something that i guess could be used together with what the some of the work you did maybe but yeah what what prompted the move so as we're building our grant and as we uh shipped it to the market one of the first questions that kept on coming up is how do we bootstrap that ecosystem right and bootstrapping really came to bring in liquidity bring in users bring in uh some of the existing applications

to the outground platform right and in the early days when you ship something technically better without a community that's a very hard problem to solve and so we were looking for different ways to connect our grant with other ecosystems you know nothing that we could really apply uh and connected that easily and um at the same time you know myself and my co-founder yogas we saw a lot of other just amazing projects being developed in parallel right like cosmos and big fans like polka dot right like avalanche solana and near and the list goes on everybody had their own take on consensus everybody had their own take of what smart contracts should look like and so it was clear to us that if the ecosystem continues to grow all those ecosystems are going to have

different applications going to have users and they're all going to have to talk to each other one day and uh you know we wanted to bring this connectivity to continue accelerating the uh ecosystem and and help compose all these different applications i mean you just mentioned cosmos though and like cosmos has ibc kind of i think it's a pretty early part of the project like i think that was announced quite early on why wouldn't you have sort of pursued something like that like a glue between networks like ibc i mean so obviously i think is a great protocol right uh and i think it works quite well it's very technically hard to apply to different consensus mechanisms so you know practically for us like raogram to

apply something like ibc we would have to pretty much rewrite most of the consensus because it works very differently you have kind of randomized selection that allows validators to be selected from you know anybody in the in the world in some sense and so ibc requires you to have very effective and efficient like like client implementations that need to be communicating across all of the different chains that you want to interact with right and so if you want to interact with you know cosmos ecosystem with you know solana with you know avalanche you're talking about different consensus mechanisms that have to exchange light lines you're talking about potentially different smart contract languages that need to support these light client implementations and then you have to

maintain these implementations every time you want to do an upgrade and then you have to you know recreate these connections all the time so while you know from a security perspective i think it's a it's a it's a great protocol and has a lot of advantages as an engineer and you know especially some of the background around networking and things like that i just knew that the the friction that was going to continue uh we're going to continue seeing to scale these protocols that being said i think you know we'll see what happens right i think it's a um i mean i think it's still early we're still building some of these kind of core pipes and connectivity tissues and learning what works what doesn't okay so let's talk then about this emergence then of axillar so i guess you left the org started a new company what

did you set out to do at that beginning point i mean originally we were actually thinking about some simple applications that would be great to build cross chain so for instance things like taxes right decentralized exchanges great use case you know right now at that time when we were thinking about it things like union swap were coming to life right lots of traction so it was a very nice early use case for the blockchain ecosystem and we thought well it would be so much better if it's if it's cross-chain enabled right so being able to interact and swap assets from one ecosystem for an asset of another ecosystem um that would be amazing that's the dream yeah yeah but what we realized is that to

build an application like that you're going to have to roll out so much infrastructure in parallel right and then every single time you want to build an application that's cross chain enabled you're going to have to reinvent and reinvent this infrastructure and you know whatever you're doing and so it was clear that there was an infrastructure gap that just has to be solved with good robust communication protocols good robust you know relaying services fee services you know interoperability stacks and that would enable and empower thousands and millions of applications down the line um and you know to us that was super exciting i think right uh working on the infrastructure which we've been doing for years and at the same time applying it to scale

the whole ecosystem like what could you ask for more right cool but so let's talk about this question of of what you call yourselves because i think i've you've been lumped definitely together with bridges but i have heard i think even like a talk we we did like for the zkv privacy and cosmos like previous online event i think you you did mention this distinction you see yourselves not as a bridge technology tell me something about this distinction good so i think at the high level the way to think about axe solar is a it's a decentralized overlay network that's been designed so from the ground up to deliver web3 interoperability okay and so i think the basic core three properties that

we're trying to implement at the network transport layer are things like universal routing universal translation of messages as you go from like one ecosystem to another right and strong and robust security properties that um the ecosystem needs in order to uh facilitate cross-chain communication right and i think you know if you look at bridges most of them been should have rolled out as a one-off ad hoc solutions to solve a specific pain point like transfer an asset from one ecosystem to another and it sort of stops there right um and i think what we're trying to do is build uh kind of a series of mega highways in some sense that would enable

us to connect millions of chains down the line and that requires a very different you know engineering and infrastructure approach so you can continue scaling you sort of mentioned like routing messages so this is a distinction between xlr and some of the other bridge solutions last month we did an episode with gravity bridge and theirs is primarily token transfer we talked a bit about messaging and i wondered like when you say messages is this like dap calls like what what are those messages what do they look like and why are they are they more complicated to translate than like a straight up token transfer good great question so um when i say i guess messages yeah i'm really referring to an arbitrary payload that you can pass from one chain to another right

okay and that payload can really encode any information that you want to be executed okay a token transfer is a specific type of you know request that you can transfer from a source chain to a destination chain that request would include encode information like i locked my token here could you please mint you know the corresponding token on this other chain for me right to execute that request you need to you know finalize it on the source chain right you need to validate it you need to create a message that's posted on the destination chain that says that this request has actually been validated right so you can trust it and then you execute that call um so i think that's a very simple use case for interoperability but i think we want to

go beyond that in some sense what we want to do is we want to be kind of a a touring complete platform right where you can build applications that are just as rich and powerful as you were to build them on a single chain right so you can encode arbitrary payload nft transfer you know contract calls lending and borrowing applications and you can include that as an arbitrary payload and get you know the underlying infrastructure to securely deliver it to the destination chain and execute is that a harder ask is that like a harder engineering feat to actually make it so generalized and not just focused on that one use case of tokens um i mean i'm not sure if it's you know harder from an engineering perspective i

think it really requires you to think how to build the right system that scales right and how to build the right system that you know when new connections are added you know you're not creating like fragmentation across the ecosystem right um how do you enable like universal routing across all these functionalities so when a new chain is added you want to make sure that other changes are aware of the path from the source to the new destination chain without too much you know engineering or interaction on the back end um so so things like that and then you know definitely i would say it actually helps improve overall security right when you deconstruct serve the transport layer of interoperability

with application specific use cases that allows you to focus and say okay i don't care what the messages are i need that infrastructure to be as secure as possible and then layers above it in some sense get to decide what to do with that information are they they read those that info they actually decipher it so it sort of doesn't matter what's in there it's just past yeah and i think a good like analogy is like think about um how you build on a single chain right you have a consensus where you can you know deploy an arbitrary smart contract and you can write your instructions on top of it when validators execute and sequence consensus messages they just execute whatever you tell them right but the consensus itself is not

specific to the application i mean i think cosmos is a serve an exception right where the whole stack is designed where at the consensus layer you're validating you know the messages but uh you know a lot of the other platforms almost to incomplete in some sense right where the consensus just sequences the messages and creates the order and structure and then you can write an arbitrary logic on top of it and you're doing it that way you're kind of yeah you're not looking so deeply at the use case with the use of the actual data i mean for some use cases you can do more interesting things if you look at the message in the payload for token transfers you know in particular so we enabled um one of these properties that they call like translation between like ibc token transfers and evm token transfers where you actually have to

look at the message you know uh in order to encode one format to another but i think of those things as serve optimizations in some sense that allow you to do more at the network layer when it comes to some kinds of information though like do you need some sort of translator on either side like some blockchains just work quite differently so like are you acting as that translator between them or are you kind of do you need to have access to some almost like the lexicon of each one and then you're yeah doing some sort of translation great question so i think this is one of the core properties that you know axle network provides at the network layer right which is translation of different messages so you know as an example when

you uh send a message from a cosmos ecosystem that is let's say an idc token transfer then an actual network layer we can take that message we can translate it to a message that needs to be delivered to an evm chain and execute it there so the network serves as this translation layer now you're right that every ecosystem speaks its own sort of language right potentially has a smart contract so you have to have this translation and then you ask yourself a question where is this translation going to happen and there's pretty much two places where it can happen it either happens at the application logic right at the think of it like almost like at the smart contract close to your application right or it has to happen somewhere in

the transport network layer yeah one check here would like if you did it the first way would that be basically like almost like a light client on one side that does i don't know if it would be called a light client but some smart contract on one side that like gets it prepared in the format that you'd need on the other yeah exactly right uh either on the source on destination chain you have a smart contract that takes a message you know decodes it right deconstructs different payload and then interprets it and and and then parses that right so yeah that's if you want to do it almost like at the at the exit and entrance points right and so if we do some of this functionality you know at the network layer which allows us to be a lot more efficient a lot cheaper right

because you know you don't have to pay like huge gas costs for doing this translation layers and allows us to continue scaling and adding more routes in a uniform way while just composing and building on the network and effects of the translation right so it's not it's you change the model from having a peer wise translations and peerwise connections right to a model where everything is down at the route and transport layer it's served in a more uniform and cohesive fashion something that was highlighted kind of early on that was special about the work that axler was doing was the use of threshold cryptography is that what makes this more efficient or cheaper is that is that the secret sauce or is that used for some other reason i mean it's definitely one of the ways

right um i mean the way we designed the whole system is to allow us to continue you know scaling and making it cheaper and making it more efficient to deliver the messages right from one ecosystem to another and so the cryptography component is almost a plug-and-play component on top of the axle network right so we can plug in threshold we can plug in multi-sigs you know i think there's a we've done a lot of work on like standardization of bls signatures which i think is going to be you know quite powerful for uh some of the chains that will support you know bls uh and you can you kind of continue down the line and yeah all of those primitives they have their own trade-offs some of them were you know

efficient some of them are uh you know have non-interactive compression mechanisms some of them are interactive but the goal is to continue building the system and continue scaling it so that the translation the message pass and functionality can be cheaper and cheaper and cheaper over time and you know there's a whole set of optimizations you can uh you can do it threshold cryptography is definitely one of them but you just mentioned a few different types so you sort of mentioned the sort of multi-sig version but that makes me think it might be good for us to explore actually what is happening under the hood in axillary like are there a bunch of different pairs that you've created that are like moving between the two different two different chains or is it because when

you say that a multi-sig i think of the more primitive bridge bridges that do exist today which is like a multi-sig connecting two networks basically locking funds on one side to mint funds on the other and then burning them and bringing them back and unlocking them but axler doesn't do that right or is it like every single connection has you know a unique bridge format so let me kind of take a step back right and like let's let's talk through high level architecture right of the acceleration so the the high level architecture is the following um on different chains that we connected we have you know a notion of a gateway account right or a gateway smart contract think of it that way okay so

you know on an evm chains that's a solidity contract so what this contract exposes is a certain api that as an application you can call to deliver a message to a destination chain that you want to talk to okay now underneath all of this is the set of axler validators okay it's a it's a permissionless set of validators built around cosmos sdk where anybody can join and participate as a validator and so collectively what the validators do is that they observe these bridge accounts right and they observe messages that are posted to them once they see that a message is posted they execute a consensus to reliably you know verify that message

and then process it process it here means you know figure out where it needs to go so that's routed translation if it's a message it needs to be sent for an ibc chain you actually have to take it and translate it to an ibc packet for instance right and then uh sort of execution and the execution means that they collectively authorize a corresponding message to be marked at the destination gateway as approved by the actual network right and so this this last step can uh is where again like you need a consensus and a majority of the validators to approve that message and to do that you can you know you can have them either post their individual signatures or you can run you know threshold cryptography to generate

one signature collectively but it all serves the same purpose where the majority of validators reach a consensus and the threshold of them authorizes the message and now it gets it can be delivered to the destination you know chain or gateway and from there applications look at the gateway and say has axle uh approved this message right yes axle validators have approved the message the majority of them have you know co-signed it or posted individual signatures or one signature and then therefore i'm gonna go and execute it so that's the high level architecture so from an application perspective you now get to build your application on any chain that you like right you pick your home base what i call and from there you get to you know

interact with other chains by just talking to the gateway so you don't have to learn axle a stack you don't have to understand how relaying is done or anything you just uh talk to the gateway that's a regular you know solidity message or if you're in a cosmos chain you will talk like ibc and uh go from there when you talk about these validator sets it just made me think like is there mev on the br on these things as well is that also where the threshold cryptography could come in handy to like prevent because it's hidden a little bit i mean at least i know what is it threshold decryption used in the context of mev but i don't know if that's how you're thinking about it um that's not how we're thinking about it like here we're using the threshold signatures i guess for validation

but you are right that threshold cryptography can help you against other types of attacks right um you know you know sequence a set of messages without validators seen what the messages are like through a threshold decryption we actually have uh kind of a short paper comment on this shortly how to do it like more effectively with things like identity-based encryption uh you know you get to save a lot of traffic at the network layer and you know you can definitely do it and i think just having uh validators that have secret keys that you can do something uh cleverly with opens up all kinds of optimizations of this transport layer and better security down the line got it but back to mev do you are you worried about that is that something to

worry about am i worried about it uh i mean i am but it doesn't prevent me from sleeping at night in some sense it's okay so kind of stepping back right um to do the interoperability the right way it's actually very important to make sure that you don't have order dependence of the messages as you move in them around okay why would that be a problem good so the point is that whenever you're talking about very different environments 100 things can go wrong okay and then if you have a system that has synchronous communication across different hubs of connectivity then there's just so many places where

things can go wrong and break and you're going to be stuck without the system that that doesn't make progress so the right way of doing this is to design a system that in some sense has think of it um kind of a ip or udp level of message passing right so these are kind of a protocols on the on the internet where you don't have a lot of properties in terms of the ordering of those messages and how they arrive but on top of it you can build application specific protocols that have stronger properties right so for instance you can have protocols that have sequence numbers that only make sure that before the messages are played on the destination

chain they need to arrive at a certain sequence at the source chain right but all of that you can build as application layer protocols on top of the you know infrastructure that needs to remain robust and uh you know secure and so if you start mixing these things up which i think a lot of projects have been doing you're gonna run into all kinds of security issues and all kinds of you know fault tolerance uh problems that you're gonna have to deal with so you wanna keep it decoupled and then an application layer continue building this more sophisticated protocols almost like tcp on top of you know udpip type of things right or http which gives you encryption on top of unreliable unreliable communication and so that's at least the way i think it needs to be approached for the blockchain space

otherwise we're going to be mixing things up and run into the security issues for forever but i think what you're saying here is like that sort of mev would be like on either side of the like on either side of axler right like when you're moving funds from one chain to another you could be like front running or doing something i don't know what it is but could there be within xlr any issues like within the validator set like is there any benefit to a validator putting forward or like i guess it's hard and proof of stake but like is there is there any game that could be played on the validator side within axelr in this context um potentially i mean i have to think a little bit more but

those are the things that you can protect against you know using like threshold uh encryption and decryption techniques so i guess on the axle network i'm not too worried about this i'm more worried about now this multi-chain interaction right where you can have potential messages from different you know source chains that get you know uh delivered to the destination chain and you can have all kinds of you know race conditions between them and all kinds of md yeah so so i think that would be a lot more complicated to protect against than like on the axle network which i think is pretty straightforward got it what is the speed of this movement across in the case of xlr you sort of mentioned that it's fast but i'm wondering a direct multi-sig one-to-one like

chain to chain with a multi-sig on either side seems like it would be the fastest it might be expensive because you'd have to like unlock on one side especially if it's like ethereum with very high gas prices but is there any sort of delay or lag by going through this kind of system um i mean not not really right uh i mean i think and that's in that case kind of a the performance of multi-sig and you know kind of centralized implementations and the performance of axler will be pretty comparable because what you need to do you need to make sure the request on the source chain is finalized right so that's subject to the rules on the source chain um so if it has instant finality you know you wait let's say for five seconds right or for one second from there you

need this set of validators to process this message and you know translate it or execute it for the destination chain for the actual case you know it is built around the cosmos sdk so we have kind of five second block finality right so it's kind of pretty efficient and you can do things you know in an optimal way maybe you know in a couple blocks right um and then from there you just take the message and you post it on the destination chain and there you're subject to the you know latencies of the destination chain i think as all of the systems gonna be improved and like the latency go down um you're effectively adding you know another hop of a proof of stake network in the middle um which i think can be can be reduced and you know down the line definitely we're looking at kind of sub second

finalities so one question that came up on a previous episode to roon actually turin was supposed to be on this one but we moved it around and he unfortunately couldn't be here but i know i feel like he would ask this question which is say you're bridging some stable coins to i don't know solana or something and other bridging technologies other interoperable kind of pools are also bridging their own synthetic stable coin over to solana now you have like the same ones but i mean they have different names but you're kind of dealing with like the same underlying assets what are you thinking about with that because i know this is a space that people are kind of worried about like

potentially they're being i don't know if it's like just crazy arbitrage or if there's some attack somehow in there i'm curious to to get your thoughts on it yeah so i think it's a kind of a general problem of kind of fragmentation right and the liquidity fragmentation where you can have a situation where you have multiple assets that represent potentially the same thing right but they call differently they have different contract addresses and so on and so forth and they could have different liquidity different liquidity i guess could affect the price of course like would you almost be able to arbitrage sable coins even they should be all close to the same amount if one is actually how would that work if one was more rare if one was like had lower liquidity would its peg go

would it break upwards like a stable coin when you have lower liquidity i mean one of the examples is that if you uh then uses like in a dex pool right that users are going to have to tolerate more slippage right that's a very very simple kind of example one of our uh you know investors actually uh steve mckean he recently wrote an article of what happens when you have this liquidity fragmentation across ecosystems and what is the benefit of unifying it and and uh kind of merging it together right and so i think there he actually very clearly demonstrates some of this precise kind of a points where if you have different liquidity pools if they're smaller liquidity pools then users suffer at the end of the day right and so what you want to end up

having is like unifying them in some sense so there's a deeper pool and users can uh you know pay lower transaction fees and and have lower slippage right than this in this process so going back to your question um of liquidity fragmentation what do we think about it and uh you know what are some of the approaches to deal with it so a i think actually an important question that we'll be answering over the coming years as we get robust interoperability and more general message passing is whether an asset will go to a compute environment or a compute environment will come to assets okay so think of it this way you know right now we're moving you know tokens back and forth through the centralized bridges for the most part that we're moving assets right

but you can do it the other way around where you can have a program right a smart contract code and if you need to execute something with respect to these assets you make a call right to a chain where there's a deepest liquidity of this asset and then that call gets executed on that chain the state can be reflected there and the state can be propagated to other smart contract or you know other users on different chains and they all get a unified view of that um of that state so i think as we get robust interoperability stacks and as we get this general message passing this would be one of the questions and i think there are various trade-offs depending on how you design an application to either move an asset or move the compute closer to the asset

would it be like you'd have one high liquidity asset let's use like a it could maybe still be a synthetic but it's some sort of like for now it would be like a i don't know if there is already this x ud usd x us is that going to be yours by the way is it going to be the is that the name of that i think we're now adding a prefix axl to our okay excel not actually um let's call it like zk so it's like the zk usd okay so so this is theoretical so if there's a zk usd pool that's high like there's a lot of liquidity in there the idea here is that instead of trying to move it over to the different ecosystems you keep it there right like you'd keep it on that chain in that

format in the largest pool possible but if if you wanted to interact with it you'd send messages over this chain but that's not how it is right now like that's not how it works it's not because there's no interoperability right now across the ecosystems right there you know but right now what's happening is like you are sending the tokens around do you think that there will be that there will actually be a move towards just having the single pool on one chain that's like the is that is that sort of a prediction or is that something you're actually seeing movement towards because i think it's going the opposite direction right now right like right now tokens are getting sent all over and everyone's creating their own synthetic yeah so i do think it's going to get unified and abstracted away from the users okay and and i think there are

various ways of doing this i think you know i don't think i would predict that you know there's going to be one asset on you know on that chain and you have the deepest liquidity and it's no it's not available anywhere yet but i think depending on the use case and depending on the application one model or the other could make more sense right so so so let me give you like one example suppose you have an nft right on solana and you want to take a loan against it on avalanche okay so in that case maybe the loan that you want is in the most liquid stable coin on avalanche let's call it you know i don't know ust for example okay but your nft you know lives on you know on salinas so what you can do is you can

you know lock it in a contract on solana you can deliver a message to avalanche that says you know this nft has been locked this is the user's address please give a loan to this user against this nft this is the duration of the loan and like all the parameters and this is their address you don't have to transfer the asset the asset remains where it is but you just passed enough information and you obtain you know an asset that you deserve or desire on a different chain right so this is one example where you don't actually have to move it you just need to move sufficient information about it and i think for different use cases um you know we'll have to iterate like one by one where it makes

sense what i think the work you kind of described before suggested that it would be good if there was like deeper liquidity pools but like single assets of of one kind but yeah are there any strategies being taken by any networks to actually encourage that like could they ever block probably they can't but like like is there any way to i guess you could you could highlight one but like yeah is there any way to decide that there is only going to be one canonical version of something on a network yeah so there are actually a couple efforts towards that and i think fracks is a good example of a stable coin right and serve the way that it works is that the team has a canonical representation of racks on different chains and they

authorize different bridge providers right or interoperability providers to swap their tokens for the canonical representation of this asset right so in that case uh all the applications would only list and interact with this canonical representation and maybe they authorized serve one or two different paths of routing or delivery of those of those assets to that chain and i and i think that's definitely um you know one of the trends that we're starting to see right now is that unification um at a again like an application layer where you now trust uh effectively a multiple underlying interoperability stacks to to execute messages on your application specific contract that just mints this canonical representation of the asset

i'm wondering like how do you actually deploy axler onto new networks what is what is the action for you and maybe actually before we do that tell me where are you now i know i mean there was an announcement that you're kind of bringing adams to moonbeam i believe and i thought that was kind of crazy because it was for me at least the first time i'm like oh my god yeah there's actually it's there yeah we've heard about this for a while but but yeah so tell us where you are at and then i want to hear about like how to add more yeah so where we're at we effectively started the main network rollout which is a phase rollout where different functionality will go live on the network over the uh subsequent uh you know months um currently we connected i think something like 10 or 11 chains

through the axle network uh some ipc chains like uh you know cosmos hub um you know injective osmosis uh terra and then a bunch of evm chains um like avalanche like moon beam like ethereum like uh polygon and uh we enabled various kind of asset transfer use cases around the network so you can move things like ust you can move atom right which i was really excited about uh two different evm ecosystems and actually you know use it as a as an on-ramp to get back to cosmos right so now users can finally get the atom and go back to cosmos without having to go through a centralized exchange um and there are pools like on union swap right there are

pools on moonbeam that have been uh created so super excited about that and um in the coming months we're rolling out more functionalities so kind of the general message passing uh is going to go live over the coming weeks uh on the main network we have you know lots of applications that are that are building in this new environment and and uh kind of building their cross-chain applications and yeah the goal for us is to connect to you know mill and chains right millions of chains down the line and that requires a very thoughtful approach how to scale and how to scale horizontally and we'll we'll tell more about that in the coming months how do you actually set up on these new networks like what are you actually doing on each side are you thinking in pairs of two networks connecting between

like between two networks are you just like i'm we're adding a new network to our input and it can go anywhere after that great so never in paris i think you know the pairwise approach is you know again adds to this fragmentation and liquidity uh you know divergence so yes you on board to the axler ecosystem and from there you get connectivity to everything else that's been previously connected so huge networking effects and huge compounding effects right from that the way that it works is kind of depends on the ecosystem so we support multiple protocols right we have uh we support ibc because everything is around cosmos sdk so to set up you know ibc channel it's pretty straightforward like 10-15 minutes and you set up re-layers from there right similarly we've done everything almost as easy maybe a little

bit more complex but in a similar fashion to set up connections with evm chains right so to connect in a vm chain you would deploy a gateway contract there the validator is registered to vote on events from that chain so they would have to query like a light node or a node of that chain and then a sequence of commands needs to be executed on the axial network to to register that chain and uh kind of create this path to this new chain once that path is added the information can flow to all the other ecosystems that have been previously connected but who does that is that your team that's doing that or is that is that potentially like external participants who are like i want my chain to be also hooked up the

goal for us is to make this permission less right and so anybody will be able to do this for now you know it is a kind of a kind of governance right of the chain and like you know a number of folks have to authorize and kind of cosign the message to be executed on the network uh but yeah you know down the line the goal is that anybody will be able to to set these things up uh you'll be able to create a connection in an easy way and just talk with other ecosystems from there do you not end up with that problem this is like an old problem that i think i highlighted on the first interview i ever did with sunny it was about like what if one of these chains is super super toxic and it's not functioning correctly potentially like there's a consensus

what do they call it it's been captured so like 51 attack or 66 attack if it's proof of stake and like someone's just printing money using xlr to send these funds elsewhere to trade them how do you actually prevent that in a in a totally permissionless way like in a permissionless system rather i mean i think it's a great question so i think a couple answers to that so first of all i think one i think that's why it's important to understand that whenever we're talking about cross chain or interoperability minimizing the number of hops to get from a source to destination is critical okay right i think like a lot of people have this you know view that the blockchains are going to be connected in exactly the same way as

like internet and peer-to-peer networks right on the internet and peer-to-peer networks your packet takes you know 10 to 20 hops going from a source to a destination in a blockchain world that would mean you have to make you know you have to assume 20 networks i trust it as you pack it goes from a source to destination which is ridiculous right so i think minimizing the number of hubs uh is going to be a key point um and then two that's why you want to route and deliver your information through networks that have been designed to deal with situations like this right and dealing with situations like this you can have you know a number of on-chain and off-chain protocols in some sense okay so on-chain protocols if the change is malicious validators you know can go and

uh you know just disconnect their rpc endpoints right or disconnect their relayers and stop processing the message from that chain right you can also have uh kind of off chain governance where you know a committee has to come in and sign a message that pauses transfers in and out of that ecosystem right or pauses the state of that chain on all the other chains that it's been connected to right so having a place an interoperability network that deals with some of the situations is also quite important where you have these rules and you're thinking through them at some point these things will happen and uh you have to have again a combination of uh kind of on-chain and consensus logic that that you can uh deal with um and also off-chain i would

say kind of a mechanisms to to prevent some of these things yeah i mean the governance idea definitely sounds like you i mean it sounds like you could halt it but could you undo it not really right i guess no actually no you can't because they live on at this point like those assets may have traveled on to other networks that your validator set would have no control over yeah i mean the reality is that i think undoing any of these things would be you know i think pretty hard right it's it's no different than there is like an exploit in a smart contract on ethereum and somebody managed to steal funds and then they you know execute in five minutes and like route it to all the other taxes and centralize exchanges and try to get their money out right so i feel like

there's other places you could stop this i think some of these things will have to come kind of at an application or on an off-ramps in some sense right where you know as an application you can always uh kind of de-list an asset for instance right if you don't trust it anymore if we're talking about this canonical swapping right where multiple bridge providers potentially swap to a canonical representation you definitely can you know disconnect one of the paths um and again from there if it already traveled through uh the swapping mechanism then the applications and like on and off ramps will potentially have to deal with it and uh you know exclude the asset or some of the accounts so i i think it's no different than like you know a bug in a g5 application in

some sense that kind of similar strategies will have to be taken on axillar there's no it's not a smart contract platform itself but like would you ever imagine a dex living on you or does it do you always think of it as living on the sort of native chains um our goal is to empower developers to build anywhere they want right and that means like giving them tools and giving them apis to go and build on the best platform that's optimized for their use case and optimize for their needs we optimize axle network for interoperability right and for routing and for all these functionalities so you know i can't i guess predict the future but um i think yeah in some sense the network has been designed with the different goals in

mind right and uh our goal is to help scale the ecosystem and empower really developers to make the best choice for themselves and and i think through interoperability you get that a few weeks ago we had georgios on the show talking about foundry and sort of testing across and we like one of the topics was this multi-chain how do you test across them i don't know if this is like your problem but i'm wondering if you think about it because it's obviously like you're just providing the way to move between you're not necessarily saying that like chain a should be tested this way versus chain b but yeah i'm wondering like do you offer recommendations to teams who are trying to develop across two networks

i mean we're definitely going to provide you know examples right then like a framework um i think i i do think in some sense you know it is our responsibility right as a kind of the team that's doing a lot of work in the space to to help developers think about cross-chain the multi-chain world and and how to do these things uh the one of the key core differences is that everything becomes asynchronous communication all of a sudden right and so whenever you're dealing with asynchronous communication you have to think about what happens if the transaction doesn't go through on the destination chain right uh what happens if it gets reverted how do you deal with um kind of fallbacks and things like that so um i do think we're going to be adding you know examples i do think we'll will provide you know tests and

frameworks and way for the developers to think about it um and i think a big collaborate effort between our um you know developers and our team to to kind of get there cool i mean a big topic that i think has come up is this idea of just the like arbitrage or hacks actually like this is where this question kind of kind of comes from is given that there's been some very high profile very large problems specifically i mean i think wormholes was the largest and most recent and that was like a pure bailout it wasn't returned by the hacker sometimes you have these hacks where it's like it's a hack and it's like just kidding they gave it back but yeah in that case it wasn't so what are you thinking like are you not

worried that you could fall into the same trap do you feel like there's some sort of thing about your system that protects you better uh yeah so i think there have been actually more hacks right after the wormhole there was the the hack on the accident infinity blockchain right that i think like 600 million which is also a bridge yeah which was like a bridge again like a centralized bridge by you know ran by a couple folks so uh i i think this is one of the most important problems to solve right in some sense is building a secure infrastructure and i think i think a you do have to have a strong base for a decentralized protocol right so where again i think everything everything comes down to building

a kind of a permissionless system where anybody can support your protocol right anybody can participate having the code open source like people audited people inspecting it multiple participants gonna contribute into the security of the network collectively right in various formats either by running validators or looking through the code or you know testing things so i think that's critical and that's i think quite important and that's sort of the base of um you know what we're doing at axler and uh from there i think it's a it's a combination of you know the right designs right the right architecture the right engineering practices kind of code audits and being very thoughtful about everything along the way uh i think we're in the interoperability we're kind of in the same phase where we were about you know a year in d5 developments right

like people hacking left and right everybody rolling out their you know decks everybody rolling out their you know boring and landing application like everybody kind of races for the market and doesn't care too much and so i do think it could be done you know secure i do think it can be done uh well but it is kind of technically probably the hardest problem we're facing right now but that's what makes us excited every day so i'm also just curious about how you'd actually how do you incentivize like the token the validators actually in this context because it's not like people are using it for i'm just curious yeah like how are the fees working are you earning the fees from each network and then translating

them into the xlr token like yeah i'm just curious how that works yeah so the way we build the um you know at least some of the functionality around the token uh and the kind of general contract calls is that you always pay in one transaction on the source chain and then the set of services takes that transaction fee and then you know converts it to pay transaction fees icon accelerate network or on the destination chain i see and then you know if there are excess transaction fees they can go back to the community pool or the validators of the network and things like that but from a user perspective it's a it's super simple you pay you know in the asset that you want on the source chain um either flat fee or it's dynamically calculated and all

the other relay fees and the network process and fees are taken care of for you how are you bringing that into your because you're not a smart contract platform like you're you're a blockchain that just has that one native token i guess right and then just is doing the work of passing this information through itself um i mean there are multiple ways to bring it hey you know you can always have kind of a proxy contract on the on the source chains right where you know the funds are locked for the transaction fees but b uh we do actually treat the tokens as sort of almost like a first-class citizens through excel network right for the purpose that we want to be able to kind of translate them to ibc messages right that's one of

the examples so so you can actually have you know a representation of the tokens that you move in um certain minted on the actual network as a standard kind of cosmos denomination right then that that asset can be you know dispersed to the validators or used to subsidize all the other transaction fees so there are multiple ways you can deal with it on the source chain axle network destination chain it just kind of depends on the trade-offs which of the networks would you say you're closest to you've mentioned cosmos a bunch of times obviously ethereum but like would you say that your focus right now is at like looking at the cosmos ecosystem or yeah are you are you looking at other networks as well i mean i think definitely kind of given

the technology rollout i think and given what we've done it's super easy for us to unborn any cosmos chain and any evm chain right and almost like be one of the uh you know one of the hubs across those two ecosystems of evm chains and ibc chains and that's why we have kind of a you know half a dozen connections across each one of those but uh you know our goal is to be able to connect everybody right down the line and so we have a kind of a path how we expand and how how we grow the network you know cosmos to me you know in particular is uh i think i have a lot of respect for you know the ecosystem for the technology that's been built i think it's been one of the you know most valuable stacks i think where that

allowed people to innovate and definitely uh the community itself is very focused on interoperability right um and i think that's uh that what allows all these networks to sort of talk to one another and have compound effects and actually collaborate so i i really enjoy kind of working with the with the cosmos folks do you have plans to potentially deploy on osmosis soon so we actually submitted you know proposal right to the uh osmosis team for uh supporting uh kind of bridge functionality for them there have been a few other projects that have submitted the uh proposals i think you know the team has been evaluating and we had uh some kind of online uh panels that we yeah i saw that i really

liked that actually it was so interesting sunny was hosting and it was like three hours long but it was great it was like it's basically i'm doing something similar but like episode by episode spread out over months he did it in three hours so we'll link to that if people want to sort of front run me hear what who i'm going to interview next but anyway cool yeah so um yeah i think you know signing in the team i think they uh kind of publicly said that they think kind of axler approach is the best technologically what provides for osmosis uh it's still going to be a subject to a governance vote of by the osmosis community so we'll kind of wait and see uh what happens there what about polka dot like you just did the moonbeam deployment would you be interested in

anything else or did you do that primarily because it's like evm and it's something that you i mean i guess you have solidity contracts or you have some template that's somewhat easy to deploy to evm but yeah are you looking at other pair chains um yeah i think for us like polka dot ecosystem is like kind of forgetting the technical differences but i think uh very exciting because of the connectivity interoperability they have within their own uh you know ecosystem so that's why you know we connected with moonbeam there are a couple other big pair chains that i think have evm compatibility so kind of see what happens there and i think we'll also see how a lot of the the traffic is routed right is it going to be now you know suppose you go from a cosmos to uh polka dot right that's like ibc then

axle or axle to evm evm to you know another uh message format um within yeah i don't know if that's a message format actually but xcmp or what are they called oh yes yes yes so so yeah and then that message format and so you know i think it'll be quite interesting so one of the next steps for interoperability in general is would be to build this uh kind of protocols on top of the core pipes in some sense right to make it easy for all these end-to-end flows for the users and applications so i think um that would almost require like a service layer above the network to make some of those things easier and then multi-hop route and in particular and what about ethereum and the l2s this

is sort of my last kind of question on networks like yes they themselves are kind of like they have kind of mini bridges to uh the main chain often but yeah would you imagine bridging between the l2s oh for sure right and the you know i think a lot of them have asked for it and uh you know so we're connected to polygon right and i think we'll connect to you know a bunch of others as well i mean i think ethereum in some sense is becoming like another interoperability hub right where you've seen a lot of the applications you know migrate from the main chain to one of this uh you know l2s right or side chains and then ethereum what does ethereum get you it gets you you know security and message

relay and transport layer in some sense right so but it is a very expensive layer no matter what the transaction fees are there still uh ridiculous um you know we'll see what happens with the proof of stake migration in in that process you know have it axler as the proof of stake network already right allows you to do similar types of functionalities but uh in a in a much cheaper environment so i want to ask you a question about zero knowledge and sort of the actual zk as validity proof do you have ck in your stack anywhere or do you have plans to have it i mean not directly right indirectly zk is used like in some of the threshold

libraries right uh in threshold cryptography to prove certain statements um directly i think it would be quite interesting to use it potentially down the line again for the purpose of optimizing some of the uh validation you know semantics right and transaction sizes so instead of having you know validators compute either you know multisigs or threshold cryptography you can you can come up you can think of creating uh you know a zero knowledge or a proof right that the validators have validated a certain message on the source chain by the sort of consensus layer or you know in smart contracts and then relaying that proof to different chains that we connected with and then just validating it there

right so um i think that'll be quite interesting i think that would be definitely one of the directions to get us to you know many hundreds or even thousands of validators depending on how optimal you can make this zero knowledge or or proofs uh and how efficient you can make the validation logic right uh definitely something i think uh worth exploring and i think the the second direction which i'm super excited about is actually working with privacy preserving chains right yeah that was actually my next question i was about to ask you it's like what about the privacy part because we talked about a bit like the use of the cryptography but yeah yeah so super excited about that uh you know we actually just a couple of days ago announced the partnership with manta network right

which is on polka dot uh that uses some of the zero knowledge techniques to get uh privacy and um it's super exciting to me because it enables you to send information let's say to a privacy preserving chain almost like to you know a black box do some stuff with that information right like manipulate it process it compute it exchange it and then you can come out you know on the other end right and like continue sending your assets or your information to to other ecosystems so i think of the really exciting direction to see this privacy preserving chains connected to to other ecosystems would you ever be able to provide privacy within axillar

i mean i guess not really if it comes out the other end it's sort of public but yeah i don't know if you've been thinking about that maybe or between two privacy chains maybe is another way to think about it great question so i haven't thought about it too much um i mean again in some sense it's a proof-of-stake network like any other so if you wanted to apply privacy okay you have to do like research what other people have done uh kind of what works in the cosmos stack and with its um merkle tree implementations and and all that stuff and so you can definitely apply it if you wanted to and um you know i think we'll have to i'll have to think more yeah i mean i guess penumbra for cosmos sdk they're definitely working on some privacy things right something to check

out but um in terms of that going across i just sort of want to keep thinking that like so far right now if you wanted to move from one chain to another you basically have to de-cloak to do it right like you have to un-shield that's what we should be using cloaking like star trek why do we use shielding sorry just had a thought but anyway um the uh the like you'd have to basically unshield the asset and then ship it over like there's no way right now to keep it private into the bridge because i guess you need to know the amounts and where it comes from and like there's probably too much info that isn't yet made you can't yet make private so

yeah right now there is no way i mean i can think of a couple ways of of doing it so for instance you know if axel network supports kind of a mpc protocols right then you can have a protocol where instead of actually you know unshielding your transaction right maybe you communicate uh you share a secret key to the actual validators that allows them to privately decrypt the transaction amongst themselves nobody has the transaction to clear but it's a secret shared across all of the validators do there are necessary functions to validate it right and compute a message that needs to be posted on the destination chain uh in a shielded way

right so uh i can definitely see you know theoretically how this would work um yeah practically and engineering-wise i think it'll be quite an interesting quite interesting interesting project to do cool i do have one last question which is a little bit about the competitive landscape we started with that like i mentioned that that like you know yours was the first project that i'd really understood to act that way but since then there's other projects that maybe even existed but i didn't understand them as being sort of this multi-asset interoperability play but there are new ones how do you think about those how do you see yourself as different from those or do you see these projects sort of all kind of headed towards this very similar architecture

um no not at all right i think uh a you're still continuing to see a lot of pairwise solutions which i think you know have scalability effects and uh kind of fragmentation issues that you're going to have to deal with uh down the line be i think a lot of the protocols and there's a you know a number of protocols that have been proposed that kind of rewrite and change the the name of things and kind of obfuscate it and actually doesn't add anything to the security of the cross chain or interoperability um i mean i think building a decentralized interoperability protocol that works across different stacks this is again like very challenging right i think um it's it's it's a very complex technical problem um i think a lot of people have

taken you know shortcuts along the way to get to the user experience that i think we've been describing for for the last year right then like pioneer than one of the white papers that were wrote with the gateways and kind of communication across them you can get to that user experience in this you know with centralized backhands in some sense which i think is a mistake and you're going to be run into the security issues but get into that user experience with a decentralized back end i think is a very complex uh kind of a problem of the other solutions this is a kind of a funny question i've never asked anyone else but i'm curious how you'll answer it um which is your favorite which is your favorite of your competitors who do you think is like really good i'm going to try to ask everyone all the

bridge all of virginia people this uh great question so you know it's a hard one um wormhole nomad no i mean i think wormhole is a centralized bridge for all practical purposes right i mean nomad i think explores interesting trade-offs in the safety and liveness assumptions but i think from a safety and decentralization perspective uh it's a step backwards in some sense um because i think you know they introduce liveness assumptions to guarantee safety which i think is very

dangerous for the cross chain uh world given like all the attacks that we that we're seeing in the space um there's not a lot of research on this right on this interoperability at least protocols that i would consider any any sound or any any truthful i think there's a lot of marketing material and uh you know heuristics proposals out there by some people that don't understand anything about basic liveness and safety properties and trying to market you know and go to market with them which i think is a huge mistake uh so i actually would love to see you know more rigorous analysis on the safety and liveness of the protocols and on the trade-offs and the you know uh distinction between you know permissioned or permissionless systems uh which is not something we're

we're seeing a lot in the space so i would say you know it is a hard technical problem i think a lot of the teams are doing you know the best that they can to serve to solve it but i think we have you know the best and the most decentralized approach and the most universal approach that that i've seen today so all right well said like a true businessman all right but i'll i'll take it i'm gonna i am gonna try this potentially with other interviews so they can get prepared for that question of who of your competitors do you like the most um well listen sergey thanks for coming on the show and sharing with us this sort of story of axillar the work that you're doing what makes it unique and

yeah where you're at i think it would be really cool to hear kind of what's coming next and then i think we'll wrap up so yeah what is coming next yeah i mean uh continuing the network rollout so various features will go live like you know general message passing will go live right on the network across evm chains and then we uh you know look enough how to extend it to cosmos chains as well so i think that's going to be you know super exciting more connections right to more networks that are not connected more applications integrated on top of the network so we have a huge pipeline of everybody from crosschain taxes you know nfts wallets that are building around the network so i think that would be you know super exciting and um yeah i think that the goal is to

get us to a world where people or users don't have to think about multi-chain right or cross chain i think these things have to be obfuscated and taken away uh from the user interaction so to me that's the biggest uh goal and that's the biggest uh you know point to work towards cool well thank you so much again for coming on the show awesome it was great being here anna thanks i want to say thank you to tanya the podcast producer henrik the podcast editor and to our listeners thanks for listening you