All Core Devs - Execution #93

Transcript

[Music] foreign so

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

[Music] so

hello and welcome to the ethereum core developer meeting number 93 i'll be running it today my name is hudson and getting on with the agenda the first uh item is the ethereum classic chain split and 51 attacks um and if there's any client implications for ethereum and just to help us understand what happened more um way if you don't mind um going ahead and just kind of describing on a technical level what happened the first and second time that um etc got 51 attacked um and so we can kind of start talking about if there's anything we need to do from the ethereum side to

um prevent something like that from happening here yes yeah so uh so i i just want to to focus on the the technical aspect of this so i mean basically the the the 51 percent attack was quite nicely it happened twice uh and the one uh interesting thing i think the only really interesting technical aspect of this uh that also played a really important role in both of the those two 59 percent attack is the maximum uh layout cap so uh the how many rear you can you can go over the the pass blocks to

to go to the the new block uh so uh so the interesting thing is for the first uh the first attack uh it was detected because uh partially because there was a split between the open ethereum gas client and then the assumed classic team firstly saw this was a bargaining operating system and they asked everyone to to switch to to gas so uh later we figured out that this was not a bug this was the maximum maximum reorder cap

of different values implemented in potentium and gas so the interesting thing is for this time there was an attacker 10 and another 10 which is mine by normal miner i would call the legit chan so for the the legit uh chan uh it's basically the one that is uh by the like operated by the the opening theorem client and uh because of the open serum plan has a really relatively low uh maximum react cap around several hundreds so all the open ethereum clients refused

to reorgan to the attacker tank but for all the all the gas nodes uh the the maximum layout cap is quite big so all the all the gas nodes immediately react to the attacker check and then later because the attacker channel already has a higher total difficulty so jtc just proceeds to the attacker chan and then also create a minority split uh uh like all for the extreme nodes and uh for the second attack uh the uh so so at this time if uh

if the the the network uh maximum react uh cap would be lower than uh the then we would basically have defended the attacker like it's not a really sophisticated attack and uh so that i would basically highly defend it because uh the double spin will not work i know the attacker manuals will be lost as well uh so uh so yeah so for this is the first time and then so it is a team uh they asked everyone to switch away from opening serum to guests uh so and then the second 51 attack happens and this time they were not that lucky there was no

opening 0 minor so basically everyone immediately arc and later they actually tried to white list the legitim uh for everyone to man on the lead time and ignore the attack chain uh but uh but because the the rear has already happened so it's already too late to organize this kind of thing and then that deal hype as well so it's kind of uh every time they for both of the two times uh the attacker successfully uh did this this attack uh so what's uh what i think is uh maybe worth discussing is whether

whether we want to like coordinate for different clients on uh value of the maximum rear cap to like uh uh like basically trying to make those uh just simple like for for for many many 51 percent attack is not possible to defend but for this simple type of 51 attack is indeed possible to just defend it by citing a maximum railcat real cap and then basically just ignore the attack chan uh in this way uh so from what i know also in the uh in after the second

uh uh the second 51 percent attack on etc uh the legislative team they also realized issue and they are implementing uh they call the the immutability threshold in in in their their gas plants it's basically just a maximum real character that is much lower than the current uh maximum uh default value in gas so yeah so [Music] so is the suggestion to have a maximum or not or have a standard maximum or not have a maximum

reward cab i think i think this those two attacks probably show that uh it would be better if we have like a default uh maximum react cap for that is uh that is probably standard across most clans that may help just my opinion so by the way um the default rear limit in get is three epochs so 90 000 blocks and the reason why we chose that is because um three epochs is about uh two weeks and based on past uh during the i'm not

even sure about the shanghai attacks so i know it does a byzantine switch when getting paired went out of sync and um and essentially the reason why we kind of chose two weeks is because we thought that uh let's suppose the chain goes off in some really weird tangents for some reason i don't know but that you know i have service whatever and then it gets reorg back to the proper chain and we kind of figure that two weeks should be plenty enough to sort out all this issue and then if we set the maximum this immutability threshold to two weeks that means that after two weeks if we didn't manage to solve the issue then okay you have to re-sync you have to do a lot of weird things but two weeks is a long enough time to allow

the chain to sort itself out and everybody just get back automatically to whatever the network considers the canonical one so that that's why we that that is the reason why we have it at 90 000 blocks and not that i know half an hour or one hour because this way you can automatically handle these scenarios and there's one other aspect that i think should be mentioned uh so if clients start using a shorter reorg cap it still doesn't change uh any any client who does a fast sync and he just selects a pier with the highest uh highest difficulty he will sync up to

the the well the wrong chain or whatever um and that's still an issue that needs to be solved because otherwise you have this weird state where everyone who who synced prior to a certain date there they went up in one chain but if they ever you know have to rethink they're gonna it's gonna be very messy and painful i um i yeah i i think i think this is mostly about um like um attack scenario so uh we're like all the all the nodes will have to react immediately uh like yes there will be

uh like if if the the rear cap is lowered then there will be a short period of time where uh likely all the miners will not be on the time with the highest difficulty but the thing is uh after the attack is over then the the the like like the legitimate will still be quickly catching up on the total difficulty and overrun the the attacker chan in a really short period of time so so it's kind of yeah it's kind of a trade-off but but probably one argument i have is that by setting a like maximum

setting this uh getting a standard maximum real cap then we would be more likely to avoid disruption because the exchanges like miners they they are most likely already online during the attack time and if zero transaction getting re-argued is uh it's a it's a big issue but uh if some some uh some new notes sensing up the network during the attack time then uh yeah it's also issue but it's uh it's a much much less less like a severe issue because they can just rethink their clients after

[Music] the attack is over or something well there is another side of this so i think in bitcoin cash they also had a similar issue because they were minority chain and they um one of their main clients bitcoin abc they have introduced the check pointing i think it was 10 blocks or something which is very short and the security analysis of that particular change was that although it does sort of uh reduces the uh the risk of these uh d pre-orgs it could actually bring another uh that could bring the possibility of another attack where

essentially the the attacker might um get different nodes into having conflicting checkpoints i mean it's a more a bit more sophisticated attack but essentially you end up different nodes check pointing on different blocks and they will never be able to reconcile again so you actually have to manually intervene and just reset the checkpoints and stuff like that i don't know all the details but i remember there were downsides as well as the upsides yeah yes yeah so uh yeah so i just want to clarify that uh that that 51 like like it's basically unfixable but what i was trying to argue is just that like either you always

need some intervention but what i was trying to argue is uh it's just about how we can like if that happens how we can like reduce the impact and make sure that the least amount of damage was dealt with so the argument is that even if we expose ourselves to potential ddos uh still it may or may not be better so this is something to decide then having funds lost because of the 51 attack

i'd also be curious to understand the dynamics of like the hash power here better because i think a lot of the issues with ethereum classic uh potentially don't apply as much to ethereum because there's just not a kind of an available supply of gpus you can rent as easily um so i yeah i'm not sure how that kind of changes the trade-off well the thing is that essentially etc security was broken down completely to zero so somebody managed to unilaterally mine a more difficult chain than the entire

rest of the network so my problem is that we can discuss different ways to make to minimize the damage but uh the actual damage is that you have an entity who can always mine whatever block and you can always force itself on the network and then you can have this entity censor the blocks you can have this entity essentially you can't have a single entity mine or the blocks in the network the whole network can be taken over with in this scenario so the question is how much does it make sense to protect against this yes you can protect funds from maybe the last 100 blocks of funds from being

reorg but this entity could just as well censor the network or do whatever they want so what's the point at this point yeah i i agree i feel like i'm not sure this is something that should be handled at the client level i guess is what i'm saying um because again like if it's always gonna be possible for somebody to just nice hash uh etc for a couple hundred thousand dollars it seems like it's kind of a like a bigger concern than whatever the clients implement in terms of checkpoints so for example another interesting

attack so the problem is that suppose we can 51 percent of that ethereal mainnet so what you can do is you just you just watch the the defeat exchanges for for five blocks you just collect all the transactions and then you just create five reorg side blocks which in which you maximize your defi gains by simply playing those transactions which which you like i mean the offers and then you just counter offer them and then essentially you can you can do a whole you can be you can completely maximize your profits based on these uh decentralized exchanges and there you

don't need to re-org a thousand blocks you don't need to break the network even reorganizing three blocks is enough and that that would be within the acceptable limit of any proof of work system so is there anyone who thinks that at a client level there needs to be changes made okay so it doesn't sound like it um should we have agree on a block what it like the six three epic block or something like that just and move forward with that oh the reorg cap thingy

yeah uh i don't know if it matters that much that they're the same across clients does it i mean i don't know if we have time for this but in order to make these decisions i think you have to also you know the way told us what actually happened but you know you also have to think about and play in your mind what would happen if the these two different clients have the same threshold i mean we i don't think we should do it now but if you just play it in your mind and see what whether that outcome would be better than what happened then yes but maybe we shouldn't really change anything i agree we definitely shouldn't agree to change something now like i feel personally that

like thinking through the various scenarios and what would go wrong is like we should do that exercise before we agree or disagree to change anything yeah yeah yeah singing deeper i think uh i think this this would mostly be an issue for like miners and exchanges for them to coordinate a value that is this thing is acceptable yeah but i agree this is probably something is not something that we need to do on the client side yeah i'd also like to add that so some of the external parties that are suffering are exchanges and peter also mentioned the whole d5 protocols and movements

and i just wanna um yeah i i agree that on the platform level uh like on a strictly platform level uh things work as they do and if you need more robust guarantees about the order of things happening in your d5 protocol then you you need to you can't just rely on the platform on the platform layer to don't rework you have to actually embed be stable enough robust enough to that it makes sense even in the case of large potentially large reorgs so i think the the layer 2 needs to be more robust yeah but so the question is what's the

user experience so the problem is that with the decentralized exchanges even if you introduce some delays you would expect that if you want to make a trade and that trade happens within let's say a minute or two minutes or three minutes or whatever even that is in my opinion quite large quite a lot of time but just reorgan just handing capping ethereum's the platform's rear limit to 12 blocks i mean that's obviously not possible so let's suppose as we cap it to 200 bucks or 500 blocks but that's already

we're talking about hours so that would mean that if you want to make a trade on your decentralized exchange you push the button and then you come back an hour later to see if your trade went through so again that's not really the best user experience so anyway honestly i'm not even that familiar with these all these different price exchanges i just wanted to make i wanted to highlight that once you accept that there are 51 attacks in the network a lot of things start breaking because a lot of things rely on the assumption that you cannot have the pre-orgs and deep okay every dab is prepared to have one a real depth of one two three

but if you start accepting real depths of 200 then things will go funky yeah i mean if we leave the reorg portion out of it and i mean one could have things like transactions which are only executable past a certain uh block hash so you see a certain block hash and you know the statute of that and you say my transaction is only executable after this particular block and i think doesn't like witnesses solve the same problem implicitly since your transaction is only a valid

if these weaknesses are correct and the reorg would remove them okay so it sounds like we don't need to just to just to time box this we don't need to make any decisions today if any or even to be made um because there's a lot of variables involved yeah but i do think these things need to be talked about because uh all of us are hoping that we will never see each other see such a thing an ethereum may not but i don't think it's bad practice to talk about it that if it happens then what will be the outcome so

so essentially my point was that uh although i i'm in favor of not changing anything for the moment i'm also in favor of keeping discussions going about what can go wrong and what can we do about it sounds good anybody else before we move on is there a place we see the depths of reorgs that are happening because uncles are basically reorgs in its own way or the the depth of them happening like where we see that uh information i don't know if there's any public dashboard of them but so they're present in the guest logs and i would guess also as a metric

showing the length of the dropped blocks drop chain and the length of the chain so when i want to run some infrastructure you can get it charged with grafana there's a flaw on them right now i think they're swapped [Music] but yeah the they bent stats is there yeah and another way to essentially keep them for like historical analysis as well is that um i think i'm pretty sure maybe the guest already does that uh so whenever you see the block if it very if it if it passes the certain criteria like proof of work is correct

blah blah blah it just it has a parent and things like that you essentially save this block wherever it becomes the canonical or not and then later on you can go through the blocks that you saved and actually charged all the the reworks that happened because you would have saved all these reorgs you would have sort of received all that blocks and then you can like go back in time and see okay what happened in that point of time it just takes a bit of development to to make this visualize visualization so all in all i would say that this is possibly we could ask etherscan to add this to their charts because i think honestly this is more of their thing than our thing

okay that's not a bad idea okay um looks like we're going to move on to the next topic now um james if you want to take this one this is on the yolo slash yolo v2 test net and any updates on berlin state test if there's updates on either of those things since it's been a while since we talked about it uh james yeah this is just coming off of the break in july and wanting to get everybody uh synced at the status of yolo and state tests and such so if anyone has updates i'd appreciate it yeah i don't have much updates but i think it would make

sense personally to have a yolo v2 [Music] cool and did peter and you start the yellow v1 last time was that right yes okay sorry i didn't find the button oh no problem okay and so with the with v1 we kind of messed it up a few times uh because the vm died in different ways but what if players need we can always reboot yolo v2 do we want any more eips in yellow v2 or just the same set um

let's do the same side okay we can do the same set for now while we decide what other ones would go in at all because then we can do a v3 for the next ones i'm guessing uh sorry uh so as in my mind yolo v1 is and will always be yolo b1 is like in in my mind the yolo v1 is a set of eaves uh denominated by commit hash to that e uh and if we want i mean a yellow b1 would be either a separate set of eeps or

if the eeps themselves have been modified i know shyamatar proposed some modifications to the to the uh yeah bls stuff i don't know what happened with that so if so if we just want to restart jolo b1 i think we should still call it jolo p1 yeah and the reason i was asking is just because in the past courthouse call i i remember i think it was eip 2046 which changed some gas costs uh that we we discussed including in like a future version of yolo so um yeah that was why but i don't have a strong opinion on either side just want to make sure we're clear on

what we're doing and we can pick this right back up after uh agenda item three point a which talks about 2046 and um alex blassoff i think that's your item right um yeah um i mean with all this um kind of break and delay from development like from further development of new features um it would be still and with berlin being obviously delayed uh now is there is a time frame where it would be possible to kind of work out all the details of for example 2046 or maybe some parts of 266 with consistent pricing of pre-compiles with their current performance

so i was mainly interested in if client developers had some time to run the benchmarks and maybe post some numbers so i can also analyze those and yeah i know way back you produced some benchmark vectors but you hadn't produced them for all the pre-compiles have you done so now well i didn't place modex just because modex is separate but what i have produced is for largely hash functions and p and pre-compile which uh like largely every pre-compile which is out

there which could have been potentially mispriced and i seen in a code base that nethermine has integrated all those benchmarks uh i just couldn't find the numbers uh in any like table form or maybe just a list somewhere and as far as i understood from the guitar charts that besso team uh maybe they did run it maybe they didn't but they want to improve the performance or maybe just don't disclose the numbers if they're very much off and a potential security thread so i'm at least interested in kind of collecting the data and even if the numbers in for example 2666 maybe

should be adjusted up a little bit too much the performance of all the clients not just the gas and openness theory which are measured by missile it's it's still necessary to know for example if there are some constant factors which are off so which are kind of compensated with large static coil price right now but which can become potential issuer if 2046 is accepted so like 266 as a larger proposal is a huge mix it also proposes different error handling for precompiles which is a completely separate question we can discuss it now or maybe later if there is some time but uh

to push 2046 and at least some consistent pricing of precompiles i at least need the data from client developers yeah i yeah i don't quite agree uh what you need is a thumb up a thumb down from the client developers um well i mean there is a freedom in choice of cost parameters maybe i just need to tune them like 25 up for example to feed one like to feed

all the clients not just all the clients except one then it's reasonable to make an adjustment in uh parameters then forcing every client developers like to forcing every client to do uh some card optimizations to fit inside a performance window yeah so for for guests we are on board we think ford gas at least i do in 2046 is reasonable but the actual pre-compiled repricing uh we haven't done all the necessary benchmarks for that oh yeah i mean i'm less worried about

gas and open ethereum because i use them to come up with these numbers but for other clients i just don't have experience with them and not the languages they are written in so i would need the numbers directly from developers so that would be if basu has any kind of update on that um yeah so we i remember for 2046 we ran the benchmarks and if it's been a couple weeks but if i recall we were good with a price of a hundred and i think 40 was slightly too low for us uh i don't know about uh 2666 i don't think we we ever ran the full benchmarks there uh and is there anyone here from

nethermind okay any other clients i'm missing here maybe trinity yeah i don't know if we were doing benchmarks for them in the first place i think that covers every major client because turbo geth is from geth so that'd be the same thing yeah okay um so guests on board open ethereum um i guess alex was running open ethereums you just said right alex um yeah i also benchmarked uh opening in a way like specifically for

2046 which mark is in a martin's proposed way and the number for a safe number for openness you was more like uh 26 or 25 so if there is a margin there so the proposed number 40 was fine for it is it worth including 2046 into yellow v2 so that we can get more numbers run on them not really i think because if we do it only 246 then we um yeah i mean we could do that but we will never roll that out of mainnet because

we need to erase some of the some of them uh if we lower it by 660 gas okay i mean we could we could roll it out if we just want to try out uh the implementation i don't have an opinion it might be worth the time more than just one thing before we do that what were you saying alex yeah i mean um like the most like potentially dangerous part if there was some large uh kind of constant costs in various pre-compiles which are now covered by

the static call gas price and will not be covered by this uh those are partially identified and like not partially they just identified in 266 so if if client developers would be willing to actually just run the benchmarks and i would quickly check them if there are no such constant factors which are potentially dangerous then on the next call for example we can kind of increase it uh on a number for 2046 um and then just accept this and later on like do the uh the separate eep with repricing of the pre-compiles based on all clients data so i i would

kind of try to get the data first and then even try to kind of select the number for 2046 and try to implement it or just vote for it okay that sounds good so you want to do that by next time um i mean i would be willing to check the data and try to get something by the next call if i would be able to get the data from developers but it's not up to me if we stay if this date is available or not oh we wouldn't we would need benchmarks from basu nethermind

and trinity not trinity necessarily because i don't think they were involved in the first benchmarks but um yeah that's something that i think their mind has also data is just either i cannot find it or it wasn't posted somewhere uh like in a plain clear text i remember that he ran the numbers and said something in all core devs but i don't know where that went exactly okay i will try to search the history but still then we need one more data point from basic yeah we can definitely get that by the next call okay great um is there anything else on

that um three point a discussion point of yours alex that you want to discuss um before you move on um it depends if there are many items in a schedule i can pass but it was also a proposal to change error case gas pricing for precompiles and only for breaking files but it would be a long discussion i think and quite opinionated okay we can we can come back to you if we have time at the end you wanna just do that yeah yeah sure okay uh the next eip we have is three point b eip 2780 reduced intrinsic transaction gas um that is from um yuri

uh and i think you're on the call if you want to give an intro to that one and um if you click on the agenda item it brings you to a link to the both magicians and the um eip itself if anyone wants to click on that and follow through while he's doing this this also um i think matt's involved um uh matt garnett so if you are also on the call yeah you are you can also comment on it if you want but i'll start with yuri thanks um so yeah i'll start with the shout out to matt for actually creating eip 2780 and i think i would like to start with outlining the motivation for this eap

and then kind of like is it a good idea is it a bad idea what should we consider and how do should we make a decision and so the motivation for or basically that like the bottom line of the this eap is can we reduce the cost of sending transactions from the current 21 000 gas into 7000 cats and the motivation to do that is that it became very very costly just to make simple trends just to send ether around became very very expensive i'm sure everybody here are aware of it and there's a question or let's say differently the reason for that is that

now transactions have to compete with you know very time sensitive and large amount transactions in d5 and it's a good thing right it's a good thing that the chain is actually being utilized by the most valuable transactions and that's by design but there's a question can we enable more transaction on chain without bringing in negative externalities or with just very very um small external that it's worth the cost so if we were able to allow for you know a thousand transaction per second on chain

and the only cost of that would be increasing the state size by zero zero zero one percent and no ddos like vector added or something of course we'd like to do that and if it was the other way around of course we wouldn't want to do that and so the question is what are the downside of doing a step like reducing the intriguancy cost of sending a transaction and so i want to go quickly over the different concerns and the issues with doing such a move just in order to identify what is what is an issue and what is a non-issue and what's what do we want to see what do we want to test

what needs to be shown in or for for the all core devs to decide that this is something that should be done and so the main you know the main items on the table of the concerns around doing something like that are what are the implications on the state size right state size is already a problem if we allow for something like that and it increases the rate at which the state increases that's an issue there was a concern brought up i think by john adler if doing something that allows for gas token to be allowed to manipulate the pricing even further and um vitalik brought up the question of uncle rate and so these are the main concerns

around it by the way if anybody wants to hop in with a question or concern or clarification feel free to just hop shoot yeah okay a number of issues so first of all in the eep it says the creation of each account adds 20 bytes to the chain state i don't know where that number comes from but it's very very wrong so that's actually a mistake i think it was supposed to be 20 kilobytes that makes maybe more sense yes uh secondly so with one mil 10 million gas there's a max potentially of 476 transactions in a block

and this with this it would be twice that so 1400 transactions in a block and leaving state size growth aside this means that blocks become huge so other externalities is more load on the network side more load on the disk while syncing more data to download today you have something like six hundred million transactions from genesis it's maybe even more than that now um and each yeah i mean it's if you're gonna if you consider that having been tripled it's it's it's big

and it's it yeah i'm i'm looking through this i think the security considerations or externalities are very much understated so a generally i agree with you and let's touch base or let's touch upon this issue as well um um about the attack vector and when you say it becomes big there is a question of oh just blocks becoming big literally bite wise and there is on the other side oh if we triple the amount of transactions how does that affect this like all these must be clarified

and needs to be seen um but let's talk about specifically the point that you brought up um it's just one aspect to add there there is a question of usage and there is a question of attack right whether increasing usage and like well if if usage increases due to this change how does that affect the load you know the i o load and and stuff like that and there is a question oh could that be leveraged to create an attack and my main argument regarding the attack is equi really saying can this attack be launched today could that attack had been launched a

year ago and what would have been the cost of launching such an attack so um definitely should be further outlined in the eve itself in the eap itself um but basically because you're well what if somebody utilizes this new attack vector and just bombard the the block with many many many small transactions can that because now they're cheap how much will that cost today with the high gas price and the utilization of the chain for d5 operations and how does that compare to how it used to be in the past so i think

and i think i disagree with that with peter on some discussion we had on twitter should an attack vector be considered only in the context is it possible or should it be considered in the cost of how costly it is to launch it it's similar to the 51 attack from my perspective um does that make sense to you um i'm not sure can i say something to this um so i definitely i think this this is uh we cannot really i mean at this point i think in a different time we could probably uh discuss the peculiarities of the technicalities of this particular

proposal but i would what i would like to say is that the um at the moment we have this uh crisis situation essentially where we have a lot of externalities as martin suggested into the what i call basically core infrastructure of the network so basically i look at the network as the core and as the as the boundary so the boundary is where your transactions are coming from this is where the d5 websites are sitting and where exchange is sitting and a lot of these things so if the core is essentially the nodes which basically propagate transactions they they sent around the blocks and so the situation we have now is that

the boundary is the where the most value is created and captured and the core is what services the boundaries and at the moment unfortunately we're much we are basically created the system where the boundary is externalizes its cost into the into the core and this is one of the reason it's actually it could capture the value so and i would like to say that we do need to solve this problem and then there are some proposals to solve it to essentially try to reduce the externalities try to push them out to the boundaries so that the boundary uh participants of the network has to actually incur higher costs and the the

core infrastructure has to incur lower cost and we i mean kind of logically it might make sense that you know why the transactions are so expensive and so forth but if we do this uh reductions of the gas cost and make it cheaper uh then yeah i would say that it probably will bring more users but it will also make the crisis worse uh to the point where we are going to be crippled by the by these externalities so and i agree with you that in other situation you know we could discuss the technical merits but i i my opinion is that we have to step back from it at the moment and then

we know already that the network is quite vulnerable to all sorts of those attacks uh you know we don't want to make it worse until we actually have a clear way of fixing it and something that i realized in the last couple calls more clearly for me is that there's another additional dimension to consider the there's the is it possible is it likely but the third one and i think is actually more important and we don't and doesn't get talked about as much as if it happens what can we do about it like what are the consequences and with the state size and some of the other stuff if something goes wrong there is were a

that there isn't like a an undo button for some of these things which makes makes it more leaning on the side of security in my opinion so um i want to respond and i'll try to respond to all these things um i'll start actually james with you if you don't mind um i agree with that that the previous discussion i wasn't participating but i listened to that really touched upon that idea specifically state size and and this is why i want to point out what is an issue and what isn't an issue so the idea is not to say oh we should do this and everything is fine let's just go ahead and do this rather than identify what is an issue and what

isn't an issue and the things which are we consider to be issues how big of an issue are they right so martin just did like a back of the envelope like a question oh well it seems to be big three times big than it is right now how does that affect in terms of load on the infrastructure or how does that affect the network alex i brought the point of is it the boundary or is that the infrastructure and as somebody who's working on the networking layer with the majority of the top 20 pools in ethereum like i i completely agree with that i do want to go over for a second here to talk about the stage size and the guest

token and the anchor rate these things in order to say going back to your point james well turns out that if we did this if if if we reduce the cost of sending a transaction by 3x um it's it turns out that even if we go with a very extreme assumption that that would mean three times more transactions and it is like it's very unlikely but even in that case yeah the state size growth is a major issue and it needs resolve regardless of this but it turns out that reducing the cost of sending a transaction that's going to even if it triples it's

going to increase the growth by something like one percent right if we did this on january 1st 2020 the state size in the past eight months or so would have increased by half a percent so there is a didn't you agree previously that the numbers were flawed in the eip no the i don't have like i i'll redo them i don't want to do this on the fly i think the calculation was done with 20 kilobytes and just what was written there was a mistake but i don't want to i don't want to give a conclusive answer that on the fly when i don't have a second to look at that if that's okay

so that's fair enough uh i was just saying that uh essentially to me uh 20 kilobytes is equally doesn't make any sense as 20 bytes so essentially in the leaf of a plain account that weighs give or take 70 bytes plus you have the trinodes which are maybe a depth of eight or nine that's again realistically maybe four kilobytes or something something so the numbers should really be checked out okay definitely and like like something went wrong with her and i would take a look maybe it was supposed to be two kilobytes again i don't want to throw something from the top of my head

um but going back for a second stay i'm not arguing that james to your point state size is an issue the question is if we change this and we're talking about the usage for a second putting the attack does this open an attack vector that we don't want to open usage-wise it doesn't seem to affect it much even if the usage increased significantly um i go back for the motivation for a second when the ethereum chain becomes hard to use i'm not even talking about one of you guys said something about bringing in more users this isn't about bringing in more users rather than a lot of the people getting very very frustrated

that they can't build things on ethereum and stuff they could do in the past they can no longer do and that cosmet like ethereum has great momentum working for it but it causes them to leak towards other chains which is a shame i think i think the motivation isn't the key thing we need to be discussing i think we understand the motivation i think it's more what what the risks are for this i think that's where the focus should lie um because that's been mainly the questions being brought up but we also need to time box this to a certain extent and also so my recommendation would be to share up the numbers a little bit and maybe cross-reference them offline with a client dev

especially about some of the some of the numbers based on what peter just said um the different parts of the chain that gets bloated whenever the stuff like this happens whenever you know you have a a gas cost that's lowered like this so if you want to give kind of a final summary of this and then we can move on to other pieces of the topic sorry to time box but we do need to move on no no that makes perfect sense and i appreciate that and i appreciate everybody's feedback the idea was to get you guys to alex do you want to say something uh yeah um i mean uh this eve actually touched very um a part for which there is no data available and like

from my perspective purely technical uh increases in our transactions in the block by a factor of two should increase the time uh which takes a minor to actually process and create a block uh like twice the number of uh active actions in such a block um and on the previous column maybe two calls ago there was a number said by alexey which maybe was correct or maybe it was just some uh random number in the chat that it for miner to be profitable he can only spend some like 40 milliseconds to assemble the block uh and this actually trying to clarify this information would be potentially a separate value

uh because it could potentially affect not just this proposal but as a pro proposals to which would later on try to increase the block sizes or maybe introduce richer transactions which require more pre-processing and i don't know if core devs has have any information of this kind if it's not classified um so i actually i i heard that 14 millisecond number i i think it's actually wrong it's something like looking at the logs from miners it looks to be in the order of sometimes in the order of 200 milliseconds if you don't consider the empty block they do

immediately right away um but again i just i want to wrap up everything so you bring up a good point but i don't want to waste further time i just want just the idea is can we like does this affect the time that miners require to process the block does this increase the time that just regular client would that throw them off the chain all these stuff are aspect does this open a ddos attack vector i argue that it isn't but we need hard number for that um my goal here was to bring up and say which are issues and which are less of issues but i'll take hudson's um proposal i'll reach out to a few of the devs team here i hope you like thank you for being willing to respond

in advance um and come back with uh probably on that eap with more um clarified numbers yeah i'd say numbers and then the the things that you had was listed off doing doing the research to show us that it's safe would get you the farthest i would suggest so just one i actually what i want to do like research pardon me like i have like saying like doing a simulation or something that is very very not meaningful in compared to doing like a test net and actually testing that so my end goal here isn't to persuade people oh we should do that rather than let's make it it's a small technical change and

let's actually test it and see if it can work rather than make a theoretical argument that it should work anything can work to test that yeah yeah it'd be hard to simulate i mean you can you could there's simulation software that like i've heard people have developed that can you know simulate something like that but like the type of stuff that like this group usually spins up doesn't have participation on a test net widely um can i just say a couple of other things before we finish but uh the because this is actually pretty good example this particular request is a good example of that we can link to what we've been talking the last three

polls uh so i just i just can't pass it up um so essentially what uh the other two things i wanted to say is that um so we are um sorry i just forgot it so the first thing uh which i didn't forget was that uh after the last call that we had i sort of realized that we do need to uh we need to make sure let it know the let's say gold ethereum team and whatever the other teams will be running kind of more or less dominant clients we need to give them opportunity to basically just say no we're not ready for this uh because at the mo otherwise this chord of cause basically becomes a pressure group

on the on a very small number of individuals because we could come up and say like you know yeah we we want this we want that and so but if they're not ready for it if the if their client is needs a major rework or something like this they should just be able to say no we're not ready for this please wait or if you don't want to wait you know collaborate with the other client get them help them to get around you know a bigger share and then implement this change there and then we will have to do that um and the second point uh is that um which i forgot again sorry is that uh yeah sorry i forgot it um that's okay if you think of it in a second you can

bring it back up yeah yeah sorry um that's a good first point though uh any feedback on that anybody if we need yeah i agree with uh alex i'd like to sorry if we need to have have a bad guy i'm happy to do it you always are um so uh let's see um okay well thanks erie for for wrapping that up it sounds like we have some good next steps for um you to continue on the process of exploring this eip and thanks for bringing it today sure thing thank you guys for taking the

time okay and yeah alexi if you remember that feel free to bring it up i think you're one of the next ones anyway um maybe um i i kept this agenda item in this next one uh how transaction selection happens in a client at the moment i i forgot how far we got along in that on the last discussion so i kept it in just in case anyone wanted to bring it up again but i don't know if we actually need this because no one requested it so i think from last time this discussion starter was mostly because because on the spam on mainnet and and then we discussed various ways to get around the spam making the sort order deterministic and

maybe just a single update that in geth we did implement the this first thing first out sort order so whoever submitted the transaction first will so if multiple transactions have the same price then they will be sorted in the mind block by by arrival time and this one we did implement it will probably release it on monday and let's see if this helps the network or not i think this was the discussion started last week yes that's right thanks for reminding um other clients are you all planning on doing any kind of transaction selection ordering um uh baesu or open ethereum that you are

like already planning on or might like think about we are not working on it and probably will not be working on it for the foreseeable future okay well actually actually i wanted to say about opioid ethereum because i know that they already have the same logic that the geth just implemented and the reason i know this is because back in 2017 when the parity used to uh sort so so the priority had the logic where if the transactions were the same gas price it would sort them by transaction hash which actually allowed uh people to uh mine like to to get the first entry

for a certain block uh sort of gas price and i think it was very important let's for example with the status ico where they essentially capped the potential gas price and so everybody was was given like 50 gig away and so you needed to be able to hash the transaction which was has a low low hash to be able to get in anyway so it really worked and then um i i reported that issue and they fixed it and when i looked at the fix it was exactly what guests just did now is they assorted them by the arrival time so i think there's unless this is changed i think there's nothing there to do okay basically what about you it's not something we've looked at i

mean it seems like it's a pretty small ish change so uh if yeah we could implement it but i think we're waiting to see just how how things go on the network and once geth is out and obviously the majority of miners use that so to see um yeah what impact it has okay that sounds good is the consensus to um just order by arrival time that's it well that seems to be the simplest option at the moment with the fewer downsides i guess sounds good if there are we can definitely investigate different sortings so it

honestly doesn't really matter as long as it's deterministic but the other two proposals are from so sorting by transaction hash still allows you to to mine it and sorting by account hash or account address still allows you to somehow try to so essentially it has this negative effect on the chain that people will start to to mine accounts and then then it's you you end up in these weird things that somebody actually let their gpu miner account for a week and then they have priority over all the all other transactions so it's um i i didn't really like these approaches

that's why we went with the first in first out because that one the worst that you can do is you can try to find where the miners are and you can try to get a direct connection to them or actually miners could sell you a direct connection but at that point they might as well sell you priority independent of when you submit your transaction so yep makes sense to me is and you said that was going to be released on monday possibly yeah is there what would we look for if there was an effect where would we look for the effect i am absolutely probably you

you would uh well the people who reported this initially it was first talked about in the east security telegram group and then a couple of them filed a ticket on death um they i i suspect i guess they're looking at the pools uh i mean depending pools and stuff and analyze the transactions but nothing's going to happen overnight because only when it no longer is um only when it no longer makes sense to do this spam will they stop when it's more costly than than then it pays off so it's going on it's probably going to take a couple of

weeks at least before they realize that hey this doesn't really work anymore we don't have to do it so and the overall effect that we are looking for which may or may not come is that eventually enough miners upgrade then these plays where you submit a bunch of random transactions hoping that you will be the next one these will uh essentially you will only need to submit one single transaction and hope that you're the next one absolute doesn't make any sense a bit more and then people or these people front running they they should fairly fast so if they will realize that there's no point

because they will just lose money on all the other transactions then they should reduce the transactions and that in turn should actually drive the gas prices down because because you don't have gazillions of transactions junk transactions just racing to get included in a specific order so that the benefit actually the effect that we're looking for is for the gas price to go down okay thanks peter uh anybody else on this one before we move on and if y'all update your agendas i added a couple of things at the end that i completely forgot to put in uh just

regenesis and one thing i thought of about changing the software for the all-core devs chat that i want to discuss with everybody but first let's go with regenesis alexi if you'd like to speak on it if you can give a few sentence summary for those who haven't read the proposal and then we can kind of discuss it for a few minutes okay um so yeah so i've recently written the what we called regenesis plan which is more detailed explanation how we could potentially go with it um and so to summarize what regenesis is is essentially so we logically split the state the ethereum state into

two disjoined parts uh we what we call one part active state and the other part inactive state uh we do not change the way that the the state is localized so we keep the the existing ways of computing state root hash and things like that so we simply introduce this logical distinction and so um then we introduced the notion of regenesis events and they would occur regularly at some either preschedule times or maybe by manual decision for example um one million blocks which is roughly six months and what happens at regenesis event is that the active state is reset to just the state would hash

and the everything is becomes inactive state um so then between these two regenesis events during for example this six month window the rules of the games change for the network and they change in like four different ways so first of all the transactions now will have to include an extra attribute which is the witness which is basically a string of bytes which encodes some merkle moon to proof so i'm not going to go into details how exactly this is going to work but i have thought about it quite a lot um and so what happens is when transaction executes first it we find any valid parts of this multi-proofs because actually a lot of

them would be invalid but there will be still some valid parts and we essentially activate those parts that are presented in this witness and we make them part of the active state and then transaction runs um so then there's a block witness which should be fairly small so it's introduced simply for the miners to be able to prove their coin base otherwise they cannot get reward so for the block witness it's again it's attached to the block and uh at minimum it should when if the if the coin basis is not in active state already but they should just include it into the block witness and uh the this lock witness gets added to the active state before any transaction are executed and so then

what we do is um uh we charge i mean in the hard fork version that's the only thing we need to hard fork actually for the regenesis is that we have to include this witness transaction witness as a chargeable data uh so at the moment we only charge for the data but there will be also charge for the witness and the nice thing about it compared to let's say status ethereum design is that you don't have to figure out how to split this charge across multiple senders because the transaction is only sent by one sender then the execution semantics of transactions change as well in a way that if the transaction runs and it hits in an active state then it basically

reverts and the gas spent up to that point is consumed but any effect on active states preserve and so then we also there's a proposal to change the chain id so that after the regenesis event if everybody anything was in flight then it doesn't end up being failing but people will have to resubmit transactions uh explicitly and so the perceived benefit of this uh uh change is that if we regulate the regenesis events properly we might target let's say specific like uh a specific uh active state size small enough so for example that some modern machines can

can store it in ram and so that or on devices with very low latency that you can get easily and so that means that all the state accessing operations like slow balance xcode hash they they don't they just read from ram and it doesn't really matter you don't have to keep adjusting their they cost all the time and then um and yeah so basically then uh there is an implication for the transaction senders is that they need to acquire this the snapshot of the state but not the moving snapshot that we as we have in right now but they just need to acquire the snapshot at the latest regenesis event and that should be enough for them to create a valid transaction

however if they want uh to minimize the witness they need a more more kind of more recent snapshot so this is where they kind of start optimize at their cost and so this is actually what i'm uh one of the kind of more philosophical uh uh reason for these regenesis is that it pushes the cost of the operation from the core of the network to the boundaries because basically the the the nodes which simply uh relay transactions blocks verify things they start to expend less resources but the nodes that inject transactions and we assume these are the boundaries where people could capture value

and so these basically uh nodes will have to optimize a bit more they need to make sure how to download the state and if they want to have a fewer like uh smaller witnesses they also need to get the as fresh state as they want and so we kind of uh the the main difference from the status quo is that the failure to optimize stops becoming the systemic problem because at the moment if we have a all the optimizations pretty much has to happen in the core of the network and if we fail to do continuous optimizations it introduces systemic risk and the network can fail however if we do regenesis then the optimization will have to happen on the

boundaries and it is doesn't introduce systemic risk because the the boundaries are more diverse they have more money around there and uh they if one of the operators you know falls behind it doesn't matter i mean it will hurt but not the entire network so and in if i'm not going to go into the details about how we could roll it out because i think it's very going to be very technical discussion so i would invite everybody to want to discuss it to the um to the east uh arandi discord there's a special genesis channel there and there is also a html file that i published on twitter a couple of days ago which details how could we possibly transition to this

thing i mean that mentions the software hard work but i invite you to read that and so we can get more technical discussions okay thank you alexi anyone have comments yeah a lot of the discussions happening in the eth r d discord so i have a question sure so we'll actually say that the transaction standards need only the state from the latest regenesis event wouldn't they possibly need data from earlier original events generation no no the the the um so basically they need uh the the data

from at least the at least the latest to genesis event or more more recent one right and the reason and so they will have because basically uh if they just simply produce the witness based on that snapshot which was at the genesis so the only risk that they're running is that their roots um so the elements of the witness which is close to the root will be invalid but they will be recognized as such because there will be already you know these roots these elements will already be an active state so it will be easy to find out which part of the witness is valid and which part is is not valid and so they don't need anything from prior to that because essentially

regenesis is a kind of a dampened event it does not depend on what happened in the previous regenesis it simply slashes the entire active state and we start over so it doesn't matter what happened before so if you look at it this way it probably becomes clear that it doesn't have a historical memory or anything this process that's because the witness provides any information it would need you'd have a witness along with every event no because there's a convention that there is a convention that the witness it could be considered if it uh kind of origin if it originates from any uh block header from any kind of root hash from regenesis till now

any witness which is produced according to any of that state is considered to be okay i mean of course the root part will be invalidated but doesn't matter but if the if the witness is produced for for the snapshot which is earlier than that then we reject it uh and maybe it will some of the bits still be valid but uh it will be by chance i think so if you want to guarantee that uh it will definitely be valid uh you should at least take the regenesis snapshot so you can just point me to the discord if this discussion is already happening there i didn't know there was a channel for it

but i'm kind of curious about what is happening at this boundary and if there are any incentives to play some sort of game of chicken where you don't want to be the first one to submit a transaction that touches a ton of state because you want someone else to do that included in their witness so that you can then just assume that the state is already there um have you thought about those kinds of things yeah i thought about this and i don't really have a i mean i don't know if it's going to be a big problem for a couple of reasons maybe i'm wrong but there's one thing is that if uh you essentially have um you know if you're like defy application or something and you run a smart

contract what you're probably going to do is that you were going to submit an empty transaction which simply reveals the beginning of the routes like um state storage routes for this particular um contract to make sure that everybody who does who who uh interacts with this contract will need to submit uh smaller transactions uh but for example for the peace for the contracts which nobody ever cares about because they were like three years ago obviously that's not going to happen and then the second feature that there is uh which fell out randomly almost is that because there is a block witness where which is used by miners to um to to advertise their coinbase

they also can use that to potentially repair some transactions for example if the miner sees that okay here's transaction and it would fail because they didn't include the entire witness but i'm going to just help them out to make sure it runs to the end and so they would include that missing bit into the block witness well at their own cost whatever or risk cost and then they will make sure that this transaction is going to succeed so the miners will have the ability to repair the transactions and i think these two things combined probably can alleviate this kind of risk because the miners in the transition period when we just roll these things out and some people simply forget to let's say to put witnesses or something like this

so the miners could be benevolent and they might be able to repair some of them but you know after a while they just stop preparing and to simplify the infrastructure so maybe there's such concern but i don't know okay any final stuff from anybody else we'll talk about this in the next one x stateless ethereum meeting which will likely be either this coming tuesday or the tuesday after that or or wednesday depending on the uh australia time um can you post that in the all core dev chat whenever

the dates and time and the agendas announced yep great okay the last official item um besides reviewing previous decisions is um a lot of people especially people who are normally active in all core devs chat are now active in the uh eath r d discord i was thinking of talking to them about moving the all-core dev chat from getter into all core dev so we can start having our own little section in there and make subtopics that we can then archive so that we don't have just one single chat channel because i think we've outgrown that at this point there's a lot of people in there there's

spam sometimes there's not really good moderation and it seems like a lot of people are already on discord so is there anyone who has thoughts positive or negative about moving the all core dev chat over slowly to discord to sub uh groups i would say let's move today that sounds good um i my thought is if we could do that in a way so one nice thing about gitter is that it's publicly available and history of it as a publicly available which on discord is kind of true but not

really the history could disappear pretty easily something happened that not happened on discord too yeah that could happen on discord i actually could do a script to bulk delete if i wanted to right that's on discord it can happen on github sorry sorry i meant get i didn't get it i could do the same thing you could yeah well just the admins of them could do that right yeah exactly and i can i can link to there's a public link to chats on getter but there that doesn't exist in discord do you have something to say martin well um no yeah i was going to say so first of all james you have a pretty

good point about you can link send a public link to some random point on getter and i don't think you can do that on discord not unless the recipient is also signed in uh yeah i was going to say that i know the getter it's very easy to just scrape everything jason i have scraped all the rooms i'm in um and i can search locally for stuff i don't know how easy that is with discord yeah that's a good point hmm i mean like discord you could ban cryptocurrency and then yeah well not like it not exactly goes down because they

they run out of money if getter goes down i have all the conversations i've ever been in it's great [Music] it could probably be done on discord as well i'm looked into it yeah i'm looking at the permission sets right now for like on a per channel basis and you can make it so that people can't for example delete messages um i believe i think people can always i think everyone will always be able to delete their own messages someone correct me if i'm wrong um but they won't be able to delete others unless they're a mod so that's kind of like how it is in

getter and then as far as discord going down versus getter going down um who owns getter now because i thought getter could go down pretty easily too uh doesn't gitlab i heard it was gitlab yes yeah so i think it i i wouldn't consider that more of a con that's a concern for any platform but we'd at least have a chance to migrate off and archive and stuff because there are bots that archive messages and maybe a good solution is to have a bot that is accessible in the discord that anyone can ping to get like a log file of all conversations for a channel for instance

i know bots like that should be able to be created and that's more of a long-term thing yeah my my two concerns are a lot of these conversations are really important and i would hate for them to just disappear because someone rage quits and deletes them historically and that the discord although it anyone could join it as discords get more and more people joining they get more and more selective about who can who who joining and being able to join so i have concerns about how public the discussion would be and how easy it is to share with people outside of the people in the channel okay um those are all valid concerns to be honest uh if this is paramount then then discord

is not the best option to be honest if this concerns a paramount and then i would seriously consider matrix for this like i know for a fact that parity technologies is on matrix i think way can tell us of this experience yeah yes matrix is pretty great decentralized and uh and stuff but yeah talking about the scout i was actually one to uh raise a concern so uh also about the the the the archiving archiving issue so yes i know there are actually both and uh and programs that you can

use to archive the whole discord conversation but my concern is that might be against these cars tournament services they might not allow like who archiving of a service conversation because they somehow consider it to be private or something so that's my concern but for for the matrix the the user experience has improved significantly until recently and they have a really great uh chat app called uh element privilege is previously called

voight uh so yeah so it's a solubility decentralized that anyone can set up a server and communicate with any other server uh stuff like that yeah the the biggest thing in my opinion is the network effect and getting people to move on to something and just looking through the list on the eth r d discord it has every major client besides nethermind and nethermine's actually in there via a bridge to telegram um so we could ask them about moving over some at least one of their people there as well um i i i would i would be okay if the discussion's happening on discord if it was mirrored somewhere that then

is public and and and um non erasable yeah i can see i can see options for that let me think about that and explore options for either bots if it follows the terms of service or a bridge that mirrors to a channel that's never deleted or things like that that's possible and we also i also need to talk to the admins of the etherndy discord to see if this is possible in and of itself to move 1.0 chat there because i know right now it's housing 2.0 chat and 1x research chat uh so we don't need to if they think we should do a whole new discord for 1.0 that would then we'd have to explore

that option so i'll get all that together and come next time in two weeks with um some possibilities without anything finalized yet and with that i think we're out of time oh what was that tim i was just gonna say real quick you mentioned the whole network effect thing i think there'd be a lot of value of keeping a single channel if we migrate and like over time we can maybe split it once the migration happens but yeah having just like all core devs on discord or matrix or whatever uh is probably like the best way to go just so it's like you migrate to one channel from from getter okay yeah that sounds good maybe start small is what you're saying okay all right sounds good um we'll see

everybody on august 21st at 1400 utc in two weeks uh thanks everyone for coming have a good rest of your day all right thank you everyone you guys [Music] so [Music] [Music]

[Music] so [Music] [Music] [Music] you