All Core Devs - Execution #131

Transcript

[Music] [Music] [Music] so

[Music] [Music]

[Music] [Music]

Tim Beiko: good morning everyone afternoon if you're in europe welcome to awkward dev 131

uh pretty packed agenda today uh ton of upgrades around uh the merge so some kenzugi stuff then uh kiln the new metaspec leading to a test net um and then lots of shanghai discussions as well um there were a lot of people uh kind of with eip proposals and i think kind of before that we probably want to have a higher level discussion about generally how we we want to shape shanghai and like the various kind of potential things we could do in them um and then a couple announcements at the end

um first off i guess on the kintsugi side

uh perry shared an incident report in the uh in the comments of the agenda about the issue that we saw on the network i don't know if you just want to take like a minute to kind of walk through it perry and and like what the high level issues were and and kind of the state of things now

Parithosh Jayanthi: sure um so the high level issues was in the beginning we had an invalid block that was causing an issue with uh nethermind and bezu because they were missing a check the invalid block led to a network split and one being on an invalid block one being without the invalid block and one set that went into an optimistic sync mode

when we deployed a fix for the invalid block we realized that the fuzzer had created another block that triggered another issue in geth causing some nodes to fail to be um to able to even sync and once the get issue was fixed as well then we noticed a few smaller edge cases and some of the clients once everything was had settled down we pruned some forks uh got all of the nodes back onto onto one fork and afterwards we were able to get the chain back on track um there's a deeper summary as well as implications in the incident report i'll just post it here again for whoever wants a quick link um yeah that's about it i think

Tim Beiko: got it uh yeah thanks for sharing uh so yeah the link is in the agenda we'll add it we have somewhere in the execution spec repo uh where we track like these various incidents uh like the testnet issue we had at london for example so it could just kind of be there forever for people interested um but yeah thanks a lot for putting out putting that together

perry

Danny Ryan: i'd say if you're working on hive or other simulation tests uh make sure to comb through this and see what scenarios you can pull out of it obviously it's all generally fixed but it's good to not have a regression

Tim Beiko: yeah good point

um cool

so

Tim Beiko: i guess next up on the agenda uh there were the kiln specs released uh last week um [Music] uh i guess maybe it's worth it for daniel mikhail to just like take 30 seconds to walk through like the the main changes and and then yeah there's a couple things after that that are still pending for like an upcoming iteration of the spec but yeah daddy do you want to just or miguel do you want to just give a quick overview of the change

Danny Ryan: yeah i can talk about the consensus layer mika i can pick up the execution there um there are two pr's that were merged on the optimistic sync spec this is when um the beacon chain is kind of churning while the execution layer is still in some sort of sync mode this is not

although it's just merged and just released it's not new a lot of client teams have been working on the implementation as the prs up additionally in the code base merge is was kind of a terrible word to have around and didn't fit the star naming so it was chosen to go with a b star after altair to bellatrix merge uh you know merge merge the merge vr and things like that was kind of fun um and then a couple of them very minor renamings receipt route to receipt routes just to match i think more of what it's actually called maybe yellow paper and um a modification of so they're named the map to the engine api miko do you want to take the executioner one

Mikhail Kalinin: yeah sure so the major change on the execution side layer side is the cement exchange of execute payload and fork choice updated they both now has a notion of execution and for execute payload it's been renamed to a new payload and the currently execution is optional for uh this net call like it it may it may be delayed uh until the payload becomes the uh becomes belonging to the canonical chain so this is done this was what was discussed during the last few calls and this is done to reflect uh the current

logic of extremely clients basically also there is the new handle uh for the case when the terminal block does not satisfy the terminal block conditions which is a minor change and yeah message order and refinement that has been done like a long time ago but yeah a while ago just and this has been released in this um in this version so that's that's it also uh the out indication yeah we can speak about it in the next item right right

Tim Beiko: yeah yeah um okay yeah so those are the changes uh

up to now i guess one one thing i wanted to clarify also for kiln is like um are there any test vectors yet and if so um yeah okay so basically like trying to like try and question but like you know what's the best way for client teams to test their implementations of these changes uh so far

Danny Ryan: is marius here

Tim Beiko: no

Danny Ryan: marius is talking about doing and maybe he has i'm not sure and we should cater we should catalog the testing methods available but he was going to cut some engine api test vectors from guess in previous sprints this is surface bugs both in guess and and other clients kind

of before we try to do some interrupt so that's probably the minimum one that's going to come up i don't know like client if um how if and how people are using merge mock in their processes i know some clients kind of where some clients were uh we're not so if anybody wants to speak up and say if merge mock is valuable to their iteration um let us know

Mikhail Kalinin: isn't it used in hive also emerging i don't know i don't think so it's kind of been rewritten to be a better fitting with the hive architecture

Danny Ryan: another mind or anyone is anybody think

merge mock in this sprint will be useful

Marek Moraczyński: i think it will be useful

Gary Schulte: yeah it's okay definitely useful there's not a test net to participate in it's definitely useful i will get it updated by monday or tuesday if that's okay

Marek Moraczyński: yeah sure

Tim Beiko: yeah that'd be great thanks a lot thank you cool um okay so yeah so we have the current v1 uh release of kiln some tests coming there's two pending additions for an upcoming iteration of the spec uh

one uh the auth for the engine api uh and two a new api call get transaction configuration which acts as a sort of heartbeat check between the el and cl that that they're upgraded and ready for for transition um uh mikhail do you have like a a status on the on the uh offer engine api

Mikhail Kalinin: yeah it's better to ask am is martin here on the cloud

Tim Beiko: oh martin's gonna be late yeah that's why i asked you

Mikhail Kalinin: okay um yeah so i think it's about to get merged for this to get merged pretty soon

i've got some um attention from martin that it's like in the final stage so it will likely merge it yeah

Danny Ryan: yeah they were working on implementation which i think they've done um and are happy with it so if you haven't taken a look take a look but i think this is going to be merged probably by the time i wake up on monday hopefully

Tim Beiko: awesome

and then

Mikhail Kalinin: yeah i think it's already ready for marriage from my side so just need to double check with martin

Tim Beiko: oh and martin just showed up actually

Martin Holst Swende: yes hello i missed a bit of what needs to be said

Tim Beiko: uh yeah we were talking about the uh auth between the el and cl and uh how just progress is going

on that i think get is implementing yet right now

Martin Holst Swende: um yeah it's not it's not in any pr yet there's still some work left to be done mainly to make uh to make these see the client part um yeah i mean it's not complicated we just need to find a nice way to to expose it

got it what what do you think about merchant apr do this back uh from i

Martin Holst Swende: i have no addictions to that um i don't know if you guys mentioned

but the last change that was done to it is to not expose the secret in any locs unless someone objects to this whole authentication scheme i think we should go ahead

Tim Beiko: okay i guess maybe we can leave a couple days for people to review but like monday or tuesday merge it in if there's no objections does that make sense

Danny Ryan: yeah i have no objections by monday this thing's getting merged

Tim Beiko: okay cool um and then the other change uh was yeah adding this add get trend or sorry adding this get transaction

configuration endpoint which basically pulls uh to make sure that the the el is actually ready for uh the merge uh mikhail do you just like to send your pr do you want to give quick bit more context on that or

Mikhail Kalinin: yeah sure so um basically it's been extended with the um not only poland but also providing cl's uh configuration for el so yeah this method is just called with the [Music] main um sentence of transition configurations which are terminal block hash and terminal total difficulty

and the cl sends its local values to el and the l response with the corresponding local values that it has in its configuration and cl and dl both may match received configuration settings from the counter party and if there is a mismatch surface an error to users also it's it should be useful for infrastructures for large infrastructures which there could probably be a script that just queries every el instance in the infrastructure and it checks whether

it's been configurated correctly and whether it's ready for for the upcoming transition

[Music]

Marius van der Wijden: updated if the head block hash is is a an empty hash we just return status inv status valid um or invalid or whatever we can like why do we need another method if we can just use the use default choice updated with the with the empty

hash

Danny Ryan: talked about it a bit for sure is updated has like super overloaded semantics already so this is to just have a clean thing that can unit thing that can be deprecated right after the merge um i mean i could go either way but fortress updated is kind of a monster stuck already

Marius van der Wijden: okay

yeah

Mikhail Kalinin: also it's not only like uh you know to check whether engine apis is uh working or not it's also to check the configuration and uh and the configuration on the outside is going to be in a binary distribution likewise on the cl side so it's a matter of checking whether the client is updated is up to date with

the most recent release in case if this parameters will be overwritten and yeah that's also one of the use cases it's probably a minor one but still valuable to have these values exchanged with two clients and surface and error in case of mismatch

Tim Beiko: i'm curious i guess um so we have we have basically these two these two pending uh prs um one of which will be merged kind of early next week i feel like we might

need an extra couple days for get transaction configuration just because it's it's newer and and and maybe we need teams to like review it a bit more um so call it like i don't know mid late next week i suspect we can have all the changes like both these changes merge in the spec um oh andrew you have your hands up

Andrew Ashikhmin: um yeah i just want if we make this change i'd like to clarify what happens if the terminal block hash is not set like it's it's whether it's returned at all like all zeros or what happens and

also if there is uh if the terminal block hash is all zeros or not said then what happens to the terminology total difficulty would be like should it return zero or not nothing

Mikhail Kalinin: um if basically terminal block hash if it's said then it overrides the terminal total difficulty uh you mean that what what should happen when it's set right you call terminal block hash is all serious

Andrew Ashikhmin: yeah yeah so do do in the api does it return all zeros or nothing in json

Mikhail Kalinin: it should return all zeros

Andrew Ashikhmin: and for for ford uh

oh sorry not like oh sorry terminal block number then and for terminal block number it will return zero uh or

Mikhail Kalinin: yeah yep

Andrew Ashikhmin: okay okay i just think it just has to be like explicitly mentioned

Danny Ryan: yeah i mean and on on timing tim i this has been going back and forth a bunch of the discord i think that if there are issues with this they should just be surfaced soon and that we should target a release uh with these two additional methods by like wednesday

Tim Beiko: yeah and i guess my question was um if we're going to start standing up like

fmri ephemeral devnets um do we want to wait until those chain those two changes are implemented in clients like is there value to having a kiln v1 devnet or should given those two changes are probably not huge should we just wait and have kiln v2 be like this ideally final or you know feature complete kill spec and then launch devnet

martin did you see me yeah

Martin Holst Swende: i just wanted to point out uh regarding the off thing the it's not tied to any to any network per se i mean it's something that is rolled out first in

the execution there um it's side by side i suppose for like a month or a release with what's already in the in the legacy and then after on the next release we remove the engine from the unauthenticated report and during that time the cl can start using the authenticated one at any point so it's not like they need to rush to to implement it on day one

Danny Ryan: yeah so we can do all of our interop experiments with and without auth as people are kind of rolling out off and then the exchange transition configuration is probably one of the simpler methods to implement

and i would say that we should just release and get it implemented also if uh if there was no call if one if it was not implemented on one cl but it was influenced on el you know el might complain that maybe configuration is not set or it's not listed not hearing anybody but also as the transition comes they would still be able to communicate so neither of them really put like a hard blocker on the core of the functionality here

Tim Beiko: okay so does that mean i guess we can probably launch devnet like next week with whatever clients have something ready um and obviously the week after that do an another

[Music] rollout

Danny Ryan: v2 v2 is really an extension to v1 not a breaking of v1 and we should anyone that's ready next week we should begin you know some interrupt uh experiments and and super transient does that

know

Tim Beiko: cool and i guess i'm curious yeah generally do teams have a feel when they're ready for that just to help like perry and others kind of coordinate there if not we can we can chat about it in uh yeah in the discord um yeah that's yeah let's do that so once once you have something uh that you

think can work on the devnet uh reach out to perry just message in the the merge general discord and we'll get a first iteration next week with whoever's ready and and grow it out the week after

Danny Ryan: oh and marius you did join uh are you going to cut some test vectors on the engine api against

guests

Marius van der Wijden: um yeah so we had a bigger refactor of the sink and um so i had to rebase so i implemented kiln before that and i had to rebase it now and i managed to fix some stuff up so we have some regressions in the code against the test vectors but i'm going to create some new ones

i'll be on holiday next week though but i'll be still doing that so yeah nothing changes

Tim Beiko: on holiday but still working um okay it's not the end of the world if they're not there next week don't burn out um but yeah we'll be waiting for those uh from you in the next couple weeks cool anything else on kiln or the the merge implementations so far

Mikhail Kalinin: i have a very small thing related to engine api um

there is the uh statement in this pack in the engineering pass back that eth namespace of json rbc api should be exposed to the same port to provide consistently a client with edh functionality that is needed for to pull eth1 data and there was a suggestion there is a suggestion to restrict this like broad requirement to to have it to have instead of it a list a subset of pth methods that are required by consistently clients i'm just wondering what do people think about it

uh is is there like strong opinions on why should we have a list of methods instead of like entire ideation in space if there is no because we'll just keep it as is in this back and will not make any changes

Micah Zoltu: so the east namespace currently is not well specified like where there's work going on to try to get it well specified but like clients are inconsistent between each other on what they return how they return and how they deal with certain situations it'd be nice if we don't uh port that forward to

communication with the consensus layer i would much rather see us have a very much more narrow but very well defined spec for what is required for communicating with the consensus client

Mikhail Kalinin: um the problem here is that consists client might have different subsets of methods that they use that they rely on and probably probably they will need to be the functionality of serial client will need to be extended in the future and it will probably depend on on one of the if methods that is presented in all el implementations but is not in this list in this case we will have to update the engine api stack to provide

cl with this that kind of method having this like broad definition makes it easier so

these are like

Micah Zoltu: i feel like what you just described is the right way to go about it like if if we need to if some new feature is needed for the communication between the two layers i feel like the proper way to go about that would be to you know come to a consensus on it get agreement on what that method is how it's defined specify it well and then have people implement it rather than just kind of being like hey we've got this giant pile of data that you know maybe some clients and maybe some don't or maybe they implement differently we don't know and then we run into problems later because we're relying on that kind of uh old thing that isn't well specified

Danny Ryan: yeah i do i think i agree with micah i the it'd be good to enumerate which methods clients are using i don't think that there's going to be like a huge disparity between between the clients and you know this endpoint supposed to be used for very particular things so it's probably good to have it well specified i think but i don't have the knowledge to enumerate those myself

Micah Zoltu: the other weak argument is just that if someone's building a new execution client they may not immediately implement the full eth consensus layer and knowing exactly what is necessary to

be a valid execution client in order to work with the cleanse layer but not necessarily everything to provide a full json rpc is valuable so just knowing what the set of requirements are so that you can be confident you will work with all of the consensus clients

Danny Ryan: good fine okay

Mikhail Kalinin: i was like assuming that what is listed on the if ricky jason rpc api is kind of um presented in all clients and supported by all clients and this is the subset that the cl client may rely on

Micah Zoltu: so what is on the uh someone else might be able to correct me on this but i

believe what is on jason rpc api is was pulled mostly from guest source code and we have not yet validated that everything on there is available in all execution clients i have not reconciled the differences so you know different clients will return slightly different things for each of those methods depending on which client you're talking to which is part of the problem here is they're not well specified and so you might get you know just as an example i'm off top of my head i don't know if this is real but like one client may send you a number formatted as a you know json number another one might send it as a hexadecimal string and so that's like a subtle difference that could very easily break something if it's not well specified

Mikhail Kalinin: okay

okay so yeah one of the way to do this is to just make a table of methods and ask see our client implement their stems just to feel it um yeah

Danny Ryan: i i go my god it helps ensure that we make sure those are very well defined as opposed to the whole name space which is still in flux okay

Tim Beiko: cool anything else on that okay

last topic we had for the merge uh last time we discussed test nets and what that would look like and post merge uh to ideally give the community a heads up so that they can start moving the test nets which will be supported post merge and not be fully surprised if some of them don't work after the merge um the high level uh we we kind of agreed to like saying we would want to have at least one test net that has like a pretty fixed validator set uh which is stable and people can just use as a as a kind of staging environment for their applications and we'd also like to have ideally another one where uh maybe the validator set is not as stable and and people and client teams can use as a way

to test uh that their software works uh when say the network is not finalizing and and stuff like that um peter has suggested uh we fork robsten into the merge deprecated shortly after um fork sepolia which is the new proof-of-work test net into the merge and use that as a new test net um so we we get the experience of forking robsten moving from proof of work to proof-of-stake but robson has pretty big legacy so um deprecating it means we don't have to like carry that huge chestnut sapolia kind of starts with a smaller state so we can we can kind of reset there um for gourley would uh into the merge we maintain that as well and then rinkybee would just not not fork

um there were a couple of conversations on on github about that um and and generally i think danny you agreed that uh gordy prater makes a lot of sense as a as a

kind of

Danny Ryan: uh yeah yeah something that looks close to maine that and is stable

Tim Beiko: yeah um and then there was i think the other kind of concern is uh how do you actually do an unstable test net so first i think we we discussed the idea of just like you have a public set of of stakers and then that means some of them will like uh you know will drop off and whatnot um adrian in the discord seem to think that uh this is probably like a weak form of chaos and and we might be able to actually do better if we um

if the the validator set is also pretty kind of uh controlled and we can do things like periodically shutting down end portion of the validators um and and uh introducing forks and whatnot so it's that you know by by controlling actually the the set of validators we can we can be more mindful about how we want to kind of create chaos um and then it was also uh i think nimbus worked on this uh this uh insecure test net uh so to like explicitly uh explicitly kind of test some uh some attacks on the beacon chain um i guess generally the people agree with like the idea of having like one kind of

at least one application stable test net which would be gordy prater um after the merge and then we'll have sepolia as well and i'm not sure how exactly but uh to have kind of that one be a bit more uh chaotic in a sense um does anyone have like oh andrew go ahead

Andrew Ashikhmin: uh well it's my personal opinion but i see value in having a hairy test net like robstone so i i wouldn't kill robstone because though it's very hairy it's kind of it's a better reflection of the main net

Tim Beiko: what part of it do you think is valuable to keep

Andrew Ashikhmin: well the state the state of course

gordy

Tim Beiko: i think gordy state is probably as big right now but uh it's maybe worth double checking that

Danny Ryan: and i will note i think it says before a tool at a disposal is a modified version of the deposit contract which allows for the issuance of like a token so it's gated so we can essentially utilize the proof of stake mechanism with this contract as you know something that looks kind of like a proof of authority so for a net that you wanted to do more structured one you know make sure that the community can't overrun it but two also make sure that you control enough of the validators that you can

you know turn half of them off and on um the skating mechanism works well and that would it essentially kind of turns it to look like the way gourley's clique works today in some sense right

Tim Beiko: okay um i don't think yeah we don't have to figure this out today i do think it's valuable for teams to think about it and kind of share you know ideas i saw thomas you just showed something the issue um and generally you know i think pushing folks towards gordy sepolia as very likely to be around after the merge i don't think gordy i don't see a reason why gory would shut down so that one seems just obviously going to be around um sepolia very likely as well uh robson

seems like there's uh kind of an uncertain uh uncertain future there um yeah so if if if you're wondering which which uh tesla to deploy on i think septolia and gordy today are probably the the most important one uh rinkeby a lot of people deploy on i think is the likeliest to be the first to be shut down so if you do have your application on rankb you should start looking at moving over to other other testnets any other thoughts comments on that

okay

Tim Beiko: um okay so next up on the agenda um i guess to put this in context on the last call we had very little time to discuss shanghai but um we we in the last couple of minutes i kind of brought up a series of uh evf object format the ips so 3540 3670 3860 and and uh both in like the last couple of minutes of the call and then i think shortly after the discord uh there seemed to be like strong consensus that those three should should go into shanghai uh or at least you know be moved to cfi so we can start uh we can start testing them on devnets once uh

once we're we're done with the merge work um and then uh obviously seeing those three uh potentially going into shanghai a lot of people came up and proposed a bunch of other eips that they would like to see into shanghai uh so there's different uh evm related eips and there's a 30-74 uh uh there's uh the whole thing about lowering call data costs and and so there's the eip-4488 that we talked about and vitalik has a couple new proposals today um and then beyond that there's obviously other things that like we'd like to do in shanghai that we've mentioned and uh people just like didn't put on the agenda for this specific call but there's obviously the bls pre-compiled um and probably the other biggest one is uh withdrawal the beacon

chain um which does not have an eip yet so i think you know it's probably a mistake to like go over every single eip and and like in a ton of detail um and i think the fear that i have is to like say that um say that like you know this and this eips are included in shanghai and then two calls we say this one and this one and then two calls we say this one and this one and we get to a spot where like the merge is not even out yet and shanghai is already bigger than any other hard fork uh in in the history um so i guess i'm i'd be curious to hear you know from just different client teams what not like high level how do you think about like

prioritizing things in shanghai like what are like the i don't know if it's like buckets or like most important things um and then from there maybe we can like go into the the um yeah go into the kind of different different proposals um yeah i'm happy to start with you actually uh you have a comment and i know there's like uh like four or five different eips that uh that are all kind of somewhat related so yeah if uh yeah if you can just kind of explain how they relate to each other and and what the whole call it like evm improvement bucket looks like that would

be really really valuable

Alex Beregszaszi: um can you guys hear me yes okay um so i would say there are like three different categories of those proposals the first one is what i think should definitely go in as soon as possible and i would start with the limit init code the meter in it code which i believe maybe is 38.55 um that is that is not introducing a new feature that is rather addressing a missing

metering aspect of the system but it also is uh kind of like a building block for the other changes um especially the validation erp um and there's another one in the same category which i think is 38.60 that puts zero instruction and this was also discussed like uh uh i think last year during uh the um last potential heart report and that is a really minor eip but it would help uh solidity um quite a bit um so these two are one category um i hope this could go in and they're kind

of small and have been discussed um at least the limited network has been discussed with the uh goitrium team and to some extent the second category is just the the baseline of the eof aka evm object format changes and that is only two eips again so that's 3540 which defines the the core proposal it only introduces the code and data section um and some basic um rules around those but it doesn't really introduce any any up codes or any other changes um and together with this is a 3670 which is the code validation

i think these two should definitely go in together and these have been around for um quite a bit and then the last category is the actual features and there are two feature eips one is the static relative jumps i can't recall the epi number now but i think that is also quite stable it would help solidity and other languages to use static jumps for pretty much everything with the exception of return from headlight function calls because those still need dynamic jumps um so the cip just introduces static

relative jumps and doesn't remove anything else and then the last dip is what we have been working on for the past um i would say month and a half but it actually started uh like half a year ago with an implementation in evm1 and this is this functions sections proposal which is um i guess quite a bit more complex than everything else i mentioned so far um it all depends on when uh shanghai would come but at this point i'm not that hopeful that the cip would would be considered for that um but this would be the last stepping stone to actually get rid of dynamic jumps entirely um

the static relative jumps jump vip and this um function sections both have been um discussed with the solidity team and they expressed interest um but it's still kind of early so i think this is the summary from epsilon

Tim Beiko: thanks that's that's uh very helpful i think it's probably worth it yeah to get a couple similar summaries from like different uh kind of people who who propose stuff and then we we can have a more general discussion um greg you had uh basically two as well that are also kind of evm improvements uh so the simple subroutine yes and then the safer control flow do you want to

take a minute to go over those

Greg Colvin: yeah i'll try and be faster than usual um 2315 uh remains um responsive criticism of the last one it got pushed um towards back to where it started and a little further as as almost pure mechanism uh and it's now static and uh it's relative and using the same conventions as uh the static relative jumps so those get along together and it's pretty much as fast as i know how to make a subroutine go or

as anyone's figured out for oh 75 years now um but the most important thing for me is the safer control flow which is not a proposal for any op codes it's a proposal for an algorithm at validation time so that's why it's very important to get the validation algorithms in so that we can do other things like this and we want safety we never seem to know what it means it can mean lots of things but i explicitly define it here as

a safe program does not encounter an exceptional halting state and when it's turning complete you can't totally validate that but if you follow reasonable rules you can check a lot so that a valid program will only hit an exceptional halting state if they run out of gas or blow stack in a recursive uh subroutine call and that can be established at validation time given the other eips we have so we have ways to do static jumps and

subroutines and given that if you're using the existing jump um that you use it in a static manner which doesn't just mean that you have to push the address right before you jump yeah the algorithm can track the track the constants on the stack enough to say oh this one actually was pushed as a return address for self routine so it's okay so that's a package that i think it's important to basically get the level of safety we've been talking about uh for the last five or six years without him without imposing any further structure any further up codes

just an algorithm to run um so those those are what are on the table for me

Tim Beiko: got it thanks sir thanks for sharing um i think that the next one on the list was eip 3074. i don't know matt do you have any updates on that or uh i know we've spent a couple calls in the past discussing it but yeah has anything changed from the proposal for for london or is it still generally the same thing it's generally still the same thing we've talked about adding an extra parameter into the auth opcode to allow it to be forward compatible with a world where we want to remove ecdsa as the default authentication mechanism for accounts but generally the proposal has

not changed since mid last year cool thanks

Sam Wilson: the only other thing to mention is that we're having a couple thoughts on where we could go after 3074 and one is like a create three or auth usurp where you can deploy code and replace an eoa and that's kind of something we're toying with but that's like far down the road

Tim Beiko: and those would like build on

3074

Tim Beiko: yeah exactly so yeah you put in 3074 it introduces the authorized address and then you can build on top of that

Vitalik Buterin: is it the replace code with uh replacing the like m e08 with code things strict not strictly dependent on 3074

Sam Wilson: like we just have one way of doing it with

i see it right okay got it

Tim Beiko: um and then uh vitalik you had a comment about different um basically new transaction types which could carry blobs of data and hence reduce uh rollups costs um there were two proposals uh do you want to take a minute to like walk through to each of those

Vitalik Buterin: um sure um so the two proposals are very similar um basically one of them like just does a little bit more plumbing work to move some stuff into the um into the beacon chain that eventually needs to be moved into the beacon chain anyway but the core idea of both of these proposals is um that um so today we have

the execution blocks that have transactions and those transactions have call data and rollups today use uh transaction call data um in the future we're going to have uh shorted data and the way that it's uh looking like sharded data will be introduced is they through this concept of blob carrying transactions which is basically a new transaction type where there is a transaction header which just looks like a regular transaction except it also has a uh an a cryptographic polynomial commitment to the uh to the blob um and the

the headers of all the transactions would still be like in the long term would still be broadcast that included everything would have would happen with them the same way um as today but the blobs would not be like passed around the main peer-to-peer network they would be passed around with like charted peer-to-peer stuff and we and the data availability sampling and and all of that kind of technology so the long-term goal is basically that um sharding would or that these blobs would give us a total space of like somewhere around 32 megabytes per block um and that could be used by roll-ups um and like other kind of data dependent applications

and this is 32 megabytes of like this data would not be directly accessible to the execution layer uh because the intent would be that you you should be able to like verify blocks without actually having the blob so the attack would be to make the whole birds of sharding is that it should be possible to have a network where you don't need any single actor to download all of the data and so the blobs would be this kind of extra this extra much bigger piece of data that gets committed to but um in the channel that everyone sees but broadcasted through this different channel where not everyone needs to download it um so that's the long-term future of sharding right so the idea of both of these uh proposals

is to bring forward the transaction format that would be used in sharding and basically implement it much more quickly but don't yet do the actual starting right so basically yeah we would have these web transactions and the contents of these blob transactions um would be if like you would have the the the header you would have the block commitments you would have the blob uh but the blob would still be kind of part of the transaction contents and it would still be part of a block and like everyone would still have to broadcast it and download it um

but there is there are a couple of advantages so one of the advantages is that it has the kind of 4488 style uh benefit that there is a separate uh limit on the total uh on the total amount of data in this scheme um so like a blog can't have more than two megabytes but there is a separate uh eap1559 update um update rule that makes sure that it stays um basically the the fees adjust and so um until like usage really really picks up if you feel would would be extremely cheap for it and it also has this feature that the the transaction execution actually

cannot touch the blob the the blob contents it can only touch the blob header which me it which just makes it much easier to have like basically do things like forgetting the blob contents much more quickly um and like generally it makes it um a much less of a burden than having like just um i'm having call data where like you it's it's more difficult to treat it because you don't know like whether or not some piece of execution depends on like accessing some random bytes somewhere in the middle of it um so these yeah differ so the there's two eips there the simple version of the eip um it basically just

implements the transaction type and it implements this in this very black boxy way basically it just says there is a u e b 2078 transaction type and there is this kind of black box function that checks the blob and against um against the uh commit the the commitments in the header um and then there are a couple of uh precompiles that let you access the blob uh like or basically prove things about the blob and those pre-compiles would be needed for uh optimistic roll-ups and zk roll-ups to be uh to be able to actually interact with the blob data the more advanced version um does a bit more

plumbing um and it basically moves the blob contents out of the execution chain and it moves them into the beacon chain um and this is something that we are going to have to do for full sharding down the line anyway uh but the basically the more advanced version of this vip um does this basically does this immediately um and so the plumbing just immediately turns into um you have like this one transaction object that gets passed over the network and then only the header gets included in the execution layer um and then the actual blobs and the blob headers would go into the or or the blob commitments would go into the beacon chain um and then there's

eventually once we do a short like proper sharding and data availability sampling it becomes much easier to kind of take the blobs out and start handling them in a different way um so i guess i yeah yeah in terms of like when i would uh like oh oh of the stevie is included i like i personally see two possible paths um but there could be more one of those paths is to be to try to do the simple version and get it included in shanghai um it is uh like possible like and this could could be as an alternative to 448 um it is more complex than than for 488 um but it's still like totally within

you know within reach of implement of uh implementability and that's like much as simpler than a lot of other things the other possible path would be that if we decide that i think if we decide that either of these is infeasible to do by shanghai um then uh we could basically do the more advanced one possibly in the fork after shanghai and then still do uh eip4488 asap and so basically we end up kind of doing both doing both of the stuff gaps

Tim Beiko: got it thanks that's that's really really helpful um sorry just yeah moving on uh because there's uh two more uh so then crowd i know can i

Danny Ryan: can i highlight one thing

this requires a um testing ceremony to do the kcg commitments correct

Vitalik Buterin: um yes correct

Danny Ryan: and there's a dependency there right

Vitalik Buterin: but that's like that can't be done by an independent by a kind of completely separate group and there's months to do it

Danny Ryan: yeah yeah absolutely yeah absolutely i just don't want us to go down this path without acknowledging that that needs to be possible oh yep

great

Tim Beiko: um and so yeah another big bucket thank rod i know you've been working a lot uh on stateless um and there's a couple eips that would help lay the the the the path for it uh do you wanna do

you wanna walk through those quickly as well

Dankrad Feist: um sure yeah um so so i i added some eips that that we kind of roughly started discussing earlier when i introduced the statelessness roadmap where the general idea was we have some gas cost changes that we need to make for state listeners and we want to get those in as early as possible which is to get applications developers yeah work in the correct model rather than continuing uh to deploy contracts that will be inefficient in the in the future model um and then uh

introduce the market partition sorry freeze the microproducer tree and replace it with and add a vocal triad commitment and then as the third step um to um to replace the frozen root with the vertical triwood so that we can have full statelessness with witnesses for everything um and so the eips i introduced for that are 305 8 30 60 and 3062. um 3058 is um about the activating self-destruct that's for me the the highest priority overall like self-destruct it has been discussed

many times deactivating it there are many good reasons for it but particularly in the context of statelessness where we uh where we will have the account storage separated from the from the root of the account so they aren't like there isn't really an easy way to um to change to access all that anymore um self-destruct would become really complex to implement so we really want to get rid of that 305.8 is a simple version which simply says replace self distract with send all and it simply sends all the funds to the caller but does nothing else um [Music] so there has been an analysis there's

basically one major known contract that uses this and there is an alternative way for them to to be upgraded and to implement this so um that would be uh one thing i would suggest for shanghai

um i yes yeah

Martin Holst Swende: when's the one big contract that uses this do you then refer to uh upgrade in place by a self-destruct and then create two or do you mean something else

Dankrad Feist: uh i do not does does anyone use that i'm not aware that anyone uses that i think that the contract that i'm referring to is the spine finance contract um and what they do is they actually replace with the same code

but they currently uh there's a problem that's uh it's basically a a contract that has been used um is in a state where anyone can take the funds um so that that that problem can be fixed um yeah i i'm not aware of any contract that that up upgrades using create two

Martin Holst Swende: yeah but are you not aware because you've searched and not found or

Dankrad Feist: yes someone has done the search for this yes yeah that was a few months ago though so um i

guess

Vitalik Buterin: um right this was like some you know like there was someone who like was like be explicitly assigned like what's the deal like was it even a grant or something like that like basically the job of like looking for um things that it would break and they only found that that fine finance thing

Dankrad Feist: so in terms of so that's the only one there were some others where the code was unknown and high in finance was the top one the one with the major deployments that had i i don't think they went 100 through all contracts so there's still a long tale of smaller contracts that someone might want to look through but they are much smaller value and much smaller

dependence

you

Vitalik Buterin: got it um um by the way after we're done with this one i i just reminded there's another breaking change that i think i think red is the importance the the the verbal thing that we should thought that we should talk about but this is about the chunk gas cost but maybe finish this first right yeah

Dankrad Feist: um so um if we are very concerned about like self-destruct that we're gonna break something when we introduce it um i wrote down an alternative version that's 3060 that basically uh ends like uh the end result is the same um but it

goes through a phase where the the self-destruct upgrade gas cost increases exponentially over a few months and so the idea is that it seems that many people in the ethereum ecosystems don't watch out like four road maps and uh changes that will be introduced and so on uh and that includes application developers um but in this case anyone who still uses self-distract would notice over those months that hey my gas costs are increasing exponentially maybe i should check what's happening and they would hopefully have enough time to safely upgrade their contracts in that time frame or get all the fans out that are still in there coordinate something

so that's 3060 it of course is a little bit more complex but also not super complex and uh yeah would be would be an alternative if if we think that uh there's like yeah we should get everyone ample notice and make sure that they will notice that something's happening um and then uh so so one of these two um i would really like to see included in shanghai if possible um then there's also three or six two which is which i've unbanned unvented previously we have had written it down as one but that's the actual gas cost changes

um that that basically introduces the um yeah the the the witness costs for vertical trees what this basically does is it adds a new cost for accessing code so that increases gas cost and there's also a decrease in gas cost when you access adjacent storage slots or slots that will be adjacent with vocal trees um and the latter means that that clients will have to have a certain database layout implemented in order to not make that um a dos factor um

i think guyum is still in the process of uh of communicating to all teams whether they will be able to to achieve this um so this is definitely a somewhat deeper change and uh um yeah and yeah more complex than just the deactivating self-destruct um and i guess like there has been the idea of just uncoupling them and just do the increases first which clearly doesn't introduce a dos vector i think i'm not a big fan of that because that yeah i think like application developers would be annoyed if we strictly increase all their gas costs without giving them anything in return um so if we can't do that then we might just

have to wait with those changes until the actual introduction of work retrieves but i think it's still interesting if the database upgrades are progressing well um i think this eip should still be considered um because i think it's best to let applications um become efficient as early as possible because all the contracts that that are deployed in the meantime i are all very likely to going to be a sub optimal once worker trees are introduced

okay yep that's that's it from me okay and

Tim Beiko: i think one i think this was everyone who posted something on the agenda one thing i think that would be

valuable uh danny i don't know if you have uh i know there's no eip for it yet but do you have a high level idea of what beacon chain withdrawals will imply yeah execution layer

Danny Ryan: yeah so essentially it's the exposing of a um a commitment to withdrawal receipts and then the consumption of those commitments at the execution layer by a normal transaction which would move the balance of that receipt into a contract or account specified in that receipt so um this is a precompile or a special contract or

something that essentially a normal transaction can be hit with the proof of receipt against commitment and and track there the receipts are indexed so as simple as a bit field in the state um can mark the consumption of the receipts the i i believe that alex has a lot of this written down and we're actually gonna be meeting in person next week and plan to have um something of a draft to be shared by them really it's commitment to receipts consumption of receipts by a normal transaction uh moving the eth into an account and then the tracking of consumed receipts

Tim Beiko: got it thanks um and then finally like there's obviously people who didn't uh just post their eep on on on the call agenda and and and there's a couple like other uh valuable ones we've talked about in the past uh 2537 keeps coming up so the bls pre-compile is is one that people keep uh saying we should have uh we we had i think a couple calls ago a discussion about uh the transient storage up codes eip 1153 um and i know there's a couple others that have been pending for like a a much longer time uh i think thomas you were championing eip2937 to have uh the

i actually forget the title sorry uh yeah saving the historical block hashes in the state um uh 2930 sorry um so there are others as well um and so you know off the top of my head there's probably like 15 maybe 20ish that are being considered across like very different buckets um there's a couple comments in the chapter about how anything that kind of increases throughput reduces uh transaction fees is is probably something you want to prioritize whether that's a 4488 or or a simple kind of uh mini sharding i believe it was called um

and yeah and you know every everything else like i think the evm upgrades uh have have been uh have been pending for a long time um i guess first of all you know i i'd be curious to hear maybe from client teams like what are you think like the top one or two things that are like most important for for shanghai um that's probably a good way to like start thinking about this and yeah and andrew i see you you have your hands up

yeah

Andrew Ashikhmin: so because we desperately need scalability i would say

something along the lines of blob carrying transactions is priority number one either in its simple or more complex form and priority number two is the basic blocks of evm improvements so 35 40 36 70 and 38 60. so my understanding that those three are kind of the the basic building block uh and priority number three is deactivating self-destruct is in its kind of simple form maybe or maybe more complicated but to deactivate self-destruct that would allow us to that would simplify the evm

would allow vocal trends things like that that yeah that's my take

Tim Beiko: thanks and any other client team wanted to share our thoughts

Martin Holst Swende: um i don't know if i speak about forget though we haven't really discussed it internally uh i would agree with what andrew said at least for the first two i agree about we need focus on scaling but i have not really started the whole blob proposal in depth so i i think

it's a new proposal so yes

Martin Holst Swende: i mean

in theory i think it's great but i i need to get it more also i think the evm improvement with the eof those first steps should be taken because they enabled so much more and regarding self-destruct i don't know if i agree with that um and i think there are a few that are pretty trivial to fix that i think maybe we could include us but um i'm not sure what else would be prioritized i think oh yeah one more thing i just wanted to mention so this 30-74 i know that there has been

some some opposition not only from me but also there's this counterproposal which would not introduce consensus changes uh by joao weiss and vitalik uh maybe it's not time for that discussion now but at some point i would be curious to hear the like pros and cons of the two approaches but we can yeah probably not time for that today

Sam Wilson: are you talking about four three three seven i think like the account abstraction proposal

Martin Holst Swende: yeah yeah yeah

Sam Wilson: i don't think they're mutually exclusive they just solve different problems um yeah i think one of the big differences just to put it in for 10 seconds is that 4337 does not help people who already have eoas only people who will deploy new contracts under that paradigm

Tim Beiko: oh got it i think that i've had this question asked several times uh sam and matt i think like and i think matthew actually had a twitter thread about this but i think if if either of you could write like a short hackmd document or something just the tldr uh and post it in the the 3074 discussion link oh actually this nethermine already did it so i guess martin you can you can read the the post that thomas just shared yep thanks um of course as aragon get yeah thomas i'm curious you've been you've been sharing a lot of

comments you want to take a minute or two to walk through what you see like from nethermine's perspective uh it's as being like a priority and and useful

Tomasz Stańczak: so personally i don't really have priorities it's more about the sheer amount of all the different eaps that we see on the list uh since long least which is good that we come into good old times when you get those lists of 20 and so on and we're filtering them down uh i think it's up to community and others who actually are champions for those eips to say like why and yeah personally i have no priorities here like the simple ones would be on my priority lines like if we all agree they are good to go it's

relatively simple to introduce and test i think the ones that deal with the code like the object model and so on um i would say yeah they go in as for the ones with subroutines i was thinking maybe and i suggested that on the thread that uh this might be controversial to split the conversations where the merge conversations happen between the f2 and if one team on all core devs to merge call and then we have dip teams that work on pushing the modifications to avm and um and execution layer clients so this thing can work in parallel and don't feel that there is some kind of um

conflict between the merge effort the merge work and tips work this uh those meetings would be even more efficient and we would start seeing those teams uh since we like when you look at the list here it's 40 people and we have like this two separate parts of the meeting uh so maybe there's a natural suggestion here that this is the way to go

Tim Beiko: yeah i think i've been thinking about that one of the challenges is that at the end it is kind of blocked on the same people implementing it right like so we can and we can have like separate meetings so like discuss the eips but like you do want input from the client developers who who will be implementing it and i think it's probably not the end of the world

if they kind of happen in parallel just because like we are still like the merge is not done it's not shipped yet we still have time to like slowly kind of get into this stuff before we we we need to be you know solely focused on it and i think it'll kind of maybe naturally happen once the merge stuff is done then we're not going to talk about the merge stuff anymore we'll be like 100 on shanghai and then like when shanghai is pretty done we'll be like half on the the next fork um so i don't know yeah i i need to think about it more i but i think there is like a i i agree there's a lot of like eip champions who like don't care about the merge stuff but i'm not sure that the opposite is true that like the people

working on the merge can be kind of excluded from like the vip discussions yeah yeah thomas

Tomasz Stańczak: maybe if you ask me about like pushing pushing ethereum the mouse forward with vips then the blob transactions or something similar would be on the highest interest

Tim Beiko: thanks that's useful

Micah Zoltu: um does your statement the same people are working on the merge as the eips uh i agree the same teams are working on them but i kind of have assumed that within the teams they had multiple people and so it's not necessarily the same humans

Tim Beiko: i think it's harder

fully parallelized than people generally assume um and you do end up like sure some different people might write the code but it gets merged into the same code base people need to review this stuff and so i yeah i don't know i i guess what would really change my mind here if client teams all signaled that hey we can actually do like two fully separate tracks and and and that's that's helpful that i i think that would that would uh change my mind it's just like from client teams that's usually not the feedback i've gotten

Martin Holst Swende: yeah i was just going to say you're

probably not going to have my client team saying hey we can we can work in multiple tracks and do anything you throw at us right because

Danny Ryan: there's always another multi-track which is like maintenance optimizations and like all the things that aren't new features yeah

Tim Beiko: yeah that that makes sense thomas is your hand still up is there like another comment or did you just forget to oh okay just wrote it up cool um basu uh curious yeah what you all think um [Music] about this

you talking agreement

Danno Ferrin: what i've heard before um eos i think are just foundational for solving a lot of problems going forward

with a lot of things particularly the things like jump optimization uh jump table um the size scope separation of the data those are very subtle implications that i think will be long-term very valuable um my biggest concern is upstream adoption of these issues uh specifically talking about things like the solidity compiler the viper compiler um if if they're not generating the features that are doing an eip then it's a one one one point of view would be a little bit wasted time the other point of view is we're not getting um an extra category of test tries of what they're actually going to try in the field and in the wild we can come up with great ideas and reference tests but we really also need to test it with what's going to come down the pipe from the compilers

so of all of these things the next question is also um how on board is the solidity team in the viable team with these changes salinity has uf implemented um great um all the pieces all three of the pieces all five of the pieces just a container you know those those are the questions to come up with that and so it looks like positive for the eos stuff would be my take

Tim Beiko: cool um i guess you know it seems like there is kind of a general agreement that like uh eo like the simple kind of fills first building blocks of eofs which i think are what we basically discussed on the last call um are high priority that beyond that like

the blob transactions are are potentially really useful but there's a lot of unknowns i think there were some comments in the chats about trying to prototype that at denver um and then the other thing i think we probably have a slight bias here is the the beacon chain withdrawals where i think from the like staking community that's basically impossible to ignore um so i know would it make sense in terms of next steps i know uh like the the first couple eofs i think it was let me just check the numbers it's like 35 40 36 70 3860 to basically

move those street to cfi like we discussed on the last call see over the next couple weeks if the if the transaction uh the blob transactions can be prototyped at in denver and and how um you know how complex it is and and what that actually looks like um and and based on having more information we can we can see you know whether which one of the two proposals might make sense for shanghai and and if not uh kind of revert back to to uh 40 48 or if if there's something we need to fix we'll have still a few months to fix it um and then i think also in the next you know not necessarily a couple weeks maybe uh we also get like a beacon chain withdrawal eip which which we can we can

look at um yeah i guess summarize like moving kind of the the i think this would be 3540 which is the eof uh kind of core eip 3670 which is the eof code validation and 3860 which was limit and meter init code moving those to sort of cfi for being the first we would try out on devnets in shanghai and then um prototyping the blob transactions and and once we have a beacon chain withdrawal eip we can we can discuss that in more detail there's any strong objections now's your

chance okay cool so let's let's go with that uh i'll put together a draft uh basically spec for for shanghai uh either today or early next week which has those um i do think so we're probably getting pretty late in terms of considering new proposals i think if if people have stuff that's completely new like it was good to share them today and there's probably you know one or two more calls where we can realistically consider new ideas but it does seem like um yeah what's trying to prioritize what's in there and i think once we once we also are a bit farther along with the merge

work um and and and we're kind of waiting for it to happen on test nets and main nets we can actually implement these new things on on devnets and see you know how much work they are how much uh interplay there is between them how complex it is to test them all and i think that'll give us kind of a good idea of how much bandwidth we have if if we do like some evm upgrades uh we add withdrawals and something around uh basically transaction data costs um yeah beyond that i think we can kind of decide once we've once we've actually implemented stuff and have a better idea cool

um no objections so i'll take that uh yeah i think that's a good sign two more final things uh before we wrap up uh one is uh the quilt team has been working uh over the past few months on an executable spec for ethereum um so um yeah it's a really important piece of work it would move us uh in line with how the consensus error teams do that and solve a lot of the problems we have when writing eips where it can get awkward to specify the changes all in line in the eip um sam do you want to take a couple minutes to walk us through um yeah to walk us through this

Sam Wilson: sure yeah um i won't take too much time uh drove me to share my screen or yeah yeah yeah if you can go for it okay you have 10 minutes and kind of nothing else except an announcement so you can go for it all right so um the execution specs are very very similar to the consensus layer specs the only difference is they're written in python first and then compiled into html as opposed to being written in markdown so here's kind of an example of what it kind of looks like from spurious dragon it's very idiomatic python well it's actually very simple python uh very understandable should be easy for most people to contribute to we're kind of looking for feedback on how useful this would be for client teams and maybe have a discussion at

some point about how we want to change the eip process um so this is the raw view of what it looks like um so you can kind of see how like validating a block header works so we haven't actually written the annotations yet um nice thing about this is the annotations will be in line with the spec but you can turn them off if you're an experienced user um so moving on to like what kind of the rendered uh specification looks like it's sphinx we haven't done a lot of work on the theming yet so we can definitely make this look better but um yeah it's searchable it's navigable you could actually get links to different data types and and it's it's kind of useful there um and you know the real kind of killer feature that we're trying to work on is um

like having a diff so this is a diff between tangerine whistle and spurious dragon for the same file so you can kind of see how a function was removed two were added there are still some bugs in this where the navigation doesn't work properly but we're working on it so you can actually see how exactly the code changes between hard forks and one of the goals of the project is to maintain these diffs so that they're incredibly clean and easy for for client devs to to follow along and implement the changes and we want to integrate this into the eip process like i mentioned earlier so that's kind of like we want an eip to be a text document still but any changes to consensus would also be specified as a diff to the python specification so you

can actually see like as you're developing a hard fork you can create one of these rendered documents that describes exactly how the hard fork is going to look like in in code and i you know do you guys think that's going to be useful is this something you'd like to see if you have any feedback now now's a great time to think about it

Martin Holst Swende: i i think it looks awesome but i'm curious um does it pass all the blockchain tests and state tests and it can can you even take this reference code and [Music] throw state tests against it

Sam Wilson: yep yeah so we run the legacy tests right now um

we're kind of working our way through getting all of the testing frameworks set up but that is a goal is we want to eventually use it for filling tests as well so we want to implement everything we need for that

Martin Holst Swende: awesome

Danny Ryan: yeah so we on the compensator side like prs for new features don't get merged without tests that would be generated for client teams so um i'm i'm pretty pro getting this on the execution layer side so that when things are specified you kind of by default as part of the process have tests integrated

Sam Wilson: i just want to

give a shout out to voice peter and guru who have been helping a lot with us just want to make sure that they get mentioned too

Tim Beiko: yeah i think this is like a really really valuable effort on some of the work that's like yeah kind of behind the scenes um and i think it would be really nice if we could be in a spot where we do use this to specify kind of the consensus changes of eips and similarly if consensus layer teams could start using eips to specify the english definitions of their changes so we could kind of uh have a single system where you know eips are just like the written text that that describes kind of the rationale and and and

overview of a change and then it just links to a pr on whether it's the execution layer specs or the consensus layer specs uh which which actually has the technical um the the technical uh details um and that will add some vip editing job for micah which he's not about happy about it seems um but i think and and i think the reason i i guess my short argument for uh eips on the consensus layer is they do make it much much easier to communicate these changes to a broader set of people um people are like like it's easy to anchor like this change is

eip1234 and people know that rather than like this pr to the spec it's just like an accessibility thing i think and

i

Danny Ryan: i very much agree um like it and it's not always just a pr sometimes it's six pr's right that after some subsequent changes so like mapping that into a kind of a single place to discuss the change set i think is is very very valuable so i was gonna i was gonna say i do not recommend only having an executable spec and trying to map a uh you know what we do in the eip process for that i i think you need something to accompany it

Sam Wilson: yeah yeah so i think

direction ideally we'd have both so you'd have like just the specification part of the eip where possible would be rewritten as like a python diff yeah

Danny Ryan: okay i mean i i definitely agree

uh could you since you can also generate html from the python spec could you also generate other languages or have a plugin structure to be able to so that client teams can implement their own plugin to generate their own language like uh yeah their the aip directly in the in their target language and then be able to tweak it to make it work that would mean some typing

Sam Wilson: yeah i think it's possible i don't know um how practical that would be and i don't think that's something like me

personally i'm interested in supporting but yes it's absolutely possible for people to do that their regular python programs you can do whatever you can do with python you can do with this

uh thank great you have your hand up yeah

Dankrad Feist: i just wonder if there's a possible future where we have both specs in one repo because then because otherwise there will always be this awkward situation with all the um any eip that needs to touch both specs that they they can't really like have like one uh comprehensive diff so that would be fairly nice i think but i don't know if that's possible

maybe we get there it's yeah i

Danny Ryan: i also see the argument for keeping it separate so that you know you don't encumber these processes until you're trying to do some sort of release but the cross cross layer testing on those cross their eips i see the value there i i would like on the consensus player um you know sam and the others that have been working on this have done an awesome job uh making a more sane approach doing this and uh kind of code first that builds really nicely and we we do want to migrate to use at least the same format over time the diff functionality is definitely killer feature

Tim Beiko: and one thing i'll add is um i think the echo that he says like there's value in trying to keep these processes separate just if it means we can be a bit quicker so like i think literally 10 minutes ago we were talking about in the comments splitting eips work from merge work and so i think even though it's a bit awkward at like a organizational level we do gain a lot of velocity from having the consensus layer split as much as possible from the execution layer in terms of processes um and and yeah so i think if if we couple stuff we want to be really mindful that we don't uh we don't end up to a spot where like

we're now even more bottlenecked than we currently are um um cool we have less than a minute uh the last thing uh is we have a merge community call trent do you want to give a quick shout out for that

Trent Van Epps: uh not much more than what you just said but it's yeah february 11th uh alternating friday from this call so if anybody would like to show up and interface with the community answer questions we'd be more than happy to host you

Tim Beiko: yeah so exactly a week from now at the same start time as alcohol devs 1400 utc um

yeah we'll answer application uh and infrastructure tooling developers uh questions about the merge cool anything else before we go okay uh thanks not everybody this was this is really really good um appreciate everybody's participation

thanks time see you [Music] [Music]

[Music] [Music] [Music]

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

[Music] [Music] you

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