Blockchain / Crosschain / DeFi Bridge Design

Transcript

Okay, hello and welcome everyone. My name is Peter Robinson and today I'm going to talk about cross-chain and bridges. Um so it's me presenting, so I guess I can introduce myself. I'm a technical director and applied cryptographer at ConsenSys and um the area that I look at in particular is cross-chain and bridges. I'm also the co-chair of the um Enterprise Ethereum Alliance's cross-chain interoperability working group um and um yeah, so let's share my slides.

Okay, so um cross-chain bridges or DeFi bridges or chain bridges, take take your pick. So lots of people have reviewed these slides and uh provided helpful comments, so thank you to all of them. And this is a picture of a bridge. Um and um as you can see, um there's a lot that's happened to that bridge over time and it was complex when they built it and it's built on, you know, foundations, you know, that's not built on raw earth.

There's a lot of work has gone into what goes underneath. And um in fact that one's even got three arches, so or four arches, and so you could almost um view it as going across multiple areas, multiple um bits of land. And so people have had to carefully design that bridge um and so similarly blockchain bridges are like this where you've got they're complex, there's a lot of design that goes in and they are based on the underlying blockchains as well. Another interesting aspect of this bridge is you can see that there's that um darker bit, I don't know if you'll be able to see my mouse moving around, where

you can see that um bits have been tacked on to the bridge um partway through. And so obviously there was some maintenance needed, and I think that's an interesting one to think through that um that bridges are likely to need a bit of maintenance from time to time. So, today I've got a big um lot of topics to cover. And the first one is really trying to define what a bridge is. And then I'm going to talk about um the protocol stack and the parts of the protocol stack. And then have talk about a few of the considerations to think about such as

security, scalability, fees, um and I'll talk about standardization, and then we can have some questions to think through um at the end of the talk. So, what is a bridge? So, a bridge allows you to swap assets um from one um blockchain to another. So, you might have some assets on one chain that you want to swap with someone for some assets on a different chain, or maybe you want to be able to transfer the assets to the other chain. So, swapping and transferring are similar but different. So, transferring you're taking something from one blockchain and getting it to the other. The other one is saying that look, I'll I'll give you some assets on my chain on this chain for assets on the other chain.

Another thing that cross-chain and bridges can do is allow you to communicate arbitrary data or arbitrary messages. Or another feature is that you could have function calls that execute across the chain, so you can have business logic across the blockchains. And so as I said that a bridge is known by a range of different um terms, and they're all approximately the same thing. Um and I don't think there are good fixed definitions of any of them. So, when someone's saying a token bridge or a DeFi bridge, it's just a bridge.

So, why would you want to move value from one blockchain to another? So, say if you're using Ethereum mainnet, um, you'll know that the transaction fees are quite high because it's a lot popular blockchain. Lots of people want to use it and it offers great security, but those fees, um, mean that, you know, maybe you can't do as much as you could if you had a cheaper blockchain. So, maybe you want to move to a roll-up or some other side chain that has lower fees. Also, the confirmation time is another aspect. So, how long it takes before, um, some a transaction in a block is final is different depending on the blockchain.

Um, as well, there might be some functionality that is on one blockchain that's not on another blockchain. So, you might want to access that functionality. Another thing to think about is liquidity pools. So, you might have some liquidity, um, in So, there might be liquidity for a certain sort of token in one, say, roll-up, and there might be other liquidity in, say, Ethereum mainnet or on some other roll-up. And if there's more liquidity in one spot, often the opportunities, um, that avail themselves are greater.

So, there's also capital utility and efficiency. So, maybe you have, um, liquidity across multiple chains and you want to, in one single transaction, utilize all of your, you, um, all all of your money to do something. And so, you want to be able to simultaneously access the liquidity across the blockchains. And I've said all that via some notes just here. Um, so, if you want to read what I've just said, There it is.

So, value transfer. How does it actually work? Well, let's walk you through what you want to do. So, you've got, say, Ethereum, some ether on a minute, and you want to get it to some other blockchain. So, you want to send some ether, send four ether to that other blockchain. So, really, you're going to need to submit a transaction to Ethereum mainnet saying, "Hey, let's send four ether to that other blockchain." Um but the thing to think about is that ether doesn't exist on that other blockchain. It doesn't know about ether.

So, you can't just send ether to the other blockchain cuz it doesn't exist. So, you end up sending what's called wrapped ether. So, in other words, you've got four ether, but represented as an ERC-20 token. And so, you say to some contract on mainnet, "Hey, I want to send four wrapped ether to the other blockchain." It It can be represented as wrapped ether on that other blockchain. And um so the all overall process though is a lot more complicated, and let's walk through this process.

So, the first thing you're going to do is you're going to buy that four ether and say, "I want to convert the ether to wrapped ether." So, that's the first transaction. And then you need to do what's called approve. So, in an ERC-20 contract, you're the only one who can do a transfer, but there's also a function called transfer from, and so an account can do it can execute transfer from on to transfer someone else's money if it has been approved. So, Alice here approves of the bridge contract spending four of her wrapped ether. So, using in a to from.

And so, um so then she says, all right, so let's do this transfer. So, she submits a request to the bridge contract saying, can you transfer four wrapped ETH to my account on another blockchain? the reason why she says her account on the other blockchain rather than just leaving that as something to happen automatically that she might have a different account on the other blockchain, so she might not have the same private key and public key and address on both blockchains. She might also be using a wallet. So, if you're using a a wallet to a contract, then the probably in all probability the contract is not going to be at the same

address on both blockchains. And so, she needs to be able to specify the recipient address. And as well, she might want to send money from her account on this blockchain to someone else's account on the other blockchain. So, then the bridge contract as part of this overall transaction talks to the ERC-20 and does a transfer from from Alice's account to bridge account of four wrapped ETH. So, essentially now the four wrapped ETH belong to the bridge. And then some magic happens. We're going to talk about the magic later on.

And then finally the bridge contract on that other blockchain says, all right, let's transfer four wrapped ETH to Alice's account from the bridge account. So, that's one way of doing it where you're transferring, but another way is that you can mint. So, you can create some new value that doesn't exist at the moment. And so, the four wrapped ETH goes into Alice's account and it's created. And so, that's a minting burning um idea. So, in that in this situation, you can have view that um four ETH on mainnet are currently in escrow or they're locked up and owned by

the bridge contract. So, you hear people talk about locked up and owned locked up in the bridge contract, but really the tokens are still in that ERC-20 contract. It's just the ownership is the bridge contract. And so, yeah, so now we've got Alice has got her four wrapped ETH on the destination on the other chain and the bridge contract has four wrapped ETH on mainnet. So, that's the transfer has been affected.

So, there are a lot of other cross-chain use cases. It's not just transferring money. So, there's something called supply chain financing and in fact, Sandra Johnson, who's on this call, she's written a great paper on that. There's also provenance and selective transparency. So, you can imagine you've got a a blockchain that's all about supply chain and organizing deals and when stuff's arrived and all sorts of transformational processes, but then you might want to also selectively transparent key points so that people can use that for traceability to know that say some produce is really organic. As well, you can imagine that some countries might

decide to stop um blockchain at their borders and so they've got say inside a country blockchain and outside a country blockchain. Um the case in point um China for instance, they might decide they've got within China blockchain and the rest of the world blockchain. And so, you can imagine to do that cross-border um supply chain, you're going to need to have a cross-chain As well, CBDCs, um so that should be uh CBDC should I say. Um you can imagine that they're all on different blockchains. And so, if you want to have interbank transfers or inter-central bank transfers, then you need to be able to have inter-CBDCs.

and the um EEA cross-chain interoperability working group, back about 2 years ago now, um or actually, we finalized it a year ago. We were working on it for a year. We um created a whole stack of um interoperability use cases. And I encourage you to read that document to get a better idea of how cross-chain can be used. So, now I'm going to talk about terminology and topology. So, the blockchain that um the information is coming from is the source And the the blockchain that consumes it is invariably called the target or

destination blockchain. You can have a unidirectional bridge, where you can only transfer information from a source chain to a target chain. Or you can have a bidirectional bridge, where information can flow in both directions. So, some bridges are custom-built just for one pairing of a source chain and a target chain. Other bridges are more generic and can work with a variety of blockchains.

Some technologies rely on a hub blockchain. So, the source chain has to communicate via the hub chain to communicate with the target chains. And so, you have this hub blockchain that helps to um be an intermediary between all the chains. You can also have um transactions that go across multiple blockchains. And um they allow you to have more complex use cases. And in this situation, you would have a root blockchain and segment blockchains.

So, one thing that I've been working on and at the EEA, we've been discussing and moving towards is a cross-chain protocol stack. And um we we think this is important to allow interoperability. And so, the idea is that you have cross-chain applications. And so, they're applications that work across blockchains. And um you can imagine you're going to have your application code, but you might also have companies develop software components that are designed to work with the lower protocols and make it easier for application developers to develop great cross-chain applications.

You've got cross-chain function calls. And so, they this is the layer that lets you execute some um complex logic across blockchains. And so, you could, you know, have a function on a contract with some parameters and it gets called from another blockchain. And so, the updates associated with these function calls could be atomic, but they could also be not atomic as well. And there are trade-offs um to be had as far as atomic, non-atomic, and things in the middle, too.

So, the cross-chain messaging layer is about ensuring that information can be verified as having come from a certain And so, it's really the thing that the function call layer is built on. And so, you've got a the messaging layer, which um you know, provides that information has come from a certain place, function call layer that gives you um, arbitrary execution of um, functions across blockchains, and then the application layer which builds on those functions.

And so, having this protocol stack with clearly defined interfaces is really important because it's going to allow interoperability. So, you can imagine an application gets to choose which function call implementation it wants to use with which set of messaging implementations, and different companies can create their own um, you know, components. It also gives you flexibility. So, you know, you could have a technique could be used, you know, say for a roll up, and um, then maybe you'll have a different technique that you'll use for say from mainnet, and you'll be able to have as part of one cross-chain own call

different um, messaging methodologies, and you'll be able to mix and match depending on what makes sense. You'll also be able to reuse infrastructure. So, you can imagine that um, you know, you could have a company that offers um, relay nodes from a certain blockchain and has some infrastructure that they've stood up. So, you could use that infrastructure to execute your system over. Um, equally, you know, you could choose to stand up some infrastructure, and then have other people use your infrastructure, and you could charge people to use your infrastructure.

And so, it rather than you know, a lot of people at the moment, whenever they create a bridge, they create a whole protocol stack and they stand up their own infrastructure, um, you know, which is not a good use of resources. Also, having this plug-and-play um, you know, style, it allows people to work on what they're good at. So, maybe you're good at function call capability or messaging capability, or maybe you're just an applications company and you just want something to work. You can focus on what you're good at rather than creating the whole protocol stack.

And if you are a researcher, you can do experimentation. You don't have to develop the whole protocol stack from scratch. Um and so yeah, so you which is good. So, if you're a university researcher, you could take uh a pre-existing protocol stack that's implemented with these interfaces and create your own component. So, I'm going to talk a whole about a whole lot of stuff in the protocol stack, but let's have a bit of a think about um things first and think, well, these are really questions to think about whilst I'm going through the next

um 100 slides or so. So, who is being trusted in the system? And how many transactions are needed to facilitate the transfer? And who is submitting those um transactions? So, importantly, if I'm a user and I don't have any value on that destination chain, do I have the right or the ability to submit a transaction? And you know, how are these um infrastructure components compensated? You know, so why should someone offer an infrastructure component if they don't know that they're going to get paid?

And um do the infrastructure components need to interact with users? And if they do, you know, they've got to worry about DDoS attacks and things like that. And how many components need to be compromised or bribed for the system to fail? And what attacks are likely to be possible? And probably the big one is, if you had a billion dollars is you wanted to transfer from one blockchain to another blockchain, which of the techniques would you use? So, before I dive into the messaging layer, there's an important concept to understand in Ethereum called events.

And so, you can imagine you have, say, a function called transfer, um which takes some parameters, and then it can call, um it can emit an event. So, emit deposit with a set of parameters. And so, this event is defined programmatically, and then that event becomes part of a block. So, the event logs include information about which contract emitted an event, that is part of a transaction receipt, and that is included in a block. So, that means that you can confirm that a event was created by a certain, um on a certain blockchain due to a

certain transaction. And so, you can imagine Alice is there, she submits a transaction, and then an event is emitted, and the event can be proven to have come from that blockchain. So, you can prove that information came from a certain blockchain. Another important thing to understand is finality. So, you can imagine you have a blockchain, and the canonical chain is shown to the bottom, and you've got a fork on at the top. And so, forks happen in Ethereum mainnet all the time, and it's

due to, um latency across the network, and you know, you have, say, two miners mine the best block at the same time. So, if you've got some stale blocks, they don't the transactions in them don't necessarily end up in the canonical chain. So the transactions may be also in the canonical chain, but they don't have to be. And so if you're relying on an event that was emitted by a transaction that never ended up in the canonical chain, then you know, you're going to be in trouble.

And as well, the transaction when executed on the canonical chain might have ended up creating a different event because the event's got information that is programmable. So it's you know, based on these parameters and those parameters might have changed. So you know, you should when you're looking at these cross-chain messaging systems, you've got to be sure that the events that you're basing everything on belong to transactions that are in blocks that are probably final. so typically on Ethereum mainnet in one way between 6 and 12 block confirmations.

I've written a paper which you can access down the bottom there which talks through how you get the numbers and what they mean and you know, you can work out which end of that you want to be on. So other blockchains have got faster confirmation times and some of them offer instant finality. And so you know, if you've got one second blocks instant finality, then you're ready to go after one second. However, you do need to be watching out for centralization and security issues. So as the block time gets less and you know, as things become quicker, you know, there's there are trade-offs and so you've always got to be mindful of that.

So I'm going to talk about EVM-based blockchains, but you know, and that that covers a lot. So you know, you've got all of those purely EVM-based blockchains and sidechains. And um also got rollups. So, all the optimistic roll-ups are EVM compatible. All of the ZK roll-ups um seem to be moving towards EVM compatibility, too. Um but, you know, EVM is not the only um show in town. Um there are a lot of other uh blockchains out there. So, I'm going to assume that all of them can produce external messages in some way, shape, or form. And I think that is generally true. Bitcoin

obviously can't, but um I think pretty much all of the other platforms can. So, one of the big design choices that you've got to make in any in the in these systems is trust. And um You know, so people talk about trustless. Um and I think trustless is a bit of a misnomer because um you know, at the end of the day, you're always trusting someone. And it's just really a matter of knowing who you're trusting and how many people you're trusting.

And um you know, that that's really what it comes down to. So, on Ethereum mainnet, for instance, if 51% of the proof-of-work miners were became dishonest, which is not going to happen, but if it did, you know, then you'd be in trouble. So, it's a matter of knowing who you're trusting. And so um Trustless, the hope is that you don't have to trust anyone, but that's not quite true ever. Semi-trusted or almost trustless, it's you know, you've got to trust that at least one party is honest. And then you've got semi-trusted, where maybe you're aiming for a threshold number of honest players.

And trusted, well, you're relying on one single party, and you're hoping that they're honest. So, trustless. So, generally comes down to hash time lock contracts. And so, the idea is that you are going to release um, some value based on a pre-image being presented based on a hash. So, H equals the message digest of R where R is a random number, so R is the pre-image. And so, you, um, you know, so HTLCs aren't, by the way, current um, exactly messaging protocols, but they're pretty similar.

And so, um, so when you're looking at a HTLC, the first thing you need to do is set up the deals between and how much is being transacted. And that may happen off-chain, could happen on-chain. And in the next step is that Alice comes along and she puts in some, um, value. Say, um, 10 and she says, "All right, 10 beta, um, coins on blockchain B giving I get, um, one alpha on blockchain A." And so, she puts in her 10 beta. And she sets up a timeout.

And then, Bob then deposits his tokens on blockchain A. And then, Alice submits R such that H equals, um, message digest of R. So, in other words, assuming that equation works, then she can withdraw her tokens And then, Bob then comes in and sees that R value and submits it on blockchain B. And then, he can withdraw his tokens. And so, that sounds great. No one had to trust anyone, but, um, and it it is atomic.

Usually, so it's limited to value transfers. There's also griefing attacks possible. So, griefing attacks is are the always also known as sore loser attacks. And so, Bob could just choose to not do step three. So, Bob could not put his coins in and Alice has to wait around for until the timeout. And um also, Alice could um wait for um wait for Bob to submit um you know, to submit the R and then um you know, Uh yes, you can get the slides. And so, um and the coin the coins will be locked up forevermore. So, it requires the

parties to be observing the blockchain, which is a bit of an issue. And as well, the time you have to be careful with the timeouts. You want to have more timeout on blockchain A than blockchain B, otherwise Alice will have to wait um until you know, could wait just before the timeout and then do her withdrawal, not giving Bob enough time. And um also, if Alice can make Bob um go offline by maybe turning the electricity off where he lives or um um maybe making the blockchain that um Bob's trying to submit his R value to busy, then again, he could um end up not being able to execute before the timeout and losing his money.

So, that's the basic HTLC mechanism. But, what about as a bridge? And so, um you need to have two transactions on both blockchains, which is um you know, that's a some block some transactions. And Alice needs to be able to submit transactions on the source blockchain and Bob needs to be able to tran- submit transactions on the destination blockchain. But, how do they do that if they don't have any value on those chains? Um another issue that some is sometimes cited is using HTLCs with consortium chains such as IBFT.

And the thought is that blockchain validators could be bribed or would refuse to submit transactions until the timeout. And so you can imagine that, you know, you could have um you know, dishonest validators doing that. But if you've got just one honest validator in an IBFT network, they will be able to submit the transaction for you. And um so if but if all of the validators on that destination blockchain or source blockchain get bribed, then you're in really big trouble anyway because your whole security of your blockchain is blown.

So um yeah, there's also talk of using deposits to stop the griefing attacks. The issue of course with them is that they introduce more latency and you're doing more transactions. So Connext have come up with a modified HTLC um based bridge. And their idea is that they don't want Bob to have to have gas on the destination chain. And their their modification though is that um for that step where Bob would have put in R to get the value, a relayer does it on his behalf. And in fact, you're interacting with a relayer for the whole um for the whole situation. So rather

than it being Alice and Bob, it's relayer and Bob. So in that case though, Bob has to trust this relayer, this router. And if the router cheats, then um he's suddenly got to get value onto the chain so he can get his money. So you know, if the whole reason for Bob doing the transfer was to get value on the um target chain, then um you know, he's in trouble. So um uh yeah, this is a um a bit of a centralization and fully trusting part of their trustless um scenario. So yeah.

So there's also semi-trusted or almost trustless mechanisms, too. but one of them is essentially BTC Relay. So, essentially you're now from if you've read the Bitcoin white paper, there was this concept of a simple payment verification. And essentially you run a light client of the consensus protocol on the And so, you use, um, the proof of work hashing power for instance of the source blockchain to be sure that the information can be trusted.

And so, the first step of course is to deploy to the destination blockchain a contract that's got, say, the genesis block or some other starting block that, um, can be used to confirm new blocks. And so, um, how it works is that you have Alice, who's a relayer, and hopefully there are lots of relayers, and they grab, um, block headers off the blockchain A, so the source blockchain, and they put them on the destination blockchain. And those block headers are only trusted or accepted if the, um, the rules for the, um, consensus protocol, so proof of work, um, are correct. So, the

difficulty is okay, and it's building off the last block header. And so, um, yeah, so I've just said And so, then Bob then executes a transaction on the source chain, which, um, causes, um, that block that transaction to be included in a block. So, for Bitcoin there aren't any events, and so BTC Relay is all about Bitcoin and Ethereum. So, um, yeah, but so his transaction gets included in a Merkel tree of transactions.

And then, um, the block header, um, that contained his transaction gets transferred across. And then once enough other block headers have been built on top of that block header and you have say six block confirmations, then you're ready to go to use that transaction. And then um Bob then can submit his transaction on the destination chain with the the transaction from the source chain and a Merkle proof showing that it was included in the block and then doing something with that.

And so the compensation model that we've got here is that users pay for confirmed transactions and then the relayers that have um block headers that are used get compensated. And so the advantages of all this is that you only need one honest relayer. So you can have as many dishonest relayers as you like submitting false block headers that are on forks of the canonical chain, but you just need one real um honest um relayer who submits the canonical chain and it's going to have better proof of work, so better better weight, better um uh length.

And so hence that will be the trusted chain. There is a disadvantage or actually multiple and one of the big ones is that if there are no transactions on that um BTC relay, then the relayers aren't being compensated and so they'll stop working. And so if there are no confirmed transaction block headers, then you can't confirm transactions. so you know, the and now that this sort of approach has been tried on other blockchains that don't have as good proof of work um capability and the problem is that then um the whole system can be hacked because someone can um come up with a um block than the real blockchain by um you know, just doing

better proof of work. And another issue is that the proof of work algorithm has to be able to be implemented on the target blockchain. But there are some attacks as well. So, um Lisse Ethal came up with this great attack. So, imagine Eve has $1,000 on Ethereum mainnet. And so, Eve sets up the contract so that it she says, "If someone gives me $1,000 worth of Bitcoin on Bitcoin, then I'll give them $1,000 on Ethereum."

And then Eve convinces Alice and Bob to transfer $1,000 of Bitcoin to her on Bitcoin based on the ETH that's on mainnet. So, only um Alice or Bob though will be able to confirm their transaction. Um because, you know, one of them will get $1,000 worth of ETH and the other, by the time they submit, it'll be too late. There won't be any ETH there. And so, Alice gets $2,000 of BTC. or rather, Eve gets $2,000 of BTC and Alice gets $1,000 Bob gets nothing. They also identified another attack, a liveness one. And so, you could imagine that Eve convinces Alice to have $1,000 of ETH on mainnet. And um then Eve walks away and never transfers any money. So,

Alice now has got her money locked up forever, which is not good. Um as well, Martin Swende, who's um was the chief security person at Ethereum Foundation, if identified a software defect as well, which meant that you could um you could get around having to pay to um have blocks or transactions confirmed. So, there were software bugs as well. So, that was BTC relay. Has anyone tried a similar thing with Ethereum mainnet?

And the answer is yes. So, there's Rainbow's uh the Rainbow Bridge by NEAR Protocol. And so, it's a way of going from to NEAR's um blockchain. And so, they've done this massive feat of getting the Ethereum proof-of-work algorithm to work on NEAR. And um you know, it's it's a huge feat because it's a time-and-memory hard protocol. And so, it's much more complicated than Bitcoin's protocol. And um so, it works. Um but but but but Ethereum mainnet is going to be um becoming of stake in Q1 next year, probably. And so, once the merge happens, this bridge is not going

to work because there'll be no proof-of-work anymore. So, um now I'm going to talk about these semi-trusted or trusted mechanisms. And invariably, you've got a threshold number of relayers or some validators or attesters. And they sign or maybe they do multi-party compu- -tation on the on the source chain. So, threshold signing, essentially. But sometimes it's not thresh- signing, it's computation.

And if you've got a trusted system, maybe you've only got one relayer. And so, the public keys of the system are registered on the target blockchain, which invariably means for Ethereum, the address is stored on the blockchain. I'm going to walk through a whole stack of approaches. Um but you know, the choices really come down to who is signing? Is it just Do you sign individual messages or maybe a Merkle root where they you've got a whole Merkle tree of messages?

Um you know, do you create that Merkle tree yourself or are you relying on block headers and transactions? So, have the blockchain create that Merkle tree? Um do the attesters cooperatively sign or do they separately sign? And do they um and relays and testers respond to requests from users and maybe have to deal with DOS attacks? And so who does put that transaction on the destination blockchain? So the first approach is a bit like iron framework.

So you have a source blockchain and you have Alice submitting a transaction and it emits an event. So business logic contract calls the bridge contract and the bridge contract emits an event. you can imagine that you have relayers and they see the event they see blocks being produced and once the blocks are final, they each individually submit the block header on the destination And then Alice then can submit her event with a Merkle proof which says this event was part of that block and hence you should trust it. And

then some based on the function call that submitted a business logic contract gets called. And so for the the simplest approach, you're submitting all of the block headers. And so this is simple. And you know, the relayers don't have to talk to each other. And the users aren't interacting with the relayers which is good. But you're submitting one transaction for each relayer for each block, which is a lot of transactions. And you know, if there are multiple target blockchains and in these these transactions are going in all sorts of directions. You've got transactions for each block. So it's a lot of stuff happening.

And you know, the relayers have to pay to submit those transactions. It's going to cost money. Um and um you know, the user also they have to be able to submit a transaction on the destination, which is not good. So, you can a subtle modification of the system is the relay is watching the events and watching the the um the block headers and only submitting the block headers that are needed onto the destination. And in this case, you know, the you're only doing one transaction per relay or per block um that is needed. But of course, the big thing is that now you've got to work out which transactions are

going to which blockchain and hence which block headers need to be transferred. So, suddenly your relays have to get more complicated. They need to be able to understand which block headers to transfer. And um another slight change would be that the relays cooperate and then just one of them transfers the needed block header. And so, this is good because now you're going down from um you know, one transaction per block per relayer to just one transaction per block header that's needed. But the relays do need to talk to each other and you know, that

cooperation, that protocol, that um of all that communication is non-trivial. Another mechanism that doesn't use these relays is having an attester. And so, again Alice submits a transaction, bridge emits an event. And then the user says to a set of attesters, "Hey, can did you see that event? Can you give me Can you sign that event and say it came from this source blockchain and it should be trusted?"

And then she gets a threshold number of those side events, and then she submits them to the bridge contract and again executes her code. So, the attesters don't have to submit any transactions on the destination blockchain, which is fantastic. Um um but the attesters um have to are only signing for a certain contract, so they don't need to understand the target blockchain, either. And they don't need to cooperate. Um but the users have to interact with all of those attesters, which is um pretty big.

The attesters could cooperate, and then the user just has to interact with one of the attesters. Um but now um the attesters are going to have to cooperate, and that's, you know, pretty big. Um and the user is still interacting with the attester, which is not good. Another way you could do it is the relayers, rather than relaying block headers, they could relay the event themselves. And so, they could look at the event, and then they could all separately relay the event. And this is how ChainSafe's chain bridge works.

And so, the relayers aren't cooperating, which is great. Um and the user isn't interacting with the relayers, which is great as well. And the users don't need to submit a transaction on the destination, which is fantastic. You know, they don't need any value. However, the relayers are submitting one transaction per event. And they're submitting transactions on the destination blockchain. So, suddenly you've got to worry about how much is it costing for the relayers to submit transactions on the destination. yeah, the um relayers do need to have some understanding of the target blockchain um of you know, for that event. So, um yeah, it it it adds some levels of complexity as well.

So, the relays could um cooperate with each other and then submit a meta signed event, which would be another approach, um which means that now we're only got one transaction per event from the relays, but the relays need to cooperate. Another approach is um the one that um the Solana bridge has done. So, the Solana to Ethereum uh their bridge is called Wormhole.

And so, with their approach, you have a you know, you do that um set of um you know, emit the event on the source. You have a set of attestors and um what you do is you observe um the event and then what you do is you submit that event as a signed event on a special cross-chain event crunch contract. And then, anyone can fetch that signed event. And then, they can then submit that event on a destination blockchain.

And so, the good thing about this approach is that the relays aren't submitting any transactions on the And so, you know, they don't need to um you know, be doing any any interaction, which is really good. Um but they do need to cooperate and the user is submitting that transaction on Um another interesting approach is the Celer Optics uh bridge. And so, with their one, I mean, it's far more complicated than I'm going to talk about, but I'm going to give you some um a feel for it, though. So, the user submits a transaction that emits an event. And then, you have these

attestors put the event um the message into a queue of messages and create an incremental Merkle tree. And so, I think you can think of, um, how Ethereum 2's beacon chain has an incremental Merkle tree model. They're I think they're using the same thing. And so, um, what's happening is they um, submit back to the source chain the root of that incremental Merkle tree. And so, what for each message coming out, they're giving a new root. And so, you can look at, say, root two. So, in root one, you've got message one and message two could be confirmed based on root one. But then, when you added

message three, you've got root two. And the good thing about root two is though, you can still confirm message one and two as well as message three. So, you know, in block header transfer, each block header is different and so, you're not summing up all of your messages into one tree. Whereas in this approach, you are. So, it it has that that's a really good feature. And so, they the attestors, um, submit an audit list of, um, Merkle roots back to a contract. Then, you have relayers, um, and they grab those Merkle roots. And so, they might grab, say, one a second, one a

minute, one an hour, one every hundredth, um, Merkle root. You know, pick It's really up to the relayers to how often they, do this transfer. And the relayer submits the signed Merkle root to a bridge contract. And so, then after a wait period, the, um, the bridge con- users can then use that, um, Merkle root to submit their message, which then calls a business logic contract. So, um, yeah, using that use of the Merkle trees is interesting one.

So, the In-Celestia optic you only need to have one relay transferring the Merkle root. So, this saves gas. But, you do need to wait for this fraud window to expire. And then, the idea is you're going to have some observers who are going to submit malicious Merkle roots back to the source chain so that you know you know about that you know that so you can slash attest so the updaters. Another sort of deficiency or issue with the protocol overall is that it's up to the application to block malicious messages.

So, if you're on that destination chain as an application, you need to understand whether a message is malicious and then block its usage. And so, this is sort of the application layer sort of knowing stuff about the messaging layer which seems to be a bit of a mix-up of protocol layers to me. And so, yeah. So, the relays aren't submitting any any transactions on the destination chain. Well, they sort of are. The attestors aren't, but the relays are.

they you know so the relays again they're not having to worry about the actual target blockchain. Well, the attestors don't, but the relays do. And the users aren't interacting with the attestors or the relays, which is good. But, you know the attestors are cooperating. The relays don't need to. So, I think my my words here need to be reworked. Sorry about that. Next edition. So, I've talked about a whole stack of different schemes for transferring events.

And one thing I've skirted around is actually the signing process. So, you know you obviously you've got ECDSA, but you've also got BLS, and BLS comes in multiple forms. So, you can have aggregated BLS and have um threshold BLS based on that. So, where you add all your BLS signatures and you keep track of which one signed, and then you use that to work out um the which public key to use. Or you can have threshold signatures where you have one public key and you use essentially multi-party computation to work together to cooperate to create a um signature.

Um you can also use Schnorr aggregated signatures. That's what One Chain is using. So, I've talked just point-to-point, but as well, you know, as I said, we can you can have hub blockchains as well. Um so, the reason why people like hub blockchains is rather than having to have potentially, you know, n to order n number of um bridges, you might only have, you know, like um an order one number of bridges. So, in in order of, you know, like the number of blockchains is the number of bridges rather than it being a multiple.

So, you know, they reduce the number of bridges you've got to have, which is good, but um do all the blockchains and roll-ups need to be interconnected? Good, you know, something to think through. And these hub blockchains is what going to you know, they're not charities. They're not going to do stuff for free. Um and as well, the latency is going to increase going across these hubs. So, you know, you're going to increase the latency of your transaction. Poly Network um has a hub blockchain as well. And in their approach, they have a Merkle tree of Merkle trees. And so, So idea there is that, you know, you've got your Merkle root from one blockchain and

a Merkle root from another blockchain and then you aggregate those Merkle roots up and you then advertise the Merkle root, the you know, of the whole network to all the blockchains. So there's also staking and slashing. And so the attesters or relayers, they can be required to front up some money. So I've heard um amounts such as $50,000 and $100,000 mentioned. And so, you know, you stake that money and then if you're proven or you're a threshold number of you're proven to do the wrong thing, you get slashed.

So, you know, something to think about is how much money is being staked. So, you know, if you're transferring $500,000 and there are 25 um relayers and it's 17 of 25 and they're each staking $100,000, then it's $1.7 million is being staked. So, 500k is probably okay. But, you know, if they're only staking 20 bucks, then it's a bit of a problem. and so, you know, you need to also understand when people say we've got this staking slashing solution, you always should ask, "How am I going to go about slashing?" You know, it's great to say I could slash, but you know, how do I really go about slashing? Who can do the slashing and

how is it really done? And who can be slashed? So, you know, you might find that there are only very few parties in the overall solution that can be slashed and only in very certain situations. And so the slashing staking solution might not be as good as it sounds. Um yeah, and how is how is misbehavior proven? And invariably, this is going to have to come down to some sort of cryptographic enforcement. It can't be he said, she said. It's got to be, "Look, you know, they signed this, but this is obviously malicious and I can prove that they signed something that's wrong.

transactions. So, what happens in the system if a transaction fails? You know? Does the Does the relayer retry the transaction? Does it reprice the transaction? You know? Same nonce, higher tip or higher gas price. You know, what happens? How does this work? And uh you know, this is something that's quite key and you could imagine that you know, this does happen that you know, maybe the permissioning might fail. Or something like that. So, what about at the function call layer?

So, you can imagine that you have a um single blockchain call where you have um say this swap function calling trans. So, you've got con D trans down the bottom there. And so, you've noticed you've flipped your from and to because you're um on one on one contract, you're um transferring from to two and on the other one, you're getting two to from. And um Appay, it'll be on YouTube. Um yeah.

And so, if you're in the cross cross call um situation in the multi-blockchain, you need some magic um function, some cross call function to do this transfer for you where you're specifying the destination blockchain and contract, the um function to call, and the parameters. And so, you could have a simple function call protocol and um so, you call a contract on a blockchain based on an event. And in fact, I've implemented an example version of this.

And so in this not atomic version of the system, you know, you you have a business logic contract submits a transaction, goes to the function call layer, and then using one of those messaging protocols, you go across to the function call layer on the other blockchain, and then that bridge contract executes the function for you. And so, you know, nice and simple. However, it's not atomic. So, these updates across blockchains are not atomic, and so the transaction on that destination chain could fail.

And the reasons why it could fail is maybe there's an a revert that happens, you know? So, maybe the on the destination chain, there's not enough funds or there's some other situation that you get a revert. Um, you might not have enough ether to pay for gas, um, say for the relay. Um, you might not have permissioning, so maybe it's um, there's solidity level permissioning that's blocking the call, but maybe also um, there are some other level of permissioning. So, maybe it's a private network, and you no longer have permissioning to submit a transaction.

Um, and maybe you submitted a transaction at a certain gas price, but now suddenly there's an NFT sale, and the gas prices have gone up by a factor of 10. Or maybe just something there's a configuration issue when the nonce is incorrect, you know? So, it does happen all the time that transactions fail, including on bridges. And so, you've got to realize that if you've got a non-atomic protocol, you've got to deal with them. You've got another protocol that I've um worked on is GPAC. And so, it's general purpose atomic cross-chain transaction protocol.

And so, it's all about atomic updates across blockchains. And so, either all of the updates are committed or they're all discarded. So, you can think of it as a two-phase commit scheme for call execution trees. And it allows you to have a composable synchronous execution model that is what application developers are accustomed to. So, in Solidity on Ethereum mainnet, it's composable, so you can have components that you can bring together to create an overall application. When you execute something, it executes immediately. So, uh and when you have a return result, it's there when you you know uh and when the function returns.

And so, it's synchronous as well as composable. And so, this protocol gives you that as well. And so, there's an open-source repo with the um implementation of this protocol. And so, this protocol allows you to do complex things like this where you have a root transaction, say a trade wallet, that talks to a blockchain which has say some business terms in it saying that a shipment has occurred. Let's pay on the finance blockchain, and let's have the logistics transfer ownership on the logistics blockchain.

Excuse me. And so, you can do that cross um system cross blockchain um call using this protocol. And so, the idea is that you have the entry point function calls on each of the blockchains. you have the parameter values that you're going to pass in. And you commit to those values. And then, you advertise that commitment by having a start transaction.

And then, you have the segment transactions which make make up the leaves of the call execution tree, and you work from the leaves up to the root of the execution tree. And then when you finally execute the root of the execution tree, then you're saying commit or discard. And so you're saying should all the updates across the blockchains be committed or discarded? And then you commit or discard them using a signaling transaction. And so the technology uses lockable storage. And so the business logic contracts, they have to all values that are going to change part of a cross-chain call in

lockable storage. And so you have a cross-chain control contract that controls the overall execution on that blockchain. And it works with a verifier to verify those cross-chain messaging um information from other blockchains. And you call that to lockable storage, and then you call back in to do a cross-chain call. And so there's a technical paper which explains this in great detail. And there's also some videos um on the YouTube channel for the Ethereum Engineering Group meetup.

So yeah, please watch them to understand the protocol in more detail. So the thing to think about when you're using um this protocol, and I dare say most of the atomic ones, is that you cannot have unpredictable values that are going to be part of a parameter. And so you can't say have block hash of the current block or the block um the timestamp. Um and so the storage locations that are going to affect the parameter values need to be accessible because you're going to need to be able to work out what they are so you can commit to them.

Um the applications need to be designed with locking in mind. So you can't um just execute um and not do any locking. But as well, if you've got something a resource that many people are going to execute, you need to design for parallel execution with locking. And it can be done. So, the root blockchain needs to be accessible as well, because it's the thing that you're going to be saying, should I commit or discard? And so, you need to be able to access that blockchain as an application.

Um, the gas costs um, more than their non-atomic protocol. So, it's around three times is my current, um, thinking. So, um, the gas prices or the gas usage is being optimized. So, anything in blockchain is subject to front running attacks, but let's face it, if you're advertising in a cross-chain protocol, this is what I'm planning to do, then, you know, you're even got more front running attacks possible. So, you need to design with front running attacks in mind. And um, I again in my, um, talk on GPack, I talk about how to get around front running attacks.

So, comparing GPack atomic with a non-atomic, say simple function call protocol, atomic across chains, um, and if any of the parts of the transaction fail, you're all good. Whereas, in the non-atomic, you've really got to worry about failures. It's higher gas cost. So, compared if you had all your, um, say ERC-20 transfers on one, um, blockchain, then compared to that, it's about 10 times as expensive. Um, if it's a non-atomic, it's about three or four times as expensive. So, you know, that that's the overall approximation.

Um, so, the non-atomic will work on any contract, whereas GPack, you've got to have locking in mind. Um, but non-atomic, you you don't have a standard execution model and um you know you can't return values and um you know you've got to be um worried about each segment executing separately, whereas with um G pack it's all together. It's just like you're executing on a normal blockchain, but you've got your logic spread across blockchains. Um yeah, and so um I encourage you to compare, you know, if you're ever got an application implemented as a single blockchain solution and then implement it as say a

G pack in a non-atomic to try and understand what the um you know trade-offs are and how you know what the actual higher gas costs may be cuz it's going to be application specific. So um so one thing to um and you know so when we're looking at design considerations for the blockchain layer, um you know the thing you've got to think about is that um that you know you've got to be trusting that event emitter and so you need to know so that function call layer bridge on the destination, it needs to only trust events emitted by the function call layer bridge

on the source blockchain. And so you can't just trust any any um contract. You've got to just trust that you know so for the relayers um you know you you need to be of when you've got these messages going along, you need to worry about replay. And you know you wouldn't want an old message that said transfer 10 tokens to someone to be replayed again and again. So you have to have a way of having some sort of unique ID or something to prevent replay um attacks.

Um and as well you might want to just have a timeout or age events. So, say look, after 1 hour, any event from that from any blockchain is deemed invalid. And that's just to stop people storing up old events that somehow or other they've got to obtained, or maybe they've found some compromised private key or something and then they created malicious event. So, I think you've got to look at having timeouts. So, the timeouts can also work in with those unique IDs that I talked about just before, so that then you don't need to store all of your new unique IDs for all time, and you can delete old ones.

Another thing to think about when you're designing these systems is at application level access control. So, you know, in on normal, you know, Solidity on one blockchain, you have message sender equals owner or authorized. And then, you know, throw a require if you are not authorized. in cross-chain situation, it's going to have to look something like this. So, does, you know, is that source blockchain in the list of or in the map of authorized blockchains? And is the source address authorized as well?

was the actual the person, you know, the entity that sent me this or did this function call, was it the actual function called bridge contract or something else? Um, so, you know, so it's worthwhile you've got to do this application authentication to make sure you're being called by a valid party because you know, that business logic contract there needs to know it's the bridge calling it and not some other yeah, so the the function call layer has to provide the blockchain source, blockchain ID, and source contract address for applications. And so, that's something that you've got to design into

your function call protocol on and should be there. And for these multi-blockchain protocols like GPack, you need to know about the root blockchain as well and have its identifier as part of the overall call. So, you can have a bridge that allows you to do arbitrary execution where you can execute anything, or you can decide to restrict which functions can be called. So, you could um have a allow list of you can call these contracts and these functions. And obviously, arbitrary execution is going to be simpler, but it could give you some more security risks. So, um you

know, you've got to think about the flexibility and simplicity versus security. Um and what does your solution need? It's also a good idea to be able to pause the bridge. And so, you know, all the you need to be able to essentially pull the plug temporarily and say, "Hey, something bad is happening. Let's pause the whole bridge." It'll be a pain to customers, but if you're currently being hacked, um it's probably a good thing to be able to do. So, we've done the messaging layer and the app and the call layer. Now, let's hit the application layer.

we now need to have the move up the stack a bit. And so, now we're in our business logic contract. And really, your business logic contract is going to need to know that it's really dealing with um part of your application and not some random other contract. So, maybe you need an allow list of application contracts that can talk to you. So, sure in some situations you're going to be open to any um any any application, any contract on any blockchain, but in other situations it's going to be more linked. And so, you need to have that allow list.

You need to be possible as well. Um so, the reason for having possibility at the function call layer and the application layer is what happens if there are multiple applications using the one function call bridge and it's only your application that's being hacked? The function call bridge is not going to want to pause. They're going to want to keep on going. And so, you um yeah, so you might be in your best interest to um have your own pause feature. And it's not going to cost you a lot of gas because all you're going to do is be reading one storage location to say, "Am I paused?" So, it's not a biggie.

Um and um so, another thing to think through at the application layer is that if you are using a non-atomic cross-chain function call layer, then, you know, you could have failed transactions. And so, invariably you'll see these ERC-20 um bridge um contracts and they'll have some admin transfer. So, it's where this you've got this um entity that can um do a transfer to anyone for any token in any amount. So, you know, imagine if you had say um $200

million worth of wrapped ETH on your bridge and you've got some admin somewhere can just do this call and can transfer all that money. So, it's a it's a bit of a scary thing. And so, I guess the question is, who is this really trusted admin that you're going to have? And what happens if they send $200 million to the wrong address? Or even if it's just a a $10,000 transfer that fails and they have to do a refund. What happens if they send, you know, they do a typo and they send $100,000 rather than 10,000?

Or they send it to the wrong recipient or for the wrong token. It to me it feels like a complete nightmare. So, I think the idea of I mean, this is the real cost of non-atomic bridges is having to have this admin transfer. as well in the at the G Pact um protocol, so we allows it requires locking. And the locking is actually done in the application. And so, you can do locking for a whole contract at a time or just single storage locations.

And so, if you do for a whole contract, obviously your whole contract is locked, but it's simpler. And it's going to cost less gas. But, um if you're doing per storage location, then you can have far more complex designs. And in fact, there is templates to help you, you know, to make this simple for you. Um but it does cost a bit more gas. Another thing to think through, especially for ERC-20, is minting and burning and mass conservation. So, these um the you can have a an ERC-20 bridge or ERC-20 contract, should I say, which is a minter burner. And in this situation,

any user can burn tokens, so essentially throw them away, have have destroyed. You can have burned from where um another account being can be authorized or allowed to burn your tokens. As well, um certain entities with a mint or role can be authorized to mint So, you can imagine that you've got say Ethereum mainnet and a side chain, and when someone transfers tokens from mainnet to the side chain, you want to mint some tokens to give them based on what they've done on mainnet.

And um the So, the the what that's going to mean is that the the entity that's authorized to mint is going to be the cross-chain bridge. And so, you know, that's a bit of a problem because it means that this bridge contract, which could be hacked, is has the ability to mint as many tokens as it likes. So, the opposite type of um bridge or contract is a mass conservation contract. And in one of those, you um you you work out your total supply, and at that point, you can't go off and um create more tokens. And so, invariably, you um your your bridge

owns some tokens, and it transfers um essentially to users, and then they transfer tokens to the bridge um to the bridge ownership. And so, in that way, the bridge is holding the tokens in escrow. So, if there's a bug, the most tokens that can be stolen is the number of tokens that were in escrow. And so, the attacker can't create more tokens. And of course, you can limit how many tokens are active as well. The bridge doesn't have to own all the tokens. another thought is limiting the value on the bridge. So, if you've got say

$50,000 per staker and you've got overall a million dollars staked, say, um then, you know, you could say, "Right, we want to limit what's on the bridge to being less than um the amount being staked." Um but of course, as we know, it's not the amount staked, it's the amount that can be slashed, which is, you know, subtly different. Um but yeah, so you want to try and limit that. But the question that you've got to ask yourself about, "All right, we're going to limit, we're going to have a bridge quota." is, so at which layer of the bridge are we doing this quota? And, you know, say, can the say function call layer know anything about the amount of

money on the bridge? And um what about ERC-20 or ERC-721 tokens, so the NFTs? How much is an NFT worth? So, how do you work out how much you've got on the bridge? And what about a trade finance situation? You know, how does that relate to money on the bridge? And um for that matter, how do you temporarily reject things or pause pause transactions whilst you're waiting for money to go off the bridge? And what is on the bridge anyway? What does it mean to be on the bridge?

So, um another um thought is at the application layer is that all these cross-chain transactions cost money. So, maybe you could somehow or other batch them up. And, you know, say maybe hold all transactions for say 10 minutes and then send them off in a single transaction. Or maybe you allow users to send multiple different tokens all in one transfer. So, you going to have to worry about then what happens if one but not all fail on the destination. What happens then? So, I think there's a lot of complexity trade-offs there.

All right. R- Security. there is So, OpenZeppelin is a project which does lots of template contracts for that you can use. And they've got um some access control contracts. And you know, using them to then have different access levels for different users is a great idea. See, you know, you don't want to have say process data and add new bridge contract being part of you know, having the same access level.

You need to have different roles and different access levels so that you've got some level of security. You want to separate out the data chain or the data channel and the control channel so that you can't get that mix wrong. Another really big thing with security is, you know, before you take on some sort of destination blockchain or roll up, you've got to look at the security of it. Do you trust that they've got good security? You know, I'm talking about physical security. I'm talking about e-security. Are there Could their private keys get compromised? And you know, how how solid is that blockchain?

Cuz as you know, the diagram here, if that ground gave way, that whole bridge is going. And it's you know, what happens if the bridge stops working because a source blockchain becomes untrusted because it becomes fully compromised. What happens to the tokens that came from that bridge that are on another blockchain? How does that all work? Another security thing to think through is attack surface. So, when you've got a single blockchain application, your attack surface is that blockchain. But, you know, once you're looking at cross-chain, your attack surface has now extended to the other interconnected blockchains. And so, you know, you

really need to then be controlling which blockchain you react to. Okay, another thing to think through is the blockchain IDs. So, where do they come from? Are they correct? How do you know that you're interacting with the right blockchain? And you know, where did how do you work out the boot nodes to interact with? So, where where do you and I via the Enterprise Ethereum Alliance have come up with a an EIP that talks about this. So, have a look at that.

Upgrade is another thing. So, you know, you need you may need to fix defects in your contracts. And so, you need to have upgradeable contract pattern. And so, there's two ways of doing this. One is like having a separate data holder and business logic contract. There's also another upgradeable pattern that Open Zeppelin have come up with, which is really cool. you really need need to think about having that ability, but also you've got to think about the ramifications of being able to upgrade. So, will users be concerned about contracts that are upgraded?

another really big thing for security, and this is for users, but you know, who are these POA people these attesters and relays? Should they be trusted? And you know, do they use staking and slashing? And how do you go about slashing someone? how are they allocated? Is it some sort of random allocation, a bit like say how Ethereum 2's going to work? Yeah, how does it work? if the if the the validators say were the same or other the relayers were the same as the validators from the side chain that you're interacting with, then maybe that's pretty good because they've got a vested interest in making sure that the blockchain doesn't get hacked.

And a lot of these protocols have these watchers or fishermen, fisherwomen who are going to be watching the chain to make sure everything is good, but who pays them to keep on working? And if there's 99% of the time there's no bad behavior, then they're not being paid, so they're not going to operate. So, who's paying the watchers to watch the network? So, we've also at the EEA come up with some great security guidelines. I encourage you to have a look at them. people ask this quite regularly at you know, how many TPS? And it really does depend.

the limitations are going to be caused at multiple levels. And so, one is that if the relayers have to sign every message, that's going to be a limiter because you have a lot of signing and you've got to be submitting those transactions to the destination blockchain. But equally, if you've got to coordinate, that's a lot of work, too. And you know, the number of transactions that need to be submitted on the chain is another thing and the amount of gas used is you know, cuz that affects the amount of transactions that can be submitted.

There's also if you're going to have mass have a quota on the bridge, then what's the latency across the bridge? And what about if you've got a hub blockchain? Well, what's its maximum TPS? And is that going to be the limiter? you've got to worry about also the performance of these blockchains and especially when they're in congestion, maybe um the scalability of your bridge is going to go down. as well the at the application level, it's going to come down to what's being executed, and as well how they um if they're lockable contracts, how they've been designed, and whether you can have parallelism or not or all got to be sync

um serially done. Bridge fees, how are we going to make money out of all of this? So um bridge fees can be charged at many levels, and um in fact I I should have probably put in the messaging layer as well. So you know, I think the messaging layer could be watching who's doing what and refuse to um transfer or relay um messages if um you haven't subscribed, for instance. But you could imagine you could um have some ERC-20 that you that you um that you ask for.

that you know, so you could have imagine you can have an ERC-20 that you get to charge as part of the bridge function call. And um you could also require ETH be transferred as part of the call. You could have people being in an allow list, and you pay um based on um subscription service. And so yeah, so there are many mechanisms. Okay, so the EEA working group is working on standardizing the um interfaces between layers. And in the G Pact repo, you will find this protocol stack including the interfaces.

yeah, this is being actively worked on. Um I encourage you to have a play with it, have a go. Feel free to contribute. So, some philosophical questions before the end. And um yeah, so at hey, if you do a if you Google Ethereum Engineering Group on YouTube, you'll find our YouTube channel. Okay, so philosophical questions. the um so, what is a bridge? So, you know, is it the function call layer, the messaging layer, or the application layer, or somewhere in the middle? You know, what what what Which of those is the bridge? And um or is it all three?

Um another thing to think about is so, we talk about transferring tokens, but uh you know, is one say token on mainnet the same value as it on a side chain? You know, you've got different liquidity pools sizes, so it's going to be different. And you know, is having an upgradeable contract a good thing or a bad thing? And um you know, when is money on a bridge? Is it when the bridge contracts have access to them? And probably the big one is that last one. So, if you're transferring a billion dollars, which one would you use?

And of course, there are these um design choices and things to be thought about. You know, who do you trust? And you know, how do you you know, how many transactions do you need to actually have these transfers go through, and who is submitting the transaction? Um and you know, can a user do this without having any value on the destination? What attacks are there? Yeah. So, coming up, we have got a stack of talks over the next 3 months. I encourage you to turn up to all of them. Um and so, next is um Raghavendra with state expiry. So, just go on to the Meetup website. So, this is the Ethereum Engineering Group Meetup. Um go on to

our one. I do put some on the other um Meetups, but not always. So, for a complete list, use the Ethereum Engineering Group. And I have talked an awful lot. and I don't know if I even dare to say are there any questions. I know Mark puts something in. Maybe I yep, that's good. Ooh, just six flies off Was that you saying something awfully quietly?

There's a There's a question for you in the chat. Oh. Okay. Is it All right. So, how how do you transfer to 1 billion dollars? I don't have a billion dollars. Ah, the problem you know, I think it if if I if Good problems to have probably. I don't know. I Is it be Having a billion dollars a good thing or a bad thing? I'd probably give some of it away or do some I'd do some community Tell Tell me a few Bitcoin, right?

Yeah, I don't know. I mean it's all all all good funny fun, isn't it? What do you do with a billion dollars? But yeah, I think um I think realistically transferring it incrementally might be the way to go, you know? So, I know we all get hung up on Ethereum transaction costs and stuff and maybe bridge transaction costs. But if you trickle feed it at $10,000 at a time, but the big thing is you want to transfer it out of the bridge cuz, you know, as we know from the Poly Network hack, you know, $600 million, you know? If if it's all sitting on the bridge, then it can be taken. So, yeah.

All right. Well, look, thank you everyone for bearing with one another. I have to ask I have to ask Vitalik that question, mate. He doesn't I I So, we've had Vitalik do a talk at one point, and I tried to make sure everyone steered clear of the is the ETH going up and how much ETH do you have, Vitalik? Cuz it feels a bit, you know, but I I I think you'll probably find he'd say, "Why would you transfer Yeah, yeah, yeah.

It's a good question, why would you? You don't need to. Well, you know, I I don't think you'd transfer a billion. I can imagine, though, transferring some money onto a roll-up, you know, just to do stuff on a roll-up, but yeah. All right, look, thank you, everyone. Have a great 2 weeks. It's going to be great to hear Ragavendra in 2 weeks. Please RSVP for all the sessions, and in particular, I'm I'm really interested in seeing how everyone goes at the Solidity test in about 2 months' time. So, you know, start learning up on Solidity now, Stefan, and you'll be ready to do the Solidity recruitment test.

All right, bye.