#DappCon22: Day 1 - Optimism Bedrock On EIP-4844, Protolambda

Transcript

this layer execution layer and other research teams he's going to be talking about layer 2 scaling and more specifically about optimism Bedrock on Erp 4844 welcome Proto we have the slides thank you hello everyone it's good to be here um you know looking back at previous and depcon Editions we went through this this cycles of skating and uh well now we're at the point where proof of stake is just a few days away and we can look at the sharding in a serious form and before sharding

we want to be more iterative and that's what the year before it refers about and Bedrock is like the the merge for optimism we're adopting the same kind of architecture we're going to the very bleeding edge of layer 2 attack and you'll see how that works together [Music] so I'm Proto I work at oplabs work on the technology behind optimism and this talk dives into Data availability modular blockchains just introduction another other talk which I highly recommend from unscar about modular book Sign and then there is eap44 the killer solution to increase the data for

overlaps then Bank starting this is the next phase of the EIP and then we have bedrock and if you combine everything you've got something beautiful so what's data availability data availability is all about hosting the inputs making sure that everybody can permissionlessly reconstruct the state so whatever the layer 2 design looks like if it's ZK or optimistic you are able to reproduce the outputs in a permissionless way to be able to challenge or contrast what's happening and so data availability is this part of the equation the other part is the execution check this is what makes rollups unique we have zika Roll-Ups with validity proofs and then we have

various kinds of optimistic rollups and then the one with the interactive game seems to be winning where every optimistic rollup is adopting this technology to bisect the execution trace and to allow for more flexibility and more more than just a specific VM set where the zika Roll-Ups are focused on right now but this more General thing where you can put all of Gaff into the proof and show that it's produces certain outputs and so with that availability there's this difference between forever available and once available but we need to be able to reconstruct the states or to challenge the the

sequencer like the the primary producer of the rollup we need to have permissions access to data that changes very very frequently it's not like a a storage thing where if you get it today later it's fine you want to have this all these changes that are coming right at your fingertips to be able to challenge whoever operates the roll up and so this is a stronger guarantee than just storage and so if we can guarantee this shorter time frame with a very high quality with ethereum layer one Comic Con sensors to the data then we can make the layer 2 a lot more secure while still increasing the data

by a lot and so this is about modular blockchains right where we are taking the thing apart so we can solve the complexity issues in each component and add this type of scaling that we need for larger adoption so this is where we are today this is going to be very soon very much a legacy Rufus Lake is happening um we have this ancient API that splits the bigger nodes the consensus layer and the execution layer and by doing so we get to keep of the ethereum one States transactions it'll be almost seamless to go through the

merge but then we can add this proof of stay components we can add a separate consensus layer that builds the chain that commands this is the new block this is the new block whereas the execution is just focused on the user experience that everybody's used to there's the big notes it's like this new consensus and so you split the two we go from this monolithic thing to a little bit more modular but it can be way more modular right we can add the data layer we can add more execution layers or more execution engines and this is what we are looking at with Layer Two to use the same kind of architecture do not break ethereum to stay very equivalent

but to not like re-invent everything either we want this execution engine to be shared with layermon so we have the they're one source of the data and then the layer two where we pull in the data and they push back the transactions and this will become more clearer once you start to talk about Bedrock Bedrock adopts this design but I'll dive into the scanning part first and like how we got data on ethereum so this is today very inefficient we hook an EPM to an evm we don't get much scaling Beyond just hijacking call data for like a little bit cheaper availability and I'm pushing all the execution costs

to there too I can do better than this so what we need is a data provider and then Layer Two execution hook to that so who came to call data anymore we're looking to specialized modular data and this is what the computation looks like they're doing the same thing except they don't have this this beautiful ecosystem of defy and everything else on the layer one ethium and you don't have both the Donald to break ethereum we want to add to ethereum and so this is what the epipher for us about it's the first step to dunk sharding and the meme as well prothod and sharding we'll get there also shout out to many other people it's not just us the

people working on the cryptography on definite development on specifications and I'm sure a lot many more people that I'm forgetting about shout out to the whole crowd backing this EIP and then we have uh discrimination of layer 1 evm and this new thing layer 1 availability we're adding this to the consensus layer of layer one and then now we can attach many more if you have as many more capacity from Layer Two to layer mount better data availability and so this is the life cycle of a transaction that adds data to layer one

it starts with Layer Two we bundle it up we compress it whatever we need to do to basically pack it up for their run availability they put it in the layer one transaction pool the transaction gets confirmed by gas but then the data as a sidecar is moved to the beacon chain it doesn't stay with graph it doesn't affect the evm the evm is just execution blob data as a consensus task and then we retain it in the consensus layer for long enough to secure the layer 2 usage so like approximately a month perhaps and then afterwards the Air 2 should

persistent it's their job to host their own historical data but it's the job of layer one to provide a security layer that layer 2's needs for this this challenging game against the sequencer and this is what the life cycle looks like I think the previous slide is clearer about this where we're going from Layer Two from the sequencer that produces data through layer one and then back into the layer 2 verifier that reads the data I'll make these slides available so you can have a closer look and then what's the blood transaction about we have ap1559 it's like the regular transaction type we add this little Fields called the the version Fashions these are these references to

blobs to commit to the data but then the data is kept separate as a sidecar and moved into this new consensus layer this is what the actual transaction type looks like it gets a little bit technical but it does have the these arrows these commitments to make sure that everything is consistent and that the things that live on the consensus layer and things that the execution there match and then um yeah like we have blobs as a sidecar it's not part of the evm state sync so you can sync your GIF node independent of the consensus layer and as long term this enables us to go for full dunk sharding Phil dunk sharding is

this process where not every node has to host all the data which is that we use sampling to split these the data it's this little extension to the engine API to make sure the sidecar data makes its way into the beacon chain it's almost trivial the hard part here is the transaction type and the transaction pool and then we can think about rollup integration again this gets a little bit into the needs uh that we thought about zika proofs as well as optimistic proofs and designing this EAP how do we get to a point where the data can be verified to be available be used efficiently as part of this validity proof or fraud proof

the zika proof is a little bit complicated so you can General is complicated but what happens is that we're doing this proof equivalence where we have the data commitments and then we have the CK specific data commitment of the choice of the layer two we show that they're equivalent and then you can do the the remaining part with the secret proof to show that we are going from one previous state that's already confirmed on layer one to a new state that introduces certain new imported data and so this is the second part where we check the validity proof and importance and change the state similarly interactive throat proofs they have this Oracle or this this introduction of pre-images to go from

the previous state to the new state with new transactions applied and what they do during the Oracle we use the pre-compile that shows just a little part of the data and the bisection game allows you to just have to prove One Step so you don't have to show up with all the data on layer one you only have to show up with the little part of the data that was involved in the contested execution step so what's the full tank sharing once we have the separation we can go even larger we want to make the data available but we don't put every node to host all the data so what we need for this is that availability sampling

and this is this random poking around to make sure that other nodes also have the data and a very clever design um making data redundant enough that if you are making these random queries the chances are extremely high that you can ensure that the node actually does have the data and then in Aggregates if every validator is doing this and we come to the two-thirds consensus but around the data then we can make sure that we follow a chain where all the data is in fact available without actually forcing all the validators to host all the copy all the data and nice thing about this is that we don't require any changes to here before it fur on the execution engine it's just

going to be a big container upgrade at this point to go even larger and then you can do this immense availability throughput number which is already an increase open for a prefer so we're talking about somewhere between the order of 100 times 2 000 times compared to what we have today making layer 2's a lot more useful you get even more of this evm bubbles on there too and we can host a lot more of their diet so what's the development status here I've keep I kept updating this slide over different conferences we are making good progress with breakout calls specification improvements hackathons workshops and then at Eve Berlin we're

also going to experiment so keep your eyes out for that or join us if you are attacked on um this is the work that's going on we have specifications prototypes API specifications more specifications for the cryptography that's involved and then we have a Death Note up and running we have some simplified fee structure the next task is to evolve this death nuts to the the next version of the specification that properly implements the fee structure for these blocked transactions okay so how are we going to fit a roll up on 4844 in practice well the current rollup technology is not sufficient but

we are getting there to appearance where it's so much learned that we can swap our data very very easily and so what network does is it adopts the merge architecture and then we're able to support snapsync we're able to support block propagation we're able to support a fully equivalent execution environment so equivalent that we're you don't have to change anything about graph except the option to insert deposits from layer 1 into layer 2. and well the deposit transaction type itself of course and so we use the standard typing for the deposits and we have this improved book derivation function where we can guarantee make hard guarantees about the

organizations of layer 1 forcing reorganization there too we can force the deposits to become to get processed by the layer 2 Chain within certain time frames and so we limit the the sequencer in such a way that we can guarantee safety for users and today many Roll-Ups they have poor support for viewworks or like they have a very large confirmation depth and they don't do this proper blog propagation Bedrock will solve these problems and we will get to a much faster form of thinking by adopting layer one Tech we don't have to duplicate or like make

these conflicting implementations of different things we can share this technology and then improve it together so this is what it looks like we have the beacon chain execution chain GAF or other if one clients I think nethermind also has stocks during this conference hope to hear more about the skating on later on as well and then we have the op nodes that proxies data to the layer 2 execution engine and I'm saying proxy because the lp node doesn't have a database it's literally just following layer 1 data and layer 1 consensus to keep the layer 2 in sync and then

this way we don't have to make many changes to gov and so we have the backbone essentially the layer one this is the the thing with most security with most availability everything right the nft layer 2 where in happy case you can sync much much faster you can get two second blocks you can get a more gas per second and uh yeah this is what a modular blockchain stack looks like or the beginning of it and then we have a data provider separate from the execution on layer one and naming the rollup nodes to both scale the data as well as

process the deposits and interact with the ecosystem of layer one with the D5 ecosystem you want the Best of Both Worlds you don't want to separate the data into like some third-party platform we got the bow from larimong and then we have the engine API just like we have on layer one on layer 2 to appletic F note so we have a dust nuts it's just up and running very experimental but very fun during the hackathon to play with it serves all the regular things you are expect from the evm chain very latest version of gaff literally just rebased a few days ago and you can you can play with it and see the two

second block time get the hang of like the larger throughputs better compression and check if anything breaks they are trying to do more of this partner testing to make sure that our Integrations work as expected before we go live and so how does it look like if we combine these Technologies we take for it for Fern and we take the Bedrock and we only really have to change this yellow bubble the layer on retrieval all the other parts of network stay the same it's very modular you don't have to change this monolithic thing and so the real transactions on the urban are replace the blob transactions

and network otherwise just works the exact same so this is what the op stack is about flexible data fatability flexible proof system flexible execution engine we can eventually support zika proofs we can change the engine to some other thing maybe move or whatever else you want to run to sports and data availability is the first Target to be able to scale further than just let's call data Sports and that's what it looks like we have different modules for the sequencer side to be able to submit data and to submit output routes or these are called proposals or state routes to be able to

withdraw from the layer 2 back into the layer one and the key part here is that the batching is separate completely separate from proposing so you get to be able to host your data elsewhere and then combine it to fix pigmentation benchmarking sync tests maybe Cassidy ceremony integration and this is the bleeding edge of layer 2 scaling where we get scale and we got ethereum equivalent execution with higher throughputs so check out if you want to check bedrock batroc.optimism.ir if you want to check out the Erp it's um it has its own websites with the introduction there are more resources

for developers also linked in the website also in the heckmd and then you can find us on Discord and you can find Erp work on the r d discords and we can scale ethereum together during the if billion hackathon [Applause] any questions hey how's it going um I have a question around custody games or you know serving this blob data

or for a layer one validator other than in the block they have you know commitments to the blobs do they have any obligation to serve the blob data like going forward for the month or anything like it so we are talked about there's that availability where we have different time skills of short-term availability and long-term availability the trickiest part here is the difference between finalization and non-fertilized data once you have sampling or once you have a proof custody you can definitely rework away from unavailable data as long as you have not finalized the layer two chain past finality it's a different story you cannot rework away anymore but what you can do is make the finality guarantee so

strong that you know that so many actors on a network did see the data that there's no way to really get get it lost and rather you make sure that one honest actor is enough to resubmit the data to the others and so data does stay available for the full month that's the intend with erp34