 So, 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, oh, 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, Ridge, how do you think it's secure? Maybe that's a good phrase. Only one person. That's great. Clearly DGen's here. 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. So the whole point of 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 Coinbase bridge. You're on Ethereum, you lock your funds into this bridge, and then it magically appears on Coinbase. You go on 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 you'll ping Coinbase and say, Coinbase, let me withdraw my 1,000 ETH because I'm a wheel. And then what you'll imagine is that Coinbase will send a message to the bridge. To say bridge, let Alice withdraw her 1,000 ETH. Now from the perspective of the bridge, the bridge has to be convinced that Alice is entitled to this 1,000 ETH. So how does the bridge check this? In the Coinbase example, the bridge will just blindly trust Coinbase. If Coinbase says Alice is entitled to 1,000 ETH, then Alice will get her 1,000 ETH. 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 all-chain database records the account balances, the program state, the program smart contract code, everything that a database should probably have. But most importantly, it's recording the liabilities of the system. If you have 10 coins in the database, then you're owed 10 coins from the bridge. And the bridge has the assets. And the whole point of these roll-ups, or these layer-to-use 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 in order to use these cryptocurrency exchanges and services. The first way to build it was a single authority. The Coinbase is the bidstamps in the Krakens. I lock my funds 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% of all cryptocurrency assets. Then we moved on and thought, well, can we have a multi-authority bridge? Now, instead of just trusting Coinbase, could we trust five out of nine validators to protect the funds? And then we went a little further and thought, well, what about these crypto-economic bridges? What if I could stake assets and then become a validator and appoint myself to protect the funds? Now, in all three cases, especially these crypto-economic bridges, they're still just multi-authority. So in late 2021, around six entities represent, I believe, 85% of the stake on Polygon. And as these six entities that you're trusting to protect the assets in the Polygon's 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 or 10 parties to protect billions of dollars. You know, the whole point of cryptocurrencies was to remove the intermediaries. And now we've just reintroduced them. Now there's 10 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 raise of hands here. Who's ever lost money with a third-party service? Look at this, yeah. Come on, the D-Gents. I hope you didn't use Luna. But anyway. But you know, basically, they all keep getting hacked. The biggest hack was Mt. Gox. They lost nearly 6% of all Bitcoin that will ever exist, around 800,000 Bitcoin, or about 6 to 800, give or take. And now we sort of just put it under the table and we just pretend it didn't happen. But it's very frustrating. But why did this happen? 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 funds, this increases the likelihood that it's going to fail and then they get hacked. What about a multi-authority bridge? That should be a little better in practice. There's more targets to hack. But of course, the run-on bridge, 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, 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, not your keys, not your coins. We're blindly just giving our coins away and just hoping they can protect the funds. So the question for these bridges is, 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 sidechain paper in 2014. They don't use the word bridge. They use, they call it a two-way bank. But the idea is very straightforward. You take your Bitcoin, you lock it into a bridge and it appears on an experimental blockchain. So this is the Ethereum example. You know, you're on Ethereum, you lock it on an experimental blockchain, you transact away, then eventually you bring your funds back to Ethereum. Now in the sidechain paper, the idea is that there would be a smart contract on Ethereum in this case, that would check 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 if the other blockchain agrees that the funds should be withdrawn. But the issue is that when you have a consensus protocol, you're still trusting the judgment of a set of parties. And there's two ways this is trusted. The first case 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 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. But the real issue with the sidechains or the sidechain paper was availability. You know, what if the experimental blockchain goes offline and 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 sidechain paper. So, again, I'm gonna 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 the goal of Plasma. You know, back in 2017, the Plasma paper came out. Has anyone tried to read the paper, by the way? Okay, maybe a better question. Could anyone read it and understand it? No, look at that. I spoke to Joseph recently, and he called it aspirational in terms of his writing, because it's a very difficult paper 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, it tried to do better than the sidechain paper. Now for about two years, as a community, we had all these different variants of Plasma. You know, PlasmaCash, you know, Plasma, and a partial spending, whatever, Plasma MVP. But none of the solutions were satisfactory. You know, they only supported payments. They all had 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's just released his GitHub in total Ethereum style, that really helped simplify the design space. He separated out data availability and making sure the updates to the database are valid. And 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. Now if we're gonna categorize this as a bridge, we would call this the validating bridge, because now the bridge will independently protect the funds. So let's give an example. We have an executor, and they want to update the off-chain 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, it will not trust the executor. It must independently be convinced that this update is valid and correct, and that updates frequently occur as well. So then the executor has to send convincing evidence for why this is valid. And then the bridge will check the evidence, check how frequent it is, and say, yep, the off-chain 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. The loop rings, optimistic ethereum, z-casing, stark, or arbitrium, they're all trying to build a validating bridge. And if they can build this, then that's really exciting, because now we can have a bridge that runs in Ethereum, and it's Ethereum that's protecting your funds from the adversary. If they try to steal your funds, nope, they try to censor your transaction, nope, it will always try to defeat this all-powerful adversary. It's a great punch, isn't it? But this sounds good, it sounds really exciting, but is it too good to be true? Can the rule-ups really satisfy this? I'm clearly knowing 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. We're gonna talk about who are the agents, who's involved in the protocol, we're gonna 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 honest user really just wants to lock their moon cat into the system, buy and sell their moon cat, and then get their moon cat back out. 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, who will take the transactions, execute them, and then propose an update to the bridge. Thus, I know, let's watch this in action. So we 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 Alice is going to send one coin to Bob. So she'll sign the transaction and give it to the sequencer. 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's simply held by the sequencer. So when you send a transaction in Arbitrum, it's 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. The sequencer waits around for a while, more transactions come in, and 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, then he'll post a checkpoint to the bridge. And he'll say bridge, here's an update to the database, and this is why it is valid. And this happens continuously. 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? Who are we trying to defend against? Who's trying to steal our funds? 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 masses delivery. The other one is that the adversary can corrupt nearly every single party on the off-chain 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. Everything else can be corrupt and evil and out to steal our funds. And this is the most powerful adversary that you have to defend against. They literally control the entire off-chain system. And if you look at L2 beats, you will notice that no roll-up today that smart contract enabled can actually defend against this beast. It's a very, very difficult adversary to beat. And it's probably gonna be another year or two before a roll-up can defeat this beast. 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 safety and the 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. Is the data available? That's data availability. Can anyone get a copy of the data? The second property is state transition integrity. From the bridge's perspective, are all proposed updates to the database valid and correct. And finally, censorship resistance. If the entire system goes offline, can the bridge independently, forcefully order and eventually execute transactions that makes you can unwind your position and withdraw your funds from the system? So what about data availability? What is this problem? And there's three questions we're gonna answer. Why does the data need to be public? What data needs to be public and 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 protect from the all-powerful adversary. So the only way the honest party can help is if they have a copy of the database. 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 win the game and you can't propose an actual update. So that's why it has to be public for one honest party. What data needs to be public? And this sort of varies between the optimistic roll-ups 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 all the updates to the database. And there's two types of data. One is transaction history. 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. Or you have database A, database B, you get the state diff, the difference in the storage values and you can propose the state diff. And so as a user, you get the state diff, apply it 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. And finally, how do we guarantee the data is publicly available? So in Plasma, the focus was this challenge process. Could I challenge the operator to make the data available? But for many years, it was considered too complicated, too complex. Today, I think you could solve that problem in a reasonable manner, but most in the communities has ignored it. The other problem, the other way to solve it is a committee. This is like the stark net committee or the any trust committee, I think is arbitra nova. 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 rule up. You just post the data to Ethereum and Ethereum guarantees that the data was available at one point in time. So what about the state transition integrity problem? Well, this is very straightforward. If one update to the database can include an invalid transaction, then the adversary can steal all the funds in the system. We've seen this time and time again with all of the bridges, the most recent one being Binance. 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. You know, you're gonna 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. 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 the side chain and what will be a rule-op or a layer-2 protocol is censorship resistance. 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? Imagine that Alice wants to steal our moon cat. So he gives the transaction to the sequencer and the sequencer is like, no, no, I'm not gonna let you sell your moon cat. You know, how dare they? The user should be able to forcefully order this transaction. So the user will simply take 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? 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 who 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. 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 tree system. And for the OGs out there, this is the bear wheel from 2014. You know, I think the three bear markets before and they replaced the Bitcoin shield with an Ethereum shield because ETH is money now. But anyway, what I want to finish off with is there's these three core problems. But they're not the only problems. There's a whole host of other problems that you can get your teeth into if you're interested in solving cool problems about rollups. As I mentioned, censorship resistance is non-trivial. There's a lot of nitty-gritty details that makes it difficult. 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. We have the arbitram virtual machine. We have the optimism, bedrock. We have fuel in their sway language. All these really cool virtual machines in 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 rollups as well. And finally, 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 rollups, the assets get fragmented across the rollups. Is that not a problem for liquidity? Well, we've always had this problem of crypto exchanges. You know, you have Coinbase, Kraken, Binance. So it's not a new problem. But now anyone in this room can deploy a solution on something like arbitram. We could quickly move your funds to the optimism. This, you know, cross-chain transfers, interoperability. This is now a venture that anyone can build. Or if you tried to do that on Coinbase, you know, Coinbase is gonna probably tell you to go away. So that's also really exciting. 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, Web3 is a bit of a buzzword. You know, if you're all developers and you're all sort of like, oh well, Web3 is just a real thing. But to me, my vision of Web3 is that if you consider the Web2 world, Web2, we've always had to trust the off-chain system. 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 Web3 world, I would hope we can have a user experience that's similar to Coinbase. I lock my funds in, a nice UI, 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 Web3, so when you use these roll-ups, eventually it will feel like using a Web2 service, but much better, you know, security and trust guarantees. And I hope, and this is a quote by Vitalik, you know, there's a wonderful blog post on this, custody'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 Mungok, so the new BitStamper Binance, you know, you run your service, you get these human processes, and you have to secure billions of dollars. That obviously doesn't scale, it's very scary. You know, who wants to be liable for protecting billions of dollars? I mean, that's where he has hands. Does anyone here want to be responsible for protecting billions of dollars? No, well, look at that exactly, you know, screw that. That's way, that's way scary. So what I'm excited for is the roll-ups. If there's one roll-up that can get a good, you know, a good implementation that's easy to deploy and re-instantiate, that has a good developer experience so that anyone here can build on it, then we've solved the problem. You know, we've replaced those human processes with software, but we all know software skills. So you deploy a roll-up, you offer a really cute UI, I can go on there and buy and sell my Mungok, but 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, but it's the operators who care. No one here raised their hand when you wanted to protect billions of dollars. So if you're all gonna do a new startup, you're probably gonna look into the roll-up to say, you know, could I re-instantiate this and reuse the software? That's the layer three 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.