Pluggable data availability | Optimism Summit 🔴✨ The Future of Ethereum - Protolambda

foreign [Applause] [Music] up next uh we're gonna have Proto come on and chat about uh plugable data availability we're really excited to have uh the king of the pineapples here uh so Proto when you're ready uh feel free to uh you know turn on your video unmute yourself and uh share your screen all right let's let's get started sorry for the delay so um my presentation is about applicable data availability um this optimism where both stewarding layer one developments of increases in depth of credibility as well as building the technology that uses data variability called rollups and so I'm going to expand on uh fight for fire also called prototank shorting that's me and with LP lab sphere building this world technology and building towards the network release which uses this data found a better team so let's just talk about data fatability layer 2 usage word for far and then some layer 3 design at the ends you can click and play and build something new so what is data fatability really that's availability is this primary scaling column lack of ethereum over time the sharding roadmap of ethereum has changed a lot early on sharding looked like this thing where we had many many different charts and they would all have data as well as execution over time we realized that having so many shirts would create communication problems if you also try to solve the execution problem and so instead of trying to solve everything at once we have this realization where the on there one we can just focus on data securing data and enabling layer twos to create this like competitive environment their the execution layer if essentially is out of protocol but secured by level so how does this work the inputs to the functions are secured by their own the outputs are there to concern and so let me get from securing the inputs is this permissionless ability to reconstruct States and this allows any honors Factor on the layer 2 to compute other light States and then contrast what the layer to Output is on layer one and then secured layer 2. so a rollup is really just discrimination of data availability and this execution check the thing that secures the withdrawals going back from Layer Two to layer one we have sphere various different types of exclusion checks they're also called validity proofs or fault proofs or previously thought proofs so if the sequencer makes a mistake or if there's a malicious sequencer they might post the wrong outputs they might post a state that's not actually valid and then you have to prove them wrong on layer one to secure the layer 2 outputs secure withdrawals secret rollups of validity proof where you prove the secret technology that the robot performed a certain State position given their own inputs optimistic rollups they defer the the proof and basically only when the there's contention in the pessimistic case then you you play this interactive game on layer one to prove or disprove the outputs so with Layer Two we already needs this data availability for other honest actors in the network to reconstruct the state reconstructing the state is very easy if the state was only ever changing like once per month very very slowly and everybody agreed on this list but the challenges is that layer 2 is quickly changing Neutron sectors are being confirmed every second and so all this data that's changing needs to be made available in a permissionless way where we do not rely on the sequencer and this is what layer 1 offers this is data availability hosting data that's changing and that is uh cannot be relied on from just one actor from the sequencer that should be available to everybody so if you think about modular book science there's this narrative coming along we're taking apart the stack and you see this on their one with the separation of consensus and exclusion and other blockchains this enables us to encapsulate complexity and to enable scaling so abstractly this looks like we have a data provider and this layer 2 for their face and execution this is the simplified version a little bit more complicated is the reality so we have deposits going or like layer one messages that change layer 2 States from layer on to Layer Two and under is this refers we have proposal transactions which you can think of as an oracle to State what the layer to state is and to enable withdrawals so we have both data communication as well as this communication for liveness and for this messaging across layers and then the layer 2 is designed the same way as layer one the consensus layer and an execution layer and so if you think about there to stay transition function it's really just a process of incorporating more layer one data to extend to layer too and then we can prove those there are two outputs on layer one and so often I see confusion about the proof of stake finalization and the Roll-Up finalization before we approve stake we used to use finalized for layer 2 data that is proof that is proven on layer one without a third proof of Stack we also have this notion of finalized data on layer one so if you think about a roll up as a function that consumes inputs rather than the function is not going to reverbs if the inputs are not going to reverbs and so when the inputs are confirmed in layer 1 then the layer 2 can also be finalized but it will take some more time for the layer 2 to also be secured on there one for withdrawals this is the slide client type of thing the the Oracle I was talking about to enable returns they're separate things and we're focusing here on just fantization of data because we're talking about data availability uh securing that was that is confirmed I'll give you a little bit more technical fuel so there have been running testnets of the next petrol prepared here's an example of a test net with two replicas and one sequencer and then what we're tricking here over time over to spend three hours is the traversal of the layer button these are these color attaches and every color Terrace is a different layer one block and then a little bit down the graph you also see the layer 2 Chain being traversed and the layer 1 references of the layer 2 Chain being traversed and so over time we consume new data and I'll talk more about this data availability as we're consuming more data we basically needs more capacity to host more users and so how do we get more capacity we need to scale the layer on data availability the starting roadmap has been split up into incremental phases this has been done before and now for the latest starting map we have this idea of dunk sharding based on bank cards from the affirm Foundation uh basically championing this ID of data availability sampling very good distribute data more nicely between many many different network nodes for um the short term we do want data in and data increase that we are not there yet with the network layer on layer one to host a thousand times increase in data like that or not ready for data availability sampling yet but we are ready for our smaller increase and so this is what for it for first about is to make this future compatible increase in data availability going from the approximate 50 to 100 gigabytes data consumed per per block now today to somewhere closer to a megabytes to two megabytes per block of data for rollups to consume and so this is what it will look like for it for far with the consensus layer execution layer and then we have this new data layer essentially attached to the layer on where we were hosting these blobs and these blobs they function as inputs to host the layer 2 evm activity life cycle of a blob or this piece of data that's Layer Two transactions are confirmed are in is like this where we have the user creating a transaction the rollup operator building the transaction delay run transactions tool basically propagating the transaction until it can get confirmed and then the they are wrong confirming the bundle of Layer Two transactions as this this blob of layer 2 contents they think of this as a sidecar it's something outside of the regular beacon block it syncs separately it looks this condition where we ensure that the data is available along with the beacon block itself and then the excretion payloads of the beacon chain stays in there one that blobs they are prunes after have been available for a sufficient amount of time for layer 2 to secure their Network and then it's up to the layer two to persist the the historical states which like basically only change this month per month um for other layer 2 users to sync from and so how do we adopt this kind of new more scalable type of data we have this uh this their facing pipeline which transforms the layer 1 inputs into layer 2 outputs into the layer 2 blocks as they are processed by the exclusion engine there are different stages that we designed as part of the battery upgrades to modularize this this transformation and so traversal retrieval and deposit processing they're all separate processes and we can swap out the data retrieval process for one that supports the new Erp with East Berlin they've been doing exactly this the second term of just like a week ago or so the uh built a prototype where we took optimism data or adopt Mr Roland and implemented the changes necessary to use the 484 data and so prism we extended with a retrieval API to fetch the blobs Gaff now combines 444 and layer 2 divs so you can use all the new changes in the same code base and on the op nodes the derive data from the blocks and submits new blocks that are being built by the sequencer the um we have a fellow there are two deployments that looks like this we have a layer on Beacon notes layer one excretion engine and there are two roll up nodes and there are two execution engine you can see the similarities here where they both mentioned API the separation of consensus and exclusion and then there are these helper modules that make the data the inputs and the outputs available to the higher layer and we can take this and you can stack it so you could think of the layer three that is basically just the same software as we run for Layer Two except stacks on top of the layer 2 instead of the layer one so this is like a felt experiment where what if we just reuse the same chords to build a layer 3 and to get to make things even more scalable now what you see here is that this only really works if the blobs the the things that host data um in layer 3 are not build up all the way to layer one but rather hosted by this layer 2 with a more even more scalable data layer and so it could adopt erp4 for only R2 to host of layer 3 but it would also mean that you'd have to build this alternative even more scalable data layer and then well how does this compare to plasma or how does this compare to the this these skating solutions that host their own data well you could separate it from the layer tumor where now you have the separate data module to fetch the layer three data from it's less equivalent to what you would like to see from layer 1 technology but it also does the same job and you can still stack the road notes the proposer the execution engine so all this software is the same it then holds the data answer and so I've been experimenting with these different types of ways like to further scale what we now know as a roll-up but then in the future that's like this this modular system that you can reconfigure to become a layer 3 or plasma or so on and uh this is what applicable that fability is but once you have this stack of marginals you can configure it the way you like and then build cheaper better Solutions based on type of applications you want to ask um if you want to learn more about Bedrock the modular stack we're building and the the upgrades really of optimism you can find this on betroop.optimism.ir we also have a live test net you could use and then there is Erp for it for fern this layer on scaling efforts which you can contribute to which you can read more about on the ap4.com and contribute to get up or in desktops any questions thank you Proto uh just check in the chat to see if there's anything that's come through uh it doesn't look like it's so far uh might be worth uh just you know as we're gonna jump into a a panel about 4844 following us directly um I don't know maybe if it makes sense to maybe chat a little bit more just as a sort of a preamble to that panel um about you know 4844 what it's going to maybe enable and also just sort of like any other thing you think that's relevant to know ahead of that panel uh with Tim and the rest of the team all right [Music] the first before but we're introducing is this this different type of data I think the context that many people may be lacking is how Roll-Ups today are hosted and how this compares to roll ups in the future will be hosted today we're using call data which is this type of data that passes through the ifm and was never designed to be used in this way it was designed to be used as an input for a smart contract and then it happened to be hijacked in some way for Roll-Ups to hosts and make their data available in the end this just means that this type of data does a lot more and it's a lot harder to maintain the the type of data that we really need and so what we're trying to design is the type of data that can be hosted and available without being unsustainable without growing the environments the current evm on layer 1 and all the inputs is this inbounded type of graph where the states the history and so on is not sustainable to maintain long term only when you can prune or reduce the strength then this this thing is sustainable to the host on regular Hardware and so with Layer Two we're trying to find this balance where we're securing the there too but we're not creating this unsustainable uh resource research on layer one and so by redesigning this type of data fatability big McLaren a lot more sustainable you can secure there too at lower costs and so they can increase capacity for users as well gotcha awesome uh yeah I mean that's good that's good context um especially to know that like right now I think the most important takeaway there is that you know the chain isn't really set up to do a good job of Hosting that data right now and it's being you know almost kind of hacked in um and really kind of the principle behind those changes that you know actually doing it the right way versus uh the kind of like other way um maybe a quick question while I have you from the chat that came through a bit of a roll-up 101 question from Abhishek um just a question around data availability he says I understand that Roll-Ups make a state route commitment to the main net then where's the actual data of the smart contract stored if it's a roll-up chain is it completely down um well if it's on roll up I basically is it completely on the roll-up chain and if so how do I access that data all right so I think I should introduce this notion of blockchain State versus blockchain data history but you could think of as a blockchain it's just a sequence of transactions that has to be available or accessible to people to reproduce a certain State and so there too makes this sequence of transactions available by building them compressing them and submitting them to this layer one which can host them with higher security guarantees and then it's up to the users to read all flare one and then reconstruct the state and then as you reconstruct States you can find your Layer Two balances your Layer Two interactions everything you might need a layer two and then then you want to withdraw from there to all you really have to do from here is to make the layer 2 outputs the state roots visible on layer one and there one in like a regular note does not not have its own view of these things happening outside of the evm and so rather than what happens in a full nodes where you can run this layer to function to compute the layer two states you need to prove the state with a light clients the slide client is essentially a smart contract on layer one that can tell you the correct state of layer 2.

to be used by other level contracts that can then process things like withdrawals the layer 2 States can be proven in several different ways this is the differences I talked about at the start of my presentation with uh zika Roll-Ups optimistic rollups and because optimistic rollups what we do is we always post the layer 2 output that only when somebody disagrees with the output then we built this game where a temperature and the original poster of the output can battle outs and will boost the posting the right output and who's posting the room claim or output and so you can secure the the claims of layer 2 output to always be correct and to those secure the Oracle and then secure the withdrawals gotcha okay awesome well thank you so much Proto I think we're going to go to a brief break while we set up the panel for the state of 4844 but uh yeah thank you for your time Frodo um and uh it's always great to have you on on eth global.tv