Ethereum Foundation DevCon 6 - Layer 2s Track, 12 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: A Better Mental Model for Rollups, Plasma, and Validating Bridges by Patrick McCorry

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/a-better-mental-model-for-rollups-plasma-and-validating-bridges/

Sidechains, Plasma, Rollups, Valdiums, AnyTrust, PoS chains, Crypto Exchanges, all have one thing in common: the bridge. This talk provides an overview on the trust assumptions, threat model, security goals and solutions associated with the humble bridge smart contract. As we will see, rollups emerged because of the scalability bottlenecks faced by Ethereum, but the product-market fit is solving the operational security issues for bridging funds from Ethereum to an off-chain system.

Speaker(s): Patrick McCorry
Skill level: Beginner
Track: Layer 2s
Keywords: rollups,bridges,layer-2

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

Hi everyone, my name, is Patrick McCory and today I'm going to hopefully come across or give across a better mental model for Roll-Ups and bridges. So, just before I begin Has, anyone used the roll up Has. Anyone used like are most people here are awesome and when you used it like did, you feel like it was like more secure than using coinbase or hey. Read your hand if you think it's secure, maybe that's a good phrase. Only one person, that's great.

A

Okay, um so hopefully, by the end of this you'll, have a good idea of what it means for these systems to be secure and whether they're, actually secure or not, is a whole different world.

A

So the whole point of uh Roll-Ups and everything we're trying to build is really just Bridge engineering. All we're building are bridges. So, let's consider the coinbius bridge your own ethereum. You lock your phones into this bridge and then it magically appears on coinbase you're going coinbase. You transfer your assets, you buy some coins, you sell some coins, you lose some money, you make some money and then eventually you want to get your coins back to ethereum, and so your ping coinbase and say coinbase.

A

Let me withdraw my 1000 eighth because I'm a wheel and then what you'll imagine is that coinbase will send a message to the bridge they say: Bridge. Let Alice withdraw her 1000. Eighth. Now, from the perspective of the bridge, the bridge has to be convinced that Alice is entitled to this 1000 eighth. So how does the bridge check this? In the Columbia's example, the bridge will just blindly trust coinbase.

A

If coinbius says Alice is entitled to one thousand eight, then Alice will get her 1000 each and then it gets sent off and we're all very happy now, generically speaking what's happening in this type of interaction, generically. There's this all chain database, the OMG and database records the account balances the program State the program, smart contract code. You know everything that a database you probably have, but, most importantly, it's recording the liabilities of the system.

A

If you have 10 coins in the database, then your owed 10 coins from the bridge and the bridge has the assets and the whole point of these rule Ops or these layer tree systems is to guarantee that the Assets in the bridge can cover the liabilities in this off-chain system, and so we have to consider everything from the Bridge's perspective, because it's up to the bridge to protect your funds, but this trust assumption has evolved over the years. After all, we've all used bridges for the past 10 years.

A

In order to use these, you know cryptocurrency exchanges and services. The first way to build it was this single Authority. The coinbase is the bit Stomps and the Krakens.

A

You know I lock my phones in the coinbase and they have custody of the funds and they're responsible for protecting the assets and today I think they protect about 10 percent of all cryptocurrency assets.

A

Then we moved on and thought well can we have a multi-authority bridge? You know, instead of just trusting coinbius kubi trust, five out of nine validators to protect the funds, and then we went a little further and thought. Well what about these cryptoeconomic Bridges? You know what, if I could stick assets and then become a validator and appoint myself to protect the funds.

A

Now, in all three cases, especially these crypto economic Bridges, they're, still just multi-authority, so in late, 2021, around six entities represented I, believe 85 percent of the stake on polygon and as these six entities that you're trusting to protect the Assets in the polygons proof of stake Bridge, if they collude, they can steal your funds, but so far they've actually done a pretty good job. But in all these cases it sucks. You know we're trusting less than 10 people, our tan parties, to protect billions of dollars.

A

You know the whole point of cryptocurrencies was to remove the intermediaries and now we've just reintroduced them. Now, there's ten of them that will protect most assets, but it doesn't suck from an ideological perspective. It sucks practically because they keep getting hacked I mean maybe a good reason. Hansier who's ever lost money with a third party service.

A

Look at this yeah comedy gens. Last hope you didn't use a Luna, but anyway, but you know, but basically they all keep getting hacked. The biggest hack was monk Ox. You know they lost nearly six percent of all Bitcoin that will ever exist around 800, 000 Bitcoin or about 6 800, give or take, and now he sort of just you know, put it under the table and we just pretend it didn't happen. But you know it's it's very frustrating, but why did this happen?

A

It hopped like these hacks, occur because in reality we're taking a set of human processes, we're implementing these human processes and we're trying to protect billions of dollars and humans don't scale. So, every time we take the human processes and instantiate it somewhere else to protect more phones, you know, there's this increases the likelihood that it's going to feel and then they get hacked what about a multi-authority bridge? You know that should be a they're a little better in practice. You know, there's more targets to hack but of course the run-on Bridge.

A

You know five out of nine validators were compromised and they lost their funds, although in reality it's not really five validators, because four of them belong to one company, but you get the idea. You know multi-authority, Bridges and I feel like over the past 10 years. When we're designing these Bridges we've sort of forgot about our old school motto. You know not your keys, not your coins. There were blind leads, has given our coins away and says hoping they can protect the funds.

A

So the question for these Bridges is, you know: can we build and transact on an off-chain system by still allowing users to maintain custody of their funds and not have to trust the operator to protect the funds? And this was the original goal of the sidechamp paper in 2014.. They don't use the word Bridge, they use, they call it a two-way Peg, but the ideas of our history of forward. You take your Bitcoin, you lock it into a bridge and it appears on an experimental blockchain.

A

So this is the ethereum example. You know you're on ethereum, you lock it on an experimental blockchain. You transact a way, then. Eventually you bring your funds back to ethereum. Now on the side, GM paper, the idea is that there would be a smart contract on ethereum in this case. That would check you know the the consensus protocol off the other system. That may be it's proof of work, maybe the validators of that system, but there's a smart contract here with the assets. Just checking of the other blockchain agrees that the fund should be withdrawn.

A

But the issue is that when you have a consensus protocol, you're still trusting the Judgment of a set of parties and and there's two- you know ways. This is trusted the first kiss. Is you know what? If the consensus protocol agrees to an invalid block, you send it to the bridge. The bridge gets the invalid block, but all of the validators agreed again your funds get stolen. Now you could use a validity proof or zero knowledge proofs to make that a little better and there's a lot six years of work to make that better.

A

But the real issue with the side chains or the sidechin paper was availability. Now, what are the experimental? Blockchain goes offline on The Operators disappear. If the operators disappear, the consensus protocol stalls, it can't make any more decisions, and then your funds get stuck on the bridge and you can never get your funds out. So that was the issue with the sidecham paper.

A

So again, I'm going to ask a better question: you know: can we build a bridge that can protect us from an all-powerful adversary? So even if the entire system goes, offline, I can still get my funds out, and this was Dakota plasma. You know back in 2017 the plasma paper came out. Has anyone tried to read the paper by the way? You know that? Okay, maybe a better question: did anyone read it and understand it?

A

Noah look at that. I met I spoke to Joseph recently and he called it aspirational in terms of his writing, because it's a very difficult people to read. But the idea in the paper was amazing: it tried to solve that availability problem that liveness problem. So even if the entire system goes offline, you can still get your funds out. You know I tried to do better than this IGN paper and for about two years as a community, we had all these different variants of plasma.

A

You know plasma cash, you know plasma and a partial spending, whatever plasma MVP, but none of the solutions were satisfactory. No, they only supported payments. They all have these nitty-gritty details that made it not practical and in a way we sort of wasted two years, but we didn't really waste two years then eventually, Barry whiteheart came along and he just released his GitHub and total ethereum style. That really you know, helped simplify the design space.

A

He separated out data availability on making sure the updates to the database are valid and you know the way he solved. It was the roll up where you roll up the transaction data and you just post it to ethereum. Then all you've got to solve is making sure the data is correct and valid, and this led to the roll ups, this wonderful little GitHub.

A

Now, if we want to categorize this as a bridge, we would call this the validating Bridge, because now the bridge will end a bit independently protect the funds. So, let's give an example, we have an Executor and they want to update the offchain database. So they do this 1990 automation. They update the database and they'll propose an update to the database to the bridge. Now the bridge will not blindly trust the executor, regardless of who's authorized. This update.

A

It will not trust the executor, it must be independent or it must independently be convinced that this update is valid and correct, and that updates frequently occur as well.

A

So then the executor has to send convincing evidence for why this is valid, that you know, and then the bridge will check the evidence check how frequent it is and say, yep the off chin database is correct. The liabilities are fine, I can let the user withdraw their funds, and this is what the rule-ups are trying to build.

A

You know the loop brings optimistic ethereum ZK, saying Stark arbitrim they're all trying to build a validating Bridge, and if they can build this, then that's really exciting, because now we're gonna have a bridge that runs in ethereum and it's ethereum. That's protecting your funds from the adversary. You know they try to steal your funds. Nope they try to censor your transaction nope. It will always try to defeat this all-powerful adversary. You know it's a great great punch, isn't it, um but this sounds cool.

A

It sounds really exciting, but is it too good to be true? You know, come the rule. Ups really satisfy this, and clearly no one in the room earlier trusted the rule ups at all, apart from one person, you're a good soul. Okay, so let's try to define the environment a bit.

A

We're going to talk about here are the agents you know who's involved in the protocol, we're going to provide a high level overview of how it works in the threat model and, of course, the security properties for what it means to be secure, so who's involved in the protocol. First, we have the honest user or an honest party. The honors user really just wants to you know lock their Moon cat into the system, buy and sell their Moon cat and then get their Moon cat back out.

A

You know they don't really care about the system itself. We have the sequencer, who will take the user's transactions, order them and then pass them on so they're a transaction ordering service. Then we have the executor. We will take the transactions, execute them and then propose an update to the bridge.

A

That's I know: let's watch this in action, so you have Alice and Alice will deposit one coin into the bridge. Then this will magically appear in the off chain database. Then Bob comes along, you know, hi, Bob and Alex is going to send one coin. The Bob so she'll sign a transaction and give it to the sequencer.

A

Now the sequencer can notify Bob and say Bob you're, going to receive one coin, but what's important is that that's only a promise the transaction is in public, it's not vital. It's not even pending it simply held by the sequencer. So when you send a transaction, an arbor trim is the sequencer, that's getting it and it's making a promise to you that it will be executed. But it's just a promise.

A

The sequencer waits around for a while more transactions come in then eventually the sequencer will order the transactions and pass it on. In this example, the sequencer will give the transactions directly to the bridge. The bridge will order the transactions but they're not yet executed. We need someone to come along to execute the transactions, so the executor comes. He picks up the transactions again, the wonderful 1990 animation. He executes the transactions and he'll post a checkpoint to the bridge and he'll say Bridge.

A

Here's an update to the database, and this is why it is valid, and this happens continuously. You know we order transactions, we execute transactions, and then we convince the bridge that this is correct and valid, and that convincing is again the most important part of a bridge or a validating Bridge, so who's the adversary. You know who are we trying to defend against who's, trying to steal our funds?

A

So there's two aspects to consider. First, the masses flow control, the adversary can view reorder and drop all messages on the layer 2 system. The only guarantee that an honest party has is that they can send a transaction to ethereum and to the bridge. That's the only guarantee they get for Massey's delivery. Foreign is that the adversary can corrupt nearly every single party on the off-chean system. We simply assume that the bridge cannot be corrupted and there's one honest party who can assist the bridge. That's the only guarantee we get in terms of honest parties.

A

Everything else can be corrupt and evil and out to steal our funds, and this is the most powerful adversary that you can or you can. You have to defend against. You know: they'd literally control the entire auction system, and if you look at L2 beats, you will notice that no rule up today, the smart contract enabled can actually defend against this Beast, the very very difficult adversary to beat- and it's probably going to be another year or two before a rule. App can defeat this Beast.

A

So what's the security properties, then what does it mean to be secure for a roll-up or a validating Bridge, the overall goal? The overarching goal is that there's this off chain database. We have to protect the cfd and a sliveness and there's three sub goals. And again these sub-goals are from the perspective of the bridge, because all that matters is the bridge the bridge has to have a guarantee. You know, is the data available, that's data availability? Can anyone get a copy of the data? The second property is steer. Transition.

A

Integrity, is you know from the bridges perspective, are all proposed, updates to the database valid and correct and finally, censorship resistance. If the entire system goes, all flying can the bridge independently forcefully order and eventually execute transactions that make sure you can unwind your position and withdraw your funds from the system. So what about the availability? You know what is this problem and there's three questions we're going to answer. You know: why does the data need to be public?

A

What theater needs to be public and how do we guarantee it's? How do we guarantee that it is publicly available? So why do we care about the database being public? Remember we had one assumption, there's one honest party out there who can assist the bridge, so anyone here ideally could help the bridge you know protect from the all-powerful adversary.

A

So the only way the honest party can help is that they have a copy of the database. You know they need a copy of the most recent database, so they can take the transactions, execute them and actually propose an update to the bridge. If the adversary can withhold One update and prevent anyone from getting an up-to-date copy of the database, then they you know they win the game and you can't propose an actual update. So that's why it has to be public for one honors party.

A

What theater needs to be public and this sort of varies between the optimistic rule, apps and the validity Roll-Ups, but, generally speaking enough, data has to be public, so the honest party can compute the database so it needs. You know all the updates to the database and there's two types of data. One is transaction history, you know get out, get the entire list of order transactions sort of like a blockchain, execute the transactions and then you'll create a copy of the database.

A

Or you know you have data BSA data BSB, you get the state diff, you know the difference in the storage values and you can post the state diff, and so, as a you know, as a user, you get the state diff applied to your database and then you compute the new database. So there you hide the transactions, you only see the result of the transactions, but in both cases that has to be valid.

A

And, finally, how do we guarantee the deal is publicly available so in plasma? The focus was this challenge process you know, could I challenge the operator that make the data available, but for many years it was considered too complicated too complex. Today, I think it could solve that problem in a reasonable manner, but most in the communities just ignore it. The other problem, the other way to solve it is a committee is take this starknet committee or the any trust committee I think is arbitrum Nova.

A

They have a data availability committee and the committee will sign a message to attest to the fact they will make the data available or you do the roll up. You just post the data to ethereum an ethereum guarantees that the data was available at one point in time.

A

So what about the state transition? Integrity problem? Well, this is very straightforward. If one object to the database can include a can include an invalid transaction, then the adversary conceal all the funds in the system. You know we've seen this time and time again with all of the bridges, the most recent one being binance. You know it's. This is how they keep stealing the funds. Now, there's two different ways to solve this problem: there's optimistic or ZK fraud, proofs or validity proofs.

A

You know you're going to hear about this topic over and over and over again, because this is the one thing they all talk about. You know this is the most important problem in their mind. uh So I'll skip it for now, but to me the most important problem that no one talks about- and this is really the difference between the side chain paper. You know what is a side chain on what will be a rule up or a layer. Two protocol is censorship. Resistance.

A

If the entire system goes offline, can I still get my funds out, and that is really the biggest important topic for rule Ops and no one likes to talk about it because it's really hard. So what is censorship? Resistance, a margin that Allah sponsor seller Moon cat?

A

He gives the transaction to the sequencer and the sequences like no, no I'm not going to let you sell your mooncat, you know how dare they? The user should be able to forcefully order this transaction, so the user will simply tick their transaction and send it directly to the bridge. This is what we call forced inclusion: they send it to the bridge and the bridge will force its ordering and now it's ordered for execution, and this is really cool because then, if we consider liveness, you know how do we guarantee this eventually gets executed?

A

We can assume that the sequencer has absolutely nothing to do with censorship, resistance whatsoever. You can have a centralized front end a centralized sequencer, but the back end is decentralized and that's cool. That provides an amazing user experience because you know exactly what sequencer they interact with, but they are not responsible for protecting the system. We really assume, there's one honest executor: you can join the system, take the transactions, execute them, and then you know post the update to the bridge. We just need one honest party to protect the system.

A

So, to summarize, if you can solve all three problems, then maybe we can slay the Beast and just you know, deploy a secure layer to your system and for the ogs out there. This is the bare wheel from 2014. You know the I think the three bear markets before and I replaced the Bitcoin shield with an ethereum Shield because eat this money now, but anyway, um what I want to finish off with is uh there's these three core problems.

A

Are they not the only problems, there's a whole host of other problems that you can get your you know teeth into if you're interested in solving cool problems about real Labs as I mentioned censorship, resistance is non-trivial, there's a lot of nitty-gritty details that makes it difficult um what I'm excited for are those experimental virtual machines. This was the original goal of the sidechain paper. You know we lock our coins in Bitcoin and we unlock it on this experimental blockchain, and now we have this. You know we have Cairo for starknet.

A

We had the arbitrine virtual machine. We have the optimism Bedrock, we have fuel in their sway language. All these really cool virtual machines and custom, you know languages and software, but we're still retaining the security of ethereum and that's probably the most exciting part of these rule Ops as well and finally, um I guess. The last point I'll highlight is fragmentation of assets. A lot of people are worried that, if you have, you know 10 different rollouts, the assets get fragmented across the Roll-Ups. Is that not a problem for liquidity?

A

Well, we've always had this problem with crypto exchanges. You know you have coinbius Kraken binance, so it's not a new problem, but now anyone in this room can deploy a solution on something like arbitrim. We could quickly move your phone to the optimism this you know cross chain transfers interruptability. This is now a venture that anyone can build, or if you tried to do that in coinbase, you know coinbase is going to probably tell you to go away. So um that's also really exciting.

A

We can really solve that fragmentation issue now, but is it worth it just to finish up? You know: is this worth it? Is it worth all the work to build this validating Bridge now web 3 is a bit of a buzzword, you know I'm all if you're all developers and we're all sort of like oh well web3. Is this a real thing? But uh to me my vision of web3 is that if you consider the web 2 world web 2, we've always had to trust the off-chan system.

A

You know I take my coins, I lock it in the coinbase and I really have to trust coinbase. To protect my funds in the web. 3 world I would hope we can have a user experience. That's similar to the coinbius I, lock my funds in a nice UI.

A

You know I get instant confirmations, but the difference is that I don't have to trust coinbase for my funds, so the actual service is exactly the same, but the difference is whether I trust, the operator or not, or what I trust the operator to do, and that's really web three. So we use these rule UPS. Eventually it will feel like using a web 2 service, but much better. You know security and Trust guarantees and I hope- and this is a coupe by vitalik.

A

You know- is a wonderful blog post on this cursody's becoming a liability and what do I mean by that? So, if you consider, if you were to do a startup, maybe five years ago, you know you could be the new mangoc, so the new bitstamp or binance. You know you run your service, you get these human processes and you have to secure billions of dollars. That obviously doesn't skill. As far as scary, you know who wants to be liable for protecting billions of dollars? I mean that's reasons.

A

Does anyone here want to be responsible for protecting billions of dollars? No I'm! Look at that exactly. You know screw that that's weight, that's way, scary. So what I'm excited for is the rule lumps if there's one rule up that can get a good. You know a good implementation, that's easy to deploy and reinstantiate. There's a good developer. Experience says that anyone here can build on it. Then we've solved the problem. You know, we've replaced those human processes with software we almost offer skills.

A

So you deploy your rule up, you offer a really cute UI I can go on there and buy and sell my mooncat I. Don't trust you with it so I believe it's worth it because I don't think users care about custody. You know we all still use custodial Services. What is the operators who care? No one here raised their hand when you wanted to protect billions of dollars.

A

So if you're all going to do a new startup, you're, probably going to look into the rule out to say you know, could I reinstantiate this and reuse the software, that's the layer, 3 goal, and so that's why I think it's worth it! You know. Custody is an unnecessary liability and that's the end of my talk. I have three minutes left I, believe so. Thank you guys for listening and have a great time cool, awesome.