All Core Devs - Execution #169

Transcript

Tim Beiko: okay we probably have enough people to at least uh get this started is yeah there's someone from GIF does anyone from another mind yeah oh vitalik have you joined another

mine okay I saw okay we have at least Amanda um okay

Tim Beiko: let's get this started um welcome everyone to acde169 um so some dencoon stuff today uh getting some updates on devnet 8 and then we can continue the conversation around the test net ordering

um then Andrew wanted to bring up uh the vertical try and state expiry strategy um so we can spend some time discussing that um and those are basically the two big things after that I think you've then just had some updates on SSD wanted to share um and that's pretty much it I guess to kick it off um do we have a yeah Barnabas do you want to give an update on

them our document it

Barnabas Busa: has onboarded all the different clients and everything looks very healthy and we have a few of the pairs that are not really working uh

yesterday we had a smaller issue with betterment hopefully there's someone from the German team is here to let us know what has happened I'm not quite sure to be honest but we see quite some job but then they release new version and after I rolled it out everything went back up again nice we have a few pairs as mentioned uh mainly Eragon and ethereum JS that are struggling with a few of these years they have no uh Beacon chain Explorer also onboarded and we have a light pick and chain Explorer awesome

I will share

with you it's

Tim Beiko: sweet thank you I'm there's someone from nethermine wanna give some context on the issue that was fixed so I'm not entirely sure because I wasn't involved but as far as I know the experimental transaction pool stuff was merged and was causing problems and it was like missed that was merged and uh yeah so that basically it so the reduction for part that we have separate for for it for for transactions uh who's causing problems it's not yet ready got it so was the fix just to revert

that change rather than having a full working transaction pool yes I think so so uh I think Martin will handle that since got it thank you any of the other clients want to share context on any issues or fixes they've made this week okay and I guess before we go into the test Nets themselves

um it seems like we probably still want to get more testing done on devnet 8 would does it feel reasonable to try and get um to try and get um all of the pairs working on devnet 8 and then once we have that move to definite nine do the last changes with the 4788 spec um and hope all the pairs sort of work um work on that pretty smoothly

Barnabas Busa: I personally think that's reasonable and uh I'm just curious if we had an agreement

on how to deploy a contract

Tim Beiko: uh so we have yeah yeah we decided we're just gonna use a normal transaction and if I if I remember correctly the reason was uh it was it was pretty split between that and the custom deployment logic um but um we figured a normal transaction was easier to uh Implement and and just start with that and then if for whatever reason there's like issues with using the normal transaction you can always add the logic around uh the

inforque deployment um yeah

Tim Beiko: good good question uh I don't know Mario

what what do you mean by

just

Danny Ryan: so there is going to be like a particular address that needs to be sent from it's like a synthetic transaction in that it's reverse engineered from a particular uh I actually don't know exactly how it works I'm not going to explain it but there will be a particular address that needs to be funded uh to do the deployment and uh there'll need to be a Gap a big enough gap between you know Genesis and the fork on that test net such that we can do that um I I think we normally have such a gap but it's just going to be something that we manually need to make sure is done um in that interim and not to just for

this test that don't just deploy it to a particular memory location at Genesis we want to do the actual transaction yeah okay that's why it has a particular address

got it and I assume oh sorry go ahead quite quickly

Danny Ryan: just one person has to do this

Tim Beiko: okay right this is not in the

cloud like

Danny Ryan: one person maybe Matt or other should you know

write a script or just do it themselves if it's not not worth to be scripted it's just a couple manual steps

Barnabas Busa: but I assume for stuff like devnet we would need to have this then deployed on the on the actual Epoch of

Duncan

Danny Ryan: no enough I deployed before so that's why I said there needs to be an adequate stretch for change Genesis and then cook it's because the manual transaction has to make it on chain

Tim Beiko: um Mario

Mario Vega: yes so I guess we can just add the expected address in the desnet Genesis that the Genesis and multiple tests just to match what the address is currently in the EIP and um yeah instead of sending the intersection and that's the reason I asked the if we were doing a normal transaction on this computer section because we we have a deterministic address everywhere and it's just easier but yeah for the tests I I assume we're going to update uh the address to the final address we are seeing in the EIP for devnet plan if that's okay with barnabox and

Empire um yeah we can do that ASAP if you if you guys want

sir

Tim Beiko: as long as it doesn't affect any so I guess as soon as you change it in a hive you know those tests will start breaking for clients um and obviously we shouldn't retro actively change this on devnet8 but yeah going to devnet9 we should make sure that um yeah Hive reflects this address

Mario Vega: yeah I I will just um send the message uh and when we get uh sufficient uh go ahead from every client I will

just update them

Danny Ryan: Mario can you make sure that there are Hive tests where this uh contract is not deployed in time to that address just that's that's something that almost certainly won't happen but it's something that can happen in this technique so I just want to make sure that we do test the kind of like no op at that address it should quote just work but we should have

just

Mario Vega: yeah absolutely

Tim Beiko: and um so there was a question by

Barnabas in the chat asking if client teams are ready for devnet nine and I guess based on the comments by nethermind um should like do we want to figure out the full blob transaction pool on devnet 8 and potentially test that on devnet 8 before we deploy devnet9 or um would we want to move to devnet9 sooner rather than later so that we can have the final 4788 spec and then maybe uh do a bit more uh non-consensus uh changes on that

devnet

I just want to ask like about

erp4788 for definite nine do we also want to add the beacon contract as a bar address or not a warm address so like uh it is sort of a precon or not I I'm not sure if this is the right place to ask this question but because I know it this question has been raised before on the

r d

Tim Beiko: so this is the deposit contract whether we should always treat it as a warm

no no no sorry so the big block loads so

the new the new contract oh that says I think you decided no

yeah so okay then uh that's fine then

Tim Beiko: uh okay and I guess so back to the devnet nine oh that was muted for everyone on this stream sorry about that everyone watching the YouTube I can try and swap with the zoom recording here today back to devdet9

so do we want to get it live as soon as possible or do client teams want to make sure that uh things are working um because we have like the The Blob transaction pool on devnet 8 that we maybe spammed that net AIDS and some bad blocks on it and all of that yeah how do people feel about moving to the next one versus doing more testing here

Danny Ryan: assuming there's no spec change other than this the way this contract is deployed I'd rather be very confident going into devnet9

rather than like saying okay well we hope these things are gonna work um and so in that case I'd rather iron out the things that we know are issues otherwise if we have a high chance of issues in devnet9 then we certainly will have a devnet and I'm not saying we shouldn't have a Dev Note 10 we should have the amount of devnet that makes sense I think at this point we can like attempt to have devnet9 be like really solid

Tim Beiko: yeah I would also lean towards that um unless people think there's like some reason to test the 4788 change much uh much sooner

is flcl

um it looks like the current definite will cleanse help several quite critical issues foreign opinion about how to calculate block hashes which is quite a basic step right and we're observing uh payloads new products uh with some kind of run data up here so maybe we could at least make it more stable and fix all of that because the network

had multiple hooks respiratory saying now now it seems more stable but this issue is still exist and I think it will cause uh a lot of troubles if we doing as a network maybe we could spend more time on stabilization

Danny Ryan: I also just want to Echo like I I believe and I think most people believe that like the deploy method four four seven eight eight is like almost a no-op for clients and so I don't think we need to rush to test that

spec change I think it really doesn't manifest has it changed them it's obviously something we have to test but stability and reduction of additional overhead and devnet it seems to be the

performance

Tim Beiko: okay so yeah that seems pretty uh widely agreed upon so um let's move forward that way and obviously we'll check in on both the CL call next week and then this call in two weeks about devnetic testing and we can use that to inform uh when we launch devnet9 and I guess uh so the next thing so you know once were once we're kind of

feeling confident with the devnets uh whether that's after definite mine or you know potentially if we need more after that um we started discussing the ordering of testnets on last week's call um and I think it would be good to start to uh align on the order just because we're going to want to announce the launch of house key uh the deprecation of Gourley and all of that um so even though we don't I need to like talk or decide on dates or anything now um yeah I'd like to just get a feeling from like what do people think is the right order for them my proposal was um starting with whole ski because um it's basically new no one will be

using it and I assume there'll be like a pretty controlled set of operator at Genesis um so it's it's not a huge group to coordinate to upgrade the test net that then I would probably do Gordy if this is the last Fork we're going to do on the network um I guess the the risks of of breaking it or are slightly lower in a way um and it's also good because most of the applications and especially the l2s run their test that's on Gordy so it gives them a tiny bit more tank to test and I would finish with sepolya just as a final sort of dry run before magnet um and by then we'd obviously expect to no longer have any any sort of issues

yeah does that generally make sense to people as a as an ordering do people have preferences uh or different preferences than that okay yeah no objections um so if that's good um we'll probably have a blog post announcing at that host he went live uh once it's actually been launched and you know it's it's relatively stable um and that same blog post we'll also

mention uh that this is the last book for Gordy um and finally as well um there's been some folks working on ephemery which is a devnet that keeps or sorry a test net that keeps restarting a Genesis for for stakers to um uh test their setup uh so we'll start mentioning that as well but it's still uh it's still semi in development uh so uh we're not going to use it as like a one of the main test Nets or anything but I will at least let people know that they can test validators on it uh and and have like a quicker iteration cycle

Danny Ryan: is the cycle one week or two weeks

Tim Beiko: I always forget I think it's on the

website let me check

uh oh

Tim Beiko: I can't fight it super quick I I don't know is Mario on

sweet

Tim Beiko: and then uh Barnabas you had a PR I guess just changing the time on Husky for uh basically removing Cancun until we figure out the time is that right

Barnabas Busa: yeah that's correct so apparently everyone would have an issue overwriting the clan content if it's already set once

okay

Barnabas Busa: so this is something that maybe some clients will have to change uh but the gear is still open uh I would just want all the year to you know approve it before I merge it in because it can potentially custom issues especially for for everyone users

foreign

Tim Beiko: anything else on test Nets or

Dan

Barnabas Busa: one more thing that I also think that husky should be the first one uh going into Duncan and we should really stress

test day three and six blobs that we have set up so it's going to be a very good test to see you can handle it and after that we could adjust if needed then to two to four or if it's uh deemed reasonable then I think we can leave it as is because at 1.5 million radiators if that can handle it then it should be good for the minute

too so

Danny Ryan: heads up adjusting down would be a hard work and so I'd rather if we did the 0.36 I'd rather just leave it as is or reboot the net one you've been having like a you know

hidden hard work for the

testimony I'm saying that we could probably adjust it down for girly or satolia yeah

Tim Beiko: right but would that mean I know on the CL I assume you can probably set all of this in the presets on the CL I don't know if on the El this would mean we have to maintain two versions of the code paths based on the network and so I don't know how how easy it is for the CLS to support different blog counts by different on different Networks

I don't know if it's easy on the on the El

Danny Ryan: it seems like a configuration parameter but sometimes things go

deeper than that exceptional code path

Danny Ryan: at that point because you need conditional logic to change the configuration dynamically and so I would definitely not advocate for even if it's not the parent position to go with I think you either keep pulsey

at a higher or you get it supposed to be in start over

I

Tim Beiko: think Justin you're going to say something about the El side

Justin Florentine: I think Danny's got me covered I was just saying that for base of at least it's more of a protocol schedule concern than a configuration concern for us so it would be work but it would be and it would be non-trivial work but it wouldn't be hard

Tim Beiko: okay so but it would be better to keep whole ski at 3 6 no matter what even if we make all the other devnet or all the other test Nets in mainnet24 right then rather than having a special Fork just on whole ski that goes from

3604

Justin Florentine: it would be easier I wouldn't say it's

better but yeah okay yeah

Danny Ryan: so just a heads up we do have the schedule to talk about next week again the main nut parameters um some new information presented about Big Blocks From midnight and just to reopen the conversation as you know it's a default in a conversation but we've all agreed we'll talk about everyone so um we can obviously don't do a lot of more here but we before even deciding if host who's gonna go two four three six decide if we're going to um if we want maina to be such before we go to the system so next week is good too sorry I was wearing my hat when I wear

my hat you can't hear me it is not a tinfoil hat

Tim Beiko: it's better about that cool okay so I think I got the gist about uh we're gonna talk about it more on the CL call next week and there's some interesting data based on seeing larger blocks on mainnet right now

Danny Ryan: yeah please join because it's their call I I you know I think we've we're easily talk about this for 20 minutes if not a bit more with some more data to discuss

Tim Beiko: um anything else on dencoon or the forks

or the

test Nets

Tim Beiko: okay uh next up uh Andrew you wanted to bring up the whole strategy around virkle and state expiry um do you maybe want to take a minute to chat about uh what questions you wanted to get into and then uh we have uh uh I believe Guillaume uh Josh uh on the call been working on vertical and then vitalik I think is also here um so yeah we can probably hear from them

yeah awesome

Andrew Ashikhmin: right sure and I'm sorry my connection is unstable so I might break but

uh briefly speaking uh like to my mind status makes sense because well for obvious reasons uh that with bigger statue at the same time goes up but also like even disregarding the sync time um with each access the biggest estate generally like roughly speaking it's like the the cost is logarithmic uh and also like like there are just so many dust accounts uh things that are irrelevant uh so these are sub-optimal to keep uh never to never clean the state so yeah and uh and I'm a big fan of both velco and static expiry and with Alex

proposal makes a nice plan how to achieve both as far as I can tell the only thing like the only problem is that um like um address expansion it's not like that that was designed to to help with the static expiry uh which might be technically challenging to have this address address expansion but to my mind that's that's a separate discussion if we decide to have state expiry then we need to to like maybe rethink whether we need uh whether we achieve that with address expansion us somehow else but I would rather have

both velcro and state expiry

got it thanks again

Guillaume Ballet: sorry can you guys hear me yeah yeah uh yeah I I mean I agree uh the question that I'd like to understand or at least the the point I'd like to understand if if you're making or yeah I'd like to understand the point you're making sorry uh are you saying uh like we should have you know vertical or stateless and state expiry at the same time because you know the current upgrade path does not preclude uh getting State expiry later

um so my understanding is that you want both at the same time and I have an issue with this because uh State expiry has been effectively abandoned as a research topic for the last two years um that would push waiting for it with push vertical uh back for at least a year if not more and we have some kind of ticking clock in the meantime which is the the state is growing and that means the more we wait the more the conversion will take time so I understand that if we switch to that scheme uh that vitalik proposed and I I think is very has a lot of uh things

going for it namely that you don't really need to do the conversion live um so it would be it would be actually not such a big problem like it would not be such a ticking bomb but the the way I see it is there's been efforts uh to to get it implemented there's been several in uh in 2019 if I remember correctly and also in 2020 they've both been abandoned so um yeah I don't see like at the current state of of research which like I said is abandoned uh I it's more like we're writing a blank check and we hope that there will be still expiry implemented in the future

yeah this way if it turns out this is abandoned a third time uh we find ourselves with having to perform the overlay transition except it's done a year later so this the amount of data that needs to be translated is even higher um so yeah basically the question is not whether or uh in my opinion it's not whether we should choose between statelessness and state expiry but if we should do them at the same time my favorite answer is no but if you think differently I'd like to to understand why

oh I think Andrew dropped

Tim Beiko: and came back

while you were talking uh are you back EDU oh Andrew

Andrew Ashikhmin: uh yeah sorry I'm back but uh yeah uh I didn't I missed the last part so is there a question what's the question

Tim Beiko: yeah I guess the question is uh trying to understand if uh if if you are you arguing for State expiry to happen eventually or for it to be coupled with um with the transition to Virgo tree and say the same hard Fork oh all right

Andrew Ashikhmin: no but not but but I am I I wanted to to

happen eventually but it affects Virgo because even if we decide that it happens eventually then we can follow vitalik's proposal and not bother with translating parts of the milk of Patricia try with with every block if oh you're really breaking up

with that it simplifies our transition to a world to vocal uh yes sir so if we do it eventually we just need to do this mute uh transformation and just as we we don't like we if State expiry happens eventually then we can we can introduce

well

Tim Beiko: um yeah I think I understood the gist of what you tried to say but you're breaking up quite a lot

at dank Rod I assume that's what you you wanted to respond to

Dankrad Feist: um yeah sure so um

I think it's it's it's definitely still open that we will do a state expiry eventually um but I think we should also so there is also basically the option that statelessness goes goes well like we achieve all the goals with vocal and um very few nodes in the end opt to have the state because we find a good way of providing a state through other means for example like secured RPC node with let clients proofs as well as I don't know like something like portal Network um and in that world it seems like State expiry would become at the values much

less urgent and would be like a potentially long-term future thing and in that World um carrying around the Old Mercury would make and vertical in many ways significant currently worse and more complicated and that is why eventually we opted like that this is pretty unelegant and it would be best to just do the full vocal um and even in the state expiry world that's still better because there's no old MPT that's still carried around um so I think um we should stay with this current roadmap which is simply to like have a full transition to vocal that makes no

assumptions about future State expiry which is still possible um and uh the question to do a state expiry eventually which is still quite a difficult problem especially because it's coupled with address space extension um yeah so we make no pre-judgment about that whether it happens or not

vitalik uh yeah I guess I just

Vitalik Buterin: thought I would just give a bit of a background as to um like why some of like we first thought about doing vertical and state expiry at the same time and then why we uh you know like ended up switching and

like some and some of the various nuances around all of those issues um so at the beginning right to the uh you know if we thought about vocal trees and uh vertical trees are important because they allow us to have witnesses that have bounded size which makes stateless clients possible it actually uh also reduces uh worst case balance for zke VMS by uh quite a bit because uh like if you have a 400 big bite with this that would also be in 400 megabytes of how she had a zig as an arc I mean so it's something that we probably have to do anyway um but the challenge with uh Virgo tree of vocal trees is uh won the transition process and the transition Pro and then

two is that like they don't solve the full problem because there's still a few nodes that have to have the entire state right so with the transition process the issue is basically that like converting a 50 plus gigabyte Merkel Patricia tree into 150 plus gigabyte vertical Tree in a live network is just freaking complicated like this is something that the research team like literally agonized on for more than a full year like I remember I mean like last year at dafted act it was basically the topic at the research event and uh you know like it's basically as much already the effort as the entire rest of the Virgo that put together probably like just to

the process of how to do a live transition like it's uh literally comparable to the merge in in terms of complexity in some ways right and so it's uh pretty uh like it ends up breaking a lot of assumptions like either you have to do some really complicated I mean like thing where nodes take two states at the same state routes at the same time or you have to bring in trust assumptions or nodes that are fast syncing during the transition process we'll have to have custom code to download two trees and so on and so forth um and so with the state expiry like the natural attractiveness of this right is basically that that whole complexity goes away because you basically say well

the epoch zero or I guess the era zero tree so it's that epoxy speed somebody else now the era zero tree is the more competition tree then we start era one new state goes into error one and then after one year new state goes into Arrow two and actually we don't have to keep the MPT around forever because what we could do is once we're in Era two then we can actually go and uh just do an offline computation and just in place swap the MPT route of error zero for with a vertical fridge and that actually adds up being significantly easier than Julio than doing a live transition right but basically yeah because just the form

factor of State expiry does make it significantly easier to like do these two at the same time rather um and like it basically removes the the transition to block City and it does um of course add all of these other transition complexities involving address space extension and I think the problem of address space extension itself might might even be like complicated enough to be just to have by itself been decisive in terms of putting things off in terms of the research agenda right because uh well just uh like give an idea of this problem basically yeah right now we have 20 byte addresses um but then if we're going to have these

new eras that the whole point is that objects that are created during these new eras would be in spaces that cannot collide with the existing uh 20 byte address space uh and because if you see one of those objects in the state then like you know that it's uh actually new when you and you know that you don't need to like scan proofs for like uh absence of some other edit record in the past right and so but the problem is that pretty much all existing contracts make huge assumptions all over the place about addresses being exactly 20 bytes long and the doing that would work like getting around that would just require

an unprecedentedly insane ecosystem level wide amount of work and like if we have the capability to do that amount of work then personally I would like there's like five other things that are higher priority yeah in the in terms of the good that they could do for the ethereum ecosystem right like getting everyone to switch over to like account abstraction getting all the gaps to support ERC 1271 and erc69 getting everyone to use to to be standards compliance so non-matter mask wallets would stop breaking um just like this it you know incredibly long list of stuff that uh that requires that same level of ecosystem level-wide

coordination and and moving from 20 byte addresses to 32 byte address this is like literally that level of a task and crazier right like even erc20 contracts would have to be redeployed right like there's huge amounts of code such for optimization purposes assume that an address 20 bytes and try to pack something together with that address within a one storage slot um so it's uh now there is one other possibility that's kind of less well known that I uh suggested which is address-based contraction and there the idea basically is that we ban one over two to the 32 of the address space from being used right

now and then we start using that in order to make error in order to create Azure spaces for new eras and if we do that then like that actually completely solves a problem but that has this like one really important big sacrifice to it which is that um counterfactual addresses that are multi-user stop being secure so there's this uh fairly small but uh somewhat difficult to understand a subset of uh applications that are kind of small right now but might become significant in the future that stop working and but like it's the sort of like security weirdness that I think you know rightfully sort of like perk security people's ears up in terms of just like

bad things that could happen right like we like security practitioners and devs and cryptography people just don't have experience dealing with hashes that are pre-image resistant but not Collision resistant which is effectively what we get if we use Azure space interaction because the hash part of the address would only be about uh about 50 in bytes so that's uh basically yeah um oh in terms of azure space interaction for links I think I wrote about this on either research and they give you just like search uh on ether research and uh like maybe Azure space contraction or something it might be in there right but basically it's uh like there's these two proposals and the big things kind of got stuck because they're

both of them like one of them is just uh very hard and the other of them is uh very uh is kind of imperfect in a different way though one thing that's worth noting is that we probably can't uh keep taking the candy on the road on this forever because as of today the security that we have on uh address collisions is to the 80th and we are over the next time you know a couple of decades uh gonna get into the regime where like doing two to the 80 yeah compute power to create an address Collision is going to be oh start to become open to more and more people I mean technically it's doable already right like in its history the Bitcoin network has done something like I think two to the 93 work or something like

that so uh right now thanks Tim though yep that's the one um but so it is something that we have to address anyway but it's like a very thorny problem and like extension and contraction both have both have their issues and the uh one of the other um kind of things with uh vertical tree is is that if we do the uh like a Virgo tree transition and we bite the bullet and uh we like actually do the complexity of it but I think just the pure virtual transition as a transition then I think the uh the downsides of delaying State expiry by literally another that did go down by quite a bit right and the reason why they go down is because even though it's true that the

state size is going to keep blowing up and at some point people are probably going to complain and ask to increase the gas limit and at some point the gas level it's going to go up to like 40 or 50 million or something and uh that's you know the the state size will grow up faster and the state will be a couple of terabytes but the portion of nodes that would actually have to have the states going to be much smaller and even validators like you know then those participating in proof of stake would be able to be stateless with the combination of Virgo trees and the build Builder proposer uh proposal Builder separation including both um you know like ensure enshrines PDFs and the the

current Med boost based Stuff Plus a couple of uh you know like fairly I think small benefit modifications that are totally manageable you'd have to do a little bit of extra work to make inclusion let's work because you'd have to make um transactions carry proofs uh with um through the mempool but uh like that's totally doable right but like the point is that with that infrastructure the number of nodes storing the state goes down by quite a lot and like the amount of people who suffer if the size of the state literally blows up to four terabytes is going to be much lower and so if Virgo trees exist and the urgency of solving the state problem just decreases quite a lot uh compared to the

urgency of uh I'm gonna look all of the various other stuff that you know like the EIP enthusiasts have down the pipeline plus the uh you know urgency on the developer side to uh kind of just uh be cautious and you know continue to improve client quality and all and uh make the existing chin work more efficiently and all of those things so I think just kind of summarizing all of those different uh considerations put together like it does be feel like a bit of a binary decision in that either you do state expiry quite uh like basically with the uh with the verbal transition or if that doesn't happen then like it's

okay to just uh wait a decade and do stay or at least five years and do your state transition kind of Fairly uh or do state expiry like fairly far down far down the pipeline after that like it's the middle path like doing State expiry somewhere like one year two years after vertical trees that probably is is unfortunately a bit of a worse of Both Worlds right so I think that's roughly the uh the consideration and I think it's uh just depends I mean like how much we are concerned by the uh um I mean like issues involving a

growing State um another thing actually I feel like I might have uh sort of misspoken a bit right like when we talk about things like complexity of uh State thinking like doing State expiry also will will require a changing a lot of that code right like it's not like doing the state transition or it's not like doing a vocal Plus data expiry transition at the same time is easier than doing just a vertical transition right I think it's uh maybe like it's definitely uh much less uh hard than a do egg the two transitions separately but it's still like more work than doing one of those transitions right so we're not going to like save time by go but I think realistically by going straight into State expiry so the question is just

that how much or do we value feeling like we have the the state problem completely solved versus being okay with this kind of kind of equilibrium where we uh you know like rely a bit on uh you know proposal Builder separation and uh the portal Network and uh you know like some number some a smaller number of State holding nodes and uh all of those kinds of things um does doing SC plus VT together mean we don't need an ascnc um no you still need address space extension or construction if you if you do a state expire and vertical trees together if you do if you want to do state expiry you need to fix the solve the Azure

space problem at that time regardless of uh what format you do it in right so if we want to do a state expiry now then basically we have to just like bite the bullet on one of the two Azure space Solutions and uh commit uh biting that bullet like basically literally now so the developers can start preparing for it

Tim Beiko: got it and so I guess I'm trying to understand you said the middle ground is the worst I I'm trying to understand why why would doing them together actually be like what is the like so I guess we wouldn't need we wouldn't need the live transition by doing them together um which simplifies it right um from

what I understand of the of the the work that's been done on vertical trees so far it seems like we're actually doing okay with regards to like designing your life transition and and like improving on that so we I I don't know how far along we are but it you know definitely more than zero I mean

Vitalik Buterin: yeah right but like we're doing okay but just uh as a fraction of complexity of uh the entire vocaling project that's surprisingly high right right

yeah

Tim Beiko: yeah but it's like I guess we've already sort of accepted the bite that bullet and and go down that path versus Azure space extension is basically in the same spot it was like two years ago um right

Vitalik Buterin: that's fair um yeah yeah I

think I just want

to make sure that that's actually the case yeah

Vitalik Buterin: yeah I guess one of the variables there that I don't know is like what percent of the cost is sunk like are we talking about 80 of The Works being done are we talking about like 45 somewhere in between something even lower

Tim Beiko: yeah Guillaume do you want to maybe walk us through I know we we covered this a couple call a couple calls ago but do you want to maybe uh sort of rehash where we're at with verkol and and specifically the transition

Guillaume Ballet: uh sure yeah well um I mean okay the the problem is always that there's uh exactly what just happened um when uh some design people agree on the design and then people just start

paying attention and and come up with a new design um but uh my um I mean the way I see it uh which is really just uh yeah I'm speaking for myself here uh we we have like the the implementation of Oracle 3 um in two clients two and Counting uh there's ethereum JS also that has made some progress and I don't exactly know where bissu is exactly these days but they they also started working on it regarding the transition so we we uh at some point there was uh there was an agreement on the overlay method um this has been implemented this has

been tested we we have numbers uh it looks like it's at least a workable solution uh we are still discussing pre-mich distribution and there's uh some there's been some uh some back and forth about uh some details of the of the transition like should we keep um should we keep uh the the MPT Frozen or should we keep writing to it uh I mean this this is a discussion for another time um but so is it is it uh completely done no uh this is definitely more than 50 done this is I I would say 90 done of course there's the question of like I

said pre-image distribution um so I think at this point it's yeah there's got to be a good reason to change the to change the transition method um but yeah like you say last 10 percent is nineteen percent ninety percent of the work obviously uh and and that's quite true although um um yeah I I think we're closer than uh than that um but uh yeah I mean okay like I said uh some people will disagree for sure uh I think we we have a pretty clear uh path and now it's just about employment yeah implementing the last few details

and um and getting uh getting people to to try it out

Tim Beiko: got it thank you and I assume just to be clear as well I'm not aware of anyone who's worked on like address space extension or compression like significantly in the past year or two but does any does anyone know of some

Vitalik Buterin: I mean one thing I think I want to stress is that it might be worth uh revisiting in the just for a kind of a future compatibility reasons in the context of Els because there may well be decisions that we can make with eof

while eof has uh not yet released to that what might make it significantly easier for us to do address space things in the future

Tim Beiko: uh Andrew

Andrew Ashikhmin: um yeah I just wanted to note that we don't have any to make any decision now but I I think like like like I don't agree with guillong's argument that workload trees is mostly done so like like how I heard it then we should ship it but we should ship what what strategically makes sense right so we need to think about like what we do strategically about Aesthetics expiry and based on that we like that might shape our worship and that's all right

Tim Beiko: right and yeah I think that that makes sense like trying to and I guess it's maybe just sharing the like mental Journey that the the Virgo people have have been through and like how how vertical yeah fits in those parts of the roadmap and obviously like the if if the explicit assumption is like we just put State expiry on hold for a long time because we rely on epbs uh basically on the builders to provide the states and whatnot maybe it's just worth making that a bit more explicit any oh uh sorry Josh let me just read

your question right yeah so how much extra value do we get by shipping State expiry at the same time rather than only getting vertical ASAP yeah I don't know if anyone has thoughts on that I guess maybe one last question uh for uh Guillaume then credit folks what's the best place for people to just uh chat about stateless and Virgo on

like a more regular basis there's uh there's a Virgo try migration channel on Discord is that the main spot that people should follow

Vitalik Buterin: I think there are State expiry and Azure space extensions are in there too right

oh yeah

Tim Beiko: there's a space expiry Channel That's their state expiry is pretty dead uh and yeah do we still have the address space extension Shadow we write it oh yeah we do okay okay so those three yeah oh I just basic extension hasn't been used in over a year

Vitalik Buterin: but yeah I mean I do think that there's

uh value in the just like putting a team to think about the address space issue because uh like it has a lot of future optionality value and as I mentioned like even if we never do state expiry the yeah the whole like 80-bit address uh Collision complexity thing is like a bit of a long-term taking time bomb that's uh worth starting to figuring out and figure out how to diffuse

Tim Beiko: yes if you're listening and you want to take this on uh please reach out and uh yeah we can probably help set up a grant and put you in touch with other folks who looked at this in the past

Andrew you saw oh yeah

so

I just wanted to finish answering your question there's also a vertical implementers call where we discuss this kind of stuff the next one is uh next Tuesday I think um so yeah that's that's usually a topic we we talk about the transition

Tim Beiko: that's it um and Andrew did you want to add anything else uh no no anything else on this um yeah I think this was good uh to

bring up and uh get everyone a bit more context around where things are at next up Ethan uh you wanted to share some updates on

SSD uh yes so SSC

has been standing still for a while but I could finally found some time to update it um from last time when we discussed it we essentially had two different approaches one based on SSC unions where each transaction type so to say has its own branch in the object and the normalized one where each transaction gets converted to a unified

representation um so now what I did is essentially combine those two approaches into something called a partial container um how this works is that essentially it behaves like the union when it comes to serialization it is very close to it a little bit different in the header but the rest is exactly the same but it also ensures that when there are common fields in the transactions which there are a lot for example the amount is present in every transaction type so far or like the destination those common fields they now mercolize always at the

same location in the tree with this new approach so um there can be holes now in this partial container so if one transaction type doesn't use a certain field in the Merkel tree it simply becomes a zero and this ensures that we essentially get all the benefits of the Union without requiring any clients that verify Miracle proofs to update each time there is a new transaction type like they can just continue to keep the same verifier forever unless they start caring about the new fields um so yeah that's the latest approach there I have also extended the

specifications for networking so um with the previous approach the SSC transaction was only something that gets created as part of the execution payload but with this latest specification you can also directly sign SSE transactions and put them in the main pool and everywhere

um it causes

Tim Beiko: this flexible concern where it is possible with the SSC transaction to test mix and match your own fields I have somewhere is a police car not it's not it's not for me somewhere else so I have made sure that there is like a

little function that checks the invariance so that no new combinations are possible so for example if you include a blob then you also have to include the destination and you have to include the priority fee so no new transaction types but everything that's possible right now with the exception of the replayable Legacy transaction is now also possible with SSC transaction detect empty preset um yeah so just want to raise some awareness there to check out the eips and I have put them in the PM issue on GitHub um and would appreciate reviews and also

if there are any questions the typed transactions channel on Discord is the one um for questions thanks yeah anyone have any questions or comments I want to bring up now okay well yeah thanks E10 for the update and then I think that was basically it was there anything else anyone wanted to cover if not

um I'll just give a quick shout to eels so uh the eels team officially put out a blog post announcing the python spec for the El uh this week um so the the Spec's been live for a while but I think now it's uh call it production ready there's also a PR from Guillaume about uh about uh the the self-destruct removal that he opened and that you can contrast with the original EIP um so that shows kind of a nice um yeah and I side by side implementation in both eels and in a regular EIP so if people want to use EOS to write eip's uh you can and uh you can even link to it

in your EIP and the bot won't um the bot won't stop you um and similarly uh so the yellow paper came up a bunch on Twitter in the past few weeks people were linking to it um so I figured it was worth a quick update but just as a heads up the yellow paper uh hasn't been updated since Berlin so if you look at it today you basically see the burden spec um so um if someone wanted to update it and add support for London and Paris and all the the difficulty bomb Forks in the meantime uh there's the option of a grant for that and we've linked this in the yellow paper repo and also our

pointing people towards eels there um as the up-to-date spec for mainnet I don't know Guru did you want to add anything more around

eels

Guruprasad Kamath: oh no not much you will cover most of it the terms of like any prison new VIPs welcome but also like some feedback uh on like how uh Ed has moved the processes and yeah we would like to continue to work on like solving any issues that people might encounter so feedback very much appreciated

wait

Tim Beiko: um anything else before we wrap up

okay well thanks everyone and talk to you all uh yeah one whatever the next call is

testing call on Monday yeah thanks thanks bye thank you bye thanks bye see

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.