New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Web3 is becoming asynchronous. Can we live with it? Sergey Gorbunov

Ethereum DenverMon, Oct 9, 2023, 12:00 AM

As we scale the number of blockchains, layer-2s, and data-availability layers, we introduce asynchronous communication between them. How should developers think about dApp architectures in this world? How will users interact across all these layers? In this talk, we will describe emerging development paradigms that will help build dApps that span the whole of web3, work in asynchronous models, and simplify user experiences. Sergey Gorbunov Co-Founder Axelar Sergey is a co-founder and CEO of Axelar, a decentralized blockchain interoperability network. He received a Ph.D. from MIT, where he was a Microsoft Ph.D. fellow. His Ph.D. dissertation was on designing cryptographic tools for the cloud using lattice-based cryptography, for which he received the Sprowls Doctoral Thesis Award for best thesis in CS at MIT. Sergey is a co-author of many cryptographic protocols, standards and systems. He is an Assistant Professor at the University of Waterloo and was on the founding team of Algorand, where he worked on the core platform design and development and led the cryptography group. https://twitter.com/sergey_nog

Transcript

Good morning. All right. So, hope for all of you that are joining online, you can hear us well as well. Um, so today I want to talk a little bit about um the topic of kind of interoperability. One of the core issues that's happening today in the web 3 space is that it is becoming more more asynchronous.

And so we'll talk a little bit about that and you know some solutions and some approaches towards dealing with those issues. Awesome. Um, I think many people have made the analogies by now that, uh, blockchains are cities, right? They're open, they're permissionless, um, and they're supposed to be robust. So whether or not you're building, uh, in a particular city, you expect it to, you know, withstand nuclear hurricane, electricity goes down, and all kinds of natural disasters.

And so as we get more of these cities being built, um this naturally introduces fundamental asynchronistic questions. How do you go from one city to the other or how do you build a business or an application that can actually span all of the cities at the same time, right? Um and um you know until recently uh the problems of multiple cities or multiple blockchains were really solved in one of the two ways. So one way you could build kind of a a centralized application across all of these different blockchains or across all of these cities to provide synchronicity between them, right? So everything from centralized exchanges to, you know, Celsius of the world to centralized bridging technologies, they're all solutions that were built across all of the cities.

They function very very simply. You have a database, you know, you have an application server. You talk to different, you know, cities of blockchains. You send messages back and forth between them. um and you provide kind of synchronous experience for the users, right?

So that's kind of a one approach and we all know where that leads, right? Uh it kind of introduces uh trust assumptions for the whole ecosystems pretty dangerous and you know multiple multiple um attacks throughout the space. And this is really what we're trying to solve, right? That having to create these types of centralized systems to to actually power um web uh web 3 applications or blockchain applications behind the scenes. And so the the second option that we had when we talk about dealing with uh multiple blockchains is to let applications kind of deploy their apps across multiple cities.

Right? So unis swap is one example kind of that goes and deploys on every blockchain one at a time. Um and let users figure out how to synchronize their wallets across all of them. Right? So as a user you have a wallet on one chain, you get some gas, you use an application.

Oh, you have another chain you want to use. Okay, figure out what wallet to use, figure out what gas to use, figure out maybe how to bridge your token, and then use the application uh on the on the different chain, right? So, from a developer perspective, you're not really doing much other than kind of cloning your application across all of these different cities. And the problems of uh multiple chains are left to deal for the users, right? It's the users that have to flip wallets, pay gas, and figure out how to use one application or the other or the other, right?

So, very very complex experience. Um and I think you know for many of you that have interacted with multiple blockchains it's really really painful and you know it has been a barrier for that prevented us from growing the industry over the last bull cycle right every time you on board somebody in one ecosystem maybe they see application somewhere else they want to use it and it usually takes like half an hour at the very least to figure out how to switch and use an application on a different chain and so on and so forth. So very very complex. Um and these problems kind of fundamentally arise from from from the fact that we have more and more of these layers in blockchain ecosystems being built, right? We have layer ones, we have layer twos, we have data availability layers and so we automatically kind of a lose composable synchronous environment where you can submit a transaction and have it go through or not.

Right? Whenever you have different systems or different layers, it's very hard to achieve this synchronicity between them. And so the only way to do that is by having kind of a asynchronous communication. And uh you know in the model that most of the applications been built today, we just have not figured out how to deal with asynchronous communication in an efficient way from an application perspective. Okay.

And so therefore it was left to the to the users to deal with. Um today you can do better though. So you can build what we call as interchain native applications that take care of these problems with synchronicity for the users using code or using logic right and I and I'll talk through some examples of how that can be achieved but a very high level is that whenever you're building in this archite native paradigm you're completely changing your application semantics right so it's a new architecture that you have to follow you have to follow these message pass in abstractions uh that we'll talk about in a little bit. Um but you at the end of the day you can build something they can span the whole of web 3. All right.

So your applications can scale as more layers uh are uh introduced as more chains are introduced. Uh you can be powered by decentralized interoperability. Right? There's kind of a couple different approaches to that. Um and you can have your application that actually composes with uh with itself or across other applications across these different layers or different blockchains, right?

And so think about it in the same way as if you were to build kind of an application on Ethereum today. You submit a transaction, you know, it has certain atomic properties behind the scenes and you can call other applications, right, on the same environment. you're now able to do that across different chains, right? By using like message passing paradigms and you're able to compose applications across uh different environments. And so the final goal for all this is to really enable very very simple user interactions, right?

So all the suffering that we had before when a user had to go from one wallet to another, you know, figure out how to pay gas across multiple chains, very very very complex and um it can be solved with different architectures and paradigms in the space. So uh if you've never played with a interchain native application, I think one good example is a squid application. So I encourage you guys to check it out. What does it do on the very high level? In a fully decentralized and a permission way, it allows you to swap a token from one chain to a token on another chain with one click.

Okay. So you have like ETH on Ethereum, you want to swap it for AVA X, you can submit and run it in one click. And the the whole beauty is that this is completely decentralized application and the way that it works it actually composes existing decentralized exchanges across different blockchains. Right? So it doesn't introduce new liquidity.

It doesn't create new wrapped assets or anything else underneath the hood. Uh but it's a very very simple uh kind of a way for composing applications uh directly with one another. So let me give you kind of a quick um sense of how how it actually works, right? So if you go and you want to swap let's say from Ethereum to Avalanche effectively what happen there would be a swap that happens on Ethereum that transfers your ETH to let's say like a stable asset like USDC right the USDC would be routed on the back end to the avalanche network and then swapped for Ava X on the destination chain using another DEX okay so effectively you're doing two swaps and you're using some kind of a routing liquidity in the middle it could be a stable asset you don't have to use a stable asset. You can use anything else if you want, but you're really composing two dexes, right?

So, if you were to have unis swap deployed on like two different chains and it has two different pools, uh you can actually compose them together uh with one another and it's fully decentralized right underneath the hood. So, you're composing dexes and because squid in particular is built on top of the axle network which is also provides this decentralized interoperability layer um your application is completely uh trustless. Okay. So, uh very very powerful. I encourage you guys to to check it out.

And so this is what I really mean by intrachain native experience. Okay. We have multiple chains. We have multiple assets that are spread across all of them from a user perspective. You submit a transaction from any chain that you like and you get the result on any other chain right away.

Everything in one click, right? So you don't have to flip wallets. You don't have to pay gas on multiple chains. This will kind of take care of you. the the swap could include like multiple swaps across different dexes across the ecosystems.

Um, but you don't have to think about all this. So, previously an experience like this would take, you know, like half an hour and or an hour for you to to bridge back and forth. Oh, great. My time just went down from 17 to 9 minutes. Um, awesome.

So, um, this is really the end goal what I think of uh, you know, UX and composability across um, different ecosystems. from our perspective right the work that we're doing at Axel um the end goal is always to think about how would the users interact with all the systems and I think the you know the target that we have every time we're building a product or uh you know system is to allow a user to interact with any asset on any chain with one click right like that's the end goal unless we do that the products that we build is just not going to be competitive with web two products right because they're much easier to use they have better UXs and they have better readability So everybody that's building should be striving towards this goal. All right. So how do we do that? Right.

And um you know let me for the last kind of nine minutes tell you a little bit about the the Axel stack and how it works. Um so Axel stack is one of the kind of a building blocks that we're building in ecosystem to allow uh for communication across all of these different blockchain layers to happen very very efficiently and very very securely. Right? So there are three layers to the stack what what we think about there is the axle and network itself and um you can think of it as a router network that's responsible for crosschain message passing delivery and routing and execution layer itself right so if you have a message on one chain the network will know how to deliver it on the destination chain and uh kind of execute it there on top of the network we have various uh services that we're building that allow you to deal with all the synchronicity um or with all of this asynchronicity across chains. So one example is a you know oneclick gas service what we call right.

So the idea is that a user wants to submit a transaction on the source chain and even if transaction needs to be executed across three other chains they don't want to have to pay gas right so all the gas fees are then folded into one payment on the source chain and then underneath the hood various services will figure out how to convert that to cover gas on all the destination chains. Right? So it's kind of a again a service that's built to deal with multiple environments in a completely synchronous way from a developer perspective. Uh and then on the very very top of it is a very very simple SDKs and APIs that we expose to developers to actually consume the rest of the stack. The stack is complex.

There are many many layers but the API is actually simple and I'll show you in a second. Um so what does the network do? So first the network supports multiple kind of interoperability protocols at the core. So if you're familiar with IBC, the network supports it natively. We have a crosschain gateway protocol that supports connections with multiple EVM chains in a in a secure way.

Um the network gives you very strong routing properties, right? So what I call is one to end routing. It's not a kind of a bridge in the sense that you bridge is always pair-wise objects. You connect A to B, but every time you plug in with the Axel stack, you get composability with N other ecosystems that have previously been connected, right? So kind of at the cost of one you get end connections and you get to amplify you know a lot of the work and then from a networking layer you can do everything from asset transfers to message passing to actually compose your applications.

The second pretty exciting uh you know building block that we have built is what we called as the crosschain translation layers. So whenever you have different blockchains or different layers in the ecosystem, some of them speak very very different languages, right? So you have EVM chains that are speaking solidity, you have Rust chains or Cosmos chains uh that are speaking a different language. How could you pass messages between back and forth between them, right? Somebody actually needs to know how to take a payload and encode it in the format that can be executed at the destination chain, right?

So, Axel network uh has one of these properties that understands multiple connection types and message formats and will know how to translate for from one to the other to give you full composability between those ecosystems. From a developer perspective, it's everything is you know abstracted away from with a very very simple API and uh it's so simple that it really looks like this, right? So, if you want to go crosschain, there's a simple call contract function that is exposed through the SDK. You specify a destination chain, you specify a contract address and you specify a payload and you ship your message, right? And then you don't have to think about how it gets delivered to the destination chain and uh you know executed there.

Um now this message by itself will be kind of a asynchronous and so to deal with various fallbacks and things like that there has to be usually some application logic that's written around it to um uh you know to deal with the application level reverts. And so this is where some of the kind of a complexity for building in this interchain you know arises and um you know but there are various ways of dealing with this. Um awesome. I guess in the last five minutes let me tell you a little bit of you know work that we're just starting to do recently at Axel. Um and the the core problem that we're trying to solve is is really the following.

One the number of layers just keeps on increasing. And two, the complexity for building applications in these environments keeps on increasing. So every time we talk with a developer that wants to ship across five different chains, they spend that they say that they spend 70 or 80% of their time thinking how to do it versus actually doing it, right? And thinking how to do it means that you think about your deployment, you think about how do you set up your governance keys, how do you perform, you know, upgrade paths, um how do you, you know, pay gas and so on and so forth. So that's not what we want, right?

We really want to be in the world where a developer can spend you know 80% of the time thinking about the application logic and the deployment across multiple environments and the management you know should be done in 10 or 10 or 20% of the time and so to to solve some of these problems we actually introducing kind of a virtual machine at the interoperability layer itself at the Axel right so Axel as a protocol it's a decentralized proof ofstake protocol it is powered by blockchain technology but with a virtual machine you actually get to program the interoperability layer, right? And actually um that has very very strong properties. Um so the first property that you can do is you can instantiate your own connections at the networking layer. So think about it like this. You purchase the house, right?

Or an apartment. You want to be connected to the internet. What do you do? Well, you you get a modem, right? Or you get a router uh and you either, you know, figure out how to connect the cables yourself or you call a technician that comes in and plugs you in.

Once they make a connection, you automatically talk with the rest of the world, right? Uh with everybody who has internet. And so this is the this is the level of um you know, pluggability that we want to get from the interoperability layers where at the end of the day, you should be able to come in and say, "Okay, this is my router." You know, router in this case would be a smart contract. It gets deployed on a chain.

You you set up some connections, some some relayers and wires, and voila, you're connected with all the other blockchains, right? We're not quite there yet, but this is really uh you know what will allow us um what will allow us to to do this. Um so yeah, a couple kind of a different uh projects that we're launching with the Axel virtual machine is one what we call as the interchain amplifier that precisely aim to solve those issues, right? Allowing different layers, allowing different developers to instantiate their own connections with the rest of the blockchain ecosystems, right? So uh you can you know instantiate them using different technologies zero knowledge proofs light clients it's it's really up to you um and there will be kind of a series of templates and contracts that will help you instantiate the connection and once you instantiate the connection you automatically uh interoperable with and other ecosystems right so it's in the same way as you connecting to the internet you know you're not just connecting to a single network you're really connecting to the whole worldwide web this is the property that we need from these interoperable networks And uh you know this amplifier service that we're building uh aims to solve that.

Um and kind of a you know the end goal with instantiating these connections is is like you could actually have multiple technologies that instantiate connections from one ecosystem to the other using different approaches right so you can have zero knowledge proofs you can have you know like clients RPC verification you can compose those things at the application layer right and you can say I really I'm transferring a lot of value like hund00 million and I want my transaction to be really really secure so you can Say you you will be relying on like zero knowledge and like client verification and you need like two out of two approvals before you execute these transactions in a different environment. Right? So it allows you to compose security at the application layer. And the um the last product that I just mention is um what we call as a uh interchain. It has a property that you can build once and run everywhere.

Right? So as you go across these different environments um you want to be able to orchestrate your deployment using very very simple templates right so if you if you code it using things like kubernetes for instance you know you you have a template you go through it and you specify how your deployment needs to happen right you say okay I'm going to run it this piece of code on this server this is my database you know this is my application server and then kubernetes will take care of the whole orchestration and management of your processes and so as we have more and more of these chains because the development becomes more complex. This is the problem that we want to solve, right? And so this uh master is precisely designed to solve that. You can take your application logic.

Let's say it's written in solidity. You can use this um you know series of contracts deployed on Axelor to specify where you want to ship the application, right? And it would help you ship it. It will help connect everything together. So you don't have to think about bridging protocol, gas payment.

So everything is going to be sort of glued together in once uh and act in a in a coherent like an interchain native way. Um awesome. So I think I'm out of time. Um and I will not leave you with a demo, but I'll hand around and if you want to see a demo how everything works and how you can manage crosschain applications in one click, I'm happy to kind of talk a little bit more about it. Well, thank you everybody for joining.

And here's a QR code, by the way, if you want to learn more. Awesome. Thank you.

Automatic transcript — names and jargon may be misspelled.