Evaluating cross-chain messaging protocols | Bryan Pellegrino (Co-Founder and CEO, LayerZero Labs)

Transcript

[Music] thank you let me talk about evaluating  cross-train messaging protocols but I think like the more important topic especially piggybacking  on kind of the first two conversations just building protocols in general in the space and  I think it's both ways how you look at protocols you're interacting with and how you think  about building your own protocols along the way um so the current kind of state of the world of  cross-chain messaging as Nas and Riaz just went through uh is a little bit uh hectic in terms  of like a lot of a lot of the hacks have kind of revolved around that you see exponential growth  in the protocols themselves we've gone from all messaging protocols collectively doing tens  of thousands of messages per month the single

applications doing millions of messages per month  and that's just been in about a year now right so um tremendous tremendous growth  uh proliferation of l2s has only accelerated this and that's getting crazier  with base in ZK sync and like everything else coming out right that that like layer of  horizontal composability is expanding rapidly um unfortunately the same trade-off uh and how  these systems are being built right now is like increasingly centralized systems so most  protocols when it comes to messaging like I go to this topic of service first protocol  most of what you're getting from many of them is you're opting into a service right there's a  third party service they're not building like a protocol you're relying on in individual set of  actors to basically perform this messaging for you and if for any reason they fail or they you  know term malicious or like all of these other

things there's just this Vector of one entity  that controls it and provides this for you um so you know like Ali was was talking about  earlier like there is this trade-off where early on those systems will be more performant but  they have a much higher failure rate there's a lot of other things that go into that and so  right now we often see risk traded for ease so when you're evaluating across your investing  protocol or just any protocol in general and how I think or we think about building protocols  there's really like three things that are that are fundamental to most things in this space  and it's immutability permissionlessness and censorship resistant uh those three things  I think are the foundation of almost every super successful protocol in the space  uh and really kind of the the earliest

um Catalyst for for why the space exists  in the first part so first one is easy immutability why why does it actually  matter so going back to the Nomad hack um The Nomad hack has this you know interesting  system you have optimistic messaging you have all the stuff that's that's sort of meant to be this  this security Vector in improving how the system works but the end of the day they have the ability  to push underlying code right so they could update uh the code in the contract at any point in time  which completely changes the spectrum of security that the end user or the application building on  top has so when you talk about like how do you actually think about evaluating the security of  a protocol like you can do things that give you a better indication early on so you can get audits  you can have rigorous internal auditing process

you have external bug bounties to make sure that  there are white hat eyes on this that basically there's there's been enough time for people to  look at it and try to break it and it stood the test of time but ultimately if you look at any  system in the wild it's really how much value has been secured and how long has it existed for why  is uniswap you know as a mechanism seen as so much more secure as a deck suit who takes Liberties  and Spins up something entirely new right it's it's really because the contracts for uniswap have  been uh securing tens of billions of dollars for many years now and I've never had a security issue  right they're not upgradable they can't be changed uh it is a set of things that like exist and  everybody knows what they're opting into and most

protocols you see when they launch tvl grows over  time in the most successful Ave certainly did not launch with 30 billion dollars of TV all launched  with a small amount and overall over time as it hardens it increases and so I think the the best  ad hoc measure is is simply value secured amount of time how big are the Honeypot has it been and  how long has there been for Bad actors or good actors in the case of white hats to come and try  to basically do this what is their incentive Ben um so the issue with immutability is this uh  anytime you upgrade a contract uh you basically lose all security so you have this you know  billions of dollars secured it's been around for a year you're in a great state you push a change  of code that may seem completely benign uh and

security goes back to effectively zero and this  has been time and time and time again I actually think in the last six months we've probably seen  four to five major examples of exactly this and so again these are like the vector of the validator  set is malicious and they're actively trying to exploit you in the crypto economic system has  been broken that is basically never happened uh or almost never happened in all of these hacks  what has happened repeatedly is I'm a Dev and I want to make an upgrade to the system so I'm going  to push some code I'm not trying to hurt anybody I'm just trying to make the system a little bit  better add a new feature do whatever you don't necessarily understand all the interactions  that that brings you've missed something the Auditors have missed something and all of a sudden  everything's gone right um which was the case in

in The Nomad hack they pushed something again that  was extremely benign and just forgot to check uh for for the zero address and then everybody could  just repeatedly perform this attack and so when you have the ability any any protocol especially  messaging if it has a product it has the ability to upgrade the contracts in the underlying  it will always be an existential risk for the applications building on top and this is  the same way if uniswap had the ability like when I talk about immutability I think uniswap  is honestly the gold standard so when uniswap migrates from V1 to V2 in V2 to V3 like it is  painful and miserable to try to coordinate tens of billions of dollars moving from one contract  to another right there's this massive social

coordination effort you are now in something that  they view as um less efficient possibly less fee efficient for the LPS uh and if they had an easy  button that they could press and auto migrate like 100 they would do that but if they had the ability  to do that then the relationship they'd have with LPS and the underlying stake is is drastically  different right nobody would trust the protocol because they would have the ability to move your  LP at any point in time which means they could effectively of malicious rug your funds and so the  reason it becomes so trusted is that they do not have this ability and so yes when you go V2 to V3  like V2 still has billions of dollars in it right they want everything to be in V3 but they don't  control it that's fine you make a system in the

market sort of decides what the best system is but  the code stands for itself and has stood the test of time um at scale and so if we don't accept  that in the applications that we regularly use it's crazy to me that that becomes common  practice at the messaging level so again almost 95 percent of messaging protocols today  are completely upgradable they have the ability to change the underlying way that the validation  system works or the contracts do authentication um and that again puts every single application  at the risk of a completely benign piece of code being moved and the whole Security State  changing for the application so I think of of all things that you can consider that should  be the number one thing is are the contracts

mutable or immutable and if they are upgradable  like what surface is exposed to me because even the best developers like it is very very hard to  write good code let alone perfect code and so like over a course of time any good developer  will make a mistake at some point in time and if that can repeatedly change you're just  like you have tail risk and on a long enough time frame there will always something  will always go wrong so immutability I think is like the number one principle for  this number two principle permissionlessness um this is like great examples of this so  obviously you know units are upgrade anybody can LP anybody can trade the entire system is there's  no gatekeeping there's no white listing for who

can make a pool on uniswot fruit and LP ethereum  is very much like this as well anybody can spin up a node anybody can participate in the network uh  there's permissionless application deploy anybody can deploy a contract on ethereum you don't need  to go to the foundation and ask permission you don't need to get whitelisted to do anything so  systems today are increasingly sort of bifurcated and how they're built along the Spectrum but  permissionlessness itself is just another Vector of security right ultimately if there are uh so  again I I'll keep going back to the Nomad case but like there were the Watchers in all optimistic  systems are like this but the Watcher set was not permissionless it says this white listed set of  Watchers where only a certain number of people Cuts you had two or three Watchers that have  the ability to to go down to potentially be

DDOS there's all these complications and there's  reasons why that system was built that way because it's very hard to make a permissionless set and  that and still keep liviness but anytime you don't have permissionlessness like what you lose  in the system is the ability like TCP like all of that the ability to have the adoption and the  network effects go you want to create a protocol that has the ability for anybody to participate  in anybody to build on uh and one of the big things is back to immutability is like without  immutability permissionlessness doesn't exist you can always change it so there's wait listing  you can always keep you can always do things and that itself becomes a huge problem in the next  step which is censorship resistance um because if

our principle when building is basically if  you have the ability to censor it will always be enforced always like even in the most free and  open system in the end like possibly the entire world right now it's effectively ethereum um you  look at what the validators have to go through right now in terms of like uh basically removing  blocks and and doing governmental things that are mandated down if you have the ability in the  code in the contracts to enforce any sort of censorship it will always happen and there are  a ton of reasons why AS application developers that you don't want this right so uh one is  the ability to reorder transactions so already there's Mev that sort of like exists in every  system you have submit a transaction there's a mempool there's value that can be extracted there  and that's chain specific you're not going to

change that you're not going to basically reduce  that surface significantly what you don't want when thinking cross chain is you don't want to  add it to that surface so any setup value again every single messaging protocol in the world  except a one right now I won't say which one but um every every uh every protocol in the world  right now has the ability to do this which is like really important they have the ability to reorder  transactions in middle which means there's no guaranteed delivery of transactions but it also  means like if you think about high frequency trading has done to traditional markets great  you see a trade pop up here and then you race that person to another Market to to take the value  to front run them this is you now own the layer of how messages get delivered and instead of just  like trying to beat them you can literally reorder

them all so that you can exploit the maximum  amount of value based on the order that they're submitted which is in a unbelievably large surface  of value that can be extracted on top of the on-chain Mev and so now like that itself like you  very much want non-serter enforcement one because of the financial constraints if you're doing  anything that's a financial application there is a a huge amount of value that will be extracted from  all of these messages from being reordered and lots of lots of these Protocols are even moving  in the direction of that being like part of the protocol like flashbots for cross-chain stuff but  but it's at the the messaging layer in the middle but it also means that there is the ability to  censor transactions there is the ability to take a governance vote that's going across and you can  think of you're ever building a system for votes

um with it within an electoral system right  within any political system the ability to uh even just the possibility of of losing votes the  possibility of removing a vote that you don't want you can see how quickly perverted that could  become and like what that could devolve into and any ability to censor not only like will likely  be exploited but we'll be forced to be enacted so I think censorship resistance at its core is  incredibly important this again goes back to immutable immutable contracts right you deploy  uniswap um and for some reason the government at some point in time you know the government of  Belgium says uh no more dog coins like dog coins are outlawed you you can't put them in there  like uniswap can't change that code there's

nothing that they can do the next version might  have something but like the system that is built and it's constructed in a way that that sort of  aligns with the ideological world of of the system that was being created cannot be perverted sort  of later on uh down the line uh which again I I think is like incredibly important because without  that things will get very very restricted very fast and like obviously as you're building the  systems you need to build them in such a way that complies with current standards at a global scale  always I think it's an increasingly uh sort of like complex surface to consider um but if you  leave it open to again the ability to change the way that it functions it's going to drastically  change how how people interact with that and so

once again without immutability censorship  resistance is is never guaranteed if you can add it in later somebody will add it in if you  can enforce censorship it will always be enforced at some point in time um so we'll go the the bulk  of the conversation which is really like building a better system so as you build and this up there  is like our method to do this but how do you build a system that is immutable is permissionless is  censorship resistance and how do you not get stuck in all of these uh sort of like local quagmires  so like one of the trade-offs that you guys were talking about with Nas and riyaz is like what  happens if something bad happens right the ability to pause a contract the ability to to change  State over time like how can you live in a line that gives users some form of protection but also  gives users protection from you like ultimately

if you're building a protocol and not building a  service or if you're building a service or your service provider is great there's lots of services  we all use every day if you're building a protocol the underlying user or application developer  who's building on top of you should not like if you disappear if you go away if for some  something happens to you in the team like that protocol should still exist the inventor of  tcpip you know doesn't change the current state of TCP it exists it's a protocol it's used at  scale it's adopted uh if you are intentionally malicious and as adversarial as humanly possible  the underlying user shouldn't need to care that much like if the unit swap devs uh decided all  they wanted to do was try to harm the users of unisoft there is nothing that they can do  literally they can turn on the fee switch

right that is the surface of control that  that unit swap has is they can add an extra five bips on a fee switch there and like that is  incredibly important because if you want to get adoption you can't leave that surface there and  so at the same time it's completely at odds with something bad is happening in Nomad and I want it  to stop right can somebody please save this and so I think you have people on both ends of spectrum  uniswap is if there was a bug in uniswap there's nothing that can be done right it's completely  immutable there is nobody you can pause it there's nobody you can save the LPS is a piece  of code that is meant to stand the test of time um and if something is wrong it's going to  be a race between LP's getting out and people

exploiting that like that's just the fact of the  case but that has allowed uniswap to become as as incredibly successful as it has so how we think  about it internally and one thing that I think is an interesting trip time locks there's a couple  things you can do to like okay this can change but everybody has some heads up and can opt out of  the system while this is changing so that was kind of like the first surface of like we can upgrade  code but you're gonna have a seven day heads up so feel free to flee if you want now that's probably  fine you know maybe that's fine for something like a DEX like a uniswap where um okay seven days  I can I can remove my LP I've heard about this great if you're a messaging protocol and somebody  has built their entire business on top of you

uh their protocol is like they need to shut down  their protocol and flee redeploy like do something like it's catastrophically bad to have that so  the way that we thought about when doing this is basically having an append only Library a  validation libraries the bet that we were making as we were building is listen we want to get this  part right of what this protocol looks like the IP right the TCP structure like what does messaging  look like what does the protocol look like what we're not convicted on is whether or not it'll be  Ethernet or Broadband or Wi-Fi or all the things in the bottom half of uh of Ali's funnel there  right and so for us that's the validation library for us we said this you know whatever exists  right now in the state of validation library is very very unlikely to be de facto five to ten  years from now like almost certainly will not be

and there's unbelievable amounts of research  happening with zero knowledge proofs with like all of these advancements in the validation  technology and so what we did is you make validation libraries published we have about five  published right now you can always publish new ones but you can never modify old ones and you can  never make people uh force them to move off of an old one so what it gives is every application the  ability to opt in to existing sets of contracts security is static if you've chosen it to be  static but it allows the protocol to innovate and continue to push features so the you're starting  to see more and more systems start to walk a line like this where it's there is some form of proxy  there is some form of the ability to add a surface but it is entirely opt-in and it cannot affect  prior applications and I think that is like an

incredibly important incredibly important thing  to think about as you're building your protocols and as you think about doing this like you don't  necessarily want to build something that you know will 100 be the case so there's there's two sides  there's uniswap which is V1 V2 V3 we're going to launch an entirely new protocol every single  time we develop something new everybody will need to Migrate move to a new system and the old  system is dead and again for LPS that's like not really that hard to do it's not really that bad  of a system and it can function for a messaging protocol when you're thinking about what you're  building on top of you are like very anchored there because if you have the ability to easily  change messaging protocols you can simply point it to yourself and rug everybody right like it's it's  the application has that ability then the user is

basically absorbing the risk of the application  security parameters basically if the application can change from protocol a to protocol via the  messaging layer you just spin up some you know spin up something malicious of whatever multi-sig  it is to control point to your own messaging layer and say yep I definitely put a billion there give  me the you know full billion on this side and so you want the ability to add feature  sets but you don't want the ability to basically make that possible because the  user won't bear and again this is not like you should think about it in a way of like yes  this is a good like this is how you should build systems these are how should like but even from  the most greedy possible internal perspective like if you look at everything that has gotten massive  adoption in the space everything that's been built

on chain with that as soon as you have that risk  to the underlying user the relationship changes completely so again you look at uniswap you look  at Ave you look at ethereum you look at all of these all of these are built in these same exact  principles all of them are structured in the same exact Manner and I think like as you're evaluating  which cross chain protocol to use like this is the framework you should use for evaluation and I  think most as you look the big flags you will see is upgradable contracts the ability to upgrade  contracts means your security is is completely non-static and will be changing frequently in  the future if the pace of upgrades right now is sort of existing um permissionlessness if it is  a white listed set again there's there's always um so there were there were two things on The  Nomad side one the Watchers are whitelisted two

actually the person who pushes the updates  um for like actually posting the route was completely whitelisted as well so you have  like in in non-permissionless sets you have severe liveness issues um and then you have  also like security issues and then third is censorship resistance again if you're if you're  doing something that has any surface of of again governance is like a very good example but a bunch  of other cases if you can censor transactions if you can reorder transactions it will be done and  it is already being done um in the background but soon to be in the foreground again this is  something like people are are openly adopting uh in the way that some Modern Protocols are kind of  openly adopting Mev extraction at the tempo level being commoditized into uh into the protocol so  I'm happy to answer any questions anybody has in

the cross train uh bridging architecture how do  you mitigate the risk of the off chain components of bridging in addition to the immutable contracts  yep no I think I think it's a great question so um okay we actually changed our stance around  this a lot when we first launched our paper uh we basically said trustless messaging  protocol right uh our stance was that from the application Level you could achieve True  trustlessness by the following method basically um some transaction happens on Source you break  apart that state into into two pieces sort of block header and receipts route you move the state  across some parties it can be you know X number of parties move the state across it's reassembled  Merkel inclusion proof happens on the destination chain validated messages passed a contract if  you give the application the ability to opt

into running one of those components themselves  again completely open and permissionless system if you're an application if you're a uniswap and  you're doing cross-chain transactions if you run just one of those components yourself you now have  complete veto rights so no malicious transaction can ever go through unless you sign off on it  so you have 100 veto right even if every other validator in the network is completely malicious  you are safe and at the same time if you you are compromised if your off-chan infrastructure is  compromised you're backstopped by the rest of the network right so that was the way that we thought  about it and like okay this is this is how you an application building would want to structure  trustlessness what we didn't consider at the time is that the user does not inherit that same set  of trustlessness right this is trustless at the

application Level but the user using it now trust  the application so fast forward two and a half years of thinking about literally nothing but this  um I am 100 convicted um in the fact that there is there is no true trustlessness in any system in  any messaging protocol and this includes um you know another sidebar we can have it's talking  about like a lot of the Forefront right now is the research and like zero knowledge proofing  and messaging like how that actually affects and I think it's an extremely interesting topic and  how how that structure is and actually the the lack of trustlessness in it and sort of like how  misunderstood it is but um there are things that you can do to reduce the surface so one thing  that ZK stuff does that that's really good is it reduces the the surface of where the attack  can come from so you have a pure open NPC system

um you know basically you have some amount of  economic stake the value that's being transacted or exposed can never exceed that economic stake  right or the that then then you just symbol it and you basically uh collude to exploit the  network so like that is the overall Risk by zero knowledge stuff you reduce the set of Bad  actors to now they are the ethereum validators um and they're part of the sync committee so  now there's like a limited set and it's because ethereum is so brought into centralized it's  harder to get a set of those willing to collude counter arguments like flashbots is literally  large scale validator collusion in production at like 60 to 70 percent um so you reduce the  surface of that so you can do some things to make it limit who the Bad actors are but it  still doesn't change the underlying risk so

they will there will always be some form of risk  at the at the off chain level ultimately you're mutating some State on a destination chain  based on a belief state of source and the destination chain has no observability  into true canonical State on source so you know in a proof of work system it's easy  right you you there's a fork and you're Frozen at a point in time and you just grab a block it  doesn't matter which one the uncle or what ends up being canonical like at a certain point of  time they're both canonical and the destination chain will never know which one actually was right  so you can wait a certain amount of time and you can measure block height and you can do this but  you sell people are like reporting these things um when it comes to ethereum transactions and stay  proofs like great I can Fork the chain I can do

some mutate some state do some transactions on  that and then take that and report it over there right and so this was kind of the whole premise  of ZK stuff was okay now we'll make sure that the right people are signing the message or signing  the message um so there are ways again that you can limit surface but you'll never remove it  completely the best thing you can do is is choose a validator set that either you have participation  in your stakeholders have participation in so like one thing is again imagine uniswap  governance is going across chains right um uniswap governance already has some or I  guess Ave governance is a little bit of a better a little better because uniswap governance has  limited control of what they can do right they can add and remove people and flip on the sweet  fee switch Ave governance has the ability to uh

change risk parameters which means if they mess  it up you basically can blow up the protocol right um so it's like very important and the protocol  already trusts that group of validators a ton right so now take those same people and say okay  we're going to do something cross chain how do we do this without extending the surface of risk  at all right we have a surface of risk now the goal is don't compound that by introducing a new  surface of risk so if that same set of validators ran one of these off-chain components ran  a cohort of like okay we're going to run a little network of of this and the same people  with the same economic stake are validating that then that basically means you have the minimum  viable security of exactly what you already have and so that is like the best case suggestion I  would say to minimize it but uh there there is

no way to eliminate it completely yeah it makes  a ton of sense it seems somewhat analogous to the sequencer problem with kind of Roll-Ups and  like data availability and I wonder if you know that distinction between ZK and optimistic plays a  role here where you could use fraud proofs or some other mechanism yeah so uh okay now we can get  in there that's a conversation I I like to have um in a roll-up one of the really nice things  that you have what makes you roll up a roll up is that you have a canonical contract that lives  on ethereum right there is a a source of truth that lives on chain and if you want to validate a  fraud proof you validate against that everything that's on the L2 is rumors uh the the canonical  contract is the source of Truth and that is the

only source of Truth and so anybody can submit to  that that maintains the total State and if you're going to run a fraud proof you simply basically  run it on chain gef client and run it against that and you can validate State um now the ZK stuff the  goal was great we're going to basically take the people who sign this block and because they have  economic incentive to sign the block canonically on ethereum then we will move they'll move the  block over to the destination chain to roll up wherever this is going and we can trust that that  state is the same because otherwise they'll get slashed so it has as much security as ethereum  has right that's that's the theory of zero knowledge messaging the problem is what they can  do with zero economic penalty is you can create a canonical block on source that is honest and  valid you create the correct block on ethereum at

the same time the validator set in secret amongst  themselves creates a completely malicious block they create a snark of that block so the block is  thrown away nobody sees it you can't get slash you present the block to the destination chain the  destination chain has no idea which is the true canonical state so they just accept this malicious  block and now that attack is basically affected right and so in all messaging anything so again  canonical contract source of Truth lives there great everything happening on the L2 rumors  everything happening on other chains rumors there is somebody who needs to move that state and  the person who can move the state can manipulate the state you can reduce how many people can  manipulate that state you can make sure it is

the same people who are validating on ethereum  or on whatever chain but you cannot remove their ability to do it and that is only because the  destination chain cannot read directly from Source it doesn't know canonical state awesome  well thank you so much Brian that was fantastic [Music]