All Core Devs - Execution #78

Transcript

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

[Music] that's interesting can you guys hear me yeah we can hear you now awesome look that is true all right it looks like we are live uh thanks everyone for showing up uh today is the core dev meeting number 78 on january 10th the first um topic of discussion was the eip 2387 mere glacier updates uh just talking about how it went and i think the cat herders are doing a

review of it if i'm not mistaken and we'll have puja talk about that a little bit if um if that's happening but uh first i guess let's throw it to whoever added that so that would be okay i guess tim added that but does anyone want to speak on it yeah but i can talk about it great so we blocked 9 million 200 000 for those falling over home we had muir glacier activated and it actually went off that while there was quite a bit of drama before in the community about it technologically speaking it went off really well and three of the

four clients were perfect and nethermine had a quick update that happened afterwards without any negative effect and that fork included the eip for pushing back ice age which now block times have reduced to fastest they have been since then it took about a day for the block times to reduce operating as normal just great dance all right and then any of the cat herders want to discuss it what what we're doing about a like a post-mortem

or have we done a post-mortem for istanbul i thought someone said we were doing one but i haven't kept up as much as i should i'm not aware of the uh like postmortem of istanbul but uh yes uh certainly come across a uh discussion i'm not sure was that you james like working on it and um yeah we are willing to help you on that oh great yeah i am i am working on a post on a post photo for glacier and so i can that's it yeah and we should also do one for istanbul i have some

kind of initial um suggestions for takeaways but uh it's not really a finished state yet so we i can speak them about that or later and we get back with um some of new glacier variant did really good like it was uh the percentage of uh readiness was more than the istanbul so it was over 92 at the time of the four and currently it is like 99.5 percent so yes we did really great with the muir glacier to sum up all right awesome any other people have comments on that yes we probably would like in the future

to move robson and block forward in case we realize that will be happening after mainland yeah that's a good call and so what you're saying is it should be like earlier in general yeah always the testing before the maintenance i thought that was what we tried well no we actually didn't really care for this one because it didn't affect the test net that much but we probably should do that in the future at the same time that it's actually going to be hitting next monday about a week and a half late yeah the target was to try to be around the same we thought we

rather than oh uh give our obstacles to update their notes the same amount of time and then the and then the time happened it all went back on the expectation was like it would happen under the window of 48 hours for both maintenance and uh the test net but somehow robsten got delayed and like yes it is coming up like around monday okay well that's good to know um the next thing is testing updates um let's see do we have demetrion no does anyone else

have testing updates okay next we can go to the eligibility for inclusion eip review uh the first one is going to be 2456 um and that's one that dano added to the discussion um so yeah go right right ahead dana so this is a proposal to try and move um the fork instead of picking a specific block to try and get some methods where we can go on a time and getting a time-based fork is a tricky issue um there's plenty of ways to introduce new attack vectors and ways to

um basically make things more complicated than they would ordinarily just by saying well for you know next wednesday at noon um so my motivation for this is these past two fork blocks because of those of the robson and main networks that were proof of work forks um they were all off by at least three days and as i mentioned earlier in the call robsten at its current rate is going to fork probably next early next monday morning which is about a week after our intended fork time and there were times where it was forecast at the block rate of the current to four uh two weeks afterwards and that's just that level of unpredictability is just incredibly bad for our downstream

partners who have to maintain nodes and run exchanges so the uh the first proposal i put together you know i'm open to other proposals i just want to get some sort of a mechanism that is predictable into a much smaller window so one of the problems with the um with forking on on a date is we have to deal with honors um and there's also the issue of reorg's reorg i think is is initially the most obvious issue although owners is also a very subtle issue um if we work on a specific time what if there's a reorg that includes that block number that also gives the um miners some opportunity to play games with the numbers to try and force forward to the

fork although geth parody basically that i know of only accept blocks 15 seconds in the future i don't know about trinity left and um nether mind i don't know what their rules are but even then you know you can have like you know all sorts of deep all sorts of difficulty if you're trying to fork in a specific block that's not round it could be random so the first thing that i proposed is that the transitions only the network upgrades only transition at block numbers that are round by a thousand um and the second thing is i propose a two-phase commit that we do the transition at the second opportunity where the block number that is around thousand is after the fork time so that gives us a window that gives us

a trigger event about a thousand to almost two thousand blocks in the past to say hey we're going to be upgrading at this block about you know on average 1500 blocks in the future um and there's you know some calculations that i did in there to say that this would happen anywhere between two and twenty years after the fourth time which is a lot from two to twenty hours from the initial time proposed which is a lot narrower a window a lot more manageable in theory you could have somebody working full time during that that window rather than putting someone on all the time for 20 hours um on ethereum magicians um peter was concerned about the armors the if there was any additional rules that might change the header validation how they a malicious miner might be able

to literally armors with transition eligible blocks um luckily it looks like the two-phase commit on round numbers is going to limit that window to about three bucks before the second transition that they could fill it up and even then there's you know there's there's finance there's uh economic limitations on how effective that can be there's only so many over blocks you can include to get credit for and that's no different from just going crazy in a particular block and doing a very hairy transition at that point yes peter yeah i just wanted to ask that uh say that my my concerns aren't necessarily malicious minors doing weird things rather it's just uh just the complexity of consensus rules

that in theory so i'm not sure how the rules are currently laid out but in theory it could happen that uh along so you or one of the blocks already fork i mean already go into the next fork but the uncle block remains in the previous one or a weird scenario where the uncle is already forked but the block itself is not yet forked so since the timestamps aren't really the uncle and the block timestamps as far as i know aren't tied together you can have these really weird scenarios and i think that mostly the problem is or the complexities that we should really pay attention to and define how uncle timestamps versus block timestamps behave so that

we don't accidentally get into a situation where one client rejects us something and the other client doesn't so that's mostly my concern yeah um bugs are actually more difficult to untangle than a malicious attack because it's pretty usually obvious what they're doing there same uh issue with this as peter brought up i think and i wrote it in fellowship and i have since edited it because i realized that it was based on a misconception so if i understand it correctly now your proposal still activates on

block numbers so an armor would never ever activate before the the block i mean if it activates a block n or the ohmers will be older than n and none of them will be activated and the whole time stamp is just opens up the window saying from in between thousand bucks from now on to 2000 blocks the fourth block will happen right so correct so i think it's elegant that way if we have this we could we can like go ahead

go ahead martin you made this microphone i think martin's microphone's down can you hear me now yes oh okay yeah so i was saying after the fact once once the fork has happened we don't even have to we can pretend that we never had the timestamp real there at all we can just set the fork number was blah and hardcoded there right we can because we've never had a thousand block rewind um so that's that was something that went back and forth on the decision whether after the fact we go back and make never canonical or whether we stick with the date

defining the number that would sound too strong but honestly is there a reason why to why we would remove the date in that case yeah because um it's easier right now it's it's easier to when we do syncing we can do checks for specific blocks if if the peer has them or not and if you know if we want to sing to after that block and check that it's on the right side of the fork and stuff so i'm remembering the reason why i went back to having the date to be the permanent number and that has to do with the 2124 interactions since we don't know the future block we

would be advertising a future time and unless we then update our record at the block when we think it happens um you know if we if we stick with that number meaning when the the block the fork block is um we don't have to change our our hash nearly as often um otherwise there's a small window where you might have a difficult time peering based on that identifier and i did mention in the block that clients might want to include both the fork number and the fork time and so like during a fast sync you could use the uh the block number as an aid to make sure that you're doing it correctly but in all the synchronization methods right now um

everyone's getting all the headers anyway so you'll have time to validate and since you're only checking every thousandth header it shouldn't be too much of a validation burden on fastings but you do have a point that if we type forking to timestamps then the fork id gets messed up because the fork id is designed to operate on blocks only so that needs to be redesigned yeah i think we could just put in the unix seconds past epoch because until we hit block number 100 billion or something i think we'll be fine or maybe it's just 1 billion yeah i mean probably it's not too hard

to fix but it's it's something that needs to be addressed any other comments um just a question of why is that why is ethereum uh it is so irregular or is the uh as if i look on ether scan the average rock climbs end up increasing i've been off so long and what is sort of relying that office and this would also be a getting a more consistent block time you know and solve so what's hitting us what's hitting us on roxton is hash rate

is much more highly variable than it is on mainnet there's no economic incentive to keep all your hashes pointing to make money um is the experience with istanbul somebody pointed a lot of hashtag early because i guess they were testing a new rack or something and and they like you know doubled or 10x the hash rate so that brought brought it forward three days sooner than we thought it was going to happen we wanted it on a wednesday and it still happened on a weekend for mainnet what hit us with um istanbul was we were not sure what the impact of the ice age was going to be we didn't know if it was going to be a half a second impact two second impact 10 second impact um i think our estimates for getting um mere glacier on the sixth was based on a 22nd block time

and it wound up being 17 which pulled it into the day after new year's um so it's it's the things that we can't predict is why getting a date you know there's an si definition for a second and we're going to follow that but there's no inside definition for um how fast you can hash and that's the unpredictable part there so for robston this would be that the unpredictable hash rate will be a problem moving forward and then for mainnet and previously has has it been that far off when things are acting normally like assuming the ice age gets fixed because that's i'm working on that after i get this close board i'm done

i have to look at those dates that would be worth putting in the eip i think in general uh previously we managed to hit the fork more or less accurately but for example i think petersburg hit at uh somewhere around midnight utc so again i'm not sure whether that was intended or not i i assume it wasn't really intended so for example what a time-based uh fork would also allow is to essentially it would allow you to delimit the fork within two hours so you could say that this fork is going to happen between

6 pm and 8 pm utc and then everybody knows specifically that you have to be online at that point in time otherwise if you schedule a fork one month or two months in advance even if you're pretty accurate you can't really be our accurate so yeah you can most probably get it get the correct date or maybe give or take one days but definitely not give or take one hours and i think one thing that's nice about this proposal is the fact that there's like this thousand to two thousand block delay which is like i don't know a couple hours so you can imagine a case where like you do set up alerts for that time and then it gives

you like a thousand block warning to you know monitor the fork um so that and and also just like within the community you know it gives an opportunity the message of like hey this thing is happening in a couple hours um the only potential drawback i see is whether or not having this window would mean that like exchanges and whatnot would pause deposits and withdrawals for a longer period that they do now um so right now i think they only do it for a couple hours but if if this is like a thousand blocks i'm not sure if that's longer or shorter but on that probably it's probably good to give this like two-step warning that the upgrade is happening

no i'm not sure so if um if your node is the one warning you that there's an update coming in half an hour i'm not sure you have time to react meaningfully so if you haven't showed you in advance sure yeah you need to schedule in advance and i doubt the node would would uh would like inform you of that but like a thousand times 15 seconds it's still a couple hours right so there's a chart in the eip for 13 second block times it could happen as soon as three and a half hours later 7 15 and after um and you know there's about a four hour window for 15 second blocks if we're if the ice age has gone bad we have 30 second blocks there's like an eight hour window with

an eight hour warning and the thing is you'll have you'll pretty much know once the transition triggers um you'll have eight hour notice basically when it's gonna happen within an hour i would say or a three-hour notice different second blocks so you'll be able to nail it down pretty tightly as to when it's gonna fork i'm liking how this is progressing for sure i think a time-based fork would be

better if we can pull it off uh anybody else have comments martin your mike's being a little crackly i didn't know if um oh okay perfect um okay we can go to the next part of the agenda that's going to be eip 1962 eligible for inclusion or at the elevate the eligibility for inclusion of eip1962 and that's going to be um alex and i think louise is here for that too right no i just happened to to come here to this into the

going on around oh perfect okay uh alex you can take it away yeah so as i written briefly um at github sure right now both c plus plus implementation and rust implication are both complete both feature wise and from testing perspective their performance is also within some plus minus 10 percent deviation so i use the rust as a kind of metering source for all the gas estimates um so in principle right now what's left is basically how i should integrate it into a few existing clients i'm only

familiar with priority and gas um and there are a few options whether to use kind of a single implementation or use two independent implementations into independent clients for example and with all of this because well for priorities the ras library is easy to include and compile uh for gas it's not that easy to compile c plus plus source um and or the rust library in any form so so like it would require some uh kind of addition synthesis existing uh continuous integration

pipelines so all those advices would be welcome or common sense inspired also to simplify alternative implementations because i know that there is one happening right now in go which is still non-complete as far as i know maybe it would be possible kind of uh to put a performance margin like uh use the current numbers for gas between which are acceptable for rust and c-class plus and just say well alternative implementation in gold for example would not be more than for example twice slower

than those two existing ones and so i can incorporate all those changes uh yeah just from the go ethereum team's perspective so for us the c plus bus approach is definitely doable so we can easily integrate c plus class or c code into indigo uh however we cannot integrate rust code so the only thing we could do with rust is to have a sub completely separate rust combination step that builds a shared library or static library and then somehow link that to togeth but that completely and utterly blows up the entire build process and then

instead of using go as a build tool we would need to have make files and custom steps and that's definitely not something we want to do so technically it is doable but practically it just nukes the entire project's simplicity we definitely would like this yeah so the c plus plus implementation is written in a quite modern dialect of c plus plus uh and well not even the library itself uh it also relies on the dependency which does all the arithmetics so the arithmetics implementation is not done by by me in c plus plus code

i've taken the existing ones existing one but it still gives me the same results as in the rust where i have re i have written all by myself and those two require c plus plus 17. i don't know what uh containers you use in your building pipeline and just depending on what uh what linux edition and distributive you use you may have or may not have a modern enough compiler this is my only concern for c plus plus side otherwise if you say that you can easily build a plus where i had some problems

as far as i tried the last time um then sure it's it's as good for me as any other version so see compiler version wise essentially go is just calling gcc so as long as you have a fraction of gcc installed it shouldn't matter what kind of c plus plus features it uses if you had some other comp issues then maybe maybe just mention them somewhere and then we can take a look uh no it's just it just requires a c plus plus 17 standard just basically a few features which were even supported in the previous versions but

officially only c plus plus 17. otherwise it's standard yeah so okay it might not be trivial but thinking against rust would be really nasty martin are you trying to say something yes sorry for making noise uh so what i i read on your comment here that um it moved to move to ten separate operations that's my map to pre-compile addresses and i looked at the eep and i've seen no such changes in the eep so i'm kind of wondering where

this uh where these changes are taking place and where we can follow the progress uh um well there is a kind of reference rust uh well reference github with all the rust code and also a few documents which describes a binary interface and operations uh which are now 10 separate of them i just didn't make the the uh can i did just make another pull request to the eip to update it to the current state but i still maintains uh the list and uh kind of also description of binary interfaces now with

uh 10 separate uh kind of operations uh i mean uh i don't know i'll ask for this few times so i just implemented this change yeah but it would be good if you could post somewhere what is the like canonical source of truth and progress for 1962 because it's to me it feels kind of spread out okay i will make a post to uh magicians uh you know corresponding thread yeah so well basically there are kind of two

implementation wise and integration wise questions like what uh biggest most likable user integration into priority myself is to have um what pre-compile address range i should use for which will be should be 10 addresses and basically uh just what is the number for this kind of performance margin for alternative implementations if there will be some in the future anybody else have comments did i hear

you say that you had made a pull request and you were waiting on that to go through or you were waiting for you that you wanted me all right or the eip like updating an eip oh sorry i i think i just didn't get get your question can you repeat once again uh for the for the actual eip in the repository or did you say you made a pull request and we're waiting for it to be merged or that you are waiting oh uh well i mean i have the draft for the parity client which can be like which is completely dropped but

basically it integrates uh collins or rust implementation and gas metering routines from the priority client but to integrate it completely i would also need to change few config files i think which will require me to have to knows addresses for all these 10 pre-compile functions which people wanted me to make which should be mapped to 10 independent recompile addresses and just to finish this integration i would need to know those addresses yeah is that something that we have a process for deciding

just everybody on the call like which when we assign pre-compiles which ones do we just decide and call typically that's what's been done um and they've always been packed tightly so there's been no open spaces that's something we might want to reconsider or not so yeah just we'll have to think of the pros and cons um for the moment we can just continue to go with that though if we want to just give alex an answer uh how soon do you need that answer alex or does it really matter uh well uh i mean if someone would want

to integrate it into parity uh for example himself uh i think i'll say go when people will need to integrate it they will need to know this information i can just leave placeholders for now just not that important i think uh so the second question is uh kind of performance margin uh for future if alternative implementations uh arise with a literally different performance so right now the difference between c plus plus and graphs is ten percent within and kind of plus and minus in different parts just more like a deviation uh so but for the future if let's say there will be some other implementation notes that performance

but still alternative and matches to existing ones completely and someone would want to use this implementation for example in gas then we can just kind of give [Music] the performance margin so i will just blindly multiply all the gas prices by two the problem with them it's not just the gas prices generally but um so if the if the margin is 10 then nobody really cares but once you start entering into 2x 3x territory the problem is that those start to uh look like denial of service opportunities so for example either you would double the gas price in which case uh

the implementations i mean in which case people would be just charged more and blocks won't be as useful or if you keep the gas price at some meaningful levels then a slower implementation could just be too slow for the network so yeah ux is probably something that is still okay and doable but above that your start you will start to get problems uh yeah for this i would need an advice uh i can do the i can just do the comparison with the current bn curve uh right now for most of the operations it's uh it's cheaper i just didn't try with the

pairing operation uh so but even for example 1.5 efficient uh is still a good margin anyway and just as a security feature too even if later some required modifications or extensions will require what like will decrease the speed of one of the existing implementations uh but it still should be first of all faster than the existing brick compiled for bn curve with the current pricing after the first istanbul uh fork and um second it will give access to wide set of secures which are not accessible right now which is still beneficial that's it i

mean it's beneficial from both sides so it will not make free compile completely useless but zeke efficient whether it's 1.5 for example or two i also wouldn't want to go above 2 would be kind of a way to allow people to make alternative ones in other languages which will kind of not give this exact performance i can also put a placeholder like 1.5 and this still most likely would be fine we can decide on the exact number later on yeah so generally the way we decide on these um

these gas prices is just if if we have multiple implementations just try to run benchmarks on multiple different machines with different implementations gather all the numbers and then just try to compare it to the existing op codes and then just boom give a number and maybe multiply it by a bit just to be on a safe side so i think in in general if we have some benchmarks or we have some code that we can benchmark then we can fairly quickly dream some numbers up i think martin also had some benchmarks suite that spits out all kinds of nice threats yeah but the whole doing that requires us to be fairly certain that we know

the worst cases which is not trivial yes uh well this was kind of this was uh largely part of my work for because i also did a gas schedule i mean i have all the formulas for gas scheduling dependence input parameters and to measure those i kind of for parameters which are in a narrow limit i can i use it worst case scenarios like for example if you multiply the elliptic curve point by a number which is in certain range uh of the bit widths uh worst case is just having all the ones

like all the bits set so you have the maximum number of additions and multiplications basically doublings uh all those were used in a gas estimate so those numbers are worst case right now i can just give a margin on top of this right but then you kind of went into this other problem because now you have gas scheduling which alters the model of the worst cases um i mean yeah then you get new worst cases based on the gas schedules um

i mean what what what do you call new worst cases based on gas modeling uh not worst cases as in the ones taking the most time but the worst cases doesn't take the most time per gas um well i mean um okay uh like there is a set of parameters for every for every operation which is happening right now for example addition of two elliptic curve points is basically a lookup table it only depends on what is your field site and for this basically i just gives a

lookup table uh because those numbers do not depend um on anything else but the number of um by kind of the widths bit widths of the modulus for multiplication there is uh with bits of the scalar but by which you multiply and those cells are are kind of split into uh windows each all categories which each of those is 64 bit uh wide and in each of the categories i use the worst case to give the gasket on so from this part it's kind of this well it's it's the safest way uh because i should not introduce the knife series

it's maybe not the most optimal way but i mean right now it's already safe if the c plus plus or right implementation is used so it's only matter whether we should put kind of additional safety on top of this which will kind of relax the restrictions or alternative implementations in terms of speed yeah okay but just to give some context then so previously what we've done kind of is compare the relative gas per second or second for gas against for example easy recovery

oh uh well i mean i used kind of as far as i understood the standard measure of 15 million gas per second in my gas scheduling yeah when you do that you become heavily tied to the actual processor and machine hardware you're using so what you can do is you can on that machine you calculate so where is easy recover and perhaps a couple of the other pre-compiles and then you reference against those so you get a similar gas per second as for example eastern recovery uh well i'm yeah so right now the this uh this number

which is 15 million gas per second or just 15 gas per a microsecond is a global constant which i can change um and if this is a standard measure across all the machines for in which you use the benchmarks i will just and if you can point me to some benchmark will which will allow me to check what is this number on my machine i can just adjust it so it will be directly apple's tables yeah uh so is there an existing page like is there existing code to do something like this or should i just write one myself yeah i can send you the

example repo the wrapper containing the examples and the benchmarks that i've done previously for other pre-compilers uh okay yeah i will yeah then i will just measure this constant and make adjustments okay are there any other comments or questions okay that's great progress alex thanks for the update the next efi eip is eip 2348 validated evm contracts um so that's gonna be dano yeah that's something to be shorter

i just want to point out that i um in the ethereum magicians forum i just i gave responses to two of the concerns the first one was about validating in transactions and my principal argument was that the contract can't be too long because of the gas limits it's either gonna be two and a half if it's nothing but zeros two and a half megabytes or something between half and a full megabyte if it is uh not full of zeros so i put some numbers in there i don't know if those will address martin and peter's concern about the attack so this is a request for comment in that thread and also the second concern was about why headers

and why not some other mechanism to identify contracts that are subject to the validation rules um the strongest argument actually came from some of the work that um wade's been doing on his on gas where he's proposing to change the call delegate call to take six instead of seven or five instead of six arguments off the stack and if you were to put that evm into an unvalidated evm things would break unexpectedly whereas if you had the version header they would break quicker and more predictably so i'm not ready to have it voted next week so it's at least a month away so i just wanted to take the time to uh solicit responses in the ethereum magician's thread okay thanks anybody have a question or

comment okay next we have the um i was trying to find my new button yeah i'm down i i'm of course generally in favor of something like this i've had time to look over the thread but not to really study this and the related proposals so over the next month we should try and find some time to go over it i think i'll be more anybody else two weeks i just barely got the responses on there yesterday and i think people should have a week to be able to respond

to it before we discuss it on the call so that's why i'm not prepared today call anybody else okay the eipip ethereum improvement proposal improvement proposal meeting also known as the eip improvement processes meeting is going to start happening next week um i need to still schedule the day i don't know what day is best i'm going to guess wednesday that feels right and that's going to be organized over telegram but i might do a chat bridge together if that'll help some people reach out to me preferably on telegram or

at hudson ethereum dot org if you want to be included in those meetings the purpose of those meetings is to look over and streamline some of the eip processes and also create guidelines and actionable ways to attract eip editors so that we can have a cleaner eip process in the future we don't have like a timeline for this it's still pretty early it's just going to be some discussions and then we'll start structuring it a little bit better and i think that's it for that item unless there's any questions all right review the previous decisions

made in action items from call 77. um the first three or the first two are about mere glacier ech released the blog post on mere glacier they did that hudson to connect the clients to get the latest versions of mere glacier ech and i did that action item 77.3 create an eip ip telegram channel yes i did that and again you can email me at hudson ethereum.org or chat with me on telegram to get added to that action item 77.4 is for someone to contact eric and add the block rewards are unchanged line to the eip i don't know if that ever happened

i did that okay great then that clears up all the action items um and i think that's the last thing does anyone else have anything they want to add uh to the meeting the rest um i do um i just so i just want to bring to your attention um there was um there there's we had a discussion uh between starkware and geff about uh the maximum transaction size of um in the bampoo to get accepted into example uh we this has been uh even in being resolved uh with the f team they

they had a limitation there and i just want to bring it to the attention of the other client that uh this limitation or other limitation could be a problematic for many uh layer two solution um can you hear me yeah we could hear you and you said this was the size of the mempool and clients like by default i mean they can let martine in uh we this is getting solved on their own on this we are already at a diary discussion for a few months uh and this is getting sold i just want to bring it to the rest of the attention that this sort of limitation could be a problem for l2 solution

in the future so essentially up until today actually geth was refusing to forward or propagate transactions that are larger than i think 32 kilobytes that 32 kilobyte was more or less picked because the contract deployment limit is 24 kilobytes and then 32 seems like a nice limit and of course if you if you want to create a transaction which has a ton of data but doesn't really deploy anything then it could happen that you want to might want to create a larger transaction and then stockwear made r that actually extended guests transaction pool so that

we can accept larger transactions it's mostly the work was because because we wanted to make sure that no denial of service can occur due to transactions but i guess the important memo here is that geth probably from the next release guest will also allow propagating larger transactions so people might be able to use transactions that are not only limited at 32 kilobytes but actually at 128. while we're on the subject uh peter do you want to mention anything about the proposal for fetching transactions yes actually i wanted to do that

just figured i'd wait until the end but i guess now is as good as the time as any uh so currently the theorems the way nodes propagate transactions in the network is horrible actually geth relays every single transactions to every single peer it has in theory it would be enough to relate to a logarithmic number of peers the problem is that if you have some weird connection then it can happen that you miss out some transactions and the theorem protocol currently does not i mean ethereum networking protocol currently does not have a means to request transactions if you missed something you cannot ask your peers for it you just have to

wait until they deliver it and um essentially we already have a pr that would again bump the ethereum protocol to e65 and we propose adding two message types um essentially similarly to how for block propagation we have a message to propagate a block and we also have a message to just announce a block and request a block the same way we would extend it for transactions so that beside the current message that just propagates the transaction we would also support uh announcing a transaction essentially just the hash or at least that's the plan currently and then the remote side could request it if it doesn't have it yet and we're kind of hopeful that this will

help drastically reduce the network bandwidth that the entire ethereum network consumes because then i'm sorry sorry sorry yeah so essentially that would be the plan and uh we'll probably write up an eip maybe for next uh next awkward of course so it would be kind of a small uh small addition to the network just to add this support announcing a transaction and request it if you don't have it yet because go ahead yeah sorry when uh when we connect networks when we connect nodes to each other i think in the moment get is sending uh all the transactions it knows about on

connection is it possible to change it so it only sends hashes uh yeah exactly that would be the other thing so if we if we support announcing transactions then on connection it's it's enough to announce them you don't have to actually propagate them yeah that would be perfect i think this is 80 or 90 of the traffic at the moment yeah it seems to me very similar to what bitcoin is doing uh with i don't remember if it's either fiber or compact uh blocks uh there could be something to be taken directly from them well this is really kind of trivial so it's just the same so currently the ethereum protocol you can request blocks by hash you can request receipts you can request everything by hash except

transactions so it will be extending that and the same way that you can announce uh blocks it would so i i don't i mean that would if you have a link to somebody else's work we can definitely take a look but this is really something super trivial what you're referring to is is doing the same thing for the actual blocks so you can you propagate blocks and you only include the hashes of transactions but not actually the transactions and that yes it is not the same it is kind of a follow-up thing that we could do but right now that's not what we're going to propose

yeah so that so that's definitely also something that we've been thinking about but um in reality we wanted to so sorting the transaction propagation problem out is fairly trivial so just a tiny addition we can get a new protocol version released and see that it actually works and then we can look look at the whole block propagation whether that's an issue or not generally since we're only propagating blocks to logarithmic number of peers it's not really an issue in my opinion i mean we can definitely make it more optimal but it's not um it it doesn't really cause issues at the moment whereas transaction propagation is something that

is annoying um on that specific i completely agree about the block propagation itself i mean um if we could reduce also the propagation then uh time which is roughly today 200 milliseconds if i'm correct uh it would be something that would be compared to the mining time of of an ethereum block it's somewhat still significant i mean not not as of now of course i'm just like in the future that could be a nice improvement yeah of course no i completely agree just i i don't really see the reason to try to do both things at the same time so i definitely think that we probably should experiment with that and

should do it eventually just take it one step at a time another agree thanks i remember i remember piper's team was working on an eip sort of around the same thing have you guys connected with them about so i that we discussed this with them back in devcon so i think they're in agreement we haven't talked recently about it i'll just i'll think him about it we've talked about it as far as ethel next up has come up or things that they

that they need from their client i'm not on their team so i don't i don't wanna i don't know i don't want to misrepresent what they're talking about but i just remembered that conversation okay is there any other um things anyone wants to say announcements or miss topics i have an observation and this this isn't anything to do with this doesn't say anything about your eid or your process alex but i think is a comment on on the process in general and possibly one also focused on improving which is

if i think back to blake 2b and i think back to 1559 i think back to others that's a single source of truth we're keeping up to date and where that is uh it needs to be a difficult thing to keep track of i just want to say that out loud as an observation yeah um i just don't know if um i can just make another pull request to update the text of the existing uh eip uh in the corresponding repository uh i just don't know what was the previous standard process i can post it in both places or just continue updating it's uh uh

it's like eip github which is like whatever we decide now i will just do this way yeah i would say the eip github uh in combination with the ethereum magicians thread if you have one already um that should cover it in my opinion and that's kind of what we're leaning toward or were i feel like we're heading that direction standards wise it was kind of vague before um what do you think uh james but i'm i'm just i'm noticing that there is a and this is more of a processing unless it's not on your actual fpl and you're doing great on that but the um there seems to be a lot of tension

between keeping those things in line whether we keep the amount of effort required to keep going is it worth it or try it in a way that has less diversions happening or tension in the process yeah that would be nice to have and that could be part of the eipip process um peter can you post a link to your pr and the um awkward devs getter uh it's gary's pr uh well i mean i can definitely post a link i'm not sure how useful it will be to you guys but sure oh trent was just asking for it oh yes of course

but yeah never mind i'll just post it but it's not a pr to the eip oh yeah i see what you're saying we just have a code it's a the goku yeah the yeah what was that trend you cut out sorry uh a link to the eip would be perfect but you don't have any idea oh sorry about this what you said no no what i was saying is that we just have a pull request with the goku itself but we'll try to get an erp up for next quarter i have a general question about networking issues um are they at this point standardized or discussed as part of the if you like

the the protocol itself or not what was the question my question is my question is um like those networking um this like uh messages and and standard are they discussed today as part of the protocol itself uh i feel like i minus my impression from the outside that they are designed decided addock by the by each client am i am i correct or wrong i don't think that's correct so the the whole the networking protocol was pretty much standardized even before frontier and then we used the usual eip process to make changes to it

so the only thing is that's not standardized is for example lds is since it's only supported by geth it was kind of never modified through the all chord of course because nobody else had it so there was not really a point to to have to introduce all that bureaucracy here but with regard to the eth protocol or the deaf pewter peer or discovery all of them were pretty much made here against once something that was not uh not designed through the overlapped work at all code of course was the discovery v5 plus the nr stuff but that again usually was because nobody else cared about them so people just assumed that whatever

the deaf people authors come up with is fine but again discovery v5 was something that's completely independent and completely new and after the whole initial specs were done even before implant we started implementing it i think nethermind already jumped on it so we had a few other teams collaborating so it wasn't really collaborated through the awkward of course but it was a collaborative thing there are multiple things on networking that would um that would actually benefit from being standardized there is one one particular example that you can give from another mind when we uh uh when we're sending requests for the nodes in the fastsync mode um the requests are handled both by

parity and gif and the way we are optimizing it we create the request patches first and then we decide whether to send it to parity or get and the limits for the sizes of the requests uh in parity are at around 1024 and you get and they are i think get handles 192 at most and requests up to 256 and the thing is if if parity doesn't want to respond to a big request it actually just sends you as much as it wants to send you back and you can handle the part and then re-request the rest but kent actually disconnects you as a punishment for requesting too much which means that we cannot ever use the fact that parity can give us more data

because if we send it without knowing exactly which note we'll be assigning it to then we might be disconnected by all the guest nodes so these are all these like um small things that are not really specified and if 63 like there is there is no definition that we should get disconnected there are some specific behaviors unlike uh when the null headers are sent by get for example which was um not following the protocol and not specified anywhere and they're above the backs reported in the past in parity and in nethermine when the special condition was found so any any further specification like very detailed specification of those network protocols improve it for the future i think for us historically this was like the

one additional thing would be great actually to introduce some more meaningful messages on this connection like so we can all between the notes and each other the information why we are disconnecting uh now like the debugging the opportunity situations when the other nodes are disconnecting it's really hard so you very often have to run two debuggers at once like gets or party code and at the same time the other mice to check what exactly was a series of events that led to the node being disconnected as a like for some for whatever reason either it was sending too many messages or something was small formative uh that is extremely time consuming so the any any more detailed specification

would be great work from all of us to uh to improve it also for any new uh note being notes being built by any new teams uh just to react to one of them so you mentioned that get disconnected you request more data than some limit and that seems so that's definitely not something we want to do so we simply if you request too much data then we stop i mean we we have limits and for example if you request 000 state entries then you will get 370 something back and that's it and you can request that i mean obviously if when i'm reading get code then i'm more likely to make mistakes when analyzing it

no no what that actually uh takes the limit and if if the request is over the limit it disconnects the request and that's what you see also happening in the in the actual behavior i'm talking about nodes not data not about blocks or headers yeah but that should you probably want to open an issue because that's definitely not the behavior we intend so we don't we never intend to disconnect just because we requested more data so it should be a clear protocol violation so we only disconnect if you send something that's definitely junk that cannot be interpreted so if we if we do disconnect in some other case then that's a bug and you should probably open an issue

okay yeah i mean because the code looks like really that was intended so maybe maybe you should treat it as a bag and raise an issue but also like specifying it in the future like what should be the behavior uh like with the requests are in different formats then that will be helpful yeah i guess the here the thing with the festival fasting and 863 is that when we implemented this whole protocol essentially geth was the single client which had this thing so there was a uh the e63 was kind of just packed as hey kind of these are the messages but there was nothing on cpp3 implemented this was before frontier i think i think this is like a common pattern when you when we when we hear

what we are saying here that like uh fasting was the get only less the client like client was to get on in discovery five as they get guess only i think the reason they are remaining for so long uh he's on guess only it's because because the spec would have to be like more detailed and it's it's very natural are we doing the same whenever we're doing something that only we do at the moment um then obviously this pack is less detailed so we should try to resurface all those changes and inspect it as soon as possible and involve more um more of the core devs to to be aware of any experimentations on the client so we may

kind of build some better communication here and it will help yeah i completely agree and that's pretty much the reason why uh why instead of why we came with this whole fork idea and we wanted to spec it out as an eip and when that's specifically the reason why we brought it up today to that hey we have this whole transaction propagation issue and let's back it out properly yeah it definitely helps definitely helps so it's already a step towards the right direction and can only improve here more and more um can i just jump on this on this discussion uh further uh i feel like the core dev also didn't discuss uh like this puts more time on the on the attack the network

faced just before new year's eve which sounds a bit like what we've been discussing on networking issues and the way we handle blocks was there an attack yeah on parity oh yeah actually it actually affected buffner to mind the party and uh it's almost like there is a second form of like maybe 20 people discussing the about the rd open ethereum and i was there as well and we discussed their fights already and because it didn't affect death we were not raising it here um so the the general thing was that uh there was the incorrect block being sent and then a party was adding into the cache of the

incorrect blocks as the hash of the block of the header but because the body of the block was modified but the hash was all fine so the block was validated then it was blowing up the processing and then it was added to the hash because the invalid block but there were perfectly valid blocks on the network with the same hash so different hashing mechanisms had to be introduced and while the same thing affected never mind the in our case it was slightly different thing so we we missed the validation on some of the incoming new blocks and we've added that and it solves it as well and the priority already has a fix where uh

where that cache actually hashes the raw content of the blog body and stores it separately so it says the block is only discarded immediately is invalid if the hash of the content is exactly the same and not the advertisement but this kind of seems a bit weird that you you retrieve the network and you don't actually match the contents to the header so this seems like yeah so like uh how how it was done on particular actually we indicated when we were saying that guest notes are actually sending that um every now and again guests are propagating the

uh invalid combinations of headers and bodies also like for example i'm receiving a lot of invalid nodes from the get node data from from gif sometimes the hash doesn't match the content so whether these are specifically designed attacking death notes or just some bikes it's hard to say but that seems really weird because uh we don't so we fast sync we do brand benchmarks and we never seen we don't see bad blocks and we never see invalid hashes either so sure so like uh i definitely should do it because at the moment we have code that says like only when you

send to us something like and bad things uh in a second and only then we disconnected but uh literally we have to be very um very very like soft on behavior of other nodes so it might be that we should start like communicate more on those network issues and then raise it more and then or just remove all of those problems so guess our monitoring guest node is still picking up these bad blocks and storing them in the bad block cache so geth like parody flags a particular hash as bad but the difference is that we don't actually use that as a blacklist in the future we do we do maintain it so

if we want to analyze it from the outside we can retrieve the bad blocks but we don't blacklist based on it so therefore later on once we get the correct body content for that header we successfully import it do you do blacklist before propagation because like blacklisting helps to prevent those bad blocks to be propagated oh okay so we we do blacklist them and we never propagate them but the blacklisting works as long as you do it at the right stage so priority was just like this thing a bit too early uh we only blacklist after a full processing um if everything matches yeah sounds correct i mean that sounds like

we should we shouldn't we shouldn't pass on blocks unless we have messed up the body content to the but wait so we don't so if we get a block from the network and the block doesn't match i mean the body doesn't match we just my opinion we just either drop the whole connection or drop that package we i don't think we ever even start to process such a block yeah but the question is do you propagate it before processing well no because we just we should in theory reject it even at the networking level because it's an invalid thing yeah that would be fine and it would be

fine i think i'm pretty sure that the attacker was actually using a modified code to just generate the connections and send the blocks because they were definitely coming from the gas nodes but they might have been modified but peter it does make it into the bad block cache though okay i have to take a look but uh post mortem on this be something another mine would be able to do have something now we can we can try to like uh copy

the data from the telegram channel where we're discussing it with the mind yeah with a priority team um yeah i'll send a few questions a few answers and then like what's more than but like i cannot promise you that it will be very quickly done on the like formal way so like uh if we don't have to rush it now but i think like the next week or two that's fine to me once again that sounds fine to me okay i think unless anyone else has thoughts yeah that sounds good um

anybody else have anything uh should we have the meeting in two weeks from now we've we realize now that we're on the same weekly schedule as the eth 2.0 calls but i think someone mentioned there's not a ton of overlap and also we've stayed on schedule and we think they got off schedule so it might be on them to not have it the same week if they don't want it let's just have a meeting in two weeks then if no one has a strong opinion and um i will be gone um in two weeks on a trip so tim will be taking over that meeting

thank you tim who had to leave i think this meeting but tim's gonna be anyways next week so hopefully he'll be back in two weeks then we can figure it out if he's not yeah we'll figure it out um he already told me he should be able to do it so but there's other people i think who can if he can't so that's it thanks everybody see you in two weeks thank you thank you thank you bye bye thanks bye thanks hudson bye [Music] [Music]

[Music] [Music] so [Music] [Music] foreign

[Music] [Applause] [Music] foreign