The problem with Cross-Chain Governance

Transcript

yes globally yes going international hello uh today we're going to talk about the problem with cross-chain governance i'm odysseus from nomad which is a generic cross-chain communication protocol we're going to set up a basic glossary talk about nomad and who we are assert introduction into interoperability the problem with approach and governance um then we're going to dive into a bit how number works as a protocol why we think that you know cross-chain

governance with nomad makes sense and i'm going to finish it off with a couple of resources and the conclusion first one we say about crosschain what's crossing what's cross-domain basically we reference the communication between different uh blockchains uh that inter are interconnected in a way that make sense in a way where applications can meaningfully uh communicate with one another among different domains uh no one is an optimistic system we're going to talk about that later but basically what an optimistic system is is that we assume always that

the function system works as expected and only if fraud happens we we we believe we hope that a good actor will tell the system that fraud happened and then the system will roll back in order to remove that fraud and when we talk about governance we don't talk about multi-sigs or anything like that with reference to protocols that are governed by a dao where token voters can use their tokens to vote and the result of the vote is direct code execution for example like maker dao where a proposal is passed code is executed to change some aspect of maker

we will talk a lot about merkle trees so let's do a quick introduction for those who doesn't know what merkel trees is it's basically a very simple way to showcase that something belongs to a larger set we have uh basically the hash of a message and or a lot of messages we don't care let's say we have one message and then we do hashes of the messages and we do the hash of the hashes and we create a tree like structure until we reach a root so right now with a single root we have a very easy way to prove that something belongs to that set because that information is

exists in the tree now if we want to add a new message to the tree we just add a new message we do again all the hashes and now that the tree the the root of the tree has changed so this is a very easy way to uh do a massive compression of of basically of data because instead of telling of giving you 10 000 messages to prove you that this message belongs to all that messages i can give you the message that i want to prove give you the hashes and then you can do the hashing yourself and figure out the route my name is odysseus i'm a protocol engineer in nomad

and that's my twitter this work was raj largely spearheaded by anna carroll who is protocol leading nomad uh so it's most of that work has already been done to to serve nombat protocol itself as we are across chain protocol so we needed a way to do course and governance ourselves now let's let's change a bit let's change space what's interrupt let's do a smart okay cool yeah so let's do a small introduction to interrupt

so at first we had uh multi-sticks it was the very simple way to do interpretability basically you have a bunch of people a group of people that attest that something happened on them on one chain and then they go to the other chain and say okay this happened and you trust that this bunch of people are uh honest then we had validators which is basically the same idea as multi-six but let's add some economic uh incentive in that for example if that if a signatory in that multisig or something the multisig fails they do some bad things maybe they lose some bond maybe they lose some money basically the same thing

with just some economic incentives the third way was optimistic so that's nomad it's the only protocol out there that has the optimistic design and basically it says that the system works as expected and you have a multi-sig or you have a validator we call it updater that sees that something happen on one chain and goes to the other chain says okay this thing happened but also we have a fraud proof window so basically we say that after after the updater goes to the second chain there is a period where someone can go to the chain and says no fraud happened this is not correct so we

turn the system you know the design on its head and instead of trusting a multisig you have to trust at least one person like at least one honest player will tell that fraud happened and the fourth phase which is like the end game it's light client it's basically a way to to verify the consensus of one chain into a smart contract or the contents of another chain for example that's cosmos where every chain in the cosmos ecosystem can verify the block headers from any other chain in the cosmos ecosystem that's great because it's very secure very fast but it's very complex it's

very costly so maybe we'll reach a point where we have light cleanse everywhere but at this point probably the most pragmatic approach is the optimistic design christian governance now we have an understanding of basically all the major design schools for cross chain protocols let's talk about grocery and governance what's crushing governance it's very simple you have maker on ethereum right you have the maker uh holders they vote for on the doubt to change the protocol but now maker needs to exist another protocol

follow the liquidity basically so what do you do how do you propagate that proposal how do you force the same change across other domains other numbers of different ways that protocols have go about it because all the protocols have this problem because if they see users in other domains the first thing is to do some patchwork basically you try to use existing bridges that exist for example polygon ethereum has a native bridge by the polygon team so you try to do this patchwork which doesn't really work it's not maintainable um it's a lot of ad-hoc scripts and work

and it's cheap but it's not a long-term solution some other protocols try to do their role of your own basically they try to create their own cross chain interoperability protocol within the protocol it's like creating a startup within startup we think the problem is too great and too big for a protocol to solve as a side gig better more better designed that the patchwork but again it's it's hard to maintain just simply easier from all approaches basically you just you know vote here you reach a conclusion here and then you have a multisig here

and you hope that the multisig owners will honor that um will honor the same [Music] decision and implement the same changes it's basically larping it's not a cross-chain governance nomad what we propose is basically two parts one part is you have a protocol which is normal which is we think very secure and it's a generic protocol for crosstalk messaging and on top of that you every dao creates a simple smart contract the executor which when deployed is configured to receive

messages from the canonical chain and owns the protocol here so this executor will always receive always accept protocols that originate from here and the protocol can only accept changes from here because it's owned by that and the key word here is standardization we standardize the layer here and we standardize the layer here so now protocols have a very easy way to do cross-chain governance without having to solve to a lot of problems let's we have

a message from ethereum and then the relayer which is an off-chain agent will which is trustless and later attested to a new message so it will take that uh message we'll talk about it later and go to moonbeam which is another check and then and if if the watch you know fraud happened

then the processor was another change again yes let's see how many microphones will change until the end of this talk yes so the processor will process the message and do whatever the message needs to be done and this part this part of them will follow if we want more messages to go from one domain to another so it's three steps and this is optional this the watcher will interject only if fraud happens and needs to shut off the system to go a bit into more detail into how the protocol works because i said

message because that's not correct it's not a message that is sent through the protocol it's a milker route so let's see how that happens and why mercury routes are very important to the protocol so where the dao um votes for a proposal here it goes to a router router doesn't it's not important just it's a user defined contract that will take a user action and make it to comply to the nomad protocol and basically it will go to home which is the outbox from the for domain and say hey this much dispatch this message some

domain doesn't matter and the smart contract will just emit a special event now this message is added to a queue of messages that are sent from home but it's not yet sent when the the updater which is an off chain agent it's bonded it's the equivalent of a validator in other protocols it will pull for events on home and maybe it's one message maybe it waits for a lot of messages it wants to batch them together it will at some point it will take all these messages and it will call the update function basically what it does is that it it

empties the queue of messages and adds them to the merkle tree so every home every outbox has a mercury tree of messages that have been sent from that domain and now the since they are added to the tree you have a new root so as i said mercury is a great way to compress information about something existing in a set so now you have a new route for that tree so you don't need to send every message through the protocol the protocol just needs to make sure that the route will go

from home from the sending chain to the receiving chain if the route goes there and lands there and in a secure way then anyone can go to the receiving chain with a message and say hey this message belongs to that route and since it can be proven unchained the message will be processed for example sent to the recipient so we don't the the protocol doesn't care to send messages per se it sends roots and that's ingenious because instead of having to deal with hundreds or hundreds of thousands of messages you just send some small strings and you know that if you do that correctly and efficiently and securely then you can prove an arbitrary number

of messages against that root so you can send a lot of messages so let's go back to this example so yeah the updater will call the update on home so basically testing that new messages have been sent from the domain and a new update event will be emitted and the relayer which is an off chain agent will just read that update event and go to the replica which is the receiving chain and say hey i have a new route you know the sending chain hasn't new messages there's a new root so you should get it and a lot of people will ask me why the real layer works you know why should

someone run the relayer what's the cryptocurrency incentive and there is none the incentive for running real layer is that you care that the protocol works you care that you want your messages to go from one domain to another fast enough for example you have a protocol you have a maker though you have unisop and you want your government's you know proposals to go from one domain to another in a fast way you care about it so you run every layer it's cheap for you you have an incentive not a crypt economic incentive but at an incentive in the protocol to work because you use it and now the route has landed on the replica on the inbox and the window of

time starts on the happy path there is no fraud so no one will go to say that fraud happened stop everything you do fraud happened the system should hold so um we're missing a line here but that's okay it's a it's just a line um yeah the processor will uh check that the time has passed which is another off-chain agent another in in it's without incentive crypto economic incentive that is um and then when the time passes it will start it will take all the messages that were sent it knows about them from

events and we'll just start proving them against the root the new route simple and proven process basically says prove the message and then process it processing means that send it and in the nomad protocol in how we designed it basically the replica will handle we'll call the handle function it expects that the recipient will implement a handle function with arbitrary logic and that's it so in our use case the router is router and protocol this is the user defined

contracts so replica will call the handle in the in the governance let's say project we're talking about and then the contracts knows what to do in our case it's an executor so the executor will it will call handle in the executor contract which implements the routing functionality and it will read the proposal and it will execute it does it make sense up to this point awesome so why choose nomad governance as i said other a lot of different ways to go about it a lot of protocols have their

solutions i think nomads is the best out there for two reasons it's very good and very secure it's probably one of the secure if not the most secure solution out there and it's relevantly it's relatively easy and simple so you get a very nice equilibrium between difficulty and quality the numbered protocol is trust minimized and secure as i said you don't trust a validator set you don't trust that any n of m people will be honest maybe that's great when you do 500 u 500 you know usdc amounts

bridging between domains but when you're maker dow and you want to execute a proposal that could have hundreds of millions of dollars in second order or third order effects then you care that it's as secure as possible and the most it's as secure as possible because it's trust minimized you run your own water you know that even if everything is malicious the updater is model issues everything goes wrong your water will cut the system from performing a malicious transaction so your funds are secure it's low cost it's a very simple protocol as i said we just care about passing arbitrary things strings the root so it's very cheap relatively to light clients

it's simple which means secure it's very simple very easy to implement in a lot of chains we are only a medium change right now but it's very easy to go to new chains when we have the capability to do so um and it has a bit of lag it does you know it's an optimistic protocol we have to wait to see that fraud didn't happen but that's maybe problematic when you want to bridge tokens so you you need to use liquidity layers on top of it like connex we we they're a great partner with us and basically they solve that so we have everything

but like in protocols in governance you don't care about luck you don't care if your proposal takes i know 30 minutes one hour more two hours more to execute and the the most succinct way to put it is again what do you trust do you trust to like a validator bridge which basically some different people saying that it will be honest and be good players but you don't know really and the that trio it's the same pokemon underneath it seems that they're different pokemons but it's the same pokemon and that means that

it's a multisig of i know 15 of 30. but is it true 15 or 30 do you really know that these you know very big institutions own the address they say they do or maybe it's less you don't know and again maybe you don't care if you move smaller amounts or whatever but when you're a big protocol and your proposal executions could have hundreds of millions of dollars in second and third order effective with these liquidations and so on you care or you care or you have a watcher boy it's simple you care you choose who to trust you don't trust a random unknown number of people

to you or known people that you don't know them personally you trust only a single entity that you control and you trust at least a single entity to be more more uh specific you can have many watchers but you need at least one to be honest for the system to work and be secure um to to dev a bit into the water more uh specifically the water has two that's two things um it's part permissioned and part permissionless and that's why we say that the apps choose who to trust because it's up to the t to enable to

allow a watcher to uh watch over it and what i mean by that is that the water when it sees fraud it will go to the sending chain and say hey this route was posted with your with the signature of the updater but you don't have any record of it and because the sending chain has all um you know it has a list of all the roots that have ever been generated it knows all the messages that have ever been sent it can see that okay the updater was fraudulent the updater was malicious that's the permissionless part anyone can do that anyone can post that proof

the permission part comes here and basically it says that the receiving chain has no way to to verify if a message is fraudulent it doesn't know all the messages that have ever been sent so um it trusts the watcher that if fraud happens it will disconnect the application from receiving messages and the trust comes to the part that if it was permissionless anyone could run the function anyone could halt the replica again and again and again briefing no word no reason

because replica the receiving chain has no way to verify fraud so if fraud happens it doesn't happen nope yes so if fraud happened let's see how a fraud would happen to understand the difference between being trustless and trusted so you generate uh a malicious message okay a message that is fraudulent uh you're the updater you want to steal

all the money from maker dao you generate the message that would do that that would allow you to you know withdraw or the collateral from a domain and then you generate the route the new route so you you take the existing route you you take the new fraudulent message you add it to that root and you have a new root now you are the updater you can do that and now you can call the update as we as we saw before that basically adds your it updates the route the existing route to a new fraudulent route that would allow you to prove uh your fraudulent message right on home then because the real layer works it

will relay your fraudulent route to replica okay it will relay your fraudulent route to replica and then is when the water would kick in and would stop the system so at before you can you have any time while the fraudulent uh window is going on and you you can't process the message um it would go to home and it would pause fraud so it would up you know it would post the fraudulent route and say hey fraud happened this updater was uh post posted the route that didn't exist and then it will disconnect in this smart contract it will disconnect your application from replica

so it will disconnect the water will disconnect the applications that is watching over from the inbox by disconnecting it means that they can't receive messages another way we said water is trusted so every application the system assumes that in every application the water will disconnect that application from from receiving messages and in that way update the home contract knows about the updater the updater can't post a new fraudulent routes and since these applications have been disconnected from

replica even if after the time passes they can't process the message because the recipients have been disconnected so they will try to process them the malicious messages and it will not be possible because the applications have been disconnected and that's how a watcher would protect its application a watcher can protect many applications it's up to um you know it's we expect to see for example services where your protocol you run your own water but you also run you only also probably you know buy a water service for extra safety and liveness and so on but that's the system and it's very

simple and we we move the power to the user to the protocol to decide who to trust and that doesn't work awesome so yeah so what choose nomad governance as i hinted before it's a message flashing protocol we put a standardized executor we partnered with gnosis zodiac to do that so it's very easy for those to just deploy the executor and use the system to do question governance again

it's very easy and secure that's what we try to be as you know as hustle free as possible in conclusion um governance is way harder that it looks like um it's it's like surgery um it's necessary um your protocol have to go where your users are but um it's better if you don't do it yourself it's better if your protocol doesn't have to deal with it and you just take a solution of the self um the right framework to think about it is that you should find a message passing protocol that covers your

requirements maybe you care more about safety and security maybe you care more about speed but the important part is to know your trade-offs and find the standardized interface like the executor we talked about because it's easy because you just deploy the interface you put the protocol to be owned by that interface and you're done you don't have to deal with any of that um no zodiac is trust minimized and secure it's cheap to use the same old things we we we talk about simplicity a lot because simplicity security if it's simple if it's easy to reason

about it's secure and of course there is no silver bullets in bridging there are no silver bullets in cross-chain communication it's all about you know trade-offs nomad is secure but it has lag other protocols are more fast but there is a cr you know there is a trust assumption for example validator so you should know the trade-offs um i'm a pos that are breeds i continue to exist as a slowly shrink and transform into nfm multisig my point is there's a lot of marketing speaking in the area it was you know interrupt was a niche now it's coming slowly to the main stage

so it's important to try to go uh you know over the marketing spring and really understand what the assumptions and the trade-offs for your solution because if you don't do someone else will do and you will get a multi-million dollar bridge most of the you know the leaders in direct leaderboard in the paper if you found these bridges there's a reason why because they assume things that we shouldn't assume some resources you can find the code here and play with the system and thank you for your time

now without any questions i think we have some time thank you watcher is incentivized somehow uh to to verify or uh just launched as part of their applications uh so no need to incentivize the watcher additionally yeah and um if uh it still uh helds a legit uh or message uh is it slashed somehow or not yeah and yeah related question uh this uh punishment of disconnecting is it like forever or it just for a

period of time yeah thank you great great questions thank you uh crypto economic incentives are hard so a general design you know approaches we try to eliminate as much as possible so we say the incentive of the water is maybe it's out of bond payment maybe it's a service like running your own you know you run a full node an archival node and you offer it as a service and also i will run my voucher for my app maybe i'm a big chip like a maker dow i will run my own water because i care for the system to work i i want to i don't want to trust anyone i want to trust my own water but perhaps

there's a liveness failure so that's why i would probably go out and buy a water service as well just to be sure so generally we try to go for in a social layer consensus and use the social layer as much as possible just because it's a rabbit hole to make an encrypted economic incentive system um to launch such a watcher it's very easy we have like we are actually we're refining our dogs right now it's very easy to self-serve and run

your own water but obviously this is an open market i expect the system to have like service like you know big providers to offer watcher service um because maybe you don't want to maintain your own operators but you want to trust someone and that someone will put their reputation at stake so if they can't for example grief you because if they grief you you will go out and say i trusted the operator and they trolled me so they don't have customers anymore and actually it's the only actually that's a very good uh point is that it's proven

in a very famous paper in 2019 that it's impossible to have bridging without a trust consumption so we are trying to move away from you trusting with we telling you who to trust and having to trust some people being honest and if they are not you're screwed if their keys are hacked to you choosing who to trust and you need at least one honest player to be to secure but you need trust at some point in the system again so the only action watcher can do is to cut vectors specific which is change so

just discard it he can't propose any other changes but only block the existing one exactly the worst they can do the worst is they will troll you by disconnecting your application from a receiving chain receiving at which point you're up you know you just change the watcher set so they can't anymore interact with your application because you have uh removed them from the white list and that's the same with like how do you reconnect right if fraud happens that the system holds the system will has a governance so the the nomad governance will

restart the system we're working it's an active research area because we have to remove the fraud from the system and then we have to restart the system so this is something we will be working on now we have some designs but yeah on your application it's up to you to implement the logic on how the application can reconnect to the protocol thank you thank you no more questions i had a question is it possible to have multiple watchers instead of a

single one to reduce the number the possibility of fraud yes so like have for example like 10 and if one is fraudulent but the other nine say otherwise you exactly okay exactly the only point being that the more watchers you have the more risk you have from griefing but of course if griefing happens it's very easy for just to remove that water so they can't interact with your protocol okay thank you yeah thank you