Interoperability & the Multichain Future - Teck Chia, Anna Carroll, Arjun Bhuptani and more...

all right um so this panel is about interoperability and multi-chain future uh i think we could start up with a quick round of intros uh of who you are and uh uh what you're doing with your project and uh and uh yeah go ahead jay you wanna start first uh hi everybody so wait okay talk really loud so my name is chris winter i'm replacing jay my co-founder he had actually catch a flight but uh i am the ceo of a company called reach what reaches is a blockchain development platform that is blockchain agnostic but it's exponentially faster safer and easier to not learn how to build a blockchain application i like i like to talk in like real use use cases we can take a traditional web 2 developer and train them for about four to six weeks and they can build things like amms decentralized stable coins things of that sort and uh you know it's been it's been pretty fun so far awesome um hi everyone i'm arjun i'm one of the founders of connext connext is an interoperability protocol we allow developers to build fully expressive cross-chain communication apps uh in partnership with nomad um uh we are live and have been for uh a while we've actually been in space for like almost five years now um and uh uh yeah excited to jump to the panel hey everybody i'm anna carroll um i'm the protocol lead at nomad um please hold your applause um nomad is a protocol for cross-chain interoperability um that uses optimistic dynamics um we're live on mainnet right now deployed between moonbeam and mainnet ethereum um and yeah we're partnered really closely with connex as well i'm park i'm from figment we're a multi-chain validator we validate on over 35 different chains we have a lot of presence across different ecosystems and we have a lot invested uh both financially and also just culturally in terms of the growth of the entire space so really glad to be here to talk about this because this is something that we care a lot about as an organization great thank you so much i'm going to start with a blog post or not a blog post a reddit post that vitalik has written about multi-chain versus crosschain have you guys read the blog post last month uh i think vitalik is optimistic about multi-chain where we're in a world where there are multiple chains but he's less optimistic about cross-chain applications primarily due to the fact that bridges across sovereign zones are not that secure um do you agree do you disagree and uh what do you think or yeah i'll go first so i i 100 agree to that i believe that's uh they're i believe in a multi-chain world but at least in the current iteration of things the the inefficiencies of bridges where at the very best it's bridges assets at the least common denominator it really limits the innovation to be able to bridge from chain of chain uh but i do believe in a multi-chain world where uh there are better chains for better things and some things can be cross chain but a the large majority of things can't be cross chain and does your uh id or tools tool chain support bridging or is it just a cross compile across multiple chains so reach is a blockchain agnostic so it allows you to write write your application in the reach language and launch on any chain that we're connected to currently that's all evm algorithms conflux and next will be cosmos but with the idea that we bridge to or we connect to all chains but we do believe that uh once we actually have a good foothold over the developers we provide extra better tools that allow for the the minimum the minimum assets to bridge cross across back and forth got it thank you um arjun you want to go next or whatever yeah um so this is a really interesting question and uh obviously it has become a lot more interesting because of the you know wormhole hack which admittedly was was related to contract code and anything else but it has really brought bridge security to the forefront of everybody's thinking um uh i think vitalik is absolutely right and i'm glad that he's brought this up that like the security of having a shared settlement layer and an interoperability happening with that same shared settlement layer is always going to be better um that said i i don't know if that's necessarily the conversation we should be having just because the reality is that people are going to do it anyway um and they'll do it using multi-sig bridges i mean there's there's a reason why you know things like wbtc exist there's a reason why usdc exists uh you know there is clear market demand for building these kinds of products and like i think it's sometimes easy to say okay well that's not the most optimal architecture but uh the reality is that if people are gonna do it anyway the better option is to find safe ways to try to do it um something that we're really interested in is to find is basically to build in like cross-chain circuit breakers have limitations on the amount of funds that can be transferred between chains even for cases where you have things like wrapped assets using techniques like that to add additional levels of verification to caution interoperability i think can bring us to the point where the amount of downside risk associated with like there is a huge black swan risk associated with a single chain getting 51 attacked and then those tokens going back and you know potentially being spoofed to ethereum and infiltrating ethereum supply but the limit of that the effect of that can be significantly constrained if you design systems well and if you build in fail-safe mecha uh yeah failsafe to stop that from happening the other thing i think is kind of interesting about this is that we tend to be constrained by the idea that it should be fully financial a lot of the crosstrain application like application capabilities and in the long tail of this as the space continues to develop cross chain is something that could work in a more modular setting right when you're trying to build things with multiple components from app chains that's where like crotch chain could potentially see itself being a lot more useful so i think right now we're in this like very nascent stage where we're trying to figure out how it is that we can mitigate the risk between all these between different chains and how it is that we want to like port things between them but i think it's really a question of like what are you bridging like how is it that you're using using within the space and i think we're gonna see a lot of development it's super early in the story of bridges at this time um so yeah that's i like i'm gonna edit jump in here real quick i agree completely there that's everybody hates when you say this but when people say we're early but we are and okay better and so when you say we're early we will figure out the better structures we will find out the better infrastructure so that we can do those things in the future anna no okay uh so that does it well for blockchains that are designed to be interoperable like cosmos or polkadot where crosschain applications are are featured by design versus like across different zones of sovereignty what do you think of that i'm sorry could you repeat the question yeah so uh you know cosmos and polka dot they're designed to be interoperable between multiple para chains or zones and stuff like that is that a better model than um that crossing zones of sovereignty uh where you know what um vitalik where the security issue um is a problem oh anyone can uh the gut feeling is yeah you know like when you have a when you have some sort of message passing protocol that allows you to create that interoperability and you're staying within that zone the gut feeling would be yeah because you don't have to worry about like asset transfer in the same way um go ahead right right um the next question is around uh what is your security model and what how can your bridge or how can your bridge fail what are the systemic risks that exist in your protocol uh i guess yeah yeah well i'll start so nomad is based on optimistic dynamics similar to optimistic roll-ups like optimism or arbitrarium um so yeah so basically there's an attestation on the sending chain as to the messages that were enqueued on the sending chain and then those attestations are relayed to receiving chains there's a fraud proof period during which watchers can come and basically block fraudulent messages um in terms of like systemic risk on the protocol i think like james had an interesting talk earlier today james prestwich who's the cto of nomad um talking about how none of the bridge hacks that we've actually seen have been a compromise of the trust model of the bridge but actually just smart contract bugs um so it's kind of interesting uh uh like we can talk about systemic risks and security models but i think at the end of the day like uh the design of the bridge should be such that minimizing potential for smart contract bugs um yeah so i'll jump under there real quick so we have uh companies building bridges on top of reach and i agree the smart contract issue is the biggest issue so one of the things that reach does is that through the compilation process of your application it automatically generates formal proofs to mathematically guarantee that the code will do what you expect in all potential realities so we are we are helping people attack the smart contract side which we found that is the biggest issue when it comes to bridges um so for connext we are sort of obsessive about trust minimization we've been like extremely vocal about that most weeks i'll be yelling on twitter about at people to not use multisig bridges um by the way don't use multisig bridges um the way that connex works currently is that it's it's sort of it's similar to an atomic swap system um you uh you have a network of liquidity providers who are accepting funds on one chain uh and and that can also include like call data to execute a contract call and receiving chain in certain limited cases uh and then you know uh basically fronting capital on the receiving chain in return uh we are working toward towards a newer model that leverages nomad further at its core but this core security model is the same the idea is like uh there's two pieces of this interrupt puzzle the first is you know the data layer how do you actually get arbitrary data across chains without introducing trust and then the second is liquidity how do you make sure that you get the right asset when you actually get to the destination chain because otherwise you're just going to get some completely random wrapped asset that isn't going to be helpful for whatever your specific use case is great thank you um so uh i guess nomad has been out only a month or so or uh very new no man i'm sorry nomad has been only live for a month is that right uh yes so we deployed in january okay um and you know bridges uh are being used for asset transfers uh uh mostly these days have you seen any applications that are uh doing cross-chain composability of applications have you seen any creative use of crotch chain message passing yeah so um we actually uh little known fact deployed with two production applications um everybody knows the token bridge transferring tokens across chains um but actually built into our core system is a cross-chain governance app that governs our smart contracts across every chain that we're deployed on um and i'm looking at this now as a problem that pretty much every application that's expanding to new chains is facing actively um so i've designed a cross-chain governance application that can allow um governance on layer one to execute proposals on remote chains um so that's one example we also have just a myriad of developers building on top of nomad actually right now so i know uma was working on a cross chains or price oracle which is super interesting um i think other folks have been uh well connect is now right building on top of nomad as the message passing layer um i think there's a lot of uh room for us to still explore this design space right because in smart contract design if you're sort of executing on an atomic layer one um that atomicity is really important to like protocol design um everything we we assume that there's not asynchronicity in smart contract design and a lot of the use cases that we have right now on like ethereum mainnet for example kind of rely on that um so i'm really interested to see this application space develop and understand how smart contract and protocol developers are going to actually incorporate asynchronicity in their designs um there's actually i'm glad that you brought this up because this is something that we've been thinking about a lot as well um so i i recognize that it's like 5 45 on saturday and everybody is like you know dead uh but i am going to get a little bit technical with this i hope i hope you know the five percent of people here who understand it appreciate it um so um uh there's a i my my goal has always been try to find ways for developers to safely build applications that go across chains and to define what those those developer patterns actually look like because it's it is a completely unknown space right now everything that you do in solidity happens within the same block so you never really have to worry about some of these really interesting problems like okay what happens if my execution runs out of gas right now it just reverts in a cross-chain paradigm it no one really knows your the transaction's kind of just stuck there until somebody pushes it forward um it's really weird and it's uncomfortable um the other really weird thing is like how do you deal with just asynchrony in general uh you know like in traditional web development patterns with like things like javascript you have asynchronous callbacks you can go and fetch a resource from somewhere else and then later at some point in the future you can come back and execute your code can we build that into solidity and as it turns out yes we can that's actually something that we're heading towards now is finding using leveraging nomad to allow developers to do that to build an application that can call a contract on another chain change the state of that contract on the other chain and then return the call data back to the origin chain and not just that but also autonomously execute a callback on the origin chain i think this is really going to like it's it's a it's this is probably like the biggest change to solidity development patterns since we started using libraries um i think it's dramatically going to alter the developer experience in in a really really interesting way because um all of a sudden you're you're not just thinking of like okay i'm calling a contract and i'm specifying an address uh where which is where that contract is deployed on the same chain now you're saying okay i'm calling a contract and i'm specifying a much longer identifier that includes chain information and i can interact with this contract operating on another chain in the exact same way that i interact with the contract on the same chain i think for a lot of people that's going to be a very fascinating and mind-boggling experience that's really cool yeah have you have you thought about some of the cool applications that you want to see using uh this model yeah uh besides governance yeah there's there's a lot of really interesting stuff i mean the the kind of low-hanging fruit is like anything that's like tao governance based you know kind of like what you were saying um you know dao is having to mod like change constants on other chains or to go and retrieve data from another chain so imagine you have a protocol that has like protocol control value that has liquidity fragmented across a bunch of chains you need to update pcb constants or basically trustlessly read pcb constants from another chain and bring them back to your home chain um that's a really really interesting example um other kinds of things are like cross chain zaps you know basically baking in the ability for users to instantly jump into an application from another chain without having to think about okay i'm going to have to bridge my funds and then use this other application as app i think uh bridges are like bridge interfaces are like boomer tech that is going to disappear in the next six months hopefully i really hope right so i'm gonna ask questions i'm curious about this now so is this a does this work with evm to evm or would this work from like evm to solano or alvarado or anything um well yeah theoretically could work uh in any like cross-chain environment it doesn't have to be evm to evm i think it's um in the evms evm world something that our contracts like a design feature of our contracts has been um the fact that they're deployed the same on every chain so these contracts every contract encodes both the information of how to send messages and how to receive them so all of that application logic is uh sort of living in the same place and what that means is that uh it's really easy for a developer to build once and then deploy everywhere within the evm i think and and we're actually a model for that for example right now because nomad right now uh is planning to aggressively roll out to basically as many evm compatible chains as we can and that's um very doable because we don't have to re-implement the on-chain component that being said nomad was designed to be uh buildable basically in other vms easily it uses simple cryptography that's available on every chain and it doesn't uh unlike for example header verification relays it doesn't use like esoteric application logic that can't be implemented easily in other languages so i'm really excited to see this play out actually um in other chains like i think uh it does potentially explode the the design space for like protocol bugs like smart contract bugs so it's gonna be a lot of fun seeing um seeing what what what goes on so there's something interesting that you pointed out here that i think is something that at least we're thinking about a lot of figment which is like when you have all these interdependencies that start existing between all of the different zones of sovereignty or however it is that you want to build the applications that means that you are building things that have a point of failure that could be non-dependent on people that are working on the origin contract or something like that so i'm what i'm really interested in is like and i think that's where you see the vulnerabilities at this point right that's where you're seeing a lot of these issues is you have interdependencies where you can't account for what's happening on the other side of what you're trying to work on you have like vulnerabilities and instabilities so i think that's going to be one of the biggest hurdles is understanding how to coordinate and govern the relationship of making sure that everything you're using in your stack to execute something is reliable and that's what i think gives me the biggest point of hesitance when it comes to cross-chain work is because you are depending on something that's far away from you right when you're working when you're working within your own ecosystem it's like an m1 chip on an apple computer right everything's inclusive you can run extremely quickly you have a salon or you basically like i compare the two in my head is like solana and m1 right like it's not necessarily the case but that's going to be i think the biggest hurdle and obviously we in the space because we care about coordination we care about the ability to like build things with multiple different modular components what y'all are doing is important but that's the biggest risk i see in my in my in my case is the interdependencies yeah and that's i mean i think that's a really valid valid point and it's a really important risk um it's it's sort of like it's it's basically like the the problem comes down to figuring out okay you have this much more complex dependency tree that's created as a result of having these things that exist across a bunch of different chains how do you find ways to reduce the risk of those dependencies the good thing is we do actually have in computer science we do have good models for how to like you know constrain dependencies and how to like think about the risk of added dependencies and there's no reason why those models can't be used here as well and i think i think you know i i touched on this earlier but like models like you know limiting the ability like limiting the like the downside risk of of any specific interaction so you know do you ever need to transfer 300 million dollars across chains in a single transaction no probably not because you could depends what you're looking for right unless you're hacking wormhole you don't need to do that yeah you're flash learning across different chains i mean um and so yeah i think i think you can you know probably set rate limits um and i think i think that's probably an acceptable acceptable outcome for for most user interactions because the vast majority of users aren't having to really worry about transfers of those sizes and if you are an institutional user that is doing you know multi-billion dollar transfers across chains you're probably okay waiting for some time um that latency trade-off is not as huge of an issue well so there's there's also something so we were supposed to have another person on the panel who unfortunately wasn't able to make it and i don't mean to downplay you because i'm really glad you're here but um superfluid is doing streaming payments and to me if you can figure that out in the right sense that actually could be a risk mitigation layer as well right so if you want to transfer 300 million dollars or even just three million dollars between chains if you have a stream you're only like worried about what's getting transferred at any given moment right yeah we're getting we're getting dangerously close to the original like interledger thesis which uh for any of you who have been in the space for a while was like a a model for for uh payments across chains that you where you like break up transfers into very very small packets and that way you only have to think about the risk of one packet at a time so if something happens you can basically stop this stream of packets um and uh and you know for what it's worth like i it's it's a fantastic model it constrains risk extremely well cool i want to spend the last few minutes talking about developer experience which uh you know i wouldn't address the question to maybe park which has deployed a ton of nodes right on different blockchains as well as like chris which is uh helping developers have a good experience deploying to multiple chains and all that stuff so what a what is the ideal developer experience for a crosschain applications and uh what's the you know audrey talk talk a little bit about that and what's the model that mental model people should have when developing crushing applications i'll start so we believe that we need to make blockchain development uh exponentially easier because right now with solidity development or salinity development or algorithm development you're you're building state machines and traditional developers don't know how to build state machines or at least well uh you go get grab a web 2 developer and say hey build me a state machine there's going to be holes in it every time so what we've done is we built a programming language that is a higher level of abstraction that allows the developers to to develop at the level of the participant and what we do is we derive the state machine from the actual uh the the the actions of what the participants are supposed to have and not only that but we automatically formally verify the output so allows for the developers to to insert assertions directly in their code and it generates formal proofs to guarantee that that code is correct in all potentialities because it wasn't just about making it easier to develop but it was also about making it safer and the best part about it is that once you hit compile it compiles to every single chain that we connect to not evm not just evm but evm algorand conflux soon soon be cosmos and they don't have to change their code at all and and you talked about earlier about the the the issue about other chains working just completely different than what evm that's a real thing and what we had to we had to do is figure out if what the effect of the contract is supposed to do and then be able to figure out the mappings from what what the participants were supposed to do to derive that state machine and how it works on the that's that specific virtual machine so uh so yeah that is a definitely a problem but like our challenge was to say not how do we make blockchain development incrementally better but how do we make blockchain development ten times or a hundred times better and and i believe we've been successful so far uh we we're launching a uh amm dex at the end of this month and the pool code is only under 300 lines of code and which is nuts um which by the way the developer that wrote it never knew what blockchain was before that so we've done it um yeah so this is definitely something i've thought a lot about because um you know i've been developing applications on top of nomads so i've also been thinking about what that experience looks like for other people and particularly other people who are lower context than someone who built the core protocol as well um so something that i think is the biggest challenge in developer experience right now for building on top of nomad is so nomad is an arbitrary bytes message passing layer so what gets passed between chains is a chunk of bytes in order to build an application on top of that you have to make those bytes be saying and doing something meaningful and so right now our applications that are built on top of nomad the token bridge and our governance application there's a lot of bespoke bytes in coding there's a lot of packing bites parsing bites um and we've gotten feedback from developers like that you know there's some developers who will just jump right in there and get down and dirty with it but there are definitely a lot of developers who are uncomfortable with not having like a higher level language for this and i think part of the challenge there in the mental models is that we've actually done everything uh at the protocol layer to be reusable on other vms on other chains like solana cosmos polka dot for example um and what that means is there's a little bit more mental gymnastics to write an application even though right now we're only deployed on evm chains and there could be easier um simpler ways of doing things so for example um for encoding bytes in ethereum and evm we have abi encoding which is like a standardized uh encoding scheme that you can use to both encode and decode bytes data it's just a bit easier to out of the box create your own bespoke message format using api but that's an evm native thing so if you want to take that application suddenly to solana you are pretty much out of luck um and so another thing for example is uh addresses in ethereum um like they're shorter than addresses on other chains so when we create an identifier for a contract on another chain it includes the domain of the chain as well as an address cast to bytes 32 cast to a different size um so it's like a layer of indirection between just directly coding which a lot of developers like evm or smart contract developers are used to at least having a language at the level of like solidity um at the moment we don't have that for for this and so um it's a little bit more low level uh you guys won't have any quick comments um i just want to follow on that so um i think like the thing that's kind of missing here is basically just developer tooling um we we you know if you were if you were building solidity applications in like 2016 2017 it was like a god-awful experience like holy it was so bad um oh my god it was like it was like an excruciatingly painful thing to do um but now you have these wonderful libraries created by open zeppelin and other other organizations that are like that abstract away a lot of the complexity and then also make the whole process a lot safer um i think like where we are right now with this is a similar place where like right now users are having to deal with like the lower level call functions the lower level like building blocks that in reality they shouldn't probably be dealing with unless they're very very advanced developers um what's missing right now is uh basically wrapper contracts libraries that can that can abstract away the whole idea of like how do you get the correct identifier for a contract on another chain you just pass in you know the the contract address and the chain that you're going to and it just spits out the correct identifier um libraries that wrap you know in the same way that you have like open zeppelin interfaces that wrap like erc20 and you instantiate like an erc20 contract by doing like ierc20 address um you just the same thing but in like a crosstrain wrapper that is like x iarc 20 and then you pass in this more generic identifier um once it gets to that point and this is this is the ideal like once it gets to that point developers should just not ever have to think about it like it should just be like one tiny change where your your mental model goes from address on this chain to address on any chain but that's it great i think we're out of time thank you so much for uh spending your time thank you thank you everyone thanks