Verkle Implementers Call #17

Transcript

all right let's start things off uh welcome to veral implementers call 17 this is issue 1024 in the PM repo thanks everybody for joining uh starting things off as usual with any client team updates would anyone like to start things off yeah I can start so um yeah some weeks ago uh C and 6 was launched um so some hours after it was launched I was deploying some contracts and mostly to check this witness Explorer thing that I showed in the previous call was

working correctly and for a particular transaction I saw something really really weird at first I thought it was related to the Windows Explorer because was pretty new but uh then I realized that was a get bag that we have so um yeah I fixed that and we relaunched the test net the yeah the test net and I think since then things are working correctly uh after it was relaunched I redeploy all these contracts and tested that the fix was working and seems to be the case um then um

uh gon was uh syncing a new gu no until um um like uh to have like a more recent state so we can do replay benchmarks and see again like performance bottlenecks U maybe get some in insights regarding uh witness sizes and things like that because our previous replay state was pretty old so we will probably work on that soon I think we still have to rebas some branches and things like that but um yeah we are going in a good direction um and also we had some time

to uh talk with uh many people involved in the eof implementation as to share ideas um regarding how a world where um bural trees and E uh uh would exist and how they will work together and later in this call I will do some small presentation to share those ideas and to maybe get more feedback from people that's it for me any other okay I can go from a side

uh so we basically tried to stat less saying the constant n6 uh Network after it was relaunched and uh so basically we were able to sync most of the blocks but in few of the blocks we found some issue like 6,128 4,775 4 4,487 and so basically block hash access was missing on this and I confirmed that U so our block hash ring buffer was of the correct L of 8192 and then um in 8915 block uh EXT code hash was missing data basically we

do a ismt block check over there and uh which basically also looks into the balance enance and I think that data is not bundled uh as of now and this is something that uh we have talked about previous and maybe could be addressed in could be decided and addressed in future uh test net how it could be handled and uh in Block 6989 uh basically for uh self-destruct to uh beneficiary address ejs uh is doing uh uh is doing the beneficiary balance access which is not which was

not present in the witness and uh this was also basically discussed with gam and uh uh will be decided how to handle it in the future so these are sort of updates from ethereum JS Gabriel anything you want to add um no not much to add here except that we've fully migrated to the viral cryptography wasm uh we used to use a Russ veral wasm but we've migrated to our own uh report that we maintain that uses Kev Andre's Library as underlyings so this paves way for an actual vericle try implementation which will be able to provide a a stateful sync as well so I'll probably begin working on that as

well so yeah that's it uh for my addition I think I can go next uh regarding the cost test net so NE mind failed on block around like 30,000 I think I know what the issue is I'll debug it probably this week uh except for that we are working on transition so I ran some tests locally and some tests and everything seems to be working fine next we'll be testing the transition on curtosis because as far as I remember I just mentioned that you can now test transition on curtosis so that's the next step and once I fixed the bug uh for the cost and testet then I'll resume

testing the vocal syn as well awesome anyone else I can go for n so ADV and agnish are not present I'll represent them so that progress with integrating uh or implementing uh vcal uh in our execution L client uh so we have a problem in our

client that there's some technical depth around the database area so that's what's been sort of slowing us down during the last few months uh so we decided to split the effort into two basically and first is to kind of uh sort of Circ convert the current database and just come up with something very basic for Conant integration uh it won't be used in mainnet it will only be used in Conant but at least we can like proceed with integration and going forward we like uh thinking of a brand new more than

thinking started implementing being a brand new database that will support both vle and Mer ground up uh with a nice feature that it will be very storage efficient uh so that's an ongoing effort it will take a while uh but uh after that hopefully like we'll be able to really support V uh totally um so uh next St for us is um continuing like with the basic effort to integrate with the consant and then we also uh change the gas costs uh We've also been looking uh at the it two layer at the consensus layer

uh to integrate as well into ctin uh and there we encountered some other issue that like apparently Ur is currently based on the capella frog um which is a bit problematic for it's it's a bit buggy uh so like I'm asking that on behalf ofish uh whether there's any plans to switch to the the neb fork in the consensus layer not immediately okay uh because that would have made our lives easier and we could

have uh integ it quicker on on top of NB yeah it's understood but unfortunately G is uh is going to have a hard time rebasing I mean by the way this is something that I would like to add to the to the go update uh we have started merging some PRS uh into into Master but everybody is aware of how long it takes to get stuff merging death so until this happens uh we would have to go through yet another if not like two really difficult rebases and uh time is better spent somewhere else so I

understand discomfort but uh and we would like to fix that but it's going to take uh at least a couple months okay all right well that's it going our part cool any other updates I can I don't know if you already shared something josua no I have not thank you okay so just on Bas side we we started to join the T net the dev net so we have a gas cast issue in the block

645 uh in a specific transaction so I asked if someone can share me the trace of the transaction to understand what is the difference because uh I try to look at the modification in the spec and I don't see any problem so I think I'm missing something uh so yeah if someone can share a trace it it will help me uh we have also thas that is working on some optimization in bzou uh we have more people joining the team so we have Gary that will help me to work on gas cost and he will also start to look at the proof implementation with thas so yeah PA

moment mainly trying to change the test net yes G uh the trace you need like did did I understood correctly that you you just need a gas cost because if you do you can use uh ignasio block Explorer No Yes the gas cost of each up Cod because I look at the Explorer of ignio and I don't see any difference so I think I'm missing something something else okay weird uh yeah okay I can try to generate you the trace but yeah I need uh I need to go home first and it's going to be like Wednesday okay no problem I we continue to look maybe I

will find something before but yeah thanks I should also say say that that blog number that you are referring to is exactly the blog number where I deployed and executed this more complex contract so it's it is probably something a bit more weird yeah yes I was just saying that I think I can generate the trace and send it on the CH by tomorrow problem okay thanks cool if no other updates we can move

on I don't think there's anyone from the testing team here this week I shared their update their abbreviated update in the chat if anyone has anything else they'd like to add as far as the testing side of things go otherwise we Canen Spencer wrote me I don't know how different it is from the update you you shared uh let me just quickly have a look um yeah basically they want to um yeah they start using the new the new uh input that we gave them it seems to work but uh they they've been delayed they will start they're trying to get something ready by the by the interrupt that's that's what he wrote me

perfect cool okay uh well then I guess next uh um is the cant updates V6 status and the V7 wish list um yeah I think but I've been uh disconnected from things that uh V6 doesn't really have any problems or so okay gender reported some some issues that we can discuss if need be otherwise we can discuss them offline uh for the my wish list would be to implement the well okay first confirm that there are some issues on the devet 6 and also and

also fix them uh but I know a and Unis swap were talking about uh you know running their scripts to to deploy on the test net so I would like to do that in on devet 6 if we could because I think it would be uh it would be quite useful to find some like more bugs and try to keep defet 7 as the most uh uh as the most stable test net we've had since number three I think um and uh yeah another thing that I would like to have on the devet 7 would be try to implement the Fill cost which so far was not was not implemented I think it's I think it's

time to tackle this before before the interrupt so that we can have some proper um estimate of what the gas cost uh really look cool okay if nothing else on that topic next up uh a presentation from the portal Network team Milos hi can you hear me yes okay I'm I'm sharing the screen can you see the slides y perfect we can okay cool um so

I already shared the link maybe somebody can also add it to the chat uh I shared it on a Discord Channel as well basically I'm doing a research on how the workl state can be stored in a portal network uh meaning the archive State uh entire archive State um I will give a bit of background on what portal Network is for the one that are not familiar basically the portal network is a decentralized API for accessing the uh archive node kind of API for the ethereum state um it's actually three uh networks in it or sub networks beon history and state and part of this

research is focused on the state Network currently what is being in development is the is the State Mar Uh current basically current state of the ethereum network and uh how it works is that every node in the network has a node ID and every content has a Content ID and basically uh every node stores the content that is close to its own ID that's way that that that way you know where to look in the network specific content like you know which other nodes is very likely to have it um and for the tree and the current ethereum state there are three types of content the

account tree node which is basically the tree node of the main tree uh contract storage tree node which is the tree node that belongs to contract storage and the contract by code so very simple structure not nothing too complicated there I'm going to skip the slides for the work Tre because I assume everybody here is familiar with with that um so the naive approach for the workl case would be to basically do the same store every threee node um but that has a problem the problem is also present with the merket Tre but is less noticeable or less impactful and the problem is that if you

have a note the tree note that is updating only one element from one block to another um the content ID would be completely different so it will store it on some completely different space in the in the network net and but you are duplicating how much storage the whole uh the whole portal Network actually needs and if the branching factor is 256 as the C of the workl tree uh you basically have a lot of waste in memory that way for the Merle three the branching Factory is 16 so that's still present but not as as noticeable let's say and that's one of the main problems um and the solution that I came up with

was to split each node basically into two layer mini kind of tree um so every node instead of having 256 children there will be two layer nodes where basically they would accumulate the witness thanks to the pon hash and where basically the the on the lower level each node will just be a 16 consecutive values um and the one level above will just combine and add them we can see that the others are basically just pedison hash with 16 elements and everything else being set to zero and the last commitment is just the sum of them so there is no pedon hash involved uh there is needs to be a bit of let's

say careful engineering here because the commitment that are being passed through on the blower levels are actually the elliptic points uh not the scolar field values but it it should work it should be possible to do it that way uh this process can again be split into uh three of four layer trees with four elements but that also increases the lookup value on the portal Network because you would have more layers to go through to find the value that you're looking for um but it's something that might be explor of how long that would take versus how much uh saving in memory would actually bring Etc um another approach that was being

considered which is more similar how the execution layer uh clients store the state and that is that the same PA the same node on the same path would be stored within the same portal network uh node or client and so basically the same node will be responsible for the whole versions of the same Tre Noe um that one breaks one of the main assumptions and that is that the hotspots uh that it creates hotspots basically some nodes would have way more activity for particularly popular like states that are updated very

frequently and basically that breaks a like a symmetry and linear growth between the the radios that portal network node wants to store and the storage size it actually will need um there was also an idea to that we B basically discussed even for the Merle case uh is to uh together look at the EPO where not the epoch not in a sense of ethereum layer network but portal Network kind of epoch where the epoch would be longer period and uh just the nodes would store uh the three noes within that Epoch and the local changes so basically something in the middle uh

this has a problem because every time there is a change from one EPO to another you have to duplicate the entire three states uh across the network which is very bad um this is probably some approach that we might consider more when we go into storing only the header of the state which will be probably stored in a different way and optimized for that specific use case and this will probably the P that we will go for that um but for storing the archive State this is probably not good enough um and that's that's that's relatively short presentation from my side on what we are doing and how we plan to go

forward basically I just wanted to give an update and maybe ask if there is anything that anybody says uh let's say wrong with this approach or any suggestions or anything like that that's great dam uh yeah I have a coule questions so you know the whole structure was basically made so that it would make things easier for the portal Network so precisely because you uh requested this like this this is why we end with this uh with this tree structure so I'm just a bit confused why you need to come up with this two layered tree structure and also uh isn't that going to be extremely expensive to compute

proofs um well it depends like the thing is like I'm not sure what we will need proofs for that's the first thing the second thing is um if you have a tree node and most likely from one block to another only one value will change in that tree node except the root and maybe a first layer or first two layers so then you want you will have to duplicate the entire 256 values and store it somewhere else in the network and that's a very high duplication factor of how much total storage the call portal Network would need to keep the entire archive State um so I guess that's why that's that's the benefits of that's the

idea of splitting it into a multiple layers um and what was the other question uh yeah just uh why I mean the okay the the proof uh right you answer the proof uh the I mean my question was like are you Bic are you no longer interested in the structure you you lobed for us okay maybe lobed is a big word but uh you asked us to to adopt basically uh can you clarify which one right so this whole Single Tree structure with 256 uh values and

everything merged into a single tree that was a request by uh by uh um Piper right uh the reason why we have this we no longer use the her account I mean there okay now we found that we we would we could adopt this this structure for our own purpose and and make a lot of optimizations based on it but until Piper made this request the whole the whole point was that like the the structure of the tree used to be um an account tree and storage uh storage trees below them so we changed the whole structure to to adapt it to the portal Network I mean I'm just wondering are

you suggesting we change the whole structure of the tree ourselves or is it just an internal portal Network representation that wasn't clear to me this 16 right right right uh no this would be just the portal Network internal representation so how the the structure would be stored within the portal Network and this approach I can probably go back there um with this approach the this would basically represent one node of the verlet tree how it would be represented within the portal Network and the end up commitment would be the same as it currently is because it's just linear algebra combined together so

there will be no change or this doesn't require any change of the worklet Tre structure this will just basically be how it will be stored within the portal netor work um I Now understand what you mean between like uh embedding the state the smart contract storage within the same tree I actually wasn't there uh I wasn't part of the portal Network at that point so I'm not really sure all the reasons I mean it definitely helps us uh from having more unified storage uh across different areas and stuff so it's still useful uh this proposed change doesn't actually affect anything regarding the worklet Tre design of the like for the execution plans or anything

that this is just how we would actually store it within the portal Network and regarding the proof um it would basically be that uh we in Portal Network would most likely not use this kind of proofs we have a system where currently with merket Tre whenever the data is gossiped within the portal Network work um the the data that is gossiped has to be proven that is valid and the way it currently works with a merket tree you pick one leaf that you want to store that was updated and then you gossip that uh basically that leaf and all of its parents at once and how it works is that the the node responsible for that

leaf would receive the leaf verify the proof and then it will just remove the leaf and CIP the parent of that leaf to the rest of the network and that would sort of like precursive propagate all the way to the route so basically when we gossip we don't actually we we actually want to have all of the parents already provided there so that we can recursively gossip them and for the workl Tre I guess we would probably preserve the same logic which means we don't actually benefit much from the um from the Z proofs that we we can actually get from the workl trees uh we didn't do much of the work in that area of whether we can optimize

something there but that's the initial thinking we would still just propagate the leavs and all of the parents with a full with a full content such that we also have to because we also have to propagate them through the network as well anyway so that's kind of like the thinking that we might actually not but I agree this kind of proving scheme would probably not work if you want to concise proof for the in a later stag and you will still have to um iterate through the tree to find the node that you're looking for right okay thanks for clarifying um another question I had but you already kind of touched uh to it just now uh you

know like the the top of the tree like your problem is the churn at the top of the tree but we already have this kind of information attached to the block right so if you see your information inside the block that means it has been touched but if you don't see it there uh it's um you need to find where it was less touched in the block so uh yeah you could you could like if you want to write an archive node or okay not a node an archive network uh you would be able to get those noes directly from the proof so you you could get it by doing some Archive of of those proofs themselves instead of Reinventing your

own your own method I mean it's just food for thought for you you know you know best what you need but maybe there's some potential saving for you either in design or storage uh by looking at what's in the blocks already um yeah I briefly was thinking about that the problem is that the portal network is designed such that the nodes in the network can join and leave kind of randomly and they were not going to go and fetch all historical blocks and keep updating themselves so there has to be a mechanism where you can just join and then then the content that is that is close to your node ID should be given to you or C to you through through

some means and uh you can keep following what is happening currently with the head of the network but if you disconnect like there is no strong requirement or expectations that every node will observe every every block header all the time and have everything updated and that's why I didn't actually find a way to actually fully use that information in a in a this kind of uh distributed structure but definitely something that I was looking into and still thinking about like because we will have a we call them bridges that we actually going to seed the data into the network and they are probably going to use this

information very heavily but from Individual noes point of view um it's a bit harder because they don't have the same expectations I'd say from them right um yeah one last question in this regard um the turn uh that you expect how like what is the depth that you expect it to be a problem is it like depth one dep five dep well five is going to be hard to reach but um for a veral tree but is yeah do you have any idea of where the churn starts being a big problem um I mean nothing seems to be a big problem per se because like I'm not sure what you mean by a problem uh because we

will just store it the way we kind of designed the the storage layer to work the problem is the idea is that if you want to find a balance on some archive States like million blocks away in the past uh you would know the state route and you would have to Traverse the tree and you would do that by issuing the queries through the portal Network for fetching each three node on the way to find the leaf that you actually interested in and if we do this splitting um then the the deeper the tree is the more query you need to make on the portal Network meaning it will take longer time to find the information you're looking for so that's a trade-off like technically we can go all the way

to the binary tree uh but then that would just take way too long um and on the other hand uh if you have like a big branching Factor then we you increase the demand from the whole portal network storage like combined storage of the entire portal Network you you you increase the requirements of how much that should be to support everything so there is like a tradeoff on latency versus the total Global Storage there is not like a strong requirements that it has to be smaller than this or bigger than this it just like depends on like a preferences and tradeoffs okay uh yeah I'm not trying to

redesign your entire thing right now well you're putting you on the spot uh one last question I would have but um you know you were also talking about potentially meeting in uh uh in frag would you by any chance be in Berlin before or after um I I I'm not I don't think anybody else from the team would be there I I know the entire almost entire portal network will be in Prague but I don't I'm not sure if anybody would be in h Berlin okay uh yeah okay then let's see but yeah I think there's some iterations like we could try to iterate on that if if you're interested um one one question last question I had because we I don't want

to hog the entire the entire call um would it be possible for you guys like do you need to have every single block or could you just have the history for you know every uh let's say every thousand blocks and then ask people to resn the note based on the proof from the from the blockchain would that be a model that would be uh realistic for you guys I mean we would have to think of the use cases of like it depends like how exactly would that be stored I I guess we currently weren't thinking in that direction um that's one of the ideas

that something similar let's say uh is this idea of having EPO and path let's say every 10,000 blocks or something um and then every node would store the state of a tree node at the beginning of that EPO and all the consecutive updates the the issue with that is that we encounter is that we would have to uh reduplicate at the beginning of every EPO we would have to reduplicate the entire basically state where basically we would have too much snapshots that we would store across like the entire portter network like we can we will still have to do some calculations to figure out how much

exact because as you keep adjusting the the EPO like making it bigger that problem becomes smaller but then the problem of the hotspots and uh having some notes having to do way more work than the others becomes more exaggerated so it there is also a trade-off in that design um so it depends on our use cases what exactly would that be uh it's something that we are kind of want to explore but this approach of using the path for the content ID not just the like a commitment um is something that we most likely going to pursue for storing the the head of the block um that way you can achieve maybe off one request for the head um head State um

and that's something that we are that's that's going to be a completely separate discussion and research on that area it's a bit lower priority for us at the moment cool awesome thanks a lot thank you Milos well okay since we only have uh 22 minutes left we can try to get through the rest of this quickly uh next up on the agenda uh there's a topic around the 32 by chunking uh ideas for veral I think ignasio maybe was this you on the agenda or I think it was me uh okay yeah interrup interrupt meio if uh if you had

any uh yeah if you thought that was you um yeah basically not much to say uh what I except that in order because of all this eof uh veral like considerations we had I was uh it's something that had been talked about with pavl a long time a long time ago uh I wanted to finally take some time to to try to implement it to see uh if we could get more information as to the benefits of of packing everything like both to evaluate the impact that UF would have and uh also to see if it wouldn't be an optimization that is interesting for for legacy code Legacy

bite code as well um so I want to do this what I the question I had for the community uh would be do we want to put uh the so in this model what we would do would be to put the bite instead of putting the bite at the beginning of each chunk like the the push data bite at the beginning of of each each chunk uh we would put that in a buffer somewhere and the question is where should that this be either we put it uh at the beginning of a 128 uh block um sorry to like the first 128 leaves the problem is uh we have to somehow store the actual

start uh offset or I guess we could compute it from the size uh that would be possible but then we probably that that has a gas cost impact because we would need to access the size every time we need to touch the code which is not currently the uh the case sorry actually it is in the current EIP but would not necessarily be the case in the in the future version of this EIP uh or we could put it uh in the reserved well some of it because that's the problem we could put some of it in the reserved uh uh leaves of the header group but in case even if the code is

currently 2 24 kilobytes uh we would not we that would not fit in the in the available space so we would need to find a way to overflow or we add yet another offset and then that means that every time we read the code we have to go get it uh somewhere else so that's an extra cost I honestly I'm not sure which one is the best approach they all have their drawbacks I wanted to know if any body had any opinion as to where this uh section let's call it section uh would have to go yeah I mean I agree that it's very

hard to predict and probably we will need to test the two ideas of like putting this information in the header and not put in there because yeah it kind of depends on the contract I guess um and the length of the contract right because the amount of bites that you need is depends on how many chunks the contract has so um yeah it sounds like it will depend on on each contract really yeah and also like another thing another thing is that if we pack together each metab byes my feeling is that whenever you

read one of them you will be indirectly like loading the metabyte of chunks next to each other and I don't think that's entirely useful because this metabyte bite is only needed whenever you you do a jump to really check that this chump is correct or valid and the chance that you whenever you execute a chunk you will jump to a chunk that is really next to that chunk I know how probably probable that is and how much you will leverage these other metadata bites that you have

read already I know if that makes sense it was a bit of a Time twister but um no no it's only it's tot understandable uh yeah that that's the biggest problem and in fact that's the that's the problem with the whole section reading in EF I mean this is what we I'm sure we will discuss that in just a few minutes um but I think it's still worth being tried so that we we have concrete data um so I don't know where to start but I'm afraid the answer is we have to start all two or all three depending on how you look at it um I'm just not sure where to start really I think um yeah I think I will first try to do it uh put some of

it in the in the header uh and then somehow use the same technique for the Overflow yes it's definitely going to be extremely expensive to if you have to read an extra section just to every time you leave uh you read a new chunk um sorry a new chunk every time you read another chunk uh and in fact this is exactly what vitalic said in uh in the efv Z PR um but yeah okay let's say unless there's another uh anybody else uh disagreeing I will start with that I will put it in the in the account header and uh at least it will serve as a base point and we can

try to optimize afterwards cool okay last up on the agenda a presentation on veral and EOS from ignio yes I will share my screen can you sh can you see my screen yep perfect okay yeah uh so these last days we have been chatting with some people from UF trying to exchange a bit of um our thoughts regarding how a world where Burl and UF uh will live together will look like and which are like some

concerns and things like that so uh the idea of this presentation is M mainly like sharing all these ideas for others to be aware so a bit of context that probably everybody knows already but uh eof is being considered for Prague and bural is being considered for Osaka and prag comes before Osaka so the idea is to yeah try to see how these both the interact interact with each other and try to see the impact of them on veral users on ethereum users um on the work Tre spec implementation and also see if this um

might put some um create maybe some problems for your adoption so it's mostly like an exploration of all these topics as to give like a really really quick dldr on Bal trees uh only like focused on the discussion of this presentation uh the main motivation of herle trees is to make stateless client viable and for that to happen uh Bal trees needs to introduce this concept of an execution witness which is basically all the data that you need um for uh replaying a block in order to verify it uh because stateless client do not have any ethereum state so you need to

provide them all the um needed data to execute the block the important part for this for this topic is that b TW um now include the smart contract code as part of the state in the state tree which is something that it isn't true today uh the smart contract code is usually like in the client's database so it's not really in the tree so with that point um in mind there are like two really obvious conclusions the first one is that the bigger your contract is the more gas you will have to pay at least

compared to the gas that you pay pay today which is 200 per bite because you had to write all this code into the tree which is more expensive so that's the first one and the other um like Insight in quotes is that whenever you execute a transaction um the more bite codes that your transaction EX ution needs um the more gas you will have to pay because we have to include all this B code in the execution witness this is a cost that is uh like new for users um today they have to pay for all this of course and this is like something that

contract developers and compiler devs uh will have to think about because it's like a new optimization I mention that they should account for but the the the the bottom line for B perspective is bigger contracts and uh needing more bite codes will mean paying gas uh um okay so that was like a DL dldr for br trees um if we do the same for EF which I'm not an expert on so have that in mind um the idea of e is to add more structure to the smart contract code so it introduce some new sections

like the header and type sections um it also includes a lot of new instructions and ideas to make the code execution more efficient more efficient and also allows the client to avoid doing some Rand time checks just like the shames analysis um because like uh I think that every J should be valid so that's a like a reason amount of work that client shouldn't do at run time and all this structure allows also to um make like the the evm like spec more Evol like evolve better because you can add remote features or

instructions um without breaking existing code so all these benefits uh have also or might also have some effects such as like maybe bigger code because we have to include like new sections and also um maybe having to read more bite codes while executing transactions see since we might have to read totally or partially these new sections okay this is like open questions so if we merge together these two insights of UF and Burl um re regarding gas concerns um we we could say that UF

might increase the C size and might need more B co uh to be read during contract execution and these two things are exactly the things that burot trees make more expensive because we need to add um the contract to the tree and also include the bite Co in the witness there are a lot of caveats here um because EF as I already said bring new effic icies so for example the shames instruction can be avoided so the contract size might be smaller from that angle and that might be that might offset these new headers that will be

included uh also there's like a lot of work that compilers can do to really optimize for the code layout or um how these UF sections are placed in the tree such that you have to read the fewer number of chunks possible now how much all these efficiency gains or potential optimizations can offset the new costs is like the thing that we are trying to figure out a potential idea to explore this a bit is to try to come up with a client that have both at least a minimal implementation of eof and Bal trees launch a test net with that client

or maybe has run a simulated chain locally and try to deploy a set of reasonable contracts both compiled with Legacy code and with eof and just like execute transactions on these contracts and compare the gas costs um so ideally we would like to have compilers that are already accounting for both eof and bural Tre optimizations because even if you have compilers optimizations only for work trees um they will be missing like considerations that will make sense for

EF and if you have only EF compilers that have optimizations only for E that will be missing all the cold chuning optimizations so asking for this is very hard because this is a lot of work and compiler teams have really probably limited bandwidth but uh yeah at least if even if we don't have these optimized compilers at least with this kind of test we can have like an upper bound of the gas difference and if we try to do this kind of testing maybe we can have some feedback loop to improve thef and BR specs so they can place um better with each

other there's another angle apart from gas cost risk which might be EO eof adoption risks which this entirely depends of if eof versus Legacy has a big gas difference so kind of depends uh but if there's a gas difference that is reasonable maybe users will simply try whenever they deploy a new contract to deploy it with Legacy code and with eof and simply do the deployment with whatever setup it uses less gas for them and that might be a bit annoying because that this might make harder to stop accepting Legacy code in the future

which I guess is like the idea because if that isn't the case we will have to accept that we will have two modes of contract execution forever and I think that will be I mean not entirely nice for complexity reasons for clients I guess uh not only for full clients but also for stateless clients we should also be aware of these like two modes of contract execution regarding verle tree complexity risks um One open question which is a bit related to what guon was talking about before is we have to figure out how K Chan will work for EF which will probably be different than

for legacy Cod so there's like a chance that we will have like a let's say double spec for legacy and eof executions in the veral tree spec uh because depending on the contract type we have to explain how chuning Works differently and things like that also you have introduces a bunch of new instructions and depending on these instructions we will have to figure out probably new gas cost for them if there are any that indirectly RIS the tree state for example today instructions like bance and block has indirectly require um state from the chain so these

instructions also require some extra gas cost considerations because they increase the witness size and um finally um due to the complexity of eof there's like a reasonable chance that this can delay Osaka fork and while this happens the state growth is still of course happening and maybe the M the St transition between the merco padria tree and the burco tree will take a bit longer and yeah um we will we will prefer this to take the short amount of time as possible because uh there's a lot of logic happening and

there's like a risk here so I think that it's fair to say that um it might seem that e and B Tre implementations are non overlapping because they are similarly touching different parts of Kinds but the point here is that their effects are really um composing with each other mostly like the gas cost effects I think that the original UF assumption was that doing all this code um structure changing um wouldn't affect much gas cost because

the code wasn't really part of the tree but since veral trees need to include cod in the tree for stateless clients then we have the situation in which um these similarly different eips interact with each other at the gas layer um like an open question is maybe a more minimal version of e can help here I mean I don't know kind of depends what a minimal version of e even means uh and if it really like helps with any of this problem uh just to clarify again this presentation isn't about saying that

there is a problem uh or a big problem the only thing that we are trying to share here is that maybe we don't know and a lot of these questions might have like a it depends answer and it maybe would be helpful to really find out um if any of these things are uh things that uh will backfire in the future and yeah trying to be uh have more like real data to support or simply discard these concerns um so that's it and also like the idea to share all this with other caves and get their feedback and ideas about this this these things

any questions or feedback um well I have a question well you mention that this is the first time and I I got aware of the and you mentioned that and the the goal of eof is to and no longer keeping no longer keeping the code in the tree in the veral tree I mean no longer kept in the storage so how could a um um block Builder um a block Builder to to to know which code or or which transcript to to execute or to verify and because then because even if the block the block

Builder owns the the whole story the entire story and there's no coding included in the tree so how so how did the block Builder know which code will be triggered in the in section block so I'm not sure that question is related to this topic like block Builders will have all the state of the chain so if the contract is an UF contract or a legacy contract they will know anyway and I I'm not sure this is related to for VOD really oh not not for work code just to make sure that if there's if there's no

code no code um stored in the trees in Stall in the storage so and Al so so in which form where the where the could be presented to to the B build or something else maybe just uh since we're at at time we can continue discussion async unless anyone wants to I'm just I'm curious I guess to stay on the topic of of eof if anyone else here not to yeah cut the conversation off but I know Dan was here and I don't want to put you on the spot Dan but curious if you have any quick thoughts yeah are the slides available because

there are some things I can clarify I think the biggest thing to mention about e is that it's cour just a container format we don't change fundamentally how The evm Works um so you know one of the big concerns about how are we going to keep two versions of evm um it's going to be the same operation execution Loop and you're going to be asking the same questions like instead of asking well am I Shanghai am I banum when you operate an OP code you might have an extra check to say is this Frame eof and if so execute otherwise don't execute so a lot of the core logic in there is going to be absolutely the same and that was one of the goals of eof um the big goal of eof was to build this container format for the evm so we can do things like add

operations that use immediate arguments which is impossible to do safely with current Legacy system um there have been you know high level requests that didn't include other large um goals of the evm future into it which include things like U removing the ability to introspect code and removing the ability to introspect gas while you're running um which will open up a lot of things like the ability to willy-nilly change the gas schedule without fear of breaking um contracts that're deployed if you can't read the gas then the solution is just always provide more gas um so those were some of the things that's why you know it looks like there's a lot of op codes but what we're doing is we're just replacing op codes that um um in a way that can handle this container format

and they operate exactly the same just they might use immediates they might not have gas introspection um they might need to use a data section to get their their embedded data so that's where a lot of these things from is taking existing Behavior patterns and containerizing it um there was a prototype Mega eoff compiler written by solidity before Mega E before big eof got pulled from Shanghai and in some tests I've done there I've seen between 1 to 3% gas uh not gas uh um op code size reductions of of byes but I don't know how that's going to translate to operational there may be less btes but there may be more operative more

effectively so the biggest open question we won't really get answered until we start getting quality um implementations from solidity and from Viper against the Curran speec um I'm hopeful it's going to be less but it might be large but it won't be you know anything outside of the 1 to 3% I'm expecting either way it's you know going to be statistical noise for a lot of these um so I'm not expecting any major large size or operational gas cost gains um anything that is costed in the header tends to be offset elsewhere but because of contract size restrictions you really can't you know multiply those gains within a contract so it's it's going to be mostly a wash is my

expectation I think those are a lot of the high level concerns out of there that what my expectations going on right now with uh I know over time we please share the last slide again because there were a couple of questions that I'd like to go over uh the fact that it doesn't change I mean uh the fact doesn't change the anything about the execution uh is demonstr demonstr sorry demonstrably wrong uh but okay how is it wrong what what are we fundamentally changing we just showed you that the gas cost was going to change so uh it was going to be affected so yes it's demonstr just demon that's detailed fundamental model's the same what I'm

saying is the model's the same the details might change but the model's going to be the same we're going to bring gas we're going to have message frames we're going to call contracts right so the devil is in the details but okay uh let's save this one for uh for the ACD uh my question was uh like the one I'm interested in is uh you know I know you've been uh asked in the past to do uh eof like a minimal version and then someone swooped in at the last minute and asked for the big version of eof but I'm still let's say the the the context has changed uh that was before Cancun now Cancun is there and veral is

next what could we get as a minimal version of UF like let's say UF comes three in three version like Three Forks or two forks what could we get that would still be useful and uh at least be small enough a scope that we could study it and not uh not uh you know go go back and forth on the question forever so the first thing you do in Three Forks you're going to have to maintain three more um growingly different versions of the VM and if we have to break the contract form out multiple times then we'll have to support those multiple contract forms forever one of the requests is if we're going to break these things that we break it once and there's only one difference between an eof contract and

Legacy contract we don't have a legacy contract and then a container contract that has gas introspection and then a container contract um that um does not have gas introspection still has Cod introspection and then one that has everything that we need so if we have those three different container things that's going to be a huge technical debt so the first requirement that you know is a lot of credence is if you're going to break every break things break as much things at one time as possible um so we need to get baned code introspection and baned gas introspection and preparing for address Bas expansion in the first go otherwise forever we're going to be supporting two or three different contract formats I mean we're already supporting two different versions of the um access list

transaction because they shipped like just a few months apart so we got access list we got 15559 we're trying to avoid this by doing it in one big go otherwise everyone everywhere is going to have to support all three versions forever so to split it up into smaller parts actually increases the surface area of what Downstream consumers are going to have to support it also increases the surface area for for testing in a surface area for attacks there might be some design issue in V2 that's not there in V3 and then we have to worry about all the details on that so while it might make it easier to deploy and get out um to do it in three different steps it significantly increases the risk and surface area of where things you're

going to need to change so that's that's my concern with splitting it up I mean I was I think that would that was the initial pitch but when you start looking at the security and maintenance issues it creates more of a problem than it solves that's a fair enough assessment although I would counter that uh yes it's uh we want to break as little uh well we want to break stuff as L as few times as possible but if the breakage is uh orders of magnitude bigger than each individual break breakage I'd rather have you know several smaller breaks than than one Big Break um but okay so just just to be clear uh I understand your I understand your uh your point and

it's completely fair but just to have my question answered the minimal minimal version of eof what would that be a minimum version of eof would be one the compilers would actually write compilers for and I think that includes um we could probably get rid of the TX create and op code but I think everything else there we've try to pair it down so we only put the minimal features in there um and if we cut much more out of it compile comp ilers won't pay attention to it and they're our primary customer if compilers won't compile the eof it's a dead feature that's we um back in Berlin we had subroutine op code proposed to go in and it got pulled very late because solidity came in and said hey we won't use this

so the real litmus test on how much can we cut is how much can we cut before our solidity and Viper will say we're not going to use this okay and I think there okay so in your view like at most we could we would still have to ship 18 instructions and uh on top of that uh okay ju just something I remember that story there was that was not EF at the time there was uh EIP I'm trying to remember 617 or maybe that's the anyway uh yeah 615 thank you um why do they feel this uh do you know like why why do they

feel that static jumps are not good enough for them what do you mean static jumps Dynamic jumps why are Dynamic jumps such a problem right yes Dynamic jumps it's impossible to analyze in static time you can write coded there that has um order n squar order exponential complexity jumps in analysis um to prove it safe because if you jump from it from something on the stack you can introduce data from outside um of the code to determine where that's going to jump and you can write these horrendous compiler bombs will absolutely freeze up your block production right so sorry that was actually not my question but thanks for

the refresher that was useful nonetheless uh my my question was why why do you know why solidity and I think there was chisan at the time who said uh 16 615 is not going to make in because we're not going to do that why do why would they not do this so one of the issues had to with immediate arguments um uh when I do my eof presentations and conferences I always start out with showing how if we were to add an immediate for static jumps today um how it would change the interpretation of other contracts that may already exist on the blockchain and if this is known ahead of time trolls will come in and create problems on a chain we've seen this before in some other spaces we try to preserve such as preserving the eof z00 header we wanted to have it just be EF but someone came

in and put in eoff emojis because they thought it would be funny um so people are going to come and control the chain and then the Shanghai attacks we're absolutely there um just to slow down the chain um so we can't just add in static we just can't add in immediates we also can't add in um code separation code and data separation uh because there's no effective way to show what the difference is between data and code you could jump into code at the end um and there are a lot of contracts out there that inter leave their code with their with their static stuff and we can't just shut that down so we need to figure out you know it's some of the existing patterns that are in use so we can't just invalidate because they're already out there live

on the Chain yeah okay uh yeah that clarifies things I will try to talk to Daniel because you know last time I talked to Daniel about this stuff he seemed pretty psyched about it so uh yeah I mean okay Daniel is not Christian uh it's Daniel's problem it's no longer CH problems so opinions might change um I guess I will it's understood that the compiler you know whether or not they want to to go over the threshold and and Implement them uh will require some um some like an effort that is like it's got to be

worth the effort I will talk to Daniel uh in Berlin when I'm back to Berlin and see what would be the the cut off for them and then we can continue that but okay thank you I I understand the context thanks thanks Dana Dan for uh for joining the call you're uh always welcome to come back to Future vix if you'd like uh cool uh and perhaps we can do another call if folks want to on this topic of eof and veral it'll defin to do one yeah cool it'll definely get brought up on ACD as well uh but yeah thanks again Dan for for coming and just helping to share your thoughts here cool okay well

yeah sorry we went a bit over thanks everybody for joining and see you again in a couple weeks thanks thanks [Music]