All Core Devs - Execution #200

Transcript

[Music] it's like I Jesus

h [Applause] for

time J Happ

hey

Tim Beiko: okay and we are live welcome everyone to

acde number 200 today um woo okay uh there's a bunch of us uh already in Thailand um other people are under way but we have a few things on the agenda to cover um updates on pectra couple spec uh discussions around 702 and 7702 uh new test net that just launched uh Mong and then if there's any spec updates for that Net 5 will cover them uh then a couple other topics um around EIP activation uh new proposal for an e protocol and an update on EIP 7610 um yeah I guess to kick us off we

have uh Perry on the call do you want to give a quick update on the

dev Nets

Parithosh Jayanthi: yes uh so to start off with we have a new um devet that's been announced today it's called the meong devet uh testnet and the idea is that uh it's a test net that's meant to be used around Devcon as well as by wallet developers Etc over the next weeks or potentially even a month or two uh to test out all the features that we want to ship in Petra it uh relies on the devnet force spec considering that we're still modifying some things on 5 so um it's it's it's live please have a look at the

landing page you can find faucets uh there's a guide for how to run a node there's already a FAQ so the FAQ is something we're going to carry on for Petra as well so if you're uh questioning how it's going to affect you as a validator or how it's going to affect you as a node operator or anything like that please have a look at the FAQ and take part we're hoping that over the Devcon week people use this test net for um a lot of experimentation in hackathons so that's the first big upgrade first big announcement and I guess the I don't know T do you still want to say something about make or should I continue with 4 updates

no

please go for DEET 4

Parithosh Jayanthi: okay yeah so uh devet 4 is something we want to deprecate soon um the question is just do we still um need to keep it up for some debugging or could we delete the Tet considering it's the same spec as Mong I guess we could ruce whatever we need on make okay if there's no objection then we will leave the S go ahead

Marius van der Wijden: um I'm kind of wondering I would like to do some experimentation over the death con but and like wondering whether it would make sense for me to do that on

makeon given that it might

incey

Tim Beiko: yeah if we do want to do things like that maybe keeping devet 4 for a week or too so that we can yeah spam it and stuff like that

yeah

Parithosh Jayanthi: okay yeah we can leave it up uh for the next couple of weeks and then I guess discuss it again once Devcon is over um the only other topic was that in meong we noticed that for a couple of epochs the um head vote was head vote percentage was extremely low uh we still haven't started properly debugging

what's happened um I know that zatu captured a lot of attestation so we people are kind of on Route so we haven't um dug into who's voting wrong and why um but in general the network is stable so I'm wondering if anyone else has had a chance to look into what's going on there okay then I guess we'll figure it out over the next days and po an update for that I think that's all the updates from

ourside

Tim Beiko: sweet thanks um any client team have updates they want to share about devet 4 or meong okay um if not there were two

Petra spec uh changes that uh people wanted to discuss so we should chat about those and then see um if and how they affect the five spec uh first one was um actually sorry let's do a 7702 first um frano uh had a PR up I believe since the last AEV and that's been uh discussed on eth magicians I don't know is Fran you on the call yeah y yeah do you want to give a bit of background and yeah

yeah much has happen honestly um I updated according to what we discussed that which was um that the EXT code copy

for example returns only the prefix um not including the delegation Target which is more similar to eof that's all I don't know what would be the next steps for this or if there's like consensus on on accepting this and it could be merged but I don't have the ability to merge it so to M I think yeah thanks for the update um on the last call I felt like it was a generally okay thing and was hoping to give people some more time to review this change but I'm pretty happy to merge it today unless someone has a concern or question about it

Tim Beiko: okay nether mine seems in favor

okay I think yeah if there's no objections we should go ahead merge it uh add it to the devet 5 spec and if there's any issues with the change that comes up we can open another PR in the future but hopefully um yeah we can move forward with 7702 any other comments on the EIP okay um uh fril we're merging the pr um I'll comment in the chat as well um okay sweet other one on the agenda uh Felix had a PR to update uh the contract in

e72 uh Felix you want to give a bit of background on yours yeah

Felix Lange: so sorry again for adding this in the very last minute um so basically this has been ongoing in discussions for a while so it's one of the basic things in this in the 7,02 contract but also the the S 7,251 like 72 51 consolidations that when you basically the fee that is required to add requests into the system contract is a dynamic one so this means uh the users May overpay fees unless they use the specific mechanism in the contract

to query the fee before they add their request and I felt that um it would be kind of important first of all to give an example of this in the in the E because it's kind of hard to use actually and um also uh just to clarify that like there are C like certain conditions have to be met for this to work at all and then while working on this example I also realized that the contract could be changed to make it easier to perform this operation so um basically I'm proposing to change the contract to directly return the required fee uh that needed to add um a request versus before where it was

returning like some other value that you could then use the compute to fee yourself this is kind of detail change but I felt that it's a change nonetheless so it may be required to discuss it here I I honestly don't know why it was I mean why it was done the way it was done before but yeah

Tim Beiko: okay yeah thanks Felix um anyone have thoughts comments on the pr um I guess and yet not that this is like the most important thing but we do have

audits on these contracts that have begun um so we should consider this as we're you know thinking about making potential changes

Felix Lange: but yeah yeah so there are some the audits are ongoing but there will be changes resulting from the audits as well so it's not like the contracts are final anyways so that's that's that um I was also more generally interested to to hear like just to make people aware that like these kinds of complications exist with the contract it may not be obvious to everyone like that these contracts behave sort of in the way that they do uh also when it comes to for example selecting the caller address and stuff um so yeah this is just Why I propose it here I guess it's

a bit too late like maybe uh we could discuss it the next time or something I don't know it's maybe a bit late to bring this in anyway seems there are no comments so we can just move on

Tim Beiko: yeah I guess last call if anyone has had the chance to review this um otherwise I would also try to get people to review it async and and not wait uh you know the entire ACD cycle to make a decision here um I I will say I I'm supportive of it and reviewed it I think it makes sense um but if other client teams want to weigh in please do okay um yeah let's keep discussing this

async and then maybe track uh the pr for both this one and 7251 for devet 5 uh if we decide to move forward with it um oh Mario ask what's the sis ASM Branch with the source

Felix Lange: i l it in the pr basically it's in the it's in the Pro request it's not actually yeah it's more like a proposal feel like maybe it's kind of weird like for for client teams to make decisions on on contracts but we we have to figure this out another time anyway yeah

okay

Tim Beiko: anyone else have comments questions on

this all right um yeah so if people can review this I syn um and yeah we can uh potentially come to a decision before the next call um those were the two only Petra spec changes proposed was there anything else on Petra implementations or Dev Nets that people wanted to talk about okay and then I guess um aside from these two changes that we discussed so we'll move forward for with the 77021 uh we review the two changes to contracts is there anything else around devet 5 specs that anyone wanted to

bring up okay um I guess that's everything for Petra um next up on the agenda so there was a discussion point on the last ACDC um about fusaka testing to see uh what El's could have the flexibility to unset features even when there's a hard Fork encoded um Alex you put this on the agenda give some context sure yeah so this kind of came up uh thinking about pios and testing it in the context of faka and like to give a concrete example let's imagine that we

have faka Dev Nets that have both pios and eof it'd be nice to be able to like test pios things without any complications from EOS eof it'd be nice to test F things without any complications from peros so I was wanting to get a temperature check from El's around feasibility here like ideally there would be some way to uh say unset like a fork Epoch or Fork timestamp uh for a particular set of features and from the last call like CL clients I think were pretty okay with this uh and I wanted to see what El's thought around visibility here

oh yeah

Dan

Danno Ferrin: um would this be a separate line for each EIP or would be like some combo activation I think whatever like the simple thing would just be to basically say only a seal fork or only an eel fork and so if that's like easier to implement I would say that I think what we care about most is just isolating E from CL changes um so yeah we don't

need could be to use something like e time um so it doesn't matter if we actually set up um faka time but e basically activates on EOS time okay like it's already possible is what you're

saying that's our proposal yeah

Danno Ferrin: yeah we've been doing that special purpose for special eips I'm wondering if we're going to do this if we should get a formal more extensible um purpose for this so like we could say um Osaka plus 79 no minus 7692 plus uh 6603 so we could get some sort of a long definition in for that fork um for a couple of reasons one of them is what if there's mult what if we do Osaka and one and then turn on eof and another one for longer standing Dev net or test net but also um this is something it's a pattern that I think might be useful um in layer twos so layer twos might say well we want to do Osaka but we want to turn on this layer

two specific feature and maybe turn it off later and it's uh done by a um an EIP or a rip there's a rip they want to activate um like native account AA so they want to say Osaka plus native account AA so I think if we're going to do this this is the right time to do a generalized notation I know years ago gu had proposed Fork plus EIP where you do plus eips add extra eips um so if we do this I would like it to be a generalized solution so we know as client devs to just build that pattern in everywhere that we need to you know there's a subset of ones we could do um some supported via Chains speec Get supports via specific um eips um but if we could get it in general it would just solve a

lot of problems Beyond Simple testing

Tim Beiko: um Lucas says nethermind supports this out of the box um I guess Lucas does neine support like the most General version of this is what Dan was describing I we can't hear you if you're speaking

we know

Tim Beiko: yeah we can actually

so

uh never mind

Łukasz Rozmej: uh supports with chain speec uh as uh if the eips are not related to each other right we can we can have them separately activated if they are related to each other uh either you need to activate you need to activate both of them right if they are somehow related but if they are not you can activate each on each one uh separately through chains spec yes

Danno Ferrin: does it support deactivation like deactivate Paz well

Łukasz Rozmej: you wouldn't activate it right and that's deactivation

you

Parithosh Jayanthi: you just set it to Infinity usually

Łukasz Rozmej: yeah

Danno Ferrin: so you would you could set Osaka which would by

default have pieraz but you could separately set pieraz activation instead it's ridiculously high number

Felix Lange: no that's not how it works

Łukasz Rozmej: so we don't generally have a concept of hard Fork so we generally set all eaps separately to the same uh number activation right we don't have Osaka as a parameter we set that was the AP set that's it that are in Thea so we have fine grained control over e okay so it sounds like E's are on board with the possibility and then it's just figuring out different

functionalities uh yeah if like uh yeah any other Els are here and could chime in to what they support today that'd be nice to know

Tim Beiko: yeah and Felix

Felix Lange: yeah so I just wanted to mention so this has been a long-standing issue in general that there are uh two conflicting formats for specifying the configurate the for configuration of the Els um there used to be more than two but now it's sort of settled down where most Els now use this format uh that g also uses where we have the fork names and their activations and then nethermind I believe maybe reth as well

has the I mean I think re supports both kind of I'm not sure um but anyway so the chain spe is a more General format it was invented uh way back by parity to allow very fine grain configuration and it's great but it I feel like from a usability point of view it is kind of overly flexible and it also requires the client to be able to actually activate all these features separately which may not be possible so or maybe it's like it just adds an additional complication in the code whereas with the with the simple like Fork named activations is much clearer uh what can be activated together and there cannot

be unintended code paths so for example when uh when we uh load the chain configuration and gu we also check that the forks are not activated out of order and they are not uh so basically you cannot have uh a fork without a previous one or something so these features because they are meant to be uh activated on top of each other if we had the ability to selectively disable certain e or only enable some of them it could create these weird situations that the client isn't designed to handle and we do not test these configurations either so the outcome is basically undefined um and for this reason um I

think we've always Le more been leaning towards just having this simple Fork based configuration so personally I would not support in having these very fine grained EIP based activations however it I know it's can be frustrating if you want to test some features or maybe some some other standard needs to be developed like I wouldn't necessarily be against having this for the duration of the development cycle of the fork for example like if we had some feature where it's like during this time where we are still actively exploring certain features maybe we

could have a list of like certain extra feature flags that are supposed to be enabled or something but then it wouldn't necessarily be possible to apply um this forever like this these features would not be available like let's say once the focus ship we would basically remove this

ability

Łukasz Rozmej: so one thing why we won't be removing this uh ability uh is that uh Sometimes some people want to use uh never mind on different uh on different networks and they want to activate only some of theps there uh so that's this where the fine grain uh part helps us what we can add

potentially is for example like labels that uh you could uh uh label for example canun or prag and it will activate all the aps like by default on the same so kind of labeling uh that that does it but we won't remove uh fine grain by itself

Felix Lange: yeah I'm not asking you to guys to remove it it's just more about like when you guys basically have the most General version and you have been supporting it so I'm not saying it should be removed it's just that for the other clients is basically going to lead to some situation where they then have to consider how to like in which like they basically have to undo their existing configuration mechanism and introduce this like fine grade thing

underneath and then the question is also yeah is this going to work or does it make sense so I think it's a it's kind of a broad topic actually trying to figure this out how how to do this best yeah I think for at least for like testing faka with like the context of pios we can get away with the corser grand thing so then the question would just be like do e all's today support this corser gr I mean I guess you would just set the faka time stamp to against some huge number and it sounds like that would do what we want um I don't think we need to get into the skin of worms of like the finer grain resolution um even if it's nice in other

scenarios

Felix Lange: now I think for certain

feature does definitely make sense for example we also have uh like a setting for for activating verle even now because it's not defined in a for yet but it's under development so you can basically already kind of activate it as under this name and it's kind of treated as like a fork so at a certain Beyond a certain size like a feature will basically be like a fork so for example e is kind of same like I'm not sure 100% but I think that also allows activating e separately just for the purpose of testing it but I wouldn't want to be able to activate like individual us e for example yeah that makes sense

Tim Beiko: and so what we could do then is if we want to have a devet that's testing eof but not

p is we have the eof time stamp before p and then vice versa if we want to just test P without eof is there any client team for whom that would be problematic

Danno Ferrin: in testing e we always had all sorts of bugs so we have multiple activation targets for eof it's really um honestly it's hurt the progress of e to have multiple Forks that it activates on and we've always had problems with test targeting multiple things clients supporting multiple things if there's multiple targets for eof to activate it's going to cause problems similar for

paired ass so I guess is there a reason why

Tim Beiko: we couldn't

just have a if we want to do a peer D Dev that we just do it and not activate the El side of the fork and vice versa so instead of having like two times you just run a devet where effectively the fulu part but not the Osaka part of the fork has activated or vice versa is there any issues with doing that

Felix Lange: yeah that wouldn't work because of the engine API like it's kind of a this is also an unest PA kind of because the engine API version kind of goes along with the forks so then you'd have to there would be special logic in the

Cent be the same

Tim Beiko: version though like what uh cuz I don't know

does p change the engine API e doesn't change the engine API

might I think the

Parithosh Jayanthi: moment it's fine but eventually we will be changing it so I guess for now kind of our plan has been for the pias world we just use Legacy versions like latest Master G which doesn't have any changes for Fu any way and for Eos we just use Legacy versions of the CL um that kind of achieves the same thing and then we deal with the problem when we want toate the

Danno Ferrin: yeah e has zero dependencies on sale changes so that would actually work

Parithosh Jayanthi: yeah that those was kind of our plan for now in case we could figure out some sort of shared activation strategy

then we would love that but it sounds like it's something we can also talk about in the testing session but for I think we have like a plan

Tim Beiko: okay anyone have concerns with that otherwise yeah we can bring this up in a testing call but it seems like a path forward at least for this fork okay sweet um next up uh we had I believe uh Julio and uh NE mind team wanting to present e70 uh which is a new uh e protocol to allow nodes to communicate subset of

blocks that they have locally um are either of the authors on the call right now oh yeah oh both of them are yeah do you want to give a quick overview of the EIP

yeah

Giulio Rebuffo: yes so basically it's it's mostly so that you can basically so this the direction of just just to clarify direction of the AP is just actually to um to define a framework that is already already used in consensus layers to basically Shard history across nodes so this is kind of a shortterm

solution to ap4 force um so as as as already talked to some people recently um soon uh to run a validator comfortably you will need four terabytes of disk because you will exceed the needing two terabytes and the hardware requires power of two and this is going to and and ETS ster told me this is going to happen approximately mid 2025 almost first Al of me of Q2 2025 approximately so there so I talk to some people and there is seems to be some urgency so this is basically a short and solution that a a short terms alternative to portal which seems to be a bit more far away than than than six

months that's time I talk to them unless it is understood um so the what this EAP not kind exp rational what this AP actually does is it basically advertise um it Bic divide the chain into chunks of set size chunks and each node when it's first boost boost strap selects random a bunch of random chunks which then back fills which then basically syns by by just verifying it against the other CH so you still keep the other chain but you keep only a small section of the transactions chain and what then happens is that they advertise through a bit list or a bit

mask as the as some people from the basil team suggested which um which which sharts they have so that when a node wants a specific block they just cycle through the charts what's actually cool is that since we have support for enr in the P2P we can just put in the enr and just by looking at the E not without even connect you can just discard the pier and move to the next one and the other cool thing is that if you choose a s Shard size you can have really really big shards and very few shards and it's actually very easy to rotate um rotate the peer Discovery to to find notes that have the blocks you want um you you probably don't even need the something

like C media even for something like that because it's just rookies numbers of shs so yeah this is kind of the proposal it's just a short and solution just to alleviate the problem if anything um but yeah that's it

Tim Beiko: okay thank you um there's some comments in the chat saying uh you know why do we want to work this and if portal is going to be there and that maybe it's it's significantly simpler um yeah anyone have thoughts or comments okay I mean if not yeah I guess

people can review this

Łukasz Rozmej: I have a comment because okay uh this is fine let's say but what is the incentive of people to keeping any uh of this why you wouldn't someone delete all its history there was

Marius van der Wijden: but there was never an incented in the first place for people to keep all the history so I don't know why this

matter

Łukasz Rozmej: well it would have to go ahead

Felix Lange: so maybe just a quick comment about this so This solution uh definitely makes it a bit better because compared to the to to just having to keep all of the history because um I mean

you are not incentivized to to to to keep any of the history but if you have to keep less by default you may be less incentivized to turn it off

Giulio Rebuffo: and and just I just want to clarify again like it's very unlikely that portal I think will be ready by the time we will need four terabytes so I mean I don't know that's that's at least what I heard from people that it's probably not going to be ready by then so this is just kind of the all this just a way you can probably avoid having people having to Stu up on you on more drives but yeah that's kind it

Łukasz Rozmej: well I'm not I'm like it's not the firstand information but uh from what I

said the receipts and blocks networks are ready the history Network and as far as I know Ashraf from our Ashraf is from our team is working on integration and he was able to download them without a problem so not sure what's not ready about portal

yeah that's yeah

Łukasz Rozmej: yeah working on Portal supporting other teams might be harder I'm not sure if uh some of the teams can leverage uh uh existing portal clients because they are for example in the same

language uh we couldn't ready uh but yeah so not sure if that's the Readiness was about portal or was it about uh integrating portal into the clients and I would if there's something about portal I would love to hear

it's

Tim Beiko: yeah I don't think there's anyone um oh Felix actually yeah just I say I don't think there's anyone on uh Porto or from Porto sorry on the call um but we definitely should follow up asnc with them on this um and yeah Felix you have

your hands up

Felix Lange: yeah I just quickly wanted to make a comment about it so my own personal opinion is that portal is fundamentally a better solution to this problem because it requ it requires you to store even less history so it's more of a dynamic system whereas this EIP um as Julio presented it it's a short-term solution that is kind of yeah I mean it does something but it's not very configurable so I don't think it's like the ultimate solution to the to the history distribution issue however um like if we can get it implemented and

and tested then it may be a good candidate for just you know shipping but in order to ship this I don't think it's so easy as to just make a quick decision and yeah we're going to have this and done but we need to integrate this into the sort of testing process that we have as we have it for other features as well so for example uh we would have to kind of I don't know create a devet with this example and then the issue may arise that this is a solution that is kind kind of specific to the main net like yeah technically we can also sh uh the history of the test Nets but the test Nets only will have a very short history

and usually now even for testing we only create these very small networks so we would have to figure out how to set the parameters for example for the test net so they make sense or maybe this feature should never be enabled in any test net but then we we basically only have to test it via the main Shadow fork or something so I think before fully commit to this solution it's not a bad solution we have to figure out how this can even realistically be deployed I wouldn't want to just turn it on I think we would have to agree in the clients on the implementation and stuff like that and we do have to uh test it as well and uh when it comes to portal I think the

portal Network itself um the specification and the clients they are uh kind of ready they have been following the main for some time with the storage so it is in a way a already tested solution and uh as wuka said is mostly the question of uh integrating into the clients which may be an issue because yeah it's basically this integration has not happened because portal right now is not on the critical path but the protocol itself is a pretty solid one when it comes to the history and I can attest that um yeah it is absolutely their goal to have

something that is ready and from their perspective it is kind of ready now so yeah this is something to be considered as well

Tim Beiko: thanks fix um and there was a question as well in the chat about whether um this there's been like a Security review on uh I assume the new uh the new proposal

Parithosh Jayanthi: um given the yeah that was about portal in general because cling that portal is ready then I think it also needs to go through the security stuff

Tim Beiko: yeah yeah as

Felix Lange: far as I know it is on the it is on the path to basically

getting reviewed by all kinds of security Focus people but I have personally don't know how how far long it is uh on that path um yeah

Parithosh Jayanthi: I mean we need an implementation first right my main concern is say you have a portal note chances are it's on the same post as the El and cl and if there's a Dos vector and portal you can essentially take down the rest of the host for free

um yeah

Felix Lange: I mean the the clients do exist so it's not like they don't exist they can be tested now it's not like like portal is an implemented system but it is kind of separate right now from from the main

Giulio Rebuffo: yeah but I think that the main

question so I I agree with everything all of all people are saying in the comments and everything you guys are all saying that for is the final solution um so it's just about whether it people will be ready by then because at least when I talk to some people um I'm not going to make names but I think that there are differing opinions even even within teams but some people I spoke to were very skeptical of portal and even portal guys told me that at least at least some weeks ago that um L is understood is that they were planning on trying to get some test Nets into actual production in six months and by then we will need four terabytes uh and by the

way the four terabytes are to un comfortable avalid dator right so yeah I mean you can I have HS take care for those numbers I'm not definitely that sure about the validity of that claim either but I think it comes from a reliable source

Łukasz Rozmej: but J this is about history Network because portal is also working on the state Network and uh uh State

Giulio Rebuffo: yeah State I think it's I think State Network it's no no I'm talking about yeah I mean the requirements is history plus state of course that's the two ter where the for terabytes comes in um then whether whether pter is working on the state I don't I don't I don't think it's very relevant because sayate is not the

biggest thing in the pipeline

Łukasz Rozmej: well they working on the archive state so it I mean

Giulio Rebuffo: yes that's that's cool I'm just I was just saying that it's it's 80% of the stuff is in history that's what I was

think

Felix Lange: yeah I'm just going to come in uh now um so basically the um another important question for this is if we can just live with basically removing the pre-merge history like this would be a simpler change to make and when we are talking about sort of like emergency solutions to remove some of the history from the nodes then this

would also be an obvious one um I suspect that very few uh notes actually require the premerge history and if they need it they can get it with portal or they can download it in some other way uh this is something that famously uh Aragon has had a solution for this for a long time where basically if you want the history you can get it outside of the ethereum P2P Network and I think this is something that will persist even in the future so if we just want to make a quick change we should maybe create an alternative e as well that just says you are not required to store the pre-merge history anymore and this would then go

with this previous proposal for the eth protocol where we would announce I don't know the cut off for the data that we have or something and um yeah I mean it would remove kind of the same storage

pre

Łukasz Rozmej: history is smaller and smaller it's not that big at the moment and it will be getting smaller in proportion to the rest of the history so I don't see this as a at least it can be a stop Gap very stop Gap solution but it's not any Final Solution at all

no it's

Felix Lange: the other thing as well right I mean it's kind of

well I think

Giulio Rebuffo: I think this is kind of a a conversation should be had in person I mean another thing maybe that we should just say because there are some clents that have a solution to this like

if Aron has that nether mind is close to have that as far as I understand from the call so maybe the actual thing is to just say to everyone just drop history now and uh and everyone can just catch up later or something like that that's also probably could incentivize people to work on it but that's probably a conversation to in person that's also be controversial

Felix Lange: yeah I mean I would personally this has the the sort of argument there has always been that before we announce before we make the collective decision to drop history we need to be kind of sure what will be the way

to

Felix Lange: get it back and if we can all agree that like Port is the long-term

thing then

we actually

Giulio Rebuffo: need to to use the same method though because I AR person is is not probably going to use port it's just going to use Torrance right because we can really do that um already so and probably and maybe and maybe and I don't know if RAF has their own static file system um I actually don't remember if they download stuff from somewhere um but maybe they do I think that we should not enforce really in the longer run like a way enfor a way in which know should get their chains I don't think that makes much sense but the

Bain question one

Tim Beiko: reason why it does make sense though is you don't want every single client to have to effectively rebuild like a

history Network and it would be nice like say I'm running Aragon and I want to switch to Nether mine um that there's like not a completely different way so like there is value in standardizing this um maybe we don't have to standardize on a single method like different way I think it is restrictive

Giulio Rebuffo: if I have to be completely blun um for example portal is Aron is is overall a better solution than portal it's much more generalized um so I'm really not really keen on doing that because if anything because it has its own advantage and it's just restrictive I wouldn't I would force people to do it of course it's good to have don't get me wrong but I wouldn't enforce people

force people to do it honestly it doesn't sound like a a good plan

in my opinion

Tim Beiko: so you're saying we should just agree to drop history by a certain point in time and then let clients figure out whatever way yeah

Giulio Rebuffo: yeah and Al since and also people actually incentivized to implement hisory expire at that point because every some other PL is already doing it so maybe people will actually start running towards it right I don't know maybe that's better to discuss it in person this is probably a controversial proposal

Tim Beiko: um let's do okay let's do a couple more hands but yeah

let's do Anar

Ansgar Dietrichs: yeah I just want to very briefly kind of agree with Julio and I also said

that in chat I think that that um history is conceptually something that's much closer to like um the different ways that clients expose tracing capabilities or even they choose different database layouts where basically that that really very much is something where like if clients want to collaborate and coordinate and multiple clients share the same format that's great um that's useful but there's no inherent reason that's not part of the kind of the consensus um sensitive parts of the protocol so so it really feels like a that choice be with the individual client and I separately also think the way to ship this practically would probably be to agree on some sort of um point in time at which um I wouldn't quite go as far as to say that

everyone stops uh stowing history at that point it's just that like at that point not every client would be expected to keep the history anymore so at that point it would basally then be that every client can just would be free to make their own choices

Giulio Rebuffo: I mean my opinion is that as when whenever a client gets a way to get the history from somewhere else they can just prune it by default so the first ones will be probably nethermind and Aragon because from because now I think like NE my close and AR already have it and then Gaff should will follow suit probably later and B too I think that probably makes sense whenever some a client is ready to drop it they can just drop it think that's my main

idea

Tim Beiko: okay let's do Lucas and Felix

Łukasz Rozmej: so I a bit disagree because if one client drops uh history and the other client doesn't have a way of uh thinking archive for example you kind of break their their archive thing so not not uh happy to do that without the social consensus on that um but uh about The Shard blocks protocol so um I kind of the more I think I uh I like it more I need to read about the details a bit and uh have more maybe we'll have some feedback but uh I like it because it's really easy to implement I think it

could be implemented in a matter of uh months let's say in all the clients and uh yeah it's simple and even if we have portal Network at least for some time being until we get uh even bigger uh confidence in it it's another redundancy method so overall I like it and history should be redundant so yeah I think it checks all the boxes for me

Tim Beiko: thanks U Felix

Marius van der Wijden: yeah

Felix Lange: so maybe some final note it's uh this is more about something that also julo earlier said we um that there

should not be clients should not be forced to implement these protocols if they have their own way which is better um I kind of just want to say that it's not NE like for this topic is and for peer top networking in general it's not um supposed to be the way that uh the peer-to-peer Network which is defined in specs uh and shared by all clients is necessarily the absolute best one but it is basically the common ground so we would I would say that if we make the decision to take in Portal for example then portal will become a part of this Common Ground so it's something that we

expect the clients to support even if they don't consider it to be the absolute best and then it I think treating it this way kind of changes also the requirements uh on the solution so if the if the requirements are not to provide the best solution but just some something that can reasonably be supported by all the clients then um it's for example it it changes the the the assumption that like Port is is kind of good at being this kind of Common Ground solution because it doesn't have a very large storage requirement so if you have to keep some part of the history in a certain format only to

satisfy portal for example then it's actually good if the protocol for doesn't force you to store a lot so for example the big shots would be kind of annoying but uh if you can have these like smaller shards then uh as when as with portal where you only have to store like a couple hundred megabytes at most of History to to be like an a good citizen in the network then maybe it is way more acceptable to have portal as a solution even if you don't totally like it it's just a way for people to basically participate in the network uh on the on in terms of being like in on the common ground

Giulio Rebuffo: yeah I mean I I kind of agree but on the same time I would I wouldn't probably I don't think I I don't think I think we need to discuss internally but we are not really that Keen to support portal network over the long term I'm at least maybe we can reink it

Tim Beiko: yeah I think we probably have a good sense of people's perspectives for the moment and we can continue the conversation both around Devcon and asyn um is there anything else

Felix Lange: this will surely be something that comes up

difficult yeah

Tim Beiko: is I guess is there anything else that someone feels we should bring up right now on the topic or are we happy moving

on okay um sweet yeah thanks uh uh yeah Julio and Amad forap and um yeah let's continue chat about it on Discord and around Devcon last one we had on the agenda today so um months ago um we decided to uh quotequote retroactively activate EIP 7610 um which uh uh formalize some Behavior around reverts for contracts creation if the account does not have empty storage um so this was effective like an edge case that we decide to make explicit to fix and it didn't affect any

previously deployed contracts or uh transactions um we uh I guess the the eel team was looking into adding support for this um we wanted to move this to final and wanted to raise on a call uh to check if anyone had uh any issues with that and also to see if every client had actually implemented it um yeah

po

uh hello how how can you hear me um so I I actually have some like second thoughts about this one um so like first of all I think it it improves situation

from what we had at least from my perspective uh because previously I I had to delete all the storage which I was not able to iterate over now I just need to know if the storage there is any storage or not so it's like one bit of information but um um actually I thought uh with with some bigger integration of of evm one I spot an issue that even finding this information it's not so easy in some contexts um and I need to build small infrastructure that serves only

this this purpose so um and it feels like a kind of theortical um case that we trying to handle so I I kind of appreciate that but I I still think it's it's it's might be a bit too much so what I was starting considering if if we can just ignore the storage and just assume if there's any storage it just stays there but I I'm sure that's possible in this in this way so um yeah if if there's option to further improve that I would I would also want it to consider

this

Tim Beiko: does anyone have thoughts on this and I guess po are you saying that uh you can now implement it as is in evm one

so on evm one side it's it's relatively easy I just need uh either the Storage storage root has or just a bull flag that says the account has storage or not and that's how it it has been implemented but now the user of evm has to provide this information somehow and turns out in in for example in Aragon that's not so obvious how to get this

information because this this this information it's not in the execution subsystem it's in the commitment subsystem so it's like much bigger um hard like struggle to to implement that so I think Aron hasn't implemented it yet to my knowledge and I wasn't sure how to implement it either um so that's that's the difficulty we have and and still this this like single bit of information it's only to to handle the the specific test cases that are unlikely to happen on real Network

that's that's the the the second thing

Tim Beiko: got it thanks um yeah Dan you had your hand up

Danno Ferrin: yeah I mean I was always when I looked at this I was wondered why storage was not considered part of the empty account standard empty account was always you know notes balance and um it was three items not balance and and the third the third thing but it wasn't storage um so so putting this EIP and I thought fix that so the empty account was all items had to be empty but I the ways to trigger this are are almost impossible because you have to make it counterfactual um and delete it and bring back and now that we have

self-destruct basically nerfed it's really hard to trigger so I don't know I yeah

okay uh dragon uh from Arian

side red side um it's similar situation that Paul described uh it's harder to do basically we need it if we want to support fully to support this and WEA seeing this as the very Ed Case that's very hard or impossible to trigger because you need hash Collision you'll need to add flag inside account and tie account or for for for us it's account table with uh

storage table for us it's not the account storage Separate Tables that are with this needs to be tied for us to support this I think uh Pro uh I think from get client they needed they wanted to add or remove add these restrictions so it's easier for them to support some things but in the end as this needs hash collision and is denos said it's very hard to trigger or impossible to trigger maybe to have uh maybe to reframe that AIP to be to allow ambiguous uh result but whatever happens

Tim Beiko: uh I was not really

sure and I didn't work on the CIP but I was just curious like how do you compute what the leaf hash of the account is because don't do you not need the storage route for that

yeah but we we do that separately when we execute the section we just touch account storage tables but for mle tree we have different tables that have hash versions

Tim Beiko: okay so I guess clearly the CIP is not something that can be trivially

implemented by the other clients um I don't know it doesn't seem like the most urgent thing to make a decision on um but we have already said that it's like included um so should we undo that previous decision um yeah

marus

Marius van der Wijden: um so I don't I don't really remember why we why we why we want why we were pushing for this so I think it would be really important for Gary and or Martin to come on the call and give a big a bit bit of

back ground um on this um unfortunately they're not here today um if I remember like there are something like 28 such contracts or something and all of this came up in a in a refractor that we were doing um and yeah it's it's kind of it's an edge case and and I think it should be handled in like it should be defined um I don't know if we need to Define it

in this way or if we Define it in another way that wouldn't require us or wouldn't require the clients to uh to to store this or to pass this to DM so yeah I don't know um uh but I think it's important for the for the E edit uh uh authors to to give the opinion on this before we pull it

Tim Beiko: okay yeah we can follow up I think uh on this anyone else have thoughts comments it okay um this was the last

sorry um if

Marius van der Wijden: if it would be really nice if the people who are against this could come up with a different proposal um that defines this Edge case um that they can uh uh that they can actually Implement um I don't know if that would be just deploying the contract um or or or whatever that whatever that would be most like smartest way

Tim Beiko: does anyone want to volunteer for

this

um yeah I can I can I can write down what I had in mind as the alternative um but it can take some time also to verify other implementation it's actually doable or not

Tim Beiko: yeah I think if you can yeah if you can at least drive your proposals that would be that would be really helpful yeah yeah thanks pal um anything else on this topic okay um that was the last thing we had on the agenda aside from some scheduling stuff but anything else people wanted to discuss before we wrap up otherwise then yeah uh just a quick

heads up uh next week uh ACDC will be canceled because of Defcon that said on next Friday there's a whole day ethereum magician sessions uh or whole day of ethereum magician sessions planned at Devcon uh to cover a bunch of uh topics ranging from account abstraction to the future of the evm block construction and uh issuance and uh next the week after Devcon on November 21st we won't have uh a formal acde but we'll have a interupt testing call for uh people who are available so yeah uh that's it for the next couple weeks uh we'll see everyone

at Devcon and yeah thanks all

thank you yeah thank you thank you thank you everyone bye bye everyone than

oh is for

e

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