EIP-4844: Shard Blob Transactions, Layer 1 R&D - Day 1

[Music] so i'm going to talk about eip4844 this is one of the options to scale ethereum this year um what we're looking at um is this this balance between call data and alternatives we cannot keep like lowering the cost of call data forever so that is what this eip is about i'm proton worked with optimism used to work with the ef on leave tool research still working on the same thing starting all the way so all this talks about data fed ability go briefly through like the basics then the rollout centric roadmap the modular blockchain design i think if you take the like higher level picture this is it's really about it not just about scaling or cheaper data it's like about tearing the system apart so it actually becomes manageable we have this huge crowd here and i think nobody really understands all of ethereum anymore i know this is a concern but like the better the interfaces are the better the modular design is the better we can scale it so what's data availability is this primary scaling bottleneck of ethereum right um cereal i've experienced like the the expensive call data so we have canonical available global ordering of inputs this is what the data is about and then you realize that actually we can separate the the outputs you can separate layer two you can separate the execution layer whatever you want to call it you can think of this a different scatting bottleneck and layer one could only just focus on the data availability and layer two or other systems could increase the processing so what we really need this data availability for is this permissionless ability to reconstruct state right so think about a rollup rollup is just data availability with some execution check in a simplified form i'm sure you know secret roll-ups or optimistic roll-ups we have some flavors within this space but already all quite similar we're checking the execution separate from this layer of available data and so last part of the basics here is that you have this difference between data being further available and data being once available so as a layer 2 system or any system that cares about execution you just need a system to reconstruct the state from so you need one homeless actor to be able to do this and like if you're a maximalist with reconstructing states you might want the data to be forever available but if you assume that the layer 2 system can retain the data as long as there are honest actors in the system this guarantee gets a lot better where now we can actually sustainably scale data increase the data by a lot more and we're only talking about a month of data at that point and invested both cases we kind of both like ethereum has this roll-up centric roadmap and we should be looking at solutions where we can like scale the evm for d5 for like this high value bridging system whatever else it serves at the same time we should look at layer 2 scaling and this is outpost from pythonic 2020 been thinking about this for a while now like really the high level picture is like this modular design enables us to add scaling so quick scanning walkthrough i'm sure all familiar with proof of work engine api proof of stack first part of modularity we're going deeper so like it's kind of silly to have layer two execution coupled to layer one execution we really need this layer one data and like layer two execution so this is what looks today like this is where we want to be for layer two there are like a high throughput data layer on layer one we're just putting data then we have this alternative layer ones where you have a data layer you have a execution layer and you have some kind of roll-up system without fraud proofs i think the value already in ethereum is that we do couple all these layer twos together we might have differences but we do want this variety of like execution environments on that on ethereum so this is where erp 484 comes in they i mean it's kind of joke where we with the prototyx starting here where i i guess you know bank starting where we add a lot more data this is a step towards that in preparation so what's happening here is we have a data layer we have blob transactions these blobs are coupled to the ethereum chain a little bit abstract here i'll go more in depth how it's actually being coupled and the idea is that we can start increasing the number of layer two epm instances or like the number or the processing power of ethereum really increasing the capacity so the life of a blob so what does this look like we have some layer use loot 2 user creating a transaction some rollup operator including the transaction then we somehow need to push this layer two data onto layer one so i have a transaction pool where we're taking these blobs publishing them and then we have the big chain where we embed these execution payloads but then we are not embedding the blobs forever the blobs live as a separate sidecar and so now we can split the lifetime we can continue processing layer one we can continue processing the evm chain with this more lightweight collection of data and at the same time we have all these blobs to provide this higher data throughput for layer two and then layer two can persist it after we have made it available for a long enough amount of time so we can be sure that honest actors can retrieve the data so what does this look like really if it's going too fast we have workshops so if you want to dig into these diagrams or discuss how to improve them really just join the workshop please we have like four hours to uh get really into the beats [Laughter] thank you fiverr so um and then we have these block transactions that are really just like erp one five f9 transactions and at the same time we're adding this reference to the blobs the reference is sufficient to authenticate the blob when any blob is separate and the blob is stored in the consensus layer and this way we can later fit on data availability sampling without changing the transaction format without changing the execution layer at all really to emphasize transactions with blobs commitments and blobs separate from the blob and when you're pushing a message through the ethm it's without the blob data just with the references called first intentions or data hashes so i have these diagrams of simplified layer 2 designs for everyone to help understand how layer 2 actually works with blob data they're a little bit small but in during the workshop we can dig into the format so in a non-interactive version you load the film blob when there's some challenge in the interactive mr slides no really okay we could go first for our secret validity probes i mean they're really similar to non-inter uh sort of to interactive optimistic fraud proofs where in the happy case reading a good design you're not loading the full blob during your throat proof you're only loading a little piece of data so you start doing this and the zika validity proves you do this proof of equivalence so that you don't have to use kct but you could use also use alternative uh zk system again same thing for interactive file proofs just load a piece of the data and this is like this pre-image oracle you're loading data by authenticating it against the previously authenticated hash so you start with one layer one hash and then from there you can retrieve other layer one history dick into all the layer one data and then from layer one data construct a layer two state so to make this all possible we're trying to separate the excretion contents layers and what we need to do this is to propagate these accepted block transactions to the consensus layer it's not just the exclusion payload at this point but we have the side car that we need to give to the consensus layer so we extend the engine api we can do this in a backwards compatible way which is nice for testing right now but then in the future we might want to combine them or arguments against them for those and then ready to finish this talk we have bank sharding coming up which is more blobs we have data effectivity sampling so now like moving these blobs to the consensus layer for storage and management is really meaningful in the future not all contents layer nodes will store it anymore we can use sampling to make sure of the network as a collective has the data but that not any every node has to store every single chart so with sampling we can secure the contents layer when distributing the work and we're looking at a big increase so this is on top of eip4844 so with erp for eight for four we're looking at a 10 to 100 times increase compared to roll ups roll ups right now are like somewhere in the ballpark of getting like 10 kilobytes per block blocks are like 50 to maybe 80 kilobytes and the like we're competing with d5 for call data and this call data is used in a way where it provides a lot more functionality it goes through the ethm it's forever available much stronger than we need for layer 2 to scale so we want a separate market that can serve layer 2 and provide this more specialized ability to serve bloop data and well after our epa episode no more changes to the execution layer consensus layer can take it from there and then this is the end state end game or we have proof state let's take we have the evm on layer one we have bloop data and a massive layer two ecosystem okay thank you and we'll go for more questions [Applause] [Music] you