All Core Devs - Execution #92

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] [Music]

so [Music] so so [Music]

[Music] [Music] [Music] [Music]

[Music] [Music] [Music]

hello everyone and welcome to ethereum core developer meeting 92 um thanks for tuning in or watching live um i'm gonna pass this over to james who will be running the meeting today go ahead james thank you hudson good morning everybody we are in ethereum core developers called 92 and we're going to start with a retrospective on the last call where we went into five why's and things uh around client development and this this month we've kind of taken a step back to

look at core development and core developers and this is so i'll turn this over to alexi to give a summary of that and then and then we'll have puja give the update is that correct alexi yeah so um i actually have thank you i have written the um the retrospective from my point of view on the ethereum magician thread but i'm just gonna very shortly go over it it's the piper has suggested to use the five-wise methodology to try to drive the discussion which we kind of try to do a little bit um and so i've counted that we went like three three levels uh deep in terms of asking why

and but first before you even start asking why we have to re-like figure out what the problem is because this methodology forces you to do that and so i realized that when we define the problem that is the it's apparently like we have a problem that there's only one uh implementation which basically runs most of the critical installations and then i realized we don't even know if this is definitely true uh we have a sense of this that it's true and but i'm not sure if it's definitely true and also the fact that there is a pressure on the the development team again i wanted to one of the questions i

wanted to ask today since we have future martin here is that why exactly do they feel under pressure but anyway so when if we assume that the the problem does exist even without basically restrict data then we started asking questions about why is this the case why do we not have others other implementations and then i came up with i think i've heard at least four different answers uh so first of all is the orgo ethereum is the oldest and the most trusted implementation and it's unlikely to run out of money because it's backed by ethereum foundation number two is that the other

implementation do not offer the same functionality and end any significant difference in performance or operation operators experience number three is that we have a lack of standards of external interfaces that's why that was mentioned after the call by tim that it's sometimes it's not easy just to get people to switch from one to another because there is this disparity in the how the let's say json rpc behaves and then number four is that they people could run on multiple implementations to mitigate some kind of risk of the defect in go ethereum but it is at extra cost and then a lot of times it might not be justified from business point of view so yeah thank you so and

the the reason for that is because we don't even know how to to to quantify this kind of risk uh it comes back to the point that we don't actually have a data about like how many critical installations we're running on the go ethereum and secondly like there's this view of the systemic risk oh you know if something happens it's gonna happen to everyone so why do i need to bother about this um and then i'm not gonna read you out through this whole thing uh because i think we can come to it again uh but yeah so there are a couple of things we could do already uh is that what i i would like to put you to talk about is i suggested that we actually do start somehow measuring the critical

installation to first of all us answer the question is it really true that the goal ethereum is the the the kind of predominantly used by the critical installation and secondly uh will we be able to assess our progress if we're trying to change this how we're going to know that anything is changing and obviously we have to be really careful about gathering this data because it's quite sensitive the raw data is quite sensitive so we need to be able to aggregate it without leaking the sensitive information um and yeah so please uh i i give give it to puja thank you alexey um first

first of all i would like to begin with this like the cathedral has started collecting information with the help of a survey i'm going to share the link in the chat so that if people have not responded so far may go ahead and respond to the survey this is basically to collect the information about major installations such as the mining node mining pools wallet exchanges and wherever if somebody is having ethereum node and they are having like multiple loans we would like to collect this information based on the responses that we have received so far uh it appears yes get is one of the uh major

uh client that is being used by people here but the good part is in in the survey question we had one of the questions like if you are supposed to or if you are willing to think about having an archive node an alternative to your present client not specifically to get whatever you are running would you be able uh would you be uh happy to consider any other client and uh the options are coming up good uh basu is one of the uh like highest selected so far but uh this response is very few because we started the survey uh just few days back and we hope to get more information and we would be updating about how the progress is going but i

think that this is certainly going to give us a good picture of what where we are today and where we can be if we start working towards the uh getting balance in the client uh you know acceptance so yeah that's it from my end yeah any any comment because i would really like to hear anybody commenting on like the approach and what you think of this and stuff like that was that question for me no no it's a question for it's inviting the discussion about the you know i would like people to speak out about whether they

think this is the correct approach uh whether the we could achieve this whether how do we expand this how do we make sure that everybody who is running critical installation will get a you know chance to participate and stuff like that i think one simple thing is uh i believe there's a list of like operators that we contact when there's a hard fork um and and just reaching out to those like there's a pretty extensive list uh somewhere uh i think hudson or james you you you must have it but that just lists most of the exchanges uh mining pools etc um so we could probably you know literally go through that list and reach

out to people and and just kind of track what percentage of it has answered um yeah yes character does have that list and we are considering that thank you for that yeah i think uh that approach makes sense uh from one perspective but i was thinking also we could if we could use the uh enr data published in the east discovery we run a crawler which crawls through the network and dumps out the enrs from all the nodes there are two things i'm not certain about that's how many clients have implemented

enr and secondly whether client information is part of the enr or not yeah so one of the uh the reasons why um kind of i suggested to go with this kind of more manual approach is that the kind of any automated information that you gather doesn't tell you anything about how critical that particular node is we know that they probably the longer term learning nodes are likely to be critical but we don't even know basically what we don't know is that what is the impact of

this specific node going down or being having a consensus failure so we kind of know how many of them but what is the impact of them going down or how am i like you know maybe for example there could be hypothetical situation that we see the in the crawler the majority of the clients are go ethereum but in reality let's say that 60 are running bezu and then you're basically having distorted information about the impact and or it could be the other way around also does the in our crawler differentiate between like lines and pipelines um i would say

yes but i think maybe peter you know better sorry does enr information uh contain information whether it's a full node or light node like nodes are not advertising emrs so it doesn't make sense for a light client to advertise it because it's uh those connections are ephemeral so they come and go and the point of enr's are to be a stable list of reliable peers in the network and secondly peter i don't know if you heard my first question whether the nr containing information about what clients

it is open right and no as far as i know it's not advertised and we might want to ask felix but as far as i know it was a deliberate choice that you should not be able to tell what so it should you should not be interested in what the client is i think that was the one of the underlying ideas behind not advertising yeah that kind of makes sense because otherwise you could be used to like find targets for a particular vulnerability yeah this is actually quite a good point because you know we do need to make it very carefully to preserve the privacy of the

individual operators so that they are confident to provide this information therefore when i looked at the forum one one comment i had is the you know you made the organization name mandatory i don't know whether this information is stored somewhere this form i don't know like did people do people have a concern about the potential you know what is the what is the damage could be done if this information gets leaked or something like that um so at this point this information is just stored as a you know excel sheet but we are trying not to share it with public

and that was the reason we tried to keep some of the questions as optional for now like if people are uh worried about getting it leaked or something they may not prefer to answer but at least they would be giving the information about the nodes that we want to collect as primary data we could also do like a different like a more secure solution in the future i know there's encrypted solutions like doing like a key base repo or password manager vault or other things like that we could look into but what is the um what is the impact of the uh what is the kind of what is the predicted impact of the leak of such information

um in my mind it would be something like um if a mining pool talks about its infrastructure and then someone targets a ddos attack towards a specific client because that mining pool is primarily that client and then another competing mining pool you know is using another client for instance um that like is one possibility i don't really see it as a major possibility but that's like one attack and then yeah there's a number of things it's mainly i i don't know just seemingly giving up your infrastructure data can put you at risk for you know if there is some kind of vulnerability just exploiting it to take

down your network yeah so the reason i'm asking this question is basically um if we construct the questionnaire in such form to minimize the impact of potential leak that could make it better so look go through the questions again and look at which questions which answers could potentially could increase the impact of the negative impact of the leak and so in second component is the the probability of of the leak as well so if you do sort of risk assessment like what is the you know this is where you can do encryption and stuff like this but if the if you already can minimize the impact of any leak let's say that you don't disclose um a specific version of the client and

if everybody's in any pay in any case everybody kind of assumes that most people using go ethereum then there's no harm just confirming it right um so essentially what i'm seeing is that if you you you can go carefully through the questions again and construct it such a way that impact is completely minimal so people are not going to be too worried about participating um and the second thing i wanted to bring up is the regarding to this data gathering is that it occurred to me that if such data obviously in aggregated format is available on ongoing basis let's say it's published every every month or something like that obviously you can figure out how to do it more frequently

but anyway this could be already quite useful uh for the operators themselves to have a coordination point because at the moment they're pretty much in the dark they don't know i mean they're kind of making the same assumptions that as we are making that everybody most people running go ethereum um and therefore they basically you know they don't really think that they're they can change anything but i think if if we could show them that this is the picture and this is what the impact potential impact could be and you will be one of the people affected uh then they might justify from their business point of view they justify extra spending on reducing that risk

and saying okay so if we invest x amount of dollars in running a second instance then you know we're going to be more protected from the systemic risk and then we hopefully kind of couple months later we will see this reflected in the in the data that makes a ton of sense to me and we can definitely look over the survey again and edit it any other questions from yeah well reflecting on my experience reaching out for hardcore coordination and just trying to get the info getting information to node operators

is has been really difficult and we've seen large you we've seen uh the last few ports still a pretty large number of nodes that initially fall off even if they come back on during the time of when when a network or when a hard fork switches and so i i guess there's there's a part of me that wonders how much we really can know in it of what's all going out there and then perhaps because even if we get data verifying

that it is the actual data is also kind of difficult on its own for it and how it will is that it just seems like a lot of effort where it might be worth this is just a hypothesis it might be worth saying that many systems tend most systems tend to an exponential distribution without some kind of doing something else to it and so if that is the case then what are things we could do to avoid that and just think of what think of what we can do in the case that that we are unevenly distributed do the things that would be safe anyway and then if we

are safe now then we're just double safe i don't i don't know i'm not sure what you're suggesting to be honest but i think we do have an issue that because of the basically we're running at the moment everybody is free it's basically free for all everybody is defending for themselves they don't have a useful kind of coordination points so everybody thinks that you know they have to make the decisions according to their own you know rational rationale according to their whatever profit based business model or something like that and they don't see the way to coordinate with others in a in a useful way so if you're basically giving up on that you're i don't know what you can come up with

uh so i'm actually just trying to get rid of some of the at least some of the externalities that we have uh in the system uh yeah i if i do if we assume that there is a problem in the distribution of clients among critical then we can come up with things that we can do to help mitigate that and then let's say and then do them and let's say that there isn't actually a problem we haven't made anything worse by taking some by taking those steps like we've only so are you are you suggesting not to do this or not to try to do survey oh no to to to do the survey and then but not but also be thinking about what

do we do about it and perhaps just do things anyway because it may not be no that's not the end that's not the only thing we'd like to do but i think it's very useful to have some kind of data to to back this up and this is to if there's no more comments i wanted to ask another question kind of related to that i guess one more thing on the survey that i think would be the most valuable is um if we like as if you assume that part of the respondents do share you know that they run more than one infrastruc client as part of their infrastructure trying to understand and maybe uh um like ex not exposes the wrong word but

like explain how they do that to others um can be a a good way at least you know at the very least for client developers but also for other operators that want to run multiple nodes and the the challenge i think is like the more valuable that information is the least likely it is for people to maybe want to give it out um and but i i don't know i think there's a reasonable shot that at trying to to look at the commonalities across people that run more than one client and and what are they doing um and and and maybe like just document that better and and make that available more broadly in the community well i think

when i actually first suggested this idea i thought immediately of the ethereum cut herders as the kind of one of the organizations could you could do that and i my first thought not about being doing it as a survey but actually some kind of interview because i assume that the ethereum card holders do have a sort of like a list of contacts in other in the critical installations and so they can actually just talk to the people and then because it just takes about like one minute phone call to to figure out like all these data and uh and also in it additionally you can ask more questions yeah like if you encounter these interesting cases yeah i think the survey is probably like a good like

funnel for the interviews like james said it's like you don't get everybody answering but those who do a subset of those will probably be available for like a 15 30 minute calls and and also i would say that the other thing we if if if everybody agrees that this is what we want to do we need uh essentially coordinated information campaign to make sure that everybody who needs to know about this knows about this and because i know that we have a great you know there are lots of things that everybody starts finding out really quickly why can't we do it for this thing because it's like uh you know there are information like propaganda

i would say sources to get the information into every corner of the ecosystem and i think we should totally if we agree that this is what we want to make it a success i think we should totally utilize those things um right and if any no more comments i actually want to ask another question which i'm i started to think about so it's mostly to martin and peter on the go ethereum team is um so what actually so we talked to two meetings before about the pressure that you guys are feeling about the correctness of the code and about like possibility of the defect that

would affect the larger ecosystem so what makes you believe that you're you know what does actually what this pressure where this pressure is coming from so what do your what is your biggest fear essentially in this case so i talked a bit about that during the uh last epcon where i highlighted some issues that have historically happened which are consensus issues and which are denial of service issues and i mean such things happen [Music] and basically if denial service uh happens on a node which has six or

seventy percent of the network then i mean that's that's the good case if seventy percent of the network goes down but in the worst case it follows on a bad path and we have major problems but this 70 that you're talking about you're most of the time you just assume that that's the case right um yes okay because that's what i wanted to find to find out because did this pressure kind of increase over last say two three years because you're assumed there's more and more people running going through right yes okay

okay so but that's why i think this is actually even more important to figure out you know to just to to stop assuming that and actually try to try to check that if that's the case if we're actually on the right track right but so until proven otherwise i assumed the worst case which is that 70 percent are running of ethereum okay and i also wanted to yeah

sorry well and and this this kind of goes back to what i was trying to say of that even if it's not the worst case it's still worth doing the things whatever it is we decide to make sure that we maintain this yeah i know the reason i'm asking the reason i must the reason i'm asking these questions and i because also because i want to see people to think about if you have these kind of highly emotional things and the way to kind of calm down is to try to substitute some of the assumptions for the data because you might be surprised or you

might just know exactly that's yeah i this my worry is justified totally and when you know that your worry is justified it's not just you're gonna who is going to worry now because everybody else will worry because in the absence of the data you are the only person who worries because everybody sees the completely different picture everything is fine ethereum is running right like what what are you gonna what are you guys worrying about um so yeah i want to make this substantiated this kind of sort of uh you know this particular impact and i also want to ask another question is the uh um you know there is also connection with the gas

pricing sorry gas blood gas limit increase and this was how actually this whole thing started he's like what is the state gas limit and i would like to understand and maybe we should let everybody else to understand what happens if let's say how does the the problem unravels if we let's say rise the the gas price limit to unsafe value let's say to 20 million right now so what will happen can we even think about what kind of problems will start happening and how does it going to occur and who is going to suffer first because people at the moment see it as a is a purely kind of hypothetical thing because most of them don't even go

deep enough to actually see what's going to happen because they assume that's never going to happen so anybody has thought about this sure uh yes no go out peter so imagine that let's suppose we raise the gas limit and all of a sudden it becomes possible to create blocks that take 30 seconds to process now what do you do that essentially we we re-enter the shanghai denial of service factors where you just have to do something to i mean what do you do how do you solve it full of a sudden blocks take 30 seconds to process but if the miners are the ones that

raised the block last limit they surely would think that it would be okay for them to process such a block because i've heard uh from the miners they say um so from the one mining pool that in order to be profitable you have to be able to process a block within 40 milliseconds so surely if they they're talking about average cases i suppose but average case is completely pointless so i mean who cares what the average case is what i care about is that the network doesn't crash and burn so what about if we start i don't know i mean how do we make this kind of uh thing a reality because if we if we see that everybody is relying

on average cases and see very very sort of different picture from what you see if you look at the worst cases can we actually produce the worst cases can we put them out is it going to be super expensive i'm not sure i follow your question there alexa so basically what i'm saying is that is it conceivable for us to demonstrate let's say that if uh whatever is currently gustling at 12 million blocks right 12 million sort of gas okay so if we construct a block which takes whatever it is uh you know what is the worst block you can say it's gonna cost over three hundred dollars a block

uh it's in 12 million way multiple i guess that's been by 100 okay uh yes so that's if if we do that and how long you know is this going to uh be processed and if we actually warn everybody to watch out for this block and i say this particular i mean at some point there will be a block and it will be that much i mean how do we even produce that block uh like the mechanics of this election is important yeah so would you want us to deliberately do the blueprint attack on ethereum network i mean if if that's what it takes to to demonstrate it because it's just that it's just the uh hypothetical suggestion because the

problem i can see now there is this rift in in perception between the what you call what some people call the community and the core developers because the community sees the the like a smooth operation and average cases and they don't understand mostly one what's the problem of raising the limit i mean because like everything is fine like why don't you just raise it a bit more so i don't know how to get this message across uh i i think there's a more of a fundamentals sort of how people are looking at the network problem too there because if i'm using metamask and i send my transaction and it goes

through i'm not thinking that my my transaction needs to go through in nine months from now uh like that it works today and that it works for the next ten minutes that it works for the next five days is very different towards the the core developers who are thinking um this need i i'm working on this client for the next year and a half or two years of my life so it needs to keep like the like the time frame and the incentives of the people involved and even minors aren't um generally thinking that far in advance so it's it's gonna be hard to get them to viscerally experience something that they

may not actually really care about because their time frame is so different well for example one one possible way to to address this is uh ether scan has a really nice awesome chart but all these charts are historical charts what we could try to do is uh essentially keep live charts so to say future estimates that if so essentially just extending either the charts that ether scan has so that we also have future estimates and then based on the growth of the last whatever time be that one day one week one month you can estimate that uh

how how will the network look like in in a year in three years in five years and maybe that would help people understand what it means to just double something so what what effect it has on on the future on various metrics that's a great idea um and but the the kind of the the more fundamental reason why i'm asking this question is because i have a feeling it's still now that we are discussing this issue here uh but i do not really see a lot of like i i don't see a lot of like the sort of not not support necessarily but it's not really seen as a very as i feel

it it's not really seen as very very important thing is there there are like the one the eip1559 seems to be much more important than this for example from what i could gather uh because everybody knows about it everybody wants it it's probably because the price of easter is supposed to be i'm going up uh but i just trying to understand like why we're so are we are we just basically just trying to do it in in is it the future like i mean one thing is that there isn't uh just kind of us a very clear and direct pointer to what the proposed fix is like the like one five five nine is i

think popular just because it is a thing and it exists and uh and if we we know what it is um whereas if it's more of this kind of you know vague effort and that's you know there's some problems and let's think about how to improve it then that's just something that people are going to be less excited than if you just say you know here's here's a proposal and here's a k and here's a catchy name for it and let's go implement it and i think like if you have that then you know all of the community people would be in favor of it i also think like isn't that what eats 2 is and i know i know like that uh obviously it's not live yet and

and what not but like basically as long as demand for block space will exceed the supply like the prices will go up and it seems like the the increases we're seeing now are not like a 10 20 30 percent increase in block size which is you know what we'll be getting by increasing the it's one block size like we need like a multiple orders of magnitude fix and and that's just like not gonna happen in the next at least six months like a year like be very optimistic so i and roll ups could do it before a year but um yeah uc would take longer yeah and i think that's also something i

don't know like like you mentioned 1559 people kind of see that as a solution but like it won't solve this um right increasing the blast the blood gas limit the 15 000 or 18 000 won't solve this um you know they'll all marginally improve but it won't bring gas prices down to two way for sure i mean like the other one example of a concrete fix is just like the the skinny gas repricing that i proposed and that's just like one example of something that's kind of conceptually simple enough though that it would theoretically be able to catch on the the problem isn't the problem state

size growth and block processing not like from from the protocol well so there's two problems right like one problem is the dust and attacks and the other which has a kind of a short-term problem like what if someone attacks us and then the other problem is state-sized growth which is um a it's a long-term problem so like someone can't use state-sized growth to cause the network to break within the next week but it's um just like expected degradation over a few years and i i guess so we we do wants to kind of treat those two those two problems separately because they are kind of technically at least somewhat separate and as for

actually so i'm actually solving that second problem and state stateless clients exist as a thing um is there is there an inflection point where we go from the services degradation to things being actually terrible as far as state size growth is well the problem is that the cost of accessing state is logarithmic in the size of a state so it's the so it is fairly linear at least it seems to be like there could be like from the point of view of each individual computer there's going to be

a point where like your disk goes from being 95 to 98 full and then suddenly you're defragging everything and like it breaks but that's more of a kind of one not at a time thing and on the end of everything simultaneously breaks thing but like i mean chronic problems are problems that we do need to take seriously because like just from a kind of social psychology point of view the acute things are easier to coordinate solutions around but chronic things like they can cause as much damage but it never comes all at once so i mean it's not a reason to not care about earlier it's the opposite so just to add a bit to that the problem the biggest problem that we

state growth that we have and that's one of the reasons why we're kind of opposed to pushing the gas limit too high is because uh essentially during shanghai we had this so the experience was that shanghai attacks first started by bloating the state and after the state was bloated up quite a bit then we had various attacks on various caches and whatnot and um and after shanghai essentially the solution the first solution was to make state bloat expensive so that we the attacker couldn't send me more junk and the second part of the solution was to actually delete all that thing now the issue is that uh if we just let's suppose

we ignore dust blocks for now just let's just increase the gas limit to whatever the network can handle the state keeps growing it keeps growing but at the point where we reach it where where we reach this inflection point that something goes wrong there's no way turning back so there's nothing we can delete so we can make things more expensive but we cannot just delete stuff anymore and i guess that's um that's something that we need to take care of and look at very uh from various perspectives so you need to look at it from uh disclose the screens you need to look at it from this christ you need to look at it from synchronization perspective and it's fine to push it but you kind of need to be aware that if the state

doubles then what happens in synchronization because i can tell you that if for at least as long as we have passing if the state doubles then fasting sync time won't double it will probably go up exponentially and these are the numbers which uh i don't even think core developers know they just have a feel for it and maybe if we were to try to somehow visualize them and see that okay the state is 10 gigs how much does the fast sig run if the state is 20 gigs how much does the fast increment and if we can somehow chart these out these out then we could perhaps we ourselves could see whether this is a problem or not the thing that we need to take care of

is is not to enter territory from from which we cannot go back the blog estimate from a denial of service perspective at the worst case let's suppose somebody figures out a way to attack the network um we will have three very shitty days to bring the block estimate down but eventually it can be brought down so the dos can be so to say stopped but the state that once pushed into ethereum cannot be removed so we're having charts and then perhaps a report that we could we could have someone do a report on these kind of things specifically sounds like the thing to do

well but all these things would in my opinion just help explain what the quarterbacks are afraid of they don't they won't really help solve the problem in any shape or form yeah so i actually did not want to jump too early into proposing solutions and i actually did propose a few things over the last few weeks around the and i don't think it's kind of good to try to propose them here because there's not much time and people just need to kind of read in them and think about them um but i wanted to also remind that we also had a slighter disagreement on the previous call for

it's just for people who probably weren't there um and so there was a point if we go through these um the retrospective again so one of the why questions so we kind of there was an agreement that it was very difficult to write a fully functional ethereum implementation which is also performant and this is where we started to ask like level three wise and then we came up with uh different answers just about four answers i've recorded and so the theorem protocol is very is basically just very hard to implement in a performant way so something inherently about something inherent about it then the second one is that we're dealing with such

big volumes of data transfer and computation that you have to do the constant optimizations and these optimizations are cutting across component binding boundaries and just ruin modularity gradually that's that's the sense i got from last call um but my own views on this is that there is nothing inherent inherently super bad in human protocol actually just we we just started off with the bad architecture a few years ago and the the optimizations could be done in such a way that the modules are still preserved but it has requires a lot a lot of work and so

the so i see it as that they we could probably do a lot a lot of technical work over a lot of period of time and fix this issue the the architectural issue it's make it a bit easier or more much more easier for people to jump in and start taking the the ownership of specific components relief the relief the burden of the one single team but but that sort of my skepticism about this is that will be will this be worth it will do we actually have enough sort of resources for this do does anybody even want this to happen or do do do do they want us to just basically coast along until

ethereum 2 comes out comes around and then which just basically just killed this whole thing well just to argue a bit against that so a lot of people see it as ethereum 2 as the solution to all this problem and essentially what i want to emphasize i emphasize a few times already that ethereum two will introduce n shards now i'm not sure what the number is currently is whether it's 256 or whatever a constant number of charges 64. okay thank you so that means that you know if if theorem two will cut the current problem in 64 that's kind of two orders of magnitude

but that still means that we're just kicking the can down the road so these problems still need to be solved for ethereum two two of course that it would probably mean that we have x more years to solve it but the problems themselves won't disappear so we can't just ignore and wait for ethereum too oh no no no i wasn't suggesting to wait for it so i kind of i'm talking not about the sort of technical problems but more about organizational problems so let's say that if um if we we we may come up with a brilliant plan like uh we create the architectural working group as i suggested and we figure out the correct have to catch architecture we start building components we start doing

amazing optimizations on all the components we get the good specialists to optimize them to help and things like this but um the question is is going somebody is going to allow us to do this or should we just jump into theorem 2 and do that work there because actually they will have exactly the same issues they will ruin a modularity by cross-cutting optimizations and so forth uh so that was my question well my answer to that is ethereum 2 is in a very very unique position and i think we should definitely use and abuse that position namely that so one of the shards of ethereum 2 will obviously be ethereum 1

and that chart will forever bear the burden of every bad decision ever made but for the rest of the shars it's a really unique opportunity to to fix the bad ideas for example if this is just an example i i don't want i'm not definitely not necessarily endorsing it don't want it but for example uh state rent cannot be introduced on ethereum one alexa you've tried quite a lot and you know why but in ethereum two it actually could be introduced because the moment you are building a new system and the moment you are launching a new shard with no contracts in it it is fine to have a different set of rules

and i'm sure that we could dream up a couple more rules which which would make scalability a lot easier to do if we had a fresh slate so maybe that is actually a good good position good point good point to take is to try to figure out what are the simplest no-brainer architectural changes that should have been done what cannot be done anymore and maybe let's try to do that for ethereum too and then maybe the solution there is to say that well 63 shards will be super performant and then we will have the 64th eth one shot which will be a bit crappier but yeah that's legacy and that's the price

the the going back to alexis comment earlier the about resources and being able to do this there's are things that we could do that don't really take resources but would change the game so to save for the community and encourage people to do their own work like us doing all this information and us including the ethereum cathedrals and and the people on this call going and finding out is are the is the network sufficiently distributed is there vulnerabilities and all those things is a lot of a law uh could take a lot of resources and then doing research and and

publishing all this stuff about making sure that the the client distribution actually being distributed is important that's all a lot of research resources from our end that that needs to kind of push or make something happen whereas if we said like something simple we could say is we won't push hard forks unless unless the network is sufficiently distributed among clients and then once that is said the network around us will figure out how to say is it sufficiently distributed because they're going to want things to be included and so orienting everyone to work

towards the same goal rather than us trying to make it all happen like um i i guess there there are simple things we can do that that don't take but it just takes deciding them well i sort of i see where it's coming from this particular idea that you know you can put more restrictions on you know like gate keeping on the ips and expect everybody just the world around us to to to adjust but i think the issue i take with this approach is that it sort of simplifies the the the stakeholders to just one group like it's it's us and then them

so there's basically us core developers and them everybody else but in fact there are so many of them and the different people are doing different things and it might be that by putting this restriction you're actually going to unfairly affect some people who are actually doing most of the work but you're you're not going to do anything to the people who are actually to who you do want to take action so it's essentially like it might be completely useless and even harmful to impose restrictions because if you know that the people who you want to restrict are not incentivized to do anything about it then it's completely useless and it's even harm it's harmful so i need to i want to but

i that is if if no if the network doesn't want to get to work together to be to distribute their client implementations then they don't want the features that they want to come through the forks to happen and so then we could just work on optimizations no this assumes that the people who want these new features are the same people who are running critical installation which i think is not really the case i mean it also assumes that people who want the new features care about client diversity but i can imagine you know some stakeholder groups saying you know what we don't care we just want geth uh and we're fine with that so yeah but if if you tie the feature to

having distribution then they then they will care about it like if we said 1559 won't happen without client distribute client being sufficiently decentralized to to then you have immediately everyone that wants 1559 is going to be very interested in how can we make sure that the client that everyone is downloading different clients but how do we prevent that from just being um you know just something to appease us and then as soon as that's out they just switch back it's not it doesn't seem like a very sustainable solution well we've we've already seen the clients installed become pretty sticky and there are if if the network doesn't want anything

more then that's fine my fear is that's not what's gonna happen they won't they won't like install base u just to get 1559 they'll just say this is like just implement 1559 and geth and we'll pay it and we'll download that i i feel it might be like more adversarial than uh collaborative so that's that's what i'm scared about it's like that backlash and yes and i also don't want to encumber this this this data that we would like to just to collect that we're talking in the beginning of the meeting i do not want to have any incentive for people to lie to us and if you try to encumber this metrics with other things

then immediately you create incentive for people to lie and that is increasing likelihood that we get rubbish data essentially and so and there is no stopper from from these players from just taking death and just changing the client identifier and code it's not like it's rocket science yes i i don't want to derail the conversation further on this but it's it's yeah the i i i see a lot of thing of discomfort put on client teams and so i don't think there is a world where somehow we're going to not discover someone

so it's uh and if we want if things are remain how they are the same oh actually i'll i'm let me let me let me just change change topics and then respond to lexi and then i want to move on i think uh going back to one of the initial proposals of alexis like if we are even in doubt of accuracy of this data that we are trying to collect here uh i i'm leaning towards thinking that if we can make the organization name as a mandatory field for people to uh like write it down there may be that can be one of the ways to assure that the data we are getting is not all

like all on that data they can be reliable i i think the best way to make sure the data is good is to make it sure make sure people will willingly provide it and there was no reason to basically provide the bad data that's i think the only way you can actually make sure that this is correct uh any other way uh is going to fail because people always are very clever to to to work around the rules so just to give an example if uh if i would decide that i want to run with um go ethereum and somebody would tell me that well

uh i have to run something else for a fork to happen then honestly personally i would run go ethereum and then i would start 10 more go ethereum nodes which will just fake their ips or i would just modify mine to fade this id so the problem is that this is so easy to circumvent that it's all right um the the other the other thing that i've so just i've been most trying to observe these calls in these conversations and i've um something that i s that and not try to go too much into things

uh something that i had saw in the first call at the very end and the kind of the pressing need that comes to me maybe is just because of my role and that's why i feel that way and maybe i'm feeling i'm over feeling the situation uh berlin is technically all clients are ready for berlin pretty much and at the end of the call the different clients here uh went through and said yeah we have support of berlin we have support of going we have supported blind but at the end of the day berlin is like even though all the clients haven't integrate have it integrated it's not ready to go to hit live on the network and some and the what i was noticing what it felt

like to me was that there was a sense of yeah we well we already have berlin we already have berlin integrated so let me just wash my hands and then but all the clients are washing their hands and then geth is left with the well we actually have to make sure that this is done and like the state tests and and and all of those things are sufficient and then i like in that moment i saw the pressure happening where where client certain clients were stepping back and so and a lot of the the things we've talked about seem like stuff that will help in six to nine months if we start working on them now but i don't see

i'd i'd like at least something to come out of this that would be in that we could be doing in the short term that would address that problem so i thought we discussed that on the very first call we had this conversation and there was the idea of like martin starting to host this sort of fuzzing call right and and i think uh we wanted to to maybe push that back after after july because martin you were gonna take some time off to decompress but um i mean i think that still feels like a good idea to me i'd be curious to hear what other people think well actually i i did send out

the new invitations uh i think yesterday or the day before yesterday uh so i reached out to bisou and to open ethereum and to nethermind and although also alex lasso and so that's happening uh so i guess the first first one of those with the new participants might will be on monday and and i do like we are taking the break from july so i want to honor that coming august 1st what's going to be different or is do we is that sufficiently

different or is there more things we need to be doing so my suggestion is that we do need to talk about or or either on a call or outside of the call on the sort of so the reason why we we i was actually advocating for almost like a freeze of features is because i wanted to make sure that the the developers in all the teams have the sufficient time to i don't know to work out what do we need to do to remediate some of the immediate things uh so if we think that this is a really long game and we

are prepared to play that game and comes back to my question do we want to do that long game or not um then it we still we haven't figured out any specific technical solution and and i sort of agree with italic here that if we have come up with a solution then people can rally around it and yeah so i don't have technical solutions okay sorry sorry i'm totally interrupting you i'm sorry but no no yes please um sorry i've been listening this whole time but i was i was driving my kids to school and they're loud so i couldn't sign in until now um yeah so i mean this is of course my

opinion of what the technical solution is and i've presented it before but i still feel like the solution to client diversity exists at the network level and it exists in splitting the network up so that we can actually have different kinds of clients and that we don't have to build monolithic clients and that this gives us easier to build clients and a more scalable network like i think that we know what needs to be done we just need to focus more resources on it and get it done so the one issue i see with it is that in theory i kind of agree with it but

in practice the simplest uh example will be that while it would be nice if one team could work on running full nodes and another team could work on running a super light client the issue is that the live client actually needs a light server which is a full node so even though i think that we can build light infrastructure that doesn't need light servers yeah i agree well i did have a proposal for that but i guess my concern is that even with that solution existing is the is it sufficient to say we don't do anything in the meantime but i like that that is a minimum months kind of thing

so then do we are we comfortable saying we pause stuff until then i don't i don't i don't i don't know exactly how to move forward so stateless is going to take a while because formally supporting stateless requires some multi-stage protocol upgrades that are difficult and hard and those are being worked on um i am still a very big proponent of building out a dht based state network which can help us in a lot of areas that's an area that doesn't have a lot of people focusing on it um and that alone takes a lot of burden off of full nodes

and different things and also lets you essentially expose the entirety of the json rpc api without even connecting to the dev p2p network um and that is something that should be deliverable within a very small number of months because it's a pretty well understood concept um at least like in the mvp stage like yes none of these things are things we're going to turn around in like a week or two weeks or a month but like we are facing systemic problems if somebody shows up with a quick good easy solution we should run with it but we have good direction on how to handle some of these systemic problems

i think we need to focus on them well yes i do see that if we decided that we want to take the long game let's play the long game i would suggest that we find the the like the points where we could split up the you know introduce this kind of modularity because the the idea behind this is that we do want to start separating responsibilities and make sure that we can grow teams uh and to add resources to the team so that they feel less pressure that they can have the more specialized people working on components so we could look at the the the existing

current existing client architectures see the points where it makes sense to uh to split things up and then just to work towards the more modular design just for that purpose so then do we are do we feature freeze till that point is that the suggestion well the feature freeze i would suggest it until the point where we actually figure out what we're going to do because again we figuring out exactly what which which approach is going to work is not it's not quick i mean it is going to take a lot of work i don't know how much i don't know but if people prepared i mean again this this question goes back

to to go ethereum team is that do your you know because now if we assume that the network runs on go ethereum the question becomes are these people are comfortable with keep with going with the features or do they need some time to grow and do they need to time some time to to regroup and things like this because actually it's not fair to try to put the pressure up and expect everything to happen right we are in this shitty situations and we either get ourselves out to the situations or we at least make sure it doesn't kind of break it doesn't get worse because i think if we keep the pressure up with a shitty situation we could just make the shitty situation worse

worse and then the the things will happen that might actually not be reversible um so yeah yeah we're kind of i think i think it's uh i think it's pretty much the situation here is that we either we either make a great jump and we do it now or we die eventually simple as that and i would personally i personally feel that um given the state of the problems with scaling right now maybe it would even be a good idea to maybe shift uh much more resources from the development of the current clients that exist today to actually making the new clients based

on the module structure well i mean that i'm not really sure that meant so i i don't really understand what that means i mean um you can't really expect me to jump into another client and build that so how how are you how what are you suggesting how what should who should be jumping to other clients and let's just spend a couple more minutes on this to make sure we get to the rest of the stuff on a call i think if we have other things to get to then we probably just need to hard stop because what we have 15 minutes yeah i was gonna give it i was gonna give it another two minutes and then

heart stop it i suggest that if people are willing to to keep to talk about this we could have another uh kind of non unscheduled uh talk about this if we or we could do it in the chat or whatever form you would want we don't have to only do it once a week once every two weeks i think if there is an appetite for the discussion because i would do want to get to the point of like what are we comfortable with and do we how do we proceed in such a way that we're not making things worse and or more importantly we do not make uh things worse in in a irreversible way as also as peter was

suggesting with some of the things that because there there might be something that we can you know we can do bad decisions now but then we can reverse them but they're some things which you can't reverse and that's what we want to be careful of yep uh so let's get to kelly i hope you're still here yes i am here can you give your update on the ip2565 yeah sure so um just wanted to provide a quick update uh into this call eip2565 which was introduced in uh march to reprice the mod x precompile uh has now moved into last call so i

believe about a little over a month ago uh it was marked in in this call for eligible for inclusion it's now been finalized fully based off of the the feedback and um a number of iterations with the open ethereum team to uh look at um possible ways to to sort of improve the performance of the open ethereum client uh ultimately we weren't able to find a better library to use for open ethereum so there is still you know maybe two to three x um uh performance overhead of of open ethereum versus gef but uh you know that's something that that we'll live with now and and at some point hope to uh optimize in the future uh so that's that's the update happy to answer any

questions but just wanted to call out that uh it is in last call now for uh through the end of july great thank you kelly your work on the eap is exemplary and i hope people in the community look at it as an example of how to handle submitting and getting the ip through the core process thank you the next up is i so i don't believe there is someone on the call who can respond for technical questions but the there's been like i don't believe uh light client is here either for to the eip2718 the type transaction envelope

so we haven't really had a chance to discuss it fully on an all cortez call and i know i'm not in a position to sit to respond on questions but i did want to get a read from the clients if with uh if that is something that could go into efi and if there's more questions about it we'll just have to delay it but if if all the clients feel comfortable that they that given their understanding that it can go to efi i'd like to motion that it does i can also potentially answer questions if anybody has one oh good thank you father uh so i just wanted to mention that this uh

the eip transaction i don't know wrapper something something yeti my only concern is the same that i had with um there was this account abstraction eip with the version numbers namely that i'm old for supporting multiple versions of transactions if there's a good reason but i think whenever we introduce conversion transactions we should also introduce the first new version of a transaction because otherwise it kind of feels like we're just introducing an abstraction but we're not really sure how that will look like in the future so so 27 wait is this 2718 or is there a

different number yes it is it's 27 18. uh so 2718 actually spawned from a different e that is introducing a new type of transaction so it was monitored transactions it's a separate gap payer for a message center so we could absolutely bundle this with 2711 thank you micah which introduces the next type of transaction which is the sponsored transaction or maybe it's not maybe it's the anyways there there are already at least two other eaps with that build on 2718 so um if you want to see how they're used they are there yep sponsored

batches and expiration based transactions yeah and there was also uh yet for eip1559 we didn't use type transaction yet because uh it was just a draft but as i understand it it would it would simplify the implementation a lot if if it was part of the protocol before so if it was efi i think there could be a good case for uh kind of rewriting 1559 once it's further along to use it and there'd be benefits to that as well does that resolve your concerns peter yep yep thank you cool

um is there a bass suit or i i guess let's continue with geth would that moving the type transactions to efi be okay i don't know how to access exactly um any more opposition from the base u team no i think it would help us with 1559 a lot so okay and open ethereum no opposition from us uh

nether mind we are someone from another mind able to give a response i don't think nethermine's here yeah okay and then piper i'm i'm like implicitly on board so yes that's my that my client team will be happy to implement it okay one one thing yeah i was just skimming uh yeah i think i brought it up a couple court of course ago too just wanted to emphasize it but i think currently dip allows the current transaction type to have two forms

the current one plus a new wrapped form where the type id is zero and the problem with this is that this kind of means that a transaction will have two hashes um so i believe that we settled on the at the at the protocol level only the new format will be allowed but that it is trivial and that the hashing mechanism for either format would remain the same so you would get the same in half either way i'm not 100 sure that that's the latest eep but either way that at

the protocol level only the new format would be allowed and that eliminates any ambiguity in the header transaction route field which would be problematic if we allowed either format at the protocol level itself so then essentially when the four kits we would forbid the old format and um i believe that the idea was that the old format can be uh mapped to the new format and that the new format remained the legacy hashing approach so that um there wouldn't be a big blocker on software that is still submitting

specifically things like hardware or wallets and all kinds of things it would still likely have a long tail to update to submit this new transaction type so we can still accept the old type and then clients can internally map it to the new type um okay but that means so from a signature perspective that it means that people would be signing the old one there's some comments from micah in the in the chat that are going by as well so um so let's see um signing yeah so signing on the old and new one are the same

so so the new format is literally just a reshuffling of the old fields and um and adding the the type to the front that's it well yeah but then what happens if i introduce a new type what will that sign the new type would follow whatever eat specifies it so so this is essentially backwards compatible we just at the protocol level force the legacy transaction format into the new format um and it gets a special set of hashing and signing rules that may not be orthogonal or the same as as whatever new transaction types we introduce

yeah but the fact so if you say that you at the protocol level you change the format but at the signing level you don't change the format then you still end up with this mixed bag of things um no there's no there's no problem with a mixed bag because at the protocol level only typed transaction envelope type transactions are represented yeah but if i only sign the internals of the transaction then i can arbitrarily change the wrapper i can change from type 1 to type 2 to type 3 and um that would be so any of we would need to look at that but i do not believe that any of the that there i don't believe that there is

any practical problem here because um yeah the there's a strong recommendation in the spec that all new type transactions include the transaction type in their signature and so it's something that we just need to pay attention to going forward but i do not believe there's any actual systemic problem we just need to make sure that we don't accidentally introduce a new transaction type that can be mapped to the legacy transaction type or something like that oh yeah but if you enforce the transaction type to be part of the signature then that holds for legacy type 2 or not we're not enforcing it it's just a strong recommendation in the base like um

but what does it mean i mean that means that i i get a choice whether i want to sign something or not so current investigation i would recommend that you go read through 2718 because i think that if you do and you look at the the way that we're mapping legacy transactions you'll see that this is likely not an issue and if it is i'm more than happy to see it but i but i do not think that there is a problem here okay fair enough great so i i'd say that with i remind everyone that efi doesn't mean something is going into the corporate into each one or the core client protocol but that it's the first step in many

stages and and that it be moved to efi at this point and that i believe is all for today let me look at um i had a kind of proposal and agenda for discussion but uh alexis has answered uh kind of it was his comments that it takes 40 milliseconds for miner to assemble the block to remain profitable so um i would want to discuss another question which i actually wanted to post on the previous call as a part of the work and like

uh 2567 um i have spent quite some time to make state tests for clients uh using the suggested retest as a tool and a manual which came along it which actually diverged quite a lot from the real from the current state that some that actually stay test in the form which is written in the manual is deprecated now in gas and it should not have worked but i had to monkey patch it and then started to work again so after all this discussion started that like let's try to postpone the forks until clients can get to the speed and

says there is potential pressure and gas team to ensure the code quality and no consistency issues between guests and other clients can we also discuss that current state of testing tools for ethereum uh is i would say quite low and it was very painful to write the state tests and like for everyone less prepared and less determined to make like to introduce a large change with eep it wouldn't be prohibitively hurt i think uh yes you totally i mean that is totally the case and it has been so weird

for a long time and it's not something we have managed to solve so maybe this would be a better priority with a clear like direction and direction for solution than trying to make uh without any data and clear solution like client diversity but maybe make first bit better tooling so it would be easier for like current teams to actually ensure the good quality than trying to change the full state of the network to run many different clients and this way like if something happens at only twenty percent of the network down

um it's still like the solution sounds kind of well defined that better tooling is needed and this should be some resources spent on this uh and it's else is the same kind of work as if it's done it will not get make things worse even right i mean like not great yeah so i totally agree with what you're saying so i don't i don't have any issues with what you're saying uh but to give some context we have been trying to do to improve the tooling uh for a long time uh as late as i think last week

someone turned down we had interviews with the potential lead to help vamp revamp the the testing solutions there is actively uh we are actively looking for someone to basically take the lead on that and it's something that has been we've been trying to address these issues for a long time well we've been talking about it for at least a year and that's just martin and i uh yeah this is yeah we're we're we're at 9 29 so

um i do like the direction of conversation how to get more resources and people to dedicate resources to testing would be great it has been very difficult in the past to make that happen right it's been attempted a few times um maybe we'll go a little bit i don't really want to go over what if someone has something that they feel strongly about sharing at this point i would invite that they do that another otherwise we can continue offline or and i would like to schedule a call for probably next week to continue this conversation well as a person who spent quite some time

pushing for 2567 for for consensus between different clients on berlin and if it actually can be kind of scheduled sooner or later in a reasonable time frame and in the meantime maybe it works pushing modex and static calls there too we're currently right now investigating uh what i think is a consensus failure um it's no it's not in a good state and we have several weeks of actively fussing it before we can feel anywhere near comfortable with it okay well we can discuss this part uh offline or on a fuzzy

uh like separate fussing uh call yeah thank you for dog fooding our testing infrastructure alex or i guess that's yeah any i was supposed to be kind of a funny joke but i'm not very funny so here we are that's fine thank you all for joining today it was a great conversation and i'll start peeing people about if there's a time we could continue on this on the client diversity topic on a separate call for us next week if you're interested let me know and have a good day thank you thanks everyone thanks everyone bye thanks bye [Music]

[Music] [Music] [Music] [Music] [Music]

you