All Core Devs - Execution #75

All Core Devs - Execution · 15 Nov 2019 · 1:02:41

Ethereum core developers cover Istanbul adoption, with new Parity and Geth releases, Berlin updates, Harmony and ethereumJ, testing updates, eligibility for inclusion reviews of EIP-2348 on validated EVM contracts and EIP-1803 on renaming opcodes, and the EIPIP meeting.

Speakers

Topics

From All Core Devs - Execution, hosted by Ethereum Foundation.

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] hello and welcome to the etherium core

developer meeting number 75 let's get started the first agenda item is Istanbul adoption and a call for assistance let's see do we have any updates for Istanbul adoption other than I think parity has an update about their client being released and what number that is yeah yeah 33 M just released update that includes the block height number and all the EIP s that are accepted and finalized so we recommend everyone to update there's also some work sink

improvements but you can read more in the details in the same great thank you anybody else have an update okay great anyone else perfect I think that's except for Trinity I think that's pretty

much all major clients that are active right now okay so James posted a call for assistance to help the ether nodes website the ether nodes dot org slash Istanbul website to reach out to different mining pools infrastructure providers and exchanges and see if they can update to their latest versions of their clients right now ether chain is the only one who's confirmed to have been updated and the cat herders and the others are going to help reach out to them but if any one just happens

talk to any of those groups just let him know to update maybe send out some tweets to them stuff like that James was there anything else just that we're at I 16% adoption so far on the way to Istanbul and we have some better data this time that we've ever had from ether nodes about the adoption and it'll be great for next time you used this as a benchmark how we're doing as a community as for adopting we're made of adoption and anyone reach out to me if you either have connections or know how to connect

because I actually working on this oh sorry I was meted okay thank you very much by the way I just updated the agenda sorry everybody if you can refresh okay anything else on this sample okay the next item is Berlin updates and I think that's just a carryover from the last agenda because I think since we're doing EIP centric now we're just gonna go over a ip's and whatever happens makes it into there unless someone who needs to talk about the timing or anything like that okay so

we have an update from harmony slash aetherium Jason McHale you can go ahead yeah harmony team to say that we stopped maintain the TMJ and harmony and legacy ether camp projects like so CJ the main reason behind this is that we are completely dedicated for is 2.0 development and just don't have engineering resource resources to maintain all the stuff also there are this efforts um so that's pretty much it I guess thanks everybody

yeah thanks McHale it's been great to have you on the call the last few years and see aetherium Jay supported it was one of the I think it was one of the earliest of theorem clients along with a left and death so and Piatt theory or PI app at the time so yeah it's been a it's been a long time and thank you so much for all the support all right testing updates I think we have one from Andre who's not on the call test death actually is Demetri on here now I'll

just say the announcement test death tool now supports generating test with a string like Istanbul + e IP number instead of a fork name this could be useful for the EIP centric process if anyone would like to look into prototyping e IPS on the left then they'll have a link with details this is the last comment on the agenda if anyone wants to look at that a little bit closer is there anyone else with testing updates not really gumbo so that thing he mentioned is guess already supports it and it

basically means that if anyone wants to make test cases for a particular eat then you can make those test cases without the Berlin heart for being too fine you can just yeah base it on the only heart for it like frontier plus your ich number and activated for test cases so that's pretty nice and that's about it okay thank you anybody else all right everybody get hype we're at item number 5 and that is

eligibility for inclusion I pee review we have two e IPS today the first one is e IP two three four eight validated EVM contracts I believed Ana was gonna talk about that just by you know giving an overview of that and then we can discuss different discussion topics on it so go ahead Anna okay so the validated EVM contract is kind of a conglomerate of several ideas that are floating around the e IPS for a while trying to and Mike my main goal for this is to try to get something that builds a foundation primarily for multi-body bbm instructions there's been

a lot of proposals for EVM opcodes that have been multibyte and one of the things I've pointed out in the rationale is that somebody can't find the link right now but there was a demonstration that just adding in that a multi by a multi byte code right now will actually break some executions because if you have a multi bite that contains one byte after it that is the jump destination and then you run it with the new version that jump destination will be removed and you can theoretically break that on that's a combination of one of the four features there's four basic features that we're combining into this this conglomerate VIP the first one is to actually use the EIP 1702 versioning

infrastructure to to turn on since after this point all the other options in the CIP are eligible for use but the version one the second one is to use the the headers into the EVM options that's one of the one of the alternatives that was listed in the NQ 1702 for how to allow code to opt in to a new versioning scheme and I think this is essential that we provide some octave or somebody's you see I want to be out of the old system because otherwise I'm gonna have to upgrade all the tools and make sure that nobody ever uses an older version of solidity to compile their main net code which I just don't think is sustainable I think it's more sustainable to combine the header and also one of the opcodes from the EIP

615 which is the begin data hub to present an envelope around your EVM code so it activation we would turn on on the EFI system to versioning at the inter version one account if you start your EDM code with the marker which could be you know zero zero zero one and end it with the either don't end it or ended with the begin data you can still put all of your things afterwards there are some flags and solidity that allow you to put the or hash of your source code in your EVM code and that goes on to the next thing that we want to fix which is invalid op codes is that those form hashes will have invalid outputs if the EVM tries to execute those hashes it's

going to blow up whether this opcode doesn't exist so if I I put in the wrapper around the EVM code we can say this is the only code that's executable and anyone who wants to put all their other extra metadata about their in class like what the spore hash code is completed after the begin data that's the third step in the fourth step I'm putting in there as well we're going in and adding this well the third step as part of the third step I skipped where we actually validate the code within that wrapper so once we have that set up inside the wrapper when you deploy your contract there is a validation steps that we go through to make sure that each code point is actually a valid code point and if you're applying enough if you're deploying an OP code that doesn't exist then it's rejected because it

doesn't exist now in the future it might exist as a multi buyer single bike but we just don't know that so the EVM would evaluate the opcodes against the no-knock code list and reject it and while we're at it I'm adding in an option to do static gem validation on yeah not an option but when you have a push end code and you have a jump code afterwards we validate that so that's one validation now that's perfect because you can still have jump codes that are done dynamically but those are happening less and less since you know we don't have to push all these if this has issues we can take the static jump validation out and push you

didn't get another version but that's something we'd like to have a discussion about at the very least I think those are the four parts so the way it would work is that you would opt in so questions from the floor yes type of question you said their main I didn't really understand your main motivation about multi bytes of could explain that again so we need to validate the contracts before they go onto the chain and we need some mechanism to do that that is that will prove that all our codes in this code stream are going to be valid op codes so that has to go with the opt-in if we don't validate them that people can put in an unused octave and the very next

byte can be the jump destination operation and the way the EVM works now you can jump that jump desktop to make operation you can jump over all the invalid code so if the bike that they had before the jump desk becomes a multi-line code when you interpret it you're not supposed to jump into the destinations like you can't jump in the middle of a push in operation so like every jump publications if you bring in another multi byte code we would need to jump over all the contents okay so I thought I thought you meant that introducing about the button more multiple codes today would break existing ones but what you mean is rather that someone could intentionally produce a contract which behaves differently after the introduction of

the new opcode right and I haven't done a full investigation of all of the upper all the contracts on the net but considering that we are in a in an environment where people will break things because again between the timing specified us that's how you deploy that if that's a problem we should just expect that someone's and then deploy a contract that breaks that invariance so in this in the case that you're describing here what if I try to execute as in it code some code that is preceded by this header so that's one of the questions that is open in this what should we do

with that header code one thing is we could have a VM when they recognize it discard it and move the PC to zero invite five in a stream another option is we would recognize it and discard it and make PC for me to be getting the operation of PC for the stream and another option is to make it a multibyte no op operation so make it the code header it is 1 by 3 bytes afterward that's you know there's three different solutions right there that we can use to make sure that this header doesn't accidentally get executed and I'd like to mention when you do create and create two they would also need to include the header and the wrapper in

the create two data as well so whatever they load into the memory would also need that the reason I'm concerned about PC 0 and the index lighting up is you can still get up the header with the ext code copy operation and that's why I'm not liking the idea initially thought it was a good idea but I'm not liking it of having piece equals 0 be at the 4th index of the stream because I think those should still line up it's a little bit consistency so of those three I've ok with any of them from recommendations from other ones my favorite one is to turn the header into a multi-byte know ah I would disagree for the reasons that I posted on the heap because if you can

have in it code which is supposedly validated but in fact it's I mean it needs to be validated at runtime but your proposal means that you should validated at deploy time but there's no deploy time for unit code I'm talking about the init code execution notes right so that would also be valid in the same time when it executes from the transaction that's a prompt on run time there's Fernet code there is no the time other than run time is there exactly so that means first time you see the code you have to validate it right and that's

so and that that makes it vulnerable to attack did you say that I posted ly on the ears only one the one coming in posters what about jump operations not preceded by push in conversation and then I post a comment on that yeah that came in four hours ago and it's 7:00 a.m. where I'm at so I haven't read all right okay yeah I'm short version is init code is very cheap to execute because you don't expand memory once and can have a megabyte of init code and you can run it and then you can flip a bite somewhere and you can run it again at only 700 cost and if we need to

do the validation up from right now that's fairly cheap we just have to do one pass on the on the code and flip a few bits in there but if we do it your way then we need to do two passes and do a lot more flipping y-yeah because in order to verify that a static jump is legal you need to first have the full jump sets jump destination set jump may be going forward and not only backwards right seeking two sets one is where I'm jumping to and ones where I have it you

collect those once and you compare those lists at the end that there's differences you reject but the list could conceivably be two megabytes if the code is two megabytes so we write you're off the jump validation for a future yeah I think it's kind of attackable if if it works like that so I think they'll only way to achieve what you want would be to not allow validated code in in a code since that's there's no deployed

time for it there's only a long time so [Music] is it over the jump ballad ation that requires a multiple flips because there's the header at the beginning want to see begin data you stop validating because you know it's not going to be executed I mean just make sure each opcode as you pass it is valid and if it's not you know it should I I'm just intending this to be a one pass validation including against existing validations so I think requires you I could pass go ahead yeah I don't think you can do it in one pass though well

you maybe you can but it might open you up to memory memory problems because if you do it the way we do it can give you just pre-allocate a bitmap and flip the bits in it but if you do it the other way around that you instead maintain every time you hit the jump test you put it in some queue or list or something that means there's a memory allocation vulnerability and that's basically why why I guess was attacked by this a couple years ago because we did just that we maintain the map about the jump destinations and doing that over and over again just choked to death on this one megabyte contract with jump

destinations okay that's that's good feedback so we go through the process I wasn't aware that that was one of the attacks I'll read through the comment but I'm finding out if there's a known attack I don't know if you need to pull it out but I think you do need to remove it from not a validation of the init code but otherwise I think that's basic okay so me too validation modes um okay I'll take that under advisement I do the prototype and see let's see how messy it gets okay anyone else have any comments on that okay thanks for that

we'll move on to EIP 1803 renamed opcodes for clarity and we have Martin lund fall on the call who wanted to bring this up I'm not sure if that you wanted to bring this up as an EFI official you're just discussed this Martin I just wanted to discuss it really it shouldn't require hard fork and so I think the European South Australia on controversial I just wanted to have it raised here because it seems like there might be a tendency to not discuss as much yeah I piece that aren't needing a fork but what this would change is some of the infrastructure

around testing and just in general it would be nice to have coherency around how op codes are named the core reason for why I want to discuss this is mainly in renaming the opcode sha-3 to catch shock since this hasn't been done in solidity already and it's generally really confusing that's the one that I made my concern about but I think the other naming suggestions are good too so this is Alex proposal I didn't write it but he's not here on the call so I just

wanted to haven't discussed so I think the problem with I mean we could easily make this change but the problem is do we screw up for two operators around the world for example tracers and what have you start using different names that's what kind of problem I see I mean yeah exactly the this why I just want to have a synchronous change to how everybody the deals with trace and debugging tools would go over for this change how difficult would this be to implement or

would it just be a lot of changing it yeah that's why I was kind of thinking I mean it'd be trivial for one tool but if you have anyone else have comments I mean it looks like really like make for example the pylons I'm getting this this yeah Pete will be eligible for inclusion

probably implemented it might be the case that for the timing of this one should still synchronize it with hard fork just so that when people are updating their tooling regardless to to be compatible with the next hard fork they would also include this change yeah I could get on board with this - I'd be happy to hear objections for like things that people know would break but a lot of the usage of the text names for op codes I mean it's C they tend to be in human readable contexts not that there

aren't machine readable context that they're used but but I mean it'd be something that we could at least consider moving forward with under the condition that we're kind of like waiting to hear from people that that we know 30 you know that are raising concerns for things that they know would break but it'd be interesting to at least explore this I would actually prefer not to do it in combination with a hard fork if it is the case that there's a higher likelihood of a screw-up during hard fork it'd be good if we don't also have broken tooling because we changed the

naming of things so instead we changed his name during a low activity period I think for additional feedback martin lund fall I would say that because this is a pretty old AI there's a magician's thread on it when was the last time that was even touched though that was okay June there's just a few comments if you could revive that magician's thread post it to Twitter and reddit and other social media that you feel is applicable and get more people to voice their support maybe even some

of the people writing these auditing tools that use this and who could benefit from it I think that would be helpful and getting this universally pushed forward and then when you feel it has enough feedback bringing it back to the core dev meeting and we can give kind of the official where like the client devs are gonna do this thing all right that sounds good thanks should we just say this is like eligible and then if if we come back and like a month or two you and you know there is like feedback and it seems like a good idea that we just move it to accept it well here's the interesting

thing this isn't a core hypee it's a standards track EIP but it's more for well I guess is it a core EIP even though it doesn't have to do with a hard fork it's sort of weird and that it as touch some of that stuff but it's not like consensus-based yeah we need to work we're good I'll be talking about later about redoing the EIP process so this can come up then but let's go ahead and just keep it since we're practicing on this whole eligible for inclusion thing we'll keep it as an EFI and add it to the meta for the EFI switch will be talk which is now linked in the core deaf agenda under yeah EFI

EIP review and I think yeah that's what James did and yeah we'll come back to this for sure is this something we should we should be moved last call and then have that beat and accelerate people giving back um it depends on how fast Martin wants to do that Martin would you this be a do you want to put it to last call which gives it a two-week period before acceptance meaning the next core dev meeting it would be decided or not or do you want a little more time to gauge the community I'm fine with moving it to last call right now yeah the IPS I will move for to eligible literacy for inclusion would

be at least in last course status because I just I mean in draft status he can still be change and and there may be confusion what was a specification actually so just a suggestion oh you mean for the eligibility for inclusion yeah process we're going through I would say I think the reason we're doing it this way is so that we can give a preliminary almost like a thumbs-up but not anything official for people to continue to do research and potentially prototyping on their AIP which actually dictates that it should change and specification based on

feedback so I would say we should probably do it that way based on what we talked about last time but look we can definitely look at other things too the specification is mature enough to be so before we move that into yes I I mean the thing is even if starters we can have like between last call and draft we have another start of saying education it's almost Rosen because I mean there could be two in the first set or maybe

seems like simple changes that completely change the perspective of the yeah II green new attacks or or make some implementations really hard to implement so yeah so when we say EFI we're not saying that you know you can go do whatever you want there is another gateway point that that has to pass through the all core - who says let's put this in a fork now and so I think we need to consider where we want to pile up all these objections if we pile them up to the very beginning in the process then we really haven't changed anything and I think one of things I like about more into proposal to be IP centric is he getting preliminary thumbs up and then he

implemented and you can see you know when you implement from aspect unless you're very thorough with the spec you don't see anything even then there are certain engineering problems that you won't see by going into the handling of the spec so you know I think the final you know vetting of it for multiple clients we need a full specification before you know the other clients implement it but I think that you know fixing that implement specification and eligible for inclusion I think is is to hampering I mean at least should be mature enough it's if is I mean we have those kind of specifications rather just

placeholders and just a quite weak adhered and I don't think we can catch those seems to be in EFI just I mean it's is is this true that probably most hotels would agree our channel direction but that direction needs to come in to a really concrete specification before we move into yeah I don't believe these Sciences stay out the process or something because even if a speculation is mounting yeah if I there's nothing stuff anyone from

actually increment this thing into a PR to propose it to all the clans and I think I understand what you're trying to prevent or you're trying to prevent these a IPS that aren't very well formed from stacking up and like clouding the process is that kind of what you're getting at yeah yes yeah I I so if you're wanting to prevent that I think there are other more nuanced ways to do it that that don't which could be just highly recommending that an idea be fleshed out

and received some sort of community feedback before coming in because I think it's not it's kind of unspoken the level of maturity something should be before it goes in the efi and i think that's something that we don't need to make a hard rule on right now and that over time we'll kind of see where that goes or where that forms and we might have to get as strict as what you're suggesting but I don't see the need to do that right now while we're still forming the process I agree but I what I was seeing like like we have the spectrum of the on the really lifestyle we have ideas and on the really right

side we have really well from Suffocation's what I'm saying is like a IP issue if it's only idea we really can't determine whether it is suitable for EFI really should be at least somewhere in the middle it should be at least have some kind of education and stuff like that before we can decide whether it is super for yeah I fight so yeah I agree we don't need a formal rule right now but that's just my opinion got it okay so yeah we should be somewhere in the middle for sure but

like what were you saying data one of the barriers is can prevent people from implementing things that haven't been blessed by awkward deaths is money and that was the point of this what was originally called blessed aid it is to give some indication from the awkward ads that this is something to be awkward as if it was fully Specht out and finalized in production-ready would go into a fort and from that blessed day it's a lot easier to go get grants and go get money if your range funded if you're like from parody or consensus you don't need to worry about that but if you're working for some of the other teams you need to have something they can take to the people that you're asking for grants for a sake if you grab this something productive will result from it and without that state that's a

lot of profit as a problem with a lot of the people I mean that was one of the main problems that 6:15 hat is they ran out of money and they couldn't you know get some sort of you know a surety from anyone that they would actually see production so they couldn't get grants for it so that's I think what the point of this first step was was as much to make sure that teams who are already funded can get some sort of assurance it'll happen so when they go ask for grants that it'll be easier to get I mean 16:55 or whatever the number is for the fee market that's exactly what happened in 1655 there is talk about major spec changes already so you know that's I think it's working as intended there I mean if we're talking about like

financial financial support for teams I don't think he's a big ask for the yet he orders to at least get their specification into a working state that is something at least in the middle of the idea and full specification spike I don't think that's a big ask and if we are at least high education that is will writin I don't think so called I will like the true Street who prevent teams into

Hazzard God's a funny show supporting it but I still think that from from this spectrum we shouldn't like just except any IPS for yeah if I just when it is ID recruit at least be a stratification I see what you're saying and I think well I guess my proposal is we since this is brand new we start deciding over time how strict to be does that make sense I think you know the simpler it is the more finish that needs to be I think is fine than that there's no guarantees okay sounds good thanks for the comment

way anyone else have comments on renamed opcodes for clarity so just to be clear we said we're gonna move this the last call great yes correct yeah so whoever's doing notes we are moving this to last call and it is also going into EFI I feel like right now last call is a status on an EF ID well no no no it's not necessarily this is a weird case so we'll just go with the flow right now and say it's both an EFI and in last call oh yes I could comment on yeah be in the terms of current test hey oh yeah

the renaming of op codes would not actually require to regenerate any of test because the generated test they consist of a byte codes however if you want to change some second existent and test and the solidity will already be changed just you'll require yes this might lead to current confusion between solidity versions and the test but overall it would not affect any test at the moment I could use like both solidity veterans and generates a test is that okay cool well that's good to them you just want to clarify so we are moving the 8003

to gif i and last cow but we we haven't really decided anything yet for two three four eight right like is not we're not moving that one who yeah if i right no right yes it is not what we discussed I was gonna bring it up as a point of yeah actually yeah so what do you Dan oh did you want to try to move that to EFI or do you think you're still enough like early that you need more time I do I mean we're having more steps to

the process but I do like the notion that if something is gonna go to EFI then it has to be noted stated in one off for devs the next sounds weird ever going to do it to get people who weren't sensitive to review it although I think you know I got some great feedback from Martin already on this but I do think that you know before we should just you know the day before for the knee IPE and expect everyone revealed I think there should for normal ones be kind of a last caller or first call for for VIP for yep I got it so generally if you call it to be EF I'd and generally it won't be on the first awkward to have call unless it's something like as simple as what

Martin lund fall brought to the table that we could agree on pretty quickly but that you would say I want to get this to an EFI state therefore we're starting discussion on this is that what you're saying yeah and I think it would be it would make sense to put stipulations in in the context of transferring and EFI so like for example the Martin like using this as a using this one as a EIP I mean as a guinea pig if Dano was to effectively address the security concerns then would that make it acceptable for you think about it but

I think that's the value of having to discussed over at least more than one great so it's not an EFI right now just to be clear forever taking notes but it is Daniel has basically said outside of any process I would like this to be moved to EFI eventually therefore I'm iterating on it and bringing it up in a meeting cool anyone else have comments two three four eight I think I read the petition I just read only the primary reason for this is

to to to to allow like soldiers orally no taxes you were suddenly in her on 7002 and require a certain to validate it suddenly contracts that could be submitted blog care no for to deploy so I think this is actually a Saudi issue I summarized mentioned this could be done using an extension on zorkin versioning which i think is much nicer than code prefix stuff

Daniel proposed so yeah I just want to give that note and yeah so yeah so how would we get that code prefix into the account versioning what are the current mechanisms or would we need to introduce a new mechanism to say hey I want to be subject to validation so the 7002 a conversion it has two extensions those two extensions are not enabled by 7002 only but there are two specifications that allow multiple versions of contracts to be deployed so

there's one for Chris and Chris ooh of course there's an extension for that and another one is for contract creation transactions so I think seven do to actually get this part at least this part of the motivation covered and I still think there's a much nicer solution the my reason is and of course like with multibyte instructions are actually quite complicated is more complicated than we previously thought and we also had like I mean this code

prefix is the really old idea is started like in when the heroism discussion was started but later we found more and more issues and code prefix that's why the 7002 account versioning decided to move to using the serger the work out the arrow key filled in in account and that's also why the two extensions that allowing it four versions of contractility provides does not use code prefix at all I think there's also a really extensive discussion probably now that extensive but we do have some discussions during

the EIP six one five where we discussed why code prefix may not be good idea so yeah just for reference so the reason why I didn't go with the extra field in the in the contract creation or with the extra op cuts is that that presents a tooling problem we would need to then also upgrade all of the tooling for them to support that as well I mean guests are also requiring them to do the headers and the wrappers but I was trying to get as minimum a footprint into here as doing that and bringing in new op codes and new fields just about engineering wise is

unnecessary when we have existing solutions I mean the whole notion of a code prefix is actually 20th century invention but every go ahead yeah sorry I'm totally interrupted you there but just one problem with the code prefix thing is that the day before it's hard for kids where we start operating different time code deploy a lot of contracts with that code prefix and it's the day after once the evm starts executing my code prefixed contract that I deployed the day before it will try treat it like a validated contracts but

it is not and therefore how should it behave when I do a jump to into a data section because clearly the EVM will not do the jump Aston alysus at runtime so one of the problems that's why it's combined with the account merging before account merging turns on you can deploy all these old contracts with the elevation when the cab versioning turns on when you deploy a contract or bring it in via transaction and you have version 1 on the account that's when it's gonna validate so all these old contracts that have that header will never be evaluated cuz I'll be extra 0 that's why I'm using both of these facilities to make sure for that

situation that people don't clutter it up with stuff that's suddenly going to break when four o'clock hits I mean I also I mean dear heart you have beautiful issues so so far the thing is code prefix was originally means just be a solution for our conversion so we just think decided like fervor we have neutral proposals so we just hides a realization that whole prefix just won't work along and if you combine the code prefix which is combine code prefix with

7002 we basically have two layers of account versioning on top of each other which is quite unnecessary I understand the tooling cooling so ecosystem tooling concert but the heat the thing is I mean now that has had really done any analysis of I mean which one will actually bring more tools the thing is for some like analysis stores like on evn they would require like oza the aver mock of course of valid under

not beauty buys so so so in that case because of the code trick fix those tools might be changed but on the other hand for if we use arrow key fields like I mean 7002 only the thing is we might actually break marsh lace source because we only require a change in the concrete creation transaction but not actually the UM red code layout not anything else so just a general comments I mean we can discuss this later is that means out the peg recovery issue is really has been

Church there was a lot of discussion already so it can definitely accelerated so we do the transaction then we have to have the compiler and the client code and EBM versus if we do the account versioning in the rack where we take out the deployment stuff we just need a compiler and the EVM so I'll I'll note these ins into that that those are some of the concerns but you know one of these ways I think we need to get there so that we can start them enabling these multibyte instructions in a solution there is to an end a validation so one of these things we need to get working is my short take you this hey Dana maybe the thing to do here would be to start

compiling a list of objections and to dig back into the history of like why people have objected to code prefixes so that we can kind of build up a small knowledge base of like reasons why people think this won't work or why it would be problematic so that we can start trying to figure out if there are solutions that give us best of both worlds type things yeah that's something to compile through the rationale so whatever particular solution comes out we understand where we came to this decision so just just a general reference on the 7002 our conversion you can already fund i remember zero

discussion and reference to the original code prefix AIP on why the code prefix is probably not a good idea and why it doesn't work so yeah and I would second Piper as well as saying that we should have that beat and if an official part of the efi process is to have the authors listed in a in a standard place so that everyone that can like what are the things that are blocking it from moving forward either in the efi or pass you I think comments will be sufficient to be honest

yeah calm calm oats or maybe editing your top post on magicians on your thread if you want to if you like if it's something that has a lot of stuff yeah I would think just just keeping having all the discussions just in the in the discussion to link in the IP will be pretty sufficient great ok next agenda item EW IP that's a meeting I want to have next week because a few people from the etherium Foundation a few people from

the etherium cat herders some people from the etherium magicians are all interested in improving the EIP process that would include pretty much any in all aspects such as what requirements are required to get the IP editors how can we recruit the IP editors what should those be may be redoing a IP one how to make the process more clear to outsiders things like that so we're gonna just start having at least next week's meeting will be the first one and then we'll decide from there you know what we want to do if we want to have more meetings or not if you're interested in attending just let me know or you can email Hudson at etherion or

yeah yeah Hudson at aetherium org and let me know you want to attend and I'll probably make a telegram group or something like that or a getter group I'll see so there's that and reviewing previous decisions made and action items for call 74 I looked at it it's basically the astable block number was decided the Berlin AIP deadline was tentatively decided as the third Wednesday of March and there's a list of VIPs that were accepted and final and some that were eligible for inclusion that need to be talked on more and we might need to start over on that

eligible for inclusion section on some of those EIP since a lot of them we just kind of threw into the efi bucket without having a lot of discussion on them there's also some miscellaneous comments are there any other talking points things I left out anything anyone wants to say I don't yeah I don't think we know how to calculate it do we does anyone here know how to calculate it the predicting of what's going to happen

with the it's really weird math for some reason that's how how it was designed and there is a last year Vitalik Lane metallic wrote a script Lane cleaned it up that and used to predict and there's also just going in it's pretty menial process but you just go into the different block numbers and figure out what the values that affect the ice age currently are that's just hard to make time I'm working on it oh sorry I was needed all right thanks James

all right we'll see everybody in two weeks bye everyone [Music] [Music]

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

[Music] [Music]

[Music] [Music]