All Core Devs - Execution #100

Transcript

[Music] [Music] [Music]

[Music] than [Music] J [Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music]

Hudson Jameson: all right hello everyone and welcome to ethereum core developer meeting number 100 woohoo that's um an accomplishment of I suppose we've been doing these since well on a Cadence we've been doing them since about January 2017 with a few before then so this is really cool that we've been doing it this long and it's been you know helping ethereum so thanks everyone who's been attending and uh has kept this going all this time um the first thing we have up on

the agenda is yellow V3 and Berlin client updates um and uh there's also some subtopics in there so I'll have James Hancock take it over James

yep if we could get a an update on iess YOLO V2 is running in is running can you just give the update that you gave me Martin earlier

on

Martin Holst Swende: sure status um as far as I know there's basically nothing happening on it uh there was a uh there was some happenings when me and Marius um so I took the old

YOLO B1 transactions and re them re did some resaling around them on yo2 uh which yeah it bumped B offline because it turned out that they their node was Yol to compatible but it was not actually configured to use the yo V2 rules uh after that was fixed uh everything worked fine um and Marius did some new Trans fast transaction vectors that he played put put out on on the network and everything worked fine uh for me the the best point about it was not so much the network but the ability to fuss the

clients and I ran I run about 100,000 test cases targeting well doing a lot of sub rutine stuff and cross uh cross contract calls which heavily um heavily hits the 2929 rules um and yeah those fasting test cases have been mix of G bisu and open ethereum which I built off one of the branches from Adamas it I don't think it's in master um but that's yeah looking pretty

good

great the

thanks for moving that along doing those tests the for YOLO V3 if we just go through the clients and we talked about last week the actual list for yolow them decided on it so just like an update of where we are as far as um integrating for each client and ready to sync or just where you are in the process we'll start out with

Basu sure um so we're in the progress of implement in the process of implementing the E we got 29 29 2565 done uh we're

doing 278 now uh Ry on the team is is doing that and he can speak to how how that's going um and we're we're obviously waiting to have that done before we get 2019 30 started uh so I suspect by the next call we should be mostly done um yeah okay and GTH can you go sorry Peter you want to go I mean go go for it since you okay so um 2565

Martin Holst Swende: is merged but not in a state where it can actually be activated but the the

change is in there and U once we Define Y3 we can just activate it 231 2315 no problem 2929 is in and the ones that we're working on are 18 and 30 and uh yeah that's why we raised a few issues today on the agenda um so once we clear out those question marks I think we can kind of go ahead but there are also U as far as we see it probably there needs to be some some more agreements about the network components like how how do we communicate these transactions do we go for new e protocol or do we use the

existing one um yeah so so there's not only implementation work left I think there's a bit of specifications that need to happen

Micah Zoltu: uh sorry I think there actually is a spec for that I totally forgot that that needs to be included if we're going to include 29 or 2718 let me find it for you

oh while you're grabbing while you're grabbing that let's have uh nether mind are you here sure um s

Tomasz Stańczak: 2565 we've compiled the libraries have to connect them andart from that it's uh just the gas price change so not a problem 2315

um so we already have it I believe so this is sub routines right yeah so we have sub routines all tested Bas on the uh consensus test that we had before 2929 so I implemented that overnight and um ready to test so want to try to synchronize with Yow V3 when ready or if ready um 2718 similar yes

Martin Holst Swende: uh so I don't know if you know but Dimitri regenerated the state test General state test with the Euro V2 definitions so uh if you run the Berlin test you can get pretty good coverage of

all the 2949 stuff

okay

Tomasz Stańczak: that's perfect so I will use it after the call to um to test if everything behaves as expected um thank you 278 I have the same feeling as as Martin mentioned that I'm a bit confused about how it touches the network so I'll wait for M specification on the networking also a bit of the how the Legacy transactions will behave and how we actually decode from from this new format because it will be like um I think it may conflict with the with the rlp in some situations and 2930 so this one was probably the simplest and that's more like um as long

as 278 is clarified it should be fine I just need deserialization everything else it works so I do prepopulate the access list just do not deserialize transactions yeah so that everything ready for Berlin on mind

yeah

great thank you let's get we'll get back to 2718 I want to give open if the have a chance to give an update first

are you guys here U yeah yeah we here uh basically just merged all the IPS for allg on our Dev Branch uh yeah we have some basically just as Thomas said about if

we going to if there actually going to be merged in the list if it is going to be merged as the separate entity it is basically inced different way but I think it's small change that need to synchronize basically on and that's it we are basically clear ready for your awesome thank you um so then

Hudson do we want to go into 2718 now or

or

Hudson Jameson: yeah if Mah has if Micah has it pulled up let's go into it since that's kind of on topic of right now

I

Micah Zoltu: I can answer half of the questions I'm struggling to find the network EIP I

created but the other question I can answer with a pull request that is outstanding um against 2930 so that PR that is posted in the chat um once that's merged 2 or 2930 should now be 2718 compatible it was just an oversight in the authoring of 2930 I believe um I there's also in the discussion link I have some other comments um I'm not a huge fan of the current format of 2930 um but this is the minimal change required just to make it compatible with 20178 because everybody correct that right now it's

not okay

Hudson Jameson: so that's that's you said

that's half of it was the other half what what Peter posted in the agenda as a comment

Micah Zoltu: the other half is um there's three Hal sorry so the second half is for legacy transactions here is the EIP oh thank you like client I don't know how I couldn't find that so the one I just posted 297 2 is a proposal for wrapped Legacy transactions which we could which I I do think we should add at some point but it is not critical to add right now um the separate question is well if we're not going how are we converting between Legacy and

um let me take a step back so there's there's two things to do with Legacy transactions one is the thing we need to do right now which is when you get a legacy transaction you need to um oh sorry sorry my my head is in 1559 because I've been thinking about that all day okay so Legacy transactions for now we don't do anything with them they're normal they're just Legacy transactions they have the first bite for legacy transaction will always be in the range c0 to C to FF I think because of the way RP encodes a list it always uses the high basically the high those High bits and so we don't need to worry about it conflicting with 2718 transactions which 2718 transactions are

defined to always be below that c0 I believe and that I think is specified in 2718 if I'm not mistaken I'll check might be in the rationale section so if someone missed it I do not blame them yeah so legac transactions will always start with 0x c0 or greater and U 201718 transaction types only go up to 7f so there is no possibility for conflict which I believe is um Peter's issue is that correct

no or concern did I Mis expl

Péter Szilágyi: that uh we have actually two ways of uh of encoding we have the the Legacy transactions which is just whatever we have now without any

encoding and the EIP also mentions a wrapped version where you prefix it with I don't know zero or one or something

uh yes

Micah Zoltu: so that's that's EIP 2972 uh it's doesn't have to be part of Berlin if we don't want it to like in the future we might want that because it gives us some consistency around transactions in the network um and makes signing tools easier to write um but it is it is not necessarily required unless we want to is that something people want

can you specify what you mean by it like you mean the ra format part yeah so 2972 basically just takes Le

Micah Zoltu: Legacy transactions retains the same signature format so the signature will be Backward Compatible but gives them a new um

format for when they're included in a block or when they're included in a in Gossip or whatever and so we can have consistency within a block or consistency within um the network protocol if if we if we think that's that's valuable thing to have it isn't I would I think it's nice um I would definitely be in favor of including 2972 along with yo I just haven't been pushing it because it seems like we've been really struggling to get Berlin out and so I haven't didn't want to add more to the plate of people about that 20 2972 is the a for that

okay

Péter Szilágyi: so the reason I brought it up is because um I think it's uh then maybe it's important in 278 or whatever is the original one to just specify that Legacy transactions

aren't touched in any wave shape of way shape or form and then U this second thep I think that's a valid debate honestly longterm I think I I'm also in favor of U of including it just because uh it's weird to have uh two different representations however I think it's also super important so I haven't read the C because I haven't see it until now but um one super important part is to uh to somehow avoid any ambiguity because um the problem with the Legacy transactions is that even if we add this extra wrapping around it there's no signature so from a protocols perspective uh a wrapped version or a

non-wrapped version is essentially the same it's cryptographically the same so when we include it in a block uh we need to Define which version will be included in for you so you can't rely on clients trying to figure out whether it was original this or that

so these so yeah

Micah Zoltu: so right now um I believe when you say included in a block are you referring to in the transactions rout and then therefore for the the Merle tree is associated with that yeah exactly um so the when it when you get a batch uh what you can do is look at the first bite if the first bite is c0 or higher then it's a legacy transaction if the first bite is 0 to7 f then it is a type transaction

you can use a type so you can think of the that type bite is still there in Legacy transactions it's just like it's a range because of the way rlp encodes down to that first bite is always going to be something big

go Ahad yeah but

Péter Szilágyi: so I'm talking about the W version so as far as I understand there was a suggestion to have Legacy transactions also having this zero prefix

Micah Zoltu: yep and that would be the 2972 and if we decideed to include that and leave Legacy transactions includable in the block so part of so it's a little bit of of story around this if we include 2972 we could choose to in a hard Fork say that Legacy

transactions in their historic for legacy format are no longer allowed to be included in a block and only the wrapped ones are case we wouldn't have to worry about it anymore and and I'm like I said I'm totally okay with that if that's what the what everybody else wants um I think that's very reasonable

so

Péter Szilágyi: so in my opinion that would be a hard requirement otherwise uh so the problem is that clients are free to represent Legacy transactions however they want within their code base so it's in my opinion it would be super easy to to mess up where so you can have transactions coming from the network from a block from RPC and um it it's super sensitive if you can actually push them into a block into consens format in two different ways

because I'm certain that somebody or I actually I'm certain every client will mess it up somehow and just not use the correct one in one place or another that's why I I would really be in favor of having only one consensus format for for it

yep so

Micah Zoltu: so right now we have a single consensus format um assuming we do not include 2972 Legacy transactions is only one way to for form them there there is no other there's no wrapped way at the moment if we decide to include 2972 then I I agree with you that I think it would be wise to say the old format is no longer allowed in block and maybe even not even not allowed to be broadcast over the peer-to network

though I understand that's a little bit more complicated because you can have multiple versions live on the network at a time um but yes I I think I agree with you it's just up to the group whether we want to do 2972 right now and make it that hard switch today or do that sometime in the future

Martin Holst Swende: so can I uh just clarify for basically my own understanding if we were to do it as Peter say then the uh when we put together the the transaction rout we don't have to make differences between is it this type or is it that type we just put the type and then we put the rlp encoded transaction into the

hasher whereas if we yes do it like currently specified we would have to look at the transaction type see oh this does this an old sty transaction do it the just hash the RP or alternatively um concatenate a bite with the rlp is that like the core of it

Micah Zoltu: yeah I I believe that's the core of it yes so if we um if we include 20 972 then everything is a type transaction that's in a block if there's a transaction in a block it is a type transaction just flat we're done um there are different types of transactions there's now the 2930 type and there's also the wrapped Legacy type so the 2972 type and so you'll still have to do the code for 201718 for

distinguishing on type before you decode the rest of it but everything would be a type transaction if we went with 2972 and followed the thing that Peter just described

Martin Holst Swende: would uh and I I also I have not read this third you're talking about but it sounds like uh could couldn't that one be couldn't 278 be updated to include that and make the specification smaller larger so

origin

Micah Zoltu: originally we did include 272 and 29718 were one uh thing where 20178 defined um the structure so the new type transaction structure and along with that it defined

the first type transaction which was just a wrapped Legacy transaction um it was split out because there was some I believe there are some push back so two reasons one as everybody knows I'm a big fan of smaller independent eips and two there was some push backer against that originally where people were like well we don't really need the raft ones yet we could just do 2930 or we could just do 1559 or we could just do 2711 we don't actually need that and so by splitting it out maybe we can choose to not do that I'm still like I said I'm still in favor of doing them at the same time um we could merge them into one EIP I don't know if it would buy us much really um but it's it's possibility yeah we people feel very strongly

yeah

Tomasz Stańczak: I actually quite strongly

think that we should keep the Legacy transactions and never touch them and keep them always available for the blocks as long as possible

so not include 2972

Martin Holst Swende: as long as long as we don't I mean we still we're still not talking about I mean users won't have to actually sign rap transaction they they don't have to update their signers do they

Micah Zoltu: that is correct the signature is the same for the the new

2972 transaction

Tomasz Stańczak: as long as it just wed with the number in front

and it's fine yeah would be you're talking about is just a different way to

Martin Holst Swende: we can shape it differently in the consensus engine but not actually making changes for the

user

yeah

Micah Zoltu: so the in if you were to do that in a client then your Json RPC endpoint would likely still accept Legacy transactions in the Legacy format and then on receipt like as soon as it received it over that like Json RPC it just immediately wrap it internally because the signature is still valid for raptor versus Legacy and so you could do that just on receipt and then everywhere in your code base you could deal with 2718 transactions only if that's the easiest way for a particular client to handle

that yeah that would be nice and Thomas does does that change what you just said yeah what

Tomasz Stańczak: what I meant was uh if there is any transaction that's already signed but not broadcast then we should keep it valid so if it

can be later just wrapped in a different calization format by adding I don't know zero in front as a type of the transaction and it's perfectly fine yeah

Péter Szilágyi: yeah I guess that was the plan

right yeah so as long as the signature remains Val then it's fine yep

Micah Zoltu: that is a hard requirement of this uh 2972 was to make sure the signature remained stable between Legacy and wrapped Legacy um something to keep in mind since we're talking about this and I'm suspect we'll then move on to talking about whether this will be included in Yolo V3 or whatever um the 2972 as currently described does specify a

slight change in the receipt format as well because I believe 201718 specifies receipts and so just be aware that that is code that needs to be written it should be pretty easy if you've already planed on inl 20178 anyways because receipts are just typed just like in 20178 um so I don't think it's going to be hard but I just want to make sure it's on everybody's mind while we're talking about this

will there be Network specification for the receipts in if 63 as well uh so yeah

Micah Zoltu: so then getting into the the third half of that discussion is the link that like client gave just above um to 2976

and 2976 is yep can

can I just figure out where we are in the

conversation and then like so then as far as Peter's comment like either use one or the other but never both was there like a do so we want rap transactions but we also want so we don't want both but is there a sense of one or the other so far

Péter Szilágyi: so I guess um this boil out so yeah this has has multiple fronts or multiple Hales too mostly discussing add the consensus level so stuff that's included in blocks or whatever else consensus format uh they are my personal vote

would be to bite the bullet and just roll out the rep format and just drop the format because it keeps things simpler otherwise if we're going to if I mean I think most of us would agree if somebody doesn't feel free to shout out but I think most of us would agree that it's better to have a single way of encoding stuff than two- ways so it's probably if we want to go down the type transaction approach it would be nicer to encode all transactions as typed and not have special cases and if so if you're going to do wrapping for legacy trans actions in a future hard for then we might as well do it from the getg go that would be my my initial suggestion I don't know if there

are any tools out there or deps or systems or whatever that uh directly poke in blocks and that would maybe not survive uh changing the block format so that's that's a question for example ether scan if we do this will ether scan die or not I don't know so this is something should ask as much possibly

would

Tomasz Stańczak: have problems even if we introduce new transaction time then those tools would fail anyway

so then taking a second to pait this decision here is there so is there people that feel strongly that we shouldn't have the the rap format

introduced at the time of doing 2718 or is that something we can just decide here and then have the later discussion

I'm convinced now we can 72 sorry 2972 2976 Miko

Micah Zoltu: uh so just uh because I would rather this come up sooner rather than later I'm going to bring it up now um there are contracts out there that receive block proofs and those block proofs re include transaction proofs and receip proofs and those would break and those cannot be fixed I don't know how many there are I don't

know how used they are but I I I've seen code out there that exists like people have written contracts that do this but I guess that will break even if we just introduce a new transaction type so this is true um depending on how they use it like if I guess there's a question of like if they can still submit Legacy transactions in the Legacy format then they can still prove that transaction they just can't prove the new transactions where if we say those transactions cannot be included in the block anymore then they can no longer get a transaction into the blockchain that can be proven by their contract

Martin Holst Swende: so I I I have a feeling that we might not hear a lot about that

uh until

we roll it out on rly and they notic that it's happening I'm not sure Layer Two folks are hey Martin you sound really far away from your mic okay I'll try to reconnect he's just really quiet yeah he said he's gonna reconnect

so that would that would tend to

uh this

Micah Zoltu: one of those things like we don't know if anyone actually does this but it is a thing that I have seen code for because I happen to work in this

space a little bit and I kind of C I copied some of it like I was using as a reference that someone else wrote on some random GitHub repo somewhere so I know someone has written this code

the that's that's a bit better yeah did I interrupt someone right now nope keep going go ahead yeah so what

Martin Holst Swende: what I was going to say or tried to say is that I think we're might not hear from uh those people who are might be affective from this on until this hits until we actually roll it out on robst rink be or gurly because they might not be active in the I mean there two people might not be active in the discussions

here so maybe we should just do it and see what happens and how bad things break and how important it is

Micah Zoltu: cross our fingers that they actually test on

Robson and gr groly yeah yeah well what's

Péter Szilágyi: case scenario we're going to have a show like we had two days ago

nice okay we've got yeah

so then I would say it would be good to have a little more time on on test Nets to give a chance like spend a little bit longer on a test it might be better make given this change but it sounds like like a Bas who or open ethereum do you have thoughts on

including the rap format in in Berlin then just it sounds like eventually it's going to happen so we might as well get to it is this yes I'm for it

Rai Sur: it seems more elegant um I don't really understand the the block proof transaction proof uh contracts that Mah was talking about I'd like to learn some more about that but from the consensus standpoint yeah I think it' just be easier to represent them with in the type format

okay I can agree with that you agree

Dragan Rakita: basically yeah biggest problem is if you're going to break something with the tooling or something like that

but for the client perspective we are fine to

have one encoded according sham yeah it's better cool so probably also want to talk to people who use e186 um because they use the proofs of transactions so if something changes with transactions and might be the first ones that will notice what kind of problems it causes is there someone I could ping about that I use one6 okay I'll talk with you after

M that's actually why I know about this I use it slightly different way but I this why I happened to know

um so then let's say for now that WRA that WRA the WRA format is going to be included if it's in 2718 or in the other EIP I don't really care however you want Micah is fine uh but then Comm bar community members coming in figuring out some things that it should that it should go in and we can count that as a decision and then move forward to the next part of the conversation

Hudson Jameson: yeah so do you want to keep it in separate IPS or just have one

Micah Zoltu: I like I said before I have a

preference for separate IPS I like more modular IPS that can be picked and chose choosed like if we decide for example we need to pull out 2972 it would be easier if there's separate IPS from

278 got it okay

so we keep so we keep them separate

yeah

Hudson Jameson: so that would mean you add it to the spec sheet for V3 right James yep

okay so I sorry for harping I this I

Martin Holst Swende: I don't actually see what 1186 has to do with transaction

formats since

Micah Zoltu: it's about storage proofs he just saying Pro it's a way to it's just a way to identify who might be doing um using proofs in general and people who are using doing like Brock

proofs tend to also do account proofs and storage proofs like the same is it kind of you're just looking for an easy way to find people look for people using that if you have finding them

Martin Holst Swende: so basically the people that would be would be affected by this is if you have like a relay like the BTC relay or a cc relay so on the other side you have a you want to verify that the transaction was included in ethereum Block so you need get the transaction you hash it and then you follow the rlp um try basically to try to get the roote and yeah yeah I don't I see the direct connection with 1186 but they might be

the same F sure

Hudson Jameson: um and real quick uh Thomas you said um incubed uses it is that the slock at blockchain's LLC project uh yes okay that'd be interesting to talk to them then to see how they use it um whoever's talking to people about that maybe James or mic I forgot who

um okay uh so yeah go ahead

Micah Zoltu: there's the third half that we put off the third half is the nwork for letting me get to that the network side of of this which is EIP 2976 and it defines basically a fairly small change to the dev P2P protocol

interestingly the dev P2P protocol was sufficiently UND specified that we actually don't need this technically but this change makes it more clear um what happens

uh which I again it's in chat I think 2976 that one

Hudson Jameson: so you're saying this is something that is not necessary but a nice to have for clarity of the client's building right

Micah Zoltu: it depends on what you define as necessary I believe so the the for Dev P2P is like a Wiki page basically it's

not super detailed and it was vague enough as currently written or at least as last last I took looked at it it was vague enough that technically these new transaction formats were allowed only because the dev P2P spec didn't actually specify what a transaction was it just said there is an array of transactions and it didn't say what that meant um but I believe there's enough clients that kind of assumed that a transaction means a certain thing and so we felt it was valuable to more clearly specify okay this is what it means to be a transaction in in depth P2P

Péter Szilágyi: so I think this part is kind of Fairly important because um so this is something that we want to bring up the

networking wise because there's a so the thing is that all clients currently are in so even if the spec allows if the client implantations assume that the transaction is this rlp Cod the thing and um and the thing here interesting question is how are we supposed to support new transaction types so any code currency running e whatever 63456 uh will drop the connection if you try to send it one of these uh type transactions so one approach can be to backwardly upgrade all the protocol versions so that these fields can all of a sudden handle a typed transaction to

so essentially we're just doing e 63b e 64b Etc and uh that seems like um not the nicest thing to do because then you're kind of overloading the protocol version just trying to hack this thing in uh Felix's suggestion was to just roll out e67 with the new transaction format which from get's perspective is fairly easy to do but if client X doesn't support e 63456 then that's going to be a painful thing to do so it's not obvious what the best

choice

is

Artem Vorotnikov: I think we should just roll out

6 to7

Péter Szilágyi: I mean it so the so the thing actually I just realized that there's a second problem we could roll out e67 which supports transmitting transactions but we need to change the block format too so all of a sudden if we have a block that contains a type transaction that cannot be represented on any of the past e protocol versions which means that not only we do we roll out eth 67 we also drop support for everything else so we need to stop supporting

63456

Artem Vorotnikov: and that should be fine if if

everyone upgrades yeah everyone upgrades go went really well this last well well they so so you see the problem was that uh basically parity was very much behind on the on the protocol stack but very much behind on the current e version so that was the major blocker before uh now I believe open ethereum is on a track to support it already support 64 there was at least a full request support 64 five it should be fairly easy to support 66 and 67 is very easy as well so I don't believe we

are as held back before as held back as we were before

Martin Holst Swende: so I I think 66 which is identifiers yeah that can be implemented pretty easily by just pretending to have identifiers but actually ignoring them and keep using whatever method we have before 65 for for a client which have not yet started implementing it uh and 65 is the you know transaction hashes and announcement and ping and I think that's a pretty big thing actually I don't know where what's the status on that for other notes

Artem Vorotnikov: so right now uh the both in both

go centry and R centry so BAS line protocol is 65 64 but we also support 65 and uh 66 should be fairly easy to support and 67 as well

Péter Szilágyi: so I guess the important thing to know here is that U with the E64 the thing that that defined is transaction announcements so that the network doesn't uh Shuffle around transactions uh and doesn't send the same peer doesn't get the same transactions uh 50 times rather it just gets transaction hashes uh this is a bit of a

special protocol version in that it's not just adding some new extra feature but it's also taking away it's taking away the the default transaction propagation where we just send it to everybody so the complexity here is that uh if a client starts piing uh E64 without actually fully implementing it then there's a chance that they will not get all the transactions simply because most of the transactions will be just announced that hey here's a hash if you need it retrieve it and then they actually need to implement this retrieval logic otherwise log I mean transaction propagation will not work for them

so gas will not give you transactions otherwise you mean e65

right yes so one option one option would be to retain uh to basically uh insert transaction propagation back into 65 and 66 and 67 and remove it in e68 so everyone could just Implement e67 and when they are ready to change the transaction uh management logic basically uh they would also upgrade to e68 I believe this should detect gas because G would quickly Implement e67 and e68 and you still would have to rebroadcast projections to every con here but it would allow a quick forward

for every else

Péter Szilágyi: well yeah but in in that case essentially you're doing the what I said previously that you were releasing if 63b 64b 65b so then you might as well just extend the currently running protocols so there's not particular I mean that that would probably possibly be less messy than uh so the thing is that if if for example G I mean we decided we want to upgrade all the protocols yes I can roll out 67 8 9 10 but um will I immediately stop talking 3 four 5 six because if yes then that's kind of partitioning network if

no then it thinks that a bit weird so that's that's why I wanted to bring this issue up as it's not that obvious there are a lot of solutions the solutions aren't particularly hard to do just um we need to figure out all the implications

Lightclient: what is the sorry what was the argument against just you know letting the rlp decod or decode the transaction message that comes over the wire or the block that comes over the wire

Martin Holst Swende: yeah I was going to go back to that same question um because if if we are changing the consensus definition of a

block then logically e 63 should transmit so should use that definition um so what what do we say I mean what what's the benefit of having 63 a of all these instead of just changing the rule so we can change

the

Péter Szilágyi: I mean we can retrospectively change or extend the protocol the only thing will happen is that if somebody didn't U so if I for example I implement this in g 1 point I know 20 whatever it doesn't matter if I implement it in a new G and roll it out and this new G will send such a packet to an old Gap then the connection would

be immediately torn down because it's a protocol violation so all right right but in this case what we to do is we need to ensure that g will not transmit any new transaction format until the fork actually passes

and then

Martin Holst Swende: right because when the fork actually passes in that case that other side won't be able to handle the block anyway and there's no use talking to him

Péter Szilágyi: yeah but then the question is what happens if uh let's suppose we're already pass the hard Fork one month in the future and um and then you have a new node that is sinking uh and it's for some reason it's getting new format

transactions from the network from somebody what happens then it's a bit murky again we could say that well we just discard it and we don't care about old no I mean we don't care about old no but um yeah possibly that's a cleaner approach to extend we just need to handle this

scenario too

Micah Zoltu: I think someone correct me if I'm wrong on a client team but I think we actually would let would would want e67 to go out before the hard Fork block right like we want people to be talking it so they can transmit new transactions over the network before the fork block actually lands is that

is that correct but if you roll we don't want

our pen imported

Péter Szilágyi: so if you roll it out as E64 sorry e67 then it's completely fine to roll it out whenever the problem is that when the fork arrives you need to stop talking 345 and I don't know g at least doesn't have such a functionality that all of a sudden at a certain block number you stop a networking protocol so it's not uh it things start to become weird so that's why I kind of also see that maybe Martin suggestion of Simply uh baking it into the currently release protocol versions might be less invasive because then you don't don't

need to do these version juggling during one time

Micah Zoltu: if I understand that that proposal correctly it's basically enshrining the under specification that we had previously so so right now the specification just says this is the transaction uh message is just an array of transactions the specification doesn't actually say what those are internally it just there's a r of transactions and so I technically again this is maybe just pedantics but technically the specification as is is what you just described however like you said earlier I don't think anyone actually implemented it that way I think all the clients implemented it as it expects that array to be an array of very specific uh structures

Lightclient: well the thing is I remember we've talked about

this in a prior breakout room and I thought that was the case but you know I don't know if that is actually the case I think that most clients have one representation of a transaction and whenever they try to deserialize something over the wire they use that and so if they then extend that transaction type like we've done it in go ethereum to support two transaction types all of a sudden whenever you read transactions over the wire you're reading both of the transaction types so I don't think that clients have two representations one for wire transactions and one for you know operating transactions and the rest of their infrastructure

so um maybe help me let's let's go back a little bit and help me

understand there's the option of we go to e67 and then stop everything previously or there's this other option that Martin was suggesting that Peter is kind of warming up

too

Artem Vorotnikov: so having upgraded the the uh opening theum Network before from 63 to 64 then to 65 basically the major blocker here really is that h65 uh it's it was a major upgrade to to the networking protocol in that it required a very specific change of behavior from the clients basically the

clients can no longer rely on the transaction propagation on the gossiping but they have to actively pull transactions themselves so this is like the major problem with implem because it's not just an ordinary protocol upgrade like changing the model of the data structure like that or implementing support for new message type it requires actually changing the uh the way transactions you actually have to pull transactions from the network basically you cannot rely on gossiping so like my idea is that we should really split e65 into two parts uh basically retain like

the the new messages uh in e65 but uh still provide for the fact that the clients that ticket 65 they still propagate the protection themselves propagation requirement in8 this way we should make it very easy for everyone else to

upgrade

so just so I understand what uh what clients aren't on to

e65

Rai Sur: we still have a bug in our implementation um so we have not turned on

e65 by default yet etherum does not have h65 yet only it's 64 yeah that's

correct yeah open etherium still needs 65 okay

so then the there's develop there's more development that would need to happen for all clients to get to whatever ends up being 67 if we were to make that choice of implementing all of the stuff and forgetting the rest of it

yeah so

Péter Szilágyi: in that case my suggestion is to just um just use the overloading approach and not roll out a new protocol version because it it doesn't make sense to start rolling out multiple versions hacked in various ways just so that it's easier for clients to roll out I mean overloading it is a bit murky but

it's still a lot simpler than than rolling out three more protocol versions just so everybody can Implement whatever they want

Artem Vorotnikov: um I think that everyone should Implement e67 and then as soon as possible so unblocking the clients is let's say maybe not the best approach from the theoretical perspective it's not the most elegant solution but it's the most most practical and workable one

think is the most which one did you think is most practical one

Artem Vorotnikov: basically it's basically

appes to G is that g will propagate transactions even years with basic if we had that then everyone could just partially Implement its as is and be compatible so open etherum would wouldn't have to to test and to implement immediately the logic to P transactions from from the network it could just it could still rely on

go

Martin Holst Swende: right but so would the just overloading method be as well right was that to Art I mean there yeah

because if I understood AR correctly he's saying that we should roll out 6 to S and then like three more variants so that we can have old style transaction behavior in a more recent uh protocol format uh and what we're saying is that we could just use this ambiguity about what is a transaction um and not roll out new protocol formats and those who have not yet implemented transaction fetching can still can uh wait with that if they want to so I think both ways forward here

means that no one has to implement 65 immediately

um are you agreeing with what Martin saying Thomas

with's your comment one idea but uh just just thought of it and not sure if it will work what we can do is that during the handshake we can specify the protocol version and calization version now it might be very strange so you would say cation version one or f65 cation version two yeah but that was still require

Péter Szilágyi: exact same I mean you would need a new protocol so then you're ending up with

e67 and then

no no no you wouldn't need the 67 or 65 or 66 you could uh connect to 63 old clients and just during the handshake um tell them that you'll be broadcasting things in the

AL

Péter Szilágyi: there's no such thing in handshake how do you tell them

yeah this would require the change of handshakes so e67 um uh no is it yeah close on we're getting kind of

close on time on spending than we than I think we should on this just a heads up

Hudson Jameson: yeah one thing we can do is take the entire thing to a magician thread if someone would volunteer to write up these outstanding issues um and then we can talk about it on there would be one solution because I don't think we're going to figure it out today until we think about it more

uh did anyone have cool but could we can we consider decided then uh the hashing format SL consensus format um as being type and then the blob

Hudson Jameson: it

sounds like yeah that was already consensus roughly wait what were you saying

Péter Szilágyi: yes and no so the problem is that we've kind of decided that we would go with the w format but the problem is that the EIP defines two reps formats and they are interchangeable

is that mic zp or a different one

Micah Zoltu: interchangeable in what way

so in so 2972 as far as I see it it defines a z z type and a z one type I mean a zero and a one type yep Y and it just swaps the signatures

Micah Zoltu: they shouldn't be malleable

between each other it's basically EIP uh 155 or pre- 155 it's like if you were signing pre 155 so you did not include the you're only signing over six Fields then it's type zero if you're signing over nine fields and it's type one we basically already have two transaction signatures correct Because unless you resign you they are not sign signature malleable they are but they are basically sending the same information just one has a chain ID essentially

okay

Péter Szilágyi: then it's perfectly fine I I was just afraid that uh they are somehow interchangeable you can convert between them

Micah Zoltu: uh no that they should not be if if you someone discovers that is the case

please let me know because that's would be a mistake I agree

okay cool thanks

so then is that sufficient Martin for answering your question yep I think so

okay so uh can we repeat the for some for the note taker for the summary what what is the answer or the um yeah the conclusion for that piece

that it will include that the 20 the the the 2718 will include the r format under the the other EIP number 2972 2972 and 2972 will be added to the YOLO V3 list

yeah 2972 is added and then

Micah you said Legacy transactions won't be valid in blocks anymore right

Micah Zoltu: that is my understanding from this discussion uh will update the EIP 2972 to specify that I believe right now it does not specify that explicitly

okay

Hudson Jameson: uh and Mah when you're done updating that if you could let James know just over Discord um so he can update yellow V3 because we don't want to update V3 before you get done with that piece

uh sure sounds good at some point we should probably spend some time and actually look at the serialization format of 2972 because it does some things we've talked about in the past such as the SSD uh additional encoding there and the

uh SS ssz like I believe ssz like encoding and it does have the prepended signature scheme which I know has been a topic of discussion before yeah we

Micah Zoltu: we do need to finish that discussion uh that discussion actually started on 2930 and we need to finish it there as well

okay

Hudson Jameson: um if someone can just that or James or someone in chat can just point to like The Magicians thread that Micah posted uh in the zoom chat and posted in the Discord sometime later today or next week so that we can jump start discussion on that in there would that be a good place

Lightclient: should we have a breakout session for this

topic this might yeah this might be a good one to do that for if we want to get out Berlin out quickly then the faster we can solve this

Péter Szilágyi: yeah I kind of agree on that that this won't be solved by writing on the chat

okay okay we will get that scheduled

Hudson Jameson: sounds good all right so like client uh work with the cat herders on that um I think usually PUO has uh organized some of them before so uh that can work out there um anything else on that that we have hanging out that or that people are concerned about Beyond what's going to happen in the breakout

session okay I think it was good that that discussion happened because it yeah did it's making um it's making things a little more complicated for Berlin but it's important that we get it figured out um so the next thing is final no-o or go for Berlin IPS I don't think we can do that anymore James because we kind of have a lot of stuff in discussion

uh we can say the BLS one is out of Berlin and we can say this one is the 278 plus this the rap transaction formats are they're pretty much just split Out versions of the same EIP so I I think that still we just need to resolve that piece but that's like the

final piece to resolve okay so that's that's almost a no final no go go

okay and after have V yellow well yellow V3 Implement implementing all this in yellow V3 will actually be the if we find a critical thing we can say that's out for Berlin yes okay but do note

Péter Szilágyi: that in order to implement this and launch it the yolow V3 we actually need the networking too otherwise there's no way to actually send

this stuff over yeah that makes sense um I think we can I think we can discuss the

and e65 to e68 in this okay

Hudson Jameson: so the networking piece can that be a sync over text or do people think that needs that that needs to be included in the breakout session

Artem Vorotnikov: uh let's do AC first and if we don't have a solution anything then

we could okay all right

Hudson Jameson: that sounds good all right next up uh we have Network upgrade process update um Pua wrote a blog post that is in progress and that they posted uh in the in the uh aord devs chat to get feedback on it's a in the aore devs

chat there's an ethereum magician link to the contents of the blog post and um pu I think you wanted to go over just some of the high level stuff a lot of the stuff is are things that we have talked about in the core Dev calls previously but have never been codified or written and we've just been kind of flying by the seat of our pants with how we're doing some of these procedures and um stuff like CFI and um YOLO and things like that so pu if you want to go ahead and kind of do an overview and see if people have any comments um and or if we can take them to The Magicians form either one

yeah sure

Pooja Ranjan: so uh I would just like to give a quick summary of whatever the process we are actually following right

now for the Bing upgrade um so there is this document if it is fine I can share my screen to show

the diagram that would be helpful yeah the diagram would be great okay

Pooja Ranjan: so um earlier this year the EIP IP group is started started discussing ways to decouple the process of EIP standardization and network upgrade uh we are in process of documenting these recommended outcomes

that came out of the eipi meeting to uh make it easily available for Community uh we are we will be posting it in a form of blog on ethereum cat herders the part one was the EIP standardization process that has been added to EIP 1 recently uh with the help of this merged PR so people can uh find it here uh the the process is here the part two is the network upgrade process for this a repository is created at 1.0 spec repository so um as we see in this diagram the first stage when a proposal is ready ready by ready I mean that it's a like in review stage or more from the

draft so it and and they intend to get uh included in any for in any future hard for they have to first go ahead and make a request I mean create an issue in the at1 spec. repo that would be considered for inclusion and uh this will be also added to the I mean I'm just going to show how how it would look like so you have to just create CFI applied once it is done that would be added to the project board which is available here and the eips will be listed this uh Network upgrade process is broadly divided into three phases consider inclusion devet and Main

net so once it is um applied for consider for inclusion then it moves on to devet phase CFI approved is the process when it is approved by the uh people here in the cev meetings all these terms are explained in the blog CI dut waiting room is a list of buckets in which proposals are there people are still uh trying to figure out if that should be included in the developers test net for for now we have YOLO test net CI devet active is the list of uh eips which are actually uh being tested uh by different clients testing green light I think James broadly spoke about it in the meeting today and then it comes to

the public test net phase uh that would be P testnet like uh robsten and the final deployment phase that's the uh main net phase there is this recommendation of EIP statuses as per different phases of network upgrade uh though this EIP standardization process is now separate from the network upgrade but we highly recommend that people should be following it uh the places to go for is like for the network upgrade process and list of proposal the best place to go is the F1 spec repository to track the process of any individual proposals we can go to this project board and for question answer yeah James James Hancock is the hardare

coordinator carders uh are also supporting them so you can always reach out to us so that's about the process we have this at Magician Forum if people have any questions that can be answered uh quickly here I'm I'm happy to do that otherwise feel free to leave questions comments

here in this Fellowship of E magici

and something that I'd like to do is move so there there is a list of of the EFI meta EIP and I'd like to move that list into the specs repo and so that it's not just a project tractor but we have like an actual document that tracks the things that are

CFI um and then update the documentation around CFI to include this kind of stuff

okay any other comments from anybody I I wanted to bring it up here before I did those changes so we could agree if it's a good idea or not

Hudson Jameson: sounds like for something like that I think you can just go ahead because otherwise someone would have brought up a something okay cool okay um thanks to axic for being one of the early people

to help try to separate this process and organize it through some meta eips and thanks to Tim Pua and James for uh organizing the post Pua is referring to that will be posted eventually um and Pua for writing the main parts of it

um okay

Hudson Jameson: so if that's done we can go to other eips uh let's hit up account abstraction get an update and uh see where we're at it looks like they're using the process already and if you go to the specs repo you can go into the issues and see that they are already CFI applied um uh for their um CFI their CFI applied and their quest to get fully

CFI so uh go ahead with the update I think who's here from account abstraction

hey I'm here hey Sam okay great

Sam Wilson: hey so um not too much has changed since the last aore Dev meeting on the EIP um we've been um trying to solicit some review um I don't know if you've noticed the post I made in the award devs Discord Channel a little while ago um we were just wondering if anybody had a chance to look at it so far

I started reading it same I'm [Music] here uh D Ry were you going to say anything

else no that's it yeah I start reading

Martin Holst Swende: I've only actually managed to do the single tonel thing and is a lot of U complexities around it so I'm thinking um yeah it's going to take a while to figure out all the coic cases and quirks and potential ways that things can go wrong yeah of course it is no like just going to say that I mean on a high level perspective I have no kind of obvious

objections

Sam Wilson: well that's good to hear um is there any part that you find

particularly complex or

Martin Holst Swende: um no I think there are lots of there might be a bit of lack uh of describing error states and like what happens in certain conditions when um when things don't go according to plan things like that um and it reference also some other e and like set indestructible and I have to read up on set indestructible how does that work what happens if I run a set

indestructible u in the init code or whatever and um yeah there's a lot of complex mechanics um both on the evm level and kind of how would this be used and what are the possible consequences in there to when

this is used um yeah

Sam Wilson: awesome well it's it's great to hear that uh you guys are reading it over and uh we really appreciate it

okay

Hudson Jameson: great uh is that the end of the update

SE uh anco is there anything else you wanted to mention or is that uh uh no

Ansgar Dietrichs: I think I think that's that's basically it maybe question would just be um is there any way we could basically uh actively kind of

um I don't know if there there any like questions in discussion you would want want to have maybe when reading that or where the best what the best Communication channel there there would be or if it just basically once you got through all that or anyone interested gets through all that we can we can continue discussion on one of the next calls or something

Hudson Jameson: yeah um so because uh we're kind heads heads or really heads down in Berlin I don't know if we're going to get into a lot of advanced discussion on it um I know there's a full chat channel on the E uh R&D Discord that people can pop into with their questions and I know that's really helpful um but because this won't be going into Berlin um it will it probably won't have a lot of

advanced discussion I'm guessing till after the holidays but um I mean we can definitely keep putting it on the agenda and getting updates and pieces of feedback I I'm open to other people's suggestions

I I go Martin Sor go ahead sorry

Martin Holst Swende: I was yeah backpedaling here so I I just real remembered that I have one actual practical question about it um which should would be good to be clarified so you are overloading the nons of a contract uh to use it as the kind of the knows for executing this incoming

abstract transaction uh and I'm wondering what if there is a creation being done from this contract um wouldn't that bump the nons as well

or is that allowed or something so

Ansgar Dietrichs: so um we thought about that and so far like uh from our perspective we didn't see an issue with that so indeed the behavior as specified right now would be that the nons increases both if if a transaction an a transaction starts at the contract and once the contract uses create or create to um we thought about like [Music]

um disallowing that or something but but we didn't see any any issue with actually this this tool purpose because the of course the kind of Repair Protection and transaction uniqueness properties would still hold

Martin Holst Swende: um I think you should mention that uh mentioned it somewhere in the E that this is a fact so that the Casual reader can think a bit about it and see if there is some ACT yeah if there might be some consequence

to that

Ansgar Dietrichs: that makes sense maybe then like and and then that would be the last the last thing for Con on this call but like one like connected question that we were actually having is the one corner case we have to protect against is um for the AA contract to to

to self-destruct and then be redeployed and then basically nons also begin at at one again and so then you could actually have the same transaction with the same hash sent again and then be included again with the same transaction hash which would violate transaction hash uniqueness so one of the options we saw were to just inforce something like this set indestructible again that's another independent e the other option was to uh look into maybe changing um self-destruct behavior in into not resetting the nons of a contract but we we just don't have don't don't have the knowledge there if that is something feasible or not so just in case anyone on this call happens to like have any special insight into that because I I do think that back when seu was introduced

or not seu when crate 2 was introduced there was discussion if if that was desired Behavior or not but I'm not sure if that if anyone has like any any thoughts around um if it would be okay to for basically for SE not to reset the nons of a of a contract or if that would have too many side effects or something but if there's no one with any any immediate reaction that's fine as well

Martin Holst Swende: I mean it would uh it would change the semantics of self-destruct in a way that would uh screw with potential like upgrade patterns or whatever so it's obvious it's not obviously a safe thing to

do obviously a dangerous thing but it's not an obvious safe thing to do

yeah absolutely

Ansgar Dietrichs: that makes sense though we definitely had that as like a thing to look into if we were to to to push for that so that's definitely not something yeah that makes sense thanks

okay

Sam Wilson: in about AA um we do have a community call coming up on November 20th uh if you guys want to join the information is on the ethereum cat herders um GitHub

yeah

Hudson Jameson: I think it's at noon Eastern or 1 Eastern yeah it's noon Eastern 5:00 p.m UTC oh and I'm running that call I think

or I'm I think I am

um so there there's also an episode of a peep and EP that the cat H herters did just on this a week or so ago or was it this week well this leeks feels really long yes uh the the

Pooja Ranjan: episode will be released on Monday we will share the link publicly on Monday okay and also the detailed information about the community call uh and blog post will be published on Monday providing the information how people can join that Community

guard great

Hudson Jameson: I think that's wrapping up just about account abstraction unless axac you said you had something

Alex Beregszaszi: yeah I'm trying to I'm trying to say something regarding the the

replay protection um so as you mentioned that that's like a crucial thing which has to be um fixed before AA is is considered and there is an EIP for the as you mentioned the setting that's tractable and there was another EIP for removing self-destruct um and that was I think proposed by Alexa but it didn't it wasn't even merch as a tra because he he abandoned it um but I don't think the the setting destructible is championed too much um so maybe Simon ancar if you if you if this is a prerequisite for for AA um maybe you could consider championing one of

those two um options

and so

Ansgar Dietrichs: just for clarification I think at least the set indestructible actually came out of uh this consideration so so I think that that was created by vitalic as part of our um work prior to releasing the AA um EIP so so I think so basically if if a were to to move forward that that would definitely be Al yeah be be part of that and then we would also change Champion that one as well and I think there were some people in the community just asking for the set indestructible to maybe be championed even in the case that a would not be considered just because it might also just be a nice thing to to have to be able to to um basically um create indestructible

contracts

optionally yeah

Alex Beregszaszi: I wonder the the other EIP which just removes self-destruct all together um I'm not sure why it was abandoned um but it would be interesting to see because this self-destruct has been like a such a mess

since it was headed

Lightclient: I think that was Alexy but I think that he just decided that he didn't want to pursue it any further

Ansgar Dietrichs: I think it's like one of these things like ESS where it's it would probably be nice to have but it might break so many things existing things that it might just be too too too big of a change to to push for that's that's just my opinion though um but yeah I I do I do think like looking back would

have been better to never introduce

SRU

Alex Beregszaszi: but yeah if you if you do have the time I would encourage you guys to maybe look a bit more into that and um I personally would be happy to see

uh s distract to beun okay

Hudson Jameson: thanks everybody um I think um the next thing we're going to do we'll have one minute on EIP 2666 because it's just a really short update and then I want to skip to the GU bug and responsible dis de Clos disclosure discussion from gu um because we've had a lot of previous meetings about bls2 381 and um there is in the agenda a link to an explainer on uh the the I guess comparison between evm 384 and BLS uh

12381 from um Alex vov it's the second comment down it's a pretty good explainer um as far as like content wise I was able to understand um why teams need it and stuff like that this this pre-compile curve or whatever we end up putting in um so definitely check that out and then Alex if you want to talk about 2666 real quick before we go into gu's discussion

Alex Vlasov: uh yeah well basically it was just cleaned up and merged um it's now even in a smaller scope after improved inversion was merged into gas to so we can eliminate repr pricing of uh BN addition and multiplication promiles so

just basically three changes of the constants for shat 56 ripen B 160 uh pre compiles and kak or shry of code very simple ones just the constants um numbers are based on what clients has provided as a benchmarks uh it's just like low hanging fruit uh to implement and uh give some extra performance um and also kind of ensures that resources which are paid for are actually like like that you actually P pay for resources which were actually spent

okay

Hudson Jameson: thanks for the update uh if anyone has questions just reach out on

Discord to Alex and again check out the explainer um if anyone has any comments or rebuttal to that explainer um post about them in the Discord in the allord devs chat uh and we will continue the discussion there um so for the last six minutes let's have gu go over kind of what happened the other day uh where part of the network went offline uh due to a bug that was revealed in a few blog posts the other day uh Martin or Peter if you want to go ahead

Péter Szilágyi: sure so um before I dive into that uh I just wanted to give a quick heads up here too that yesterday so about two weeks ago we found um pretty serious

issue in go and reported it upstream and for the past about two weeks we were going back and forth with Google on getting that fixed and uh essentially that was fixed and released yesterday uh in two security releases for Upstream go and uh we also did a release ourselves yesterday mostly to to rebuild um all our releases Docker Launchpad Etc with go5 115.5 I just wanted to to highlight it here too that uh this is actually an important release because it can be used without it uh G noes can be taken offline remotely I won't go into the

details on exactly how currently I can do that maybe in two weeks or four weeks or whatever when a decent chunk of the network is actually upgraded so anyone running g notes please make sure you running with go 115.5 okay so with that out of the essentially just a quick recap of what happened I think two days ago in the morning uh essentially there was um a block appeared in the network which uh did a small um chain split uh within etherum mayet uh now it was a bit unusual in that you didn't do the chain split across different clients rather

the chain spit was only between older versions of G and the rest of the network plus newer version of G so new versions of G and the rest of the network were on the correct chain and old GS dropped off and essentially what happened is that um about one year ago uh we did some optimizations which uh which introduced a consensus bug and that consensus bug was dormant in our codebase for I don't know seven months or even more or eight months or something and somebody reported on The Bu bound to list that they found this consensus bug and we patched and uh silently released a hot fix for it of course this also meant that uh um all of

a sudden since we changed the consensus we fixed the consensus bugs old versions of G and new versions of G were not compatible with each other even a specifically crafted aack transaction and U usually we've did this a couple times previously too uh just as a disclosure and usually what we do whenever we discover one of these bugs is that that uh we try to evaluate them what their impact is and what the probability of actually hitting them and in this particular case the probability of somebody accidentally hitting this block meaning that people just using ethereum and just hitting this bug is more or less impossible so unless you very explicitly found the bug and very

explicitly crafted an attack transaction there was no way to to abuse this and because of that we've decided that it's better to to silently roll out the fix and just get the network to eventually eject old nodes than to to raise awareness to it and um and yeah and uh and have a potential attack so the thing here to know is that it's essentially a oneliner fix so if you announce that hey we have it's a consensus issue this is a consensus release and here's the one liner fixed then that's a fairly large Target that's why we try to avoid it um in general I'm kind of feel it that this was the correct approach to take the

problematic part which I I agree was that um even though I don't think we should have announced it during the release so I think it was the correct choice to keep it hidden uh people on the internet are right that retrospectively um we should have made a actually really strong suggestion that there was something wrong in a previous release and people should be on the new releases now since we didn't do that a few people uh and projects were using old stable releases and since INF was one of them um yeah that kind of blew up in our

faces so that was kind of the issue um as for we've uh in the past couple days we've have been talking about this on and off on essentially what better way we could have handled it and as I said I I'm still convinced that uh it's not um you can't just unilaterally say that hey here's a consensus bug this is a consensus release everybody upgrade now you have five minutes because that would be extremely strain full I mean people cannot we cannot expect people to be in front of their computers so one possible solution that we were thinking about it will put a bit more strain on people but maybe that's the correct

solution anyway is to still I mean this is something a fluid so I mean we're open for suggestions and input but the idea would be that U uh we retain the right to to silently fix issues but uh we try to commit to for example if we do such a such a fix in the future then let's say we release it at one at certain date and then we could commit to uh reveal feeling maybe a month later that one specific release was a consensus contained a critical consensus fix so that anybody not upgrading within the last month they would have a somehow an

emergency notification that you might want to release it sorry upgrade it and then maybe after one additional month we could also simply say that okay this was the bug and at that point if anybody didn't upgrade then that's probably going to blow up so we this is the the best thing that we've could come up with that we could do but it does so people the one of the reason so people were kind of really angry at us that we didn't admit that there was a consensus issue and what the consensus issue was uh we are open to to disclosing these issues but uh what everybody needs to be aware of is

that these disclosure will act as so to say barriers so every time we do one of these disclosures that is an active risk for the network and for anybody who didn't upgrade so that's essentially that's the Dilemma

okay

Hudson Jameson: so we're a little over time but I do want to have people chime in on this especially James prestwich who actually added this uh in part to the agenda I think you're here James right

James Prestwich: hey how's it going hey um so uh I uh respect the amount of work that has gone into this especially like this week with two major issues uh coming out of the guest team um I think

that the uh you know the interesting thing about this bug uh that caused a consensus failure is that it was found by a downstream team uh and who decided to go and test it on mainnet uh the optimism team discovered this specifically and tested this because uh they were using a stable gu release as the base for the ovm and were not notified of the consensus issue privately uh typically in open- Source software there is a uh disclosure policy that is a specific document that says who will be notified privately how and when on a uh you know discovery of a severe vulnerability like this and I

think Downstream projects like BM like cell and like other people based on gu uh should be pretty high up that list um because we tend to use older stable releases rather than newer uh cuttingedge things to minimize our engineering overhead uh early notification of Downstream projects would have pre prevented this specific instance of uh consensus failure and early notifications of major stakeholders like infrastructure providers would have mitigated the impact I'm not saying that we should go go ahead

Martin Holst Swende: I think it's just I just totally do not agree because you're saying it

like if we had notified Downstream then it would we would have avoided it and I mean if are the ones who exploited this particular instance it kind of shows uh yeah I'm not I don't agree with that reasoning

James Prestwich: um so Downstream notified me on uh Tuesday night uh and I gave them a tear down of the bug and what it would do but that wasn't communicated to all of the engineers um and so another you know person who did not have this knowledge was testing to see what would happen um if the knowledge of the bug

and how it worked was communicated to him this likely would not have happened uh but I I don't want to get into like the specifics of this kind a weird circumstance right now uh you know my overall point is that it's common to have a disclosure policy that says you know based on risk and based on responsibility who gets notified in what order

Péter Szilágyi: yeah so the so the problem here is that for example um this in theory sounds nice but in practice um okay let's suppose I'm going to say that okay I'm going to notify infura and I'm going to notify uh I don't know one of the mining pools then all of a sudden people

will get angry kind of quick Noe and alchemy that I didn't notify them so okay I will add them to the list too then cello and OBM and whatever will get angry that I didn't notify them okay I will add them to the to the pool then uh three other smaller mining pools will get angry that it's not fair so I will add them too and eventually I will notify 100 projects and and I might as well publish all the details because at that point it's so many people know about the consentant issue that it's what's the point of even keeping it private anymore so the problem here is I think that there's if I notify U let's say I have three mining pools or I have I notify 10

mining pools then actually there is an incentive for one mining pool to to produce a block that breaks consensus simply because they will have have the next 100 blocks or or something so how can you control it once the details are out how can you how can you see if there's somebody actually abuses it what do you do how do you avoid that

James Prestwich: yeah I you know definitely agree that there's a lot of like judgment that the GU team has to exercise here about who gets disclosed to and when and who can uh you know use this information responsibly into as unlikely

to uh but you know the impact of these issues on other people is very large and could be mitigated by early disclosure to people that you believe can responsibly handle the information

yeah

Péter Szilágyi: but in that case we will still have some backlash from the people who didn't know about

is

James Prestwich: yeah um I think that you are likely to have backlash regardless unfortunately uh and that really does suck because you guys put in a lot of work uh in order to keep things stable uh I I don't think that avoiding

backlash should be a significant motivation in uh security policy

so our

Martin Holst Swende: whatever we do I mean the the SEC the basis for our security policy has got to be towards the Main and everything else is secondary so that's like number one uh I do I mean we could have some kind of Downstream agreement but we wouldn't

Tomasz Stańczak: I don't think there was any better solution than what you've done at G I mean we can improve the notification like how how the bags are reported so we can advertise security at ethereum.org

and tell everyone if you notice something risky send it over there so it can be try imediately and fixed silently it's almost like just just come back to the back Bounty program from the past and people stopped using it because they assumed that everything will be stable um there is a difference between what the actual situation is and what people claim it is I mean there was lots of people who are just complaining because they use it as an opportunity to make you feel worse even as most likely this was the best solution fix it silently and then slowly wait and observe and see if everyone is switching maybe maybe paying more attention all of us that like who is on a very old version and

and just suggesting it very delicately that they should have upgraded recently because there were some very important I don't know performance changes or whatever when it will be harder now

but it's not can you versions

Alex Vlasov: which have valid and everything else you call duplicated and say we don't guarantee anything like the standard way uh I mean you you cannot obviously you cannot force someone to upgrade but at least if you if you like publish such policy on the front page well most likely people will pay attention

James Prestwich: uh so uh earlier in this call you know

we had a very nice polite uh a security patch dropped and you should go and upgrade your nodes uh I'm not asking for any more information than that in early disclosure uh but you know that amount of notification would have to infura two months ago would have prevented most of the impact of this specific consensus failure uh or that amount of uh disclosure to optimism would have prevented the specific consensus failure

Tomasz Stańczak: there's also a chance it would move it two months forward I mean if if that's what happen I would I would say if the team does test and exploit one

main not and it actually warns you against disclosure of those Downstream I mean this is OS respon irresponsibility to do something like that

James Prestwich: uh it is extremely irresponsible to do something like that and it should inform disclosure to that team in the future but not uh to the general it should not affect the general idea of Downstream disclosure

maybe here would be for

so the it it sounds like there's an amorphus list of what of who would want to know at different levels of detail these kind of security things maybe if

those people got together and said we want to be on this list it might be easier to talk about it

Péter Szilágyi: well um that's one of the problems that if it's a list that is maintained externally then it will probably be the most horrible list because everybody will be on it who shouldn't be on it

James Prestwich: right I definitely agree is that the GU team should uh is qualified to choose you know like who is trustworthy to handle information like this

James Hancock: yeah but people could signal that they want to and not have the GU team have to figure it out like like them them having the like be able to choose but not having to make the list like it it might not be

as yeah don't

Hudson Jameson: not putting the burtom on the

GU team but at the same time having it available to them of people who are interested whe if they do decide to in certain circumstances that might not be as dire as the bug that just happened but in certain circumstances say hey update

Péter Szilágyi: so um just a quick memo um which people are going to hate me for this uh people I think in general the etherum community is not really aware of how serious updates are so uh over the past we've been releasing I don't know we did about 200 gu releases give or take I have no idea how many I am fairly certain that a lot of them are super serious in that

they maybe this one fix a network where you can crash the other one fix um fixes um a memory leak where if again if you know how to crash it you can crash it so generally all of these fixes every time we fix some bugs a lot of them can be exploited maybe it's super hard maybe it's super convoluted but they if you really want to they may be able to be exploited and uh now either our code is super which I doubt or my guess is that the same thing holds through for other clients too in that um well when you are fixing bugs those bugs have some effects and the effects can be pretty bad

so you kind of people kind of need to be aware of that the updates are useful

and I

James Prestwich: I think what I'm looking for is a communication Channel where people can uh opt into becoming aware of that much more quickly uh a lot of people running infrastructure prefer to stay on older nodes to avoid new instability bugs uh so I spent a lot of time on the phone yesterday with infrastructure providers like four different companies running significant amount of nodes ensuring that they update to the new goang version uh they were largely unaware of the

severity uh of that issue um and were uniformly on older nodes uh so I think like some sort of Communication channel where you can you know tell these people that upgrading is important directly uh would help a lot with that

Hudson Jameson: well the cat H herters have a list of so in the event of an emergency or a hard fork or something that has to happen very quickly that's very public we've used a list of exchanges uh Miners and infrastructure providers to reach out to them to make sure they up grade so we could have that list be the same list for any client not just gu who

would want to reach out just you know poke the cat herters and say hey can you send this out to you know these subgroups of people whether it being miners or exchanges or stakers or whoever and um let them know is that kind of what you're looking for James in a way at least like part of partly

James Prestwich: uh was that list activated on Wednesday or Thursday this week

Hudson Jameson: no because um we were not we don't have that system in place right now to be poked for that unless there's a very public like this this has this like H needs to happen right now to upgrade your node otherwise the Network's going

down kind of a thing

James Prestwich: um so if it wasn't activated on Wednesday or Thursday this week I don't think that it meets our needs

okay

Hudson Jameson: so we I mean we're still going to have that list especially for eth 2 stuff coming up um where it comes to like exchanges and stuff not knowing about um when or actually not even eth 2 eth one also where if exchanges need to know about an upgrade coming up we use that list for even longer term like this is coming up a couple months from now or have you updated yet and stuff like that so we're still going to use the list but I understand your perspective that it might have not helped on

Wednesday

Martin Holst Swende: so just to to clarify a bit so in this for the critical fix we did do an announcement a couple of days before and that went out on Reddit Discord Twitter uh and this is an old Skype group with a lot of exchanges in it and then the message was repeated um when we actually had made the new release if there are if we have if there are other channels where we should do announcements or sound the the the alarms yeah that of course that would be good

it's a good

Péter Szilágyi: thing to note that for

example yesterday's release that was not directed by us that was um scheduled by Google and uh essentially that's I mean that was our part of the responsible disclosure in that we cannot take the lid off it faster because that issue affected an insane amount of infrastructure over the internet not just ethereum and yeah definitely and um the moment they gave us a public day I mean the moment they actually announced that there's a security release coming that we also try to maybe we announced it half a day later that we are going to do a a g security release it was a bit weird that um

this is kind of overlapped with the concerns issue so that made things a bit funky

yeah that is a unfortunate synchronicity

Hudson Jameson: so just to wrap this up so we can all go there any final uh comments on this I mean this conversation was more to have a conversation about it and to get word from gu about how their policy works today and how they've kind of thought it over since getting feedback from the community um and so we've accomplished that are there any final words

I

James Hancock: I have one thought so if if G did their suggestion of they like a month later or two months later said that this was a security release make sure you do

it and there was like a way to publish to a way to subscribe to that message being published does that like fit in kind of the middle of what works for you James like so there could be so you could subscribe to that list so you you might not have gotten the date zero because it wasn't determined to be significant enough for that but you would have found out way earlier

James Prestwich: yeah uh it would be helpful um you know we're in somewhat the unfortunate position of having to coordinate validator upgrades when issues like this happen uh which can take a significant amount of time um but any amount of like uh notice

that a security release happened would be very helpful

okay cool

Hudson Jameson: anybody else have final comments

Micah Zoltu: I have I have a one sentence thing for people to chew on if you don't mind sure um just keep in mind that any sort of private list that we create creates a competitive Advantage for large actors in the ecosystem and disadvantages small actors who can't get onto that list because there's a competitive advantage to being more less likely to crash in a consensus failure than someone else and so any private list that we create that people can get into we just need to be careful of that like we do not want that because that increases centralization or

has potential too I should say

yeah and it's one thing you add just related that the wor noting INF fura

Tim Beiko: also mentioned this in their postmortem blog post so you know they seem to agree that they shouldn't get the preferential treatment over whatever the community gets

Hudson Jameson: oh yeah that's a really good thought I think that that should shape some of what the cat H herters do including having that list even if we the list needs to be either public semi-public or only used in situations where they're warning about an upcoming Fork that's happening like a planned Fork so it's more an not an alert system for emergencies but more of a

notification system for for times that things need to happen that are very public and that you might not hear about

yeah like a pub notification system yeah that's coordinated a little bit yeah something like that

Péter Szilágyi: well this was kind of the reason why we were trying to to go the path of um just doing for example if we do uh a silent fix and doing a public announcement some time later that this was a pilot a private fix or a silent fix but the idea of this opposed to reaching out individual projects was specifically so that we don't end up in this weird situation where essentially the reason people use

infura is because they are surely not crashing because they have The Insider information not to crash and I mean it's definitely really horrible if in if INF crashes but uh but yes it is also unfair that uh that the small operator who's not in fura but in fura 2 they they have no chance of competing on this front it's I don't know so essentially yes we're I I would say is we're open to suggestions we agree that um we could have handled this a lot better and we should have warned people nudged people more aggressively towards upgrading so that's something we need to work on but uh we're kind of open to suggestions on

how to do that fairly in in a way that it's it's open to people without cre creating a possibility for abuse

okay

Hudson Jameson: thanks Peter um and thanks the team for you know working through all this and getting the fix out quickly and coordinating all this I I know a ton of people at least privately and publicly have said that y'all y'all are heroes for that so keeping the network up is always a good thing um thanks everybody for coming we are well over time so the next meeting is November 27th uh 1400 UTC and um again if Daylight Savings Time change so that is an hour previous

and a lot lot of places to where it has been the past months so take note of that thanks everyone for coming have a good day

thank you cheers you bye [Music] [Music]

h [Music] [Music] J [Music] [Music] [Music]

h [Applause]

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