Ethereum Cat Herders PEEPanEIP, 21 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP#64: EIP-4444: Bound Historical Data in Execution Clients with Alex Stokes

Description

Topics covered
-----------------------------
01:01 - Guest intro
01:46 - EIP-4444
01:58 - What does it propose?
04:30 - Aside on state expiry
05:30 - Changing the guarantees of the protocol
06:43 -What even is Ethereum?
08:35 - What does an Ethereum node do?
09:53 - How expensive is it?
12:32 - Why do we care?
14:21 - How does EIP-4444 want to solve it?
16:42 - I’m 4444-pilled, what now?
17:15 - How can history be validated?
19:11 - Who will provide the history?
20:41 - Example providers
22:53 - How will we get the history?
24:06 - Bonus round: The Merge
24:55 - Weak subjectivity
25:46 - Bonus bonus round: Statelessness
27:12 - Latest work on EIP-4444
29:53 - End of presentation
30:06 - Readiness of community for this proposal
31:17 - How often does a normal user need Historical data?
33:20 - Archive nodes with state sync functionality
35:32 - Shim client
36:58 - What do you think of Portal Network vs EIP-4444
38:48 - How would Weak Subjectivity help users run nodes?
40:35 - What are the breaking changes to JSON RPC endpoints? Which projects will be affected?
42:33 - Usage of “Should”, “Must” and other words in an EIP?
46:30 - Implementation on Geth client
47:22 - An example of “Must” vs “Should”?
48:25 - When the proposal is ready for “Review”?

Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1ljUgCuhp2dV6G07wNmFy9rxonutoT2_3wPVclzTEEss/edit?usp=sharing
Proposal - https://eips.ethereum.org/EIPS/eip-4444
Discussion-to - https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450
Breakout room EIP-4444 (1) - https://www.youtube.com/watch?v=lkKXlVlFvZQ&list=PL4cwHXAawZxqOabsdbDgzBUyztSHn4Lap&index=6&t=2s
Breakout room EIP-4444 (2) - https://www.youtube.com/watch?v=Kv2gbgBzQzg&list=PL4cwHXAawZxqOabsdbDgzBUyztSHn4Lap&index=3&t=3s

Follow at Twitter
-----------------------------------------------
Alex Stokes @ralexstokes | Pooja Ranjan @poojaranjan19

Merge Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12

PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/

A

Hello and welcome back to another episode of an educational video series where we discuss an ethereum improvement proposal, upcoming upgrades and the basics of ethereum blockchain, I'm puja ranjan and today we are going to discuss eip4s bound historical data in execution. Clients with one of the co-authors of the proposal alex stokes eip4 is a standard track. Networking eip proposed in november 2021 that is currently in the draft status and to provide the overview of the proposal.

A

Let me welcome alex, who is also a developer and researcher at ethereum foundation and is mostly engaged with ethereum beacon, chain development. Thank you for joining us, alex.

B

Yeah thanks for having me so yeah uh today we're going to talk about eip4s, um just like sort of a quick intro puja, you know said some nice things but yeah I uh with the ethereum foundation, one of the co-authors. On this proposal. I've spent a lot of time more at the consensus layer, uh but finding myself spending a little bit more time lately at the execution layer and, as uh you know, especially as we come to the merge that everyone is, I expect so excited about.

B

uh You know these things will become more and more. uh You know relevant to talk about the same time so either way um I have some slides. We can run through eip four fours. uh If anyone on the call has any questions like please stop as we go, um yeah should be, should be fun, so yeah eip4s, I'm alex stokes. If you want to follow me on twitter or find me on my github or telegram my handles are alex stokes, you see it there at the bottom uh and yeah.

B

So the first question is like what is four fours. You know what is the propose, so the key thing it wants to do is change the guarantee that we have today that if you run an execution client on the network, it has all the history of the entire chain for all time.

B

This means I could go back to like I don't know the 10th block and say what was you know, give me a transaction in that block and uh that's great in terms of like making the ethereum node be responsible for that uh service right, but as we'll see it actually doesn't you know it really doesn't scale, and that's that's what pork forest is trying to drive at. Is that like and I'll say this later but like?

B

If you think about this, like let's say you know, we're running the ethereum protocol in 50 years, even 100 years, like you, won't care about transaction that happened today. So why would your node want to like keep track of it right? So anyway, I'm getting a little ahead of myself. um Specifically what 444 says is that we're going to drop this guarantee?

B

What that means is that on the peer-to-peer networking layer, no longer can you get blocks, and that includes the headers of the blocks transactions in the blocks and also omers, uh which is just this historical sort of proof. Work function, that's going away with the merge, but either way uh they exist are important for history and also receipts.

B

So a receipt here is when you execute a transaction on ethereum today, there's basically some side effects and these side effects are recorded in this other data structure called a receipt and uh they're important they're important for like clients, they're committed to in the block, header and yeah.

B

You know if you're, like adapt, developer, you've seen logs you've, I'm sure run into logs, either in solidity or like events and slowly or logs with the protocol. These receipts are where the logs live, um so they're, very important in terms of like using the protocol and importantly, four force- does not touch the execution state. So this is a distinction. That's like actually quite important.

B

There's like if you think about the blockchain, there's a chain of blocks and when we say history we mean like. Basically, all of these really old historic box in the chain separately, you can execute.

B

You know the transactions in these blocks and they perform some mutation to this state that we'll look at a little bit more in a second but basically there's the ethereum state and uh that is kind of its own can of worms in terms of managing the state and like there are various ideas around state expiry I'll just go to the next slide.

B

Now uh so yeah, just a quick aside here, there's this notion of state exci expiry very different from history expiry simply because, with history expiry as we'll see, there's probably like some very simple things we can do to get a lot of the benefits, whereas the state expiry it's like so much, there's just so much sort of like subtlety and intricacy around handling the state uh that we're probably gonna need like a whole different approach.

B

So four four says: okay, uh we can. We can do a lot of good just by like managing like history, growth with respect to a full node, uh we'll leave we'll leave the state alone, and you know that's someone else's concern. So, if you're watching this and you're interested, I believe this is the latest thinking. Is this document metallica's written on state, expiry paths and there's a few different options there again, it's like still an open sort of r d, sort of research, design, space um and yeah.

B

I mean there's a lot of interesting research for this coming out of that, but uh yeah it's a whole different thing. So four fourths is concerned just with the history of the chain and again you know, like you, could probably drill down and like there's like some like specific technical things you could like talk about, um but really more like. Four fours is about changing the guarantees of the protocol. So it's almost more like a concern of the social layer, not so much like.

B

Okay, like is there this, like very crazy, like cryptographic, witness to like give us nice statelessness or something like this like there. Aren't these like really core deep technical challenges um that we need to solve with four fours or like history expire in general?

B

It's really more hey uh if you're an app developer- and you suddenly don't have your logs from like two years ago- is that okay? What does that look like? um So a lot of like writing?

B

This eip was to like basically just start this conversation um and I'll again I'll summarize some of this later on in the talk, but I think that's kind of what we've gotten to is like right now, we're still just gathering input from, like all the different community members, because, like this is like a core guarantee that protocol does provide and like it really does touch on, like so many different actors in the ecosystem.

B

So uh hopefully we can align them all one day and uh do something here, but in the meantime uh we have the cip.

B

So to like motivate this, you know we can ask like what even is ethereum and like this really is the question because you're like okay, what guarantees does the protocol provide? Well, what does the protocol do and like if we can agree on what the protocol does then, like? I think the guarantee should be obvious, but either way. uh Here's one definition and really it comes down to the state like ethereum, is the shared state that we all have like. If you run the protocol, then you have the state, along with that.

B

You have a permissionless protocol, so some rules for running turing, complete computations on this state so like not only do we have this state like this, like you know this, like data or information that we all agree on, but, moreover, there's rules for how to like change it and like that's where all this sort of the power and flexibility of the protocol comes from. So, like I said here, yeah, it's very powerful. You can do things like programming currency. So that's where we get ether you can program like sub currencies.

B

Then you have all these rc20 tokens, but you can do more complex things. You can have like the state of the decentralized exchange right, because you do have this like trade, complete richness. You have this expressivity to say things like okay. This is now like a constant product or constant some decentralized exchange, and you can build that on aetherium.

B

That's where we get things like you know, swap or curve, and then again, if you're in the, if you're in the space, I'm sure, if you're, watching this video you're aware of all this stuff defy nfts, daos, meta versus all this stuff right and your idea here, like there's like so much that's possible to protocol. I think that's what like attracts everyone to the space, because it's like there's so much potential here but anyway. This is not me talking about ethereum. uh This is me talking very specifically about history.

B

Expiry, so point is there's a state and we have this protocol to change the state.

B

uh This definition will actually be really important because really to answer this question, what are the guarantees right, like I said, we're gonna have to answer this question so anyway, we at least have a working definition for what ethereum is so then the question is like okay: if we have this node, we have the software that implements the protocol like what? What does that node do?

B

um This permissionless bit is actually quite important, because what it means is, anyone can make transactions. Anyone can make a block with those transactions, and so as a node, you have to verify that you know the next block in the chain is valid, so you're going to collect blocks from your peers uh currently and again, there's like a various research efforts to like change, how the statement reads. But what happens today?

B

Is you re-execute all the transactions and that's how you know if they're valid um and then importantly, once your node has executed things and determines what the state is that stays exposed to end users? And so that's where like when we do things like build uni-swap dapps, like we can say, oh like here all these liquidity pools here are like these trades that happen, then we can actually like build applications with this stuff.

B

um So it's actually quite important that, like you know, people can actually interact with the state um and yeah. This takes various resources right so like this. Has the cost and the cost in terms of running a node is like the computation that this footprint, the network bandwidth all of these, like technical resources that have to go into this in terms of operating the protocol.

B

So if it has a cost right, we can say how expensive and you know ultimately that's a relative question, but uh yeah I mean a lot of it- is that you know everyone comes to protocol. They try to interact with it. They try to do like a token swap like I was just talking about and they're like, oh, like the gas costs are so high. Why is this? Well?

B

This reflects the cost of operating a node right, so if it were somehow radically cheaper to operate a node then like with the same sort of security parameters that we operate. The protocol today, you could, like you know. Essentially the gas cost would be much less and some unit you care about to give a flavor for this one element right because I said there's like a couple of things right: it's basically like you have all this like computer hardware, you have to throw it.

B

You know throughout running a node. So, to give you an example, some flavor for this one one you know dimension to this is the disk footprint, and so that's what I have here you can, if you're on a guest node, you can run, guess db, inspect and it will basically go walk through your local database and tell you okay, you know you have these recent headers and they take up this much space or block bodies and they take up this much space.

B

You can see this chart here and this was from a death node that I synced just over the weekend. So it's super fresh version 1016. If anyone is interested point, is you see here at the bottom? You know it takes half a terabyte 500 gigabytes right. So that's like a lot is the bottom line and so like what for foreign is trying to do is say: okay um and there's other dimensions as well right in terms of computing and also networking.

B

But the point is: is that uh having to sit from genesis and like sync, the whole chain it already takes? You know 500 gigabytes of of storage. You know on disk, and the question is like: can we reduce that right and in a second we'll see it's important to keep this as small as possible?

B

um So I did do this call here with the red box and just to say so. There's some. You know differentiation. The guest software makes between like recent values and like ancient values. I don't know exactly what this cutoff is, but approximately we can say this is about what four fours would basically say. Okay, you could drop and it would be the stuff in this ancient store, and so you look, it would be like headers block bodies receipts and if you total this up, this is like 300 gigabytes.

B

So that's over half of like the disc footprint already so like. If we ship four fours as it was written right now, then you know you could basically suddenly like run two execution clients or, like the you know, you suddenly have so many more resources uh just immediately.

B

And yeah, like I kind of, was alluding to this like. Why do we care well, it's important, both in the short run and in the long run, so in the short run? It's like okay, yeah like for me to do this. I need to have a big enough disc and, like uh you can imagine again going to my prior point like if we're running an ethereum protocol, 10 20, 30 50 years from now like this, is only going to get bigger.

B

The way that the protocol currently works, because the way it works is that as a full node you're responsible for the entire chain history, so it's only going to get bigger and bigger right. So, like this just flat, you know plainly does not scale um and then also right again in the long run, you have the same issue where it's like. This is what I was just saying where it's like yeah 50 years from now.

B

Like you don't need, you know, okay, the issue is that if, in 50 years from now, we don't change the guarantee we currently have then you're going to need. Some, like very you, know, uh high-powered disks to even like have all this data along with computation, along with networking all the stuff and that's the issue. Is that, like the the the more like sophisticated, the hardware requirements are needed, the harder it is to run a node, which means fewer people will do it, and this is again in this bottom bullet point.

B

What I was calling out is that, basically, with higher cost, you end up with more security, simply because fewer people are running nodes and that's like where ethereum gets its centralization and that's where a lot of uh the potential and power comes from and then also by the way. This is the same reason we can't just like to next. The gas limit people will like always ask ask for that, and it's just like. Well, it's not that simple uh yeah.

B

So four four says: okay, um it's already reasonably expensive to run a full node right, and it's only going to get worse. That's actually really the important point, um and so like this, this notion of just like having the chain monotonically increase forever, doesn't scale full stop.

B

uh So 444 says: okay, if that's the case, what are we going to do about it?

B

Well, one thing we can do is just say: yeah cut the old history make it someone else's problem, take it out of the core protocol, and so that's what the eip says is we're going to change the guarantees on the peer-to-peer layer where, basically now, these headers block bodies receipts these historic parts of the chain that, like honestly, are sitting on your disk and for most users you actually don't need them like you can just get rid of them right, and so what that means is that if I'm a peer-to-peer node on the network and I'm sinking in the chain, uh I would basically go to a peer, and I might need something you know.

B

Let's say I ask for something from two years ago: if the cutoff period is one year, they wouldn't give it to me uh and again, that's like changing the guarantee, um but anyway, so the eip says yeah we'll do this. uh We need some cutoff period right now. It says a year. um I think that's actually about a good value, but obviously you know we could debate that. You know the specific value but anyway, the point is: is that if you have this, then that implies that your node doesn't need to keep the chain history.

B

You know, for example, because it doesn't have to provide it to your peers so because of that, you can just delete it and suddenly, you know, like I said this red box here could just be gone, so a huge savings right out of the box.

B

um Importantly, if you don't have this information, it also means you can't give it to users, and that's like probably the bigger sticky point. I think with the eip so far is that a lot of people rely, like I said, there's like there's events in solidity. These are implemented as logs within ethereum and the protocol and people use them like if there's a transfer into like a gnosis multiseg like there's a log, that's fired, and so the issue is like okay. What? If you need to like audit that multi-seg?

B

Maybe you want to audit like funds flowing through it and suddenly you like can't look 13 months ago, because 12 months have passed and that's the history cut off like that. That is not great, necessarily so fort forest does need to provide an answer for that and and we'll look at that in a second but either way. uh In summary, we want to change this guarantee, and that means that uh you can basically save a lot of a lot of resources that you currently need to run a full head.

B

So maybe I've convinced you by now and like what do you want to do so we still have to answer some questions, and this is what I was alluding to like. How can history be validated? um It's still very important that we be able to like say: okay, this is the genesis block that we all agreed to. How do we get to today's block?

B

um If we do do this, then the question is like okay, we definitely still want the history. Someone needs to provide it who's going to do that and then, if they do it, how are they going to do it?

B

These are all questions that are sort of tangential to the eip and like we're actively looking into so yeah like I said it's like very critical to ethereum's values because, like even if we get rid of this guarantee at the core protocol layer like in terms of like, for example, if we do say, okay, um the peer-to-peer networking layer no longer serves as historic data. That's fine, but you still need to be able to say. Okay, I need some way as a user. The protocol to validate.

B

I don't want to necessarily have to rely on someone else, and so uh how are we going to do that? So the ip basically says we'll make this shim client. So what this means here is rather than have like a sort of uh full node like if they look today, you could have something: that's even a bit more stripped down where it says: okay, um I'm now.

B

Basically this like offline data processing software that says okay from I'm, basically going to just like read ethereum box, and then I know that from you know, this block number to that block number. There's a certain format, a certain rule set and then I'll be able to evaluate them, and the idea is like, uh rather than having you know, execution clients today, where they have all this stuff in them. uh You can basically drop the old code because that moves into this like separate client that is just available.

B

You know in some open source fashion, for anyone to use and the client then can say: okay, you know for this range of blocks. I do this. I do that and then you could basically say: okay, here's like a whole batch. You know basically here's the history file. It could be mini terabytes like it.

B

Actually, you know it could be the whole chain um and you could say: okay, here's a chain, even if it takes you like a week like just sit and do it and then at the very end, tell me like what the state is and then from there I can hopefully get to a more recent state and then, from there there's other techniques we can employ to figure out.

B

Okay, uh given this recent state, does this link up with what I think the head of the chain currently is and yeah I mean that's, that's basically what this says here so there's an answer for how history would be validated um and basically yeah. It's just providing the software to do the re-executions.

B

A more interesting question is like who will provide the history. So the thing is you only need a few actors right. You just need a few like reliable. They could be very well established players in the ecosystem that are providing this history.

B

um There are, of course, like censorship risks to having just a few, but uh it's definitely the position of vip that you know we think there'll be enough, like trustworthy actors in the space that, like can, you know, provide the history and when I say trustworthy, I don't mean that you need to like, because you can still independently verify it's more. Just like this is more an availability question um yeah. We we think that there will be people who provide this data um it'll, be so important, at least in my opinion.

B

I think it'll be so important that, like someone- um and, like importantly, I say it's like an archival use case, so it's like, even if you are a provider of this data, you know it's something where you're going to probably write the chain. Every so often there's some like very low frequency just to extend your local history and then you know, like we were saying earlier.

B

Most people aren't going to like need transactions from like 50 years ago or like five years ago, right like so because of that, like there's going to be a very low volume of reads, so it's like you can have like sort of an optimized uh sort of hardware, setup and operational environment for this that should hopefully be low cost to operate and uh yeah.

B

It shouldn't be that terrible to provide the history- and I gave some examples here like here- are some you know, ideas about who who concretely would provide this data, so there could just be altruistic actors in space so like, for example, the ethereum foundation could be like okay, we're just going to host the history forever and like provide it at some endpoints that, hopefully, is again not too expensive to operate and like we can just really provide it to whoever wants it.

B

um We've had some inbound interest from the fileclean team, actually like people at protocol labs, who want to kind of, I think, demo um hosting the chain history uh on filecoin- and you know basically, as this has been visualization incentivization layer to ipfs, so that could be really cool like we have some cool collaborations there, um the internet archive.

B

Sorry, I need some water, but I don't have any the internet archive um so yeah. You know archive basically just wants to archive the entire like web. uh We haven't spoken at least I haven't spoken directly with them yet, but the idea is, you know they could say. Yes, ethereum is this important service? So we're gonna, you know the same way. We are creative. The web we'll just also provide an archive of the chain.

B

uh You could have other actors in this space that, like maybe aren't as like altruistically motivated, but still like, see it as like a value add for them right. So like etherscan or if you're, you could say, hey, you guys are running these like really profitable businesses. You could also provide this again, hopefully inexpensive service as a benefit for the community, um just as like a way to gather goodwill and like a cooler example, I think, as some sort of public good staff.

B

So you can imagine you know people actually use the chain to coordinate on preserving its history, so that could be pretty cool um and even if the dao itself doesn't like, like, I think the idea is more sort of almost like lido or like rocket pool style where, like the dial, is like actually in some way like essential in a decentralized way like maintaining the chain history. Almost, I guess like falcoin, but either way.

B

Even if you don't go like down that road, you could still just have a dial, maybe raise funding and like somehow provide that funding to these other orgs anyway. The point is the position of the iep is that there are probably many players who will do this and we just need a few and we're good. There then again last question: how will we get the history? So this is almost a bit of an implementation detail.

B

uh There's some ideas around, like you know, even just making torrents and using bittorrent to like distribute the chain history, uh traditional, like ftp, like data mirrors uh and then yeah, something like falcoin ipfs, so using foulcoin, essentially as a service to basically host the chain history.

B

There um there's like a couple options: you'd honestly, probably want to see them all used in parallel, so yeah, I don't think at least as far as the site eip is concerned, I, like I, don't think this is really the contentious point, um because there are plenty of ways to like retrieve archived data, like that's a very common thing that happens outside the crypto space. Even um some interesting pushback we've gotten so far, is that essentially we would basically want this part to be in the protocol itself.

B

So, like you can imagine a separate like dev p2p protocol that implements history, retrieval um and then nodes can opt into that. So not everyone runs it, um but yeah that that's a bit of a open question right now we can get to it later.

B

On top of everything, I've said: there's now a bonus round, which is the merge and what happens with the merge is that we move to this proof of stake security model.

B

Part of what that means is that we now have this notion of weak subjectivity.

B

Where, basically, what happens is that as a you know, as someone who follows the chain, the proof of stake chain, I, unless I'm following the recent validator set, I actually wouldn't be able to tell the the right chain and that's because there could be enough churn. So basically what happens is I'm following the chain? I know the battery set. I go offline.

B

What happens, then, is there's enough churn in that set that now I can basically have like conflicting views. Look completely plausible to me because I come online sometime later now. I get these two views and I don't know right um and within proof of stake, there's no way to actually resolve that.

B

So in parallel, we're speeding up this notion of like week, supportivity a way to distribute exclusivity checkpoints a way to resolve this issue of long-range attacks, um and it turns out that, like you, can actually use this to like as a sync paradigm, where, basically all you do now is you have a recent trusted checkpoint say, like um you know, the recent state hash from there you can say. Okay now appears on my network.

B

Give me the data that aligns with this hash and then maybe there's like some notion of like okay, I'm at like you know the block from this morning and then I'm gonna, like backfill the history, there's history, I'm gonna backfill the history uh to say a year. I mean I could stop there. For example, if you implemented, you know, four fours then like we would just stop after a year, and that's that um so it appears really well and like it's kind of happening. Anyway.

B

Is the point I'm trying to make there's also a bonus bonus round even a little more forward-looking with some of the research is like this introduction of statelessness, where the idea is that now and again this won't be a stateless talk, but at a high level the idea is um blocks now are going to carry their own history in a sense where like, if I need.

B

Basically, if I have a stateless block it it contains with it the state or the history that it needs, and it also proves right that it's valid, and so because of that, I don't need to maintain my local history or any local state. It's just attached to the block and so like.

B

Similarly it uh you know pairs well with this, this notion of getting rid of old history, because the blocks will just provide what they need and again this is still very much in the r d phase, uh but it does change what's possible with the full nodes, so um yeah another another thing to keep on the horizon.

B

So basically, the point I'm trying to make here is that what is ethereum is it? Is this protocol or is it some archival service? uh I would say it's a consistent protocol. It should not provide any archival duties. I think that's the you know the position of the ip is aligned with this as well. I think that you know even pointing to some of these like uh forward-looking research directions that seem to have a lot of support. So far.

B

You know it's very much, the former, not the latter, so there's four force uh I'll, give you a short summary on the latest, um so we have like a very small working group, that's like the co-authors and some people who are interested to help um probably the best way. So actually we just opened a channel on the uh beef r d discord this morning for history expiry, so I'd actually direct you there, um but that even happened in between when I made this slide and now um but feel free to dm me.

B

If you want to figure out how to get involved, I can direct you to where you need to go or go to the ether r d discord, there's a district expiry channel, just like say hi there, and similarly, someone will direct you into some space to help. um I did want to say, like we, we put out the ip and it's been discussed a little bit among core devs. um I think, generally, there's been a lot of.

B

I guess push back, there's been, I think, the main point so far. The main sort of the main takeaway so far is just that, like people want to see more uh from the ip and uh that's understandable so anyway, I've, I would still say we're still very much in like a information gathering stage trying to talk to as many different stakeholders across the ecosystem as we can and that's what I mean when I say it's like you know.

B

If we do change this guarantee, it's almost like a social issue right, it's not even like the technical details are not even that you know.

B

I mean they're important, but they're they're not like the core issue here like cory. Schuh here is, like you know, would you live with an ethereum protocol that works like this is not like. It does today, so point being uh you've probably heard of devconnect that's happening in april, there's a fellowship of ethereum magicians council gathering, uh it's called the og council and anyway, I'm also leading a session there on this eip.

B

uh So if you're there come say, hi or let me know what you think about the eip um and then I just wanted to call out this user abstract df. I think his name's uh ownery or henry either way he's been working on uh prototyping, an actual demo of how the ip would work so essentially saying.

B

Okay, if we do have all this chain history like what are the actual details of how it's laid out, you know in terms of like schema and the data types and all that and then also taking existing like off-the-shelf execution, clients and then giving them an import and export feature to. Then you know work with this history, um and I think he latest I heard is that he's working on an update for devconnect as well. So um should be some some more exciting stuff soon, and I think that was it for me.

B

A

Well, thank you so much. It was a nice overview, great presentation and, as as you were trying to say, I believe, is like readiness of the community for this big change right.

B

Right yeah like if we do, if we do move ahead of the cip it'll, probably be something that takes like it'll. You know it could take a year to like transition right like it is actually kind of a big thing and, like touches many different pieces across the whole stack. So uh first you need buy-in and then the question's like okay. How do you like actually roll it out to users in a way that is like uh nice and then uh yeah just making it happen and like that whole process?

B

You know, will probably take uh quite some time, not a simple change.

A

Yeah, I agree. I agree. I mean this is again one of a kind proposal and I understand that pruning will help sometimes running full node is concerned just because of hardware, and this is a concept that needs to be accepted by the community. If you want to bring this big change right, um but this definitely looks like a futuristic proposal, so I hope this stock will help people to understand it even better yeah. I have a few questions for you. If you don't mind, I can take one by one.

B

A

All right, so we did talk about historical data right. You did mention about how how we can verify the data and who will provide it. So I want to go a little bit deep in it. So how important do you think this um historical data is for normal people running nodes like how common it is to refer back to these data.

B

Sorry repeat the question: how common it is for uh people to use this whole data.

A

That's right, yeah.

B

Yeah so yeah right, I mean that's a great question.

B

um It's a little bit hard to say without, like doing some sort of, like you know, user survey, um which perhaps we should do, um I I would hope to like speak again to like you know it brought like a wider variety of uh sort of stakeholder types during this magician's council, um because again so far, we've really gotten feedback from core devs, and obviously you know we should get many more people involved point is, I would want to ask them and say: okay, like yeah, like you know, I mean I gave sort of an example of like auditing a nurse's multi-stick, like is this something you do like.

B

Is this something you'd want to do like? Do you think that would be an issue for your adapt, your application? If you know you didn't have this guarantee, um how would that look? um I don't like again just like off the top of my head. It's like you know like how often have you gone back like three years to like find a transaction in some block like you haven't. I haven't it's like no one on this call has no one listening to this call has like, I think it's.

B

There are definitely like archival services and, like you can go get that information like there are people who index the chain and they have it. um It's certainly important right. It needs to be available, but, like it, shouldn't necessarily be a burden on every user, and this is what fort force is trying to get at is that you should be able to run a full node without needing to like keep all this history.

A

That's right, I think this kind of question if answered well like if we do not have much tons of users having looking for access of these data. This proposal make a lot of sense there right. So I was looking into some details of the proposal and it talks about the archive notes.

A

So I'm wondering like do you have any visibility on the archive note with state sync functionality, because currently, if, if someone wants to bootstrap his note for the first time, the um the only way is like getting into full sync and with this proposal full sync will not be uh available.

A

So the question is: do you have any visibility on archive node.

B

And just like how how they'll change this.

A

Yeah, you know how I I understand that this is currently under development, and I'm trying to understand here is like is this development will be before the eip444 I mean? Is there any dependency of eip for force on this particular chain? We just don't want to break the chain right. We don't want that. Data is not available. uh What are the backups here.

B

Right um yeah, I mean the way that you would roll out. The uap is like you know, you probably have a year or, like I don't know, we could even say two years like you would have.

A

B

A very long period of like uh essentially transitioning the network to from the current state to the state, and so because of that, like uh yeah, I wouldn't I wouldn't worry about lack of availability like I don't think you know, we wouldn't bring the cip to mainnet without, like everyone being very comfortable, and you know keeping the history around, we would. We would have very quickly answered all the questions like we would know. Okay, you know these players have committed to hosting the history.

B

Here's how we can get it all of that we have like if we need some sort of like shim clients. You know then like that exists and has been like tested um yeah. So I I wouldn't worry about like losing the history um and yeah I mean so archive nodes could be like a data source right where, like, if you're an archive note today, you could basically, like honestly just keep doing that um you could. Whatever that looks like you, could keep running an archive. Node um and yeah provide the same service.

A

Right so you did talk about shim client, so is it like currently available for people to run, or is it something like uh being expected that it will come in future.

B

Yeah, that's like, I think we wanted to see like probably more like uh positive enthusiasm before committing you know the resources to having someone go and like build a shrimp client. um The thing is, you could even just take like, for example, geth today, and you could basically just like. I think with very I mean I know with very minimal modification turn it into the shim client. Like that's not uh you know, that's not again. I think a huge technical ask.

B

uh It might again take resources to like maintain and develop, but it's not like again. It's not this, like big, open-ended research question that we just don't know how to answer. um It's essentially taking execution. Clients like they are today and like either modifying them just a little bit to like parse history, and so that's you know when I mentioned uh unreal here, working on the prototype, like that's what he's doing is sort of demanding how you would take, I think, he's working in gas, but how you would take gath to like to do this.

B

A

Yeah, that makes sense um there is another development work I am aware of. That is like a portal network, so piper mariam, who is the lead developer of portal network, uh was uh with us on this show a few months ago and, as I understand, portal network also proposed different way to use like less bandwidth and usage of light client for running an ethereum chain, and I also remember having some breakout room discussion uh developers discussion on this. So I'm curious to know what is your take on portal network versus eip4s.

B

Yeah I mean, I think, they're certainly complimentary, like uh my understanding, is that uh they're still working on some of the questions around you know the specifics of the pro network, but uh essentially, I think in its full vision. The perl network very much acts like an archive note like that's the way to think about it, is that uh it's just like dht is like decentralized network. That is also an archive like that's sort of a an interface it provides to users of the perl network and yeah.

B

So that could even be like you know you could say all right there we go. uh You know I went back to here to like example, providers like you could even just tack on the perl network right um so yeah I mean definitely they're complimentary and uh yeah. I'm definitely very excited about the portal network and, like hope to to see you know further developments there and yeah. um If four fours uh rolls out then definitely like that could just be another piece to the puzzle. It was like sure you could go to a torrent.

B

You could like go to traditional data provider. You go to the pro network.

A

Right, that's that's quite relieving to hear that because I remember a conversation in which the scenario was like either or or but it looks like it's complementary and that is really good to know. Thank you.

B

Yeah, I don't, I don't see why they would be exclusionary.

A

Yeah right all right, um moving on the uh pus weak subjectivity, you did mention that it's like tangentially, related to the proposal. um So I'm curious like how this proposal is going to help user running a client node. um I suppose this is like after the merge. Obviously we are looking this proposal in a long run so and we are expecting merge before that. So yeah.

B

A

Going to help users run a client node.

B

Right, uh how will it help them run a node with regards to exhibitivity or.

A

Yes, with risk with respect to weak subjectivity.

B

Right, I mean, I suppose so it would imply. You would need less of the chain to download right so like uh if you have like so, for example, like beacon chain nodes today like if they uh like, if you think of beacon node, you have the full history like all the way from genesis now, and we actually want nodes to do this. Because again we want to it's basically an availability, guarantee and yeah.

B

If we move to a four force kind of world, then we change that guarantee um and then yeah, rather than needing to like uh start from some with two week, subjectivity checkpoint and then like sink all the way back. You know to the very beginning. You could basically just like stop one year.

B

If that's the period, for example, you could stop one year behind um and so yeah again, you'd still have all the benefits, the savings in terms of resources uh and yeah. Just now, you're in a proof-of-stake role,.

A

That's interesting. It is really very interesting to know that uh ethereum developers are not just preparing for merge, but also post merch, like what all changes can we bring in.

B

A

Yeah, all right uh so um again from the proposal. This is related to json rpc changes. What are the breaking changes to json rpc endpoints, and what do you think uh like what kind of project will be affected by these changes?.

B

Yeah so, like I mean honestly, that's probably the like biggest, I think or like the most stitches point of the eip, is that there is this breaking change so, like you know, we can sit here and be like. Oh, you get all these savings in terms of like the disc footprint you need. You know less bandwidth to like move blocks around lost compute to verify the box, because you get rid of all this history and that's great.

B

But what that means is that now, as a you know, adapt developer a user of this json rpc endpoint, uh you could ask for some history and your node just might not have it. So. The question then, is like okay. What do I do? um You know the like easy answer? Is you say, okay, yeah, this node doesn't provide this anymore. You go to some other service like in pira and again that gets to questions of centralization and that's like not like an ideal answer again.

B

Portal network would be a great solution here, along with being an archive node right. It also wants to expose this like web 3 interface. So you'd have you could imagine the json rpc sort of api being sort of implemented by the portal network, so that would be really cool.

B

But the point is is that uh there is a breaking change, because today you can ask for any history and you'll get back an answer. um You would not have that with four fours and again this is like part of just having like a very frank conversation of being like hey the way the protocol works today is not going to make sense 20 years from now, so we need to do something.

B

A

Yeah, it's more of convincing community, that's right, uh all right! uh So moving towards more eip specific questions. um My first question is about eip warnings. Some users in the ecosystem seems to be like particular about word, that we use for a standard and eip is a future standard.

A

I'll, be curious to hear your thoughts as a co-author. What do you think the usage of must should may or may not be there in the proposal and how? How far does it actually affect the enforcement of what is proposed with the proposal.

B

Right I mean so okay, those are very important words and I've had many conversations with other developers around. When do you use one over the other so like taking a step back, uh I forget the rfc number but basically like before we had crypto. There was like people organized in a very similar way, working on like the internet right, and so uh they realized that somehow that it was important to when you're writing specifications.

B

For these things, uh you need to be very precise and like there's, sometimes when you have like a feature or an aspect to your protocol that, like it, must work this way. So you use must there's other times where you have a little more flexibility, and then you can say should and again.

B

This is important when you have this like sort of spec driven development or like a spec first workflow, where uh the idea is that you have a specification for some protocol and then now you can have different implementations and, like again, this is a different talk, but it's very key to the ethereum ecosystem that we have multiple implementations. It's like saved the network from like suffering from very terrible bugs in the past and like we'll, probably continue to do so in the future.

B

So we have this, like you know, rich client ecosystem, and so what that means is that these specs are very important, because that's how we all determine exactly what we are are building and so part of that is yeah. You now are writing these, like you know, probably english description uh versions of what the software should do, and so now you need to like be precise, and so we have these words less than should and they help us do that.

B

um You know, uh let's see, I think I kind of went off on a rant. What else were you asking? No.

A

That sounds like yeah.

B

Well, I just keep rambling, so god yeah.

A

I found that there is this conversation and fellowship of the theory magician the discussion tooling, where people are saying that it should be mass. It should be should like kind of that- and I haven't seen that kind of conversation before so I was just wondering like I understand it- is important that whatever we want to achieve with the proposal should be achieved, and this is a big change so giving right.

B

A

To community would be.

B

Right and yeah, and that's the thing where, like uh maybe I'll, think of an example but essentially like you can have something where, like I don't know like the things that are kind of coming to mind, are like more examples from like the beacon chain and like the networking, for example, where it's like uh it's actually very critical. There must versus should like, if you have some validation condition uh that is, should where it should probably be a must. uh That then gives clients flexibility to implement it. You know, let's say either way.

B

If there's two options, then what that means then, is that you've now suddenly partitioned the network, like you'd, actually have a change split um from this flexibility so like there are some cases where, like muscles are important and like you know, if there are specific examples in the ip we could like talk about them, but essentially like that's, that's what this comes down to is like um it does matter, it's not developers just being pedantic and uh it can actually have like implications for security and all you know, usability and all sorts of things.

A

Right, and especially when it comes to implementation for networking proposal, it is mostly on like client right. It's not that it has to go with an upgrade. Then everyone has to be on board at uh at the same time. So when, when it comes to implementation, uh I remember you did mention about someone working on the prototype henry. I think that is there for the deafconnect, so that is with the uh get client right. I'm curious like is there any parallel implementation working on with any of the um consensus layer? Client?

A

Oh, oh sorry, this is just the execution layer, change right.

B

Yeah I mean you can imagine like there might be things. Do you want to do with the kids as a slayer um or like even the same thing, where, like you, have a similar sort of guarantee around only keeping a year of history, um but yeah like this is primarily focused on the execution layer right now and yeah there's been some prototyping work, uh I'm not aware of any other serious efforts right now um that could change.

B

Also, though I do want to jump back to most versus for one second, because, like I'll just give you an example right like.

A

B

A

B

With with the cip is like if the eip was clients, so you know, I believe what it says right now is something like clients must uh stop serving history one year in the past, whereas if it said clients should or like could whatever the equivalent would be um well, essentially, I guess it should.

B

If client clients should do this, then that gives them the optionality and the reason that's a problem is because then what happens is you'd have some nodes in the network that might not have the history and some of that do and then what happens then, is that you have this issue where, like again, it centralizes the history to just a few actors whereas like if we say this thing must happen.

B

As of the cip, it also forces us to say: okay, here's also this, like uh other other way, to get the history like there's some other protocol.

B

If you say should, then you actually like, don't have to provide that and then some people have it, but then over time, like network quality, degrades and it just becomes a mess.

B

So anyway, we'll stop that conversation, but it's it is an important distinction.

A

Yeah right, it definitely will help. I think clarity on this part will help users to intake that.

B

A

All right, my last question for the day it is about the readiness you did mention about. This is a long haul proposal and we are expecting to see it in like somewhere around one year down the line I'm curious like uh when do you think the proposal will be ready for review uh when the spec is all ready or when uh you think the community is on board or like? How long do you think that it will take to bring the proposal to the review status.

B

Yeah, that's a good question, so uh I mean I think that process has already started like again because of the scope of the change. I do think it's going to be this like very sort of ongoing thing that might take a year or more to resolve uh if, if anything ever happens here right, so um you know with writing the eip. We basically getting it out there. It's like now something people can like debate and say, like here's, a specific thing: here's a specific like counterpoint.

B

uh So that's really helpful again. I hope to over, like the next like month or so. I'd get a lot like much broader input from the community. um Again this like uh magicians, council and things like that and yeah. I mean uh I think, even from here getting um I mean yeah. The concrete next steps would be getting some sort of like uh prototypes of of well there's, there's two parallel tracks, there's like prototyping in the eip, because I think that helps people like sort of conceptualize and like actually see.

B

What's what would what would happen, but then also yeah, continuing this process of getting feedback and then kind of like you know, keeping them in sync as we go, um and I still think there are a lot of like open sort of, I think they're still.

B

I don't think the cip is at a place where it's like ready to ship and there's just a matter of convincing people like, I think, there's still room for conversation here and so yeah. I mean that that could take.

B

It could take a year just to get to a point where it's like here's, a formal spec that you know, answers data layouts and like here's, the torrent format and where the torrents live and we've like gotten the furon board and etherscan and like the ef and like they all, are hosting the history and stuff like this, like yeah, that that could take a while.

A

But from the process point of view, what I think is like until the proposal is under the review status, it may get only limited uh review. Comments like even the involvement of community is less still. The project is in draft status.

A

Earlier when we did not have this particular status called review, it was okay to keep a proposal in draft till it is ready for the last call, but now that we have review, we can keep it for as long as we want.

B

Right and yeah so then uh perhaps we remove it to review. um I don't know enough of the details of that process right now to say how that would happen. um Yeah.

A

Yeah all right I mean I'm sure one of the co-authors of the proposal is an eip editor, so you will be getting right directions.

B

A

B

The question: that's a question for matt.

A

That's right yeah, but uh in general I'm just trying to let everyone know that moving to uh review status is not difficult. You just have to create a pull request to change the status, even if you are not fully ready, because that is the period when, when it is open for review the community review the eip editor review, as well as the core developers review. So it's just for review.

A

It's not ready and when it is ready, the proposal is changed to last call where it stays for the next 14 days and after that 14 days, an author can make a pull request to move it to final. So that's the process. I.

B

See that's helpful good to know um and yeah I mean the thing is like I, I think uh I think it's probably somewhere in between like draft and review state where it's like. I think it is more serious than a draft. I think that uh just based on the people we've gotten so far, I think people are going to want to see uh things like this prototype.

B

I think just see like some more answers to like again, I keep losing my slide thing uh more of these questions right like um having really solid answers because that's the thing is like. I think people agree that, like the current state is not sustainable and we should do something, but you know the concrete something is going to need to answer these questions, and so um I think, if we have more fleshed out around how to actually answer these questions, that will go a long way.

A

I'm sure that we can come back on this proposal, maybe after six to eight months down the line when we have clarity on these things, because this seems to be like really important. Questions to be answered for this big change like merge is a big change, and removing history will also be again a very, very big change for ethereum blockchain right.

B

Yeah, I know that sounds good, um definitely happy to give an update and some time and yeah, hopefully by then we we have uh more clarity, at least at least we have. You know the eip. Authors have uh yeah, we.

A

B

Yeah more concrete answers to these questions. That's.

A

Right, that's right! Well, it's time to wrap up. uh So if any final thing that you would like to share with our viewers, ethereum developer community, with relation to this proposal or in general.

B

Yeah, definitely if you have feedback or you watch this and it made you excited or angry or something like. Let me know: um yeah and yeah, we'll see we'll see where the iep goes.

A

Well, I hope the information shared today will help the community have some background and then they collect their thought when the proposal is actually available for review.

A

So yeah people, please make sure um you follow the discussion tool link uh provided in the eip to share your thoughts. Your comments, if you find something, is going wrong with your tab because of this proposal come forward and share that with developers and yes, one more thing I I missed to mention it earlier alex had been on our show uh to provide a talk on beacon chain, accounting reform, which was after the altair upgrade.

A

So if you have missed it check out the episode 34 to have an understanding of rewards and incentive on the present beacon chain, which is like, after the first upgrade and uh concluding the episode on behalf of ethereum characters. I thank the guests and other participants to join the call thanks our youtube viewers for watching and sharing your feedback and comments.

A

Should you have any question reach out to us I'll leave it as a comment reach us on the feeding category check out the description box for all the related links subscribe to ethereum cathedral's youtube channel? If you haven't done it already and next week we are going to have another interesting proposal that is eip4337 that account abstraction via entry point contract specification, so stay tuned. Keep watching keep sharing your love with ethereum tackle. It is have a good rest of your day. Thank you. Everyone.

B

Thanks everyone.