All Core Devs - Execution #115

Transcript

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

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

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

[Applause] [Music] so

Tim Beiko: hello everyone welcome to awkwardev's 115. um i'll post the agenda in the chat here um oh sorry made the chat go away okay uh cool and we are live everything seems good with the live stream great um so first thing i had on the agenda was just

uh basically to get an update on calaveras um i know marius kind of spammed it earlier this week i don't think he's on the call um but yeah i don't know if another another team had just like an update about uh i i know basu and nethermine uh there were some things found when when married this test uh i don't know if you want to walk through that

um yeah i think we were generating blocks that were too large um and so they were being rejected but we're i think everything is working now we should be fine

Łukasz Rozmej: so from determined side i know there was

there are some issues that we stopped producing blocks from time to time but i'm actually debugging this today and i think i found a solution so i will uh restart calaveras validator after i'm done

Tim Beiko: awesome um and i think those were kind of the two only issues it seemed like they're anyways i didn't find anything else i don't know if anyone had had any other uh yeah any other things to share about calaveras okay um so the next one

uh it's actually quite a a big one is over the past like week or two uh there's been a lot of conversations about json rpc and and 1559 um and basically uh it seems like there's three open questions left uh that i was hoping we could uh kind of resolve on this call um the first one uh and this was martin's so he's he's not here yet uh the first one was eighth call we can maybe skip that one and see if martin comes in um the second one was probably the simplest uh so basically the idea of adding the effective gas price to eat get transaction receipt uh light client you had a pr open for that already it seemed like

everyone was roughly in favor of it but we did just wanted to check here to see um yeah if there was any objections or if people all thought this was a good idea and let me post kind of the pr here um but yeah this would just make it easier for uh projects who are uh dependent on the effective gas price they want to show it to the users and whatnot to fetch it so they wouldn't have to manually calculate it they would just be in the transaction receipt

Lightclient: so i think there was a discussion a while ago either on discord or maybe in some other channel where people were saying hey maybe we just have tx.gas price be set to the effective gas price and so

when you do eat get transaction it would return the effective gas price for for all transactions because the gas the gas price is the effect of grass price today and then for 1559 transactions that would be overloaded to be the effective gas price so i don't know i think that might actually be how geth is currently implementing it and i don't know if people want to continue having that behavior or if if going with this pr also means to revert that and only have gas price for non 1559 transactions i know some of the people in this pr

specifically want to do the latter where the gas price is not in the transaction object and it's only in the receipt and their arguments are that the effective gas price is this computed property and so it doesn't it generally computed properties generally shouldn't live in the transaction return value they should be things that are sent by the receipt rpc but that's just their argument

Tim Beiko: does anyone from the other client teams have thoughts on that or at least like

how it know how it's implemented now in your client

i think that second one sounds more intuitive to me as a consumer of the api since uh setting us the gas price seems to imply that yeah it's you know it's a field that was set in the transaction i kind of like it being separate but that's not a strongly held opinion

yeah necessary thoughts not ready

Łukasz Rozmej: so i don't have any opinion on this

Tim Beiko: okay um and yeah do you know so right now what does transaction.gas price do in base u and nethermine does it also just return the effective gas price like i guess i don't know yeah

i think i think we don't do either yet i don't think we return the effective gas price as the gas price nor do we have the effective gas price in the um receipt yet just waiting on clarity for that

Gary Schulte: yeah we have a pr for that but we're waiting

Tim Beiko: okay and and like client you said geth basically already does this thing where it returns the effective gas price in

the transaction.gas price so we would need to revert that in geth and then move it to the the receipt right i believe that is but if anyone else on the gas team is here they can better speak to it jump in yeah unfortunately i didn't really follow this particular issue so yeah i can't really add anything okay um yeah i seems like the one kind of has a strong opinion on it um yeah like client since you opened it do you have a

preference for and you did a lot of the work on the fpr as well do you have a preference for moving it like um i guess would you be if we if we just like merging your pr are you okay doing the change in geth if if if it needs to happen so that's it sure

Lightclient: okay that's fine i think like my i don't know again i also have a strong preference but i think that the people who wanted it in their receipts brought their arguments and so you know there's no one really opposing it at the point at this moment

Tim Beiko: okay great so yeah let's uh yeah let's i'll merge the prn today and we can use that as a reference so that yeah the effective cash price goes in the receipt

and if any implementation already has it in like the tx.gas price then we can just revert that cool um that's the first one um so uh oh i see martin is just joining so we can probably do the eath call thing um hi martin

hi sorry i'm like

Tim Beiko: oh no worries uh yeah we were just talking about json rpc and um you had posted this uh comment in awkward devs about ethcal um trying to figure out how does it deal with the base fee and the gas price um yeah do you maybe just want to give like a quick

background about that

like uh yeah yeah

Martin Holst Swende: so background about it is that for equal yes and parity back and they used to handle things differently um guess would use whatever the account of the node that you made the column would use that as the like the caller if unless otherwise specified and that was a pretty yeah arbitrary choice um apparently used

the zero address as the sender [Music] and gets switched over to that as well and the problem is that the xero address didn't always have funds and as a solution for that we use the zero gas price so we can do the eighth call you can see what happens um and it works you we can specify any gas limit you want because gas doesn't cost anything and the problem with when we do is call on 1559 is that it has to cost something because there's a base fee and if we use the base 3 we have to charge whatever it basically is so if you use zero address then you we can run into

this problem that there might not be any funds and i am not the best person to speak of how we eventually fixed it but uh it seems like peter is not on the call and he eventually fixed it and merged into gap i think what he did if i understood correctly is that unless you specified gas and he hacked around it a bit so if you do the operation the op code basically you get the correct one but charging wise it will [Music] not charge recording in progress um yeah i i can't detail it further than

that there's a pr which was recently merged

Tim Beiko: i guess do other teams have ethecal implemented yet

so i'm not exactly sure what we do right now um i can get back to you

okay yeah i would also need to check the details okay um and i saw

Tim Beiko: uh i think it was open ethereum left a comment on the issue

saying uh they would like to add the optional base fee uh to the parameter list

um yeah yeah

current currently open ethereum uses the base fee from the block header that is provided in a parameter list when you call the adhd um so there's there is actually no way to set the base feed to zero so uh if i understand correctly the the discussion on the discord we want to for this function h call to

work in two modes one mode is uh to mimic the the what happens in reality when you apply some transaction on a specific block and the second mode is to just analyze the control code i guess while assuming that the base fee is zero and the gas price is zero so just to omit some of the of the data that is not needed for that uh for that mode so i think uh the right way to discuss about it is to first decide what's the actual meaning

and the usage of this function should we just uh assume that this function is used by default that is used to to analyze what's happened what have what happens in reality and then if we want to use it in some other specific way then we need to provide additional additional uh conditions through the parameter list

Martin Holst Swende: yeah i i posted the link to the pr that peter wrote on discord he basically says there are two major use cases that need to be covered and then he has six different

tests slash cases before and after 1559. um it would be interesting to know when whenever you guys implement something regarding this if you guys do the same thing or if you find reason to do something else if you can just post it somewhere

Tim Beiko: yeah peter's peter's pr description there is very good uh it feels like it probably makes sense to use that as like a reference and uh if yeah if teams have like some disagreement with it we can deal with it then but it seems like he's really thought through

uh all the all the various scenarios okay so uh yeah i'll link uh i'll link it in the the ticket um and yeah if if people have issues or changes they want to make we can we can discuss them next time um cool and the last json rpc thing uh was what was it sorry lost in the tabs you guess price or free history yes okay yeah best one for us um so basically uh there was another long conversation on the discord uh this week about whether uh we should use eth max priority fifa gas to return kind of a

uh value for the priority fee in the clients or whether we should just return raw data and um and allow wallets to to kind of calculate uh their own priority fee because it will be much simpler post 1559 um micah had posted uh a quick comment on the chat kind of summarizing that you know from the last call we had with a bunch of wallet providers um you know it seems like the fee history approach would be better um i think there's also you know like some issues that uh he and others had raised in in the the the call with wallets that if we go with like the max priority fee for gas api it kind of becomes a crutch and maybe wallets will like never build

better estimators um whereas if we just start with the fee history api um yeah uh things uh you know it it kind of forces people to to actually build a an estimator on top of that um uh zolt i know you had worked on the fee history api do you want to maybe take a minute or two to just kind of describe how it works and what data it returns okay yeah so uh so the fee history api is uh well yeah it's this road data approach and uh and like i came to like this this this

conclusion that this could be the best solution based on like this long discussions and everything so i also had an initial suggestion that uh that tries to try to to like uh give like uh prices as results and and and and i think peter was also kind of opposed to it so what fee history does it basically i just just returns so you can you can specify uh like a number of blocks how many recent blocks you want to retrieve uh you can also like specify that you want to so you you can you can also select a block range which

can even be an order range or it can go up to the head block or if the the supply the the backhand node is a minor or has a or a full node and has a pending state and even the pending state can be accessed and what it returns for each block is well it returns the the base fee it returns the relative like guess used and so that's just a number between 0 and 1 and it can return multiple percentile samples of of minor reward and by minor reward i mean the effective rewarded effective tip so what the miner

can keep and uh yeah so basically basically the the api in the api code you can specify either uh one percentile number which can be zero in which case it returns the smallest smallest minor reward in a specific block and in each each specific block and or you can specify like if you specify 10 then it will return the 10th percentile calculated i mean i and when i say percentile i mean weighted by actual gas used inside the block uh the ap the the call even even allows specifying multiple percentile values

and and then it can take multiple samples from each block because calculating this is basically zero overhead and it can be useful so yeah this is this is a basic idea and by the way about the other thing the max priority fee api so i can add a little bit to that and that's basically that i'm also now i also kind of think that maybe it wouldn't be very good to to just drive the wallet developers in a way that

so that they can they just use this single number suggestion because i don't think that's going to like be a good direction so the reason we have this thing is that we allow sending transactions where they where the price fields are fields are not set at all so we so get has this like auto fill uh feature for prices and if we want to send a 1559 transaction then we have to just fill in some very dumb default and maybe what we should do is that we should have this number for for for the autofill but maybe not expose it as an

api function so i now i think this would be maybe the best compromise and yeah piper you have your hand up

Piper Merriam: yeah so i have some concerns with standardizing this type of thing because it requires nodes that serve it to have access to a like decent chunk of kind of like recent history block data i guess it's not a huge chunk but i'm thinking about kind of light nodes and light nodes that want to be able to expose json rpc still and this kind of thing is going to continue to make that more complicated whereas this data is servable

i understand correctly from i mean it's really just aggregated data over the recent history of blocks so i recognize that it seems more like a convenience api that aggregates that stuff but by standardizing it it puts like further barriers to entry in kind of putting an onpar json rpc api for light nodes so anyways just voicing those concerns

Tim Beiko: would that also be true of the max priority fee api because you i think you still need to look at the transactions in the block right

Piper Merriam: uh i'm not familiar enough with this to

answer that but i assume that that might be most recent block as opposed to like significant aggregated data over large recent block ranges but somebody can connect correct that for me you are kind of correct so correctly uh if we serve the so with the like currently existing guest price oracle yes we need to access a few blocks and we need to like fetch the transactions in order to extract the data and that's what the old guest price oracle does and and that's what the fee history implementation also does and well yeah it works for the right client obviously

if you want to retrieve like a long history which you you are not forced to do you can just if you if if you just want to operate a wallet you can probably fetch the last two three four five i don't know blocks and you can do that with a light client and yeah so having an api that that's theoretically serveable by a light client and with some parameters it could be like expensive and take long well that's true for most of our apis you can do like clash filtering and you can do a lot of stuff that can that does work with the light client and these things do work with the light client without any problem it's just

yeah uh if you retrieve like a 100 block long history which you just don't need for for wallet but if you do then it will take long time so i think

i think i think i think it's

Piper Merriam: yeah you can i i'm totally on board with you uh in the in that yes you can absolutely do this stuff from from a light client context i'm just giving a i'll call this just like a minus zero small pushback on adding a new standardized json rpc api that is kind of inherently maybe the concern here is that it's very much not like oh one operation time that that like you said you know logs and points

like that that have parameters that users might pass into them that make it that it could have unreasonable bounds in terms of how many blocks they want to process this stuff for and things like that um and that you know the end expectation for users is these things just work right like you you say yeah give me the average whatever for the last you know 100 000 blocks and the expectation is that it will return that data but on some level it becomes undefined behavior because what happens if clients start even not like clients start dropping old blocks and things like that or what

happens if they pass in a 10 million block range or things like this yeah

Tim Beiko: the biggest difference here is that you don't need like a very large number of blocks to build a good estimation um because 1559 adapts pretty quick i think it's like every six blocks you know the the base fee doubles so you can see you can see with like a handful of blocks what type of like regime you're in and so and and that's what you could use and set your tip

Piper Merriam: maybe something that would make me feel a little bit more like less resistant to this was if the json rpc spec had some clear bounds on like expectations for you know longer ranges into history

or longer ranges of blocks or even actual upper bounds say the behavior of this is undefined above this range that's a good point

so yeah and like

Piper Merriam: i would love to see that for the logging endpoints to say the behavior of this endpoint is undefined above this number of blocks or whatever so yeah yeah that's that's that's a fair point so the thing is that uh already uh so the my the fee history spec already allows or optionally allows like giving data about the pending block which is also obviously something that like clients can do so that's also specified as uh some some some backhands might support it but it's optional and

the caller should be prepared for that that it might not work with some backhands and maybe we can just do the same thing with block count because it's yeah it's not a one it's all blow count and we can just say that uh uh like supporting these four block counts larger than five or 10 is optional and might depend on the back end whether it will be reasonable or not that'd be great the other thing that i might ask for here is some way for the node to signal back to the user what is allowed into this endpoint so whether or not this is some sort of like meta endpoint that we start exposing that displays information that

that the node can hit and say how many blocks back am i allowed to go for things like this endpoint or logs or things like that because that's the other hard point here is that even if we make it clear that nodes don't support this it still doesn't really quite address the issue because the wallet software still needs to be able to somehow figure out what am i allowed to ask at this end point and just sort of poking it until it stops responding empty probably isn't very good us how about yeah that's that's also like uh we don't have to solve this on this call i just wanna like drop these ideas in here because they're kind of like problems that have showed up in past

json rpc endpoints

yes yes yeah sorry

Tim Beiko: i was just going to say a quick question like how many blocks do light clients typically hold on to like what's like a is it like 2 20 200

i i

Piper Merriam: i there's no real number here but i think 256 has often been just like a sane like okay like but this is just really sorry yeah so that lifelines don't really hold on to blocks by default at all so uh in some sense the answer is zero but they can like request it but that costs some bandwidth and time so yeah definitely like uh requesting 200 block history with a live client is

too slow so maybe one thing that we could do about this thing is that the the call format already allows like uh not supporting all the data that the caller has requested because uh the answer contains like the uh first block number of of the results and then the lists of of base fees and rewards and everything so it's it's it's totally possible and we can just specify that the the back end can any time just limit and say that okay you have requested 20 blocks because maybe the full nose will serve it

but the right slide node only wants to serve eight so yeah the answer can just point to a later block as the first block and contain like eight blocks of results and i think that could also work because the caller should be prepared that okay now this backend didn't give me so much history then i have to work with what i have

Tim Beiko: and yeah yeah and that generally makes sense to me i feel like eight to ten blocks is probably sufficient until i get a very good estimation because you know if you have like yeah that amount of full blocks you know you definitely know that like you're in a massive uh demand spike and and you'll need to put a big

a big priority for you anyways um so i guess just to take a step back would would all the teams be okay kind of going with the fee history as kind of a default um and capping the number of bucks uh that it returns the history for to some small number around you know like eight or ten ish i see a plus one from base u um any objections nope okay um so great let's do that um i guess uh we have the the spec in your gis uh zot uh would you be able to open a pr against the the json rpc specs

or should somebody else do that no no i will add these uh clarifications to the spec first about the block count and yeah then i can open a pr again okay awesome thank you very much cool so i think those were all the outstanding json rpc issues um i don't know if anyone is aware of any other okay um if not uh there's one more thing uh that came up this week uh with regards to how we treat uh eoas and smart contract accounts which could under some very

uh tiny edge cases uh have the same private key i know uh denkarad you've been researching this and wrote a nip about it do you want to take like a minute or two to kind of explain the problem and and what you see as a potential solution

hopefully you're still on the call sure yeah um yeah so just a quick overview i mean so the

Dankrad Feist: the problem is uh the simple like um like a an address collision between an eoa and um and a contract and uh just just for everyone who's like less cryptographically inclined to summarize like

um how that could happen i mean we're talking about uh someone specifically creating a collision here so like in order to do that like for in order for that to happen randomly that would be super unlikely like it's 160 bits like 2 to the minus 160 is like a super small number that's not going to happen like we can basically assume that that never happens um but someone can basically use collision finding algorithms to specifically create that and like to give you an intuition like it's it's much much easier because you only need to get to the so-called birthday bound and which is like root of of of the difficulty of the problem essentially so um finding a collision basically what you do is you generate

2 to the 80 um end user accounts and you um simulate the deployment of the contracts two to the 80 times and then an expectation you will have find about one collision between these and now you see like that is obviously much much much easier than two to the trying two to 160 times um and uh like this very simple description obviously has a problem that you would restore these two to the 80 addresses at least for one of those two like lists you generate but in actual practice that's not true so there are algorithms so-called cycle finding algorithms that do this without requiring these insane amounts of memory and that basically means there's a

problem now um and the reason that's a problem so uh think about like bitcoin mining uh bitcoin mining currently solves uh a problem of this difficulty um about ev once every year so dimitri covertow which um one of our cryptographers estimated this and thinks like finding one of these collisions is basically about as difficult as like one year of bitcoin mining which is uh which is which costs about 10 billion uh dollars probably like developing the hardware plus paying for the electricity and all that um now like uh just remember that these kind of estimates are are not like an exact sign so like it could easily be

off by a factor of 10 either way uh just i just want to make clear it's not like completely outlandish to think that this could happen now basically someone could specifically try to prepare this now and now why is this a problem so um like basically previously like we thought about the case where okay like what you could do is you like um create this collision and then you don't deploy the contract but you somehow trick a user into sending funds into it and then you withdraw it using eoa key i mean that is actually i mean that is of course possible but um people don't tend to send large amounts to contracts that aren't deployed yet so it

doesn't seem like a very serious attack vector if you like have to invest several billion into finding that collision however like when we started thinking about this last week suddenly we found that actually uh even after deploying the contracts you can still do that right now we don't have any protection against that like it's basically it was assumed i guess when the uh spec and clients were first built there this never happens and so you just um uh yeah you just deploy the contract first and then like it could be something that looks like completely innocent like let's say like craziest example would be something like rubbed if or something like that right you think it's just a wrapper contract it does nothing and you can always get your e-stack well that's not true if someone had the end user account key for that

contract um but luckily this very bad attack back that we can just stop by just like making all transactions that um that have send their equals and a deployed contract invalid and that basically stops this uh yeah in my opinion most serious attack vector and all the other ones they're still kind of annoying but but they are at least for the next few years not really practical attack vectors and that's basically what this erp does i think 3607 has been assigned to it basically i think like we should basically we might not want to treat it actually as a full upgrade we might just say well we're kind of specifying what some previously unspecified behavior was

um and so we say like this does these transactions become invalid and um and then yeah this cannot happen cool yeah that's the summary for my site

Tim Beiko: so thanks uh demprod um i think there's also one thing worth specifying uh oh and i'll let micah speak right after this but one thing uh we're specifying is this eip doesn't actually require a hard fork but only a soft fork uh because it's like a tightening of the rules that doesn't introduce any new features

um so you know while there might be some value in trying to like time the deployment alongside london because people are forced to up update then this is actually something that can be deployed as a soft fork uh at any time um micah

yeah

Micah Zoltu: i'm just curious what the status of extending um addresses to full 256 bits is like if that's close then this feels unnecessary if that's still like a year off and it feels much more necessary

Martin Holst Swende: it's at least the euro would be my estimate

Dankrad Feist: i mean we haven't really even got a proper specification of that yet right

Micah Zoltu: uh yeah like last unless they heard

Dankrad Feist: i definitely wouldn't call it wouldn't call it close i think that's the open field

Lightclient: this is also something that can be soft forked in and out assuming you know there hasn't been an instance of this before so it's not really an issue for some reason we reverted it when we had larger address spaces

Micah Zoltu: no that's true

Tim Beiko: and as i understand it it is like a pretty small implementation change right like you're just adding one check when you verify the validity of the transaction

Martin Holst Swende: so the nice thing about this is that in order to

whenever you want to do that check you must have already loaded these this try object this state object from this we already have it you have the code hash and you can immediately check if it equals to the you know empty code so there's no extra cost really to do this check

Tim Beiko: so my my proposal for this um was yeah given that it's like three lines in geth um and you know

uh it is like a small change uh but at the same time it's not something that's probably gonna happen tomorrow uh you know there is still like a a pretty high uh pretty high like uh i guess hash power needed to uh to actually exploit this um and because we've mentioned in the past we wanted to see london on test nets sooner rather than later um i was wondering if this is something we could add into clients uh basically in the mainnet release for uh for london um so that we kind of go to the london test nets with you know the fork as it's defined now um i think in the past there's also been some concern about like accepting something the first time it's presented

on awkward devs because you know people might watch this meeting a week from now and come up with some objection or whatnot and want to to raise that um so that you know if assuming like you know no one has an issue with it um on the next call we could just say this is something we add to the clients before the mainnet release of london but that we don't have to delay the test nets because of that um i'm curious what people think about it oh thomas is against sorry

Tomasz Stańczak: i'm uh i'm generally against of dropping anything more to london even if it's small so even even if you find those collisions i at the moment it's it's just a question whether it is

consistent behavior of all the clients or not like they just sending the transactions from the contracts is not the problem of itself right

no

Dankrad Feist: no it is a huge problem because you could steal all the funds like say like someone had done that for up either like just to be clear i assume it's not be done for raptor because it's been deployed years ago but like if someone had premeditated this and deployed that contract with this collision then now they could use their key and take all the ether that's right now in that contract and transfer to their private account

Tomasz Stańczak: okay so that's what you mean that it might have been planned like a launch

long-range attacker

Dankrad Feist: or anyone yes or anyone could plan it right now like i mean we we thought first thought about this like one week ago but someone might have thought about it last year not super likely but there could be someone basically ready to deploy this

Vitalik Buterin: yeah it's i think also important to not overestimate the ease of doing this like we are talking about to the 80 computing power which is an insane amount of computing power and like yes it would be a medium difficulty if we had asics for it but nobody has asics for ketchup at the moment

Dankrad Feist: uh so yeah i mean i i generally agree that it's very unlikely

that someone has this right now i uh on the other hand if someone could start this now that that actually there might be worthwhile like one year ago probably nobody would have done that it's just the whole ecm network wasn't worth that much but now it's very different

Vitalik Buterin: you know just like my feeling is that the urgency is nowhere near high enough to even think about doing like modifying london to put something like this in

Piper Merriam: so one easy potentially low low friction way to include this would be to get the uh the fixture test ready for this that would it would demonstrate compliance with it and then just to get them merged after london is out

so that they are already part of whatever comes next and so by the time that we get to our next hard fork after that and clients are working on compliance with whatever new versions of the fixture tests are coming out these are already part of that base and they inherently have to add it in by the time the next port gets around

Dankrad Feist: that would be the most then

Tim Beiko: not necessarily because we're pushing back the difficulty bomb to december 1st assume the merge is not ready december first uh we're gonna need to push back the difficulty bomb again so that means that would be like i guess at the latest if we don't do it now we'll do it uh december 1st roughly uh martin you've had your head up for a

while

Martin Holst Swende: yeah i i think it's important that we you know agree on this and that there's consensus that it's something we should have i don't think we need to tie it to hard work i don't think all the clients need to say yes we're going to include it for london uh as long as we have this agreement i think your clients can just merge it whenever wherever as they see fit as fits for their release schedule and if someone exploit this and then they pay them billion dollar for consensus issue on ethereum um which i think is a nice price i think it's

a decent security um yeah so so i would just if we just get agreement i think being guest would probably merge it pretty soon probably before london maybe after uh definitely not wait another half year and to the next park but whenever we feel like it [Music] yeah anyone agree these agrees for that

so

Marius van der Wijden: so the only the only thing blocking it from from merging it right now uh are the state tests because um a lot of state tests um assume that the sender has some kind of code uh so we need to i already rewrote the

state tests so that they don't do this anymore um so they can be verified with the with a new change in and i now have to write some tests basically for the change to verify that a client has this has this this query and as soon as this is done the problem is that um we have to merge the tests before we merge the updates in the clients otherwise the testing pipelines for the clients will fail

Micah Zoltu: uh just for clarity if we go with martin's plan

are we asserting that should someone do this from here on it's a consensus failure if anyone includes such a transaction and accepts that block regardless of whether you update your client or not the right or the canonical fork is the one that does not include such a transaction is that correct

Dankrad Feist: so it will only lead to a consensus failure if it's not the majority mining client like that uh rejects it otherwise the longest i would

Micah Zoltu: so like let's say another mind let's say another minomundus which has i think no miners and no one else implemented it and someone exploited it another minus canonical chain

in this hypothetical chain split because we were green that is the rule if you don't update your clients that's your problem

Martin Holst Swende: they would fall off so it's yeah so so it's it's i mean as long as it gets exist for london problem is solved

Tomasz Stańczak: like nevermind is not mining on uh on main net so there is no chance that uh this will be included in another mind against what kev uh believes

Micah Zoltu: sure so i guess maybe we're saying is guest goes first everybody else will follow and then as soon as geth implement implements it at that point

forward that's the canonical rule set

Tomasz Stańczak: yeah i think it can be it can be just assumed that this is currently the role the rule it just might be by getting implemented on the clients which means that if gef follows with the change it doesn't even have to go as a heart for it because it never happened on mainnet nor we plan it happen so it can go just like as a soft update and then just get says like and then if we failed to update very quickly then we took a responsibility on ourselves in the undermined that that we have a split that nobody will follow because gaff will have overwhelming majority and that's why

i think i think

Martin Holst Swende: i think that's what the e means i

think bankrupt it didn't put you know a rule where at block number x but i mean it's a it's a retroactive rule so it's not it's not actually tied to hard work and this is just a practical uh practical aspects of everyone are going to update pretty soon so it would be neat to get it in for them but there's no time yeah

Tim Beiko: so does anyone disagree with just you know the nature of this change that this is what we should do

Tomasz Stańczak: no i'm in favor of the change just didn't want to have it uh as like um necessarily tested change

for london because that's that's what i thought would be a quite a big effort for the testing teams but i'm totally agreed that geth can go with this change that we want to go with this change and we would go with it as fast as possible just didn't want to have it officially in london

Tim Beiko: does anyone have a different position than that

Tomasz Stańczak: quick question did someone verify that this actually never happened this kind of transaction

i mean we can verify that somebody i'll go ahead i mean we can leave here he

Martin Holst Swende: would do a full sync with mary's pr and then we're done

Tomasz Stańczak: yeah so i would i would like that proof

that it never happened it's very unlikely but

Martin Holst Swende: sure

Tim Beiko: cool okay so i guess just for the next steps uh maybe you yeah so uh we'll do a full sync verify this never happened um assuming that's the case clients can implement it whenever they want uh we agree that's kind of the general herb that's kind of the canonical behavior um my last question would be like where does this get documented so if you know somebody wants to build a client one year from now um if this is not in london you know it'll be kind of a weird eep

that's kind of standalone that people need to know is in so is there like okay so we added to the yellow paper

Tomasz Stańczak: yeah that seems like right thing

Tim Beiko: okay so yeah if we can make sure to add a pr to the yellow paper uh as well i think that would be good just so we don't just forget that this is implemented in clients um thanks

miris

Tim Beiko: cool anything else on that okay um so i guess uh lasting related to london uh it seems like we're you know uh in a pretty steady spot

um i'm curious you know when if teams feel like they're there they know when they can have a release that they would be confident for to to fork on the test nets um there's like a few outstanding json rpc issues i'm not sure if they're all kind of must-haves for the test nets how do people generally feel about that

Martin Holst Swende: i think we should not weight with the tesla deployment due to these rpc issues and i mean jason rpc are part of the ux and yeah it's just good to to continue

developing the ux on the actual user-facing network

Tim Beiko: okay does anyone disagree with that in that case uh you know when the clients think they can have a test net uh release out is it a few days a week a couple weeks

tuesday

yeah i have not talked to peter about that but i believe we can do our next week about

Tomasz Stańczak: somewhere next week uh not exactly sure

today

Tim Beiko: okay so you know if i guess does any client team feel like they could not have a test net release sometime next week um so you know next week that'll be basically like uh june 15th um i guess depending on how much time we want to give people to fork the test nets we could probably uh we already have like a blog post ready that that explains all that we just need to fill in the client versions um there's 10 days after kind of the the um the releases are out seem reasonable to people for the test

network to have the first test network to happen um and then they would be kind of scattered over uh uh one per week after that um okay plus one from base u two plus ones from base u um and that feels good okay from guess so uh let me share my screen here uh so i basically put this together uh robston's a bit tricky to find a fork date uh because the the the blocks are so high that if you need like a palindrome block um it's hard to to get but um we could probably go with the later one

um where if we forked robson on block 104 99 401 um that would give us that would be a thursday so we can either get the tuesday or thursday thursday is probably closer to 10 days whereas tuesday is probably closer to eight days um yeah that would be june 24th and then we could have you know the two uh the two other test nets uh one week after each um we mentioned before we didn't want to set a mainnet block for now because uh we want to see how it goes on the test net so we we don't have to add that into clients um but would people be okay with kind of having these three days for the test nets so june 24th june 30th and july 7th and yeah there's a comment in the chat

that none of these scenarios have july 14 on the main net for sure we probably won't get a main net fork one week after the last tested fork so um yeah it would be later than that um and you know i have some tentative blocks here but like those are not final uh depends on you know what happens on the test nets and

and whatnot so um yeah yeah i uh i'm the question yeah so uh robson and gurley

Martin Holst Swende: are both multi-client testnet and currently are there any other clients can get that does ranking

Tomasz Stańczak: um so another mind can synchronize ranker b but uh

i'm not sure if people are running actively we may be running one ring kobi node just to confirm that it's always fine

Martin Holst Swende: well at least there are i know that brinkley is all the sealers are guests

[Music]

Tomasz Stańczak: we always during the forks we always run the rinkaby note we fully sync it and then we go for the through the fork so that's for sure happens but uh we don't draw

yeah i didn't

Martin Holst Swende: i didn't mean that you you didn't mean that you were lying but this meant that all the sealers are death so for 1559 it won't be very interesting from a ceiling perspective uh yeah i'm just

thinking if we just know so you're saying we should either do it and so making sure that they don't break something i think is value yeah do you want to add another mind node as a sealer

tarinkaby

Martin Holst Swende: um yeah sure but we can take that plan

Tim Beiko: but i guess martin was your point that if it's only get cedars we could do rinka b earlier or later like

Martin Holst Swende: um yeah well it it it kind of looks like it was building up in

in priority i mean robson is the most throwaways we do that first uh and it looked a bit odd to me that we do girly and then drink to be um instead of ring to be or maybe even rocks and andering at the same time then do girly because i kind of thought that girly was the more used well-used and high higher more valuable network um but i don't know yeah

i

Tim Beiko: i think that's that's probably a decent assumption um i guess uh one of the reasons why maybe i would put it first is because it's most used we probably want to have more data

on it right like we want to see more usage um but you know i it's not very

Martin Holst Swende: i think it's fine as it is

Tim Beiko: okay does anyone else have thoughts comments if not we could go for like these basically these three blocks at the top um i'll post them in the chat and then the discord yeah any objections to those okay great um so uh yeah i'll make sure to share that um and then i'll follow up with the different client teams next week uh to see when uh the releases are out

and when they are we'll put out a blog post uh to to link everybody to the right releases for every uh every client um and just to make this clear to anyone listening uh none of these releases will include a main network block so that means that uh there will be another release that download if you're running uh only against mainnet this one won't have the london fork activated uh we'll figure that out at a later date once the first test net has forked um great uh so that's everything i had for london was there anything else anybody wanted to bring up if not uh so a few i think

months now ago a light client discussed 74 at eip 3074 on this call and uh people wanted to see an audit for it to better understand the security implications uh so that's been done and uh yeah the the auditing team is on the call with us today they wanted to give a quick overview of their findings um so yeah maybe lifetime do you want to start by just giving you a quick recap of what 374 is and the context there and then we can move to the the audit

Lightclient: yeah that that would be great thanks tim yeah so if i could just briefly recap for people who haven't been following us closely and may have forgotten what 3074 does 3074 introduced this two new opcodes off and off call the

auth opcode accepts a 3074 signature and it returns the address that signed the 3074 message additionally there is a new context variable in the current frame of execution that allows the executing contract to then make arbitrary calls as the recovered address and because the caller opcode is kind of a de facto mechanism for authenticating users and smart contracts that allows that essentially allows users to delegate control of their accounts to certain smart contracts so we refer to these contracts as invokers because they're the uh they're the contracts that are invoking auth and off uh and 30 74

messages and signatures are domain bound to these invokers and this helps protect users from replay attacks that might be tried to have their messages replayed on other invokers and so this basically means that all the security functionality is implemented in the invoker contract and it's sort of a extension of these uh like protocol security in that sense and this presents some uh some interesting security challenges which is why we've had some of these teams do these audits we believe that like safe invokers can be written even if it's a small number of them and that with wallets having allow lists to avoid social engineering attacks that 3074 can be safe

even with these security challenges i think the 3074 is really important vip to consider including because it does allow for many desirable constructions and a couple good examples of their of those are it allows for generalized transaction batching from eoas it allows for sponsored transactions that allow uh people to pay with tokens not other than eth you can do social recovery mechanisms for eoas that can be signed off chain and then only be played on chain whenever the social recovery needs to happen and you can minimize on-chain accounting for state channels and these are just the things that you know kind of we've thought of and thought that

would be useful but i think that because it's such a flexible primitive that it does allow for a lot of other things that i think people will come up with in the future and so because of these unique security challenges we've been working with ethereum foundation to have the spec audited and there are two main components that we wanted to focus on the first was an audit of just the specification itself in general trying to think through the things that could go wrong the security concerns that arise just from the spec and that has been completed by leased authority and i'll have them share their fines in just a minute the other component that was really important to audit was there is a small part of 3074 that creates a breaking change for mainnet contracts

and we really wanted to have uh this auditing from dw look into this and see how our mainnet contract is going to react if this change is included and i want to stress that that this breaking change of 3074 is something that's optional the 3074. it does provide the nice functionality of allowing users to send 3074 transactions themselves without relying on some sort of sponsor system but 3074 without this change does not present breaking changes and i think it's still incredibly useful to have because it does allow for all these transaction batching sponsored transaction mechanisms so just keep that in mind as uh they're discussing their findings so if there aren't any questions on 30 74 specifically i can

have the least authority team talk about their findings in their audit okay yeah at least authority you guys want to go ahead and share

yeah great um yeah thanks like client and thanks for the opportunity um to have us work on this it was a nice experience with the quilt team you're all very helpful and we had a good month talking back and forth about security around this this is a bit of an interesting audit since it has a lot of potential things that can go wrong from the surface level this you know looks like opening up

an account to the entire possible world of smart contracts and leaving yourself vulnerable to any random execution so just to quickly go over our structure and and what we looked into we we looked at you know current breaking changes as you had mentioned um you have the do bob team working on checking the message.sender equaling tx.org assumption for the frame of execution and the use cases for that being used against flashlight entries we looked at the signed data security what is actually being signed the type prefix the importance of including the invoker domain

and why that's necessary and and the address manipulation possibilities um social engineering attacks on that incomplete fields maybe in the commit do we looked at are there enough fields in the signed data to assume that this is reasonable um went further into some replay protection looked at human readability of the signatures and and decided that this was a concern for the wallets we looked at the implementation security of invokers trying to reason about if it's possible to create such a trusted and important piece of contract code we kind of did some brainstorming on all the ways that invokers can go wrong

we kind of made a list of potentially bad invokers and um how easy it is for an invoker to do the wrong thing which again stresses the importance of creating correct invokers and really spending time to make sure that these pieces of code are doing what they're supposed to be doing and you'll see that stressed throughout our findings in our report we think a little bit about the permanent authorization aspect of this where you are signing your account to a piece of code and this piece of code will have that signature potentially forever this is comparable to infinite approvals i think that that's kind of a good way to sort of think

about these invokers and and compare and contrast to that situation um and infinite approval can be unapproved but an infinite approval is still infinite and the damage is going to be done if it's if it's taken advantage of we look at wallet implementation security because this is particularly important since wallace will be in charge of securing these invokers or making sure that signers users are signing the correct invokers and and this idea of allow listing and creating a set of invokers that the community and wallet implementers consider to be safe we find that very important we looked a

bit into the relationships the self-sponsoring case and the meta transaction sponsored case sponsor-responsive relationship and any potential pitfalls that that may create you know um distributed network concerns similar to a gas station network and in those areas and uh and we have our general uh you know conclusion that i think is uh similar to some of the community members we independently came to the conclusion that an invoker is a sensitive piece of uh tooling and it's going to require a lot of care but if the if the rights um uh implementation is created

if they are perhaps simple enough if they are um verifiable if they can be formally verified if if we are confident in their correctness then then these things should be able to make their way into a hard-coded list inside of wallets and you can sort of view these more as an extension of your wallet than giving total access to all of the contracts that you may be interacting with um and i think it was dan finley on the ethereum magicians forum made a pretty cool post about um how you can sort of view an invoker contract as you know giving specific uh access it's giving more functionality to your eoa

if done correctly and this can bring about some positive changes in the current way that we are doing both meta transactions um and infinite approvals if if we can uh bring them to a central point then we can have more confidence and correctness that might bring up concerns about central points of failure the um the attack surface or the consequences might be more drastic if a single invoker fails and it's attached to a lot of accounts um however it's also a positive if you are able to trust that source is valid you don't have to rely on every application

implementing something like infinite approvals correctly so in general we think that this if done correctly they've taken time and if the right use cases are implemented and wallets implement only the right use cases that this has some net positives for security um yeah that's i think our final conclusion

Lightclient: thanks for sharing that nathan um i don't know if anyone has any specific questions for nathan or i think ryan from lisa thor is also here one of the other auditors but we also have the dwab team here to discuss their findings so i'm not sure if it makes more sense to just go ahead

and have them discuss and at the end have questions for both or if people have burning questions right now

Artem Vorotnikov: um so i have a question so basically the solution to your solution to the social engineering issue is the invoker whitelist is it correct in the words

correct yeah um the white list is very important um and so i think that is the point that that allow list might reduce some of these fishing attempts that could be spread across multiple applications

Artem Vorotnikov: okay and how are we going to call that

white list ethereum banking charter

um that's a good question so that i believe would require some effort between the wallets and um yeah i think that's a good question it's important that consensus is achieved and i think that it's a it's a very sensitive piece of code that needs to be done and implemented and white allow listed correctly right so um that is a good question

Lightclient: i actually don't think that it's something that has to have consensus yeah there's something that needs to be necessary consensus across wallets it's something that as a wallet you can you can say i'm going to allow this invoker not that invoker and then you can tell it to advertise this to

your users as this functionality and you say look this wallet can do these sorts of batch transactions because we've done the work to make this invoker trust this invoker and that other wallet you know they have more features but they're trusting an invoker that's insecure and you know it's something that wallets can decide on their own time

but

in practice you can get convergence here as people try to avoid blame for you know like leaving the approved set and now you've got a relatively stable equilibrium of you know rent seekers so it's not a great look but yeah

Martin Holst Swende: it's i mean you you obviously trust the wallet provider with your private key so if you also trust them to

tell you what which ones of these contracts are safe to interact with i don't think that's a big change

Artem Vorotnikov: um there are cold wallets sorry what was that there are called cold wallets too which you do not trust with your private queue 24 7. basically yeah you it's basically it is you have to issue the transaction to do something now uh with the new mechanic it can be done for you at any time forever so it seems like

the recreation of the banking system basically

i mean that's just a choice

Martin Holst Swende: if you're a technical user you can make this kind of signature with your cold wallet or you can choose not to do this kind of signature right

Micah Zoltu: yeah it's totally opt-in so if you don't want to use 374 wallets you definitely don't have to there's there's no automatic anything here

Ansgar Dietrichs: yeah i think it's really best to think of these as like opt-in extensions to wallets and there will be standardized some standardizations so like you see like where basically there's probably one

one specific implementation for for a simple bundling invoke or something just just so it's easier for for kind of wallets to to kind of maybe expose an api that that tells the website if it supports the bundling or whatever but it's always just like opt-in functionality extensions that that's all it is really

Lightclient: um we only have 15 minutes left i also want d-dog to share their findings and have a chance to answer questions so be honest if you want to go ahead

Yannis Smaragdakis: sure uh so just to set up the context again we just did the analysis on existing contracts like the impact of 3074 actually the optional part of 3074 on

existing contracts and the biggest impact uh to refresh everyone's memory is that tx origin equals message sender is no longer a reliable distinguisher of voas so anyone can impersonate message center uh so that's the biggest threat because this is being used in practice and we try to quantify how much it's used in practice and to also inspect both prominent and randomly sampled code and see what the expected impact might be for existing contracts again so there are lots of details in the report so i do invite you to have at least a quick look at it there was there were lots of automated

analysis both at the syntactic level and the byte code level and semantic automated analysis and then extensive human inspection of pretty well-known protocols uh bottom line certainly it affects a lot of code i think that doesn't come as a surprise probably it affects around we we sampled around 1.8 of actively transacting contracts right now have some kind of check that combines tx origin and message center now does that mean 1.8 of the contracts are actually affected actually probably not uh in most of those contracts there are comments from programmers that say

just to be extra safe or we know that this can be front run but i why not check for eoas some people certainly are not aware that there are issues already regardless of 3074. now what are these issues uh with nav kind of deals anyone colluding with a miner can actually exploit contracts exactly the same way so is this code already vulnerable it depends on where you think mev attacks are going to go in the future and i'm not sure if people have a formed opinion on that already or they'd like me to elaborate on that but let me get back to the main story

there is a significant impact we actually think that such code is already kind of half broken that it's not going to stay safe for much longer we think that the kind of mev attacks we're seeing they're becoming very sophisticated they will soon be proactive so 3074 is not actually going to break a lot of code uh badly not any more than code would be broken anyway so that's our subjective opinion at the same time we tried in the report to be to very clearly separate subjective opinion from objective fact so there are measurements that are objective fact

and subjectively we assess that the risk is not that much greater than med so i can't fully keep up with uh chat uh questions let me try to sample a few how would the mev attack work so current mev attacks they wait for a transaction and then they send you it they wait for a uni-swap swap for instance and then they send you to future mev attacks could very likely have combined some analysis of vulnerable code that checks tx origin equals method sender so it can right now it can only be called by an eoa and the moment they find such code and they find

a vector to exploit it they issue atomically the exploit transaction first like they borrow from the miner they tilt the pool and then the attack transaction they make the victim contract lose money by calling the code that has that nested sender equals dx origin so that would be a proactive mev attack that we think there will be coming within the next few months mev attacks have become very sophisticated already so i think i gave a quick summary maybe it was too quick and maybe i can go over specific topics if people have specific questions is there something that you'd like me to

elaborate on or should i go through the chat and try to read questions linearly

Micah Zoltu: you you're getting another chat i think just discussion mostly

Yannis Smaragdakis: so just to add uh we did sample a few protocols we did sample some of the most prominent protocols inspected the code most of the uses of the guard comparisons of tx origin method center are for flash loan protection there are other uses like for instance for pricing there are services that give away their their services for free to eoas

but they don't want to give away everything to a contract because a contract can aggregate lots of customers so that's one concern there was also a pattern of uh avoiding briefing attacks like making sure that nobody can turn down uh receipt of uh if because they are an eoa but all of those are secondary patterns the primary pattern by far has been flash loan protection price manipulation protection that's the the primary reason why people check that whoever called a function is an eoa and not a contract uh reentrancy was a major concern

we found zero evidence of use of reentrancy uh maybe one contract maybe gsn actually becomes re-entrant if that guard is removed that was the only instance we found in both automated analysis and manual analysis

Lightclient: thanks be honest that was uh yeah you guys did a great job on the analysis does anybody have any further questions for leased authority or d-dog on their audits

Tim Beiko: i think you shared a link to the full audit by dwb

on the on the issue from here for the call uh the first comment um so if people want to read the whole thing it's available there um and then the lease authority one i believe yeah will be published shortly is that right

Lightclient: yeah

cool

Martin Holst Swende: yeah i don't have any specific questions i just want to say i think it's um i think it was a nice approach that was done here where one uh one approach being just a kind of theoretical thinking about it and modeling it and the other being more practical hands-on static analysis i've been skeptical about it

and yeah i can't really stop it anymore so i guess i uh yeah i no longer object to it if we had done two security reviews and both are kind of positive against it towards it

Ansgar Dietrichs: so i'm of course in favor of of kind of bringing this domain it but i also think it is dangerous to kind of just do this by attrition so um i would be hesitant to kind of go go ahead with changes even even if there's not no no kind of very specific objection but if it's still kind of if people are still

generally uh concerned on some level um so i'm just wondering what what the best kind of path forward here then is would like for example i'm not sure of course um might be only one of the people kind of concerned about it but i think one of the most prominent ones so like do you like would you for example be willing to maybe um sit down with us sometime try and really kind of hash it out and see if if if kind of we can find any specific concerns or if we maybe can i don't know alleviate some of your concerns or i don't know i'm just kind of very um hesitant to just kind of again to just basically go over something because we try it often enough to make people

just not want to reject it like just keep giving up on the objections kind of that makes sense

Martin Holst Swende: it's a bit late on the call now but yeah i mean we're going to talk about our future calls right because now we passed the security phase the security reviews that we said we were going to do and i guess that's some future call we'll discuss when or if to include it if or when

Lightclient: um sounds good

postponed until then

Tim Beiko: yeah and at least give you know weeks if not uh maybe a small number of months for people to actually read the reports

and you know comment on them and and and whatnot

um cool

Lightclient: so i don't know if they're like you know what is a good path forward for 30 74 from here and like what is a good timeline to again discuss potentially scheduling because i think there is quite a bit of value in having a reasonable amount of lead time because these invokers if this does go to maintenance and focus need to be developed and audited thoroughly so it's not i mean it's not critical but the sooner that we could say this is scheduled the sooner we can start building and auditing things and that means the sooner the users can utilize them so i don't know if we want to plan for

you know maybe like one month time

Tim Beiko: yeah i think maybe like taking a step back beyond this eep you know once london is kind of out and whatnot you know possibly in around one month uh or so we should have like the main network he says out and at that point we're kind of just waiting um i think there's like the meta question of like okay what are we doing next in general after london you know uh will we have like shanghai before are we gonna try and have the the merge uh you know and and what's even there so at least to me it feels like that's kind of the thing that needs to get resolved like we might yeah like if if if we if we think we are

going to have like another fork on the execution layer this fall before there's a merge um then we're going to need to start playing that one and then it would make sense to obviously uh consider a 30-74 um if we think on the other hand you know like we might actually not have a fork before the merge um and and have the merge first um then i i feel like it kind of pushes back those discussions um to me that feels like the biggest like decision point

Lightclient: okay yeah i mean these things are things we can discuss in future meetings yeah i just want to say like one last thing on 3074.

i think that you know i've had the opportunity to talk to a lot of prominent developers and teams of the application layer who aren't generally representing this call and there's exceptional interest in the eep on their side and you know i can help if people are unsure like who wants to do and how are they going to use it i can happily connect people with prominent teams to see like you know why they want it and how they're going to use it so i just wanted to share like my experience with talking with application developers and make sure that their voices are heard on all four devs regarding the

eep

Tim Beiko: yeah i i think that's helpful yet to have that context because it we are sometimes pretty removed from

like the end users and how they will use this and and i agree there's been like some like there's been a lot of enthusiasm by app developers for for this um enscar asks in the chat what are the latest chances for emerge this year with three minutes late left i'm not sure you can speculate on that uh marius you have your hand up

Marius van der Wijden: yeah um so i don't think we should we should speculate on on merge times and um also i don't think we should take uh the application land into account in this decision i think this should be a decision that we make about the

security and if it if it's secure if it breaks stuff and this should not be driven by uh applications wanting uh to to spend less gas or something

Lightclient: no i 100 agree more it's just a motivation for people to try and figure that answer out sooner than later you know if there is no interest in the eep then maybe people don't look at it but i'm just trying to convey that there is a lot of interest and i would like us to figure out is it secure you know we did these audits and there's a lot of text now to determine for core developers to determine their own and so that's really the yeah i don't want to push something through that's not that's insecure or leaves things in a bad place

my suggestion would be to come with a better answer to the social engineering issue than ethereum banking charter with

Lightclient: the ethereum banking charter is not an answer that's i'm not sure where you're getting this from this this is something that wallets will decide it doesn't have to be consensus among wallets it's can you can think of it like a an additional module on a wallet and you might choose to use one wallet over another because of functionality and so this isn't something there's no charter there's no you know community that has to say this is what we think is the best and here's like a voting process now it's just i'm going to use this wall because it has these functionality and i trust that it's going to do it's safe

and if it doesn't then i'm not people won't use that wallet that's the most important thing all to have is the trust of their users

Tim Beiko: um yeah we're kind of at time uh but clearly yeah we're gonna need more discussions about this uh in the future um there's two announcement that people wanted to make uh before we we cut off um so one i see run in you're on this call and you post it in the chat that gordy seems to have issues i don't know if you want to like take a minute to just kind of explain that i don't know if you have a mic oh lucas you have your hands up i don't know if it's about the same thing

Łukasz Rozmej: yes we are syncing our note to produce a correct block

i think it should block it i hope

Tim Beiko: okay awesome um and then lastly puja you had uh i think you're the catheters are working with methamine on the survey uh do you want to take a minute to just kind of walk through that

Pooja Ranjan: yeah sure thank you jim uh so uh atm cad hurdles in association with another mine team is conducting a survey on ethereum blockchain users and developers uh research to better understand the future requirement of client developers in terms of tools and documentation we thank everyone who already have responded and this list includes each takers

community the developers and researchers and most if you haven't done it already consider responding to the survey if you are any anyone who is running ethereum one dot oh node two dot or validator node and otherwise contributing to blockchain it also includes hobbies minor wallets and launching projects because uh this survey is going to help us create a better infrastructure for the epm ecosystem we are we will be sharing the responses received in a form of report in the month of july the survey link can be found in the all code meeting 115 agenda it's there and also at the catholic discord responses are accepted till june 30th

midnight pst consider responding we need your feedback to let everyone know what is needed in the system to improve it thank you very much

Tim Beiko: cool anything else anybody wanted to bring up uh in less than a minute if not well thank you everyone um yep see you all on the next call

wow [Music] thank you all right cheers we'll be on discord for a little bit if anyone else

wants to chat thanks bye [Music] [Music] so [Music] me

[Music] [Music]

[Applause] [Music] you

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