Superchain Technical Details | Karl Floersch, OP Labs | ETHTaipei 2024

oh my goodness jams all right I'm so happy to be back in taipe oh my goodness okay so this talk you may have seen parts of it before honestly is kind of like an evergreen talk and I kind of need to like set this context over and over again because it is so important and honestly I've been giving this talk I feel like for n years trying to scale ethereum it's been an absolute Journey but we are getting so close we're so close to scaling ethereum finally so anyway how are we scaling ethereum we're scaling it with the super chain and we also I want to leave time for questions and so I'm going to set up my phone with a timer so that I don't run out of time because I'm definitely going to we're absolutely not going to cover everything that I have here um but let's let's get in all right so talked about the super chain many a Time we are going to get into the weeds it's no fun allowed let's do this Li Jenkins okay so super chain to the rescue this is you know the statement blockchain is insufficient for the web why well meet congestion congestion is really our Bane the bane of my existence I will say that right now we have had high fees on L1 High fees on L2 it is over and over again this is the challenge so blockchains do not scale right look at all this I'm not spending a you know multiple dollars to send out a Tweet now notably I want to actually give a little rant here before I even talk about how this is not new information I think we really underappreciate how important it is to lower the price of transactions because okay it's one thing to have a one Cent per transaction at that scale you know you may even still need to you know have a wallet and and have you know a couple bucks of eth and and kind of get get through the day but when we get down to like 0.00 cents we start approaching a kind of limit of you know transaction cost that kind of resembles the cost of quote unquote transacting on the traditional web and that means that users don't need to worry about paying gas period because it's so cheap you might as well just you know pay the gas for your users or you know maybe you make an account and you get a free gas allocation every month or maybe you you know you various ways to pay to like kind of get rid of the gas paying experience and so that brings the blockchain out of the like purview of your of the end user and means that they can focus on actually doing the thing that they came here to do and not have to worry about wallets and all this kind of stuff I really think that we you know we're not quite there yet but we're starting to see a Kind of Perfect Storm of things like embedded wallets combined with the lower fees on you know on on l2s with 444 and all of these things come together to provide a user experience that's actually acceptable to on board large numbers of users now we're not there yet to be super clear the infrastructure is not there yet the applications are not there yet yet but we're like getting that like tiny little taste of what it could be to transact with a web 3 application and have it actually be a better experience than a web 2 application so anyway I just wanted to pause here because $13 is one thing even one cent is one thing but 0.00 you know some sense whole different story whole different ball game all right I told myself I was going to blaze through this presentation J three three slides in and three minutes in okay anyway but this anyway back to the regularly scheduled programming this is not new information you know the first response to the Bitcoin white paper was hey this thing doesn't scale like I love your idea it doesn't really work though and you know what they were right I mean you know bitcoin's done great things and ethereum's done great things but we're we're not there yet so it's been you know many many years and we're still not fully there but imagine if we were imagine if we were and we could use you know we weren't just trading dog coins and we were providing real value to users and everyone was happy and you know we we we created a developer platform that's serverless and composable and free to use and all these kinds of things like oh man I really want to be an application developer and not have to worry about like hosting and infrastructure costs because we've decoupled it sufficiently so that I can just Define the logic of my application and then users can go bring their own gas and you know play with it like all there's so many things that we're really going to get from building out this infrastructure we're just oh we're so close oh my god look the internet currently is a lockdown prison dying and it's going to become beautiful and vibrant and all this kind of stuff while the ocean goes the other direction anyway um no okay we'll fix that we'll fix that some some other day you know we will be able to build things like Twitter and world global scale applications okay how are we going to do this how are we going to have this amazing world well it's because of years upon years of research toil and incredible people joining the industry like y'all you know this has been a massive industrywide effort you know from the rooll of centric future all these kinds of things we're coming up with the abstractions the concepts that will allow us to go from being a you know monolithic slow hard tocale system to a modular well-run system and how do you do this you build the abstractions so that we can all work on this problem together and solve it in small chunks and then compose those chunks into one big glorious solution I love this quote things that are beautifully done like the web you know the web stack the networking stack uh uh uh normally come with really wellth thought out abstraction layers so we're getting there and thanks to all these amazing people it's coming in to to Vision Clear Vision congestion meet the super chain let's go all right we're all we go to we're getting there we're getting there anyway scaling okay so now some fundamentals just like real quick what is a super chain right scaling requires more than one chain why is that well you got this node you know it's fine things are chugging along but then you start increasing the block size until the blocks are so big that it causes a black hole and your computer explodes so you can't just increase the size of the blocks you need to do more so you need more than one chain but the problem is that multi-chain designs are often insufficient as well because often times they each come with their own security risk own validator set or deploying the chains is super expensive tons of tons of issues so we need a kind of system where the chains are commoditized it's trivial to spin up a new one you don't need to sync all of them at the same time and that is the super chain it's not monoch chain it's not multi-chain it's the super chain all right so right concept many different chains shared security model shared message passing and you know as we standardize the op chains we can get superpowers okay so governing the standard I'm actually going to Breeze through this section but the tldr is that you know optimism governance is governing the standard and they're all you know all the different chains are on shared security you can transact between all of them don't need to worry about where the tokens came from because you can you can trust that they all of the the proofs will have checked out you know Universal tooling so that I can deploy use my you know application Frameworks on one chain or many of the chains I can also you know all the shared block explorers and debuggers and in fact can even do things like kind of abstract away and start composing many different chains and deploy my application to all of these different chains like you know who likes having to deploy your smart contract on 30 different chains just to get it working on polygon or you know op man or whatever it's a pain I'd much rather have one thing that I can use and then boom it's deployed everywhere so you know at least for the standardized chains we can do this and start building orchestration software for applications like kind of like the kubernetes but super netes um so anyway and Cooperative Innovation right we're all working together on the shared standard and we can contribute back Upstream remember to Upstream your changes it's incredibly important and that is the beauty of Open Source and guess what with retrop pgf retroactive public goods funding you'll get rewarded as well for your contributions so we can create this virtuous cycle and fund open- Source software all right so we're making public goods sustainable and decentral ized okay so that is that's where we're that's where we're headed that's where we're headed um Windows XP I don't know I love Windows XP um okay super chain derivation so here I'm going to go through two of the concepts because we don't have a lot of time and I've already burned through a majority of the time that I was planning to take so the two concepts I'm going to go through today are derivation and cross-chain message passing interoperability so these are the two most fundamental I would say so derivation what is derivation derivation is the process by which you generate the layer 2 Chain from the layer one data what does this mean this is this is basically how all the rollups work and absolutely how all the op stack rollups work so we got ethereum we derive op main net or maybe red chain let's call it red chain and you know Alice wants to send a transaction she sends it over to you know ethereum L1 maybe deposit and then boom the derivation function is called and we derive the red chain so this is really saying that ethereum defines where all of the transactions and all their or the ordering and then we derive what the chain is through that data all right so then you know progress along and Alice instead of submitting it directly submits the transaction to a sequencer sequencer kind of relays it on her behalf and boom the D deration function kicks in again and now we have got that transaction so pretty simple not too bad let's just test our intuitions a bit very important myth the sequencer can forge transactions all right we'll see let's see so Alice sends the sequencer assigned transaction is the sequencer going to be able to forge it well let's see so sequencer changes the recipient to themselves they're like Alice you thought you were sending to Bob nope you're sending to me now all right so now the transaction has an invalid signature okay so we that's why it's red it's an invalid signature now when I call the derivation function what happens to that transaction well I check the signature of that transaction I'm like that does not check out that's the that that transaction is some garbage and I throw it away and it does not ever get included in the red chain what does that mean well that means that myth busted the sequencer cannot Forge transactions because all of the transaction data is posted to L1 and everyone who wants to derive the L2 chain can detect that there was something wrong and throw away the transaction that was forged by the sequencer so important concept sequencer cannot Forge transactions now let's talk about kind of connect that to the super chain well this is the derivation function for red chain but the derivation function changes depending on what chain you are deriving so blue chain might have a different derivation function instead of reading all of the transactions submitted by the you know op main net sequencer maybe that it's reading all the transactions submitted by the Bas sequencer or the Zora sequencer and so we've got you know blue and purple chain all the different sequencers submitting their respective transactions and Alice can choose to derive whichever chain she wants she syncs a node she wants to sync the red chain node boom she syncs the red chain node she wants to sync the blue chain node boom she syns the blue chain node so this is actually hat while to scales right we're taking this one big list of data but we're deriving different chains from it and that means that Alice can run each chain in a different computer parallelize it she can choose to not run some of the chains all of these things this allows us to get around that bottleneck I mentioned before where the blocks got too big and Alice's computer exploded because there was too much to do so that's how we kind of get rid of it but that's just that's like normal that's status quo but let's turn it into a super chain let's derive infinite chains okay so instead of defining the derivation function as just the L1 and having a special one for every chain we can actually Define the derivation function as having two inputs one the chain configuration and two the L1 chain so that means that based on your config you now have a different chain and so however many configs you have we have different L2 chains all right so this gives us access to a practically infinite number of chains and of course you know standard Bridges and standard addresses are important so you know pink config we get that chain blue config green config all the configs right that's kind of how it is so you can kind of think of it as like a kaleidoscope you're like looking into the kaleidoscope and you're like whoa so many chains okay anyway that was the Super sorry that was that you know that's that's that's how we derive as many chains as we want to derive so that kind of gives us infinite compute now notably in this talk I'm not going to tell you about how we get infinite data but if you notice there's a bottleneck on ethereum L1 with data we're we solve that with 4 for four and ALT da but you know we only have so much time we're only going to solve some of the problems today so cross chain messaging okay so these chains they're all independent but how do we solve them communicating with each other because it's not going to be super useful if you can't bridge between them or you can't deploy applications that share State between different chains so what is let's talk about the fundamentals Alice and Bob they want to send some messages to each other Alice writes a message she has a two and a message and a proof Mo the mail person Gra grabs the message and brings it to Bob okay so that is you know that's messaging pretty pretty simple in the physical world well what if I told you that they were chains they were actually chains all along so Mo the mail person is actually really migrating their tokens sends a transaction to the Alice chain the Alice chain then emits an event for example and then Mo takes that event and all the proof data and FES that along to the Bob chain Bob chain verifies the two message and Pro proof and executes the transaction so that is essentially that's the core concept of cross-chain messaging pretty simple pretty simple that's the interoperability stuff no no problem so you know they can talk to each other now it's easy to do the two in the message that's just information in the message the proof is really hard proof is annoying oh my God we've been working on proofs for years so how do we verify the authenticity of message while preserving decentralization cryptoeconomic you know security Etc well let's let's actually just you know go over the fundamental fundamentals around how the proof works well the way the proof works is actually the same as the derivation that I was talking about before that's why I provided that context because it is actually very useful context so we're trying to verify a message of red chain on the blue chain now the blue chain knows the red chain configuration and has access to the ethereum L1 data they have the access to the you know the the latest block hash for example and so the blue chain actually knows how to derive the red chain from all of the data that it has access to locally so the blue chain can actually run that derivation process that we saw and verify the authenticity of the message now you might notice a problem if I say that that is the only way that the blue chain can verify the message then they're going to all you know all the chains are going to fully verify other it'll kind of collapse into a a single basically a single Mega chain so this is why proof systems they take a bunch of data that it takes to verify and basically make it compress it into a much smaller amount of data right ZK proofs turn a linear sized amount of data into a logarithmically sized verification problem so different types of proofs they all serve that similar purpose all right so this is a little bit I'm you know I'm sorry this is well it's a good thing it's a new some some new slides but there's a bad thing it's less pretty and less beautiful so we're going to change gears into some more work and progress slides but we can appreciate this very beautiful little JBL or hamsters all right so I'm going to talk a little bit more in the weeds than before about some of the introp specs which you can look at you can look at them today and in fact please provide feedback so okay here are some Core Concepts for some of the interop specifications first cross-chain reads we're going to talk about chain dependencies and the proof system for this thing so this is essentially how we go from the cross-chain messaging as a highle concept that I was just talking about into some more you know tangible details okay for cross-chain reads what is the specific uh you know what are we reading well we're reading events this is events from from other chains we can now read those events why events well there're very there already a lot of tooling that exists around events pretty pretty simple also events are extremely easy to look up and also extremely easy to expire they they all come in a kind of orderly list we can take the fir you know the latest day of events or or week of events or month of events and then expire the rest so this is you know a nice property versus the infinite State growth grow and so then once we once we can read the events so I'm on a chain I can now read the events of another chain once we have that primitive then we can build out things like message passing on top of that two not only read an event but do things like replay protection or general replayability nice features that you would want on a message passing protocol so think of it as like UDP and TCP built on top so you know you build out the message passing the TCP style thing on top of that and we've got the proof system I'll just note here right got to make it so that the proof system supports this same block event reading which is very nice right eventually we'll get to Atomic cross chain transactions but it'll take some time and the sequencers are not going to support that for for quite some time so that's the just cross-chain reads pretty simple not too bad cross-chain dependencies or chain dependencies what are these dependent chains well chains can read at low Lany these events from other chains that are in their dependency set so what does this mean what is a dependency set we're we're kind of like adding a new primitive and I it's it's it's a kind of cool thing adding a new primitive to a chain to to what a chain is that it can depend on other chains so what are these dependencies they're uni unidirectional that means that I can spin up a chain that's you know that reads from multiple different chains maybe I read from 30 different Chains It's not a problem very easy then but it may also be hard because now I have to make sure that I run 30 different chains noes like all these kinds of things also dependencies are of course transitive chain a chain B and chain C if chain B depends on chain C then if chain a depends on chain B then chain a will also depend on chain C right you're you know you kind of like inherit all of the dependencies and of course two-way dependencies that's how you kind of enable asset bridging so if chain a depends on chain B chain B depends on chain a then you can Bridge asset between them and so you can form like little like either clusters or all of these things for low Lancy like really low Lancy now to kind of go into that a tiny bit basically the high Lany bridging that's achievable with normal proofs for reasons that I won't go into in this moment we can get even lower Lany for example like same block uh messages if we have this kind of abstraction of chain dependencies all right so yes expect a core cluster two-way dependent chains nice and importantly syncing a chain I'm syncing you know chain a it requires a client for all of the dependent chains or a light client for all of the dependent chains so this is actually how you can kind of get into things like crypto uh you know uh secure like clients with either offchain fault proofs or zero knowledge proofs so you have you can have guarantees around your about your you know cross chain messaging and this this is this is actually how you kind of by the way oh yeah another concept it's just in general people are always like oh it's an OP you know the op stack it's all about optimistic rollups yes we like optimism as a concept high level but it's not just about optimistic rollups we're going to you know we have to use ZK and so this is a really clean way for us to integrate it in it's used to secure the light clients for these dependent chains and as we you know scale up we can secure more all right now let's talk about the proof system amazing so proof stack pretty much the same built out the system to be pretty modular so that we only need to change for example like the op program the proof program to support this kind of new structure and new way to read messages from each other so you know you you kind of like think of it the change in the the program is you split it up into two steps first we right now we only have this like execute step but but what we can do is we can do the execute step first for all of the blocks and then we have a resolve step that just resolves all of those cross-chain messages relatively simple and so this is the you know nice little modification so the way that it works right we've got two chains I mean and we've got two messages one in each chain we have a little resolve dependency step check the dependencies and move forward so now we have done three things we can read events from op chain Get Low Lane C reads for you know like fully Atomic for the chain dependencies and we can prove the authenticity of all this stuff with a nice modified proof system did I say a proof system a proof stack well in fact we deployed on testet the fall proof system uh which you can play with today in fact I have been really enjoying it there's a little secret if you go on ether scan and you kind of like dig around you can submit it's fully permissionless so you can submit invalid proposals no problem and Through The Ether scan UI is very easy and then you can watch yourself in real time get challenged and then you can attempt to challenge back of course you know be careful you'll lose your bonds um unless you found a bug which would be sick um so anyway I recommend trying it out I was gonna think I was like I could have done a live demo but I don't have my laptop um but yeah I just keep getting challenged it's rough all right well we've got five minutes I'm going to transition back you know we we had a great time with the uh the hamsters very happy and then uh now I'll transition back Switching gears back to the presentation we've got infinite chains now we've got change meage chain message passing and so we're going to do the rest of this presentation in one minute so I still have a couple minutes for questions well what are we going to do the messages are asynchronous so we introduce decentralized shared sequencing boom and now we just get to watch and just feel the atomicity coming up oh my gosh look at that atomicity through shared sequencing and all these things that are synchronized okay and then the last concept is data availability remember I mentioned it before we've got infinite chains we've got a data bottle like what am I going to do well EIP 444 and plasma for alt da so we can standardize how alt da gets plugged in and infinite chains meet infinite data and there's a catch of course you know Alda isn't as secure as normal data but but we've got data availability challenges and yes there's no Fisherman's dilemma problem here y'all don't worry don't worry we we know our we know our classic metallic posts um rollups plasmas you know pretty pretty chill so yeah we've got we've got the full the full thing we've got infinite chains we've got in Cross chain messaging we've got synchronization between them and infinite data we got the super chain that's just coming it's so close and there's congestion p we knocked it out look at that we we achieved our goals and to infinity and beyond you know we're going to create this beautiful open- Source ecosystem and summon ether's Phoenix to fund public goods and coordinate the world around an open source and decentralized internet that benefits human beings because that's because the impending super intelligence will kill us otherwise so save this save the race and scale ethereum thank you very much [Applause] much we got like a couple minutes for questions any questions y'all yeah so the question basically about the ization time of optimism chain uh so the block penalization takes the challenge takes up to 7 Days right so how we can trust the proof coming from one chain to another chain verifying it if it can have invid stat truth because the pro pro proof didn't come yet to to ethereum main chain so can happen valid state so how that kind of brings uh the fast transaction cross chain if the finalization time is s days nice nice so this is this is kind of where the chain dependency stuff comes in I like to think of it as there are like two things here that happen there's subjective finality and objective finality it takes seven days to get to kind of quote unquote objective finality where the you know the fallproof finishes and everyone knows what uh the state is going to be but for that seven days it is possible to for to predict what the trans what the chain state is going to be and so you can similar to how the the sequencer can give a kind of optimistic confirmation of a transaction before it lands on L1 similarly we can basically predict what the chain state is going to be before the fault proof resolves now notably it's important that the proof system does resolve as we would expect and so if you do you know have this property where you you know are dependent on a chain and you wait a full seven days for it to kind of come to full objective finality then you need to make sure that neither one of those chains finalizes incorrectly so this is this is why the chains become in some sense intertwined but this is actually more of a sliding scale than we normally think because we could for example have a multi- prooof where we have a zero knowledge proof that we get in low latency but then a fault proof which we get in high latency and we've only resolved the zero knowledge proof to to kind of get the Get Low Lany message passing but we haven't had the fault proof resolve and so there's actually like weird hybrid solutions that I could get into but um but it's a great question and this is like you know my best attempt at a 30- second response any more questions yes is it possible to transfer nft between super chance nice yes with cross-chain messaging that's absolutely possible the the whole point is that it's really about authenticating secure messages and those messages can be for example I burn an nft here and please mint it over here and then on the destination chain it mints because because it verified the burn event thank you we got the questions coming let's go the juices are flowing can the proof system for the multi uh multi between the op stack also work for like other optimistic like Arron so this proof system can be like IPC for eum or is special for do stack nice so okay I'll tell you what what we're hoping to do is create a kind of like Universal interoperability protocol that allows you to kind of program with all of the different interop you know either all the different chains that you're using or the different kind of like uh proof systems that you might use to communicate between those chains but but there are going to be differences in that like for example as an application developer it's going to be a lot easier to for example deploy my application to the same same kind of block space uh versus supporting many different kinds of block space but it is 100% a goal to like zoom out to a sufficient angle where we can kind of cover all of the different types of chains types of proof systems and uh you know third party Bridges and all this kind of stuff one one last question uh okay you had your hand up first I want to make sure that we get that question I'm so sorry um so since the super chain would require like uh a single agreed upon standardization like you think we might see chains previously part of the super chain that disagree and then Fork to create their own standardization versions and how might that be handled in the future nice so this is this is also related to the last question around like does interoperability work for non hom homogeneous chains so there are two things one of course we're going to make sure that migration paths are as painless as possible it's there are some fundamental issues with migrating like it's not always going to be easy depending on what change you made so that is one thing so going from non-standard to standard make sure that happens however the second thing is if you are for whatever reason stuck on a non-standard chain we can't leave you out we got to make sure that there's at least some interoperability features that you can benefit from now notably it may be the case that things like for example super low latency message passing don't work in that context but you get you know some level of low lency just a little bit higher you know things like that and and of course we'll have to solve it later on cool thank you thank you for the wonderful presentation call let's give it round thank