On the state of scaling research in Ethereum - @protolambda at @ETHDubaiConf

Transcript

so i'm proto i work at optimism i am a research and developer and [Music] we're building a layer two roll-up and to scale the roll-up we of course need to scale layer one we need to fix the primary bottlenecks of ethereum and then after fixing those we're hitting the next bottlenecks with increased execution so what does this talk about this talk is about data availability it's basically the what what are we trying to fix now we have the centric roadmap this is the how like

how is this going to work for ethereum in the future we have modular blockchains survey to encapsulate complexity we have to merge the first part of this modularity i have blobs and further scaling and then i'll talk about the optimism upgrade so what is data availability you could think of this as the primary scading bottleneck in ethereum today where if you have some layer one it's kind of like it doesn't use ethereum quite right it doesn't offer what the like layer two needs all right so that availability not about bandwidth

or about storage about processing like these are all properties that you can scale today using traditional web 2 technology it's something you can scale on individual machines but this is really like data availability is about the permissionless ability to reconstruct state reconstruction of state enables many different crypto economic scaling solutions where now you don't have to trust any particular party but instead you can reconstruct the state yourself and can challenge the system so how does this challenging look like or how does this kind of execution check look like if you combine this data availability property with some kind of

proofing technology you'll get a rollup and so you have a zika rollup or optimistic roll-up the difference here is that the seeker roll-up has an immediate validity proof whereas in optimistic roll up it's a fault proof where you kind of have two flavors a non-interactive and an interactive flavor where the non-interactive flavor kind of like is similar to the zika rollup except you only do it in the pessimistic case right where you in the worst case if there's a fault you can challenge the original proposer of the data of the proposal to show them that they're wrong

and so with some bonding you can secure the system the interactive version you have to have the same but you have multiple rounds of this game to show that the sequencer or the proposer is wrong so there are two kinds of data availability there's type of data availability where everything is available forever this is the kind of naive solution that we have today in ethereum that we have today in bitcoin that everyone knows and then there's the data that's once available like this is a lesser data availability but it's good enough for layer two because if you think about layer two what you really need is the assumption that at least one honest actor can reproduce the state to challenge whoever

is progressing the state if you cannot join the system you cannot basically become the new sequencer or win or try and like prove the existing system wrong reconstruction is important but say if you had a month some honest actor will be able to reconstruct the data and we'll be able to prove the system wrong when it fails and so you can challenge or replace any bad sequencer with just the data once available assumption there are different arguments for oh should we make data available for maybe just 10 minutes maybe just a week right now we're staying with a conservative one month or maybe even longer

it's already a huge leap compared to the data forever available since um we're now not paying the unbounded price for whatever it takes to store the data forever it's that we have a bounded limit on how much data for how long will be stored and it can be cheaper this way okay so let's talk about develop centric ethereum roadmap it's not a new eddy this is something that vitalik already proposed in 2020 or way back before rollups and before plasma before other scaling technologies there was already something called the shadow chain which was a chain that was derived from another chain

so a roller works kind of the same where you derive the roll of data from the layer 1 data and this enables us to decouple the execution from the data and we can dump down the layer 1 in favor of these more advanced layer 2 execution environments another way we can scale our execution independent of the layer one bowl next and independent of the layer one ossification this is huge because it keeps ethereum competitive with other chains so how do we really achieve this kind of thing right well you need to encapsulate complexity there's no denial that

there's like a growing complexity in ethereum and the only real way to manage this is to try and encapsulate it so this sparked like the new trend in blockchain design where now everything is modular all the new layer ones they're all modular modular merge learn because of the increasing complexity you cannot keep going on this monolithic graph fork all the previous 2017 outlayer ones are just a copy of gaff in one way or another adding new consensus or adding new things but if you don't decouple the components it will grow in complexity and will be more and more difficult to maintain okay so let's walk you through this

modular design so we start with layer one today this is where things are very monolithic we kind of just combine proof of work and the exclusion layer there's one block there's just one thing called efhash that secures everything and it's just kind of singular now think about the merge we have this proof of stake beacon chain already live for a year now we kind of want to couple that to our execution layer and get rid of proof of stack and we do this with the engine api where the engine api couples the beacon nodes the contents layer and the engine is the exclusion layer makes them talk together and then we can

basically encapsulate these two different things so then we'll start to look like this small steps it's like the first tiny thing of modularity in ethereum which we hope like comes sometime this summer hopefully this year where we now have two different layers and we have proof of stake okay so now take a step back i think about layer two how are we really going to scale ethereum right so this is the current design where we have deposits and the sequence data you pull it you process it you push back the proposals and anything you need in the future to sync the layer 2 chain

this is still kind of monolithic and now think about ethereum today it's kind of city also like we use the execution layer to style data into we take one exclusive layer from there too we use the data availability for layer one that's used for call data this thing is type of epm inputs that you compete with for defy that you is really a huge ask that's why the base fee is so high there are too many parties that are interested in this data because it's the most naive most simple solution so we should really try and specialize we can do better than this so instead we want the layer one data

provider you want layer two to kind of just use the data from layer one and not touch the evm at all except in the case when there is a fault proof or some kind of validity proof to resolve the execution now if you think about other layer ones right now that are trying to fix the data variability problem they don't have an unified execution layer they just have what we know is there too they just have an execution layer some kind of software envelope system where you can have these different rollups chained together but notice how there are no fault proofs or no validity probes in this diagram this is because they have an off chain they are not part

of the layer bond system and then well we do have a data availability layer and we can scale the chain by a little bit at least still we can do better and for ethereum we need to do better because we want to preserve this whole defy ecosystem we are not throwing away everything that we have it's that we want to embrace data while keeping our beautiful global exclusion environment so this is erp 4844 this is the change that we're trying to introduce to introduce data without breaking

ethereum it's kind of a meme where we say it's like the full starting design developed by duncan working at the foundation it's called blank sharding and so i work on this efp and it's kind of like the precursor to the field design so called prototyping starting okay so how does proto dunk sharding look like or how does erp 484 look like think about it as our consensus layer so this is after the merge then we have our execution layer so this including d5 and then we have a separate layer for these data blobs which means that we can

host our data for say a month for some limited amount of time that's enough to secure the layer tools while also providing more capacity and notice how we're providing blobs for very specific format it's just not any format this makes it forward compatible with the fill design of dank sharding what we're trying to achieve here is that we don't have to make any modifications anymore to the exclusion layer to go ethereum instead we only in the future we work on the consensus layer to implement these more advanced technologies for filtering sharding and scale even further so let's talk about the full version so while we have more of those blobs

that's the obvious one we introduce data availability sampling it sounds really complicated but it's really not it's this technology where instead of having one blob or one collection of blobs per block that you have to enforce everyone to download and to keep available instead you can distribute it through the network you can split the task and to secure you just have any validator do these random checks request to others in the network to make sure the data is still there and then there are fancy data extension and data recovery techniques to increase the chances to make it like really secure that those checks actually map to a data being

available or not being available and like i said it's first compatible so we can get away with a single layer upgrade again even though we're scaling by another 10 times so how does this look like well it kind of looks very similar where except now we have many more blobs per evm [Music] block and this means that we go from like around a megabyte on average per layer one block to 64 times that so now we're talking about 1.4 megabytes megabytes per second whereas now we have like 70 80 kilobytes per

14 seconds on layer one it's a huge difference it's like 100 times if not more in scaling so okay let's talk about optimism bedrock optimism bedrock is this kind of philosophy where we want to take a layer too we don't want it's a rushed version that tries to roll everything on their own but then also not like really provide the users with what they want what the users want is something very similar to layer one but faster cheaper and more usable so you want to keep snap sync we want to make sync of your node as fast as possible we want to have a transaction pool we don't have

this centralized endpoint to submit transactions to we want fast block propagation we want the equivalent execution environment you just want to run gaff really we want deposits that are actually nicely typed and not some hacked version on top of the current system and we want to improve the stability on like how this layer 2 comes to exist now it extends so we want constant block time cheaper transactions and a bunch of other optimizations there how are we going to achieve this we have modularity so think about layer one today is like gaf now we're adding prism with the proof of stack

chain and we can do better we can repeat this pattern on layer two where now we have a consensus layer on layer two an execution layer on layer two which means we separate all the roll-up technology from go ethereum so optimism is just a stateless client really easy to set up no database no configuration it's just there and it pulls data from there converts it processes it and forwards it to the layer 2 version of gaf and so we get this the same pattern where the beacon node talks to layer 1 gaf the op node talks to there to gaf and you can repeat the pattern the other

way around we have the beacon chain talking with the beacon chain play around with the layer one and so on everyone talks of their own kind and here again layer 2 kind of just does the same as the beacon chain where distributes blocks in a faster way but notice how layer 2 is like the happy case and the other one is the base case they won't always guarantee security if the layer two completely fails and falls apart you can still reconstruct it from the layer one so it's always there i was live in a way where you can process deposits you can keep keep continuing but we also repeat like the if you have the sync the transaction pool we keep all these properties so it will feel and

look a lot like layer one and the one difference that we want users to take away here is that they don't have to change their systems they don't have to change their defy projects it's just going to get more and more like it's going to get better for them less expensive so this is what it looks like if the data provider and the engine kind of just have now one day to pull the data from one way to pull these deposits on our excretion activity from rollup node sits in between maps everything to layer two and then layer two is this engine which processes the

blocks and um well it's all open source we don't hide new upgrades from the world we are here to share everything we're here to get feedback from you f you and you can go to this repository we're planning to merge it with the other optimism monorepo right now it's a separate specification repo we have a reference implementation and a local devnet as well so you can get started it's all very experimental with our specifications you can learn about office and it's what we think is the future of modular blockchain and ethereum scaling thank you

[Applause] you have some time for questions yeah if we have any questions uh we can bring the mic around to you come on we gotta have some questions i can go back to the diagrams there's a lot more to them so from what i'm getting ethereum is not going to need a separate data availability layer to just support instant data availability a separate layer like celestia or something like that so sorry to repeat the question you're asking about the differences between like a data focused layer one and ethereum right yes okay so and you

mentioned celestia as an example so celestia is one of those cases where software roll-ups are becoming the new thing whereas i think like we don't want to shy away from like this unified exclusion layer it has a lot of failure for different purposes i think one of the main cases here in terms of security is that we can play these validity proofs and these exclusion things on chain which sounds slow but it's only in the worst case and so we get better guarantees for the completion of this security game and when you think of a software rollup it all has to happen off chain and so once somebody starts to publish these things

and they cannot publish it in time or when they refuel themselves they are more vulnerable to be like try to be censored to try to be attacked some kind of denial service attack whereas if you have layer one to purpose two you publish the layer one you have a week of time to do so in the optimistic case and then once it's confirmed nobody doesn't see default proof there's no hiding of the execution whereas with celestia it's really focused to try and be purely data and are doing everything outside of layer one also i think another case is bridging where if you think of all these different

layer tools if you're like a really diverse system you want to bridge liquidity you want to do so we have the almost security you don't want to rely on centralized purchase we all know how that goes like just yesterday or like day before there was a 600 million dollar hack on one of these bridge platforms like really you should have a roll up type of bridge with like the security guarantees of a system instead of any random actor that operates the bridge yeah if anyone wants a good job they should be uh looking into kind of monitoring that stuff too like you could probably um you could probably find a good job for

monitoring make sure that kind of stuff doesn't happen because i don't think that they had any monitoring in place monitoring or auditing of bridge systems is probably the most lucrative business right now yes all right we have one more over here hello thanks for the presentation so if a relayer posts a fraudulent bundle and fraud proof happens and it is detected that is fraud what's the current economic cost in optimism now right so i think the current rollups none of them have running file proofs yet i mean there's a huge reputational cost they do enable like default pros in the future i think

so optimism doesn't have default proofs enabled right now arbitrarium has like a what is called like a allow list to only have like a selective accounts do the spot proof and then some of these ecosystems are not in production either yet so in a way i think we're not quite there yet in the roll-up centric ethereum i do hope to get there in the future but once we get there we'll be talking about millions billions sorry can you speak up and repeat the question yeah yeah so once this is in place i if i understand the relay we have to put a bond and if anyone wants to meet the fraud

proves this bond has to be matched so i'm wondering what would be the size of the spawns if you do execute default proof what would happen is that the proposer is independent of the layer layer 2. so the proposer you have to really think of it as a way to bridge back activity from layer two some kind of messaging like withdrawals to the layer one and like in the case of celestia or these other data centric layer ones you don't need these proposals if you don't have a way to if you don't if there's nothing to bridge back to like the fault proof is really just about showing layer two activity to layer one and the layer two will not be affected by

default proof at all everyone on the layer two will interpret the data their way will process it their way just like if somebody poses a fake proof of work or does some fake voting of proof stack it doesn't change the system or the rules of the execution everyone processes their own chain it's really just the layer one that you're you're trying to trick with like a bad proposal and it just purely depends on the bonding of the proposer on how much they get slashed and we can parametrize this we can have like a huge bond to secure this type of withdrawal okay thank you all right

we still have about two minutes if anyone else has any questions just raise your hand if you have questions about the modularity between the data and the execution layer and then specifically about execution you should maybe wait for the talk from anscar who's going deeper into that type of scaling hello hi i have a question about the latency about the data blocks if we say one of the data blob in one chart and then how long time it takes to synchronize this problem across the entire network the current efp describes the usage of the current transaction pool so we're not changing propagation and so

it'll just be like a regular transaction where it just depends do you pay enough of a base fee and if yes then your blob transaction with all the data will get confirmed okay and the second question about this is about uh you mentioned the data rate to save a blog in the blockchain is about 1.4 megabytes per second so i would like to know more about the bottleneck about the data rate is that the synchronization issue across the network all right so we do plan to scale data by launch and this of course raises network concerns how much data can propagate does it scale it's definitely something we want to

test it's not something you can work out neatly in theory where we have both on the exclusion layer as well as on the consensus layer this increased network activity so in the upcoming devnets we'll try and benchmark not yeah thank you thank you very much yeah round of applause please proto lambda you