All Core Devs - Execution #130

Transcript

foreign [Music] foreign

[Music] [Music] thank you

foreign [Music] [Music] [Music] foreign

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

[Music] Jesus [Music] foreign

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

[Music] foreign [Music]

[Music] foreign foreign [Music] foreign

[Music] [Music] welcome to awkward as 1 30. um basically a bunch of merged stuff to discuss today along with uh some some discussions on a couple eips for Shanghai potentially

Tim Beiko: um

first on the merge stuff uh Mikhail I saw you proposed a change to the engine API based on some of the reorg issues we've been seeing on kinsugi do you maybe want to take a minute or two to kind of describe the kind of the issue that that led to this this PR and what you're proposing to change

Mikhail Kalinin: sure um thanks Tim so this is the change that have been that the changes that have been discussed recently um on it's on the umstick various call and uh previously in the Discord uh yeah let me just go briefly through uh the

set of changes um and probably we can discuss either offline or address some hot questions uh right right now first of all the execute payload previously had two semantics which is uh the semantics which is a sinking if there is not enough data for executing a payload and validating it and getting back to the consensus to their client uh with the the meaningful response and the execution schematics and in the case if there is enough data the execution semantics was kind of mandatory so this change reverses to remove this requirement District requirement on

executing the payloads so um the execution where a client may just keep Cash Store or whatever else do whatever else with the payload um and not executed um mainly this and yeah mainly this is to address the case when the payload is coming from a site work um which is which is not which is like missing data for the payload to be executed or the client according to its implementation doesn't execute payloads on the site Works unless they become economical uh chain

blocks so it's it it just doesn't require to execute it anymore also the pork Choice updated now becomes uh aware of execution and if that need be if that need the according to the client implementation um it may execute and validate payload before update in the future state so that's like a major change in in this set of changes um also we have an accepted status for execute payload by the way execute payload is renamed to Newbury law to um to make it more sound with respect to

uh removing this execution semantics from with respect to making it optional um yeah accepted status for which may be returned to new payload uh would mean that a payload is accepted the block hash is valid uh but uh the execution like line doesn't isn't going to do anything with this it it isn't going to initiate either a sitting process or uh execute this payload so that's the new status that we have in response um by the way uh now um now this uh

this change requires to have the log hash validation stated exquisitely and the new payload method so it will all cash must be validated disregarding the state of the software because it doesn't need any additional data except for the payload and um the constants from the eip3675 also there is one change that is required by the optimistic sync and if the payload is from the canonical chain but execution their client and making

catching up with some side work let's assume in this case and there is a new payload the child of the current head of the chain um is coming from the consensus client execution the client must validate it and respond accordingly um and not response syncing so we have the syncing process on the side branch but the software can still verify the payload and if nautical chain and it is currently stated in this way that it must um validate on the payload in this case this is required by the optimistic sync to avoid um to avoid a node to turn optimistic for no reason yeah

it's some additional stuff there so there is the payload validation process section and student process section that gives an option of the execution process how it looks like and this reference from the vultures updated method from new preload added now um and yes there is a sync process section that just gives a brief description of what scene process is yeah and this basically this does not introduce like huge change to the El client software and it's uh the main purpose of this is to reflect the current state of the art of the logic of different clients and support logical different

clients how they often do they run the execution and the how do they maintain Forex and the payloads from different works but what's it really [Music] but the complexity on the client side might be increased because zero client will need to learn how to handle different statuses and different and the different semantics on on the punctuous updated method so it may return sync in May return it may run execution it may uh do nothing so and yeah engage clients from the both sides of the stack to take a look at

this PR and comments out that's pretty much it with respect to this PR I

control the link uh Lucas you had a question and

Łukasz Rozmej: yes so if the execution isn't mandatory then we don't validate state route right what would happen could this be a potential issue

Mikhail Kalinin: yeah yeah that's it yeah it's like it's not just executions it's called validation so you don't validate the state route but uh the potential is here here is

that if right uh the cavity is that you must if if you receive book Choice updated and is about that head to some block it must be validated it must be deemed well so you must run this validation process at some point so you may uh on on the new payload images or this block but then you receive the boxes updated and you you must validate it before you update the voucher state

Łukasz Rozmej: okay so it complicates the consensus layer right because they might think

block is fine and that when they try to set it as happening they know that okay this is not fine

Mikhail Kalinin: yeah they will have to follow what yeah uh yeah the example is like new by Lord returns accepted so it's okay in terms of block hash it's the payload feels correctly in the block hash is valid but and since it's their client doesn't have any information with respect to validity and it doesn't have any information with respect to whether anything is required like whether the scene process is required to motivate this payload and then you and and then it sends voctures update attempts where it's for the

response and the response might be valid which would mean that the payload has been executed has been validated and it's valid and

uh yeah the factory state has been like set to is has been updated according

Tomasz Stańczak: so does it mean now that the entire voting process attestation process some consensus layer happens on a block that is uh not known to anyone involting whether it's correct or not

Mikhail Kalinin: no it does not mean that uh the optimistic things to access that until the consensus layer client receives the ballot status for the

payload it doesn't matter which uh whether it's in New payloads Or vouchers updated response to this status um but until it's received if if uh yeah until it's received and if economical chain um if it had a canonical chain hasn't been yet validated so it's it hasn't been sent for the canonical chain had then then the you know turns optimistic it applies the consensus layer block optimistically without verifying the the validity of the Baylor Autumn execution payload and in this case all their

client stops um a testing and proposing the book and and then in the case when the voucher is updated induces the validation process in some in some edge cases it might be the case it might turn the node optimistic if for example real work happens to to the fork which is more than one block lens and in this case the software response was sinking because it has to like execute multiple payloads and so forth so yes there are implications and most of these implications are

foreign [Music] um I'll do it later [Music] what would happen then kind of wouldn't it mean that the cl level would have to attest optimistically

Mikhail Kalinin: um no it must not test it domestically

so if it happens with economical change so it will turn into optimistic mode and we'll wait for execution there to to make those validations

Martin Holst Swende: and what triggers it will triggers execution layer to make those

validations [Music] um it's now like up to the execution layer it may be triggered upon receiving new new payload or Focus updated

Martin Holst Swende: right but if if it doesn't trigger on new pedal because it's optional

Mikhail Kalinin: yeah so

yeah it's and these uh change purpose like if this changes are replied uh that could be the case when neither new payload nor Publishers updated um have triggered the execution so it may it might be the case yeah then serial client will stay in limbo Forever Until um until it's like results or if if it can't be resolved I mean um if uh this optionality is to give uh execution their clients um the flexibility in terms of the design

Martin Holst Swende: right but but doesn't it lead so if it

says that we should validate the payload if we can then we can all make the implementation decision that uh yeah we'd rather not we'd rather wait a bit because that's easier

Mikhail Kalinin: right

we do may do this so she wouldn't be better if the decline software must validate the payload if requested data preparation is locally available right

Mikhail Kalinin: um yeah I see so it must validate we can do this I guess we can do this for the canonical chain for if this is like the child of the head of economical chain I mean if uh we require well date every payload disregarding whether it's from

the side chain or from the canonical one we make the spec too strict for the for uh the clients that does not execute

Martin Holst Swende: um you shouldn't leave it as a like implementation choice if you want to validate it or not when you can

Mikhail Kalinin: um oh yeah that's that's a good point I think it should be in this pack so uh will it be good to say that it may skip a lot validation if it's not on the canonical chain but it must validate if it's the economical shame what do you think about it

um I I can't

Martin Holst Swende: I don't know off the top of my head and probably better

yeah it's fine for Aragon

Mikhail Kalinin: cool okay

how does that

Micah Zoltu: how does the execution layer know whether it's canonical chain or not is that part of the request from the consensus client I think the parent hash will be matching the current canonical chain or like you know yeah so so um so if the latest had the execution layer has matches the parent hash of the incoming payload then it's considered

canonical chain and the execution layer is expected to execute it and if the internet doesn't match then the execution layer is not expected to execute that accurate

Mikhail Kalinin: um it may not execute it doesn't mean that it's not expected yeah yeah it's not expected there's no expectation

all right

Micah Zoltu: um so should when it receives a new payload that is not part of the canonical chain should it how does it know to when the appropriate time to switch canonical changes we don't want the execution client to just be stuck always thinking you know forever I'm waiting for the next block above my

current head and just never receives it because the chain fort and went down a different

path

Mikhail Kalinin: um then you will receive the focus updated that switches you to and using okay and you will have to execute all the payloads from this side chain if they haven't been executed yet before updating the

purchase date gotcha okay

Tomasz Stańczak: so this would sound very similar to the current implementations of proof of work I think at least that amount so what we do is whenever we receive a block it will be on top then we execute it validate it and received something on the side chain then we only start

executing the entire chain of side blocks if the total difficulty becomes higher which means this is like forecast updated situation um so this would be fine I believe without further

analysis

Tim Beiko: so in terms of next steps here obviously there's the small change we just

discussed um is it realistic that by like the consensus layer call next Thursday we can have a PR that's like every client team has reviewed and we've either already merged or are ready to merge um so that we can then kind of get to implementing the change uh across across the clients I guess another way to phrase is does anyone feel like you know the next four days next week is not enough time for them to probably review and think through the implications of this or is this pretty straightforward

and um

yeah

Péter Szilágyi: I think the suggested changes are almost the mostly relaxing stuff so wondering if a client doesn't do anything I think they might still be

spank correct

Tim Beiko: got it right okay so I guess in terms of next steps just uh probably because I'll just doing the clarification around like the canonical versus non-canonical chain um and then making sure that you know we get people to review it and but then we can assume that this General behavior is going to be uh going to be the actual spec I guess the one thing that clients

probably do all need to do is the renaming um but that's

that's pretty small foreign [Music] would be nice to have some some hype tests for it so that uh I guess it's going to be that it's every kind can decide exactly how they want to operate but I think it would be nice to have test Suites for for the weird cases

so that yeah at least clients know what their client I mean I understand what their client is doing in certain yeah that

Tim Beiko: that makes sense um I'll reach out to the folks working on the hive testing anything else on this PR

Ok

Tim Beiko: Okay uh next on the agenda um is a proposal by Martin Around the authentication for the engine API and

the consensus layer node um this seems like the last kind of feature that we we haven't implemented yet there was already some conversation on on the issue this week but Martin do you maybe want to take like a minute to kind of describe your proposal here

Martin Holst Swende: yes okay one minute um one thing not mentioned here is uh that this would be on a new Port so we would have the next court after the one we're using already on that board would be the engine API and the other API because CL needs to be talked both of them uh we want some authentication on that mainly to prevent that someone just exposes their node to the Internet so it

happens very often on manual today um but the consequences could be worse with the engine API um the authentication we discussed in Greece where we discussed several one of them was JWT which is that we in the HTTP headers some token which is signed with a key that is shared with the El and the CL um um other I mean we couldn't do other variations as well um JWT is one of the options um they don't want a strong opinions about this um yeah please write them on the tickets

[Music] I don't think we're married to the JWT it just seems like the thing we could use um the design as I said is for just not any random stranger or web page being able to interact with it it's not designed to be super robust in like hostile environments where people can snip your network traffic or whatever um yeah I don't know what else to say I guess my minutes up

Tim Beiko: I guess does anyone have thoughts comments about this

Micah Zoltu: I'm generally a fan but just to play

Devil's Advocate very briefly um the HTTP and websocket have headers but things like IPC do not have headers are we I'm pretty confident we're gonna stick with it you end up websockets for the foreseeable future and that's not an issue

Martin Holst Swende: so the idea is to yeah that we would consider IPC and the actual web socket um connection to be already authenticated um because the JWT for the websocket that is handled during the handshake and there is no JWT token passing during the actual websocket communication so it's only for for a continuous HTTP

dialog that we continuously and generate and validate JWT tokens sure

Micah Zoltu: so you're relying on the TCP connection beam or whatever um that's underneath to be stable and secured in some way

Mikhail Kalinin: I just wanted to say that this proposal looks so reasonable to me and uh um it's like the minimal stuff to my observation that we um like can do and to get the desired results so um Martin what do you think about like

submission IPR and continue the conversation

there sounds like

Martin Holst Swende: yeah unless someone opposed to this and has other ideas here um but yeah it's the best next step I guess sure

Tim Beiko: yeah it makes sense to submit the pr and I think also maybe get uh this in front of the consensus layer teams uh just looking at the conversation I guess it doesn't seem like any of them have have engaged and obviously there's this they're not on this call so I think once we have a PR just kind of sharing it uh in the consensus Dev channel so that they're aware it can give feedback

and

Micah Zoltu: I do have one other question after

reading through the comments um so it sounds like the plan is do you like boot up your execution client and it would print out a key and then go over to your consensus client and start looking to the client with that key um it seems like there's value in allowing the user to generate the key

Martin Holst Swende: so I think you missed the last part of the first comment versus key distribution the El and clients must accept the Clio config parameter JWT secrets

ah okay yeah which is exactly I'm not sure seeking cool

Tim Beiko: anything else on this

[Music] internally but uh am I right to assume that there is no encryption involved here um kind of right yes there

Martin Holst Swende: yeah you are right there is no encryption per se aside from generating signatures but the data that is passed on jwd is not encrypted to work another way oh wait so jwp generates the interest local messages uh it generates signatures for the JWT message that was passed which in this

case will um only be Acclaim which is the IAT claim issued app claim so the JWT will contain adjacent struct that contains information about when it was generated and that is just so we don't so we have some basic non-replayability um but we won't sign the entire Json payload sends in the as the as the engine

code

one thing for me

um the good thing you're mentioning that it will be this IIT when it was generated because I think without it we would be very very vulnerable to uh yeah like someone's spoofing uh this uh message

right and we're playing it yes and yes again impersonating right right uh so in some

Martin Holst Swende: in some sense if you if we have the if you want to protect against the attack Vector that someone can read your traffic uh then maybe we should do something more robust

yeah like randomly generate this right

yeah I mean then

Martin Holst Swende: we might not even want to use symmetric Keys we might yeah we want to might want to assign the payloads um in generally be more do something else

yeah it

Péter Szilágyi: can't we just use a PLS let me just use https for the whole thing with

South Side stuff yeah both of both sides so yes you could take a easy driver you can do a shared secret so it's it's fine

and what you could do is derive a server key if your eyes so essentially you would take the same this in your case you have this Vector key which was shared and you could just share this and just generate both sides of the keys and just cross or navigate the two clients with each other but that's not really the problem we want to avoid

Martin Holst Swende: yeah we could definitely do that um sure um so I don't know that might be problematic if you want to host your El

client behind an actual SSL Terminator or then you'd have SSL or SSL or something like that but otherwise

it's yeah sure I think that

Micah Zoltu: um having played a little bit with both uh implementing JWT stuff is very very simple um whereas implementing TLS is very complicated and the nice thing about doing something like JWT thing is you can just throw TLS like a reverse proxy on the machine and you're done like basically anyone at the infrastructure level can add TLS pretty easily and the JWT part gives you that like shared secret functionality and then if someone

wants to actually encrypt the traffic um it's generally a solved problem in the operational space like I don't think the clients need to solve that problem

Martin Holst Swende: uh yeah in general also uh it's I think it would be easier to use an existing um tool like for example curl or or maybe even even using the browser to interact and use web jwc tokens but if you also need to add client certificates

[Music] um it might be probably more problematic but I I can I I don't know I'm open to either suggestion really

um so personally I was I think about Michael who said

Péter Szilágyi: um it's safer to leave the SSL to some other infrastructure I kind of plan to agree with that because we have a lot of kinds of moving components SSL is not hard to important I mean I guess most modern languages have a proper Library just follow a few functions so that one should really be an issue still I can accept that maybe

using some other wrappers or other infrastructure base could be easier or more I mean everybody would get a positive together how they want however what I wanted to mention is that from a security perspective I think it's important to emphasize that if you are posting your clients on different machines so if you are actually legitimately going over the network and without encryption that's in my opinion a very dangerous place to be so I'm not sure that for example if you have I know I I would be I really wouldn't condone using non-encrypted network

connections Over The Line

I mean

Martin Holst Swende: I think in practice most of these are going to be sitting inside um closed off Network um partitioning the CL and the year along the same place we bought the same machine

yeah yeah I I get I'm just saying that if yeah well anyway I don't really want to hold this discussion up I think I'll just read up a bit on on the proposal featuring Beauty positive stuff and then

Péter Szilágyi: maybe if I had something really bad that I want to say that I can just

bring it up again it should be fine and just in the internal a little bit afraid of knowledge of this stuff because people if you if you can misuse it people don't misuse it even though you really

haven't wanted

Martin Holst Swende: yeah definitely

Tim Beiko: anything else on the Authentication

Martin Holst Swende: not from my side

okay

we discussed offline yeah um and

Tim Beiko: yeah I guess that's also something that we can hopefully have resolved in by the the consensus layer call next week um cool uh next up uh we have uh Henry or sorry Harry my bad uh to talk about uh some potential issues uh with regards to tooling uh that arise from changing the random op code to difficulty um on that

Harry Altman: uh sure things I wanted to uh talk about as I said eip4 one or four three four three nine nine which uh proposes part of the merge to uh replace the difficulty off code with random and um basically my concern here is about so okay I had originally intended to come here saying do we really need to replace an existing op code rather than using a new one now that I've looked at it somewhere I understand why it's replacing the existing one but this does this does raise some problems uh for tooling purposes

um you know for like disassemblers and debuggers and anything that wants to report on is because I mean there have been op code three names before certainly right I mean and those aren't really a problem because if an OP code just changes its name I mean you can you can handle that but the problem here is that this isn't just change the name but it's also corresponding to changing the function and so we have this problem that we look at a chunk of byte code and we don't know what it was whether it was intended for pre-emerge or post merge and we want to you know disassemble it and report on it we'll do we say this is difficulty or do we say this is random and you know

this maybe seems like a silly thing because I mean it's the same op code but it's like there's there's a reason that the name is changing and it is because that the meaning is changing and we would like to be able to you know do it as a purpose um sorry I'm kind of repeating myself at this point but um so this this introduces this problem of yeah yes I see yeah difficulty or rent that is that is the awkward uh um solution not so a thing I wanted to suggest actually and I would have put this um I'm sorry I I would have put this in my comments on

eip4399 earlier but I didn't because I only thought of it like an hour ago or so is um so I I I understand why difficulty needs to change to random but maybe uh what if there could be uh second duplicate op code for it like if if you could have like like you could have difficulty change to random but also have a new one which is also random and then we could just always call the old one difficulty and always call the new one random um and um yeah I mean I'll go comment I'll go actually add that comment later of course um like I said I only I didn't

mention this earlier because I only just thought of it um but yeah I just wanted to bring up these difficulties and also that suggestion

Greg Colvin: um that would seem like a better approach to me I don't like I don't like seeing an opco change its semantics um it's necessary but it's still unfortunate it would be better to deprecame it but we can't do that either for some reason

so I think

Micah Zoltu: there's value in clarifying that within a given uh client at a given point in time the opioid does have a well-defined meeting so in you know

nethermine version X where version X is after the merge or after where we're after the merge happening um the op code does return random though like so we know from in that context within that context we know exactly what it turns to either return random or difficulty but never either or I think this is I think the confusion for naming is primarily when you're working with tools outside of the clients

Harry Altman: yes exactly clarify that's yes thank you for that clarification that is exactly the case the the the the difficulty um no pun intended uh comes from working in contexts where you do not have that contextual information available about

Martin Holst Swende: isn't this the thing also like a double whammy because not only does do we have this op code which is now either one or the other we also have this header field and that's different it's like a mixer which I said it carries

yeah

Micah Zoltu: all of my types for my blocks are now going to be mix hash or random or whatever it is

foreign so it's probably okay to generally omit no

no the random randomness value is it

Micah Zoltu: positionally it's in the same spot I think it's mixed hash right like the the night or the 15th or Whatever item in the block is used to be mixed action is now random I'm taking numbers of it I don't know what it actually is

perfect ly from the times you don't perspected the field just became its dashboard random I thought it was said about zero am I just wrong on that didn't even

Micah Zoltu: have a post merge Block in

front of them

Mikhail Kalinin: what what do you mean the mix hash yeah it's deprecated but it's replaced with um the random in

the CIP yeah from a structural point to you it's yeah yeah probably yes from a

Mikhail Kalinin: structural point of view it looks like it's just you know relate and and the content has changed but semantically has has changed but not like physical um I have a question to um they're probably the Harry um yeah thanks a lot for bringing this up

but what I'm wondering is um is there an issue for disassemblers and other tooling to like represent um this random value or isn't it an issue at all and it's just an issue with the respective semantics how to treat this um up code in in the context

Harry Altman: I don't know of any issue like the one you're talking about I don't expect it to be um I haven't looked into uh lots of detail about how exactly the randomness works but based on what I know I wouldn't expect that to be a problem

Mikhail Kalinin: yeah from this perspective Randomness is

just a huge number uh much much bigger than difficulty just say difficulty is bounded by two to the power of 64 random expanded to two to the power of 256 so yeah that's uh it's it's it's a number it's still a number right

and and anything having to deal with you know

Harry Altman: anything happen to deal with ethereum stuff has to deal with large numbers anyway

so yeah yeah so difficulty uh there is like the current

Mikhail Kalinin: as I understand the current semantics or difficulty of code it uh it's allowed it's allowed to return

um these large numbers um if difficulty would hit these large numbers so there is there should be no like artificial restrictions on the size of uh on the number of wires in the response to the difficulty occurred in peripheral value and yeah and as I am just trying to understand the issue so the issue is that uh for the user who is using the tooling it will not be clear whether it's like difficulty or it's random

yeah so on that um when

when are you disabling code without knowing the review under which

it was created

Martin Holst Swende: um but that doesn't actually matter because if you if you decode a contract it doesn't matter when it was deployed I mean the if you run it now and the post merge is going to be give you random but if you run it back in the day it was going to give you the difficulty yeah that's the right way to do it really I mean maybe we should just let it be

well I think they're still there's still a use case for disabling something in the regime under which it was created to recover the intent of it uh because maybe you want to understand how it works um but yeah it's true it's completely

unambiguous you know how it's going to run now you just assemble it under with the new

semantic

Mikhail Kalinin: I should also say that that you may actually distinguish whether it's Randomness or whether it's Randomness output or a difficulty uh uh based on the value because uh for the main nuts and for other like networks we assume that the main ad has the highest difficulty that is possible um this number is bounded to the power of 2 to 64. and for Randomness out would to fall into this range and this is low

range there is a very very low probability so it's negligible so basically if that need B probably two tools these assemblers to make include from the value the size of the of this number whether it's random or difficulty I don't know whether it's helpful or not

Martin Holst Swende: one more thing that I just came to my mind about because the cross check as far as I know with the change in gas is that we replace runoff code with another our code implementation with another so the the resulting Trace would say will say random it won't say difficulty

if we hit this or code post merge which is uh yeah that might cause false positives in the passing unless other clients do the same um we can fix it it's not a big thing um just wanted to put it out there so our tracing will be correct

dressing up

Harry Altman: yes for tracing when you have that information that's not it's not a big problem

Mikhail Kalinin: um yeah I should one thing again should just get into the minds uh these eaps

um are currently a scope for the merge and this is going to be the main net change and now that doesn't change so if we I decided to turn some work that stat into the proof mistake so there will be like uh in one of the hard works and uh I don't think that toolin may [Music] um you know make assumptions on these or that of code without knowing the context without knowing that this block is like from the on the is from the main network is that but I I really I haven't used this assemblers and I don't know how do they work so I I would assume that there is a constant context for the exact block and for the exact transaction

that provides some information on on pay execution hello it's great hey Greg yeah I just needed him sorry uh Miguel you were talking yeah yeah just finished just the point that I don't know if the context is provided for disassemblers I'm in the context uh for the evm and change that like um

and the eip's that have are effectively are taking effect for the blog that is being disassembled if it's not the case then

Harry Altman: yeah sometimes you have that information not always

Mikhail Kalinin: and so if you don't have this information I would assume that you are like you're in the version that is from the yellow paper I mean the original version of EDM without any

changes that's quite

Harry Altman: that is not an assumption I would make

I mean how

Mikhail Kalinin: yeah I mean how does other

change to the edmr handled by this and to win um if there is no context

Harry Altman: well for the most part at least so speaking for truffles this December like the way we handle it is mostly just to assume that I mean until now this is basically uh this is never cut this has never come up in a practical sense I mean obviously technically every time you add code add an OP code you are changing an old invalid op code to a new function but since we don't expect to encounter uh invalid op codes other than the designated one at Xerox Fe um this is just not really a problem and

we just assume everything is the most recent version and that all codes that have ever been created exist um this is the first time that a op code would have its functionality and name changed in a way that is not from invalid's valid

okay okay but

I still don't understand like when do you not know how you want to disassemble this okay either you're disassembling it how it was created to see what they intended or you're dissembling it with the current rules to see how we'll execute

like what is there an ambiguity for how to disassemble it I mean it's the the former one right when you say like when when someone just giving you by code and saying like this was deployed at some point and you don't know the address of it um what what role said it was deployed under because if you're finding it from you know a deployed contract then you can just see what the block

was deployed at was

yeah I mean you're

Harry Altman: wait I mean yes sometimes you're disassembling by code that has not necessarily been deployed and is it you know just sort of exists independently of I mean in these cases you can I mean assuming it was like compiled you know uh which you know is usually the case you can say what it was compiled for perhaps if you have the compiler settings um but you can't say what it was deployed to because maybe it wasn't deployed

so when you run other issues which is you know different off codes have been implemented throughout time and so if you don't know when it was deployed that

your December also could be reading codes that are now valid and disassembling them into something that they were actually invalid at the time oh yes yes absolutely that is that is yes like this problem is not anything new and uh it seems like it doesn't it seems like this doesn't make things worse it

Harry Altman: is not new in a technical sense it is new in a practical sense the as you say these cases exist previously with invalid op codes but I don't consider those practical cases so I never worried about it before

right I guess I'm wondering like are there any practical cases even here uh

when you add in the fact that usually you know what rule set under which you want to disassemble this

Harry Altman: well I'm not sure I agree with that latter part

okay yeah that's what I was curious about like yeah maybe there's something missing I don't use disassemblers ever really

um yeah no I mean it's it's you

Harry Altman: you may want to do this with a contract that has not been deployed and therefore this the the evm version is not defined in that sense although it could be defined in the sense of what it was compiled for uh assuming you have that compiler information

which you may or you may not

oh I drew ya

Andrew Ashikhmin: um so like if you are investigating um a code to be deployed and you don't have like you don't know what is the Eva revision then most likely or like there is a high probability that it will be deployed later so I guess if you don't have an EDM rubies and you can assume the latest VM revision has imposed merge so and then to say that it's random

right uh to my mind it's like oh you can to be like completely accurate you can rename this if it's only above the name rename its difficulty or random and let the user figure it out so to my mind it's like I don't see any practical problems about from some confusing about the name

Harry Altman: um sorry I'm trying to there's discussion going on in the chat in the text chat also

and it is

Martin Holst Swende: yeah again

but I was just wondering if there's anything like practical we should decide on as an old quarter group uh or if yeah we should just move on I don't know if they're

understood yeah that's that's

Harry Altman: I think that's the right question to ask um I I would suggest um I think the thing well so like I said I I made my suggestion before about perhaps introducing a duplicate op code for random um and that one would be the designated new random and the old one would continue to function as random but to keep the old name and so I don't know if that's something that needs to be decide

on right now but I think that is some things inside whether to do that or whether to just go ahead with 4399 as it currently exists

Martin Holst Swende: so I I would think that the current proposal is better because if there exists contracts which today and with some way shape or form rely on difficulty to provide some kind of entropy and then they are better served with uh getting the new random rather than getting uh all zeros or getting some um I don't know in that little code error

because we want to add as to as little extent as possible screw up the existing contracts which makes some use of difficulty

Tim Beiko: yeah it seems like there's not a ton of desire to add a second of code from what I'm getting um and obviously yeah anything more complex than that this late than kind of the development process seems uh like it would delay things for

uh I don't know not like a major fix um yeah I I'm kind of inclined to not make a change based on the conversation here um we can yeah we can obviously discuss this uh discuss this more offline but um yeah it seems like at least at the consensus Slayer we probably don't want to change things um and obviously at the tooling that you're there's there's a few kind of workarounds it seems like you can do

Harry Altman: yeah I mean we can come up with something sure yeah

um but I came here you know but you know since I work on this stuff I I did have to you know I have to come here to make the suggestion that will make my job easier right

Tim Beiko: yeah fair enough

so um yeah

Harry Altman: anyway I I left my comp I left the comment that I said I should have written I have now actually written so that is now actually there on the ethereum magician's discussion for 4399 so that suggestion is recorded what people will do with it I don't know but I wanted to at least come here to say this and I you know I I sort of read that comment earlier but I only thought

of that particular implementation like two hours ago so yeah I don't I I think I've basically said what I want to say

Tim Beiko: cool um and yeah definitely I guess yeah we we can continue to thread on these magicians if you know people want to uh suggest more ideas there but I think for now we can leave things as is and uh plan to deal with this at the tooling level um yeah and uh I guess uh on on that note we'll probably be organizing another merge Community call um in the next couple weeks uh so I'll make sure that that's something we just mentioned in the agenda so that uh other teams are aware of this

cool um so next thing I had on the agenda related to the merge is um there's a few people starting to ask in uh Discord what testnets uh you know if they're looking to deploy on that is are expected to stay on post merge um not necessarily looking for like a full list and and like all decisions on them but I'm curious just generally what people think if there's one or two test Nets we do expect to be uh to be continued on after the merge and transition to proof of stake just so that we can point people in those directions as they're asking the coming months um

Marius has a comment about the shadow for Gordy I'm not sure if that implies we're keeping Gordy or not um but yeah just curious about people's General thoughts about about that like which test that should applications be using if if they want to be like merge proof

Martin Holst Swende: so I have a question um as as like core devs uh do we really is there anything from our perspective to be kind of gained from

having test Nets that are not following going

in advance

Tim Beiko: what do you mean sir I'm not sure I understand

Martin Holst Swende: so I mean I mean is there any reason for us not to go full proof of stake on all

tested oh right

Tim Beiko: right so yeah I think that the point is more we've discussed in the past like say deprecating Robson and I think we probably should run the transition on every test net but if we say want to stop maintaining robsten afterwards uh we probably shouldn't be pointing people in that direction on all of them

um yeah

Micah Zoltu: I agree with Martin that I don't think we should be running a proof of work test Nets anymore but um correctly we're wrong but uh running like a girly network is way easier than running a full multi-client proof of stake Network so it seems like there is value still in having the simpler ones

you know

Tim Beiko: oh you mean running

gorgeous Republicans

Micah Zoltu: yeah so girly is key away which is simpler than POS sible so it feels like there's value there but maybe not maybe since these are public test Nets we should be you know doing the whole thing and not half-assing it

Péter Szilágyi: so the problem with um keeping your most

functionality is that you need to keep for example certain Legacy code like uh Legacy mining or another synchronization all these code needs to be kept and maintained in the clients

Tim Beiko: yeah also yeah there's stuff like the difficulty up codes and whatnot that are just going to be weird um so I guess I don't know oh go ahead Micah

Micah Zoltu: the other um argument here would be that robston is our most bulky and problem written testnet which has value for testing specifically if we clear it out and have a Greenfield test that's only then we

lose that kind of you know ancient crafty crusty thing that has potential to show up bugs that a clean Greenfield that's not what not this is pretty hypothetical but like you know if none of our test has actually went through proof of work and then transitioned maybe there's some bug in the future that only shows up on a net Network that went through the transition and so it does seem like there's a little value at least in keeping Robson but I'm not married

Péter Szilágyi: I don't think the proposal wants to kill the Old Testaments rather just to transition them and

just not support standing up even empty distance no sorry the proposal is so

Tim Beiko: it's not necessarily a

proposal but it's I guess people want to know which test Nets will be alive say six months after the merge right I think it's pretty clear we should run the merge on all of them in case you know each each of them kind of increases the hours we find an issue but you know do we want to maintain a full validator set on robsten rinka B and Gordy and if that's if that's the case then great we can just tell people the existing test Nets are not going away but I know we've discussed in the past potentially sunsetting Robson specifically and and potentially other

test Nets so increase we've

Péter Szilágyi: discussed that um became a monster and at least increased and I said this was that we

should launch a Newcastle yeah it was actually launched and there were many clients but there is actually a new Chromecast that's just hiding there and I think the idea was that uh Rockstar would be kept alive up until the merge just we can also emerge it just for the test but afterwards it would be the applicator since it's just this huge pile of I mean it's a rocks and the size is huge the data search it's very hard to synchronized there are only a few peers and it's not really useful for anything so our our idea was to just take this audio test that and switch to it because at least some here you can

just in essence it would be kind of like crops than just without all that crust and at the end of the day the question is what do you we can definitely keep the Robson history just so that clients could use it as a benchmark for example to synchronize although maybe it may not be suitable for that

but as as a testing ground roster is I don't know how how viable it is at this point okay so I think I know

Tim Beiko: that seems sufficient to answer people's concerns where it Gordy has a lot of activity and it seems like there's no reason to shut it

down so it's probably pretty safe um Robson might be replaced uh you know by sepolia over time and and we maybe don't want people uh to assume it's going to be there forever I guess the other one is like rinkaby is that something you would plan to keep long term after the merge

um I mean it's

Péter Szilágyi: it's hard to answer that question because uh it's kind of was managed by the guest team but I don't really want to be the person deciding whether to kill it or not kill it um I think in general we should uh I think a Bitcoin World they they have

these semi regular desktop presets already based on New Testaments and I think we could do something similar just to kind of thing every year start a new testament and then just start eventually start applicating the old ones because at the point where they just reach a huge size it just doesn't make any sense

it isn't the case also that bridge in all these testnets we need a corresponding and Deacon chain so I mean we have a prospector for garlic but then we need other um we don't do we have those and doesn't such exist efficiently money we're gonna

Tim Beiko: need to set them up if we

want to test the merge right

so for foreign [Music] or something like that I know and

Micah Zoltu: can all the proof of authority networks um reasonably go through the transition like even though they don't really have

difficulty

Péter Szilágyi: well difficulty they do have because either one or two difficulty on the blocks so the TTD can be used or transition I am unsure about the mix digest because maybe click users has to feel delicators and it's pretty much it doesn't so we we tested the transition uh yesterday on on girly basically we deployed a a big deposit contract and went through the transition and everything went fine so we have now

a Network that is parallel to to girly and if we were to shut down the girly validators then uh we would be able to like we actually did did much uh early already but it's like shadowing the normal chain right now

is one

Martin Holst Swende: one thing that might be problematic is if so apparently if you want to use dropstone and then when it's finding it you can just spin up a minor in mind your own box and help out of it as for the POA testers there are various organizations that are dedicated running nodes uh in the garden we keep it if we switch the proof of stake and they come

it's going to be harder to to have them continuously work because if people want to test something they might Deposit they do their testing and then they stop running the node testing it back on and after a while it's all

about it interests

Micah Zoltu: we'll get lots of testing of leading people out

Martin Holst Swende: yeah

that would be uh well sooner or later I don't know what happens yeah

Parithosh Jayanthi: So currently with Prada we've just made sure that the majority of the validators are on the entities we know so all the

time claims EF and um if there's some operators from Lido or other um other providers then they run a bunch of Educators it hasn't been an issue with the regular users um are just turning off their metadatas and the general recommendation is once you've done finished your testing you should exit your validate if you don't and on running it it hasn't been an issue on product but yeah we can't guarantee that it won't be one in the future

yeah

Martin Holst Swende: I guess we'll see maybe it'll work

out well I guess here are the solution is

Péter Szilágyi: either you could have some special where

essentially average users are not allowed to deposit so you cannot and you validate and essentially just logging into the current one that would be one solution that's a bit of a changing of assessment consensus the other solution is that yes you could you could just say that okay um if there are 10 currently 10 signers and each of those 10 signers will get 10 000 validators and then average users will be able to create their own validators but they will they won't be able to obtain so much easier has to to be able to make a data on the um

we could also modify the deposit contract so that it cannot be deposited into after like the deployment so we deployed with a set of validators and that cannot be changed

yeah hopefully

Gary Schulte: there will be a test net where you could practice you know there's a lot of folks who want to practice at home staking on something where there's not as much eth on the line

so my distance would be the

Péter Szilágyi: uh contract is a bit simpler but it has a few risks for example if for some reason one of the signers

authorized signers to manage is to get themselves slashed they kind of made themselves cannot come back so um that runs every step we actually saw in the network very long term and so from that perspective I think it's similar to just go to the other approach where you just create enough validators so that average users can still screw around but they cannot impact

Network performance

Micah Zoltu: so if we had to pick which of well let's say we wanted to have one public one air quotes

private test Network private here just means limited validator set which of the two Gurley or sepolia would be the public one which one would be the private one

yeah I'm saying you should have all of it should be funding

Péter Szilágyi: you just create a margin of validator set for your authorized signers so that unauthorized signers won't won't be able to break

the sentence

Micah Zoltu: I see so I I do have a medium strength opinion that we should have at least one test net that actually does regularly suffer from failure to finalize and failure to come to consensus and reorgs and forks and all the bad things

um I think there's significant value in seeing that in the wild and a great way to do that is to not have you know well-known validators let anyone who wants to validate validate and people will disconnect and it'll slowly get blood blood dry and then eventually fall out and all this stuff needs to be exercised and I think should be regularly exercised and so I would prefer one of those test Nets um was not you know guaranteed up so to speak

Péter Szilágyi: um so the problem here is that then you you're missing a bit the purpose of the test that's so I I definitely agree that it would be super nice to have one of those Teslas but then that particular investment would be more like a developer consensus assessment and it would not be that

developer that's not and currently girly and Green Copy are both I mean deaf developers rely on it so we could be goes down and two hours later I've already mentioned a lot of pizza people so aren't able to test their whatever so I think if if you don't really want to mess around with with a test that is actively live used to test them you don't want to keep breaking that because then you just

if we have

Micah Zoltu: is there any reason not to have one of them be that and just the one that has the authorized stickers is the one we recommend to people for

you know if you want something that's always up use this if you want something that's going to battle test your UI and make sure it can handle reorgs and failures because I think there is value and uh app developers being able to battle test their UI against things like lack of finality

the only problems that currently both went to the End early is stable

Péter Szilágyi: so you have seven uh teams building up monsters it will be kind of like a rock pool if you're going to say that okay now this network that you've been using for five years is going to be

honest with your work

Micah Zoltu: okay so how about um Gurley and Rincon B transition over and they continue to be authorized ish like you described and

then maybe sepolia is our um you know real world example of

firefighter

Péter Szilágyi: because that would work but then you don't really have that deprecation path of creating a new stable that's not so that eventually you can Sunset the older ones so I think it would be still important to have a new empty stable that's that spawn up so that eventually we can

Sunset Green Copy and we can Sunset early and

Micah Zoltu: so ideally we would have at least at any given point in time we'd have at least two

of each one which is the new one that's coming in and kind of got started recently and then the old one of that type so authorized users or whatever that is you know still running and it'll run for a couple years but eventually we're gonna phase it out and then similarly you have two of the public higher fire tests that's that's kind of rotate every year or two sets at the time

Tim Beiko: yeah I guess uh we are kind of closing in on time so uh we can maybe continue this uh I'll open an issue on GitHub

um and we can continue this async but it it does seem like Gordy is already used by Prater that that seems pretty likely to keep going on sepolia is likely to to stick around and I think we can figure out kind of the rest and like the broader strategy I think a bit

then discuss it to get on a on a protocol so that's just a final thought

Péter Szilágyi: personally I would say that it would have been nice to sunset during the week in favor of early at this point in time for example during the march it would have been nice to say that okay you're welcome it will stop we'll keep or will not be adversed just to reduce the burden of having to spin up a beacon

chain for weekly I guess the only problem is that it's a bit late in the game for that so it's a just telling people that hey all your stuff needs to be ported over ASAP currently because spirit is continuing is a this kind of sounds nasty

but it would would have been nice to to Sunset directly now

Micah Zoltu: we can just not merge it people can still use it for testing most things I just won't be able to test a new functionality that comes with merge which I think is acceptable

Péter Szilágyi: um yeah perhaps but but either way I think before we make any kind of decision on on killing off any of the test Nets or replicating them we need a

solid strategy on how to spin up

when you posted that makes sense

Tim Beiko: um okay we only have like seven minutes left um there were two comments uh about people wanting to Champion uh eip2537 and 2315 um it doesn't seem like there's a oh I guess yeah the two of them wanted to discuss this uh but then there was also kind of a big question around 44 44. so I think it maybe makes sense to just do uh 4444 first and then uh if we have

time we can kind of uh also touch on the two other ones briefly but we've discussed those two other ones uh quite quite a fair amount in the past so it's probably less blocking than uh 4444 so um Martin you have a kind of a comment about basically 444 being a prerequisite for 44.88

um yeah yeah

Martin Holst Swende: I'm sure everyone has read it I I just think that it's a bit leaving a lot of details uh kind of big and I think if we actually want to do for the 444 we need

to get the the nitty-gritty details are not

tested and Productions so [Music] yeah I don't really how much else to add

Tim Beiko: yeah there's a few people on the car who have been working on uh 444 so I don't know if anyone wants to kind of share it updated where things are at then

Lightclient: I was just gonna say we totally agree I think you know four four the actual stack of this relatively simple but there's a lot of external things that are that have to be worked on and are being worked on so we are working right now with a contributor to develop some sort of standard format for school Randy's and sort of like epochs of

blocks that will be provided over various methods right now the main mechanism we're looking at is using like bittorrents to share that information but I think there's obviously there are ways like the portal Network and we could potentially have mirrors set up um and then in terms of the archive node that's something that we plan to like work on in the next couple months as well so these are definitely the things that we're looking at it's just not included in EIP itself

Martin Holst Swende: okay uh I was aware that they were in a group actively working on it um so I I from my perspective we don't actually have to have all the details set this call I just wanted to raise it and I'm happy with that

Lightclient: okay we can try and be a little bit more um oblique with these things so it's clear to everyone what's been worked on yeah

Tim Beiko: I think as soon as you have updates uh yeah under progress uh to basically enable 444 uh yeah it'd be great to share them on this call and get feedback from

from client teams

Tim Beiko: well um that was quicker than I expected uh Alex uh are you still on the call yes you are

uh I'm gonna

Tim Beiko: have some questions about uh the BLS pre-compile that you wanted to ask also of client teams because you're looking at a championing that

Alex Stokes: yeah I mean that that's about it uh I just wanted to ask client teams on the call uh sort of where their status is uh you know for context I think most of us are aware but we had the zip uh 2537 for BLS freaking files and uh it's essentially almost went into London but then was deprioritized because you didn't do nine and then now the merge has been pushed to after the merge um and yeah we'd like to consider it pushing High inclusion and the first step I think is just getting a sense of where it's at um things may have got a little sale since you know people were lost actively looking at it so if anyone knows of anything uh blocking or you know any potential issues uh it'd be good to know

about them sooner around later

Tim Beiko: cool and I guess the best place for that would be there is an issue on the ethereum PM repo about uh including 2537 in Shanghai yeah 2537 that's right um so it might make sense to just uh yeah if clients have issues or like concerns to just share them in that thread I'll post a link in GitHub um and it was a comment by Danny in that threat as well that a lot of the libraries are have been tested and are being used in production on the

consensus layer side um yeah so we we do have more data on that since the beacon chain has has been live for a while and so um there were there were two things that I remember from the last debate that were still open and the the the one thing was this uh evm 384 um I think that's not coming so um I would be fine with uh uh 2537 and but the other thing was um it introduces nine nine pre-compiles I think and there was some discussion that we

might not need all of those nine free compiles and so it would be really cool if someone could describe why we need these why we absolutely need these pre-compiles for each one of the pre-compiles or if it makes sense to uh just I don't know do the three most important ones that we actually need for for building stuff until that's it

Alex Stokes: yeah unfortunately like you kind of do need all nine it's just there's like a lot of different operations

um yeah

Tim Beiko: okay um what one minute to go uh Greg you also had a comment about the EIP 2315 oh are you still here Greg

Greg Colvin: we're out of time but that and the whole set of evm changes is there and I'd like to keep it on the table and discuss it because I and I think the other people never want to go through years of work to have the whole thing fall apart on

the day of uh shipping

Tim Beiko: right and you had a comment uh on on one of the open issues about kind of the the different uh eips for the evm and and how they

related

Greg Colvin: yeah there's basically an order in which yeah there's an order of dependencies there and for 23.15. there's specific changes to uh to answer um answer criticisms that did come up at the last literally at the last minute um so I've made changes to answer those and introduced uh a new IP a new EIP to answer some of those

um and uh and the eips that uh the other people on the on the uh foundations evm team uh are also related so I just like to see some commitment early on that we're moving on with improving the evm or after six years deciding that no we do not actually want to fix the evm and let's quit wasting time on it

Tim Beiko: right

um yeah I'm serious

Greg Colvin: I'm serious I'm pissed off okay foreign we put many years into this and made no progress

Tim Beiko: yeah and I think there is a lot

of desire that's been like mentioned by many people to improve it I just think your comment helps kind of untangle the different proposals and and and uh you know sort through them it's probably unrealistic to have all of them go in the next upgrade obviously but uh hopefully this can help us prioritize

Greg Colvin: um yeah yeah that's that's the point of of getting them in an order of dependencies

Tim Beiko: cool um anything else anyone wants to share oh Mikhail you have your hand up

Mikhail Kalinin: yeah I have a very quick announcement um this engine API authentication cement exchange and the optimistic since back

um other major things that will be in the next merge attack release we already meant to iron this out here in the next week and do a release after that we will have like a time for engineering and and the devnet and then uh replace skincare test that would like the new one correct me if I'm wrong

Theory or him like the yeah that seems reasonable um yeah I was going to say I mean did you authenticated API is going to be on the new uh a porch and

Martin Holst Swende: I don't see any problem if for one month

longer or whatever one release we still serve it on the Old Port to reduce any

programs [Music] yeah I see cool yeah let's do it this way I mean that's that that's not like not not aim for uh of authentication or this release if it take too much time and I think yeah we what's the new specs are out and and we can probably discuss uh kind of a more specific test net plan on the consensus lyric call next week or yeah short term that's not done yeah

Tim Beiko: cool

um anything else before we go

Pooja Ranjan: um I would like to take a moment to thank the community ethereum Caterers are celebrating uh the third anniversary with ATM blockchain and um yes of course we would like to take this opportunity to thank the community and we look forward to continuing support engaging them thank you and one voting they have published a Blog with like all the Jazz that were done by the cat holders in terms of like protocol support and education and everything else so please check out the characteristics Twitter

and the medium blog

Tim Beiko: thank you for sharing

okay well thanks everyone for coming on and I will see some of you the consensus air call next week and everyone else two weeks from now

all right [Music] foreign

[Music] [Music] [Music] foreign

[Music] foreign [Music] [Music]

[Applause] [Music] foreign [Music] thank you

[Music] [Music] [Music] thank you [Music] foreign

[Music] [Music] [Music] [Music] thank you

[Music] foreign foreign [Music] [Music]

this is [Music] [Music] foreign

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

foreign [Music] foreign

[Music] [Music] thank you

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

[Music] thank you [Music] foreign [Music] foreign

[Music] foreign [Music] foreign

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

thank you [Music] [Music] [Music] thank you [Music] foreign

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

thank you [Music] foreign [Music] foreign

[Music] foreign [Music] foreign

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

thank you [Music] [Music] [Music] thank you [Music] foreign

[Music] [Music] [Music] [Music] thank you

[Music] foreign foreign [Music] [Music]

thank you [Music] [Music]

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