Episode 230 - Designing Optimistic Interoperability with Nomad

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online [Music] this week i chat with anna carroll and my sometimes co-host james prestwich from the nomad project we explore their optimistic interoperability solution how it first developed what lessons it takes from previous attempts at interoperability how the optimistic part of their

optimistic system works we finish off by looking at a few use cases and cross network projects already working to deploy on nomad now before we kick off i just want to highlight the zk jobs board a spot where you can find a new gig working in zero knowledge technology there you can find jobs from some of the top teams in zk i specifically want to highlight one job post which would have you working with my team over at the zk validator we are looking at the moment for junior researcher who's interested in exploring and writing about zero knowledge proof of stake and general meta blockchain topics specifically the ways that these intersect with privacy if this sounds like something you would be interested in do check out our job ad in the show notes and get in touch

now tanya the podcast producer will share a little bit about this week's sponsor today's episode is sponsored by polygon hermes the polygon hermes zk roll up is a layer 2 built on top of ethereum that solves its scalability through mass transfer processing rolled into a single transaction zero knowledge proofs are used to present and publicly record the validity and correctness of the role transfers processed on the ethereum blockchain by storing just the proof and the compressed data of a batch of transfers the efficiency and the throughput of the network is multiplied visit polygon.technology to learn more about polygon hermes and other polygon solutions so thank you again polygon hermes now here's anna's interview with james prestwich and anna carroll from

nomad [Music] today i'm here with anna carroll and james from nomad welcome to the show to both of you hi anna hey anna thanks for having us james i think our listeners will be very familiar with you you are a sometimes co-host i hope you co-host again soon we miss you it has been a while i think the last time i was even on the podcast was the new year's episode i think so so this is a request made publicly i hope you come back soon we'll have to figure out an episode for you to do this summer oh definitely cool um but yeah i think most people do know you but why don't you just give us a quick brief on on what you do and who

you are yeah my name is james prestwich one of the reasons i haven't been on the podcast lately is because i'm currently the co-founder and cto at nomad uh so that keeps me really busy during the days and uh it's been difficult to schedule time to come back on zk unfortunately no problem well you are missed uh anna i want to hear from you about your story we actually so we met at least a year ago i know i actually did an interview with you on video which we could probably link to uh last summer in paris but yeah tell us kind of about yourself what you were doing before and what you do now yeah hey everybody i'm anna carroll um i'm the protocol lead at

nomad and i've been in the ethereum space for nearly three years now i started out at dharma doing like back end engineering and a lot of stuff sort of interacting with the chain and then moved on from there and started working with james on uh what today is nomad very cool so i want to hear a little bit about the journey to nomad where did this idea start why like why was this idea even like adopted was there some like need at some point that like became very clear yeah tell us a little bit about that journey yeah definitely well you know i've been working on cross

chain protocols for i want to say close to five years now uh and nomad is really the realization of a lot of the lessons we learned along the way about what works and what doesn't and what people want and what people don't want uh so the actual like protocol design for nomad came from christmas vacation like 2020 so towards the end of 2020 uh had some time off to just kind of sit around and think and you know work on what i thought the ideal cross-chain communication mechanism would look like i took a lot of inspiration from

optimistic systems and roll-ups and tried to build something that caught a lot of those security benefits and cost benefits but rather than being a new chain like a rollup is being a cross-chain message passing system so we started off as an internal project at cello and towards the end of last year the team decided you know it's time to pursue nomad full-time uh so you know nomads the company started late last year and i actually i'm excited to say like i'm a investor in nomad through the xero knowledge validator of just recently this has been put together so congrats

on that round and i'm excited to be sort of part of it you know peripherally you know how much i love working with you anna oh james welcome to the squadron yeah we've been an illustrious group i'm curious now i feel like i probably know the answer to this but what were the projects before this what were the bridge things that you were doing like i feel like were you working on keep but like it wasn't your like you were i know you were working a bit with that team but what what other things were you doing you know at suma we worked on a lot of things in the cross chain space we started off working on atomic swaps between bitcoin and ethereum because

that was the only crosstrain thing anyone knew anything about back in 2017. we kind of quickly realized that cross-chain swaps weren't that great and nobody wanted them uh and pivoted into working on uh relay-based constructions so we built that bitcoin like clients in solidity uh for ethereum and go for cosmos and rust uh and a few other languages the idea being that you could use a light client as a communication mechanism and that's what underpins tbtc today the problem with light clients is that they are fabulously expensive to operate

the tbtc light client still costs uh five to six figures every month just to keep running and a bitcoin light client is the cheapest possible blockchain like client so we don't think of relays as a very viable option anymore the only place that they're happening in practice is ibc where the relay is uh heavily subsidized by the chains involved so after we stopped working on relays at sumo we contributed to a few other like cross-chain or uh complex multi-chain things so we contributed a little bit to aurora the the near evm in the very early days

but you know mostly we like working on cross chain things we like working on applications we like working on things that are user facing and that's what we you know set out to do when we started nomad get back to the applications get back to user facing things and i want to hear like what's what kind of brought you to this problem do you have anything in the work you were doing before that kind of like got you more excited about this in particular yeah well the really the honest answer to that question is um meeting james is what got me to this problem so nice i was starting at sea labs it was january of 2021 uh just a few short weeks after james had

the initial concept for um this construction and of course james's reputation in the space precedes him and i had heard lovely things about him as a person so he's making a fight i really just wanted to work with him and he was working on this so um that's how i really got into the interop space yeah nice what do you feel has been like the challenge of this kind of work what is this kind of work actually what is it that you build i'm gonna go into like the actual architecture and stuff in a second but like are you is it smart contracts primarily like what is the work of a bridge development team yeah well i mean there's two main components to the

cross chain system that we've built which there's an on-chain component that's you know the smart contracts right now our on-chain contracts are only written in solidity so they're evm compatible but it's possible and we have plans to expand that to other you know execution environments not just evm so there's the on-chain component the smart contracts and that's kind of my domain my realm and then we have an off-chain component the agents and this is kind of necessary because the core of the problem like what we are trying to solve is there are these discrete chains which each have kind of their own

security boundaries they're self-contained and we're trying to enable them to communicate with each other you kind of can't do this in the evm world natively using just on chain components there has to be also an off chain portion that sort of varies these messages from one chain to another yeah an easy way to think of it is like a chain can't connect out to the internet and pull data in chains need information to be pushed to them they need someone to make a transaction that pushes that information into the chain and so when you have two chains you can't have one pull data from the other you have to have one push data off chain

and then somebody off chain push that same data to the other chain so any cross chain communication system has like these three steps is you know send the message on the first chain somebody off chain sees it and decides to forward it and then the second chain processes a transaction that's actually that that idea of it not having any ability to pull like a chain not being able to pull are there some systems like maybe the and i don't know how deep in this you are but like something like the polka dot system or maybe like ibc like do they allow more of a pull or is it also the same problem in those in those cases it's really the same problem the the core here is that chains need to come to

consensus and so you can't introduce anything where different nodes might have different views so you can't like ask the node to connect to google.com as part of consensus because five different nodes might connect to five different versions with different doodle art so the way we ensure that all nodes have the exact same view of everything all the time is we ensure that all of the data is pushed in concrete blocks that nodes never have to connect out to something and ask to pull information from anywhere in this way though are you creating almost like a copy or like tracking of a certain chain and this is maybe goes back to that

question of like clients like do you still work with some form of a like client maybe just like a more efficient one and is it tracking the entire chain on one side in a nutshell we don't use like clients okay uh we think that a light client is the ideal way to do this but again fabulously expensive so in the majority of cases you just can't run a light client between any two given chains and we don't track the entire chain the way a light client would uh we track only a very small portion of the chain and we think that in general if you're not running a light client

which most bridges aren't like only ibc and the near rainbow bridge are running like clients in production today in general if you're not going to run a light client tracking the entire chain is a bad idea okay but i think uh what's interesting about the question for me is what you're getting at is is actually at the core of the nomad design which is nomad is designed to take some state from one chain and allow you to relay that state or replicate that state in a sense on another chain in nomad that state is represented as leaves in a merkle tree and what's actually relayed is a signed a tested merkle root so

really like the core of this system is simply there are messages sent on one chain and that creates some state and then that state needs to be relayed to another chain in nomad we're not tracking the entire state of the chain we're not tracking the entire state of a smart contract we're trying to track exactly 32 bytes okay the merkle root of all the messages that that chain has ever sent oh and yet it's not attracting the current state of the chain just the current state of that 32 bytes wait where does that live actually um the 32 bytes lives in uh the nomad smart contracts so when people send messages

they call a function on that smart contract which dispatches the message via nomad and what all that does internally is update the state of all of the messages in nomad and then that this is kind of one of the core efficiencies is that all we relay is the summary of all that state um and then people can use that to prove that their message was included in that state interesting who who activates that or what activates this like what sends when you talk about sort of like sending that message it's like it sounds like an application or something is doing that to include itself into the nomad merkle tree well our goal going into

this was not just to move tokens around but to allow anybody to build cross-chain applications easily so anybody can dispatch messages via the nomad smart contracts okay they can send it to you know any other chain that we're deployed on in addition to just the cross-chain communication piece we built a standard pattern for building cross-chain applications how do you connect to these channels what's the content of the messages that are sent so the goal is to make it really easy for developers to build their own applications that can send messages over these cross-chain channels that can receive messages that are coming in and

to enable the creation of a bunch of different chain applications right now we have a bridge application that moves erc20 tokens around and a governance application that manages control of a smart contract system on another chain we're really excited about those two applications but we think there's dozens more interesting things waiting to be built cool is it like have you created when you talk about that like the rules basically that one of these applications would need is there like a framework then is there like some template or something that you've produced i know that sounds maybe very basic but like something that you that somebody could easily just pick up

and run with or is it more like you've created a protocol set of rules that they just have to build with yeah we have um so we have created an application pattern um built on top of nomad we're kind of we're calling it kind of a router pattern um with the idea being i mean going back to your original question right we're talking about this cross-chain messaging protocol and it's kind of like what are cross-chain messages what do they do what do you even do um like why does it matter and uh you know varying random bytes from one chain to another doesn't particularly matter what matters is you can build on top of nomad you can build applications on top of nomad so we allow

it's completely flexible it's completely arbitrary information and then developers can use that to do meaningful and interesting things using the underlying rails to build on top of so nomad has done the hard part of get information from one chain to another so developers can do the fun part of doing interesting things with that so yeah to answer your other question we have created sort of a template pattern um we're calling sort of the router pattern the idea here being that uh applications need to sort of talk to each other on either side of this messaging channel

they need to basically create a language or an encoding that is understood both by the sender and the receiver so the pattern that we've made is kind of a build once deploy everywhere pattern where the same application is deployed to every chain and that application is capable of both sending messages and receiving messages based on a standard set of logic that performs the kind of application the core of whatever that application is yeah uh we we call it the router pattern in an analogy to like your your router at home right is you've got this internet connection there's a bunch of data

coming in over it all the time the router is the device that sits connects to the internet and handles that incoming data translating it into something useful and getting that useful message where it's supposed to go in your home network so you know the nomad routers that are at the core of these crosstrain applications they handle getting the data from the nomad channel translating it into whatever is useful to the smart contracts on that chain and sending it off where it's supposed to go and in the other direction they handle calls from local smart contracts they convert it into the internet format and they sent that off you know to the

over the nomad connection to some other chain i think what's hard about this in the current cross chain landscape is that the mental models even just for arbitrary message passing across chain are still quite nascent um we're still building up an understanding of a separation between the channel that passes information and the applications built on top of it and part of the reason for that is that we're really familiar with one single type of application and that's token bridges so when a lot of people think about cross chain stuff they only know think about or understand the use case of

getting tokens from one chain to another but the fact is there's so much more than that in the cross chain space users hear cross chain and they think oh i can put my usdc on polygon which is true but in order to do that you know that's not the whole story a token bridge is just one thing you can build in the cross chain space and in order to build a token bridge you need some reliable communication channel under that and you need some interface between the token semantics and the crosstrain communication channel so we work a lot on you know to borrow a phrase from our celestia friends uh the modular bridge stack

is looking at what a bridge is breaking it up into different components at different layers and we think that the router pattern is a really critical layer that is neglected that people don't think about very often this interface between what is the application that the user wants to use and what is the communication channel that's going to help them do that the existence of the router provides that translation layer it lets you abstract things across chains because you can have a different router per chain using the same channel it lets you use multiple different channels depending on what chain you're trying to talk to it's a very

like flexible useful piece of the stack that nobody has really thought about before you had just said before this kind of like if they deploy it here it sort of deploys everywhere but i just thought like are you talking evm compatible chains because i guess it's different if you're not using solidity yes it's very different if you're not using solidity you have to write once for each different vm if you're talking about virtual machine if you're talking about the on-chain components um within the evm world if you build your smart contracts using this pattern you can deploy your smart contracts to any other evm based chain but that being said part of what we've done is we've taken pains

to make our router pattern forwards compatible to other types of virtual machines so that we build once per virtual machine right and even when we do that our routers on ethereum or evm based chains can talk to our routers on other chains such as like substrate-based chains for example cool does the developer do they still get to use this a template though like would you basically provide two templates sort of yep okay one of the like critical functions of the router has to be handling the differences between chains

a little bit so for example in you know the evm you're running your smart contract it calls out the other smart contract runs and then yours resumes when it's done but in most other chains like cosmosome and so on near instead what happens is your smart contract's running it cues up a call to somewhere else and then when it's done that other contract starts running so there's just this fundamental difference in the way smart contracts communicate and part of the reason you have to implement once per vm is to kind of handle those fundamental differences between chains and the router pattern lets you do that very easily

is once there are template routers for each chain it becomes much easier to build a cross chain application that does the same thing on multiple chains have you encountered any combo chains that just are like very complicated to work together like have you found that like ethereum is bad like tricky i'm just curious or do you do you sort of see this as like a pretty neutral ground that they're all sort of similar the way this is usually handled right now is very bespoke engineering uh so you'll come in you'll do a lot of bespoke engineering on the solana side of the stack and some on the ethereum side of the stack handles a lot of things like anna said earlier we've put a lot of effort into figuring

out what things are shared across all chains and how we can design applications and design patterns in a chain agnostic way a good example of this is addresses ethereum uses these 20 byte addresses but everywhere else in the ecosystem uses 32 bytes okay so if you want to design your application in a forwards compatible way you need to use 32 byte addresses even in in ethereum and there's actually no like runtime overhead for doing that or very little it's just you have to think about it as the developer up front and

you can handle that difference at the at the router layer and so if you follow like the router template it'll just help you handle that up front and you won't have to worry about it it'll translate between these chain agnostic 32 byte addresses and the local 20 byte addresses so the goal is to like take this that's been very bespoke engineering for each pair of chains and turn it into a relatively chain agnostic standard uh that helps people abstract things build across different very different vms we're still early in this process though yeah i mean i think to james's point about um being early i mean right now

there's more than enough work to do just focusing on interoperability between evm and i think that part of what has been a little more challenging about the developer ergonomics of what we've built right now is that you know james and i have built our smart contracts we've taken great pains to build them in a way that can be expanded beyond evm but right now you know nomad is primarily evm compatible at the moment and you know right now um if a developer is building applications on top of nomad at the present moment um they're likely doing so only within evm chains and

that's kind of okay because there's plenty of interesting applications just within that world so there are some shortcuts that you can take if you are only interested in the evm world to make it a little bit easier to build these contracts for example you know our contracts all use a custom bytes encoding scheme for our message passing so we have done this again because we want it to be compatible with other virtual machines but ethereum and like the evm has kind of its own bytes and coding scheme this is like abi uh so you abi en code or abi decode messages and it would have been really easy for

us to just use abi encoding and decoding but we didn't right for ford's compatibility issues but since then you know i've encountered developers who really and truly are only ever going to be building for evm chains and for them you know i recommend that they use api because it's simpler it's easier and the mental models are a lot more built out for you know solidity developers it's a it's a great example of kind of the difficulties of working in this space is we as the people building the protocol have to stay completely chain agnostic we need to plan for the future in which we're on near and solana and we have a substrate

palette and you know we're out there and like cosmosome but we also need to make it really easy for people who are used to solidity and just want to write solidity to use this system we have so much work to do on the developer experience on the template applications on the you know solidity interface uh if any of this sounds interesting to to y'all out there just hit us up we have so much to do um okay i i think one of the uh unique parts of nomad is this optimistic model you are on the zero knowledge podcast you realize um there is a competing kind of like thinking

which is at least on the roll up front which is like zk roll-ups and optimistic roll-ups i don't actually know if there are zk bridges or zk interoperability not not yet i don't think i don't know is there anything like that that you've heard of there is not there might be reasons or there are definitely reasons um you can kind of think of it as you want like clients right yeah anything that's worse that's not a light client is going to be optimistic or multi-sig there's no way to prove validity except you know like clients and optimistic systems

so to bring zero knowledge into this we would have to build a zk light client and the only chain on which that is conceivably doable right now is mina there's just no other chain whose consensus process is amenable to being inside a zero knowledge proof but what about plumo like i worked on that trusted setup is that isn't that a zk like line in a way sort of plumo is a good step it has the difficulty that its proofs can't be validated in any other chain efficiently uh the flavor of bls they use is just not present

we tried to get it into ethereum via an eip a couple years back but we're not successful okay so in terms of zero knowledge bridges you know we would like to see some you know zero knowledge like clients but we don't think we're going to see that for almost any like chain just mina maybe maybe the plumo work but that would only be one side then i guess it's like a light client on mina it's not a light client elsewhere that can like talk to that right so you could build a mena light client in some other chain but you couldn't build that you know uh cosmos like client in mina

so even then you'll still need some other system to handle the return trip we did like design a hybrid zk optimistic system uh called rollouts a few years back yeah you did a talk on that actually the zk summit in san francisco ck summit four so long ago oh my goodness uh so the the core idea there was that you would build a zk roll up uh where different parts of the roll-up uses different chains for data availability it is very difficult to do leader selection in a safe way because you know the leader has to be selected on all the different chains

uh the same way we think it's interesting that it has technical potential but we don't see anyone building it anytime soon it's a massive headache and again it requires every chain involved to support the same uh zk proof primitives interesting uh which so far you know like most chains don't support very good zk proofs oh and rollouts would require like one level of recursion to be any good and that's really difficult to get on any chain right now yeah i don't see zero knowledge proofs taking off in the cross chain space as a core part of the cross chain communication system anytime soon i think there are places where they

could lower costs slightly or take away some of the headaches of getting a good security model but i'm not sure that the expense of building them is worth it yet i want to walk through but i want to kind of do this after i want to walk through an example of like a cross-chain proof and verification sort of system but that's more like in the messages themselves it's not like in the technology that's doing the bridging but before i do that i actually want to talk about the optimistic pattern so you're kind of you make the comparison to an optimistic roll-up is it actually the same or like i guess i'm curious if it's actually similar to the optimistic

roll-ups or the optimism specifically or arbitrarium or if it's something else well sort of as you were touching on earlier i think you pretty much hit the nail on the head that optimistic systems are flipping this idea of positively proving or verifying up front on its head um so the whole idea is that okay instead of having a fully verifiably true thing up front um having a construction that allows us to prove that which can often be more expensive or heavyweight or difficult to implement we are going to assume optimistically assume that something is correct and

give an opportunity for someone to prove that it is not um with the idea being that this can be basically cheaper um from a lot of different perspectives be it gas or sort of resources to implement to get to this optimistic assumption that something's working and then in the case that it's not people can come through and do the expensive thing of proving that it's not and that's the fraud proof basically yeah the main difference is between nomad and optimism or arbitrarium are two things first is that you know our fraud proofs are really really really really simple

uh our fraud proofs are just you know you're supposed to say x but you said y instead it's really simple easy trivial to verify trivial to check um optimism and arbitrary because they're doing something so much more complex than we are has to have quite complex fraud proofs uh so now that optimism has followed arbitrom's model you know an arbitrary optimism fraud proof is this recursive unpacking of an execution trace and you know it takes up to seven days for a nomad proof it's just like oh you were supposed to sign this you signed that instead done easy and the second difference is that

nomad fraud games happen only on one chain they only happen on the chain that sends messages because that chain knows all of the messages that have ever been sent the other chain the chain that is supposed to receive messages doesn't necessarily know what those messages are that's why we're trying to send the messages there because it doesn't know about them yet so you can't run the fraud proof on that chain and so the bonding has to be on the sending chain the fraud game has to be on the sending chain and you have to rely on other parties to propagate the outcome to the receiving chain so each

application needs kind of these trusted watchers who are you know shutting down the application when fraud occurs fraud is very clear very obvious very easy to prove on the sending chain but the receiving applications need this other mechanism to shut them down how long does that take like if it's so simple is it a much shorter because i mean i remember i think we did last year these interviews with all the roll-ups and these were at least the time frame at the time was something like seven days that the fraud proof could still be submitted is is this the same in nomad in nomad it's much shorter so the reason that

the optimistic roll up time frames are so long is because the games are complex they take a bunch of different rounds so they may take you know 10 20 transactions from different parties in nomad it's always one transaction very simple small amount of gas the other reason it's a long period is so that in the event that something goes wrong in this complex protocol and the underlying chain decides to censor your fraud proof it's easy to show that that was the case in a long complex fraud games you need a long period in order to show that in a short simple you know fraud proof

you need only a short time to show that you were censored like if we have an objectively correct fraud proof that you know we can broadcast to everybody and we can pay super high gas costs for it doesn't take very long to show that miners are deliberately censoring you so what is the time frame then uh right now we use 30 minutes for most places i think for everywhere right now yep we think that in the long run each application is going to want to select their own time frame for this okay uh maybe you have a very high risk tolerance and you want to go much shorter uh maybe you have a very low risk tolerance and you want to take a

few hours or days right now we think 30 minutes is a reasonable amount of time does that mean actually that it takes 30 minutes for a message to go or like does the message go immediately and then there's this 30 minutes where it could be kind of recalled so the uh sort of the route right like that 32 bytes the the summary of all the state on the sending chain can be relayed immediately once it's relayed there's a period during which it can't do anything right that's the fraud period during that time that's the period of time where someone can come and block fraud right so that it can't take effect after the fraud period

messages that are included under that state included under that route can be processed okay so it's it's not included until that period is over yeah the message can't be received by the application until that period is over and you know it's kind of worth noting that in general any cross-chain system has a pretty significant wait time you have to wait until the sending chain finalizes which takes anywhere from you know like 10 seconds to 20 minutes depending on what chain you're on or even longer sometimes you know bitcoin being an outlier here with something like 60 minute on average finalization

uh proof of work probabilistic finalization anyway um so any cross-chain messaging system whether it's a multi-sig or whether it's a relay has to have some amount of latency built in to account for you know the sending chains finalization period basically our argument is that every cross-chain system is going to want this latency on pros before processing messages and that most of the bridge hacks that have occurred could have been prevented by this system if you have a little bit of time between the commitment to process the message to receive it and the actual receipt of the

message you can you know make reasonable sanity checks like hey is the bridge broken or is this going to steal all of the money uh and you know having reasonable financial controls built into the system and a period where you know people can prevent fraudulent or prevent faulty messages from being processed is going to be important to bridges going forward forever this isn't a you know like oh it takes 30 minutes to send a message it's we're sending messages as fast as it is safe to do so do you think that there will be like

some use cases where they'll sort of like go with the trade-off on security for the speed and then others where the security is so important that you need to like i don't know if you're if you're thinking around that like do you think there still are use cases where they'll continue to use a multi-sig because of that speed despite the fact that it's like super unsafe i mean will they or should they are two different questions [Laughter] agreed i think like people are going to keep using multi-sigs yeah we have essentially in the ethereum ecosystem just accepted uh multi-sigs and oracles which an oracle is just a kind of multi-sig

you know we've accepted these as a core part of our uh financial system the maker oracle and the chain link oracles underpin so much money and the uscc and wbtc multi-cigs and the usdt multisig you know un secure so much money so i think people are going to continue using these regardless our argument is that the applications a good chunk of them are going to reject that in the long run are going to try to do better than just an oracle

and that foremost application developers in the space something better than a multisig is what they're looking for i want to ask you just a clarity question here like you just compared an oracle to a multisig and i actually don't know that comparison sorry i feel like i'm maybe i've just never done enough work on what oracles are but like can you explain what like i always think of oracle's like price discovery right there's like how much does something cost versus something else no right well that's what they do okay that's what they use for right now yeah but what they are is just a set of people who are signing the the price huh it's not based on like market activity

or something like what an oracle is is a way for somebody or some group of people to say this thing is true and this thing could be anything um but in the majority of the use cases right now this thing is um in the real world this is the price of an asset or this is you know uh they're they're generally used for price feeds right because yeah they could also be like token to token right like it could still live in the crypto world unless are all oracles basing it on like a usd value and then comparing them to each other are they sorry i'm so naive about this i'm realizing big gap in knowledge here

from a really basic perspective we have this problem we talked about earlier blockchains can't pull data yeah uh so when a blockchain wants to know something or when an application on a chain wants to know something someone needs to push that data there and the chain needs to verify it somehow so when we call an oracle you know any system that just pushes data on chain that the chain can't verify so this usually is real world market data like what's the price of an asset right now or what's the relative price of two tokens or something like that but it could be anything like you could have an oracle that uh tells what the

color of james's shirt is today uh it would be a boring oracle because it would almost always report black but uh you know you you can have an oracle for that the question is like how does the chain verify this it can't objectively go and check that my shirt is black it has to rely on some set of parties to report that uh it can't objectively go out and check the coin base price of a dollar in bitcoin or a dollar in ether today it has to rely on somebody to sign over that and so all of the oracles that we trust in production like the maker oracle the chain link oracle

they're usually you know like a group of 15 signers and some sort of uh medianizer like a you know system that sanity checks what they're signing it's still you know a multi-sig it's a multi-sig signing data instead of signing you're like tokens i never thought of it like that but yeah i guess you're right like and how did they even get checked though did they get checked uh no they okay the the chain can't check them but and this is a great part of oracle's and a great part of nomads model is that the human beings who are sitting off chain and can open up coinbase can check those

uh so if the maker oracle is reporting you know a completely bogus value the human beings will know that and can respond to that if the nomad you know cross-chain system is fraudulent human beings can know that and can respond to that and can shut down because of this latency period can shut down applications before the fraudulent messages are processed you know a lot of oracles have similar latency periods built in or similar restrictions on how it can be updated the goal is you know we can't authenticate this oracle data or this nomad channel data directly but we can sanity check it we can have waiting

periods to make it safer and we can allow human action to correct it so i mean i think i understand the logic in having the time frame and the delay that's the time when the human beings can check if it's correct and potentially submit a fraud proof but are there also is there this idea of having tools that live on top of that to sort of speed it up at the same time and then have the ability to claw it back on the other side i don't know if this is even something you're thinking of but this is coming again from our i think our interview with optimism last year which was like they talked about yeah it's going to be held for seven days but there's like a ability to provide liquidity in the meantime so yeah i just kind of wonder if there's

any equivalent to the cross-chain stuff well i mean there's a one-to-one equivalent in terms of um providing liquidity up front for token transfers and we have a partner who's doing that which is connext so their upcoming sort of network upgrade or sort of hard fork of the connex system will be built directly on top of nomad and will basically have two cases a user sends tokens on the sending chain and it's very easy for a next router that has liquidity to see that that has happened off chain and then sort of provide liquidity up front for the user

so they can get it like more or less instantly in in on chain terms this goes back to what we were talking about a second ago it's easy for a human or another off-chain actor to see that the system is behaving correctly so that liquidity provider can see that those tokens will make it to the other chain in 30 minutes and that means that it is very low risk for them to go ahead and fill that order now because they know they'll get paid back in 30 minutes hmm exactly yeah is there any equivalent for messaging planned or would it would that be problematic that is

that's problematic okay yeah so there's basically like two classes of message and you know this goes for transactions on a single chain as well as messages between chains the first is like ether transfers or token transfers uh anything where the message is sender independent and anything that's sender independent can be sped up like it can be done by someone else and that allows this liquidity provider to come in and do it for you the second is where it's sender dependent these would be anything that's like an oracle update or a permissioned access to some smart contract

like maybe borrowing against your collateral in ave or compound that is sender dependent and so you can't have this liquidity provider coming and do it for you it is not always easy to tell which of those two buckets a message falls into so you can't speed up arbitrary messages we can only speed up certain ones okay exactly to sort of reinterpret or restate what james is saying like when a message arrives uh you have to validate who has sent that message right the sender center dependent or independent and if you're receiving tokens you don't really care who it came from you just care that you got the tokens part of what i was thinking of saying earlier

which i'm realizing now might be a bit more of a confused mental model because of the world that we live in right now but uh like token transfers are sort of fungible with each other right like if you receive like 100 tokens it doesn't matter who it came from whereas uh instructions like a governance message are like kind of more non-fungible like it really matters who it came from it can only come from the person whose permissions whereas if somebody else just rocks up and gives the same instructions like it's not um yeah that's a that's a fun way of looking at it fungible versus non-fungible i like that example that's the that's the core of the fast

liquidity system is you want your under tokens you don't care where it comes from if it comes over the bridge that's fine if it comes from a liquidity provider that's fine too but if you're waiting for you know collateral in your compound account or if you're waiting for vote in the governance system or if you're waiting for you know any of these other like application messages we want to going over the nomad channel you can't speed that up necessarily so i want to switch directions a little bit and look at the competitive landscape for bridging technologies you know that i've been doing like a series of interviews where we talk about this from different perspectives i just last

week had rob on from polkadot we talked about xcm i know you're familiar with ibc i kind of want to know like how do you see nomad interacting with those like would it like tap in directly to like ibc or would it sort of have to have an extra interface to be able to play in that ecosystem as well it seems like a different model uh so going back like 20 minutes in this conversation we talked about layers and you know modular bridging stack we have built you know this optimistic cross-chain communication layer we've built the router pattern on top of that and we built applications on top of that

one of the things that we were really careful to do with the router pattern was to keep it very communication system agnostic the router is just expecting some bytes uh it doesn't care what communication system those come from uh so we're really hopeful that the router will let us just plug into xcm or just plug into ibc directly on any chain you know where those are available the real problem is that on many chains those aren't available there's no ipc for ethereum and there is not going to be any time soon so we

are really excited about you know building out nomad router as substrate pallet or building out the cosmosim version and building like the little shim contracts that connect the router to xcm or connect the router to ibc would that actually be the application deployer who would then use that so it would be like an application like it but you know we're looking for that we're looking to provide that build once deploy anywhere model where it shouldn't matter to the application developer whether they're using ibc or xcm they shouldn't need to write special contracts

for those that should be handled for them by the router framework that they build on in the long run we're going to be able to do that right now you know xcm is so nascent cosmos i'm so nascent like it's going to take a while to get to that point but because we built this with a future forward compatibility in mind we think that we're going to provide some of the best developer experience around consistent applications using different channels underneath where would the like just using the ibc case like would there be a relayer from a chain to nomad or would it be like

that that's the one thing i'm not totally clear on like would you almost deploy an instance of ibc on your side and exist kind of as a standalone zone for this particular case i guess you're talking about these frameworks i think this is where i'm a little bit lost i just don't know exactly what that would look like um i don't think we're ever going to want to build our own zone or our own chain the way i feel about it is you have two block chains and you need one connection between them it doesn't make sense to build a third block chain to try to provide that because now you just have three block chains and you need three connections okay uh you've made your problem worse by building a new chain not better um

so our goal is essentially build out the application pattern you know make it really easy to build applications and then anywhere we can use ibc or xcm your application should just do that for you and anywhere you can't use ibc or xcm it will use the underlying nomad channel so you know between two different cosmos zones ibc exists we want to use ibc uh it's fast it's secure it's subsidized uh you know like we want to use it between two different para chains if xcm is available we want to use xcm uh between cosmos and ethereum like

their ibc is not available between uh any substrate zone and ethereum xcm is not available uh so your application though should not have to worry about that your application shouldn't have to worry about which cross-chain communication mechanism it's using it should just be hooked up uh and be ready to go is there a limit though to the number of chains that you guys can build like i mean you sort of did a call out just before for help but like do you do you have to cap it at some point because there are all these different architectures uh we have to very carefully prioritize where we build yeah we have to prioritize

the cap is um you know theoretically limited by our lifespans i guess but um we have to prioritize i i did ask this earlier and i'm kind of gonna ask it again but like was that is there one that's harder for you to build on on your side any of the networks chains and i know mostly you've done evms so maybe you haven't even explored what it would be like for all the other ones but well we've done a little bit of experimentation in near wasm in cosum wasm uh you know i've played around with writing substrate palettes and writing solana smart contracts i don't know that it's there is any specific environment where it's more

difficult i think it's more about the maturity of the relative environments um evm is very mature we know how to do contract upgrades in the evm like everybody knows how they work and how delegate call works uh it is much easier to find evm talent and people who deeply understand the evm every other system out there is a little more nascent you know these exist there are developers for them but it's you know less than a tenth of what you can find for solidity developers and the depth of expertise is not there the way it is with uh solidity yet i can go out and i can talk to like

several dozen deep solidity experts on telegram right now if i want to uh people who really understand the intricacies of the evm and how smart contracts call each other and all the little edge cases and gotchas in the evm other environments they have those edge cases they have those gotchas it's just that there aren't as many experts who know them really well and when you have something delicate like uh transaction routing from across chain like meta transaction smart contract upgrades really want a high level of expertise to ensure that we get it right and so it's not that any particular

environment is going to be more difficult to implement in it's that the available expertise in solana is not yet what it is in ethereum or the available expertise in qasim wasn't or substrate is not yet the same so we are going to take more time because we want to be more sure of our work there because it's just not as well understood yet yeah i mean so many of the meaningful like smart contract bugs that have caused like massive hacks are so subtle or so deep in the weeds um it's really a question of having that level of understanding which we do in evm and which we want to collaborate with

folks who do in other ecosystems james's point being that's harder to find in other ecosystems a really like concrete example of this is the wormhole hack um a few months ago exactly it was an issue with how the smart contracts checked signatures um ethereum has a very analogous issue that ec recover um returns zero for invalid signatures so you need to not just check the signature you also need to check whether the output was zero uh so back in the day you're like five years ago a bunch of people made that mistake and then it became common solidity practice and well understood

and a bunch of experts were aware of it because in solana nobody had yet like made that mistake uh there weren't people who were aware of the issue and how to avoid it so uh solana you know fortunately able to remedy this with standard library updates which florida doesn't have a standard library uh but you know in general like some of these hacks happen just because the environment the code is running in is not well understood not deeply understood by the developers so we want to be very careful adding new environments that you know like i don't deeply understand or anna doesn't deeply understand yet got it

i had sergey on the show i think about a month ago from axillar and we talked a lot about that system i have seen nomad and axler kind of put sometimes like head to head in bridge and interoperability competitions or whatever so i am curious like what what do you make of that system how do you see it as different i mean obviously i think you're going to feel that nomad is is better but yeah i'm just curious what you what you make of it yeah definitely um you know i think uh axler is a nice iteration of the thor chain model uh this idea that a proof of stake chain should select the multi-sig

members for a multi-sig bridge you know they they have some nice efficiencies there i i think i want to see more security model innovation in bridges is i don't think that introducing a new chain and a new proof-of-stake inflation system to try the same security model with some efficiency gains as like what i would spend my time on this actually this just makes me realize something that we didn't get a chance to talk about yet which is the agents on nomad like you just sort of mentioned proof of stake you're not right you have these watchers they have you have a few different roles right we

have several different roles the two that matter like the two that are trusted that are part of the security model are the updater and the watcher okay the updater's job is to sign the route of this merkle tree they you know receive an instruction from the smart contract that just says sign this route and they sign it and give it back to the smart contract on the sending chain like that's the whole thing they need to do the watchers job is to check that the updater is doing that correctly to cause the updater to be slashed if they're not

and to if they are permissioned by an application to go and shut down that application before any fraudulent messages are received so the updater is really boring and the watchers are much more interesting the updater is system selected while the watcher should be selected by the applications um and this is what you know distinguishes us from just a multi-sig uh like wormhole or layer zero or a you know proof-of-stake selected multi-sig like axelr or thor chain is that the watchers must be for the security model chosen by

the application not by the cross chain system wouldn't would an application choose a single watcher or is it a group they can choose as many as they want they could have it be a group they could have it be like five individuals they could have it just be one you know watcher the trade-off is you know the watchers need to be online they need to be prepared to shut down this application and they need to only do that if there's actually fraud you know kind of the trade-off here is that the watchers can prevent fraud but they can also shut down the application so if they do that when there's not fraud you have a problem so you need to choose watchers that are

trusted by the application to not denial of service attack it got it and this is like pretty important i think uh about our system is that um the entity that right now has the most trust placed in it the worst that they can do is cause a delay they cannot steal funds and that's why our system is based on uh james you know put this nicely revocation rather than permission the trust lies in trusting someone to stop bad things instead of trusting someone to uh you know force good things if that makes sense if trust breaks in a system where you trust uh you know you trust

someone to permit only good things um then that's when the root of trust breaking can cause loss of funds right i mean that's like the ronin hack for example the reason nomad is not the same as a multi-sig is because even if you steal all of the keys if you steal the updater key and all of the watcher keys you still can't steal funds from the system as long as any watcher has access to a key even if the attacker has access to the same key the honest party can still shut down the application and prevent fraud from occurring or rather prevent fraud from damaging users in any way and this is

you know we think basically the only innovation in bridge models in the last five years well cool i want to sort of wrap up our interview talking a little bit about use cases so we had sort of mentioned uh i think we mentioned somewhere the voting use case i also wanted to sort of walk through this zk idea to see kind of how or if it would work on maybe even what the challenge would be and the idea here would be like to create a proof on one side that you'd verify on another i don't know what you'd actually i in the previous episode i actually rob gave me a really much more complex like smart way of describing this and i can't remember it

but um basically i think i just want to know if like could you use a bridge like nomad to push like a proof through that would be verified on the other side and it's not that the construction is a zk or zk bridge of any sort but just that like a zero knowledge proof could be interacted with across uh yeah you can definitely use nomad to do things like that we've thought about using zero knowledge proofs for like messages in the merkle tree or for more complex non-mercalized commitments you know various other ways of connecting the message to the to the commitment um i do want to ask about the other this other use case as well though this use case of voting because this sounds like

something that has been kind of fleshed out and i'm curious like how is that going to work yeah well for for cross-chain governance there's a couple different related issues you know one is you have users on polygon who have compound or ave and they want to vote in the governance system which only exists on ethereum so how do you let those users who are on some other chain vote in governance and then the second is ave governance and unit swap governance and compound governance and all of these different governance systems are only on ethereum

once users have voted you know once governance has reached an outcome how do you take that outcome and send it to other chains and implement it on other chains so we have some very strong opinions on these subjects and governance is one of the use cases that we are most excited about and that we built out of the box to start off so from launch nomad has had a cross-chain governance system which manages and controls all of our smart contracts on different chains you know governance decisions are made on ethereum and then are sent to other chains to be implemented and for the you know like first part of

the problem users voting uh we have some really cool plans here we want to enable users to vote on other chains without losing liquidity of their assets and so we're looking at voting vaults and gauges and you know how we can take the lessons learned from curve and from the element finance voting systems and apply them in a cross-chain environment i don't want to get into like details of like what we're thinking right now because we haven't built this out yet and the specifications aren't finalized but we're really you know excited about this is we think that for the next several years like

voting in governance is going to be one of the most interesting things a user can do in you know defy and smart contract ecosystems and we think we have it as a first-class use case in nomad i think what's really interesting about cross-chain governance right now is that so many applications and so many teams and protocols actually have this problem and a lot of them don't even know yet really that they have this problem or sort of what the problem space even looks like and this is kind of

vestigial of how the market structure developed in this case so basically you know because solidity smart contracts can be deployed on other evm chains what happened was protocols that gained success on ethereum you know as new evm chains launched like polygon for example and you know more and more i mean optimism arbitrary etc there became sort of this pressure for a lot of these applications to deploy on other evm chains and oftentimes they did so without necessarily

putting a lot of design work into how those protocols would be governed on other chains so um right as james sort of mentioned in a lot of cases the canonical or the initial protocol lives on ethereum the token and the governance system lives on ethereum but now their protocol is also deployed and living on other evm chains and so the question becomes how can you take this setup and convert it into something that has truly decentralized governance across all these different deployments and the easiest way to do that with where things are right

now really looks like okay governance lives on ethereum will let it live on ethereum decisions are made on ethereum but when decisions are made you can also make decisions about protocols on other chains and just simply pass that decision to the other chain um to be executed but don't you see like i've always heard this argument that like the voting should happen actually not on the main chain ethereum maybe it's a different evm chain because of its expense it's so expensive and it's like not of value i mean it's valuable but it's not like do you want to spend the gas to submit a small vote or maybe you have to do multiple votes yeah i'm curious if

you're if you're also when you say ethereum do you kind of mean like ethereum and evm adjacent where votes could happen or do you just think it will never move off well a lot of people are interested in or talk about moving votes to cheaper chains moving voting to a cheaper chain you know like optimism or like polygon for example and i think this is a really interesting avenue to pursue um as things sort of develop it's just not really um where the ecosystem is at right now basically um you know where we're at right now tokens and governance live on ethereum

generally speaking there's just a lot of considerations here but um i'd say you can think of this as two different structures and then there's like sub options within each but really there's two main sort of choices which are you have a single governor chain a single chain to rule them all and that is where decisions are made and those decisions are passed to other chains and in the current ecosystem the governor chain in almost all cases is ethereum right that's where governance was initially launched and that's where decisions are made and so people talk about moving the kind of quote-unquote governor chain the

the source of truth for where decisions are made to other cheaper chains um and really the other option is just fully localized governance right so like each chain governs itself and there is no global governance and that in that construction you don't really need a cross-chain sort of messaging thing because it all is localized the the problem is when apps don't have a consistent strategy here there's not really consistent governance for a bunch of these defy applications across the chains they're deployed on it's haphazard at best the beauty of you know using cross-chain

messaging for this is that you can essentially build over time a modular governance system i i love calling things modular now that's you know fully fully celestial but the place where the votes are made the place where the votes are counted and the place where the decision is committed and propagated out to other chains those don't have to be the same system and they don't have to be on the same chain anymore you can have votes on every chain that go to one place to be counted and then the result of the vote tabulation is sent to the place that make you know

handles governance decisions uh and then the result of the decision is sent out to other places got it the problem today is that applications just have no consistent plan for this uh they've deployed places trying to grow quickly and now they're having to go back and figure out governance after the fact and that's what we want to help them with cool do you have any projects already doing this or is this sort of like something you've mapped out architecturally absolutely so there are projects that are doing this and then there are projects that have designed this and are doing that okay okay slightly different um but we have been working with stakeholders in the

uniswap ecosystem uh to discuss what this looks like in uniswap right now uniswap is deployed on more than more chains than just ethereum but the uni voting token and the sort of governor bravo contract both live on ethereum so um they had built a sort of bespoke solution for each chain to govern the protocol on remote non-ethereum chains there were a lot of problems with that first every time uniswap wanted to deploy to another chain they had to figure out a bespoke system for passing governance messages from ethereum to

that chain and in practice that included not just different message passing channels but also different smart contracts to communicate over these message passing channels and what this created was a sort of patchwork of solutions that were very difficult to interact with as a governance participant trying to pass a proposal across chains so the system was you know somewhat opaque difficult to navigate borderline impossible to build easier experiences on top of and basically very difficult to extend new chains which sort of rate limited the speed at which

uniswap could deploy to new chains if there was a standardized solution for this across all chains for example using nomad as the message passing channel and a standard set of smart contracts for uh you know communicating over nomad then you would have an out of the box solution deploying to new chains you could pretty much make deploying uniswap to new chains a push button experience and then indeed you would also have a standardized interface and solution for people trying to pass proposals and to actually govern and use this governance system across chains um

so uniswap is one uh sort of protocol that we've been working really closely with on this for a couple of months an example of a team that has has sort of designed a system around this is um the ave team actually they have you know put out some thinking around cross chain governance and built a solution for themselves but their solution as well also used different message passing channels for every chain which again replicated this really cumbersome experience deploying to new chains interacting um and i believe that they are you know thinking about better

ways and more standardized ways to do this cool i mean it sounds almost like this is work like i i feel like we should do a full episode on like new governance structures and voting structures across this ecosystem we are a little bit out of time to go too deep on into it today but um it sounds like a really cool use case and i am very excited to see it in action what status is this at the status of this governance discussion with uniswap right now proposals are live on chain to deploy uniswap v3 to moonbeam as well as to gnosis chain and

both of these chains both of these new deployments are using nomad for cross-chain governance and one of these proposals is being stewarded by me by nomad um i am nomad by the way cool it's true um but yeah so the status is um for both of these new deployments they are using nomad and we are discussing with stakeholders in the community whether it would be a value add and what it would look like for nomad to provide this sort of as a service for any new chain deployments and even

possibly for existing deployments again to create a much simpler smoother experience to deploy to new chains and to use governance on existing chains cool so thanks so much to both of you for coming on this show and sharing kind of the journey to nomad what you're working on where it's going in a lot of ways uh yeah thanks so much for sharing this with us it's been so lovely thanks for having us anna thank you yeah and james i'm going to ask one more i know i'm putting you on the spot but you'll come back as a co-host right of course okay good thank you to the podcast editor henrik

the podcast producer tanya chris who helped with research and to our listeners thanks for listening you