Building Bridges, Not Walled Gardens

Transcript

all right there we go um so due to a bit of laziness and mix up on my part we have the unstyled version of my presentation today so about half the slides are going to have styling and most of the actual like meat of the subject won't so my name is james prestwich i've been involved in crypto for about seven almost eight years now so when i started there wasn't like uh ethereum as a thing there was bitcoin and the bitcoin imitators and that's really like all there was um i got down started in crypto by founding a

decentralized storage company back in 2014-ish uh so what i work on all day now is cross-chain communication protocols i had a company called summa from 2018 to 2020. we were acquired by c labs and i work at c labs on cello we build a proof-of-stake evm chain and i lead the bridges team working on cross-chain communication protocols so the talk today is a bit about what is a bridge what is cross-training communication and what's the design space for these things when we're talking about bridging tokens from

ethereum to cello or to matic or anywhere else what kinds of decisions do we have to make about the bridge in order to achieve this and what are the different trade-offs between all the types of bridges out there so we're going to go real quickly what is a bridge some cross cross-chain communication terminology that you'll need to know and then we're going to just dive into like what are the trade-offs of all these applications um i'm going to be taking breaks throughout the talk for questions i tend to cover like really a lot of material very quickly and i want to make sure that everyone kind of stays on the same

page as me so uh every you know few minutes i'm going to stop and see if anyone has questions feel free to raise your hand and i think a couple people with microphones are walking around all right so what's a bridge uh when we're talking about bridging chains or d5 bridges we're talking about an application we're not talking about like a base technology we're talking about something that serves a user need we use cross-chain communication channels to build bridges bridges aren't the only thing you can do with cross-chain communication channels and there are a bunch of different

choices of channel technology you can use to build bridges and the goal of a bridge as an application is to represent tokens from another chain so to represent ether on sello or to represent the ube swap token on ether or solana or near or anywhere else in the ecosystem so you know putting it all together a bridge is an application that uses cross-chain communication to represent tokens from another chain and the goal is to use your cello in ethereum defy or vice versa okay so glossary uh

it gets very difficult to talk about anything in a cross-chain environment we can't just say on chain we can't just say it's an erc20 token so we have some pretty specific terminology that i'm going to go over pretty quickly uh so when we're talking about bridges we have to talk about where we're bridging from and where we're bridging to and we call these domains uh we don't usually say we're bridging between chains because we actually build bridges not just between layer ones but between layer ones and layer two so if you wanna move your ether from

ethereum to optimism you need to use the optimism bridge if you want to move your ether onto zk sync you need to use the zk sync bridge so we want to talk about domains rather than chains because not everything is a chain ibc is very particular about this because their concept of a bridge includes uh completely trusted proof of authority databases so the next piece of terminology is where is the action taking place in the context of a domain you know we have things running in cello and a contract in cello can talk to them directly so those things are local

things that are on ethereum can't be directly communicated with from cello so those are remote and we need to handle them differently we use channels to connect and communicate with remote contracts remote assets remote users anything that's in another domain so when you move your ether from optimism back to mainnet you use a channel to send a message from the optimism chain to the ethereum chain we use channels to connect those two domains um and in the context of a domain uh tokens you know the thing we want to

bridge are either locally or remotely originating on cello ether is a remote asset it exists it's defined by some other domain we don't know anything about it it could be anything but uh cello needs to make a representation of that remote asset we need a local token on cello that represents the remotely originating asset and that's what really defines a bridge so this is about the point where i should stop for questions does anyone have questions about

terminology or what a bridge is or what the goals are i can't really see the audience up from up here so uh you know any questions i think we're okay cool i'm going to assume that everyone understands this perfectly and i can do the remainder of the talk at double speed all right so uh we talked a lot about a channel channel is how you send messages between two domains so if you need to communicate from ethereum to near you're going to use a communication

channel there are a bunch of different choices of technology for this uh we've been working on different versions of this for like three to four or five years now and they all have different properties different trade-offs they send messages in different ways uh so some of the like ones we worry about a lot are latency when i send a message how long does it take to get there security how confident is the destination domain that the message it receives is valid we can talk about this a lot more but

essentially we want to talk about uh is fraud possible who could commit fraud who could cause invalid messages to be processed on the remote domain we also think a lot about implementation complexity so some channels are extremely simple and take like three weeks to stand up and you can do whatever you want some take like two to three years to implement uh some of you may have heard of ibc back in like 2015 that's just rolling out earlier this year we also want to worry about channel

overhead uh what is the cost to the chain and to the users of the chain or domain to validate messages uh how much gas do we have to spend to build a channel and to keep it running uh for example i wrote a lot of code for tbtc uh it uses a header relay from bitcoin to communicate between bitcoin and ethereum and uh that header relay cost something like 15 000 a month to operate uh it was like five times more than that a few months ago when ether was higher so we want to think about for any given

channel tech what is the cost to operate it on a given domain and then we also have to think about reusability when we build a channel and we spend you know six months to three years building it how many domains can it reach most channels are designed to go from one specific domain to one other domain the ideal is that we build some sort of channel that works for all domains okay so for specific examples ibc which i've mentioned a few times has very low latency

it only takes a few seconds to pass a message between two domains and it has very high security as long as the sending domain isn't you know compromised as long as the validators haven't committed fraud ibc will only pass valid messages unfortunately ibc has very high complexity it's been under development and in specification for years and we've just seen it hit main net in the last few months it has kind of mid overhead you have to process the you have to process all the headers from the remote chain

so there's a significant cost to different cosmos zones to connect to ibc and it has high reusability as long as you really like cosmos once you get out of cosmos all of the work done for ibc needs to be redone so we can't use ivc and ethereum cello optimism near solana or any other interesting domains but you can use it as much as you want very easily within cosmos optimistic roll-up channels are designed specifically for connecting mainnet to the roll-up they're usually orchestrated by a contract on the main net they have very good security because the

main net is handling everything so ethereum handles all communication over the optimism channel and you know because they're part of a rollup they have very high complexity they have relatively low you know like medium overhead especially compared to a header relay like ibc or tbtc but they're only applicable to the specific roll-up that they're connected to arbitrarium can't reuse the optimism work and vice versa we end up developing a completely bespoke channel every time we build one of these one of the most popular models for bridging that's used by like matic and bsc

and basically every other chain right now is a trusted channel what if we just uh hand the money to some trusted custodian and have them hold on to it for us these have very low latency because the custodian just gets the money and does whatever they want with it they have no security the custodian can cause any message to be uh received by the remote chain so the custodian could run off with all of the money cause any smart contract to receive messages that were never sent whatever they want to do but they are very cheap to operate and very cheap to implement which is why they get built so often uh and they're very reusable because you

know just having some guy sign messages works everywhere so what my team works on is the optics channels which we trade off a bit of security uh and latency for lower complexity and high reusability so optics channels permit fraudulent messages in edge cases uh only if everything else is falling down and as a benefit of choosing to allow that we are extremely cheap to run have very low overhead uh and can be used in any domain uh that supports basic smart contracts

um the interesting thing about all these channel choices is that the bridge doesn't really uh the bridge is an application just needs one of them anyone so we talk about the trade-offs of the different channels and how they bubble up to the bridges in application but generally speaking any of these choices will work for a bridge so i'm going to ask myself a question which i already spoiled can you have it all can you have low overhead low complexity high reusability no you can't the rules of blockchains forbid that and i'm happy to explain in depth why sometime

after the talk so before we get into talking about bridge trade-offs i should pause for questions again i'm going to back up slides a few bit to give ourselves some context i'm happy to answer questions about channel technology okay what is it that prevents ibc from connecting with non-cosmos chains ibc is an example of a header relay so the way ibc works under the hood is that

it takes the headers from the other chain and verifies them within the local chain so the way a header is verified is specific to the tendermint pbft consensus proof of stake protocol that they use and you can't reuse the header verification for other chains cello eth2 solana near they all have different headers different consensus protocols in order to connect to ibc you would have to rewrite the entire header chain validation logic which is what takes you know years thank you um question no

no yeah go ahead i don't know as the mic sorry i was wondering if you could talk us through the thought process of picking the the constraints because i know it's never easy and i'm just curious about how you got to where you got and what were different discussions um a lot of these are targeting specific applications talk about latency because users don't want to wait seven days for the optimism bridge to work they have to but they don't want to

we talk about security because we are fundamentally uncomfortable with the idea of a centralized custodian holding all the money uh complexity is because we have been waiting so long for ibc ibc is incredible it just arrived three years after we wanted to use it and you know i'm going to use it in the future but each new chain that we connect to ibc is going to take a six month plus process to re-implement a significant chunk of the logic uh overhead is because for tbtc we ended up spending hundreds of thousands of dollars we didn't want to so i think about that one an awful lot

and reusability is because i implemented the core tbtc logic for five different chains uh and i spent a huge amount of time doing that and i thought it would be really really nice if i didn't have to do that for each chain each time so the the constraints are mostly from experience with specific applications i'm not going to argue that these are the ideal set of constraints for channel tech but they are like what we've bumped into in practice can you explain a little bit more in

depth how the optics bridging technology works uh yeah so we should probably say channel technology um the main thing that it does is it has an optimistic model for cross-chain communication really optimistic-ish optics guarantees that optics designates a tester and they regularly attest to the state of one of the chains if the attester commits fraud there's a waiting period which allows anyone to shut down the channel and fraud is always detectable on the

chain that sends messages so in the edge case where the updater commits fraud and nobody closes the channel a fraudulent message can be passed uh we think that that should be extremely rare in practice but we do like very directly point out that this is a security tradeoff ibc permits fraudulent messages sorry optics permits fraudulent messages where ibc never will any other questions before i move on i think we're okay

all right so i'm gonna fast forward back through these you can't have it all so bridge tradeoffs uh it's sometimes difficult to talk about bridges as their own application because they get conflated with the channel so often in the history of bridging we've actually never had a meaningful separation here ibc has its own bridge as part of the specification optics is going to have a bridge that is loosely coupled i'll come back to that in a second all of the trusted channels are bridges and bridges only because that's the main application that

people are interested in and there are other channels that exist but they pretty much only get used for bridging so we tend to conflate bridges and channels uh when we should really think about them very very as two separate things um so we have to talk about for the bridge application what happens if the underlying channel fails uh for ibc what if there's a liveness violation for a trusted channel for optics what if a fraudulent message is received do users lose funds are they are there any inaccessible funds and are the

representation tokens on the remote chain worthless now we also have to talk about recovery can the bridge gracefully handle recovery of a failed channel and how does it do that how do we recover funds how do we hook up the new channel and how does it manage its uh known channels how does the bridge become aware of an inbound channel and know that it ought to process messages coming in over that channel what sort of permissioning aspects does a bridge have who gets to decide what new domains are added

what requirements are there for new domains and who registers these on the bridge application on each domain if we want to bridge cello and ethereum the bridge application on cello has to be aware of the bridge application on ethereum and vice versa what are the permissioning and acl setups around access to those smart contract calls we also have to think about routing we're connecting different domains uh maybe not all domains are directly connected and we have to send a message that passes over two or more channels before it reaches its destination ibc does this very well we have to develop some sort of identification

system for domains uh this is broadly similar to routing in the internet we're making multiple hops through different routers and uh one of the really interesting non-intuitive questions we have is are tokens with different routing histories fungible so if ether goes to cello and then solana and other ethers goes directly to solana are those two different ether tokens interchangeable the technical answer is no because one of those because

each of the tokens has to retrace its steps to get back to ethereum so one of them is exposed to two different channels and one is exposed only to the direct channel so the bridge application has to either expose this and make them non-fungible or handle it somehow and make them fungible ibc for example chooses to have each of these tokens be non-fungible a token in a given domain uh commits to its routing history and is not fungible with the same token that came if it came by a different route uh so again we're going to go through

examples in the wild ivc the ibc bridge is essentially specified alongside the ibc channels and it only uses the ibc channels i think they have plans to upgrade it to allow different kinds of channels but there's no eta on that there's no active development ibc bridges permit theft on channel failure so if your tokens have passed through a domain and that domain's validator set fails for example those tokens can be stolen when an ibc channel fails it requires a

public recovery process uh ibc channels like all cross cross domain communication has a trusted setup ibc fortunately allows anyone to observe and verify that the setup was uh done correctly which is why we call it a public recovery process um ibc has completely permissionless membership anyone can boot up an ibc uh compatible chain and connect to any other domain that's ibc compatible anytime they want to so you can boot up a single cosmos zone a single node cosmos zone at home

and connect directly to the cosmos hub and this is why ibc bridge tokens with different routing histories are not fungible is to preserve the permissionless element there's an inherent trade-off there and ibc supports arbitrary routing on a graph so you can send messages from domain to domain to domain in any number of hops um optimistic roll-ups are again very application specific they're designed specifically to get ether from mainnet to the roll-up uh on failure there's no theft unless the roll-up itself has failed

usually this just results in a seven-day delay the edge case is that the roll-up fails and nobody notifies the main chain that's probably never going to happen roll ups require a public setup as well so if they fail there's a public recovery process they can only connect two domains the roll-up and its host chain and so routing is not really applicable here um oops so for a trusted bridge these are you know bridges using trusted channels there can be theft anytime there is no public recovery process

there's no way that a third party can verify that the channel is set up correctly because it's running trusted code on trusted hardware obviously it's permission membership and i'm not sure if routing even makes sense in this context because if you're having someone just hold all the money for you you might as well go direct optics bridge the design that we're working on is mostly implemented we took a lot of effort to be flexible with our channel technology so the optics bridge application can use any channel it could use a trusted channel

it could use ibc it could use any of them and we did this deliberately to separate the logic of the communication from the logic of the application we are going to launch using optics channels however we are optimistic that we can switch in the future and if we deploy on an optimistic roll-up we're likely to use the optimistic roll-up channels as well alongside the optics channels the optics bridge does permit theft because it can't because optics channels and other kinds of channels uh can process fraudulent messages

so if the channel fails some value may be lost uh optics channels and the optics bridge have a public setup process anyone can verify that it was done correctly and that it's using channels that are known to be good we have permissioned membership and we haven't decided uh how it will be governed yet uh we're open to suggestions there um and because optics channels have a cool one-to-many property uh we require direct connection we kind of forbid routing we always want to be able to reach the destination in one hop the goal there is that we can provide fungibility

across all domains regardless of routing uh this is getting to the end of my prepared material i think oh do i have more slides oh okay so i want to talk for a minute about why these choices specifically we chose to make flexible channels so that we could upgrade to future technology if ibc becomes available on cello or on ethereum we want to be able to use it it has lower latency and higher security we'd love to use it if it's available we choose to allow theft on channel

failure because some channels allow that and we want to be abstract across all channels we want to allow the operators of this application to choose their channel tech we love public recovery we love allowing users to verify that the thing is working correctly and we've taken a lot of pains with the channel technology and with the bridge application and to allow that we've decided to go with permission membership for a very specific purpose uh if we are sure that all channels are high quality we can make tokens

fungible without uh worry about routing um if we know that the channels won't fail we know that we won't experience theft and we think that having permission to access you know permissioned membership in this bridge and limiting it to high quality domains can achieve that right now in the wild we're seeing fragmentation of usdc and other stable coins on different chains because they have reached that chain via different bridges we would like to have a single bridge that fixes that and has a unified representation for

usdc regardless of where it came from this is the reason that we made direct connections mandatory is because we don't want routing to affect the token representation our thesis is that the representation is the most important part of the bridge application and that unifying the representations is more important than anything else we could be doing with a bridge so i'm james i'm happy to take more questions uh that's the actual end of my slides uh please feel free to raise your hand if you have questions

uh the question is how can we make direct connection mandatory um so optics channels uh have an interesting property that other channel tech doesn't which is that there's only one outbox per chain and that outbox handles messages going to any number of remote domains so we have this one-to-many connection just built into the channel tech and most channel technologies can't achieve that so because we have the ability to add connection so easily and there is already an outbox that can send to that domain we just choose to

have channels be direct all the time so when you say that the bridge has permission membership do you mean that only a permission set of users can send tokens across chains uh no we mean that only a specific set of domains or chains uh are participating in the bridge we control the domains that are part of this free trade zone so that we can have a better user experience if the code is open source uh

how do we plan to enforce having domains come to us for permission if the code is open source i think that the important thing here is the sla that a domain can provide to the users the code is open source and anyone could stand up their own version of this application the representations would be fragmented and non-fungible with other versions of the application which of these bridges is going to provide the best sla to users and the best user experience i don't think that we need to force chains to come to us i think that if we build the best representations and the most reliable system

that everyone will want to join and it'll be good for everyone makes sense um when you talk about reusability you're really talking about the bridge not the channel is that correct um when i talk about reusability i'm usually referring to the channel for example we've talked a lot about ibc it works incredibly well within tendermint as long as you're running a tendermint chain ibc can get spun up and running

extremely quickly once you get outside of tendermint there's no reusability right now you can't use the same channel technology to connect near and etherium without uh months to years of work for a trusted channel or for an optics channel that's not the case uh the overhead to implement on the new domain is very low for the optics channel like how do you how is it low if you need to have some kind of way to do fraud proofs like that doesn't it need to be customized to whatever the validation mechanism is um specifically uh

the latency for fraud proofs and the you know reusability of the code and the technology in different domains is kind of on not really connected when we talk about reusability it's more about if i spend a thousand developer hours building this how many developer hours do i need to spend on the next domain for like client-based channels that's very high and for trusted channels and non-like client based it's very low is it easy to sorry is it easy to re-implement frog proofs for different

chains the optics channels have an interesting property it which is that the fraud proof occurs only on the sending chain so the fraud proof occurs at the outbox for the domain rather than at the inbox for the remote domain so we know that the fraud proofs can always be very cheaply verified at the sending domain thank you i'm happy to answer more questions about you know optics channels or other cross-chain communication systems after this as well you can find me out in the hall

anything else right now great thanks so much i think that's about it for me okay i'd like to thank james for the really cool insights and welcome sonia to the stage you