See all Parallel Polis transcripts on Youtube

All right, hey everyone, I'm Alexei, I'm 1 of the co-founders of Intolay. We just had some minor slide issues, but it's the same deck, it's all correct. So today we're going

to talk about mastering cross-chain bridges. We come from a research background, We've been doing research on bridging techniques and how to you know connect different blockchains in a trustless manner for the last 5 years and This talk kind of provides an overview of the challenges the problems and the way forward to you know Which will their centralized multi-chain future? Now I won't take long on this 1, but why should we care about cross-chain bridges? I mean you just heard a talk by Zaki about you know Using it for option functionality and there's so much things that we can actually unlock I'm a strong believer of the option thesis that you know You can customize your chain to certain products and that there won't be 1 chain to rule them all and we're likely looking at like the theme roll up architecture, Cosmos, Polkadot, Appchain, Ethesys and Avalanche. So it's very unlikely that you know only 1 of them will prevail and will all converge towards 1 system, right?

They all optimize for different things and we basically need bridges because it's very unlikely again that they will not speak to each other just like you know in different currencies different states you do have interactions like they're not completely isolated and we'll have the same situation in blockchains in the SQL system in the near future. System in the near future. The issue is that, well, we all try to design decentralized systems, blockchains, or decentralized networks should not be bound to trust a centralized provider. But then when we talk to each other, we unfortunately have to go back and use centralized bridges. And I looked at the volume of funds moved between different chains over the last 30 days And it's over 10 billion dollars and that doesn't count like NFT values and so on and unfortunately the only like trustless volume that we have comes from cosmos polka dot a little bit through like the Intel a BTC bridge and some L2 bridges and that's less than 10% right so we're still like relying on centralized bridge providers and that is of course the potential risk.

So cross-chain bridges

101.

1 important thing to remember and understand is that bridging means depositing. Like if we ignore the complexities of different designs of different blockchains, from a user's perspective what you're actually doing is you're depositing Ether into some other product. This product might be Binance or Bitfinex or Kraken. It might be some cash app or something like that, which is a custodial wallet. Or it can be a roll-up, an L2, that allows you to use the same functionality, but cheaper and faster.

Or it could be a completely different chain. So for you as a user, it's depositing. But of course, we prefer to deposit into a decentralized system than into a centralized exchange. And the goals of depositing or bridging assets are pretty straightforward. We deposit ETH into an app chain.

We use ETH there like any native asset. So you want to be able to interact with all the smart contract functionality just like on let's say Binance You can use your Bitcoin or ether in all of their features You don't have to figure out how to wrap it between these different products, right For you it's like Binance ETH or Polkadot ETH or whatever. And to withdraw Ether back to Ethereum, well you want to always be able to get it back. And the goal is the usability and the user experience should be as simple as depositing Into a centralized exchange and getting it out, right? You don't want to worry about signing different transactions, you know Connecting your wallet to 5 different things and it should be secure, right?

You should always be able to get your assets out of the system. You don't want to end up losing your money pretty clear Now before we dive in a quick reminder on trust models if you are working with 1 single system with 1 single chain What you need is a wallet you trust that the network is secure Otherwise you won't be using it and you kind of trust that the wallet is not corrupted. We've heard recently, right? There's always like wallet hacks happen. And this is definitely something you should be aware of.

And the way to verify it is, well, if the code is open source, there's a big open source community that kind of audits the system. Even if you don't code yourself, you can somewhat rely on systems working. Now, if you go multi-chain, a few things I added on top first of all you need 2 wallets Yes, there's multi-chain wallets But under the hood they are kind of creating accounts in different systems on different chains and provide you with nice interface But you're still managing multiple accounts And then you're now trusting 2 networks. So you're trusting network 1 and network 2 now This is an okay assumption because well, you know, you won't be depositing into another system if you know if you don't trust it, right? Why would you use it?

Otherwise so we can kind of assume that that's okay you need the wallets to work and and that's where things get hairy you need the bridges to be secure and This talk focuses on that specific point now last 1 kind of basic basic kind of points If only exists on the Ethereum chain This means to move it into another system We're actually not taking like, you know Like an Apple from 1 box into the other box, which you actually have to create a representation of an Apple So you think of it as a projection? So you're projecting to the other system that hey I've locked 1 ether And now I should be able to use this 1 ether on this other network But in like in physical terms the ethereum is still locked on the ethereum chain And in computer science terms what this means is you're obtaining a right lock So you prevent any other updates to that Ether coin on the network until you have crossed back over from the other chain. And this also means that if I transfer the wrapped Ether to somebody else, obviously it should not be me who is redeeming Ethereum on the Ethereum chain, but the recipient.

So you want to make sure you propagate all the updates back to the source chain So that was the basics right Sounds simple. So why is bridging so difficult and why haven't we figured out today and This takes us back over a thousand years in history it takes us back to 1 of the oldest problems of commerce, the fair exchange problem. Now, you may wonder, like, oh, how does this even relate to blockchains and so on? But bear with me. In the fair exchange problem, we have Alice and Bob.

Alice wants to buy an apple. Bob wants to get paid. Super simple. What would they do in non-digital times? Well, they'd meet in some marketplace where there's lots of people, there's guards, and they would exchange their goods.

Why would they not meet in a dark alleyway? Well, because Alice does not want to get robbed by Bob or his friends, right? Because She does not necessarily want to trust him. On the internet, however, you don't know who your counterparty is. Think of ordering from Amazon, right?

You're buying some goods, and you're either making the prepayment, or the merchant trusts you to pay afterwards. And essentially, When you don't know who your counterpart is and you have no way of enforcing their correct behavior, you need somebody else to do so. And there's a formal proof from 1999, and this is like actually a very old problem, but in the end, to do trustless communication, Well, you need to trust a third party to make sure that the swap actually is executed. How does this relate to bridging? And some of you may think of atomic swaps, and if we have time, we can come to that at the end.

But bridging means swapping the Native for the wrapped assets, right? You swap ETH for the wrapped Ethereum, and when you go back, you swap wrapped ETH for, wrapped ETH for ETH on the source chain. So someone needs to make sure that this locking and unlocking actually happens in an atomic way, right? You only want to get wrapped ETH if you've locked the Ethereum and vice versa. And that's the bridge problem, right?

So you have 2 actors and 2 different chains. Bob is a potential recipient of Ethereum, let's say, on Polkadot and you really need to make sure that these actions happen atomically. So you need to guarantee that you Bob only gets the wrapped ether if if your has been locked and under no other circumstance, so How do we solve this problem? Well coming from fair exchange or learning from that we know well, we need to pick a custodian So someone and maybe custodian you can pick other words, but someone needs to be in the middle and make sure that the locking and unlocking happens correctly. And this can be a centralized entity.

So someone, a centralized entity, signs messages on both contracts and says, hey, yes, Alice locked Ether in the Ethereum smart contract. Let's unlock and mint some wrapped ether on Polkadot It can be a committee or Federation if you don't want to trust 1 person So you say well, let's pick 20 people in this room They do a multi-sig And they are the ones who kind of agree the majority of them says yes, then we're good, right? But that's a fixed committee, right? It's a fixed set of people. It doesn't change So if you want to have it more dynamic and more open to everybody to join and leave you can go a step further And you can create a separate network that is used purely for bridging, right?

So committees federations you have things like axel are most are you multi-chain wormhole? There's quite a few bridges in like the committee Federation kind of sector You have things like axel are the kind of position of those more towards consensus, right? They have a separate network which connects between different blockchains and you trust that the axel our chain will behave correctly But ultimately the best setup is to trust the consensus of the involved chains So if you only trust ether if you're a member cut out and nobody else So centralized bridges quick reminder, how do they work? I deposit Ethereum into a smart contract, or the smart contract is just maybe an account, or It's controlled by a custodian. The custodian says, hey, I received Ethereum.

Let's mint some wrapped Ether on the target chain. And then that's executed, either manually or automated. But in the end, there's a central party. And if I want to go back, well, I have to ask, Hey, can I please have my theory and back because I'm returning the wrapped assets and of course you need to trust the centralized provider and if a centralized provider says no and Loses axe or like basically they steal they lose access something happens You have nothing that protects you against it, just like with centralized exchanges? So it raises the question, is it really DeFi when we bridge between different chains if the bridge is actually centralized in CeFi?

And if we look at the recent history of bridge hacks, And I'm just listing the ones here that really relate to Private key and access control compromise. So where the bridge broke because it was centralized. There's tons of more hacks, right? Nomad and so on that happened as well, but they're not because the bridge was centralized, right? That wasn't the main reason And then also it doesn't mean that the bridge has to be hacked You know The team might just lose access to to the servers and something might go wrong and in the end you just trusting that centralized Provider just like you're trusting binance when you use binance So the question is how do we build a decentralized bridge?

And as already hinted, we want to use the consensus of the 2 chains we're connecting. So ideally, we want to inherit the security and decentralization of both Ethereum and, let's say, Polkadot, the target chain. And the way to do this is to use like clients so aetherium would verify the state of polka dots and Be able to check state transitions updates of the states this proof-of-stake kind of longest chain and know which transactions happened in a smart contract and vice versa polka dot would have a smart contract that verifies the state of aetherium and The only thing you need them between the 2 systems is 1 honest online party that sends a message the proofs and that's it And this construction is called like lime bridges Sounds fancy sounds complicated, But it's been around since 2014. It dates back to the Bitcoin sidechains paper which basically already back then said look the best way to connect to change these to use these SPV like client proofs because then we Don't need a centralized bridging partner. So question is well why haven't we built them yet today?

And we'll talk about this in the end. So if you look at the scheme, essentially, what changes when we use Liteclient bridges is instead of the custodian or a centralized provider, you have smart contracts. And these contracts are able to verify the state of the other chain cryptographically the same way that you know When you have a light wallet on like your phone that has a light client It doesn't store all the data of a theorem. Usually it stores like some metadata so it can verify transactions same concept here You don't download the entire chain you don't download the entire chain like over here on to Polkadot, you just download the block headers which is much more efficient. So what do I do then?

Same construction, I lock Ethereum, a proof is generated in somebody, forwards that proof to Polkadot, I get the wrapped assets. When I go back, same idea, I return the assets, proof is submitted and I get ether back Now what happens if this relay or this person in the middle is malicious right and does not relay the proofs well, the cool thing about this construction is that I can do that myself, right? And if I'm an application that uses bridges for like for some of the other chain or other products it's in my own interest to actually run 1 of these relayers to generate the proofs and make sure that they're submitted between the 2 chains. And anybody can do that, which is the beauty of this construction. So you don't need anyone in particular.

You can be your own kind of relayer, and you're good to go. Now, quick kind of reminder, like clients, super important part of this construction. We want to know what's going on on the other side. So what we do is we store the block headers, right? So just the metadata which says, okay, hey, like, this is block number X, we're referencing the previous block hash.

This is the root hash of the transactions that are in this block. And then we also, on top of that, have information about proof-of-work difficulty or proof-of-stake state. And that contract verifies, If given 2 different chains, which 1 has the most proof of work or the proof most proof of stake so it kind of verifies whether the consensus executed correctly and On top of that it can then check transactions Security model assumption super irrelevant It assumes that if a transaction is included in the main chain Then it must be valid because it does not download all the blocks It cannot really trace the transaction back to all the executions. It cannot check if there's a double spend It must assume that well if it got into the main chain, That means that all the full nodes in the network accepted it, so it must be valid. Otherwise, somebody would have had to attack the entire network.

So this thing really is secure as long as there's 1 honest party that submits the data from Ethereum to Polkadot and keeps it up to date with the latest blocks. If that's given, this thing works, and you cannot lie to it. So we actually built a decentralized bridge. Before we talk about challenges, let's talk about economic security. If We have 2 chains, let's say Ethereum and something smaller, like some app chain, and we're moving value between them, so the green kind of thing is the value of all the assets moved from the green 1 to the green 1 and vice versa.

If this is the model that we're speaking about, so the actual market cap and the value of the actual chain is less than the bridged assets, we're fine, right? Because it's not really worth attacking this thing and losing all your stake and sending the whole value of this to 0. But if at some point the value of the bridged assets exceeds the kind of proof of stake or proof of work security budget of the target chain, you might run into issues. Now this is purely theoretical, but in the future, if we kind of, you know, have a multi-chain ecosystem, there's a high chance that this will at some point happen. At some point, there will be a chain where somebody decides to buy up the stake or kind of you know prepare the attack and then steal like stable coins Bitcoin where they can exit to a separate system so that's definitely something to pay attention to you know when you're bridging assets over make sure like at least that the value kind of is not completely exceeding the security budget of your target system Now we won't have time to talk about Bitcoin bridges But economic security is also relevant when we're bridging between 2 systems where 1 does not have light clients So for example a Bitcoin aetherium bridge If I want to bridge Bitcoin to Ethereum, right, Ethereum can have a light client for BTC.

It can verify Bitcoin payments and Bitcoin state. But Bitcoin has no smart contracts, so it has no way to check what's going on in Ethereum. And in this case you need someone on the Bitcoin side to simulate the smart contract behavior, right? So you need a few nodes that kind of replicate and pretend to be a smart contract, but you trust them and Enwrap it you see on a theorem today, right? You have WB DC a bit Co is the custodian and you trust Bitco to lock and then release the Bitcoin when you go back and the way to Make this model more secure is to use Game theory and incentives and without going into too much detail because of time But instead of having 1 node you make allow anybody to run the nodes and then you make them lock collateral.

So it's a collateralized system. As long as the collateral is worth more than the Bitcoin that you lock in the vaults, your Bitcoin is safe because they have no incentive of stealing it. Because if they do steal your Bitcoin, as shown in this picture here, you will be reimbursed in collateral. And how this is enforced is by using these state proofs. So you prove to the target chain to Ethereum, hey, I locked the Bitcoin, and these guys need to prove to Ethereum that they actually returned the BTC to you.

And if they don't prove, Then they get liquidated and you get reimbursed So last 2 minutes. I'll probably cut down to 1 minute. So What's the outlook First of all, unfortunately, there shall be chaos. And the reason is we have so many different bridges right now that exist in parallel. And what's happening, we're fragmenting liquidity because wormhole ETH and Axelr ETH are not compatible.

The other issue is that they don't, mostly for now, they support EVM chains. So if you're coming from Cosmos, Polkadot, and other kind of layer ones, you kind of have to either add EVM support or you plug into another chain that has EVM and you have to do multi-hop routing, which again creates even more fragmentation and complexities. And then you as a project, if you're an app chain, you have to decide, do I put my, like all of my eggs in 1 basket and I trust only 1 bridge or do I spray and pray and get as many of them as possible and hope that you know if 1 breaks then I'll still be okay but then I'm fragmenting liquidity and then my users need to choose well which you know version of ether I'm actually going to use Now the other issue is, you know, I've been shilling like clam bridges to you for the last 20 minutes So why don't we have them yet? And the challenge is that it's not that easy To build it's a technically quite complex issue So for Bitcoin proof of work there exist like lines that are built as more contracts We can verify Bitcoin proof of work and and sing like and signatures and everything reasonably efficiently on a theory.

That's possible For litecoin for example that uses at the s script algorithm that is memory hard. It's not possible It's simply not feasible to do that verification in the smart contract So you cannot bridge like on using this mechanism, right? You need to use some off-chain trust a third party and that's actually you know, simply it's a no With a theory and proof of stake or Solana proof of stake, right? So if you input POS, we know it works there's first bridges kind of being designed, and should be launching later this year. With Solana, it's still not quite clear, will it be efficient enough or not?

And what I'm getting at is, there is no universal like-client solution. You're building a like-client for each single chain that you're connecting to and each of them has its quirks, formatting issues and everything you need to take that into account. And 1 thing to really keep in mind that ZK does not solve this. Zero-knowledge proofs may make it cheaper and more efficient to do the verification, but you still need to build the custom circuits and proving it, provers and verifiers for each single chain. And considering that, you know, if it's difficult to build without 0 knowledge you can assume that it's even more difficult to build a proven verifier So we're kind of getting there, but it's a very technically challenging issue However, I'm very certain that like line bridges will prevail you have Polka dot near cosmos already have them kind of between like within their ecosystems and First kind of cross-chain bridges are going live from them to Ethereum later this year I believe and in 5 years my bet is that Between all these big networks, right?

If you look at like the biggest networks in terms of adoption, we will have like climb bridges between them Because and then essentially we can finally rely on Code as security rather than trusted third parties Thanks a lot, and I hope we have maybe a few seconds for questions Otherwise, catch me later. I'll be around.

Hi, kind of, I mean, InterAllay is a nice technology or nice idea, I would say, but I was surprised that it has so low TVL. So I would ask what do you think is the reason? And maybe if you think that the reason could be that the customers need to put collateral if they want to bridge something? That's a very good question.

So maybe first of all, like Interlay is a Bitcoin focused product, right? So it builds the big decentralized Bitcoin bridge. Like-client bridges, if you have like-clients on both sides, you don't need collateral. It works because you know, you have 2 smart contracts for Bitcoin That's where it gets tricky. And I mean we can briefly take a look at this image here So obviously, you know the users don't put the collateral.

It's the vault operators So it's like you as a user if you have Bitcoin, you don't need to put any collateral, you just bridge over. For you, it looks like any other centralized bridge. It's the operators that need to put up collateral. And the challenge so far has been, obviously, it's less capital efficient. There is a capital cost.

And the way to solve this, and there is a blog, actually, that we posted 2 days ago. The way to solve this is to use liquids taking assets as collateral or integrate the collateral into different protocols so instead of you know competing with like the base free risk the risk-free Yield rates of a theorem proof of stake or lending you actually use like Q tokens or a tokens from other components collateral or like liquids taking it as collateral and then you're not competing anymore and Then anything these we've all earned on the bridge is On top and then actually it allows you to scale the bridge much faster So this is essentially what's what we're doing on Italy right now And this will allow to get a much more collateral in the bridge and maybe 1 day get very close to like eigenless restaking Vision, right? So like what you can do is you like use somewhat like risk-taking and it works and we've actually been doing that for last year and it's you know while it's on like smaller networks of course the TVL is not so high but apply this model to Ethereum and you can scale much much faster.

Thanks I think we're out of time. You