Verkle Implementers Call #13

Transcript

okay this is veral implementers call number 13 and issue 958 in the PM repo we have a few agenda items today um just a few actually might be a quick call uh after we go through some updates guom has some updates on the shadow Fork as well as the test net um there is if uh if we have time and uh Pavo is here we have uh agenda item that we did not get to last week the uh proposal for code packaging and last up on the agenda we have uh gender on EIP 2935

blash so yeah uh anyone have any updates they'd like to start with okay I guess we'll start um yeah so there was a shadow Fork we're gonna talk about this uh like yeah in more details in a few minutes uh we yeah that that involved um some reworking of the curtois tooling so I don't I think par is on holiday this week so just mentioning that there was some Dev work involved and they did a

very good job to to spit things up so that that really helped um otherwise yeah I'll I'll let ignasio talk about the investigation he did uh also ignasio worked on the replay so if ignasio you want to say something about this uh but yeah just before uh book we we had we we were discussing with other teams to try to investigate bugs on the test net uh I did some work on the transition tool for test in so there was a back and forth with Mario who's also not on that call today um and uh yeah I think at this point it's clear that we need to start working on I me I'm saying we uh gu

needs to to work on the rebase of veral on top of Cancun because we we had the wholey shadow Fork working uh but uh yeah now we need more more data uh to to keep testing to keep pushing and uh and that will come with sepolia and Main net and I think at this point it's clear that we need we need to get that um otherwise I think in the next week uh I will work on so that rebase it's not going to be done in a week but uh at least make some progress on that um because there there are also some developments in in gu on the GU side that we're going to reactivate archive mode hopefully uh in the next release

and that's good point this a good moment to to also integrate moreal code and I want to start investigating the the Chun fi cost uh that that were part of the of the EIP 4762 that we're not we're not integrating on the test net currently I don't think we should integrate it for the time being still but I would like to to spend some time on that and yeah ignasio did two things so I'll uh I'll let him I'll give him the floor yeah will get a quick update um so apart from some fixes that we did for cing regarding bus that were present that we

discussed in the previous call um yeah I'm working on some um have this replay chain uh replay of importing a chain and now on rebase um fixes that we did on coent in the last weeks so there are some problems there I have to investigate but apart from all this main like main stuff I try to um make some progress on trying to answer this question about if in bural trees we have a de Spector regarding making a branch deeper than expected uh all this was motivated by the plash discussion and um if like

using ring buffers is problem or not and things like that so I think I just wanted to make some like more um I wouldn't call formal approach but trying to see if this is really a problem or not and put this problem to rest hopefully if we have to do something about it or not because it's very confusing to people um if if like developers have to do something about it or we have to change the Perle tree design in some way or not so what I did I will just talk very briefly about this because I don't want to get into details I share in the in the chat a hackmd document that I shared with um godri and

Kev some days ago so they didn't have much time to review it yet uh but I got some feedback and the the idea here is to to do some semi naive attack on this kind of BOS Vector um because like we I think that the summary of this topic is that we have to answer two questions the first one is what is like a practical result that an attacker can achieve um on producing a branch of a particular depth so let's say that the expected worst case depth that an

attacker can achieve is 13 or 15 or something like that so we need like have an idea of what is that number so that's one question and the second question is we need uh some idea from execution client teams if updating a branch of this depth is really a big performance hit from for them or not so I tried uh to answer both questions in this document I did some kind of P code to um generate a branch of a given prefix and I have some numbers on different CPUs which is are obviously not really that powerful compared to

what an attacker could have and also I created a benchmark for GU into to understand better how much time it takes to update the roots of the tree on different um branches with different depths as to try to have a sensation of what kind of depths start to feel somewhat uncomfortable and I did this in two setups uh one in my desktop CPU which is a semi modern CPU let's say and on a rock 5B which is like a really really low um Hardware um yeah so the bottom line here is um I just

chatting with go that was giving me his feedback now and it seems like the like a reasonable number to expect that attacker can achieve is a depth of um 13 or 16 in that range uh so that's a good ballpark um to have in mind and now it's more like trying to answer the question if having branches of this dep is really really a problem to for clent l or not and I how do we get yeah how do we get 13 to 16 that's very high I mean 10 depth of 10 would be 80

bits and I mean 80 bits seems like a very like I think you can use yeah you can get higher using collisions but collisions um are not going to give you the ability to attack a specific address you can create Rand ones that are deeper but if you want to attack a specific contract say that stores this ring buffer then you have to um get a pre-image and I would think that pen would be hard and I think like I expect like attackers to get at most to something like eight right I mean maybe got want to

talk about this but I think that was exactly his conclusion I think that this 13 to 16 is considering a collision not really like a specific Target of address so right but that is not relevant then to attack uh something that we want to store in a safe course at a specific address right yeah correct I mean if he if it wants to attack a really hot Branch it shouldn't be like reasonable to expect that kind of depth so yeah I think that's a good point to to to clarify um so maybe like yeah a more specific attack to a branches around 10 and 13 um yeah I mean 10 is really is is very very hard um I think like realistically

like yes like if we want to be strict and say we want 28 bit security then it could be uh up to 16 I guess but like realistically this is not like this this attack is not going to uh like bring bring down etherum it's just going to make blocks slightly larger or slightly slower to process uh so is someone going to invest trillions of dollars to attack it no like I think like maybe we can like set the cap at 10 billion dollars or something and then I think like like yeah 10 is really the max that I could ever expect cool yeah I mean this is exactly

the kind of let's say conclusions that I was trying to um find so that's very helpful I think it's still worth that each client does this kind of Benchmark to see how how big of like how much time it takes to update the root node on different branch depths just to be sure because get is maybe using a library is very optimized um but yeah this is very helpful I think go three will we still talking so is this still only about the block hases uh not really this is like a more General concern yeah oh okay I see I see because for the block hashers I think it's not really a concern like because

we have to Brand use that gr at most once per block right because we can batch all of the transactions together and so both the size and the access times are pretty bounded I would assume yes yes uh well yeah I got for is right in the chat but maybe we can keep with the updates jump back to this topic if you want to keep discussing cool uh any other updates yeah hello I can wait for the

N uh so on our side the Constantine Library uh which includes all the mat remes for veral as is complete and is on par with uh with get and in parallel we are also starting the integration into the nas clant um um yeah that's it thank you um yeah I'll just give another reminder that the pedison hash um the serialized commitment method that we're using in patteron hash is being

changed uh this is a breaking change for uh I think Nimbus needs to update and I believe never mind uh everyone else I've sort of pushed the branch or PR to um do the update for etherum JS we have worked a little bit on uh developing a pre image manager which Gabriel if he wants to talk more about uh on DOA side I can also pick up the rebase to dup so that I can support gam in his uh re

and yeah that's yeah as uh condition was saying we've developed pre-images manager to be able to handle uh preimages saving on the etherum JS C which is necessary for the transition uh we initially had a puc that through testing we noticed was missing some things that happen at the Block Level and not transaction level like withdrawals preimages as well as the coinbase so that's been uh addressed and it should be merged into the production ajs client this week um one thing while we're on

ethereum JS we had a meeting and I think one thing which is going to uh stop the full integration for eum JS is the fact that proofs are being serialized on the vericle tree um sort of layer we I think it was brought up a while back are we ready to sort of only make proof serializable and der serializable on the IPA sort of on the cryptography there uh so you mean like having opaque proofs yeah so only the cryptography can dilize and sort of make sense of what it is

um yeah I mean we could it's just that it's such a nice tool to debug I would rather push this as uh yeah make this this change as late as possible but we could we just have to write something that thiser realizes uh like if if you take Dora for example the Dora the Explorer which is the Explorer we've got uh we've got on the the block Explorer we've got on on kelen um you know I just take I just take the Json and I I dump all this information ah right but you mean the cryptography that would only be the cryptography yeah I guess we could do this uh you would just need to provide a

uh I don't know yeah do you have a write up of what you would like and then we could make it happen I guess um I don't have a write up but essentially everything that we considered the proof uh is now just an opaque bite so like CL l CR um like every um the things that I think wouldn't be considered part of the proof would just be like the keys and values because the cryptography doesn't need to make um well it does use it but I think verle also uses it so that's not sort of considered a part of it I can write up a an issue for it just to be more concise yeah if you don't mind then we

can just refer to it and implement it any other updates cool okay uh up next Gom with the shadow Fork yeah so that's going to be very short um the there was a shadow Fork of holisky there's um yeah that that was like the the simplified version of it we

were not running any transactions but it was it was about testing that we had we we could perform an overlay transition with with the right uh you know real life data um so it revealed a lot of issues namely that uh there was there's a at least in gu but I'm sure in every other client there's a there's a reury problem you have on the one hand the the minor that produces blocks and on the other hand you have U the the API engine that can potentially preempt and and cause some some issues so this got fixed with a simple lock of course uh which is not as efficient as as I would like but

at least the proof of concept is there the the more test need to be done more refining uh of the of the Locking uh of the Locking System needs to be done but at least it it's uh it's proven to to be working um so there's a branch uh it's a PR that's uh that's on gu on the guest repo more exactly my guest repo that's called um I'll actually just copy the copy paste the pr in the chat uh but it's called post Genesis transition position and that's the branch that uh that you want to look at if you're interested in looking at it but uh there

will be more updates to that Branch as as we keep testing Shadow Forks uh yeah that's pretty much it unless there are questions cool uh did you want to keep going with any updates on the test net as well G ah yeah uh right so the test net so I will share my screen for this one um where is the right that's the that's the window um so as you know there's this um this page that describes the the current

uh specs and status of the test net so we we found some bugs thanks to all those team that try to to join it and uh and get it and get their clients to work with it so the the test net is currently uh at 10 times what other teams have uh reported bugs at at least so I assume uh most clients are actually just 10% of the way um I mean I'm happy to be wrong of course but I think that's that's my understanding um and we had some books so we we fixed none of them on on the test net they will all be fixed during the the relaunch uh I think currently it's quite valuable to keep this current testet running and finding

more bugs namely because Adrian from open Zeppelin has released um has released his uh like he's got a lot of test contracts that he uh that he has uh uh deployed around 70,000 so I would like to encourage people to try to keep sinking even though they they see bugs at least uh they are they are understood they are being fixed u i could go over them um there's there's one uh there so two of the most of them have been fixed already in the branch so it's just a waiting uh a redeploy we have two one of them is

understood but guas has no fix for that but it's it's well understood and there's a new one that has been reported by uh Gabriel from from Basu this morning and uh we am still um there's an understanding it seems to be uh coming stemming from the fact that g will not when um it it's coming from when the contract is deployed and it it has all the gas it needs to to execute the the init code but then it runs out of gas while charging for the for the gas cost related to um to the contract creation that uh occur

so yeah when when you deploy contract some witness cost some veral veral tree related costs are charged before the init code is executed and some are charged after so this is all in the spec um if the if the contract creation uh runs out of gas during that second uh time that gas is charged apparently there's a bug uh or at least there's a disagreement on the spec of on the interpretation of the spec between yes and and other clients so we want to uh we want to keep investigating this one but I I assume which it's just a matter of agreeing on when need to happen and fixing it and uh yeah otherwise there's

this on on this block on this block 6,842 there was a weird interaction in which uh gas would charge the the gas at the wrong time and this gas instructure then this the the init code would actually or actually sorry it's a self-destruct that would actually use the gas instruction to uh decide where to send the the balance so it's it's a very peculiar um um Corner case but it's it's a valid one so we we found we found that guas was charging the gas at the wrong time because of it so that's great um so this one yeah it's not fixed yet

but it's just about charging the gas at the right time so it will be fixed this week um so that's pretty much it for the bugs uh yeah like I said there's no relaunch plan yet but I think for the relaunch we would also want to integrate so fix those bugs obviously but we would also want to integrate the change that Kev talked about last time uh which is if I'm not mistaken instead of serializing the commitments we would um map them to field is that correct correct cave uh yeah from the outside you're just still mapping it to 32 bytes um it's just that you're using the group to field or map to field method

instead yeah so I would like to to add this uh when we relaunch just want to make sure everybody uh is okay with it I don't expect any opposition but you never know okay well I guess that's it for the test net cool okay uh next up we have the proposal for code packaging in veral I believe uh some folks from ipsilon pavl

as well as guom and others have been discussing this for the past few weeks um yeah yeah okay cool um hi everyone I think it's my first appearance here um so I I think I wouldn't call it proposal yet it's kind of the exploration at this point and like the original of this is um thinking how can we what are what are the alternatives to uh having this code layout that is currently used in verus which is uh one bite of metadata in the chunk and 30 31 bytes of of actual code um and all of

that is needed to um to be able to have localized jump dis analysis right so to be compatible how how evm works and U and and this document which is uh the link is in the in the agenda I can resend it to the Chart if you want um yeah so mostly um mostly the this document uh tries to have Alternatives which are um kind of splitting this metadata and the code into separate sections um to that we use some some

small pieces of EF but I think thef is like the L important part all of that uh so I think conceptually uh we try to think what are the other options to uh to keep this metadata somewhere um and uh this this document mostly proposes to have this metadata being um uh proceed the actual code and there are to at least three different kind of encodings that we can use uh which one of them is the same as this current use so we just move this one bite like separate section and the

the actual code is can then can use like 32 bytes of of of payload um so whenever you have to uh verify a jump instruction you need to reach out to this other section and check if the metadata there actually confirm that the jump is valid um yeah so so we we kind of listed three different encodings for it one is a bit set which single bit informs that the destination is is a valid jump desk this is more or less how the current VM works it just produces this bit map on the on

the way for the whole um and yeah and the other one is to put this one bite of metadata in the section accordingly and the third one is we can actually squeeze this one bite into I believe six bits because that's enough to have all of that so this this gives us some savings um so in general this is kind of playing with the tradeoff between uh the actual code size and the com computation needed for uh and yeah um I

think I'm not fully sure what to do with this next there are some comments about the document that I plan to to uh incorporate in the document itself uh but I think the that's that's more or less uh the idea um and I think this they come up the question for example is it worth it to do it I think this this like two like Main benefits of this one is that the execution execution is more similar to what we currently have uh I think you already know that uh there will be at least two different

modes of execution one is for for unit code one is for the deployed code so we already have like two like variants of VM and they will behave differently depending on the context uh so at least maybe that that simplifies the implementation um for the execution and second aspect is that um The Meta data is actually only needed when you when you have a jump instruction so in the current veru trees design uh you kind of waste this one bite of metadata if you fall through from one chunk to the next one and you don't perform any jumps there uh because you

can kind of uh figure out the the offsets by by yourself uh using the context on the previous chunk so um I'm not sure how to actually uh simulate the the different modes of operation and which one is better but I think that's for later so was with this method this last point you you said there could be some kind of happy path in which there would be pretty much no jump in the code or as little as possible and then you would charge less gas because you wouldn't

have to go and read the the analysis right yeah yes uh but I think it's a bit difficult to to to justify that um so yes so it's not like so strictly it's not like uh uh the code size that is actually deployed doesn't contribute directly to the like gas overhead for accessing code um but to kind of uh to say which one is better I guess we would need to analyze the execution of existing contract somehow I think that's doable but I think requires some infrastructure

to do it or you can just launch different testet I'm not sure exactly how to do it but you need like kind of dynamic analysis of the execution it's not enough to just see the code you just need to know like what are the offsets of the jumps and how how frequently they happen and then we can compare the cost of like different variants of this right so we I mean not that it's a complete perfect indicator of what future use would be but uh we have this code that ignasio is maintaining at the moment where we replay blocks historical blocks we could do this and get this

kind of of information if we implemented some approach that you describe which doesn't sound very difficult uh well on paper at least yeah yeah that's that sounds really good for for analysis I think if you have something that that can that this proposal can be applied to I think that would be I think one of the next steps for it yeah so unfortunately that code needs to be rebased um yeah I mean I don't know as you can tell how ready it is but yeah we might need a couple of weeks to to get it to work but we could do we could do

that uh so that's first question answer I had another question um just actually it's not really a question it's more like to confirm I understood correctly you you describe those three approaches like the either putting the bit map or putting the offsets in a section or putting six bit offsets in a section those are interchangeable like if I pick the bit map for example I don't have to store the offset is that correct yes yes they they differ by like um additional kind of computation you need to to get the information like the bit set is like the like the straightforward access you

just need to read this one bit from from there for the others you you just need to to do something similar your you you are currently doing which is this I I just call it like localized jum this analysis so mostly perform uh this analysis on this 32 byte chunk to know where the valid jump Des are in the chunk yeah and um I wanted to make a calculation because the the bit map would would be the best I mean yes it's more computationally intensive but uh because reading from the tree means uh

increasing the gas cost uh if we have to store the bit map next to it um next to the code it would be uh it would be better for us to just Store the store the bit map um but yeah uh one question I had sorry I'm I'm brain dumping here if uh the section was that extra section the jump L section was uh spread over several lead in the tree uh would there be any issue with this uh I'm I'm thinking of storing the section corresponding to a group of leaves close to the close close to the Tree close to where in the tree they are basically so that's uh yeah I'm just trying to see if

we can optimize the gas cost here uh yeah I'm not sure I fully understand like the question but um all this all these jump Des sections are kind of random axess so okay mostly when you need to decide if a jump test in a given code Chun is valid so for the given code Chun you need to do a look up in the jump this section and in a specific offset so I think in in in in most cases it means you need additional chunk to load from the jump Des

section and whenever this this same code chunk will be reused for later jumps this is up to like checking empirically yeah with this simulation tool like how often do we actually reuse the chunk so the chunk for the bitet for example has uh how many 32 * 8 uh code positions right so right 26 26 I mean if you if you if you jump a lot within the 256 instructions or like code offsets that's that's probably then then we use

the same trunk if you jump like a lot with the lot like big offsets then maybe it won't so yeah I mean seems to me like this will increase the gas C but a bit right it's I mean it's it's like to my experience it's more likely that will be the gas cost will be increased with this proposal but I think we need to verify it okay cool makes sense uh yeah I have more fine detailed questions but I I guess I'll ask them offline no need to uh I assume other people want to ask questions so I'll leave the any other questions or followup on this

and thank you Pavo for giving the overview if not we can also continue at async and Discord okay then moving on to the last agenda item uh EIP 2935 hey guys uh so I have uh prepared a short presentation to help navigate the discussion and I'll be presenting getting through just getting through the

mechanics of sharing the screen no problem Josh could you share it I'm not getting permissions yeah just shed it oh you want me to share my screen yep okay sure give me one second [Music]

f sorry for some reason it's only letting me share my entire screen which does not work well um maybe we can just kind of each go through this document do we need to screen share is that oh I think we just maybe go will be right back okay he's back did that fix it for you otherwise I can

share yeah maybe if you don't mind there we go cool sorry about that guys G

back thought it was oh sorry it was muted okay there you go okay so um this is a short presentation to come up with consensus for moving uh for the way forward for dealing with block hash and uh so the current status is if we can go to the next slide so current stat is that we have a proposal which says that uh so we can basically update uh number to Hash uh on the start of every block uh so basically we have a Serial storage

and uh on the fork block we also write uh the last 256 ancestors so that we can instantly switch to the new logic to resolve the block hash next SL so the seran features of the current proposal are that this this is stateless and wal friendly that the accesses uh in execution witness can help the stateless client resolve the block cash and there is no weird waiting period And since this is a Serial uh serial storage there is no real wraparound uh so Perpetual history can be stored since activation and the block number is not going to wrap around for

this particular time which is quite large and Slot is even bigger and currently we have this active in po N4 so we have had this discussions two discussions on it uh in the last viic as well as last ACD and the main discussion points are that why is not bing ring buffer like 4788 and uh what what should be the correct implementation method should we just do a client native implement mentation like how it's being done right now uh or we should do a system contract and depending upon what implementation we choose there are few things we need

to uh decide upon next slide so uh the current proposal is for the serial storage and uh so the points are that there is Perpetual history but it's still small compared to what the current St is and offers providing proving capability against any history TR there are no rep rounds and simpler logic uh and it is resistant to Branch poisoning attacks because there is a new Branch every 256 slots as per the work logic and but as ignasio mentioned it might not be a real problem and then the second uh proposal

that has been brought forward is that have a ring before like 4788 so we might just need 256 uh slots for the ring buffer and basically poisoning since poisoning is not a real deterence and this can just be kept loaded and updated in memory uh but even with the serial uh solution we can uh keep last 256 loaded and updated in memory as well so uh and uh 4788 can be used to construct proofs uh because they are beacon block accumulators so you can pick up uh uh beacon block header and construct roof against beacon

block header because it has uh it has uh uh it has the history accumulator and then you will have to sort of uh create proof against latest uh block latest execution block header in the in the uh in the bacon block so it might be a longer proof but yeah it is still possible so yeah we'll want to have this discussion that uh how do people here want to weigh between these two options so please give your thoughts

um yeah if no one else is talking I guess I'll start I think yeah the the ring buffer might actually be the the best option at this point because I know the state doesn't grow as much as we yeah I mean this is not going to to be a significant increase in the state compared to the actual day to-day operations of the chain but it still makes it it doesn't help um so we have um we have the the conversion on the one end and we have the realization that uh Branch poisoning is might not be such a big problem at least targeting a given

Branch yes uh we haven't actually gotten back to To Go's points um but we should we should actually try to cover them but uh I still think if if it takes 10 billions to to just slow down the Network a bit I mean this is what dunro was saying um I think I think it's totally worth it and there's been a lot of push back on ACD about not having a ring buffer um I think we could at least at the beginning um go for uh go for the ring buffer and if it turns out our fears materialize we we all we have to do is just uh keep uh

keep increasing the account and not use a ring buffer anymore so there's an easy way out of this problem if we if it turns out it's uh it's really materializing yeah I would say that it would be useful to like decouple this discussion about Branch poisoning with ring buffers I think it's like still think it's not like the correct framing because if it is a problem not ring ring buffers won't be really as solution I mean sounds like a workaround for blash but if Branch poisoning is a problem it's like a much bigger problem in general um and regarding this ring

buffer versus Perpetual history I have like a question is there like a clear argument on why it is useful to store the history at the execution layer in the tree compared to this other option that is possible today with the Bon accumulators it's like like any like concrete argument on why we need this Lo history execution layer I mean my understanding is that there is none and that's why the EIP went St stagnant cool okay yeah so if we are going for ring

buffer in that case I mean what is the size of the r but for that we want 256 uh yeah basically sorry basically keeping the old behavior of block has sounds good anyone has uh any differing views on this uh I have like another question so I think this perer to history IP was mostly motivated by I I think like the idea of clients

pruning their databases regarding history uh was that like the original motivator for this maybe like if there's someone interested in that topic I have an opinion if like the CP is still needed or something or maybe I'm wrong I it's of the original motivation I think 47 88 has sort of solved that problem so I guess we don't really need anymore all right we can move to the next discussion Point uh so what is the implementation

method that we should go for next slide please so basically the current uh implementation is that you know just implement it like a precompile uh so client write native code to update the storage and they resolve the block hash again in the special way uh so there is no system contract accesses and there are no charges is and uh we can basically keep the gas charge for Block hash for what it is or we can change it to any other static

value so uh how to explain so one one step behind and if we are choosing this then there are two ways we uh we can we can use to escape the 158 cleanup which is uh basically on the for Block we switch Nuance of uh of the special address to one by doing an IR regular State transition or we can just deploy a get by code so that uh people can also call the contract if they want to from their contracts or uh basically block has op code can also be resolve natively so both of so the second part uh basically can give us two

benefits so if there is a system uh contract then looks like that we are basically put using we are using our own system for implementing new features which is sort of elegant and the gas charges will be per the actual excess of reading them so basically uh the confusion about what is the cor what is the right gas charge won't be there and but the drawback is that system the clients might need to introduce system contract execution capabilities uh especially if for example there is a special gas pricing that needs to be done over there and uh yeah so uh the generated address will

be used so there are no 158 cleanup considerations over here yes so please way how you feel about this um I I have a question regarding this so I think this question was also also existed in 4788 right um I know if someone remembers the argument of why they decided to deploy a contract compared to a client native solution because it sounds like the same discussion right or it has something different in this case yeah it is the same discussion in

the sense the first of all in beacon block Hader I think there was no uh backward comp compatibility issue so it was just like you know something a new feature that needs to be implemented even though uh clients can basically transition uh can kind can transition execution to this uh system contract when they want to resolve the op code uh but as such I don't really have uh you know any particular reason for whether we should go for system contract or client native except uh the fact that the gas charges would basically be a mess to deal with or basically we need to figure that part

out at least yeah if I may add to that the biggest problem with this uh question to begin with the fact that we asked the question is that until veral happens or until at least we have witnesses in blocks or available it doesn't matter what you choose to do you don't have to call the contract so for example gu uh does not if I'm not mistaken does not call the doesn't call that code it just updates the the state directly um we cannot have that anymore because if you actually call the code you will find the code in the witness or um you need to fake the fact that you

have called the code and that's a bit uh tacky um or you could also say well this part of the code will never end up in the contract because we expect even stateless clients to to have a copy of this code which is what Matt suggested to me um that can be done but honestly yeah it feels it feels like a special case that's not really uh useful and while I don't exactly remember the connection with the reason why they they went for this system system call uh sorry for calling actual code um I I can I I sort of get the feeling that this was to be a bit more generic uh at least

that's what I got from conversation with people it's just my intuition don't don't quote me on that um but uh yeah I think even if we if we pretend that there was code execution when there is not or if we do code execution where there's no need to be we kind of break this purpose uh alog together so I think we should actually enshrine I mean this is what I would be pushing on AC um saying well you know what deploying code was a bad idea let's uh when we switch to veral Let's assume everybody has their own implementation that they go and update the contract that they don't call any code um that will definitely give some push back but

I think that's the right uh that's the right choice I think for for beacon block header uh the ring buffer is a bit bigger as well so here we only if we only have to store for 256 I think yeah we don't really need to do code execution to evm code execution to serve the block hash yeah I mean this point of of yeah if we have a contract that means that all the witnesses in every block will have this Cod which is somewhat annoying and yeah working around that seems like an an an

exception to assume that all stateless client have the code and don't have to rely on that in the witness is very messy so I think that's sounds like a really good argument to maybe try to avoid system contracts in this case if possible I was that in my brother yeah right so and just to add some detail you you actually have to pass some of the some of the data in any some of the tree in any case because if someone another attack or actually pretty much the same attack someone starts inserting uh values even if they don't do it on purpose but there's you know a new level

being added you need to be able to handle uh this insertion in the tree so yeah it makes it makes things uh really techy like if you want to Omit this uh approach uh omit the fact that uh like if you want to omit the the ring buffer from the proof you will still need to go through a lot of Hoops to to keep the tree in in the proper shape so yeah that's why I would advise uh not doing it okay so in that Casa in the case that we are going for client native implementation then what is the best way to resolve 158 cleanup we do by setting the no once to one or we actually deploy

a small contract that can at anyway resolve the get calls to it I mean even if we we won't use it if someone wants to use it in their contract execution they're free to use it yes so my personal take on that would be indeed to just exactly do what you said which is a get just a get so that other contracts can access say that uh that data if they need it I don't know why they would do this but they could um and uh yeah it solves the problem of the nons indeed yeah so in that case we'll get a special address and that is something that we can update in the EIP along with

the bite code for get that's all from yeah thank you thank you caser that was great okay uh well perfect we got through the agenda thank you everyone joining see you next time thanks thank you