# Defragmenting Ethereum - Interoperability and the Superchain

- Speakers: [Karl Floersch](https://streameth.org/speakers/karl-floersch)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-13
- Duration: 25:28
- Watch: https://streameth.org/watch/673499049dbb7a90e1dd0381

## Description

With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.

Now we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?

## About the speakers

### Karl Floersch

Started out at ConsenSys building applications, then moved into the core protocol at the Ethereum Foundation, then started work on L2 scalability with Plasma Group which evolved into L2 scalability and public goods funding at Optimism.


## Transcript

6 p.m. Final slot. Everyone wants to talk at 6 p.m. and also listen to talks at 6 p.m. All right. Well, hello. I am Carl. We're going to talk about interoperability for Ethereum. So defragmenting Ethereum. We are in, let's pick up where we left off. So I really measure time based on DEVCONs. It's like one DEVCON and then two DEVCONs, you know, go that's kind of how I measure it. And I really think it's kind of legit in that every DEVCON there feels like a new sea change that happens. All the brains get together and they mash up. And I feel like DevCon 5, it was this crazy proliferation or this beginning of optimistic roll-ups, ZK roll-ups. And then we had next the super chain and proliferation of all these OP stack chains across Ethereum. And then boom, now we are in a new phase, which I like to call interoperation, because unfortunately with the proliferation phase, you end up with a whole bunch of fragmentation. But this is exciting. We have a moment where we literally have an unbelievable amount of low-hanging fruit to bring all of these chains together through open source interoperability standards across Ethereum. So nothing is that new, by the way. This is a PSA, people. Nothing is that new. Nothing is that unexpected. And technology marches forward very, very slowly. In other words, we've known about all of these problems since the, you know, scaling roadmap for Ethereum that Vitalik put out way too many years ago. And, you know, sometimes I think of myself as like a little snail moving along, like seeing the tech progress go. And then I whip out my phone and I'm like, oh my God, what's going on? And I'm on the moon. But no, it's fake news. Just calm down. We're making progress one step at a time. So, you know, right? Like, we knew that we would have a bunch of chains, and we'd fragment the roll-ups, and then we'd, you know, join them together into a happy union. Like, that's kind of, That's been the point. So, anyway, I want to talk about the basically my goal for this talk is to show a very large amount of, you know, low hanging fruit that we can all pluck for this interoperability phase. And, you know, before even all of these dev cons, I was but a mere durable developer working on memes of meme craft. You know, my absolutely killer application. It was incredible. You know, I had everything that you needed for a killer app in Ethereum, right? I had a manifesto. I had a team page. And I even had an unusable application. It was like literally killer app material. But I knew that there was one thing that would hold me back and that was my application would never scale to the number of users that I needed. I knew the world was going to use memes of meme craft. 10 TPS, you know, 10 second latency, not going to make it. And so I got into the trenches. We all got into the trenches and we started building out both the role of technology and now the interoperability technology to make it possible. And so it really is a moment where it has become possible. The low-hanging fruit is immense. So let's go over kind of like all a smathering, a kind of shotgun of all the different things that we need to fix, candidly, to make this happen. Things, by the way, that are not new. Like the great thing about this low-hanging fruit is that it has been done before. For example, asynchronous programming paradigms, that is the norm in normal application development. We can build those in. Passkeys, thankfully, Web2 did us a solid and fixed a bunch of our wallet UX for us. Sessions, like session keys for when I log into a website and I do a bunch of interactions without constantly clicking sign transaction over and over and over again. There's no reason that this stuff and more cannot be used in the crypto space. So in order to kind of like make this a little bit more tangible, I'm going to go through a user journey, kind of a developer journey, and then just like talk more about the tech. So let's get into the user journey. What is the user journey of memes of meme craft? This incredible application for the masses, right? We're gonna have a login screen. The login screen, familiar terms. We're talking about logging in. No seed phrases, pass keys, I'm sorry. I just have to, we need decentralization but we just got to make it usable at the same time. So both, both mass adoption and decentralization, but we just got to make it usable at the same time. So both mass adoption and decentralization for the world. So, you know, click login, sign in with a passkey, user auth with face ID, boom, you're in. Great. Now the next stage, mint. We need to, of course, mint our memes. So what do I need to do? I need to click on mint. No extra signature, just like boom, transaction succeeded in the background. Don't worry about it. Easy. Now I have my memes, and now I'm going to battle them. Of course, what else would you do with your memes? So I'm going to matchmake. Boom, I found a battle match person. And success, I won. Right? Great. And now, of course, I'm going to share my battle. Because that's what we miss about Web 2 and Web 3, the ability to click the share button. I've never clicked the share button, unfortunately. But anyway, really I just wanted to talk about composability. And that was my little segue into it. So simple, right? That was like a very normal, like, honestly incredibly boring user flow, unfortunately. Well, no, no, no. It's a great user flow. Memes of Minecraft, take it off. But the developer journey is actually kind of immense to make all that happen while preserving the open source decentralized protocols that we all know and love. So, developer journey, building all these things. Okay, first, I'm going to kind of skip past a bunch of the developer journey because it's not actually just too much. But imagine we're on an AI code editor and in the browser with auto-refresh and all the bells and whistles. OK, so for the login side of things, we're going to sign in. OK, what do we need here? Well, we need easy to use frontend libraries that I can just very easily import, start a passkey kind of session, smart wallets with sessions or even just a temporary wallet, that's fine by me. A super RPC so that I can actually send transactions to all of these different chains. I don't need to click on that network switching, kind of icon. All of this built in very seamlessly. Please give me a very good solution for this. All the chains across Ethereum, you know, let's do it. So, right, clicked mint, etc. Now, this little flow, this little flow is actually insanely challenging. So, what happened here? First off, I have assets across a whole bunch of chains. I clicked mint, and I paid for gas. I paid for the mint of that meme. And I did not have to worry about any of these silly chains. Why did I not have to worry? Because we got things like ERC7683, the easiest ERC to say. And what that is, is intense. You're able to abstract away and say, okay, a user has cash on, you know, one chain, one ecosystem. There's a really high latency bridge that connects them. Well, happens to be that there's an open protocol for fast liquidity providers that you can send them your capital on this chain, and then boom, they will give you the same amount on the destination chain. No problem. They'll handle rebalancing. And this is great. It's a win-win for everyone. Instant user experience for the user and fees for the liquidity providers, regardless of the speed of your message passing. Now, this, and we can get a good UX for this too, you know, abstracted into a very simple interface that everyone can use. All right. So first off, that's how we consolidate all the assets into one chain. But obviously, because my example has this in it, the mint function is on a different chain. So what did I do? Well, I wrote an asynchronous smart contract. So, you know, we're building out these interoperability protocols. If you use a kind of like, you know, intertwinement-based interop protocol, then you can achieve two-second or really instant interoperability. And that is a major unlock because now developers across the Ethereum ecosystem, it's one thing to build a smart contract that does a kind of, you know, end to end two chain flow with, you know, when you have to wait for like, you know, even five minutes is a long time. But if it's just an instant flow between the chains, that's like, I don't know, I personally experienced it. You will too, and it's pretty sick. Anyway, so we can actually build out a whole bunch of asynchronous programming libraries pretty easily even today. You can use common promise syntax that you'll be familiar with if you, you know, do, for example, JavaScript. And promise sponsorship, you know, we are going to be able to reuse all of this intent-based infrastructure for general messages. And by the way, Ben wrote an async, you know, library, and Ben is not even like, well, he's a physicist. He's not some coding genius. He wrote it in three days. You know what I mean? This is like, this is the level of like obvious stuff. You don't have to be smart to be like, oh, JavaScript has solved this problem this way, and it's not solved in my language, let me just do that. You know what I mean? Like, that's the kind of problem that I like, you know? Because I can't think of smart things generally. That's hard. Okay. So, anyway. Battling, right? We're going to battle. Matchmaking. Boop, boop, boop. Found. All right. Remember, that's what happened. What happened in the background? Well, what did we do first off? We found a low congestion chain because guess what battling is transaction intensive, of course Do a lot of battles anyway and they're gonna be chains that have high liquidity that will always have high fees because there's an incentive if the price moves and you Need to our bidding you got a bunch bots, you get a bunch of spam. Well, you need some chains that are explicitly not going to be the mega TVL chains that can do your little battles, you know? And you also probably want to have subsets of chains that you interact with explicitly. For example, memes of MemeCraft actually has two chains, and one of them is kind of medium usage and one of them is low. And so the front end will automatically just check and see, okay, the gas fees are very low on this chain. Let me deploy the battler there. Speaking of deploying the battler, installing contracts. This is 100% like, you know, contract deployment should be permissionless by default. And then developers can restrict where they want their contracts to live. This ecosystem, that ecosystem, this chain, that chain. But for a large swath of public good contracts, for example, you really want to have that be available as many places as possible. And so, you know, instead of just developers having to, like, choose where to deploy, the front-end should just deploy directly, and we can do that with Create2 Factory, which is available on, like, pretty much all the EVM chains. Cool. So... Now on to the bragging section. Well, this is... Obviously, I added this, tacked this in, because I really wanted to talk about composability and chill a very particular concept That is you know a little crazy, but think about it composability is key web 3 composability That is like the magic sauce. What is the most analogous, you know composable first thing? My opinion it is the web browser The web browser is this amazing universe where all these? Websites can link to each other and use each other and all that stuff and what did they do? They made this crazy choice the people who did the smart things over there in the web browser they decided to literally send code instead of just like binary blobs over the wire to then display in the browser. What did that do? This was an intentional choice by the web browser developers. They wanted to make it so that users, anyone, can right-click, inspect element, and read the code that runs and powers their website. Kind of sound familiar? Well, turns out we are doing the same thing all the time. We're just going to Etherscan and then getting very frustrated that the contract has not been verified yet. And then we're like, how do I verify it? And it's horrible. So anyway, I'm just really, I think we can like 10x the amount of, you know, code collaboration and the speed of our feedback cycles if we have things like on-chain package managers or inspect element for smart contracts, some kind of environment that makes coding with smart contracts more collaborative. Now, obviously, you know, maybe it doesn't work for a crazy DeFi protocol you want to formally verify, but I just think smart contract programming can be so fun. It doesn't need to be a horrible mess. And I don't know, we just haven't invested. So let's invest and make the feedback cycles fast and make it so that it's easy to learn because there's tons of examples of how people are doing it. And we can really foster an open source culture, not just at the protocol layer, but also at the smart contract layer. So now that was a kind of developer kind of shotgun of all the tech. Let me just list it all out in one big list. So first off, right, cross-chain reads and messaging. I could do a whole talk on this one. I'm not going to get into too many deets. But the TLDR of these and by the way, this is all open source protocols. There is no this is just a fact of the universe basically that you can build interoperability protocols which use this kind of optimistic or speculative output. So you're on one chain and you're like, okay, I think that this other chain is going to resolve to this value. So I will optimistically include that value and then move forward. And this works for ZKP-based proofs and TE-based proofs and all sorts of proofs. It's just literally, it's kind of, you know, how we, you know, lowered the latency of L2s by introducing a sequencer and more predictability in the ordering before it hits Ethereum. Same kind of, same kind of thing. So anyway, Mark can tell you, Proto can tell you more about that. And then, of course, we got Intents that, you know, There have been many talks. Shout out to Hart from before. Also, of course, chain-specific configs and chain-specific addresses all on L1 so that we can deterministically derive all of these different chains from Ethereum. Super important. Also, cross-chain token standard. Very exciting. All of these people, We can have interoperable tokens with zero slippage liquidity. And we've got this is my favorite section because it's the essentials. It's obvious. We need to build this. And it's just badly supported now. So like promise libraries that hook into Solidity as it is today, or even modifications to Viper Solidity that support promises better, please, please. And then also async contract upgrades is going to be a whole thing. Oh, my God. If you want to build the new open Zeppelin thing, man, there is going to be real patterns that develop there. And we need to standardize what those async upgrade patterns look like. I already talked about how users should be able to install contracts on chains. That is enabled with these create to deployments. You're able to permissionlessly deploy a contract at a particular address and not mess with the configs. And passkey wallets. We need to solve user experience. And so then, of course, finally the dream section. I just really want this collaborative coding environment. It would be so nice. Also all VMs, shout out to all the VMs. And write some rust or whatever. Oracleize everything. I want all these RPC requests to come with signatures so that I can use literally just use them for whatever. If I'm really horrible, I can do an RPC request and use that as a bridge for my horrible degenerate token bridge thing. Definitely probably don't do that. Missed browser. Okay, no. That one is a little... I'm going to get some flack for that one. But I don't know. I just still want to, like, not have to rely on a central party and load up a decentralized website, like, fully deterministically. I don't know. And obviously, you know, that's kind of the point of the dream section. I don't know everything. So, you know, we are this little slow snail progressing through the technological thing. And sometimes we come upon a tree and a whole bunch of fruit. And you know what? In those moments, those are the moments to capture and just absolutely devour all that low-hanging fruit because it is, I mean, it's easy. And I will say that I was last week, shout out to Proto, shout out to Mark, shout out to the interop, like peeps, they put together this interop devnet and I was like playing with it and it really felt like 2016 again. I don't know, this is such a reminiscing talk for me, I don't know why. It felt like 2016 again, where like everything is so obvious that needs to be built, and yet no one has built it because no one actually, I don't know, has like, I don't know, done it yet. And it's just, it was exciting. It was exciting. Like all the pieces coming together. It's like more collaborative because you're, because you're not fighting over a tiny little slice of a pie. You're like, oh, I'm going to work on this, and then you're going to work on that, and we can compose together, and we'll all win together. I mean, that is how we unify Ethereum IMO. And finally, create memes of meme craft. So this is our timeline. But what about DEF CON 8? Well, DEF CON 8, it is mass adoption time. We're going to have 8 billion users. Ethereum is going to solve the fertility crisis. Can't stop until global adoption. Every single person. And so, obviously, you know, very excited for the future. But we still got a lot of things to do. We got to ship Interop, obviously. All these standards. We got to scale ETHDA. We got to dog food the protocol. We got to build all these dev tools. And hopefully, either is Phoenix willing, you know, we'll be able to unify Ethereum, defragment Ethereum, I guess is what I should have been saying, create a retroactive public goods flywheel so that we're funding open source software from now into the future. And, you know, that's why we're building the Optimism Collective. Together, we can make impact equals profit and summon ETHUS Phoenix, build a user-owned internet. Thank you very much. All right, Carl. You know, when I was watching him perform I was reminded of someone who moves a lot And so much energy And it was such a joy watching you do that presentation When someone is so passionate about something You cannot help but smile And the first and most popular question Carl is How does Carl have so much energy? Because I'm deeply anxious And I channel it into excitement. What a gently answer. I'm deeply anxious. Okay, anyway, moving on to the other questions. Thank you for that lovely question. Carl, if I were to start building a library or framework today to make building horizontally scalable apps as possible what should I build? Nice okay if you are a solidity nerd then go out compete Ben because you definitely will have just kidding and build an async promise library something like that no the other thing if you want to just be I don't know key to my heart I built a horrible like create two base deployer thing. I just want to make create two deployments really easy because, I don't know, I just don't like dealing with the, I don't know, it's just the tooling is bad. You know, please, please do help me with that. Yeah, those are two of them. And the slides have even more. Fantastic. Please do help me with that. Those are two of them. And the slides have even more. Fantastic. When will Optimism Mainnet become a ZK roll-up? We already have! Obviously, Optimism is the name. We're very optimistic people. We obviously love optimistic designs. But, notably, Optimism is not a ZK roll-up. Not an optimistic roll-up. It's actually not really. It's a super chain. But the tech, the OP stack supports all types of proofs. And in fact, one of our design principles is to be proof agnostic so that we don't need to choose between this proof or that proof, and instead we can use them all. Because to be honest, they're all really bad. So when you have a lot of bad things, you stack them on top of each other and hope that nothing, well, they all don't break at the same time. That's called multi-proof, by the way. It's not just trolling. You have got to be the most entertaining speaker I've ever had to MC for. Isn't Superchain kind of like vendor lock-in? What would you say to that? I mean, I think there is, you know, definitely an aspect, but what are you getting locked into is my question. You are getting, quote-unquote, locked into open source protocols which fund public goods and, you know, create a flywheel that hopefully we all benefit from. And guess what? Ethereum, I don't know. Okay, they're going to get mad at me. But anyway. No. I think you can fork everything. You know? Fork us. And by the way, actually fork friendly is in our constitution and in everything that we do. It is incredibly important that it's open source so that you can, if you get vendor locked in in a bad way, fork to a different system. By the way, way, another thing. Web3, the whole point of Web3 is enabling a somewhat more robust right-to-voice. Vendor lock-in is inevitable in some sense and that is why in Web2 this whole like just exit this platform for the other platform, we see it doesn't work. Instead what we need to do is we need to build systems where governance represents the constituent parties and so that's what we're trying to do. we need to build systems where governance represents the constituent parties. So that's what we're trying to do. Very good. We got one and a half minutes. Excellent answer. One and a half minutes. Let's see how many questions we can go through. Which are the key things Dream Interop has to have? We want it to be fast, trustless, and secure. No. But, okay, yes. 100% fast. Honestly, yeah, fast, trustless, and secure. But for real, fast was my, like, I honestly undervalued the fast thing until I started using the fast thing. I got a little addicted. Because, like, there's a very big difference if you, like, have to go, like, if it's more than a couple seconds, then I'm going to click to a different web page. And I hate, like, I'm never going to go back. And so, I don't know, when I started, even when I'm testing, it's so much nicer to be able to, like, do everything real quick. So fast, really fast. Sub-cent and sub-second. Cheap, I guess, is the first thing I forgot to say. All right. We've got 20 seconds. You want to do one more? Last one. What are the biggest mistakes the Ethereum ecosystem risks making as it works on interrupt? Making it work on interrupt risks? Well, okay, I don't know what that actually means, and I'm not good at reading, and so I can't figure it out. But what I'm going to say is the biggest risk for Ethereum is to forget our values. We are building open source protocols that will create the world computer. There is one world computer. We're all building it. Remember that we can do this together. Don't, you know, get too mad at each other. It's fine. The algorithms don't control us. Well, that was truly the most entertaining Q&A I've ever hosted. Let's give him a big round of applause. Carl!
