Sergey Gorbunov of Axelar discusses blockchain interoperability, a technology that enables decentralized applications to work across multiple blockchain ecosystems. Host Philip Winston spoke with Gorbunov about programmable blockchains, distributed vs. centralized changes, the Ethereum virtual machine, Axelar’s Cross-Chain Gateway Protocol and Cross-Chain Transfer Protocol, security issues, delegated proof of stake, and other implementation details.
This episode sponsored by TimescaleDB and Kolide.
Show Notes
Related Links
- Episode 297: Kieren James-Lubin on Blockchain
- SE-Radio Episode 343: John Crain on Ethereum and Smart Contracts
- Axelar Network
- Ethereum Yellow Paper
- Cosmos
- Polkadot
- Sergey Gorbunov Twitter
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Philip Winston 00:00:17 Hi, this is Philip Winston for Software Engineering Radio. I’m here with Sergei Gorbunov. Sergei is a co-founder of Axelar and an Assistant Professor at the University of Waterloo. He was previously a founding team member at Algorand. He received his PhD from MIT, where he was a Microsoft PhD Fellow. His PhD dissertation was on designing cryptographic tools for the cloud using lattice-based cryptography. Sergei, is there anything I left out of your bio you’d like to add?
Sergey Gorbunov 00:00:48 No,I think that pretty much sums it up. Thanks, Philip. Great to be here.
Philip Winston 00:00:53 Great. Before we start here, two shows from our archives that I found helpful in researching this topic: Episode 297, Kiran James Lubin on Blockchain and Episode 343, John Crain on Ethereum and Smart Contracts. So, starting from the top, what is blockchain interoperability?
Sergey Gorbunov 00:01:16 Yeah, so in the very high level, what we’re seen in the blockchain ecosystem today is that many different networks have been built, right? Many different blockchains. So, you have networks such as Bitcoin, such as Ethereum, Algorand, Cosmos, Polkadot, Mir, and the list goes on and goes on. And so blockchain interoperability at the very core is the concept of, how do we connect all of these blockchain systems together and allow connectivity between applications and users at the very end of the day. Today, that’s not really possible in many instances and blockchain interoperability in what we’re trying to solve is precisely that.
Philip Winston 00:01:57 Okay. Do we know how many blockchains are there or how many sort of major blockchains are there, and which ones do you expect users want to inter-operate between? Or is it just any inter-operating between any blockchain?
Sergey Gorbunov 00:02:11 Yeah, so I mean, I think today there is definitely higher number of like dozens of blockchains that have good usage and good use cases, right? So, maybe it’s 30 to 50. There are thousands of blockchains on their own. Many of them are smaller blockchains still today, but they continue to grow and continue to get use cases and continue to get tractions. I do expect we’re going to see thousands of big blockchains down the line in the years. And I think the reason for this is similar to, if you look at the history of the internet or how it evolved, right? Then you would see very similar properties as we see in the blockchain system today. We started with dozens of networks, then it went to hundreds, then it went to thousands. Many of them kind of optimize for specific applications or specific needs of their user base or demographics. And I think we’re starting to see a lot of the early signs and a lot of the same momentum happen in the blockchain systems today.
Philip Winston 00:03:10 Okay. One thing I wasn’t clear about, I know cryptocurrency has only one use of blockchains, but today I assume I can exchange cryptocurrency from one type to another. So, if I have ether and I want to use a service that’s on solana, presumably I can exchange between those two. Is that not a form of interoperability, or are we talking about something more pervasive or more deep than that?
Sergey Gorbunov 00:03:36 Yeah, I mean, I think exchange in a value through like a centralized provider, right through an exchange is, actually a form of interoperability, right? And the centralized exchanges, to date, they’ve been actually the only interoperable systems that have scaled, right? You take an asset on one chain and you swap with one asset on the other chain. Now I think we’re in a pretty exciting space in the blockchain system where we’re actually starting to see interesting applications been built, right? Decentralized applications, web3, open finance, NFTs, and so on and so forth. And so, for those applications to interoperate and allow them to do their functions and some of them could be as simple as swapping an asset from chain A to a chain B or some of them take a loan against my asset, but those are inherently decentralized applications, right? And like to connect them together we similarly need decentralized and open software stacks and the technology to do that. And so that’s what interoperability is about is like allowing these applications to continue growing, to continue being as scalable as some of the centralized applications like centralized exchanges, but without having to add friction and kind of concentration in the process of centralized parties.
Philip Winston 00:04:48 Okay. Yeah. We’re definitely going to get more into applications in a little bit. One thing I wanted to also clarify is, I guess there’s a series of documents called ERC, which is kind of like RFC is for the internet. I guess these are for Ethereum and there’s one called ERC 20. Can you explain a little bit what this is and how it relates maybe to the proliferation of different types of either blockchains or just of currencies on blockchains?
Sergey Gorbunov 00:05:17 Yeah, no, it’s a great question. I mean, one fundamental kind of use case of a blockchain system is to be able to create a new asset on top of it. So, for instance, you want to create a tokenized version of land as property, right? So, that’s one type of asset, or you want to build your own kind of governance token or digital coin that represents a business or an operation that you were trying to set up. So, how can you do this? One way of doing it is you go and build your own chain from scratch, right? But that maybe it’s not as simple if you’re a one-man kind of developer that wants to have these assets being created like overnight in a couple of hours. So, platforms like Ethereum and ERC20 asset, ERC24 format trying to solve this by allowing people to easily create their own sort of assets or forms of assets on top of existing blockchains, right? On top of Ethereum, like avalanche.
Sergey Gorbunov 00:06:12 And you can go to other blockchains and do this, and you can do this in five minutes by executing a couple of command calls and a couple of function calls. And then you can define your own rules for this asset. How many of those assets do you want to mint? What are the transfer ownership rights, who is the owner behind the asset? And you can kind of customize it as you need it for your own use case and application. And so, the ERC 20 format is one example of an asset class that’s easy to create, easy to use. And then you, as a developer can integrate it in your application or kind of build a use case around it.
Philip Winston 00:06:48 Okay. I think this might be related to, I’ve read about different layers for blockchains, different layers. Can you not necessarily go through all of them, but just kind of explain from an interoperability point of view, what layer are you inter-operating at? Or is it multiple layers?
Sergey Gorbunov 00:07:04 Yeah. Great question. I mean, I think on the high level there’s notion of like layer ones and layer twos. Right? And I don’t necessarily think they’re quite accurate in some sense. Layer ones I think are pretty clear and what is a layer one for everybody, it’s basically a blockchain. Okay. You have a set of notes, those notes execute a consensus protocol. The consensus protocol allows you to write data into this distributed system and allows people to read data out of it. Right? So, that’s like a layer one. Layer two is very similar in that model, but some of the properties of these distributed system may be inherited from other systems, right? So for instance, security of my chain could be inherited from a security of your chain, right? Through various mechanisms, like transfer rights.
Sergey Gorbunov 00:07:54 And so that’s what people refer to as layer two. But I think kind of, for all practical purposes, it’s, it’s a chain thatís sort of instantiated differently somehow in the ecosystem. The way we think about interoperability, and specifically what we’re doing at Axelar is we’re thinking of it as an overlay network that sits across multiple blockchains. Right? So, I think one example of overlay networks are players like Akamai. So, for those that are familiar with a traditional network and an infrastructure sort of Akamai sits in an overlay network that has their infrastructure built around different ISPs. And then it delivers service for the internet that allows people to efficiently deliver content from a source network to a destination network. Right. And so similarly we think of Axelar as a similar type of a service overlay network that spans across multiple blockchains. And there’s a network layer and on top of it, there is an SDK and an API layer that makes it easy to interact with a network, but it sort of sits as a layer above that, that spans all of the other blockchains. So, I don’t know what number we want to give it or, but I think that’s a high level.
Philip Winston 00:09:02 Yeah. It’s interesting. The analogies with the internet or with networking, I guess in some sense, a blockchain is a network. You have nodes and you have connections. And like you say, you have then multiple networks connections between networks. So, it’s interesting that this is new, but also, referencing stuff that’s come before. You mentioned consensus. The two shows I mentioned at the beginning have more details. We’re not going to get into the full details, but are there many different types of consensus? And does that affect interoperability? I don’t know if the proof of work and proof of stake, if those are considered consensus or maybe those are incentive mechanisms, but just trying to get a lay of the landscape and what challenges it presents to you?
Sergey Gorbunov 00:09:47 Fantastic question. Yeah. So, there are many different types of consensus mechanisms, right? There is going to Nakamoto proof of work consensus mechanism. There is these 19 types of consensus mechanisms, right? These 19 consensus kind, traditional consensus algorithm that has been used at least in academic literature for many decades. But finally started to find its way in the blockchain systems as well. It has been created in various shapes and forms with there is properties, there are newer consensus protocols that people have built including the protocols behind Algorand, like Avalanche and so there are many consensus protocols. And back to the point, this is exactly what makes the interoperability as a challenge and problem, right? You’re not speaking with systems that have the same interface or the same properties you have to talk and translate from systems that speak very different languages, have different varied formats of what is considered for a transaction to define, right?
Sergey Gorbunov 00:10:47 Maybe for Bitcoin chain. It’s like, is this transaction six deep in the block, right? Then that takes an hour for other chains, maybe it’s just a couple of seconds. Then you have instant finality and then you have to translate the messages from one format to another. And so yeah, I think just the vast array of different software stacks and consensus protocols people have built is what makes interoperability challenging because you have to translate all of those things in the process. And then back to your previous point about centralized exchanges, being interoperable systems, you actually see players like Coinbase take like six months to onboard another chain that has like very different rules because like, it’s not a trivial task. But we have actually built, with Axler, there’s a software stack and a platform that makes it super easy to onboard new chains, right? Regardless of the consensus mechanisms like 10, 15 minutes through the platform, you can run through assuming that has certain EDI and UVM support then we’re going to continue scaling from there. So, that, that was really one of the core properties of what we wanted to achieve is that we want to keep on scaling, but want to be able to make those connections as easy as possible without having to spend six months of engineering work to do that.
Philip Winston 00:11:57 Sure. And I guess something that comes up a lot are the idea of a validator. Is that something that’s common across all blockchains or is even that, dependent on the implementation, having validators or not?
Sergey Gorbunov 00:12:09 I mean, some ecosystems call it differently. Some call them validators, some call them miners, right. Then Bitcoin, because they’re using a lot of process and power, but the notion is pretty similar on its own is that certain nodes in the system are allowed to produce blocks. Let’s say that. Right. And so in the Bitcoin networks, those are minors. In proof of stake networks, those are validators. And it is a kind of a, what makes the consensus protocols sticks, right? Special nodes that are actually running the underlying consensus mechanisms and reaching these find articles.
Philip Winston 00:12:43 Okay. So that gives me the sense that each blockchain is not totally from scratch unrelated to the other ones. There are similarities, but there are differences, which makes sense. So, let’s talk about programmability on blockchains. Was Ethereum the first programmable blockchain, or is it just the most well-known and is programmable blockchain, is it for implementing just smart contracts or are there other benefits to programmability?
Sergey Gorbunov 00:13:11 Yeah, I mean, I think, actually Bitcoin was probably the first programmable chain, but the programmability there was pretty limited, right? So, you had a notion of script, a Bitcoin script that you can write your logic in, but it’s very limited. And I think Ethereum, I don’t know all the roots behind how they came up with a design, but they said, well, how can we make it more generic, so that we’re not limited the developers to kind of very special script and functionalities, but we can make it, close to a full developer platform, right? It’s close to like a Turing complete language where you can write any program and execute any function. And so indeed sort of Ethereum was a first instantiation of that version, where developers could write their arbitrary code in some sense, right? Then execute complicated logic or simple logic on top of the platform and then the network of validators and minors in that case, validates that logic and allows them to execute it in a distributed system.
Philip Winston 00:14:11 Okay. We’re going to linger on programmability just for a little bit, since we are a software engineering. So, I read, I think it was the Ethereum yellow paper. I’m not sure if there’s a white paper and a yellow paper, but I think the yellow paper had the machine codes or the op codes, I guess, for virtual machine. And it described them in detail. I was pretty interested to see that. How would a developer write software that runs on that virtual machine? I know, say with C-sharp or Java, you write in a high level language, it gets compiled down to the virtual machine. Is that how it works with Ethereum or other blockchains?
Sergey Gorbunov 00:14:46 Yeah. Pretty similar. Right. You have Solidity, I think is a common language that’s used in a kind of Ethereum based execution environments and then developers write their code in Solidity and then they take that code. They sort compile it with a specific Solidity version that produces the bytecode and then this bytecode is what gets actually deployed on the chain itself. And then so, you do have to be careful in the process to make sure that you are compiling, using the right version of the compiler that the chain interprets and understands correctly, so that you donít end up faulted by code. But yeah, I think Solidity, I think is actually pretty straightforward as a language to use kind of, if you’re familiar with JavaScript or Python, like you get a grasp of Solidity, I think pretty easily. That being said you do have to be very careful not to introduce a security vulnerabilities.
Sergey Gorbunov 00:15:42 Then you can talk about it. But I think that’s what makes it challenging to once you deploy your application, unless you put Some type of upgrade logic, it becomes immutable on chain, right? So, what that means is that the code is sort of fixed in. Then you can just easily push an upgrade button. If you find a vulnerability into it, you can work around it. Then you can put an upgrade logic around it, but you’re going to have to do that explicitly. But by default, the code is immutable. So, you have to be extra careful to do audits, right? To find vulnerabilities before the code is deployed to carefully check all the security conditions, because once it’s out there, it’s ranked by a decentralized system and, you can’t take it down.
Philip Winston 00:16:21 You know one detail I wondered about that is, how many different nodes are potentially executing your same program? Is that I assume there’s a lot of redundancy there, but is that dozens or hundreds of times, or is it cross-check? What’s actually running your byte code?
Sergey Gorbunov 00:16:37 It depends on the blockchain in some of them it’s depending on how many validators you have. So, every validator will have to execute it. So, if it’s dozens of validators, then it’s dozens. If it’s hundreds of validators, then it’s hundreds in some systems you have nodes that are also executing similar bytecode, right? So, there is a redundancy there as well. So, yeah, I think that’s sort of quite important in order to reach the consensus, right? Because you have a system that you’re trying to execute in a decentralized environment, then your goal is to reach a consensus on the state of that system, even in the presence of malicious actors, right? So, you can’t trust a single person execute all the functions. You have to trust the decentralized sort of or validators to do that. That being said, there are ways to kind of simplify some of this. There are things like zero knowledge proofs where you can, change the program and model a little bit, then require only a smaller subset of validators to execute the logic. But by default, it is a large number of validators and some nodes that are, that are executed all the logic.
Philip Winston 00:17:36 Okay. So, we talked about Ethereum sort of up the ante for the degree of programmability. Are blockchains that have come out since then sort of matching that level of programmability, or is it getting even more customizable? Like what’s kind of the direction for programmability. Have we already reached sort of maximum generic capability or is it still evolving?
Sergey Gorbunov 00:18:00 So, programmability, I think it’s been expanded on two levels. I think one of them is at the core blockchain level itself. So, projects like Cosmos and Polkadot, for instance, they ask themselves the question, well, what if a developer doesn’t just want to build a smart contract, but they want to customize the rules of the underlying blockchain, right? So, for instance, customize the number of validators or customize what the upgrade protocols should look like for the underlying network, right? So, those are ability to program the network layer itself. And so projects like Cosmos or Polkadot, they allowed you to kind of a program on a lower level than the underlying network and this distributed database. So, that’s one avenue of expansion and many projects kind of have benefited and build their own software stacks, customizing a number of validators, their programming environments.
Sergey Gorbunov 00:18:52 And then the second. I think programmability aspect is like, what language do the developers actually interact with the system right? In Solidity and Ethereum virtual machine or definitely examples, there are others. So, there are people writing code in Rust. There are people kind of writing code in JavaScript. So, first is Gorik. And so they built their own chain and with their own program and environment on top of it. And so the programmability on top of these blockchains, I think continues expanded to support different languages and different frameworks. That being said, I think most of the changes today that have gained traction, there are kind of Solidity and Ethereum based outside of Ethereum because that’s what early developers were familiar with and they know how to just take their code and kind of deploy it on a different chain and continue scaling from there. But I do expect to see, I think, more variety over the coming years.
Philip Winston 00:19:46 Okay. Let’s talk about applications from the user’s point of view for just a little bit, and then we’ll dive into existing operability methods and then the Axelar or network in particular. So, can you give some examples of distributed applications that would be improved with better interoperability? So, something that’s maybe possible today, but would be much easier or something that’s not possible today that would become possible if interoperability were sort of a solved problem or an easy thing for users to do?
Sergey Gorbunov 00:20:17 Yeah. I mean, I think, one example is to go back to this application of exchange, right? So, today we’re starting to see early examples of DeFi applications that allow people to swap one token for another. So, at its core, if you build one of these applications, let’s say on an Ethereum chain, then the assets that you can allow users to swap are limited to these secure C tokens that are built on Ethereum, right? So, you can’t take an asset like Bitcoin and allow them to swap in, in your application. You can’t take an asset from a Cosmos chain and allow it to be swap for an asset on an Ethereum base chain. So, who can do this? Only the centralized exchanges can do this, right? And as we go back to what we described, but these DeFi applications want to continue expanding, reaching more users, getting more distribution and liquidate it.
Sergey Gorbunov 00:21:04 And so this is a simple example where you can post this application on one of these chains and then connect with interoperability later to allow users to swap an arbitrary asset in the ecosystem, through your application that may be hosted on a specific particular chain. And so I think that’s one example, we can continue thinking about them. Like another one is for instance, NFT transfers, right? So, NFD has been issued a lot over the last year, but many people want to see applications around that. For instance, I want to take a loan against my piece of art. If my art and NFD representation of it was minted on one chain, but the application where I want to take a loan against it lives on a different chain. Like I can’t do this, right? Like I can’t even go to a centralized exchange because what do I do? I sell my art so I can take some other assets? I want to keep my art, but I want to take an asset from a different chain? So, kind of centralized changes don’t work at all in this case. And so through connecting the chains directly through a decentralized protocol, you can allow users to still keep their art, take a loan against this, lock it in some application on a different chain, take an asset in return and use it somewhere else and kind of continue from there.
Philip Winston 00:22:14 That’s interesting. I didn’t quite understand that even simply exchanging could have benefits of being decentralized. So, I guess the idea is a centralized exchange could be a single commercial entity that could decide to change the rules or to take it down or maybe an attacker or something takes it down or it gets hacked. Or there are those kinds of some of the concerns that people have with centralized exchanges?
Sergey Gorbunov 00:22:37 I mean, I think those are some of the concerns, but at the very core of it, I think kind of a decentralized open stack allows people to continue innovative and reaching audiences that centralized stacks cannot do on the very core. Right? So, if there is a new algorithm that you want to experiment with, if there is a new type of a way of an exchange that you want to experiment with, you can take a look at other people’s code. You can take a look at others, people, data, you can understand what they’ve done. You can understand how they’ve kind of captured users. You can replicate it in a similar environment than a similarly decentralized stack and get a distribution from all of these blockchains from day one, right? Like centralized exchanges. Don’t have those things. They they’re bound by an entity, a jurisdiction.
Sergey Gorbunov 00:23:23 And an operator behind them. That’s responsible for the distribution. And I think just the power of building around open systems actually allows you to go much faster and innovate much faster, where I can keep on building on your work. You can keep on building on my work. We can keep on improving things. We can reach all of the users, same user base. Right. All the systems are open. So, it becomes a question of who has a better product, as opposed to who has spent more on marketing, right? Then like satisfy and regulatory regimes and figuring out like how to create another partnership with another provider.
Philip Winston 00:23:55 Yeah. I can see that. How about one more application, I wouldn’t say not financial, but maybe less purely financial. Is there any other that come to mind that are maybe not possible today, but you could see happening, I’m just trying to frame the benefits of interoperability for people that maybe are not clear exactly.
Sergey Gorbunov 00:24:13 Yeah. So, I mean, I think one example with blockchain, such as Falco. So, I don’t know, for those of you that are not familiar Falco and then IPFS or decentralized blockchains and systems that were built to store information and knowledge in a lawn forever, effectively. Right. So, you can think of it as an immutable ledger where you can write lots of data and people can host their websites on it. People kind of host their NFTs music, arts. So, it’s the ledger that has been optimized to store I think as they call it like a human’s most important information. So, it’s an archive of, of information. On its own, that ledger right now in some sense kind of lives in an isolated system, right. And there are APIs to interact with it, and there are ways to connect with it, but you can’t really build interesting applications around that data as of right now.
Sergey Gorbunov 00:25:08 And so by connected this chain that has been designed around the specific use case in mind with other chains that have programmability, for instance right? We can continue expanding interest in applications around it, right? So, maybe you can host a social distribution application on one chain, you can connect it with something like IPFS or file going on another chain. You can read data from it, you can write data back to it. And then you get to interact with this two different environments that have been optimized for different use cases. One is for file storage and the other one for programmability, and you can compose them together.
Philip Winston 00:26:24 That’s really interesting. So, I can imagine, instead of evolving one blockchain to rule them all that has every capability we could tie them together and mix and match. You mentioned IPFS. I think that’s the interplanetary file system. Is that what it stands for? Yeah, that’s an ambitious project, but I think it makes sense. So, I guess that leads to a question, which is how big are these blockchains in terms of data? So, like the blockchain is a chain of immutable blocks and, the validators in some cases have to download the whole history. Is that becoming an obstacle? Is that sort of just happened to be a size of that validators can download or where’s that all heading?
Sergey Gorbunov 00:27:09 Yeah. Most of the blockchains you have multiple modes of operation, right? You can run sort of an archival node that stores all of the data that has ever been produced by this chain. You can run a server, a full node, and you can think of it, a full note as a note that stores enough data to be able to validate transactions on the latest state of the system, but nothing old. Right? So, if there is a transaction that happened in the past, but it’s no longer relevant, I don’t necessarily need to store it because, it cannot be, double-stranded cannot be executed again. And I’m not in the business of storing old and archival data. Right? So, in that case, it’s a full node. It’s typically like a fraction of the archival nodes in terms of size. So, maybe it will talking about depending on the chain from tens of gigabytes, maybe hundreds of gigabytes of data, but it’s only sort of the active state of the database.
Sergey Gorbunov 00:28:02 You also, have modes of operations such as light clients, right? So, on light clients or even lighter objects, maybe they only store a couple of gigabytes or even less, and they only store information relevant to them. So, if I want to monitor a specific account and I want to understand what transactions are happening from this account, I can do that. Or I can talk to another full node and ask them for some information, or I can talk to archival note and ask them for it, a state of, uh, an archival transaction. So, you have the different modes of operation, right? And the sort of requirements of course differ. If you want to be an archival note, that’s the heaviest, if you want to have a light note, that’s the lightest that being said, I want to mention that there are techniques to reduce storage as well, right?
Sergey Gorbunov 00:28:46 In all of the blockchain systems. So I think proof systems, or like zero knowledge, proof systems and protocols like Mina, I think as some examples that apply in more advanced kind of cryptographic protocols in order to compactify the state and compactify the information. So, that they can be validated more efficiently. And nodes don’t have to store hundreds of gigabytes. They can store only a couple of actual megabytes of data or even kilobytes of data in order to validate the state transition. So, all of those things are possible, it’s just the question of how and when we’ll get there.
Philip Winston 00:29:20 Yeah. I mean, that really rings true with sort of how active the space is, how much experimentation is going on, how quickly things are evolving. So, whenever you see a problem that looks like it’s going to be a limitation or sort of a hard stop, and it’s going to halt progress, it seems like there’s people that are working around it or discovering new techniques. So, that’s an interesting aspect of the space. So, getting into interoperability a little more specifically, let’s first talk about some existing methods, again, like with the layers. I don’t think we need to go into them all, but I’m just going to list off some, and maybe you can pick ones that particularly are good at contrasting with Axelarís approach or that Axelar did build on, or just trying to like frame what are the possibilities here? So, we talked about centralized exchanges already as a form of interoperability. There’s something I’ve read about side chains, wrapped assets, token bridges, federated Oracles, just to kind of paint the picture of, I guess, what led up to Axelar and what methods are, or what methods are being developed in parallel, or just to give us some idea?
Sergey Gorbunov 00:30:27 Yeah. So, I think effectively what happened in the ecosystem is the following. We had early examples of blockchain, Bitcoin, Ethereum, right? Like 2013, 2015 interest in applications. Then 2017 to 2020, all of these other chains have been built, right? Many of them optimize for different consensus protocols. What has happened in parallel in there is that people realized that the interoperability is going to be an important topic. Right? And so some early examples of interoperability are projects like Cosmos a Polkadot the talk about interoperability within their own ecosystems, right? So, I call it sort of consensus dependent interoperability. So, meaning that they have designed protocols that have their notion of sort of side chains or chains that can talk to each other through the protocol, that’s kind of native to the underlying consensus. So, that works fine, but those protocols do not scale and don’t work to connect with other ecosystems.
Sergey Gorbunov 00:31:22 Right? So, if another chain doesn’t have the same protocol baked in and the consensus layer, it’s very hard to connect and interact with it. And so then the last year we saw an array of all of those solutions that you mentioned, like from token bridges, like federated Oracles. And the issue with all of them is they’re actually centralized parties that are solving the interoperability, right? So, just like centralized exchange can allow you to swap one asset to another. You can build a centralized database that allows people to take their token know rapid in some other form and move it on another chain it’s representation. But in this process, because there is a centralized party that you’re relying on, we’re adding a lot of friction in this process, be a lot of trust assumptions. So, if this centralized party that moved the asset kind of goes down and it gets shut down or has a quality of service issues, then the representation of the asset that you obtain on a different chain can no longer be moved anywhere else.
Sergey Gorbunov 00:32:21 Right? Like you’re kind of stuck with it. So, you pretty much lose in it. And finally data won’t allow for composability of applications, right? Like, as we talked about earlier, if you have an application on chain A and you have an application on chain B, how do you allow them to talk to one another? Right. Well, if you’re talking to a centralized party on the back end, well, might as well just build a centralized database and the centralized application doesn’t make sense. And so this is where, kind of the world that we’re stuck in over the last year. And now that’s kind of the way we approached Axelar. And the way we’ve designed this stack is to satisfy a couple of core properties. One, keep it decentralized from day one. So, it’s an open consensus. It’s an open system where anybody can join and run a validator.
Sergey Gorbunov 00:33:00 You can run a note if our validators go down, there’s a state, you can take it, you can run your own validator, right? And kind of continue working with the data itself to make it easier, to create connections with different ecosystems. So, just like we have consensus, specific protocols and centralized parties can actually integrate with them. We want to have a similar property where a decentralized system can understand multiple consensus protocols and interact with them. So, that was the second property. And the third one is a kind of a general programmability and the composability that we’re talking about, right. Allowing different message requests to pass through the network and allowing developers to customize what those messages that they want to pass. Right. So, we talked about three use cases today, but if you have a 4th, 5th, 10th, a hundredth use case, we still want to be able to support it. And you shouldn’t have to go and ask us, well, could you deploy this protocol? Could you do this for me? Like, no, it’s an open system. It’s an open programming environment where people come in and code and kind of continue passing the data as they want through the system and not have to rely on it, going to centralize operated behind the scenes.
Philip Winston 00:34:04 Okay. Let’s get into some specifics about your solution. So, we talked about analogies with internet. I think one of your pieces of technology is this cross-chain gateway protocol, which you draw in an analogy with BGP, which is a border gateway protocol used by internet routers. Can you explain the analogy a little more and also, just dig into what this cross-chain gateway protocol is like?
Sergey Gorbunov 00:34:31 Yeah. So, I’m in, I think on the high level for those that are familiar with protocols like BGP, like those protocols at the very core are responsible for connecting multiple autonomous networks, right. And being able to route information and deliver information from them in one shape or form. And so, they’re actually a fundamental, and I think a good example you can actually see from a couple months ago when Facebook misconfigured their a BGP routes and what had ended up happening and like the whole Facebook network and like applications like what’s up, we’re just disconnected from the rest of the world. Right. And so that’s exactly a use case for a BGP protocol where it’s network. However, it was configured was talking with the rest of the world and other networks. And BGB was a protocol that made those kinds of translations and connections in the process until Axelar as a network, you can think of it as a similar type of routing layer that underneath it has certain functionalities that allow you to configure these routes across different shapes.
Sergey Gorbunov 00:35:29 So, you can come in and you can say, okay, I want to make a connection to this ecosystem A, I want to make a connection through this ecosystem B, here’s the path that’s going to happen from a chain A to a chain B. And along that path, the assets or the information can flow, right? So, and then our cross chain gateway protocol is simply a set of commands and a set of API is a set of kind of standard transactions that we expose that will allow us to configure all of these different rules and make these new connections across different ecosystems and our, the network underneath it will support these functionalities.
Philip Winston 00:36:03 That’s interesting. So, are you saying that there actually could be interoperability paths that go through multiple chains and sort of how many chains might be possible? Or is it a question of finding a sort of a point to point connection?
Sergey Gorbunov 00:36:18 Yeah, So, I think it’s an interesting question. And I think the answer is that I don’t know how it’s going to shape up and I think we’ll see, right? If you look at the history of kind of the internet again, then you have hundreds of thousands of networks, right? It’s mostly, you have to go through like six or seven hops to go from a source to a destination, right? Those are like the averages in the blockchain systems that becomes a little bit trickier because even though you can technically go through multiple hops, every hop that you take along the way, you’re going to have to take some trust assumptions in the process, right. Because if I go through your network and I rely for your network to verify information and relate to some other network, then I’m trusting you on network. I’m trusting my network, I’m trusting the destination network.
Sergey Gorbunov 00:37:02 Right? So, the more hops that you add, in some sense the more trust assumptions that you have to make. So, that’s why I think one of the things that we’re starting to see is Axelar or like Cosmos hops, they’re effectively serving as this universal route in networks, right. That have a trust underneath it, but then they connect with many other ecosystems. And then you only need to trust that a single network to go from A to B, as opposed to having to trust three or four different networks. If there are, there are always connections in this process. How it’s going to continue shape it out? I mean, I think we’ll see, it’s an interesting question because the properties, this is where the properties of the blockchain networks and the internet are diverging a little bit, right? On the internet, the network itself is unreliable, right? And there are no security properties from packet delivery. For the most part, you tell me the packet, I have to build another application layer protocol on top of it to verify that packet. But in blockchain, we, at the very core of one, I have this verifiability and authenticity property. And that’s why having these kind of hubs in the middle between all of these different ecosystems makes a lot more sense.
Philip Winston 00:38:09 Okay. And a second protocol, I think this was mentioned in your white paper. I think that might be where I’m getting, this was this cross-chain transfer protocol. If the gateway protocol is going to find a path between two blockchains or a path, yeah I guess between two block chains, this cross-chain transfer protocol is going to actually transfer the token or the contract or the asset, or what’s it going to transfer?
Sergey Gorbunov 00:38:35 Yeah, so the gateway protocol is a kind of a network layer protocol thatís responsible for executing the message and deliver it from one source to a destination. And, and along the path, and the transfer protocol is more, you can think of it as an application layer protocol that allows developers to write a message on the source chain, in a specific format to an underlying gateway. And then the cross-chain gateway protocol will take that message routed, deliver it to the destination chain, understand how it has been executed and call the receiving application on the destination chain. Right? So, the transfer protocol is you can think of it as a layer above the network layer that makes it easy for the applications to interact and benefit from all of these cross-chain infrastructure.
Philip Winston 00:39:23 Okay. One term I saw, I’m not sure if it’s totally related to this was a threshold account. Is that something to do with this transfer?
Sergey Gorbunov 00:39:30 Yeah, so whenever you executed kind of cross chain, you have to do two types of requests, you have to process like read requests and write requests. So, I need to be able to read from a source chain A and I need to be able to write on a source chain B. So, read requests they’re somewhat straightforward to do, like you can call and node of the chain, and then you have to have a kind of consensus or a majority of people that are calling all those different nodes and finalizing transactions. For the write request, you have to allow a set of validators or a set of parties in order to collectively authorize write operations on the destination chain, right? And you can execute those things in multiple ways. In all threshold cryptography multi-signature is various like proof systems. There are all these examples that can enable you with the right functionality that effectively says that if you have, let’s say a hundred validators and majority of them, or some subset of them need to collectively authorize a message or assign a message in order for that message to be valid on another account or another destination chain. So, threshold cryptography, multi-party cryptography, multi signature, they’re all examples of protocols that can allow people to collectively authorize a decision.
Philip Winston 00:40:45 Okay. And you mentioned that low level internet protocols don’t typically have anything to do with security or any promises of security, but obviously with blockchain dealing with financial assets, it’s a big concern. So, I saw it broken out into these terms, trust, high safety, high liveness, I guess, decentralized trust, high safety, high liveness, are those three different things that are worth teasing apart? Or is it just all security?
Sergey Gorbunov 00:41:13 There are, I think, worth teasing apart, right. Because I think security is so generic that in some sense, that doesn’t mean anything, right? Until what it means. So, yeah, I think those three kind of decentralized security are I think something, we’ve talked about already, which is a property of not having to trust a single operator and having a protocol and a kind of system that can be supported by anybody in the community. So, that’s a decentralized property. Safety and liveness, those of core properties of consensus mechanisms, right? So, liveness says, under what conditions is my system going to continue making progress, right? How many nodes do you have to participate in the protocol? How many if the protocol like aborts how do we resume it? And then safety is a core property of any blockchain system that that’s what allows us to trust it.
Sergey Gorbunov 00:42:08 Right? So, meaning that it allows us to verify that the block of transactions or a specific transaction is valid according to the rules of the consensus protocol, right. Even in the presence of malicious actors. And this is what traditional distributed systems don’t have, right. If there’s a single, like malicious actor in a traditional decentralized system, they can typically corrupt data of many other parties, and nobody will notice it. But in a blockchain system, that’s what it kind of prevents some of these properties, is that some malicious validators cannot cause harm in the system and affect other people to take a different ground truth as the verifiable information that that just cannot happen.
Philip Winston 00:42:48 Okay. So, is Axelar a delegated proof of stake mechanism? Is that the consensus mechanism or is that the incentive mechanism?
Sergey Gorbunov 00:42:58 It’s more of an incentive mechanism, right. So, how do you run a consensus across validators? And that’s, what’s called to delegated proof of stake consensus, similar to projects like Cosmos or Polkadot, where users that have a certain token that have a voting power in the system, they can delegate this voting power to operators that are running full nodes and participate in the consensus. And those validators then kind of serve in the consensus on behalf of the users with their voting power. Right? So, delegation is this process of users simply delegating their vote in power to another validator that guarantees a certain uptime for everybody else in the system.
Philip Winston 00:43:37 Okay. So, how many delegates are there? Does this fluctuate over time and how are they selected? Just trying to give an idea of sort of the dynamic runtime aspect here. Like what’s kind of really going on.
Sergey Gorbunov 00:43:49 Yeah. I mean, how are they selected? They’re selected based on the voting power that users delegate to them, right. So, everybody chooses who they want to delegate their stake to. And then you can say, well, let me take the first 50 validators, and those are the validators I’ve kind of run consensus, or you can take first hundred or first 200, and it is a parameter in the system. But as a parameter that gets adjusted and will be adjusted depending on scalability and the kind of other constraints that we’re seeing on the network. I think for us, we’re going to start with something like 50 validators, but it’s a kind of tunable parameter in the system that you can keep on increasing as you need to.
Philip Winston 00:44:24 So, would it be correct to say that Axelar is a blockchain or it has the blockchain, or it uses a blockchain? What’s kind of the relationship there?
Sergey Gorbunov 00:44:33 Yeah. An excellent network uses consensus and blockchain in order to process cross-chain transactions.
Philip Winston 00:44:40 Okay. That makes sense. And I guess I came across another term here was read-write Oracle. Is that fair characterization of how Axelar works or is that something else?
Sergey Gorbunov 00:44:52 Yeah, no, I think that’s a fair characterization. Right. Then afford an application to talk with other ecosystems. You need to support read requests and write requests. Right? So, in this case, you can think of Axelar as this protocol in a network that you can ask to pull the information or write information on your behalf and the network processes this under the hood.
Philip Winston 00:45:11 Okay. You mentioned Cosmos and Polkadot a few times, are these things, Axelar will have to inter operate with, or are you trying to replace them in some form or what’s the relationship between these different projects?
Sergey Gorbunov 00:45:24 Yeah. We’re interoperating across them. Right. So, actually Axelarís stack was built around kind of Cosmos as decay, which kind of going back to your question earlier about the programmability is what allowed us to program the network layer itself. Right. So, we have to customize the validators, customize the logic that they’re executed. And so we’ll build around the Cosmos decay and through our protocols, we can connect with both Polkadot ecosystems, as well as other ecosystems. We also supporting kind of Cosmos native interoperability protocols like IVC and doing kind of translation in the middle between that protocol and our protocol to talk with Polkadot. So, yeah, through Axelar those ecosystems affected has now become interconnected.
Philip Winston 00:46:04 Okay. How about Axelar, the project and the company? Is it a standard venture backed company or any part of the governance itself be distributed through a distributed autonomous organization or some other mechanism? Just trying to understand the relationship between the company and the project, I guess.
Sergey Gorbunov 00:46:22 Yeah. I mean, there is kind of an Axelar competent, that’s built in an initial implementation of the software and the protocol, right. That being said, the network itself and the governance around it is going to be decentralized and open down the line. It has a similar upgrade protocol. Like other proof of stake networks have built their own Cosmos educate where a community can propose a change. If that changes implemented by either our software development team or some other development teams, that change can be adopted in the consensus or in the rules, new integrations can be made and so, on and so, forth. And yeah, users can participate in the governance, propose upgrades, proposed changes to the parameters like numbers of validators rewards. I think we’re definitely going to be continuing to contribute, but it is an open system and that’s what makes it real scale is the fact that anybody can contribute and anybody can build around it.
Philip Winston 00:47:17 Okay. We’re kind of starting to wrap up, but what are some milestones coming up for Axler? Either the protocol or the company in 2022? Like what do you see as some of your goals?
Sergey Gorbunov 00:47:28 We’re continuing to sale actively and starting to actually deploy our network on the main net. So, I think a couple of weeks ago we announced that we started the rollout of the network. So, that means we started, we built initial connections across half a dozen of ecosystems, first use cases and kind of asset transfer applications. And similar ones are starting to go live and we’re going to continue turning on the network over the next four, six months, gradually turn it on various functionalities that we’ve been working on board in ecosystem tools like validators, developers, dashboards. And really the next years for us will be how do we take every application and allow it to go across-chain and allow it to go multichannel right then? So, we’re going to work closely with our developer community, with different applications on different platforms to give them this capability over the next year and alongside with it we’ll be building on the backend and kind of supporting all the infrastructure.
Philip Winston 00:48:24 Okay, we’ll talk about how people can find out more in a second, but taking a step back. What developments are you monitoring for blockchain in general this year that would impact Axelar and interoperability sort of what’s happening in the space that you’re tracking?
Sergey Gorbunov 00:48:39 Where do you always track it? A new interest in ecosystems, new interest in applications and new interests in use cases, right? So, some chains are being recently launched. Some chains are going to launch over the coming months or weeks, different applications have been built around those. And so we’re keeping a close eye and figuring out where we can help those applications or those chains go global in some sense. And that’s what I, primary driver of how we think about our development than our roadmap is.
Philip Winston 00:49:08 Okay. A lot of companies and startups, they say that the founders started them to solve a particular problem that was personal to them. If interoperability continues to become more robust and more fluid and easier for users, what personally are you most looking forward to as an application that you’d like to see available?
Sergey Gorbunov 00:49:29 I mean, I think to me an ability to just frictionlessly transact and go across multiple ecosystems is what I would like to see. I think as a personal example, I think I onboarded a friend to a blockchain ecosystem when I told them like, go use this wallet, go use this application. And she started playing with it. Like he started generating like hundreds of transactions on one chain. It was a great and like, oh, I became a liquidity provider. I’ve never even heard that term before. Like now I’m a liquidity provider. Like where could I provide liquidity for my $10? Right. Like in traditional finance, that’s impossible. It takes you a $10 and you can, you can’t do anything with it. And so just seeing like in a regular audience and folks that are not familiar with the blockchain, unlocking this different kind of a use cases in the power of decentralized finance and other open systems, I think it’s super powerful. At the same time, this friend saw another application on Ethereum and they started to use some bridges and then, we lost him.
Sergey Gorbunov 00:50:24 Right. And then he realized that once he gets Ethereum, he has to pay 300 bucks in transaction fee, like his transfer was stuck and he couldn’t get out. So, that’s how we lost him. And I don’t want to see that. I think I want to continue on board and then regular users that can understand the power of these applications, give them new opportunities that they could not have behind traditional closed systems and see them build their own use cases around those.
Philip Winston 00:50:49 Yeah. I’ve heard of other fees can get pretty significant in some cases. So, one question is if Axelar was created to work with some blockchains that perhaps were designed long before Axelar existed, going forward, how do you see new blockchains? How would they be developed to work with interoperability from day one? Like what kind of changes now that interoperability is a thing for future block chains?
Sergey Gorbunov 00:51:17 Yeah. So, we have done two things. I think one, we haven’t like an arbitrary support for common software stacks. So, meaning that if your chain supports like Ethereum virtual machine or Solidity, you actually don’t need to do anything to integrate with Axelar. Okay. So, it’s like 10 commands will run through the network or you can run and then you can integrate your chain. You can optimize your consensus kind of governance rules. And in that case, we’re sort of agnostic, right? So, we integrated the software program and the interface, if that’s not available for you, then at the network layer, we have really built these kind of core primitives that you need to make other connections simpler that you can leverage, right. And that comes down to those read functionalities, those write functionalities and those cross-chain process and translation functionalities. And so, at the network layer, we have build those where if you have a very custom environment you want to integrate with, you can reuse those building blocks and write your own translation layer to integrate your blockchain with all other ecosystems. And what we have done is like exposing those building blocks and functionalities that are needed for interoperability at the very core.
Philip Winston 00:52:23 Yeah. That’s where you can really see how things evolve, where you’re, you’re building on everything that came before. But if you’re adding significant new capability, the next person is building upon that.
Philip Winston 00:53:22 How can listeners learn more about Axelar and blockchain interoperability in general, whether it’s website or a podcast, and I can put this in the show notes So, people can see it.
Sergey Gorbunov 00:53:33 Yeah, I think to get started to learn about Axelar, or you can visit our website axelar.network. You can follow us on Twitter. @axelar core handle. I encourage everybody to sign up with Discord. It’s a very vibrant developer community. We have over 30,000 developers that are signed up on it. We have there’s Testnet channels. We have there’s like social community programs where we engage folks to develop content or write their own tutorials around the network or how to use its functionalities. And if you have any questions there, again, feel free to ask. Lots of people are watching those channels and will help you answer them. And yeah, I think just get engaged start building. I think that’s the best way to learn.
Philip Winston 00:54:12 Okay. Can I ask about the name, Axelar: where does that come from?
Sergey Gorbunov 00:54:16 Yeah excellent questions. Well, a big constraint about picking a name is making sure the domain is available. So, that was a big factor, but I think as my co-founder and I, we were thinking through it, where Axelar is a play on words on accelerate in the ecosystem. So, that’s a play on words on that.
Philip Winston 00:54:35 Okay. And how about you personally? Do you have any social media or blog or anything that people could follow?
Sergey Gorbunov 00:54:41 Yeah, I mean, I think the easiest place to start this, to follow me on Twitter @sergey_nog. From there, you can find a couple of links to my website, like some white papers that I wrote over the years, kind of standards and things like that.
Philip Winston 00:54:54 Okay. I’ll put those in the show notes also. Thanks for your time Sergey. This is Phillip Winston for Software Engineering Radio. Thanks for listening.
Sergey Gorbunov 00:55:01 Thanks, Philip. It was great being here.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
