Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Sergey Gorbunov: Axelar – The Blockchain Interoperability Network

Episode Date: March 4, 2022

Axelar is a highly scalable, decentralized blockchain that aims to connect all existing blockchains. The proof of stake network, built on the Cosmos-SDK, allows application developers to choose the best blockchain to deploy their applications and use Axelar’s cross-chain communication protocols to lock, unlock, and transfer assets between networks, as well as communicate with applications on other blockchains. Co-founder and CEO of Axelar, Sergey Gorbunov joined us to chat about his experience working on Algorand, the importance and future of interoperabilty protocols, and the vision behind Axelar.Topics covered in this episode:Sergey's background and how he got into cryptoThe lessons he learnt from his time at AlgorandWhy and how Axelar was builtThe future of interoperabilty protocolsWhat are security challenges around interoperabilityInteroperability use cases beyond token transfersAtomic transactions with AlexarThe road ahead for AxelarEpisode links: Axelar SiteAxelar DiscordAxelar on TwitterSergey on TwitterNonconventional Podcast by Ela CrainSponsors: ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/433

Welcome to Ep Center, the show which talks about the technology projects and people driving decentralization and the blockchain revolution. I'm Brian Crane. And today I'm speaking with Sergei Gormanov. He's the co-founder of Axelar. Axelar is one of the leading intraoperability protocols, like aiming to kind of make all of the blockchains interoperable or lots of different diverse protocols. Very cool project. I'm really excited to. to dive into that with Sergei. Now, before we do that, let's briefly go through our sponsors. So we have, first of all, Pereswap. So Pereswop is a Dex aggregator on Ethereum. So that means through Paraswap, you can access liquidity on various different decentralized exchanges. So the protocol automatically finds the cheapest source of liquidity for you. And you know, you can get the best price. It's also very gas-friendly. So it keeps your transaction costs low. They also added, recently for different EVM networks like Avalanche, Polygon, BSC, and Phantom. And you can also use it directly from your ledger life.

And also they've started a kind of doll. So if you want to get involved in that, you can do that with their PSP token. Yeah, so go check that out at Parasop.io. And then second sponsor, course, won. So proofstakes becoming like a major way of securing decentralized networks, lots of different ones, including the one we're going to speak about today, Axelar. So course, one is running staking infrastructure on lots of different networks, allowing you to earn rewards and contribute to network security and doing so in a secure way.

So we have billions of people staked on, you know, around 30 different networks. And also supporting institutions in participating in the staking economy through, you know, white label notes. So yeah, if you're interested in staking, head over to course.1 and start. start your staking journey there. And then before we get started, one more thing. So my wife has started the podcast. It's called Nonconventional. And it's really great.

They have guests across lots of different domain. I was a guest on there. I think there's some other crypto episodes too, but it's like all kinds of things. Also like entrepreneurship, art, science, etc. So you can go and check it out and let me know what you think. So you can find it on nonconventional. dot show.

And so with that, let's get started. Sergei, it's so great to have you finally on Epicenter. Hey, Brian, good to be here. Pretty excited. This is like, I have the question of both here is like directly in, but maybe you can like take a step back a little bit. Like how did you, how did he become interested in, you know, crypto and blockchain? Yeah.

So, you know, I think my background, I played with. various technologies, I think over the years. Originally, I worked in the kind of software-defined networking and just distributed systems. And then I wanted to go to grad school to study formal cryptography. So I ended up going to MIT to work on theoretical cryptography for a number of years, including, you know, lattice-based cryptography, like functional encryption, like multi-party computation protocols and things like that. And then, you know, by the end of the grad school, kind of solve a few interesting problems. I knew that, you know, I had enough to defend my thesis, but got a little bit bored, right, and was looking for a new space and a new set of problems to work on.

And so that's how it started to look at the at the blockchains and crypto that was around 2014, 2015, kind of pretty early days. You know, Ethereum was still in the early makings, and they were figuring out some of the scalability issues. And I started to collaborate with Sylvie McAWale. who was a faculty at MIT at the time on some of the early designs behind the Outground Protocol. And, you know, 2015, I finished grad school. I went to the University of Waterloo for a few years, continued doing research there in systems, you know, crypto security. And then after that, been kind of joined the crypto space full time, right, and helped to build Outgrant. We took that to the market, you know, two and a half years ago.

And since then, yeah, it's been kind of full time. It's an amazing space to be and I'm pretty excited to build here. Yeah, absolutely. It's a pretty unique industry. I don't think there's anything like it. At least I've not heard of anything like that. So one thing I'm curious about, so with Algorand, right, you were part of, you know, like a big blockchain project, right? Big layer one project.

Now then you went to start Axler, like your own project. So I'm curious, like, what are the? the main lessons or learnings that you had from like your time at iGrant that you were like okay that's something you know definitely when you do differently or that's like something that's like really important in terms of how you approach launching crypto protocol yeah great question i mean i think a you know it is important to say that the time it is probably you know a little bit different that right now than when it was when we're launching algrant so you know some of the things that i say you know should be revisited right um but i think that because that because

being said, at least building right now over the last few years, I kind of realize that building alongside the community is probably, you know, one of the most important things, right? So that as you making decisions, as you're building a network, right, where you have lots of actors participate in it, like validators, right? You have users, you have applications that will be interacting with it. I think getting feedback early, getting, you know, reacting to the feedback, iterating quickly, allowing people to, you know, contribute and participate and build on side with you, hear their ideas is kind of quite fundamental, right? And I think this is right now that to me, to me, that's been one of the most rewarding things.

I think building in crypto space and building, you know, an open network is that, you know, we have a core team that does a lot of development, but I think without the external support of, you know, folks like you guys, KORS1, right, and other validators and other community members, building like dashboards and tools and monitoring services, I think it would be a lot harder to get what we are. So we're trying to leverage that, I guess, to the fullest extent. What's your secret to like building the Axler community? What has worked best? I'm not sure if there is, you know, a specific one secret, but I think being transparent, right, being open and where we are, you know, listening to feedback, inviting people. And I think,

you know, it's important to help each other out, right, as we're building this. There's a lot of folks that are kind of get into the space trying to learn how to, you know, set up nodes or how to perform simple transactions across networks and things like that. And just listening to that, providing feedback along the side. I think that's, you know, that worked quite well with us. I think the other things that we have done well is we're running a lot of different community programs where we try to structure how people engage with Axler, right? So we've been running this quantum community program over the last few months. And Kate, who is working on our community development, has been doing a lot of driving behind it. And there we allow kind of non-technical people

to participate, right, which is something people have asked for a lot, which is like, how do I create content? Like what type of content do you guys need? How do I create documentation? Like technical write-ups about XLR, like how to explain it better and things like that. And so, you know, we try to put some structure and give them some ideas how to how to get engaged and then i think that that worked quite well let's take maybe step back around axelar so what was what was the original impetus like why did you want to start this project and what's your vision for axelar yeah i mean you know i think as we're building outground and taking it to the market i think a we quickly realized that a lot of other platforms are being built in parallel that are going to have traction,

that are going to have use cases and maybe optimized for different constraints that like our rent was optimized for, for instance. You know, some of them build around different software stack. Some of them just target different markets. And so definitely we quickly saw that many ecosystems would continue to evolve in the space. Now, when you take that as a given, then the first question that asks, well, how do you interact across those ecosystems? For us, the first ecosystems we wanted to interact with from our grant were Bitcoin and Ethereum.

Then I think every proof of stake blockchain that was built around the same timeframe had a similar question. Like how do you connect to those two networks? But that on its own, you know, you can think about like bridges or some type of a one-off solution and sort of that's fine. but if you take as an assumption that many other ecosystems are going to continue being built, continue being developed, then you ask yourself a question, well, how do you make it easier to connect all of them together? What are the universal metrics that you have to satisfy at the protocol layer, at the infrastructure layer, to connect them together? And so that's what we started to do. And the end goal for Axler has always been to allow users and developers to interact with all

of these ecosystems in an easy way. I see an application. I have an asset. I should be able to go and use that application with my asset, which is not really possible if you have to hop across from one that route to another in some fashion. So if you see in the end, like if you see sort of axler or interoperability in the long run, do you think we're going to have like lots of different intropability protocols or do you think there is going to be like a convergence on, you know, one or two? Great question. So I think, there's going to be different protocols, but different protocols are going to be across different layers of the stack. So if you take as an analogy, you know, how the internet works, right?

Intraoperability protocols are all about how the internet is structured, right? And it's not a single protocol. It's kind of a sets of protocols that were built everything from, you know, routing protocols, transmission protocols, application layer protocols. on some of the layers you have few protocols. You know, on the core routing infrastructure layer, you have protocols like IP, BGP, right? Then you have TCP and UDP protocols on top of it,

but then you have many application layer protocols that are making it easy for the applications to interact and kind of talk to one another. And at least right now, I would think that something similar would happen in the blockchain ecosystem where at the core, you know, routing or infrastructure, layer will probably get to end up with, I think, a handful of solutions, right, or maybe protocols. And then on top of it, I expect to see a lot more application layer protocols that,

you know, leverage all of the core infrastructure to communicate and go back and forth. And that's what, you know, applications would be exposed with. But on the network and route and layer, you know, I don't think we cannot scale if there's just too many protocols, right? This system is going to continue to be fragmented. So I do think there's going to be, you know, a convergence towards a few approaches or a few, you know, message formats in some sense. When you were pursuing that or like, you know, kind of started working on this on this idea of like having this interoperability solution. What did you feel like was, I mean, what were the main kind of requirements that you had for like the solutions that would produce? Like what were you trying to optimize for?

Yeah. So I think first. requirement that we had was to be able to connect with any ecosystem in an easy way, right? So meaning that in the blockchain space, we've seen lots of different consensus protocols, everything from proof of work to proof of stake, they all have different finality rules, they all have their way of dealing with, you know, safety and liveness thresholds and so on and so forth. And so we wanted to be able to plug in an easy way with any of the ecosystems without having to make complicated engineering projects and kind of spent years integrating one platform to another. So that was a, you know, first core requirement. I think the second

core requirement was to be able to translate, right, and route across any of these ecosystems in an easy way. So, so I think the basic problem that comes up is you connect more and more of these ecosystems is that, A, they all speak very different formats and different languages, right? So you need a mechanism. to be able to, you know, take a message from one chain, be able to translate it and put it as a message on a different chain, and you need to be able to route it in an effective way. Like, how do you make sure that as new ecosystems are being added, there is no additional, like, latencies or, you know, hops that are introduced to connect to those ecosystems. So those were some of the core requirements that we wanted to make sure we can satisfy.

And the final one was to really think about it, how do we make it easy for the users to interact with all of these solutions, right? I think we're still so early at the interoperability space where we're talking about, you know, core pipes and infrastructure. But we do have to get to a level where, you know, applications integrate with this infrastructure so that the users can go and just use the application that they want across the ecosystem. And so building a stack that would allow for that user experience is actually quite fundamental and quite important. And we spend a lot of time thinking how to make those design decisions that would down the line optimize for this user experience and make it easy for the users to talk to all of these chains. Cool. And so can you describe the, you know, what's the architecture that you ended up arriving at? Like what does arcs law look like on a high level?

Yeah. So on a high level, Axler is a proof-of-stake network that's built around Cosmoso SDK. And what it runs is that it runs a kind of cross-chain consensus protocol that we have built. And what happens under the hood is that a set of validators are collectively monitor in different blockchains and they're monitored special exit points on those blockchains. We'll call them Axler gateways. So think of a gateway as a special account. or a set of accounts or a smart contract,

if you're talking about a smart contract compatible chain, information can come into this gateway account. The validators collectively reach a decision of what needs to happen with that information, where it needs to go, where it needs to be routed or translate along the way. They perform those functions collectively. They vote on it.

And then they produce a message that can be posted on the destination chain and that message then gets executed. And so the basic idea is then you have this axillary consensus protocol and the validators that are executing all these cross-chain functions. You can onboard more chains. You know, more validators can join. It's an open network. You can keep on adding more protocols and you get all the benefits of having this, you know, universal overlay network across all of the all of the blockchain that does all the core functions.

Right. And just to maybe kind of contrast this. like one interoperability solution that people may be aware of is, you know, something called IBC, right, which exists in cosmos. And in IBC basically you have like, okay, let's say cosmos hub and osmosis, and you have a light client of the cosmos hub running in osmosis and the light client of osmosis running the Cosmosis hub or, you know, these light client proofs are basically accepted. And then you can connect this way.

Now, of course, the problem is that doesn't really like, work easily across like lots of different chains, right? For example, like, how is the Bitcoin chain going to like verify it like client proofs and some other chain? So then here you basically have a set of operators know that are like running full notes that you then trust. Yeah, exactly. Right.

So I guess, yeah, like, you know, what you mentioned is quite correct. Right. Like I think IBC is a, you know, great protocol. I think it works really well, but it wasn't a very heavy engineering undertaking, right, even for tendermint based chains to, you know, integrate and implement. Integrating for some other chains, even proof of stake chains like Algrant or Avalanche. I mean, a lot of the stack would have to be rebuilt to do that, right? Which is, you know, kind of would be years of work and engineering.

And so I think that's one thing. And two, you are always going to be in the need of maintaining these like lines and these connections, right, if you create IBC connections. So if I'm upgrading my proof of state blockchain and I'm modifying consensus because I have a better algorithm or I want to change the way I'm, you know, creating blocks or headers, that means all of the connections that I need to manage as an operator of this network. I would have to go and write the like clients for them. They may have to be produced in different languages like solidity, you know, rust, consensus layer, whatever that is. I have to go and upgrade them, maintain them, and so on and so forth.

So I think we try to optimize a little bit more for engineering ease of use and onboarding in some sense than I would say kind of a, I know, IBC is almost like, you know, the ideal model, but it's, you know, but it's very hard to scale in practice. And if you're talking about diverse ecosystems. Maybe you can talk a little bit about the security aspect of intropability, right? I mean, I think we have seen some of the biggest hacks and sort of misfortunes have happened around intropability. I think there was something on Ethereum. I remember what it was called now, but there was like a few months ago. That was like a really huge one.

And then, of course, we've had warm hole more recently. Like, why is the security? of interoperability in your view why is this so hard yeah great question at the very core kind of any interoperability protocol works as follows right you you need to you have let's say you have two two blockchains right on the very high level any blockchain is a is a database plus a network right so let's think of it as a database so your goal is to get to synchronize two databases in some sense, right? So what is the way of synchronizing a state across two databases? Well, the most standard approach is that, you know, you lock a state on a source chain, you replicate it on a

destination chain, right? So when you're talking about moving assets across different blockchains, most of them effectively lock the state on the source chain of an asset, and then you replicate the state on the destination chain, and then destination chain can work with that state, and then you go back and forth, right? So it's a similar how, you know, on the internet, we're doing messages across different systems where, you know, and messages sent, you can put databases, you know, you can lock information in one database or another, you can manipulate it and so on and so forth. So that effectively creates a big challenge, is that when you lock the state on the source chain, how do you make sure the,

nobody can unlock it, right, without being authorized, without getting authorization to unlock. And, you know, in IBC, for instance, model, what allows you to serve lock or unlock are these proofs, right, that you pass around from kind of source chain to destination chain, and that proofs allows you to verify that information on a different chain has entered a certain format, and therefore it can now be manipulated on this destination chain, right? with the most intraoperability protocol, that's a similar way. It's the question is what is this proof? The question is how compact is the proof, how easy it is to generate it, and so on and so forth. And because a lot of these intraoperability protocols are built across many complicated software stacks, it's just non-trival to do this the right way. But I would say that it's kind of a note different than, well, it is different, but it is very similar to how we would

just learning how to build, let's say, like, different defy applications in a secure way three years ago, right? I mean, I think you remember, you know, 2017, 2018, 2019. Lots of applications were shipped. People were just experimenting, blocking, you know, millions or hundreds of millions of dollars of liquidity. There was some attacks where, well, some chains even decided to fork, right? To prevent, to kind of resolve the incident. But it was the same problem that people just didn't know how to do it securely. People didn't pay attention to the audits, right?

People still learn in the kind of edge cases of some of these software programming models. With interoperability, you're talking about a much more complicated problem. We're talking about different ecosystems. You have to create those proofs in an efficient way. You have to relay them. But, you know, I do think it's a solvable problem. You just have to be much more thoughtful how you think about security, how you think about audits, you know, emergency mechanisms and so on and so forth.

It's a full stack that you really have to. sort of embrace if you're actually trying to solve this. And do you think there is, you know, kind of like a fundamental difference in sort of the level of security between, you know, like this kind of light client based approach versus an approach where, you know, you have basically a set of operators who run full nodes on each chain and sort of observe the state? I mean, there are definitely, you know, differences if you look at, you know, kind of a one connection at a time, right? But I think if you look at the ecosystem from a broader perspective,

then you kind of realize the following. A, suppose we're going to be in a world with hundreds of thousands of chains, which, okay, not even an assumption anymore, right? I think we're definitely going to be in a world with hundreds of useful chains, maybe thousands down the line. In that model, you cannot have pairwise connections across every single chain, period, right? Because then every chain will have to manage. you know, a hundred other connections, you know, you're going to need to have, you know, almost then square connections across all of these chains. Who's going to manage them?

Who's going to, you know, update all the whatever protocols like clients deal with emergencies and so on and so forth? So no matter what, I think if you're in a world with many different chains, then you're going to have to trust some intermediary, you know, hubs along the way that will route your information, right? And whenever you trust in some intermediary hub to route some information, you're going to through whatever protocol, you're going to be trusting the validator set of that hub. And on the internet, as an example, we are, you know, on average, taking like six or seven

paths across any different network when we send the packet, right? And so, you know, if you were to replicate it to the, you know, to the blockchain ecosystem, imagine taking six paths, which I don't think we should, by the way. I think we should try to minimize the number of hops, you know, we'll go from any two blockchains. For this reason is that every time you would take a hub, you know, you're going to have to trust, you know, another set of protocol or another sets of assumptions along the way.

So it's a never rule that you're going to have to trust some intermediary unless you're big enough to manage, you know, hundreds of thousands of connections yourself, right, which nobody wants to do. So I think that's not really, you know, an issue. You would rather trust actually somebody who can do a diligent job of being this sort of security provider for you, right, and being this hub that can, you know, securely connect you with hundreds of different chains. and so that you know that if something goes wrong,

this network provider knows how to deal with it, right? And has the operations in place, has the protocols in place to deal with emergencies, you know, and react to it. I think that's one thing. I think the second thing, which is, I think, quite important to note is that most blockchains today run across the same validator set, right?

You know, it's the kind of chorus, right, figment. I can name a couple dozen validator sets and a lot of them have the majority of the stake on most of these protocols. And so whenever you're talking about trusting this network or that network, at the end of the day, you trust in the validators and most of the time you trust in the same validators. So, you know, I hope we'll continue decentralizing. For right now, it's not even a problem of kind of how many nodes a protocol can support. It's more about how much we can decentralize the stake in some sense, right? While still making it economically attractive for the validators to continue operating the networks. So I think that's actually a bigger challenge than, you know, how many nodes your protocol can support at this point.

Yeah. And then, of course, one of the interesting aspects of like, you know, I remember in the past, I don't hear this argument so much anymore. But, you know, people are often saying like, oh, in Kosovo's like, how is it going to be safe? insecure because like you have so many different chains and you know is the market cap enough and things like that but then like of course we haven't seen right like in in ethereum classic we had this thing where like you had the majority of the mining power basically do this 51% attack and like roll back the chain well this is not happened in a proof of stake chain and like okay why not i mean i guess various reasons right first of all like it's economically it's just like so much more

expensive. It just doesn't make any sense to basically ever do that. But then I think you also have the factor, right, that now, okay, you have all these different validators. And if they did something malicious on one chain, well, they would like totally ruin their whole business on like all the chains, right? So I think it means that even smaller chains, right, can be pretty, you have this kind of like additional trust through, you know, reputation and, and, and, and, it's, you know, in a way like the aggregate stake that's with them. Yeah, I mean, I'm totally with you that, right? And I think the only thing that we have worked to protect the ecosystem has been to try

to maximize decentralization, right? You know, it's still, I would say, not sufficiently, you know, decentralized yet. I think we have to continue working and get, you know, more validators kind of included in these sets and having them, you know, giving them enough voting power and things like that. but like you said, that's the only thing that has kind of proven to work, right, where you have dozens or maybe hundreds of different actors and coordinating between them, like an attackage. We all know who they are, right?

Like they all put their labels and websites. And I think just a huge credit, I think, to all the validators communities on that because I think they have powered a lot of what we're seeing in the blockchain ecosystem today. Let's dive into a bit more. So far, right, intraoperability in crypto has mostly been around token transfer, right? Like you have, you know, Bitcoin and you want to put it into defy. So now we're going to use like WBTC or, you know, you have in cosmos. You have like different tokens and you want to put them on osmosis.

You know, you want to put atoms in like liquidity pool on osmosis or like what do you think are the use cases, like beyond token transfer that you think are most exciting? Yeah. So, you know, I think there's a lot, right? Like, I think token transfers in some sense is just kind of a need. And that's why we've seen a lot of interoperability been centered around it. But more generally, you can just ask, can a user, you know, directly interact with an an application with the tokens that they have on a different chain, right?

And interaction with an application may or may not involve the token transfer, but it often involves, like, other information that means to be passed along, right? So let me give you like an example. So suppose you have, you know, a stable coin like UST on a cosmos chain, right, on Terra, right? And then as a user, you want to get directly, let's say, ETH on the Ethereum chain. So the ideal user experience from a user perspective is then just going to their wallet, right? making a one-click transaction where their tokens, if needs to be routed across from, you know, Terra blockchain to Ethereum, swapped on the destination chain for ETH, and then the user receives ETH right away in their wallet. So this is a sort of one-click experience where a token transfer is augmented with some other information the user,

the user may include, like what is the destination address where they need to receive the token, what is, I don't know, the slippage that they're willing to tolerate during this exchange and so on and so forth, right? So I guess going beyond tokens, what we're asking is that can the users and applications compose with one another across this ecosystems, right? And that often requires passing messages like, you know, slippage information, whatever exchange rate that you like to take amount, you know, source, destination addresses that you want to communicate across and so on and so forth.

So I think that's just a layer above, I would say, you know, the token transfers, which is still mostly focused around token transfer use case. I think from there, the sky is the limit in some sense, right? Any asset that's being created like NFT will effectively need interoperability because users want to interact with those assets across different ecosystems. And finally, the applications want to interact with one another and compose. Right. Today, if you're building on top of Ethereum, you are taking interoperability for granted.

But the reason that we're seeing Defi and, you know, Ethereum or other proof-of-stake blockchains emerge is because they allow developers to talk to one another, right, on the same blockchain. They can execute, you know, function calls. They can perform swaps one another and so on and so forth. And so that's what we want to enable across different blockchains, right, where applications can talk to one another. send information,

cool, you know, rewards, incentives, liquidity, mining, rewards, and so on and so forth. And, you know, I do think it's important to understand that that model we're going to have to change the way the development is done a little bit. You know, and we can talk more about that. But it is a new programming model in some sense

and developers will have to embrace it. But I think it's sort of inevitable that I think it is going to happen. Yeah, let's get into that because that was one of the topic I wanted to discuss with you. So has often been brought up as, you know, one of the core, you know, strengths of Ethereum and, you know, the advantage of Ethereum over, let's say, something like the Cosmos ecosystem where, okay, you have all the smart contracts on like a single chain and then it's pretty easy for me to, you know, create some other application that, like,

uses the different chains. And then in other, in other aspects of this that has been often brought up as like, okay, this is like a, you know, really core advantage is that I can make, you know, a transaction that interacts with different blockchains and, or different smart contracts. And, you know, either the whole transaction succeeds or it fails. So this like atomic transactions and flash loans on Ethereum, right, is like this, this paradigm example where flash loans basically allow you to kind of borrow money, like use the money in a bunch of transactions and like repay the money like in the same transaction, uh, in the same block. So then I basically, you know, there's like no capital risk, right?

The money is basically almost like instantaneously taken and given back. And, uh, of course, that's like pretty unique and kind of strange use case. So yeah, how is that going to change? Like, do you think these atomic transactions is that, is that something that's like that important or how is that going to play out in a in a sort of axelar cross chain context i i think before maybe we we we just answer that i think just taking a slight step back i think it's it's kind important to understand that it's sort inevitable that applications you know and sort of cross chain will have to be a reality to just continue scale in the ecosystem right because why aren't we

continue building all on top of Ethereum, right? Well, because it's one network, it's one database, and it's congested, period, right? And I think if you look at a lot of other blockchains, no matter how much throughput they process, however fast they are,

if it's a single database, if it's a single network, at some point it's going to be congested once you're talking about, you know, even a handful of major applications that need thousands of transactions of throughput running on top of it, right? So in some sense, to continue scaling the ecosystem and to continue, you know, surviving, like, we're going to have to have more networks.

So I think that's inevitable. But then in that model, you know, you ask, well, how do I talk to to one another, right? And I think, like I mentioned, the model changes were instead of having a transaction that may be, you know, atomic whenever you execute in a single program environment, you will be intracted in a more of a message passing way. This is similar to how a lot of the networks on the internet again, right, and the traditional Web 2 applications have scaled. They all run behind different networks or different database instances in the back end, right?

And they send messages to exchange to one another. And we have protocols for reliably sending messages, unreliably send in messages, right? And then you build your application logic around those messages that tells you what to do when, you know, the message hasn't arrived, right? Or it needs to be retransmitted. or in this case it would be what to do when the transaction doesn't go through, right? Or, you know, the asset is not delivered on the destination chain or whatever the swap that you want to do on the destination chain doesn't go through.

What do you want to do with it? You're going to have to put some coding around it and you're going to have to put some rules, right? And that's where I think this layer of application layer protocols will have to be built to almost think about, like, what are some of the good examples in use cases that we want to have with stronger problems. properties that, you know, just a message passing, right? Like, do you want to revert transactions across different networks? You want to allow people to, you know, retransmit and replay and what types of fallback mechanisms that you have? You want to have. Those are all kind of application-specific cases that you have to think through, but, you know, I don't think it's that hard. Well, it's not trivial.

We have to think of that through it, but it is a solvable problem, and we have solved it in the past. And, you know, in this case, I think, yeah, it's inevitable that we're going to need this. And, you know, and I think in some sense it's a never rule that developers will have to adjust to this programming environment along the way. Do you think, is there, have you thought about the idea of like whether Axelor could provide some kind of like atomic transaction guarantees across chain so that like, you know, I can make a transaction on chain A and I wanted transaction. chain B and like you know I only want the transaction chain A to execute if I if also the transaction chain B executes what do you thoughts on then I I think it's a great question so we have we have thought about it and you know it is possible and I and I think this is where I think one of the architecture decisions that we made for building axel it becomes you know pretty

fundamental and necessary in some sense is because axler itself runs on top of you know consensus and a blockchain system, right, around cosmos SDK. So that means that whatever cross-chain transactions you want to execute, you can sequence them, right, on the Axel network itself, right? And then you can build your protocols around it and you can say, you know, because there is a sequence of events and because you can rely on the Axel network to give you the sort of ordering of the transactions that need to be executed across different chains, you can then execute them in a, you know, in a specific order and only trigger

if some other conditions have been satisfied. In contrast, if you were to work and try to satisfy this without a consensus layer in the middle, without an ordering service, this becomes a lot harder, right? You would have to replicate a lot of this functionality at the application layer, which is pretty painful to do. Yeah, it's a very interesting topic. And there was actually two podcasts I did just in the last like weeks where we kind of talked about this. And, you know, one was with Dean Tribble of Agorik.

And he made the interesting claim that I don't think I'd heard before. But he kind of made the claim that like, okay, if you have actually these different chains and if you don't have these like atomic actions across chain, that that actually leads to a much more kind of, you know, you know, robust ecosystem because the risks and the failure modes are more contained. You know, you'll have like, okay, something goes wrong and but there's sort of, you know, a little bit of an isolation of that. Do you see that as well? Yeah, I mean, it's an interesting point. I would have to think a little bit about it. It is definitely, I guess, easier to build systems in that way, right?

where you have like this asynchronous model and then you know if one system goes down you know you can continue operating the other models you know is this efficient for applications that I'm not sure then I think we'll have to think but but again I think from a system's perspective I do think that that's the way you know we're going to have to build things in some sense but I do think you can build you know application layer protocols on top of it that sort of you know some specific needs whenever you need to satisfy some of these you know atomic operations but But on the network layer or intraoperability layer, in some sense, it needs to be a little bit more decoupled and loose for these reasons. Right.

Where if one network or one systems goes down, like you can't take down everybody else. Right. Like you have to isolate it and you have to contain the damage in some sense. Yeah. And the other, let me just also mention it briefly because I just did the episode yesterday with the near guys. And this was also something that like we discussed a little bit. And I was not aware of that before. But right on near you have like different charts.

and then even if you have like two smart contracts that are on the same chart, they actually still don't, they still function this asynchronous way, where you don't have this atomic transactions. And they were like, okay, that's sort of their design choice so that they develop, it doesn't actually have to care about which charts the thing is in.

And then the contract can be moved around and it doesn't really change anything. But then of course, it also has that implication that functions in this different way. So I thought this was very interesting because maybe in the past, maybe this is also something that the Ethereum community has like emphasized so much about like, oh, this is so crucial. This is so crucial because it was maybe that's not really the case. Like I think, you know, back to what I was saying earlier,

I think, you know, Near, right, and Dean and Agorik guys, they thought about how to scale the ecosystem, you know, for years to come, right? And I think they quickly realize that the only way to scale it is to, continue sharding, right, or scaling horizontally in some sense. And whenever you scale in horizontally through many shards or many blockchains or whatever that, you know, architecture that you choose, you're going to have to switch to this asynchronous communication model. Right.

So I think, you know, that's probably, I would say one of the reasons those guys are embracing this model because it's, you know, it's sort of inevitable. Maybe talk us through a bit. Like, what's the, uh, what's the status? of Axler today, like what has been developed and yeah, like what's? Yeah, so, you know, we spent a little over a year. I think today it's kind of a building the core networking technology. We've run, been running, you know, test nets for over eight months with our community. And, you know, last month we just announced that we're starting a phase rollout of the main network. So that means

that, you know, in the first phase, we already started to onboard, you know, early valid. And data getting them connected with different ecosystems, I think we're already connected to, I think, six or seven different ecosystems through Axler. And we're slowly going to be opening up different functionalities on top of the network. We already opened up functionality to transfer some assets. So you can move things like Luna or UST across many EVM different ecosystems through a kind of front-end application that would build on top of it. And, you know, the coming year is going to be pretty exciting as we're going to continue open up this functionality is working with developers and working with the community to start scaling this, right? And, you know, along the way, we'll have

to build better documentation, better APIs, you know, SDKs, think about those application layer protocols that we want to, that we want to work with, with our partners and, you know, what ecosystems will continue integrating down the line. So super excited, I think, for the coming year. So one interesting question I have. So let's say now we have like chain A and like you make the example, right? So you have UST, right, which is the stable coin that originates on Terra and then you have some EVM chain. Let's say Avalanche and you know use it on there and then you know Axler is like a solution that so that somebody can move it over. But of course Axler is also its own blockchain.

So do you think, what kind of things do you see like running on the axelar chain itself? Do you ever see, for example, people developing like, I don't know, let's say putting something like a permissionless cosmos in there or general smart contracting environment or like, yeah, like what kind of functionality can the axelar chain, you know, can be put in there in the future? Yeah, great question. So, you know, I think the core problem that we're trying to solve is intraoperability, right? So, and the way we want to see the future is that developers get to decide where they want to build, how they want to build. But underneath it, they have a set of protocols, you know, and infrastructure they can rely on to go cross-chain, right? So this is our ultimate goal. So in that model, right, like we want to build the infrastructure and stack where developers are empowered to go and build, you know,

on EVM chains, on Cosmos-based chains, on whatever they really want. And, you know, an Axela just helps them to communicate and go cross-chain and be, you know, a service provider network in some sense that they can do those things. On top of the Axel network itself, would developers be able to build? You can certainly build some things. And, you know, I think we may open up kind of cosmwasum for the purposes that we want to customize some of the application layer interoperability protocols. and things like that down the line

and allow people to onboard new chains easier. Right now, if you want to onboard the new chain, if it's an AVM chain, we build it so you can onboard in 10 minutes. So it's pretty straightforward. For Bitcoin, we have a module that we're working on for Cosmos. You know, it's IBC compatible, so it's kind of integrated at the protocol layer. For other chains, you may need to push another module.

But, you know, we want to make it easier so that, you know, maybe as a developer you can just write another smart contract that allows you to translate this message from a particular ecosystem. system to be routed by the Axel network with all the other networks that are connected with, without having to write like a full Cosmos module and pass a governance proposal down the line and things like that. But on its own, kind of solving interoperability and cross-chain message is just such a demanding requirement. And, you know, you need a lot of throughput. You need to optimize for this use case. And, you know, we're designing Axel network to kind of optimize for

this use case as opposed to, you know, as another, you know, develop. environment. I think there's a lot of projects where optimized for, you know, JavaScript development or solidity development or, you know, Rust development. And I think there are a lot of them doing a fantastic job. So we want to, you know, connect those ecosystems. On the actual network itself, we'll ready process in, you know, tens of thousands of transactions per day just for cross-chain message passing. I wouldn't necessarily, you know, start building the application on that. And I think we'll want to remain as a service provider in some sense. Yeah, that makes sense.

I mean, one application is that, you know, we've had a bunch of conversations on. It's kind of like an interesting, I think, sort of product. On Ethereum, you have something that you can notice is safe, right, which is this smart contract wallet. And, you know, that's pretty nice because you can have, you know, multi-sick, you can have, you know, maybe some sort of programmability. You can have, like, different types of things. But, you know, it's an Ethereum thing. It doesn't function cross-chain. And in general, like, you know, cross-chain wallets don't, I mean, there's no great solution, right?

There's not like one wallet you can use across like different ecosystems you have, you know, on cosmos. You have something like Kepler. Okay, functions great on cosmos chains, but like doesn't function anywhere else. Solana, you have phantom. Great over there. But like, doesn't we do much else. You know, Ethereum, you have a metamask. And so this idea of like, okay, can you have like some kind of universal programmable wallet?

And of course, I guess one way of doing that might be that you have actually like a chain or someplace that costed these assets on all these different chains. And then, you know, I could just have one private key on that chain and I send a message to that chain. And then that emits like transactions on another chain to like, you know, for example, stake Ethereum or like, you know, swap Ethereum on uniswap. But like, so there's like an interesting, I think an interesting kind of product I hear. Have you thought about this and how do you see that sort of playing with the AXLR stack? Yeah, no. I think kind of a building universal cross-chain wallets, you know, is is one of the top, I think,

use cases of intraoperability, right? And it kind of goes back to the things we talked about earlier is that, you know, allowing users to interact with all of these ecosystems and DAPs, in an easy way from a single wallet. And I think the way that this, you know, will play out is that you do need a combination of, I guess, asset transfer and message passing to make those universal wallets. And I think, you know, it seems like you already have some great design ideas, Brian, right? But, you know, I think, you know, if I were to invest in this, it's sort of similar, right,

where you have potentially some smart contracts that are living on different chains or as a user, you know, you authorized to interact with those smart contracts, right, and those contracts. contracts allow you to have your balances, you know, on different ecosystems, maybe even the way people send money to you is through, you know, a universal like handle that, you know, can be used to uniquely identify you, right, or universal identifier, QR codes, whatever you want. And then underneath it, the wallet providers or the DAPs and the user, they get to interact with those contracts, shuffle liquidity back and forth if they needs to be, shuffled messages, if they need to be and, you know, all of that experience is a lot smoother.

So I think it's a great example. And I do think we're going to see something like this to start appearing over the coming years. Yeah, I mean, I guess one, I don't know if that one way one could build it maybe, right, might be as a cosmos chain. And then you could, you could maybe use IBC to connect with other cosmos chains and use something like Axelard to connect with like the rest of the blockchain universe. but who knows, I mean.

Yeah, definitely. I mean, and in that case, I think, you know, you can build it like on the cosmos, right? And then kind of use the IBC Axler stack to talk to other networks. Similarly, you can build your logic wherever you want, right? Like, you can build it like an avalanche or Solana if you want. And then again, you know, use like the Axelot Protocol to send messages to other ecosystems, right? So in that sense, as a developer of that wallet, this is really, allows you to pick wherever you want to host your logic, right,

which application layer logic where your core functionality is going to live and then use the interoperability protocols to communicate and, you know, interact with other ecosystems. So when you look to the future of Axler, what are the hardest problems that are our head? Yeah. I mean, you know, I think it's a combination of continuing to build technology, in an efficient way, continue to integrate more chains, more assets, improving security

along the way, reducing the gas costs, reducing latency, and working with a lot of the developers to teach them and to educate them how do you write applications in a cross-chain environment, right? How do you think in this new different paradigm of programming model? Yeah, so I think all of those things are. you know, um, challenged, but also that's where, you know, the rewards and opportunities are, right? And, you know, to us, that's what's sort of the exciting, the exciting aspect of it is that we will get to change the way, um, the ecosystem can scale. And I think it is quite, quite needed, um,

to continue growing. Can you talk also a little bit about, uh, you know, kind of like the roadmap, or, you know, like the rollouts that are coming. You mentioned EVM chains, right? So I think there's like one of the initial focus on CVM chains. Like, yeah, so talk a little bit about like, you know, where's that at and like what comes afterwards? And what would be, you know, it's kind of the ways people can actually interact with Axler in the coming year? Yeah. So, you know, the initial rollout that we started doing, focused on connection between Cosmos chains and EVM chains. Right.

So, you know, Cosmos chains, we can easily onboard through IBC, kind of pretty straightforward. straightforward for EVM chains. We also program that on the network layer so you can onboard an EVM chain, you know, in 10 or 15 minutes, assuming the validator is supported, right? So it's incredibly easy and very straightforward to do. And, you know, we're continuing to work on a Bitcoin module that would allow to onboard, you know, Bitcoin and similar types of proof of work kind of legacy ecosystems. and we're, you know, opening up the SDK and a set of APIs that would allow developers to interact and talk across all these different chains, right? So this is something I'm pretty excited about. Right now, if you want to integrate and move assets back and forth, there is a simple, you know,

JavaScript SDK that we're going to be releasing that allows you to do those calls in an easy way. You know, you can integrate like bridging functionalities in your decks or your defy Apple But then from there, we're going to enable this SDK that will allow you to talk directly to the gateway contracts, right? Or directly from your DAP front end and talk with other ecosystems. So that's something we'll be starting to roll out soon. And that's how we envisage most of the developers will interact with Axler and other ecosystems. Well, thanks so much, Sergei. It's been really a pleasure to like have Yon to like learn about Axelarts and kind of share this with

for our audience. And I think it's been exciting to like follow along. And I'm super, yeah, excited to see, see how it evolves. I mean, I think for me, what has actually been interesting about interoperability was that when like IBC launched, I was really surprised how good the user experience was. And, and of course, that's still pretty limited, right? Because it's just, it's just cosmos, right? It doesn't really work. Well, and then it gets much worse when you have, like let's say interoperability between different I don't know because often you have different wallets on each side and stuff like that so I'm I'm excited about you know what things like axler will enable by having this like smooth seamless interoperability cross chains because I mean it's just

going to be enormous like what that enables yeah for sure well it was great chatting and brine and thanks for all the questions uh always a pleasure chatting with you thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners,

you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.