Ethereum Cat Herders PEEPanEIP, 26 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Peep an EIP #10: EIP-2935 with Tomasz Stanczak

Description

Presentation: https://docs.google.com/presentation/d/1RlT4lL2dfqFDbi0B2rNEagiG5OeIOc8xIFiTMCTzcY0/edit#slide=id.ga49406d9c2_2_75
EIP: https://eips.ethereum.org/EIPS/eip-2935
Discussion: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565
The Life of EIP (blog): https://tkstanczak.medium.com/the-life-of-eip-8031e2c079d1
Ethereum network upgrade (survey): https://docs.google.com/forms/d/e/1FAIpQLScc1vrOXzaoFQZ4uuy2oJnWGibRGSs7anZPyzEfuWGhTTt8pg/viewform

Follow at Twitter:
Tomasz K. Stańczak @tkstanczak | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369

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

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

A

Welcome back to another episode of penny and eip focus series where we are trying to understand details of an improvement proposal and why that is needed for ethereum network. Today we are going to learn about eip, save historical block, caches in state and our guest is thomas stanza, who is also the founder and cto of netherman thomas great to have you on the show before getting into the proposal. Let our audience know a little bit about yourself and how you join the ethereum community.

B

Sure yeah hi thank you for the intro. uh I've been working under my client for the last three years as a developer, and because of that, obviously I have interest in the changes to the protocol.

B

um That's how I ended up on some of the calls listening listening listening and after a while, I probably started talking a bit um and 2935 is in particular one eip that I'm really interested in uh one that I think that can bring some simple, yet powerful improvements.

B

So if we find with this intro, then I'll be happy to introduce everyone to the ap. Okay, great! Thank you! So much uh so, as you see the name safe historical block, hash is in state, so you may know that. Currently we have okay, all right so having historical block hashes in state. uh As you know, we currently have an op code.

B

uh That's called block hash, which allows the virtual machine to query any block hash up to 256 block hashes before, and this block has nowadays is used, probably for some verification of headers for the recent events, uh but also by some is used for the random number generators, um maybe not the best solution, but by many just treat it as the simplest one for for some non-critical situations, when you have to do some randomization and erp2935 suggests something relatively simple.

B

uh It defines the blockage. Storage address. Add this address fff with e at the end, because we use, I believe, ffff. All f's is a system account, and here we stopped here at this address before every single block before all the transactions in the block are executed. We plan to. I call a single s store at this address that you've seen in the previous slide, and we push a block hash there at the storage slot and the number of the books.

B

So we can save the storage as block 12 million, for example, and the hash is the value in the storage. So the s store always takes address as the address of the contract and the index in the storage, key value store and the value will be a block hash of the parent block. So we don't do that in the given block because we don't know the hash. Yet, when we process the block, when we're verifying block, we don't know yet what the state route will be.

B

We only calculate it after processing the block, uh which means we push the parent block hash to the state and because of the way the storage is stored. At the moment, you end up with a merkle root, whether it's physically on the on the disk on the storage device. It doesn't matter, but it's important, that you can construct proofs and you can get the storage root of that merkle tree of all the block hashes and you can use those proofs for any use cases in the future.

B

And how we do that, so we extend the block hashtag code later, for uh inclusion of any range request beyond 256 blocks, all the way to the fork block for the eip2935.

B

So if, if the fork for 2935 happens, that's 10 million 500 000, then we can ask about the block hash of that block, even in the block 11 million inside the email. So suddenly the block cache upload is much more powerful and can be used in other situations and also because of storing it in the state. Instead of having this magical additional requirement for evm to have access to the last 256 headers, which are really outside of the state in the way we see the status world state of accounts and storages.

B

So instead of this, we can just reach to the storage of the account.

B

um What are the use cases and they can be collected from discord channels and ethereum magicians and if research generally mostly will be talking about wi-fi lifeline thinking like fight fire and uh less even stateless ethereum. Why? Because we need to build weakness and witness has a bit of difficulties with dealing with block cash hop code, because suddenly you have to include the block headers in there in the witness, which is not very convenient either.

B

You need to require the all the stateless clients to actually keep that kind of state of last 256, headers always and for for blocks that would be from the past. You would have to request more and more headers to have this full verification um or yeah in this. In this solution, when you have to 935, you can include the block hashes within the witness itself, because it's just just treated as the storage, the same way as any other storage, uh historical header verification.

B

So whatever you can do now for the last 256 blocks with the header, you can do for anything from the past, so you can imagine off suddenly being able within the evm to start talking about the state of the account in the past. So you can imagine of the questions like if you can prove me that you've ever had on your account, um given balance of. If then I'll do something, or if you can prove that you've ever been an owner of something uh in the past, then I can do something.

B

So nowadays, it's not possible because evm has only access to the current state. If you can reach for any historical block, then you can provide a proof that is variable verifiable against the state. Truth, that's within the header and you can provide the header as well, because you have a block hash, so you can verify that header actually existed in the chain and you can do that all from the evm and some of these questions are only related to the header.

B

So, for example, can you tell me what was the difficulty of the header from um one million blocks ago, but the other ones can actually ask about historical stain, and this is quite powerful. I mean you can create lots lots of different products based on that.

B

Where are the links so 2935 link itself?

B

If I send this presentation later, if it's shared, then you'll be able to just use those things for convenience and there's also if research, which mostly discusses my client like client use cases, and there eip2935 is suggested as one of the powerful solutions a bit like a compromise between a perfect solution and a very slow solution, I mean not compromise, really like something in between, but much closer to the perfect solution. I think um there is a implementation done in nethermine to one of the branches, so feel free to look at that code.

B

I'll show it to you in a moment. I did a magician's link and this one, I believe, discusses a bit more the uh the weakness and also compares the 2935 from the previous approaches to the same thing. 2935 generally, it's very clean and simple compared to previous solutions. Previous suggestions, um they're both authored, like both main suggestions, 210 and 2935, were suggested by vitalik, but this 2935 was a bit of a huge simplification over the previous approach.

B

um What's for the discussion based on the implementation, though, in a moment whether the change in the block, hash op code should include the gas codes, change to the s load calls because suddenly block has become s load, but it's only s load for the very first transaction in the block and later it can be cash, I guess um or but if we have 256 blocks in the past, and if we don't create some additional structure for those, then then it's really slowed on the storage. So that's a bit of a question.

B

My my preferred solution would be to introduce another op code, potentially long block hash. um That would cost more because then we don't change the cost of the existing op code, suddenly from 20 to 5, 000 or like 200, sorry on the slow.

B

If it's repeated- and there is one more thing, because the current solution suggests to store the storage on the address that doesn't have the contract code, it creates a bit of maybe nothing very bad, but suddenly it's different than what we used to um there exists an address on the chain which has storage but has no byte code. So my suggestion, my suggestion here is to deploy a bytecode at this address, with a single stop instruction there. So one byte byte code that can be used as a okay.

B

There is some contractor, so it's fine if there is storage and that prevents the clients to have to handle some special cases uh when we have they like touch dead accounts and remove the account which is the remnant of the past, of the cleaning of the accounts after the shanghai attack, and that's it for the presentation. I'll show you the source code as well quickly.

B

Can you see the source code? It's not uh uh it's literally source code, another minecraft, it's really cool. I changed society to variables for you to read.

B

There is also some kind of pseudocode that the specification so generally, depending on the three numbers, really the current block number the requested block number for the hash and the transition block for eip2935. We define the behavior. So uh if we are within 256 blocks from the transition, then because we haven't filled yet all the all the historical block hashes that we could normally ask about with the block hash op code as it is now, so we behave the same way as as the block has behaved before.

B

So we have some kind of access to the block hashes for the last 256 blocks, and we ask about this requested block number later.

B

If, if we're beyond this 256 transition period, then if we are asking about the block that is after 2935 transition block number, then we- and here is a suggestion of actually charging s load cost on the over the block cache requesting from the storage cell of the block, hash storage requested block number.

B

We just read the storage cell and the storage from the storage cell, um and this is the block hash that we return and if we asking about the block from before the fork, then we return zero because we simply don't have it in storage. We know that we don't have in storage any blocks that were created before the transition before the e4, and that's it really.

B

So that's what it does, and there are some tests here mostly for telling us how we should behave, whether we should use old style block hash or the new approach, depending on what the transition block was. The current number was the requested number, and this one tells us which behavior we should pick.

B

um So you can analyze it in details, but the op code here is quite simple, so we just push the requested number, we call block hash and then we load the store and sorry we start in storage, and then we verify uh if, after loading, uh okay, we verify what was called whether we called the block hash provider as it was in the past, or we read the storage cell. So this this can be obviously different for different clients, the way it behaves, but these test cases can be easily used and adapted for different clients.

B

Also, the clients will have to test the the behavior at the the transition um boundary so at the fork of whether we start to save the block hashes in the storage before the block execution, so you can think of it. This is a bit like a additional 20 000 gas cost of storage before every single block, but it's not really 20 000, because um because we don't really need read before saving we just save straight away, so it's much cheaper operation than executing it in the in the virtual machine yeah. So that's that's about it.

B

I guess um if there are any questions or maybe suggestions that I missed something that would be important to add here.

C

Sure um I'll jump in first of all thanks a bunch for showing the code. I think that's really. I think that really gets like a good sort of hands-on feel for what's going on with the eip um just a few, maybe basic level questions, maybe I'll, try and zoom in on a thing or two does this affect full sync at all?

C

If we're changing where the block headers are, should we see some kind of change in full sync, also to the best of my understanding right now, full sync stores, the last 256 blocks fully, which I see is the same number- is that affected in some way by this.

B

So currently, both the full sync and fast sync will most likely download all the headers um from genesis, or at least from some um some hard-coded block header, but this is only if you trust the block header, so this eip assumes that you no longer have to create some kind of external source of truth about what block hashes were there in the past, so clients that follow less last protocol, the the light client protocol is defined by geth may actually use it instead of checkpoints, I believe for for loading, historical block, hashes.

B

As for the storage, the storage of all the block headers is around 8 gigs. Currently, I believe, depending on the client implementation downloading, all the headers may take between 15 minutes and 2 hours. I believe, but this requires quite a powerful setup when you have lots of parallel connections, any any light clients that try to operate from uh very weak machines or from the browsers. Potentially they wouldn't really do that, because downloading headers will be really like a networking nightmare for those.

B

Yeah- and I guess it answers your question in a way that is 256 headers. Yes, they are currently downloaded and maintained by all the pulsing fasting clients. As for the light clients most likely, they have to load much more headers than they would like to just because of this block hash potential block hash code and also like the same for stateless clients as they would appear.

B

You have a bit more pure verification of the block itself and the witness, because you don't have some externality to to all your analysis.

C

I believe so I mean so full sync should remain the same thing even with the change in how the headers are stored and, in fact yeah. So.

B

It remains the same in a way that you, don't um you don't decrease the storage requirements of the full sync, but the benefit of not not loading headers in full sync would be negligible, because if headers are eight gigs or even less right and obviously the full sync will have one terabyte plus of data, uh then.

C

I didn't mean archive, I meant uh with archives.

B

C

B

Pulsing, as the you'll have full state, I mean, if you can think of approaches that we took at nedermind, where we uh allow users to decide not to download historical headers, but we actually suggest not to follow that option. So so it's not default.

B

uh You can skip those, but then it's not super healthy for the network, because others cannot really ask you about the headers. We use it for beamsync and in the beams in case. I think dcip would help as well, because it gives much more much more easier. It enables much more much easier verification of the headers that you start from.

B

You can start from very late headers, instead of either hard-coded, headers or or even worse, genesis just by sampling from different other uh nodes on the network, like the the music, then because a bit like fly client in verification of the uh fly client in the verification of the hashes of the block hashes. But then it uses some state requests just to get state quickly. So you have everything together without downloading any any big structure, whether these are headers or bodies or transactions or state.

C

Interesting, um I mean yeah even on the full one. It's not archive, however. Large full sync is right now, which I think may depend on how much gets flushed onto actual storage. I mean the eight gigabytes of fedoras is still going to be negligible, compared to whatever states being stored being stored on full.

B

Yeah, I think the full client in this uh most minimalistic form would be around between 60 and 300 gigabytes, depending on whether you include bodies and receipts uh yeah.

C

So this eight gigabytes.

B

Of uh headers is like probably the most essential for security at the moment, and also a bit at least heavy part, because headers are just quite light. I mean 512 bytes per header.

C

um I also wanted to zoom in on light clients a bit um I'll admit. Some of this is likely my own ignorance about how light clients function, but I was wondering if maybe you already started answering this and the answer to the last question that maybe, if you could talk about um how this eip would help light clients as in what allows a light client to be so light.

B

Yeah, the the light client, usually I mean when we think about light client- is something that should exist with minimalistic state if possible, right, so something that sinks very fast, because it doesn't really require everything to verify the full blogs potentially or just just something that is necessary for the blog. So how can you? How can you execute a lite client here?

B

If you just want to execute a transaction, then you may potentially request just the proofs of your current balance for your account. So I base, I believe, that's how last protocol behaves. So you can connect you download some kind of headers tree with the checkpoints that are stored on chain and- and here it's a bit of like uh unpleasant thing- that those checkpoints have to be pushed there by someone.

B

So you have the external influence over what is true and what's not, and then after you verify what's the longest longest chain, you can start asking about the proofs of some parts of the system so like it could be. Give me a proof of the account balance and then I can create transaction based on that. So that's one of the approach with the light client agree.

B

The beam sync is a bit like light client on top of the full sync fast sync and the the light clientness of beamsync is that it also downloads just the state that it needs for executing transactions and verify particular accounts.

B

But it doesn't ask for proofs, but it literally asks about the physical representation of the stage tree and again, if those clients they the mimsync and less, are to execute very fast and with minimal storage like we just proved so, potentially with just few hundred kilobytes or maybe even less of data, uh then we don't expect them to download eight gigabytes, because while we were talking about eight gigabytes being negligible in other cases here, it would be a huge part of of any data, interaction and downloads like impossible to download in the light in most nightland scenarios.

B

In many at least, um if you have eip2935, then you kind of um you are able to start sampling these different headers from different nodes on the network, and you can also for the winner nodes. You can verify if the samples really exist to the chain. So so you have like additional strength, additional force of verification.

C

I think it may have been missing. How does that avoid the need for headers, as in before the light client needed to be able to verify headers, which was pulling it into the situation where we need the eight gigabytes which, in a lot of the cases in the browser, mobile data? Things like that becomes like this huge burden.

B

Sorry um in the past, it didn't need to download uh eight gigabytes of headers, but it would use some kind of structure to avoid it. So the last protocol suggests this uh headers trees, like the the merkle trees header, something like that. It's called chd um headers, three, something header street compact industry, whatever uh the but but those structures are like not exactly natural in a way that there are a very strong like some additional object introduced by protocol and has to be pushed like those.

B

These hashes of those structures have to be pushed to some contract on chain, ideally or or you can.

B

You can ask about those and collect some kind of miracle-proof verifications, but it's it's a bit awkward just a bit and- and you can avoid it here, for example by knowing- uh which was the header of the fourth block and then sampling different headers from different nodes. So, like the way the fly client does and then after you start requesting state from the longest chain, you can also verify those those headers that you sampled, uh if they're, really on chain according to the longest header that you know so.

B

D

B

They for for light clients- maybe it is not- I mean for fly clients. I believe this. uh This just simplifies some structures like uh and necessity of, of requesting more data.

B

I think here I I suggest you for the light client scenario to go to the f research and there is a great uh discussion about it from cena moody.

B

I believe, if I pronounce it right and and that's where it'll be great, to ask those questions as for the weaknesses, so obviously they're, uh you simply don't have to have those headers anymore, because you can just include it in the state weakness and for anything defy or or historical accounts scenarios.

B

So this is just simply solved by having access from inside the virtual machine to the block cache.

C

I understand, and maybe just a last one from me- um I I'm not sure I understood you 100 right about when you were talking about stateless um in order to really leverage eip 2935 for stateless. Does that mean that there's also going to be another piece of information that would be being stored here or with stateless, also leveraging just the historical block, hash itself.

B

So there'll be less information required because imagine that you have a block nowadays or a transaction that invokes block hash 256 times for every single number available to ask about.

B

So then, alongside the block witness you have to include also those hashes and now the way the block weakness is delivered is that you can um yeah, so you can either provide it in the form of proofs which might be a bit inefficient or in a way where you actually com, compress it and you you hash it and include it in the headers. In the second scenario, you can you have just the ability of adding those 256 headers as part of the weakness, but the verification of those headers is.

B

Yeah I mean like it would have to be included in the header hash in a way.

B

Here you can, you don't have to have any any additional complexity into the construction of weakness. So whether this is that's super important. That's another question I mean like it just makes the block witness more unified. It's uh the block. Hashes belong to this state weakness like if the. If you call block hash, then what you do now you you have to have some external structure of headers.

B

What you will do after 2935 you'll be just calling the storage access of the state, so it will be like any storage access, which means that it uh confirms with this standard operations that you do for the weakness, construction.

C

As in the call is going to be the exact same, it could be depending on how stateless develops that we'll have different styles of information that might be stored there, but it's always going to be stored at the same place.

B

For the weakness or yeah so like this will be part of the state. If, if it's tonight, free five weather will have other other parts of information in the weakness and block weakness, so we want to make it as um as small as possible.

B

Obviously I mean the big questions about the weakness of the block.

B

Are the called mercurization so how to include the just just parts of the code that you access when you execute smart contracts to avoid um some kind of attacks on weakness sizes by calling lots of accounts that have very big code sizes and the the block hashes I mean calling the storage and accessing storage may even like make the weaknesses slightly longer, potentially than if you construct the weaknesses with the hashes but a bit more powerful and they like ability to verify against the state route.

B

You don't have this like awkwardness of having some kind of set of hashes that you don't verify without having the full headers.

C

Okay, great thanks a bunch.

A

Thank you, william. Now, moving on to the next section, it's not so very technical, uh like a little non-technical but related to the eip and the process. um Taking a little tangent on the eip uh about the recent article that uh that is published by you. uh um I know that you're not only a developer, but a researcher in this space, and you keep sharing your thoughts. So last friday there was an article on the life of eips, which is a good read on the process part.

A

Can you share your thoughts a little bit more from the article with our audience and also about the expectation with the network upgrade process.

B

um Yeah I mean like just thinking that probably I only call myself a researcher here, but I was like looking at this space of vips for sure, so I think I'll try to use this example for a for visualization of that process. That is a bit more eip specific.

B

So in this article of life of vip, what I was trying to suggest is we had a discussion in the past about eip centric upgrades network upgrades where we, instead of collecting a few eps into uh um into the next network, upgrade and bundling them together, testing them together and creating the like.

B

Every few months we were thinking of a solution where each eip separately can be approved and when it's approved and tested, then it can be pushed to your main net fruit ass net, independently of all the others, and uh they, the eip centric solution had uh maybe had a bit of uh it wasn't fully described of how exactly we test the cip specific upgrades, how we create test nets for those, but recently we started creating those tests for ip1559, where two or three clients were having um ability to synchronize together a network that was specifically designed for testing kip1559.

B

And what do I mean by specifically design? That's the network was defined as eip1559 enabled, and this is obvious, but it also had a tool for generating transactions that specifically addressed various test scenarios of eip-1559, so various gas costs, gas prices and so on now, in this eip, centric solution with eip test nets for any eip that arrives as it would be, 2935 a proposal or community or whoever is championing the ap.

B

They would have to convince two of the clients or three of the clients, depending on the uh on the threshold. But I think two would be sensible in the current state if you have two clients that implement it and can synchronize a network that you define for them as the like genesis, file or chain spec, and if you can provide a tool that generates transactions that verify the behavior of of this particular eip.

B

Then you provide the client implementers with a very strong testing tool, because not only their test scenarios, but also they show you that they can synchronize with some other client implementer and now not only the testing but also immediately. It creates a arena for the community for researchers for or ethereum users to actually download that download those clients in the branches and just experiment themselves with with this particular eip, and it means that you can test various behaviors.

B

You can give it to the to like researchers of the economics of the network, to the security researchers and so on, for the initial scanning and reviewing and then only then you can actually say: okay, so it's it's implemented into clients, it tests it and so on. So you can bring it to the all core devs and then the on the alpha devs channel. You can say: oh yeah, okay, so here are the problems with it. And here are the already some answers we can ask.

B

If we have some new ideas, we can continue researching it on those test nets that we designed.

B

But if every is fine, then you just the next step is implement it in other clients and potentially define design the the gas costs, because you already have it running so you know how much it costs and then push it to test it if you're happy, but it can be quite independent and at the same time you don't have this strange thing that now you would like to make the ips independent, but because they're always bundled with lots of other erps that being tested, and you don't really have that test nets to to make them properly verified before they go to maintenance yeah.

B

So in in the case of 2935, you could create a 2935 test net that would uh store block hashes and would allow people to deploy some contracts that already use that play with that.

B

Synchronizing clients launch the network, and only then it could be push to main.

A

Great, thank you I mean people need is about improvement proposals and personally, I am also involved with the ethereum process, uh the eibip group, and there we are discussing about the network, upgrade process that how process should look like. It is very much similar to what you have tried to describe in the repo in that article, and I think I can share my views here in parts. I also agree to the idea of shipping, as proposal is ready, because that's the core theme of having an eip centric.

A

However, the frequency uh uh we are not very sure of that, like what it will bring for the node operators like if it is too much for them to be upgrading very frequently or what so uh we, the cat editors, are also conducting a survey on the node operators to collect data to understand the feasibility of this proposal, and nevertheless this is a very good read for people out. There must give it a read and also, if you are running an ethereum note, share your feedback with us.

A

I will leave the link for this article as well as for the survey in the description section uh below so. My next question to you, uh thomas, is about your experience as an eip leader. I'm not sure if this is your first eip that you are championing.

B

Yeah yeah, it's the first time, I'm taking that wrong.

A

Okay, I mean because when when we are talking about a proposer or a champion, especially for the core proposals, it it already comes with a lot of complexities of clients, agreement to implement and push it through. The network upgrade. What has been your experience so far leading this proposal.

B

um I I don't think I have enough experience to actually share something more here. Well, it's it's the first time, I'm acting here as a champion of this particular ap. um I implemented it. I understand it. I didn't yet create a bigger discussion. I I hope this is stay in the start of a potentially bigger discussion and yeah, I'm like so it's too early to talk about experience, we'll see in um in a few weeks or in a month.

B

Hopefully I would say we'll see in two days when it's already implemented by everyone, but I don't think it all.

B

A

Great, thank you so yeah. I think I am good on my part brent. Do you have any questions for.

D

Yeah I had one question: I'm not technical, like you guys it's fun to listen to you guys talk, but I always assumed it was a fairly easy task to prove that any particular address to prove a balance at any block since genesis, but something you said almost made me think that that wouldn't be possible without 29.35 or something like that, because, because we're working on a historical voting mechanism that will allow people to vote their ether at points of time in the past, not just current but anyway, yeah will 2935 be required to prove uh address, has a balance at any block.

D

B

uh Yes, so uh if you want to verify the balance of an address from the past, then you would need 2935 if you want to ask about blocks beyond 256 blocks in the recent history and you'll never be able to ask about that balance from before the the fork before the network upgrade. That includes dcip2935, because so far we are not planning to feed the historical hashes. It's possible that I think it would be not very nice to do that. So most likely won't do that.

D

That's that makes this very critical for our our stuff. So how do I sign up and say yeah yeah yeah vote for this? That's I.

B

Think that's why I say that people probably don't appreciate how how powerful it is, uh how many cool I I'm quite sure there will be lots of products that will appear in the space in defy, as you showed on some voting solution um that will be enabled by this eip. So I really like it, and I think it's simple enough to to bring that and there'll be some creativity from people. um What do you say like it is possible to verify outside of the of the avm like with the data from uh from ethereum chain?

B

You have to download all the headers and then you can verify all the historical states and then, when you do that, you can potentially like sign it with the group of voters that they validated it or something. But if you want to do all of that on chain, then you won't be able to do that without 2.35.

D

Well, yeah one of the possibilities. We would have a server that would download the entire chain and and and just store the addresses or how much ether was at every address and then once someone signed and proved that they owned that address, then they would count that ether for that vote at that time and stuff like that. If that makes sense.

B

Yeah, so this this is the only solution nowadays, but obviously it's not like you have to introduce some trust for someone from uh outside of the chain that they actually um don't deliver the incorrect data with 2935. You can verify it inside the avm. I'm not saying.

C

It'll be super.

B

Cheap but it should be relatively cheap. I think it should be around 20 30 000 gas, for verification of the account balance, I'm not sure I've never tested the cost in gas of the uh proof, verification of the account balance, but I don't think it should be too hard. It's a few error piece, uh yeah a bit of data, so maybe fifty thousand girls, okay, cool. Thank you. So much.

D

A

Cool so recently, in one of the codex meetings, a list of uh proposals was released that was considered for yolo, v2 and v3. That may eventually be deployed in berlin upgrade, so this erp could not get into that list. My understanding was that there wasn't enough information around. I hope, after this episode uh it may may get on the list, but that's not on me. It's on the codex to decide. We thank you. So very much elton is to join us today on people and talk about this proposal.

B

All right, thank you, so much for for allowing me to to talk to people and preparing all of that, and uh probably also there'll, be some more work from you to to actually distribute that so upfront. Thank you so much for that. It's it's massive help to to promote it, and it's like uh almost feel like you're, more of a champion here, like you, didn't work. Thank you for that.

A

Thank you. Thank you for your kind words for people watching us on youtube. You may find twitter handle of the mass and rest of the participants of this meeting in the description section below. You will also find the link of the eip and the presentation and everything that was discussed here I mean like not the code, but yes, you'll, find the relevant links in the description.

A

If you have any questions, comments and concerns about this or any other proposal, or if you have a suggestion or which proposal should be included in the next episode, please leave a comment uh if you like it share it with other community members. Let them know about the people. This is the first eip focus series. We tend to keep it going with lot of proposals to be discussed and upcoming episodes do like share and subscribe to ethereum cathartis. Thank you. Everyone.

D