History Expiry, Layer 1 R&D - Day 2

[Music] uh yep hey everyone so this tees up well uh because there's a hint just at the end there around like what you do with this information in your node that you know once there's been some notion of finality either in protocol or output out of the protocol right there's like the stuff that never changes and today uh nodes have this like you sort of well let's get into it basically uh this will be about history expiry uh there's a particular eip that i'll get into uh that suggests one at least opens the conversation and i think that's what we'll do today is later in the workshops around this topic like discuss what this looks like what it means what's acceptable what's not so yeah first like what history kind of like i was saying just now there's all this historical data you know like the third block that ever existed like no one needs that block like it's critical right to the integrity of the chain but it's like you as an application user like user of the chain like you haven't needed to go get that block like probably ever um like clan actually helped me with this we found the first transaction i believe in the chain uh etherscan has this nice little tooltip it shows us from 2015. um the funny thing was basically gas limit was too low and so this was the first block where it was over 21 000 so you could send an ether transfer uh they paid one eighth in gas and sent i don't know it's like 3.1337 times 10 to the minus 10 or something either anyway it's here but it's like do you need this like no you don't um tax day was just for some of us right so maybe you care a lot about what happened last year but you don't care about this transaction yet your node has it and the point here is that this doesn't scale right like this the chain will only keep growing and that's how it works and so what that means then is that there's this linear increase in storage bandwidth processing and everything right um granted there's like perhaps bigger fires right but this will happen and so if we care and like you know if if we want ethereum to be here in like 100 years we don't need like today's blocks at least we don't need them to like be part of the experience of running a node and this is what we mean by history expiry is like changing the guarantees that nodes have today such that they don't have to keep this historical state and this is what we suggest in this eip four fours uh bound historical data and execution clients so what does it basically say it's changing this guarantee that i keep circling around like what history does your node have um concretely that is the blocks right so like headers transactions omers for example the transaction i showed you uh receipts from execution results these things that uh you know are critical for you to validate the chain at the time that it's sort of being appended to the time that you extend it but uh again after a certain amount of time that we can discuss what the right time should be but after a certain amount of time it becomes much less important for you to have this information on hand um and i just called out here does not include the execution state i think i have a bigger i'll just jump ahead a second to this aside uh there's this whole different research topic of state expiry right so there's there's chain history which is like yeah receipts and blocks separately there's the state you get from executing those blocks and the state is specialized enough that there's like a whole different research domain around how we want to handle that when we talk about four fours and history expire in this context we mean just the box jumping back a second like concretely how would you do this you just say okay uh within the ptp layer you no longer need to serve chain data older than one year for example and this number is a parameter we could decide what it could be if you no longer need to respond to peer-to-peer requests for this data then your node could prune it you could keep it you have freedom to do what you want but uh if you are allowed to prune it then we can delete it nodes are lighter and to give you like some sense of how expensive this is um i mean yeah like people complain about gas cost you all certainly know that you know this reflects the cost of operating a node this was from a freshly synced geth node a few weeks ago now but essentially it came into 500 gigabytes and a huge chunk of it is this ancient store and again this was a geth node so guth devs here will be able to speak more precisely to this but approximately uh if we say drop the last year of history i think we'd about get rid of this ancient store um and that would free up about half of it right off the bat and why do we care well again it comes down to the cost running a node the questions here are like who's running a node and how are they running the node and what does it really mean to be a full node to be an archive node like we have to define what these things mean and these come down to like ethereum's values so i'm sure there'll be some heated conversations later maybe not heated but it can become heated because it's something that's important to all of us right but like at the end of the day like uh this isn't sustainable right again if ethereum's here in 100 years we don't need a hundred years of block history and so the question's like yeah what can we do about that um if you do keep polish history it becomes more expensive to run a node you might need some specialized hardware then fewer people are doing it fewer people are actually running the protocol network's more fragile where security and again this is about guarantees like the actual technical implementation is like okay sure like you know i can just snip off my database past a certain point um the thing we all need to come to because this is on is like what do we want here like what does it mean to run the protocol what does the protocol do uh this is my take is that essentially should be like a very secure consistent protocol right so the way to think about it is that there's like sort of a cursor over the recent activity and like the output of that process is finality right um and then once you have finality there's like all sorts of things you can do um and the point here is that you want it to be very like focused and minimal so like for example we saw a bunch of stuff yesterday around like scaling and starting in various capacities pushing settlement execution these things like to other layers of the stack uh when we say the protocol i mean the sort of l1 ethereum protocol and it should do this process very well like in particular it's not like an archival service you're not going to have you shouldn't also like have this like highly sophisticated like settlement protocol maybe you should just take consistent protocol and then also like say oh yeah provide me this transaction from like 2015 right like those are different tasks jumping back so uh if this is interesting to you maybe you think it's bad idea maybe you think it's a great idea if you are interested to explore what this looks like there's still questions we have to ask um essentially like who provides this history because again still i'm teeing you up who will provide this history uh like in a sub question how it'll be provided um how can the history be validated because that's the thing is like just because you know like let's say we go into this vision of like having a super link consensus protocol like that doesn't mean that the history is not important it doesn't mean history shouldn't be available in some way it just might be someone else's concern and then separately who should value the history that's kind of a leading question around like yeah what is what does it mean to run ethereum um so yeah who will provide the history um if we move into this four fours world like ultimately you just need a few like reliable actors right because again it's just the data it's like not changing ever um going back to the previous talk you know there's even suggestions of like putting on bittorrent and like different actors just seeding it and just having this data out there um the like sort of the the data you know the access pattern to this is like an archive archival use case in the sense of like again the data is just there once it's finalized so it can just look forever you don't have to like have a very sophisticated like uh methods to update the data and things like this uh here's some examples right so you could have like altruistic actors in the space so for example the ef could do this i think that makes a lot of sense i've been talking to like filecoin just like a bit they basically want to like put the history on filecoin and have like a cool demo we'll see what happens there portal network uh which we'll hear about i think just after this um but then other people outside of quote crypto like the internet archive there are different players where like they hopefully also think that like this history is very important and it's a public good to provide and they could just step in and do it for free um and then yeah just like individuals hosting torrents or different file mirrors things like this um etherscan if you're uh players in the space that again are aligned and want to provide this as a public good we could have something more experimental like a public good style lots of ideas here how will we get the history uh this is again kind of implementation detail but it's important one because a lot of us are developers so we like these things you could have torrents again like file mirrors data mirrors these things like this file coin a bunch of different options uh how to structure it so like the actual like syntax of the data if we move into this world we'll need to answer this question uh we'll see a demo the first leg workshop for this after the series of talks now will be a demo around an initial exploration of this question a cool thing would be if like we have a format that we could essentially make proofs about and you could even then like put commitments to this data on chain that could be fun uh how can this be validated so the vision here is essentially to have like a shim client where like you could have you could even imagine like you could have one sort of version or cut of your client that's for one person one specific rule set you know across forks and then you say okay i'm gonna run like all these different clients you could have like a meta client that bundles them and wraps them just for ease of use but then it says okay here's this huge history dump from this block to this block do this keep going fork by fork and you could in fact like run every transition from genesis if you wanted uh this is here as a motivating question because again i think a lot of this comes down to like what do we mean when we say run a full node um who should validate it like is it critical that everyone who runs a full node is valid in the history for malt for all time like do they need to start from like maybe a recent checkpoint or something validate from there do they backfill from the checkpoint if they do this there's a bunch of different things here to discuss and again yeah there's a huge design space in terms of like what your client does what it looks like how you answer all of these questions so the latest work here we have like a small working group you can probably just dm me on telegram if you want to get involved more directly um [Music] vip says about what i just laid out and at this point i think we're just getting input from other from various community members again this would change a lot of the guarantees of the protocol so it's something we definitely need like wide alignment on and yeah henry who i just mentioned who has working on our prototype they'll be demo later today and i think that was it yep so yeah hopefully we'll uh talk later [Applause] [Music]