Design Approaches to Bridge-Agnostic Crosschain Messaging Solutions

Transcript

Hello and welcome everyone. I am Peter Robinson and this is the Ethereum Engineering Group meetup. Um today we've got Dr. David Highland Wood who is going to tell us a bit about crosschain. So David, can you please introduce yourself? Uh hi. Uh yeah, I'm I'm David. Uh I um have been around the blockchain space for about five years now. uh started at consensus with Peter and Joan and Frank all on the call. Um I have since uh left and I'm working in a university at the moment. Uh but I still consult very much in this space and try to keep current. Um, a couple of

the people that are probably going to join us today, uh, including Peter, uh, and I were on the, um, UNIS swap Foundation's um, crosschain bridge committee recently to evaluate a number of crosschain bridge solutions for Uniswap's use. And so, some of what I'm going to present today came out of of that work. Uh, their final report is going to be available later this week. Uh, so I can't talk too much publicly about it until uh that comes out, but it's it's coming soon.

So that's me. Yeah. So, thank you. Yeah, I can't wait for the report to come out, actually. Yeah, it's exciting. It's it's good report. It's good report. Lot of work gone into it. Um, yeah. All right. So, um, are you happy for people to ask questions at any time or should they wait till the end? I am absolutely happy to be interrupted. Um, I won't be able to see the chat if I'm presenting my slides. So, Peter, if you could just uh let me know when there are questions and um yeah, I'm happy to happy to take questions along the way and I'm happy to take questions at the end too.

Yeah. And so maybe pause at the end of each section as well and then just to we can check in on what's in the chat and um do that just in case I miss it. All right. So, please present your slides. Are you able to see those? Yep. Okay. So, I'm going to talk about design approaches to bridge agnostic crosschain messaging solutions, which is a bit of a mouthful. So, we probably need some context uh to understand that. So, basically, we've ended up with a lot of blockchains,

right? When you ask the web how many blockchains we have today, uh the answer is over a thousand and those thousand are going to include uh public private hybrid consortium chains everything from Bitcoin, Ethereum to hyperledger instances and Cardano and you know experiments banks and and everything else. So it's it's quite a complicated ecosystem and it's hard to map out uh today. And so when we have all these blockchains, we get to this fundamental problem of how do we transfer um coins, information, uh NFTTS, etc. in between chains and that means we need

some sort of bridge uh between the chains and these are typically called crosschain bridges. Um crosschain bridges are most often used to transfer cryptocurrencies or messages uh specifically um messages uh in the context of say governing solutions which is what what unis swap uh was after particularly. Um a generic bridge kind of looks like this. Uh this happens to be out of Axel's documentation. XLR is a crosschain bridge and you can see that a user uh here sends it buys ETH and uh the Ethereum

blockchain is the custodian for that ETH and there is some kind of authorizing agents uh agent in this case labeled multisig and it's watching uh that uh uh that request to transfer ETH to some destination chain uh when that request is made um that entity that that authorizing agent it might be a validator network it might be a private blockchain uh it might be an actual multisig with people it might be automated it might not be when that authorization occurs it issues a command on the destination chain to the debt issuer

uh which then is going to um give the user some kind of wrapped ETH on that new chain. And so basically, it's going to hold um cryptocurrency on one chain, it's going to wrap it and represent it on another chain. In terms of me, the messaging flow, if all you're doing is sending messages instead of buying cryptocurrencies or exchanging cryptocurrencies, it works pretty much the same way except you don't need that wrapping uh function.

you're just sending a message through the same pipeline. A generic bridge architecture uh generally looks something like this. They vary widely, which is why they're relatively hard to compare, but users interact with whatever chain they're on. Uh they're then talking to a series of contracts. Uh and these contracts will exist for uh each chain, each bridge, each infrastructure component, all the libraries etc. that implement uh typically a bridge at a layer 2 level and then those contracts will talk to some kind of authorizing

uh agent. uh typically that's a validator network on a private chain but it can be done uh purely at the L2 level as well. Uh if it's uh got an L1 backbone uh then uh they're typically relayers that then relay it off to the other chain uh and um and that uh logic flow from the previous slide ensues. So that's what a bridge is. Now, it's never that simple because now what we've ended up with is not only a lot of blockchains, but a lot of different blockchain bridges or cross-chain bridges. And what we find is that not all bridges deal with all chains.

And so, if you want to transfer currency or send messages between two chains, you're now having to figure out what the subset of bridges are that support those chains. and you're having to make a choice about which one you want to use. Uh so it gets it gets complicated and it gets complicated pretty quickly unfortunately. So crosschain bridges are really really big business. Uh there's uh they're worth a lot of money.

Um, and because they're big business and because billions of dollars flow back and forth between the various chains, they're a hacking target and they get hacked a lot. So, if we look at the biggest um monetary losses uh of the last year, what we find is that the vast majority of them were attacks against bridges. Uh, and so If you look at the numbers here, they're pretty scary. Um, uh, according to uh, reports from security firms, uh, Basoin and and Certic, hackers made off with more

than$2 billion dollars in 130 different exploits in the first eight months of 2022. Um, Bitmark, uh, they lost $196 million hack and it just a million dollars less than Oiler and it didn't even make the slide. Uh, nor did Nomad's $190 million hack or Beantock's $181 million hack. Uh, you get the idea. And so this is this is big money. Uh, some of that has been recoverable. Um, some chains, uh, Poly particularly wormhole done a pretty good job in recovering this. Um, and so it's not quite as dire as it looks. Uh, but

it's a long way from being good. Uh, you'll see that the one thing that's not on this slide there that's on this slide that's not a bridge is the um, uh, Sam Bankman Freed FTX failure. uh and so you know there are other ways to lose a lot of money in this space other than bridge hacks but bridge hacks have tended to dominate recently. So now we can parse out the title of the talk. So we're going to look at design messaging solutions. Why do we want to do that? Because crosschain bridges have been hacked a lot. uh they have certain classes of vulnerabilities that we're going to look

at. And so we're going to look at ways to design solutions that allow cross-chain messaging and crosschain uh cryptocurrency transactions that are bridge agnostic. That's the talk. Okay. So if we look at the most common forms of bridge hacks, what we get are uh is this list. Um a hacker can generate fake events. Often that's a fake deposit or depositing some um valueless uh token and trying to get something that's actually valuable back.

positive value of the token, you get like real ease back or something eth. And that was present wormhole hack, the the BSC hack, uh, broadly speaking, the oiler hack. Um, another one is message verification bugs where people are generating messages and those messages aren't being validated properly upon receipt. Uh, and this is what happened in in Poly. Another common problem is access control bugs.

And you know this was part of the polyhack as well and and with Ronin. And so this occurs when um uh people can access bits of your contracts that they really shouldn't. Uh and this is just a a security problem in the design of contracts and their dependencies, right? Uh when people are writing contracts, they often have a pretty good understanding of their contract code, but they don't necessarily have a good understanding of their library dependencies.

Uh um and this can lead to um bugs, right? Uh and and that can in some cases this will create message verification bugs, but more often access control bugs is the problem. Now, in Ronin's case, the way those access control bugs were exploited was actually because the hackers were able to take over um a quorum of validators. And this happened because uh the validators weren't as independently operated as uh one would hope. Uh a couple of companies operated a number of validators. Uh and so once

and they had a relationship between those those organizations and so once somebody's keys get hacked uh the hacker was able to take over a number of validators and then they were able to use that relationship with a partner company take over a bunch of their validators and then uh exploit an access control uh bug. Uh and then of course uh this all started at Ronin with a uh the leak of a private key that was then exploited to take control of the validators then uh took uh um uh control of access. Uh this private key leak also happened in in the Harmony hack. Um

all this stuff's available online. Uh all the hacks are pretty well documented. So um Cointelegraph chain analysis um some of the uh uh auditing companies have done a really nice job with deconstructing these various hacks and how they occurred and then what um happened after that. Uh I do have links to all of my sources uh but they're in the speaker notes of the slides. So, if anybody wants them, let me know and I can uh I can copy those into the chat or get them to you out of ban.

So, um now we've got uh 2023. That was last year, right? All this all these bridge hacks for last year. So, what do we see this year? And in the first quarter of this year, January, February, March, what we saw was about $119 million in stolen crypto. But interestingly, it it wasn't in bridge hacks anymore. And we'll talk about how the bridges responded to these hacks. They did close a lot of bugs uh in late 2022, but these early 2023 hacks have all been uh pretty much uh against uh NFTTS.

And that's interesting uh because it suggests that uh the bridges are getting a little better in protecting themselves and uh we're not really seeing the hackers focus on the bridges because they're not as easily exploitable as they as they used to be. Doesn't mean they're safe, just means they're better. So let's look now at bridge agnostic architectures. um what can we do to just avoid being reliant on any one bridge? So, I'm going to go through three of these in general.

Uh the first is a proposal. It's an ERC, um Ethereum request for comments, uh 5164, the 5,000th 164th comment, uh you know, on on the Ethereum ERC system. Um, and this one looks particularly at at crosschain execution. So, how can we uh create a bit of a standard for crosschain execution um that uh stabilizes how people go about this, right? And we can use that standard to have the whole community weigh in, address the approach, address the bugs, get it right, and then let

anybody who wants to uh create a bridge that's compliant with the standard. Uh ERC 5164 has been in the review stage since uh September uh last September 2022 and it has a reference implementation uh on GitHub which is github.compool together 5164. Um it's worth looking at. It's pretty good. Uh it's also a little on the basic side. you need to implement a fair bit um as a user in order to basically what you're doing is making your own bridge.

You may want to make your own bridge and you may feel that you can secure it and operate it and upgrade it and track it with the time in which case this is for you. uh if you're already operating a bridge, if you're a bridge company, um you know, a lot of companies are looking very seriously at implementing this and coming around this community standard, but it's not um it's not an Ethereum standard yet. Uh even if it becomes one, it won't be universally adopted. So, keep that in mind. But generally, the way it it works is this. You've got a sending chain and a receiving chain. um you have a contract uh that is going to

send a message and that message is either going to be um money or text. Um, and you're going to then uh u dispatch a message uh with that message signature that I've included there uh to some chain ID uh add its to address uh and then it's going to have a payload of a bunch of call data. Uh you'll notice that that method signature is payable. Uh and so uh you're not necessarily doing this for free.

Uh when the message dispatcher receives that message, uh it's going to dispatch it to a message executor on some receiving chain. When it does that action, uh it's going to emit a message dispatched event back to the sending contract. When the message executor then uh is going to authenticate the message dispatcher, it does that via um EIP 2771, which is the secure protocol for native metransactions.

Um and uh in this case um that uh um you met transaction is is basically a transaction that that may include other information, right? Uh it goes between chains and so that's um the message is authenticated. um messages get executed exactly once and in any order and that's guaranteed by the ERC 5164 protocol. So that means that if you wish to create a system for yourself and you

wish um messages to be able to be sent more than once. Maybe you're just dealing with text messages. You're not dealing with uh currency. uh say you've got governance messages and you want the multiple copies to go through. You'd have to send that message more than once yourself, you'd have to make that message different at the protocol level in order to get through more than once. Uh and if you want them ordered, you would have to include your own nons in the metadata and uh track that yourself in your own contracts.

ERC 5164 doesn't do that bit for you. Okay. Now there's also a dispatch message batch function which is a peer to dispatch message and it basically has the same um signature. The difference is instead of uh accepting uh a single um call data uh it it accepts a bunch of them except accepts a batch or an array of them. Uh and that's just a u that's just an optimization.

Um the reference implementation has uh a contract on GitHub called executorare.sol uh that you can inherit from to make the writing of the sending contract much uh easier. And so the reference implementation I think is pretty good. Um there's still a lot of community discussion around this. Generally speaking, this ERC has been pretty stable for about the last nine months. So, it's not yet accepted as an EIP, but it's getting there. Uh, it wouldn't surprise me if it um uh if it did eventually get to that status. We'll

talk a little bit more about who's implementing this a little later in the talk. Now the second approach I'm going to talk about is hashi. Uh for any Japanese speakers on the on the uh call uh that character says hashi in Japanese and uh and Chinese actually and uh hashi means bridge. Uh it can also mean chopsticks but mostly so the um uh hashi is a bridge aggregator uh it's created by uh nosist and they intended to create this thing

they call a block header oracle and so if you think about it bridges generally need to read the state of another chain And so they need some kind of oracle that's going to tell them what the block headers are for some other chain that they're watching or observing or sending messages to. And that's what they're trying to look at here. That's what Nosis is trying to look at here. And so Hachi was created specifically to implement this concept of u what they call a a rajo a redundant array of independent hash oracles. So instead of having one oracle that they

have to trust and that's a decentralized single point of failure, they instead have this group of oracles, this redundant array of independent oracles that are all watching the block headers on whatever um chains that they care about. The bridges then together um uh a in operating within the Hashi aggregator have to agree uh on the messages that are to pass between these bridges before the protocol can proceed. And so Hashi started with ERC 5164 uh but then they deviated from it due to

their own specific requirements. So where ERC 5164 tells you basically this is a standard way to get a message from bridge A to bridge B or sorry from chain A to chain B. Um Ashi generally uses that approach to get a message from chain A to chain B. uh but it does it it adds the functionality to aggregate a bunch of different bridges together that might be implemented quite differently uh from ERC 5164 with different implementations with um totally different architectures and then it aggregates those bridges and

coordinates their message traffic. Um so this is the basis for Hashi's uh statement that they don't require standardization of the bridges. Uh and that's why they're moving away from uh ERC 5164 because they don't think that standardizing that message protocol is necessarily the way to go. Now Hashi is not ready for implementation yet or production. Um, it's not particularly far along, but it's a really interesting idea, and I actually quite like their design. Some of the things they say about it in their documentation is they're really trying to provide two things. They're trying to provide what

they call additive security. So every new bridge in the aggregation uh can ideally um be implemented differently and then instead of just sort of creating a new bridge with a new set of trade-offs, a different set of trade-offs from some other bridge um the cooperation of those differently implemented bridges uh who have to agree with one another. This is really what a message says before the protocol proceeds can provide additive security. In other words, the aggregation of these different implementations agreeing um improves security in the aggregate. I think that's that's right. And then they've tried to create a standardized

approach at the lowest level of common bridge actions which is reading the block headers from various chains. Now the drawback of this approach is now instead of dealing with one bridge, you're dealing with a variety of bridges. And in order to do that, um, you're going to have some higher gas costs, right? Because now you're talking to a number of bridges and you might have potentially slower bridging times because you have to um pay all those gas costs, take all those actions across uh the various bridges and then check the results across them. So uh you get some benefits from the jumping up a level of

abstraction. uh there are some practical economic costs and timing costs in doing that. Now the third approach I'm going to talk about is MMA the multi- message aggregation um uh bridge agnostic solution and so this started about January it's been running for half a year uh GitHub link is is there um it's a non ERC5164 alternative uh attempting to gain traction with bridge operators like Hashi, it's still under active development. There's still a lot of discussion between the vendors. Uh

generally speaking, it's a bridge aggregator. Uh in com in competition to Hashi and it kind of looks like this. Um, the sender sends a message to this contract, multi- message sender contract on the left, and it's got a series of um endpoints that are going to talk to equivalent uh endpoints on on the destination chain. And in between those uh that group of endpoints, you're going to have a series of bridges. And these can be any of the bridges that already exist.

It could be um you know a poly or axelar or or wormhole or whoever. And the idea is you just use these existing bridges. Um uh you have a standardized way of sending messages to them. And then on the destination chain you have a standardized way of receiving messages and aggregating in them into this multimessage receiver on the on the right. And that's going to then uh result in your message being sent out. That multi- message receiver will only pass the message out to that contract on the right if the bridges agree um or if depending on the way that you've set

your message up. Uh if a quorum of them agrees, whatever quorum uh you decide to set. So that's that's MMA. Um MMA has at least two groups that are trying for MMA compliant implementations. There's Seller, their state guardian network, and Hyperlane uh and their implementation still in progress. The image here on the right is Hyperlane's uh general architecture. The thing to look at in their architecture uh is this mailbox contract. Um, the thing about Hyperlane that I would personally be a

little concerned about if I were a user of it is they have a uh a fairly small multi-IG. I can't remember if it's three of six or four of six that has control over those mailbox contracts. And so if they decided to uh uh implement a change to approve a change to the code of those contracts uh they would then uh have control over the the message flow and of course the currency flow uh at least until they got caught. So using something like hyperlane as a bridge uh or any of these others that have various problems, the bridges that have various

problems, using them singly can create these kind of security concerns. Using them in aggregate through something like MMA or Hashi is um attempting to abstract above the layer of the bridge. If the bridges don't agree in their various different implementations, it doesn't really matter if one gets hacked. It just stops message flow through the bridge agnostic solution. Of course, uh you might still have uh you might recognize that if you stop um uh message flow by hacking a given bridge or a certain number of bridges within your uh your multiple bridge

solution. you still have a livveness issue there, right? Uh you if you stop the flow, you stop people from being able to transfer money, uh conduct governance, do all these things that we do with crosschain technologies. So that leads us into our conclusion nicely where what is the state of uh you know these bridge agnostic solutions in the ecosystem? I would contend that they're pretty promising uh because they abstract us away from the kind of um economic uh hacky risks that we saw in 2022.

Uh and that's important because uh just hackers aren't targeting bridges in 2023 doesn't mean that they're uh in good shape yet. And it doesn't mean that as they upgrade and change uh new new problems won't be found or might be introduced uh so-called bad fix injection. So that's that's certainly possible. So abstracting away from any given bridge is still a good idea. Even if we have bridges that are good, we don't yet have enough bridges to really participate in a multi-bridge solution that's ready for fielding

today. Um, having just gone through this process with Uniswap, um, we didn't come up with three or four or five bridges that were just secure, happily passing our assessment framework um, really ready to be trusted to a high level that we could then aggregate via one of these uh, bridge agnostic solutions. I think that's going to happen, but it's not ready in June of 2023.

So, look for that to phase in over the next year or 18 months, uh, probably. Uh and once we get to that point where you've got three or five really solid bridges that are really ready for prime time that everybody likes their governance and their um and the the state of the code and their contracts and they've addressed all those common um areas for uh security vulnerabilities. Now you put those together into a bridge agnostic solution like MMA or Hashi. Maybe they implement ERC 5164, maybe they don't. Um, now you've got some way of guaranteeing high safety and high livveness um, uh, across,

you know, uh, between the various chains that you are concerned about. And that would be that would be great. That would be a much better world than we're currently living in. Now um the problem of course is when you try to create some kind of standard uh not everybody follows along. So whether this is ERC 5164 or Hashi or MMA those are just three solutions. Somebody might develop a new uh solution tomorrow and there are a couple out there that are a little less mature than those three.

And you know, you already see the uh community diverging a bit. So, Hyperlane and Cellar implementing MMA, but they're not guaranteed to work together. They haven't been tested together uh yet. Um Nosis um started with ERC 5164 and then deviated from it. And uh that's kind of interesting because you might see others do the same. Uh so some of the other people that are talking about implementing ERC 5164 now may not be compatible uh uh across the various groups. So that's where we are um at the

moment. uh immature yet promising is about about the best I can I can give you now. Um that's it for me. Peter, do you want to jump back on uh video here and uh I don't see any questions in the chat, but I'm happy to take questions now. Yeah, why don't you do questions now whilst we're in the flow? There's a few in the chat. Um All right. I'm not seeing them, but I believe you.

Yeah, I'll read them out to you. Um from let's see, I'll probably um just a sec. Does MMA need to translate a single message to many forms of messages based on different bridges in the multi- message sender? Um, no. So, the the purpose of these uh endpoints in the MMA architecture is to um wrap uh a a given MMA message in whatever format that the individual bridges need and then unwrap it on the other side. So

the sender and receiver deal with an MMA message and the contents of that can be application specific. It's just a call data right uh but these endpoints are bridge specific. So AM1 right matches whatever bridge infrastructure one is AMB2 matches bridge infrastructure 2 etc on down. And so those are the contracts that are going to be responsible for uh sending that message uh on through the given bridge and they're going to do that level of wrapping and unwrapping for Yeah. Which hopefully is very

lightweight because you wouldn't want to be paying for lots of gas on Ethereum or um in most cases it is. In a couple of cases it's less so, right? Uh, normally it's just a matter of adding or subtracting some metadata. Yeah. All right. The next question is from Ben here. Um, uh, are agnostic bridges mainly trusted, trustless, or hybrid, or both bridge designs? You know, that's an interesting question. Um, I I could get all philosophical with you and challenge you about what trustless really means.

And I'm kind of tempted to go down that road specifically because layer zero, for example, calls itself trustless. And when we went in and looked at layer zero in some depth, what we found is I would not call it a trustless architecture. the reason for that uh was because there were uh there were situations where a given party uh single party could break livveness in the protocol.

Right? So just as a refresher uh for those people who don't live in distributed computing world um safety is the guarantee that good things are going to happen livveness is is the guarantee that bad things won't happen so do I have that backward Peter or you're you're looking yeah I would have thought safety is good things happen bad things don't happen livveness is things keep on happening. Um, yeah, yeah, we can argue that offline, but um, yeah, fundamentally uh, yeah, when when when people if you look this up on

Wikipedia, if you look up if you Google safety and livveness properties, there's a Wikipedia page on it and, uh, generally speaking, bad things happening include the protocol stopping. Yeah. Yeah. A protocol stopping like a Yeah, it's that. Yeah, sorry. Let me let me pop the stack here a little bit. So, we were talking about um trustless versus versus trustful systems.

So, not every my caveat is not every protocol that calls itself trustless is actually trustless. Instead, I would say that protocols that call themselves trustless are all attempting to be trustless and some of them are better at it than others. So, you know, uh look, if you have some kind of um uh you know uh zero knowledge system, you may say, you know, look, our intent is to be trustless. You implement this zero knowledge system and and you don't have to trust anybody. That's the whole point of zero knowledge systems. But you might implement it badly or you might design your solution badly. You might introduce a protocol level bug or a

software bug in in the process of implementation and that can that can break that trustless assumption. So in in a in a bridge agnostic sense if you're if you're doing something like M&A and Hashi and you're aggregating a bunch of bridges some of them might be trustful some of them might be trustless they can mix and match you're abstracting above the layer of the bridge and so having different types of implementations uh in those bridge types is actually a benefit, right? Because if all of them give you the same answer or a quorum of them give you the same answer, then uh

you're getting the benefit of really being able to trust that different uh bridges have come up with the same solution even though they're radically different systems. That's a good thing. Yep. Yep. Yep. Yep. There are a few more questions here in there and I will go to those. I have a question for you, David. Sure. So, in my experience of um MetaMask swap um no MetaMask um bridging where you know allowing funds to be bridged across invariably people choose the cheapest option, the absolute cheapest in fact

independent of anything people choose the cheapest option because they all look commodity. If I use this multi-bridge architecture, surely the cost of bridging is going to be at least say if it's a three, two or three system like you've got on the screen here, surely it's got to be at least three times as expensive to do this bridge even though it's more secure. Will people do that tradeoff of cost for security? That that's an excellent question. um it depends on the user right so most of these systems um almost all of the systems that I've looked at whether

bridges or bridge agnostic solutions all of them pass on the gas costs to the end user they require the user to pay the gas costs and so I would suggest that if you're um transfer transferring money currency from one bridge to another, then obviously you're incentivized to have really low gas costs, but you're recognizing that you're you might lose your funds. So, you might do a whole series of small transactions versus one big multi-gazillion dollar transaction because if you do a multi-gazillion

dollar transaction and and that transaction gets lost, uh you're in trouble, right? uh and so there are absolutely economic decisions to get mi made and I would say generally speaking people will follow the the uh lowcost solution but the way we got into a lot of these bridge agnostic solution discussions wasn't for currency transfers it was for governance messages. Yeah. what you're trying to do is govern a big web three system, then you might be absolutely willing to pay for security because you're trying to govern

your infrastructure and it might be really critical to you not to introduce yet another way to cause trouble in your architecture. Yeah, that makes sense. That makes sense. So for plain messaging. yeah and even Yeah. Anyway, rather than me going down my loan of questioning, let's um do some other ones that are cued here. Um so I think Hashi's bridges are mainly trusted since oracles are used.

um posed as a question and I I guess I mean if they're oracles they are going to it's it's an M sort of like an M event isn't it? So um this Hashi started with trying to abstract away from having to trust a given oracle, right? So they're trying to get this um redundant array of oracles to agree on block header information. And so they're doing that because they recognized they had this single point of failure, this this trusted system, right? Uh that they were reliant on. And if somebody hacks the oracle, well, it's

outside of your control. You're going to trust the answer you get. Uh and that's uh that's really what they're trying to do here is to abstract away from a centralized um subcomponent. Does that answer the question? I think so. Yeah, I think so, too. Who whoever asked the question, please ask it again if I didn't answer it. What's next, Peter?

Yeah, the next one is so layer zero can not only cross EVM chains but also nonem chains with a single click. Any comments on that? So are there Yeah. Yes. Secure or not? Um yeah. So I didn't say that layer zero is insecure. So please don't don't take my statements as that simple. What I said was there are cases where there are even degenerate cases where the default configuration of layer zero uh can be insecure in that you have to trust um the given relayer operator if

you're using the default relayer which is uh a single entity uh and that relayer can break livveness uh but not safety Um depending on the oracle you choose, uh you might put the oracle in the position where they can break safety or livveness. And so obviously if you choose to use layer zero and you choose to use a decentralized relayer of size and complexity and a decentralized oracle of size and complexity, you can absolutely address these problems. And layer zero's team is actively working on um exactly that uh enabling this in

their default configuration and we we expect to see that in the next three or six months. So um it's not that layer zero isn't trustless or isn't secure or isn't a good bridge. It is uh it's just um there are issues in their default configuration for pedantic people like me that are worried about how such a thing might get hacked. Now um separately to that uh in terms of the uh the chain support um anything that's on the cosmos infrastructure is going to have wide applicability to a lot of chains both EVM and nonVM

uh and that's um that's a big ecosystem right uh and I am not so thoroughly familiar with that big complex ecosystem that I could guarantee there aren't some pairs of bridges where the individual implementation of the adapters aren't a bit fast and loose or the bridge itself uh can't be secure because the chain itself um you know can't allow uh totally great security on on that bridge.

the real solution to all this stuff is to recognize that all these chains are implemented different ways. Um they all have limitations and tradeoffs. uh they were all designed for some purpose and the more things you support the more you guarantee that not just ignorance of the complexity but the details of the individual implementations on top of the details of the individual trade-offs and architecture they're going to be holes somewhere. Um practically speaking whether they get exploited is a function of whether or not they get found. Um that doesn't mean that layer zero shouldn't provide all that

functionality. Uh they've got a perfectly great business uh doing perfectly great work. You just have to recognize that um that level of complexity comes with security tradeoffs a priority. It's just going to happen. Yeah. Yeah. All right. Let's um Yeah. Let's move on to the next one which I think I know the answer to this one. Well, I've got my perspective and so are bridges primarily relying on relayers for gasless transactions or implementing um the advantages of account abstraction. So um ERC um 4337 and gas delegated transactions.

yeah. So, when I put up this generic bridge architecture slide, uh, I put a relayer component in here, not because it's universal, but because it's common. So, not every bridge um, uses relayers. Um, not every bridge uses a defined subset of relayers. In some cases, uh, anybody can choose to relay besides the default set of relayers. In some cases, relayers just aren't a present component. So, it's it's really more complex than I'm making it out to be here. I was just trying to present the general idea on the way that most people implement it. So, your point is well

taken. You're entirely right. Um, uh, it just wasn't my point. Why don't we flip to the end slides? Okay, let's do that. Um, here we go. Over to you. Yeah, the merch store is still open. Um, yes, all good merch. U, anyone wants a t-shirt? It's just a clicks away. All right, next slide. If anyone wants to see Peter modeling one of these shirts, he can just uh stand up a bit.

Yeah. Yeah. Yeah. Stand back. And um yeah, it's what the the bite code one. Um yeah, I definitely should have the option for the bite code one is um if you can um if you understand what the bite code is um you know, please tell me and I'll give you a job. But maybe we need to wait for the next um bull market for that t-shirt. All right, next slide. Um okay so um in two weeks time we've got Frank Cassay who is going to talk about op open problems in rollups and talk about the issues um that uh the rollup ecosystem is facing and I don't know maybe um profer some ideas on h how

how things can be fixed. Um we've got Jane Wendell who's going to give a talk on ERC6551 and we've got um Philip talking about the um bridge aggregation and um there is likely to be an extra talk or two slotted in in the middle of all that as well which um are in the midst of being organized. Um but um yep if you go to the next slide. Yep. Um, if you're here today, we're on YouTube. If you're um watching this on YouTube, you can join the Meetup group and come along live and then you have the opportunity to ask tricky questions live, which um can be very helpful, I

think. Um, so um yeah, so that's the end of the slides. Um, and you might as well um click off the um unshare as it were. And um so are there any more questions for David? You know, golden opportunity um international renowned researcher. You've got him on the spot. Tricky questions away. There you go, David. I think we're we're all out of tricky questions for you. So, um So, that's that's probably because people know I'm gonna hedge if they catch me out.

you had some you have your hand up. Yes, I do. I I think I attended a very early discussion on crosschain bridge design and I'm just wondering across the bridge ecosystem is there any particular design that seems to be preferred that seems to have given us maybe more security conscious features across design because it it feels like it's the wild wild west at this point in time and there's so many different bridges out there and there's less standization the kind of design. That's my take on it. So, I'll just Yeah, it's it's an excellent. Is there any design you've noticed that's become

quite prominent? I I had hoped to be able first of all, I'm glad to see you ask a question since you're up at 3:30 in the morning to to uh listen to the talk from from the UK. look, the ecosystem is complicated and it's full of trade-offs. There are there are aspects of certain bridges that I really really like. Uh one of the people asking a question talked about um uh FA I guess was asking about uh or noting that layer zero can deal with nonem chains as well and that's that's an important uh piece of functionality. the the kind of things

that we ran across that we really really like. Um I would say that I'm a big fan of decentralized governance because it's harder to hack than centralized governance. So, the chains that had, you know, a a uh three of four or four of six kind of multi-IG and I don't know who those individuals are. And if I did know who those individuals are, I could just bribe them or threaten them or whatever to get them to do what I wanted. That that can be a scary thing from a governance perspective.

Decentralized governance fixes that problem. But on the other side of that um particular coin um we've got 10 years or so now more of of Dows and we've seen that decentralized governance can lead to certain kinds of sociological governance failure and generally with the Dows that have failed sometimes they'll get deadlocked because they just don't have enough people out in the ecosystem willing to participate.

uh and so they can't reach quorum and thus you know their their DAO will just stop. Uh and so now you've got this problem where decentralized governance has these advantages but also has disadvantages and centralized governance has some advantages but has some disadvantages and how do we deal with that? Um last year I was working with alongside finance for their AMKT token uh launch and in their governance model I was dealing with this sort of layered set of fallbacks from starting with the DAO and decentralized governance but if it gets deadlocked it falls back under certain circumstances down to these more centralized approaches in an attempt to

um mitigate against these problems. But the bridges generally choose a governance model and they haven't really solved this problem because it's not solved in the general community yet. Now the other thing I really like in the bridges like I I would say of the bridges that exist right now uh how people have organized their validator sets is really interesting. Some validator sets are big, some validator sets are small. Some validator sets are pretty independent. Some validator sets are not so independent.

I quite like validator sets that are big, that are independent, that have some kind of competition to get into the active validator set. Often that's via some sort of proofofstake model. And then if you do that, you can run into what's known as the validators dilemma where some what happens if somebody just buys a bunch of stake and they end up controlling uh a lot of validators um or or a validator and it has so much staking power that it can just outvote others. And so the implementation of quadratic voting on top of that kind of large validator set

that competes to stay in the active set gets slashed if it isn't live or doesn't do the right thing and then has a quadratic suppression of its voting power. Now you can balance it in such a way that you get this really dynamic active validator set where all the incentives are just working. I would say the one that's kind of best to breed right now is AxelR. I don't like all aspects of AxelR, but I love what they've done with their validator community. So, hope hopefully that answers your question.

All right. Well, thank you very much, David, for your talk. Um, thank you to everyone for coming along. Um, and have a great rest of your day. Bye-bye. Thanks everybody. Thank you. Bye-bye. Thank you. I