All Core Devs - Execution #103

Transcript

[Music] [Music] [Music]

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

[Music] all for

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

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

hello everyone and welcome to Number 103 of the ethereum cevs meetings I'll be your host um Hudson and we'll jump into it with some exciting yellow V3 updates from uh the client teams and we'll go through um all the regular ones and then also Pua is going to be talking for ethereum JS who has given uh her an update so uh James if you want to go through everybody yep uh let's go through also happy New Year everybody hope you had a good holidays and where is my list let's start with uh nether mine can

you start this this is updates on your Readiness uh so the in December we updated 2929 implementation to make sure that he passes all the consensus tests from the development branch and everything is green now with the mind for the Berlin 2929 um then 278 293 so both were implemented to the extent where it worked for the basic operations and it obviously would fail in some cases which were not yet fully specified and may change so we're just waiting for the final specifications decisions on those ones uh then we also build already the packages for the GMP library for the

faster I think it was 2 365 I believe the number so that's that's ready to change and that's a reasonably easy change after that so everything is ready and the other the other ones uh were implemented long time ago the ones from yellow vi1 so all fine great thank you and Basu uh everything is implemented we're still working on the testing for 2930 um Martin from gu provided some uh cross referencing some referencing data so just trying to check against those okay and open ethereum uh yes should

be everything ready so we finish at implementation in December so yeah we don't expect new things so yeah everything done cool and G yes we are yeah it's 2930 sl8 uh that is remaining mhm after that is mainly some um Regular um what's it called yeah uh surrounding stuff but on that one I did generate some uh reference test to sh that I shared with Ry uh but I saw that light client has

been doing some updates in so maybe we need to change those once again and maybe light client would like to uh talk a bit about how the imputation is where it's at sure yeah I'm really sorry that it didn't get done before Christmas I had some personal St come up but I it should be up to spec now um there was one thing I needed to change after you or one main I need to change after you made the cross client test cases I I hadn't updated the signing hash to generate as just an R rlp list it was still concatenating a typi so I I fixed that and then I went ahead and I updated the uh the cross client Tas so

if you want to pull the the new ones right that should have the proper signature hashes okay do you think that's why Martin had to uh he couldn't deserialize them immediately he need to change I think the parody bid or something although it probably should have changed more than just the parody bit if you didn't rlp that whole list yeah I'm not sure if the parody bit should be the issue there it should be the hash that was created from the vrs yeah okay so sorry not the vrs sorry the whole transaction I'm surprised it didn't break more catastrophically then when Martin tried to dilize my block body but

okay great thank you so we're pretty much at the at the end here I wanted to give kind of just a sanity check on stuff that we're do um we actually I think Pua had JS or did that happen already yeah um I I can go ahead with the updates on JS I have been provided by hogar um the team lead from from the JS they are closing to have their client ready to join the test Nets development is taking place in a monor repo they haven't done any release yet reflecting the changes and the current state is that the client is now getting a reliable connection on mainnet and is processing the blocks with JavaScript

VM with decent enough performance for YOLO test net Readiness uh they still need to improve the connection reliability on the PO POA Network improve the hard workk integration and do some other fixes all YOLO V2 eips are implemented and they are interested to join uh the first ground to test uh their client and they should be ready is by the end of this month that's it cool and Yol V2 is uh who would be the best person to point

them to to being able to to connect I don't know if Yol to is anything to connect to uh this stage yeah all right um I don't in a few weeks it would be I guess it depends on the answer to this next question so let's go to uh thank you Pua for relaying that and great update from from the JS team I'm excited to see that work coming along so the at this point we're pretty close to having the clients ready to implement things and I just wanted to check that deploying YOLO V3 does it add

value now and or would it be would going to main test Nets be more of value just to take a pause and to think about that as a group like which should be the priority here and I guess like the in my opinion the reasoning behind that I think is if we were to deploy on yellow V3 and run that and then run a test net that espe especially on the POA test Nets that are already running like or or even robon um what value would it add to have YOLO doing the exact same thing that the next test STS are doing I guess I guess the one thing is if yellow breaks from the

new eips we wouldn't have to relaunch the main test Nets um but I I want to hear opinions if that's not the case or if like we're overthinking it well pretty much that's the only thing so that's that's the reason why we don't want to launch on testnets because things great quite often and people rely on the tests okay well that sounds good um are there any other opinions on that otherwise I think James what would you say about this so you can go ahead Martin yeah I was going to say I mean launching launching the test net from the perspective of

just launching the Explorer the foret and stuff it's not that much work compared to you know implementing and all the stuff um so I don't think we need to overthink it too much you mean launching the yellow test net right or launching like okay mat Robin and Gordy and all that right yeah I mean we have the templates for doing it now and they're pretty slick to just it it's it's fairly easy to to launch T it's more difficult to you know pick up all the old transactions and replay them and make sure that all the everyone gets on the same test

net but actually just launching the yeah the basics is it's not too much work now so I think we should do that yeah okay is there just thinking of timing is is there like a could we say something like have it up by next Friday so people could start joining before the next allord Dev call kind of a thing I I I think that's a bit too optimistic because even if if if we are happy with the 2930

implementation it's going to take at least a week to get it merged because it needs to you know a fairly thorough review so then after that it's launched we can like consider after that's merge we can possibly do the do a release which contains the but our next release is going to be a big one I'm not sure when that's going to be um yeah I guess we could launch the testet even though we haven't made an official release yet though but one week is a bit maybe cutting it does it help like can other client teams

help with that um yeah like say you know if in basally we have it merged before it's merged and get does it make sense for us to try and start the test net and then you know forget to to join once it's merged um or I'm not familiar with the tooling yeah I mean you would be very welcome to do so but um then you would have to do it from scratch because uh the like answerable test and the pupp definitions they're all based they're based on G got yeah yeah yeah faet the Explorer and all the other inas are based on gu got

it um yeah that might make it turn it from like a few days to much longer um cool for the next quar of call maybe yeah that would be um better aim I think um but what would really so personally I think you know YOLO test Nets are nice and fun but what's really really awesomely useful is when these test Nets can be activated for

fussing uh so if you if other clients are finished with the YOLO V3 implementation uh and make sure that it can be enabled for fussing then uh yeah we can get that started and that I I mean I can get that started way before our PR is merged because yeah that just runs local what's the list of things that I guess that's something I could help coordinate I think yeah I I think by this time all client Dev knows what's needed because we have plus and calls and discuss these

things so I don't think I need to explain too much about what's needed from the client teams okay so I can just follow with client teams and then we can work on getting that up next week while you guys are finishing the pr so then we can have YOLO stuff by maybe the next C of call yeah does that sound reasonable to everybody and then I'll start looking at tenative four block dates proposals kind of things like that the week after in preparation for next call in case we

need them so I'll have the math and stuff done for that great uh was there anything else James uh that's it for me excellent um next up uh well I don't think anyone else has anything maybe just I'll I'll clarify the action items so the not for the not takers oh perfect okay is this next week reaching out to clients to get everybody done what they need for fuzz testing so that can happen soon um then the GU team is working on Final reviews so they can publish YOLO V3 and then before next week's call hopefully

get YOLO up and running so we can talk about next steps including Fork date proposals great the next agenda item item two um first bullet point would be evm 384 update um that was asked about in the agenda notes so if you click on that uh it'll come up with a question uh is there anyone here who can speak to that it's usually uh axic I don't think he's here today though hi uh I think I can just say that uh this like new update uh V5 being prepared uh but that's not ready at this

point so I don't think think we have we have anything to to present in this meeting um I was uh like I added this question to the agenda for a reason that uh the problems with EV 384 is not like speed of the principal operations or whatever those can be achieved to the reasonable degree like to the degree which we can call reasonable uh compared to like naive implementation non-optimized native code uh but the problem with implementation of final cryptographic operations is that evm itself adds an overhead which is twice as large as the cost of those

mathematical observations and uh I wonder if it's even addressable and uh like uh I posted around two months ago I think the comparison between uh how much it would cost running in a pre-compile in different precompile different mation of pre compile compared to how it's like can be implemented in evm and what is the current gas costs of P incorporations in evm 384 and the difference can be up to 10 fold comparing like the fastest native implementation to the uh like uh optimistic view on the evm

384 um and if there is no update on this I would even a question like maybe it's a dead end and we should just because no one uh disregarded that there is Need for more cryptographical Primitives in E 1.0 already uh and if it's a dead end we should just go back on track and continue to um like and get back to precompile and formalize the process of uh introduction implementation and uh kind of acceptance of cryptographic PR compil in general like make formal criterias like we did for based on the work for

2567 for example uh so well it's like long uh long uh long statement but uh it's you you took the the two 10 times uh more costly in G from your your your benchmarks or from the update v v before uh I taken the one which was the latest posted public update uh like I taken the guess uh Fork which was also posted in those notes uh I taken the code which was used for benchmarking which I assume Implement something close

to the pairing function uh or paying function in full it's not that important um and I just look at the numbers which like amount of gas which evm like which is spent to run this contract uh and then I looked at the how much gas it's it actually spends on this new VM 384 op codes and it's only like oneir at maximum uh so at the end of the day it just becomes uh that um the gas which is spent on control flow and evm code not related to evm 384 operations but just for whatever it is

there uh in a compiled code to ensure the control flow is already few times more expensive than the precompile which does everything yeah yeah okay uh so yeah I think like more or less that's that's that's that's accurate and that's what the the the next update is going to address to to some this thing I mean uh but yeah I think that's that's that's what we also see uh so uh I think in terms of I mean I personally benchmarked uh this evm 384 uh uh implementing pairings or like some some other stuff I'm not really into

details what exactly uh the the implementation we have uh if if that's that's a complete final final version of and this is exactly mat with the the AP but anyway uh in terms of like runtime speed they are comparable in terms of gas cost there is issue that uh because like mostly all the computation up codes in evm are like at least 10 time 10 times overpriced comparing to anything else or any anybody that you can find uh that's that increases the like this virtual gas cost of the implementation and that's

what we we try to address in the next update uh but there's like internal discussion still like how exactly approach this and uh yeah it's it's rather complicated issue op on that as you mentioned those are potentially 10 times more expensive than actual time which is spent for those operations no I mean 10 times overprice comparing to I mean they should be 10 times cheaper that's that's my my position on that oh well I mean my question is like is it even fixable in the observable future because uh partial gas cost proposal was either rejected or stall

like half a year a little bit more more ago we want to put time into this and like yeah yeah so like depending what you mean fixable in terms of allord death coordination I don't have opinion about that in terms of technical technically fixable yeah of course yeah well I mean there is no doubt that it's technically fixable uh like but in terms of coordination uh which already like uh nine months since the last for I don't remember actually sorry uh and it tells like the EV 34 as a proposal is great it's like it's just just the same as the plake precompile which is unusable for

practical purposes in its current form uh so if the work continues to actually fix all it together and I most likely it would require a lot of repricings in evm implementation itself this is a good work but I say that like yeah okay so we need something we need a solution and solution was made already yeah I I can speak to um kind of a little bit of what we've been thinking road map wise behind the scenes and starting to get feedback uh later but I I don't think it's fair to ask Paul like what that's going to be I guess because that's more of a group decision yeah this go this goes back to

the BLS versus evm 384 discussion which we decided to put past Berlin uh yeah it's related but it's like more related to El generic approach like I don't know if it applies to every case to every other maybe future uh cryptographic promile which can come up there was a lot of work done for BLS there was a lot of testing cross implementations and was even Yol we one without problems found in this uh people like James I don't didn't see him in participants today uh he did a lot of

work for just uh separately from me and other people to run an extensive one month of fuzzy testing of the library with uh like with kind of gray box testing in addition uh and explicitly testing the exceptions which are in a spec so it was a lot of work done which can be first of all kind of we can see that BLS implementation should be considered safe uh on top of this we can use this process on what we all did to kind of ensure the safety and make it like a standard for all in principle cryptographic proposals and well third and like if it's more and more delayed

and as I was also mentioned in this analysis of gas cost for evm 34 implementation now there is also a wonderful library from uh supernational uh blst which is like insanely fast uh formally verified and uh so it's a C library and since all clients already use the C library for uh uh secp signatures uh like it's standard assum signatures maybe it would be even a good idea to kind of all agree and standardize it as a like reference implementation which else will uh eliminate risks of uh

consensus divergences so I I wanted I wanted to say real quick without taking a position I do believe that it's not consensus among this group that there is no safety concerns although I agree there has been a lot of testing with again without taking a position there has been safety concerns regardless of how much testing there's been due to the nature of pre-compiled in general and comparisons to how 384 is structured well I mean no code can be uh claimed safe uh I think in principle we seen the uh changes in like we seen that go language itself got a security update

due to vulnerabilities so a standard Library so like then we should even start to talk about the standard libraries and potential miscalculations uh in different languages no code can be claimed say can be claimed like safe up to our bar which is set to something or to the best of our knowledge and effort but that yeah no code can be claimed safe in like I I I might have not I might have not been clear I thought you said that it was considered safe by the group but I might have misheard your exact wording on that so that's just why I was pointing it out um but this is kind of a discussion topic that's been going

around round and round and I think the request that you made for newer benchmarks that people like Paul has been doing is a fine request but it's not like we're going to be able to release either 384 or the implementation you've been working on until at the earliest the next hard Fork which we will hopefully be soon discussing pre- Berlin to start making plans um it could be post Berlin that we really get around to solid conrete plans for the next hard Fork but um that's something where I would recommend having a lot more async communication as I usually try to bring up um with getting those benchmarks

together and using the chat rooms for 384 and for the uh implementation uh space that and The Magicians thread that you have um it's it's not about including in the perin it's uh more like about the approach to cryptographic promiles in general formalizing the process of acceptance um and then like if it goes into next one and not in Berling it's it's still fine it's just that there are Primitives which would be great to see in this one.to yeah no cannot be included in the current form yeah that makes sense oh go ahead Martin yeah I was going to say I don't I

don't know if it's worth it to try to for formalize some uh you know official this is how we will include this is the process to include uh the future upcoming crypto promiles um I think we're going to have to take it on a Case by case basis I mean to decide is precompile is is it worth it for this one and why what and and how much testing and what is the qu you know I don't think we should spend too much time formalizing everything there that's just my opinion and I I would agree that so far we've taken the approach of we do

things as they come up instead of deciding how to do things before they actually happen and I feel like that's kind of fits in the spirit of that just like unfortunately we had this problem that every time the work is done uh it's only rejected on a form of like uh like based on the on uh like subjective opinions that well it's not safe something like this if it can at least set a bar like yeah it should should be considered go back and so trying to set an arbitrary bar or or something like I like I understand that the intention here is to help get pre- compiles and well help get crypto graphic functions

so developers can use them and that's something I totally agree with like going back to when we were discussing this and the reason why I kind of pushed on unwinding doing BLS is when evm there like the the it wasn't to me about the safety concern it was the we have this discussion that needs to happen that's going to take a while and we have other eips that are ready to go and we need to for focus on getting those out instead of continuing pushing things back and so the last couple months the last couple all cordev calls have been focusing which is great because we found the um 2830 was a lot more work than we anticipated

which is we wouldn't have found out if we kept pushing back on this BLS stuff because the evm 384 team is still going so it's so um like I understand frustration that sometimes things get kicked back or it takes longer than you than people would like and I I I it isn't like we just got to keep moving some things at some point uh it it's it's also not my point uh so I mean BLS was ready to the point to be included into the first test net and since it was 324 proposed and like then it was kind of uh removed from YOLO V2 and V3 and uh like

removed from Berlin and completely fine with this it's not my point my point is just that problem so this problem in general and like the for the process for uh well at least it should not be swept under the table and say well everything should only happen after Berlin I don't put it for Berlin like that we need immedate discussion I shouldn't I only identify the problems that well what would be good to look at uh and it may be used as a standard or like internal bar for cryptographic Primitives but uh I just wanted to emphasize that pre comps are still most likely the way

to go and the attention should be paid to some so uh Martin you might have had a comment I saw you on mute but I I wasn't sure H yeah maybe I unintentionally did uh but oh that's fine either way I what I kind of thought think right now is that the longer time that goes without any changes being done to the code base the BLS code base um I mean guess we're still doing fing not cross client fing but still uh crash fing and it would make I think it's good if it's like six

months since and change was made to the code and it's maybe even used in a couple of projects and uh but I mean six months ago all the code that was written was kind of brand new um uh fing looks to be a well paralyzable process so it's not a matter of time it's a matter of computational power one might think so yeah so like it's it's also not a great comparison like I know James did not like a random fing but uh kind of attacking with it with specific factors which potentially can trigger discrepancies in mathematic in the code itself which done a

mathematical part and like error handling or input validation uh so it was kind of another view on testing such promiles and real quick that you mean James presswich from the C team when you say James yeah yeah I mean I mean yeah I mean James but he's not he's not in the call uh yeah I I again he's not here um so uh like there was a great amount of effort put in there and like this process of fuzzing for whatever reasons can Elsa continue definitely that's why El continue to mention that well maybe we should at least say that it should be equivalent of six months of fing on like 16 core

CPU um of this pack on all threads or whatever so we can at least try to achieve something and not say like well we fast this for month but where like local laptop one single core instance in the cloud or or what what so we can put a check mark on something more formal without saying like let's keep this code unchange for next six months and see like well if it's a change it nothing happen but people will also stop paying attention to this problem and uh like they will be get so frustrated and stop their effort to find the Box improve the code quality and continue to work in this uh after it's included yes it's

frozen it can be frozen even if it can be improved uh but before this if it's just stall for months months or year uh then it will not be like possible to easily get back to this work okay um anyone else have comments on this I some Just Thoughts continuing work well con connecting with James prw on because he also had did the other BLS pre-compile with with the silo Network so continuing work with him um I think it's totally fair that we took a while to focus on Berlin and it's definitely not even though it's not come up on

calls it's been it's still on my mind that that problem has not been solved and is something that we should or I my opinion we should be addressed somehow in 2021 or this this year and my the stuff to move forward the work that you're giving my suggestion would be that there is currently an unknown amount of pre-compiled that the evm 384 would be able to supplant and then there is a currently unknown amount of pre-compiled that it wouldn't and there and just get and getting closer to more definitive what is and what isn't on in the implementations is just going to take a while for the evm 384 team and it's not really fair to them to asked to

like have a conclusion on this call today and I don't know is it worth having like some separate calls to discuss this it feels like every like second C of calls we end up spending a fair amount of time in this I guess crypto precompile versus evm 384 um that maybe it just needs like a separate track so that people are able to make you know to to have these discussions and and make it more progress um I think the other thing that like you know is probably worth discussing is how it's being used on E2 and the data that we get from from that um but it just feels like it yeah it's it's like uh maybe too

early and break doing a breakout room but it feels like yeah it's more it's not like a one-time thing you know like with 1559 you know we have I don't know monthly calls because there's just like a lot of progress that happens and a bunch of different teams working on this with different updates and this feels like it's maybe not the exact same thing but close enough that having like a more a different track might be helpful because it it would be good to have the like discussion with the evm team beforehand so that they're also more prepared and and and in the expectation of the discussion too so that is a great idea yeah I mean my report is few months old I posted in a C of chats and like I was hoping that

maybe some questions from it can be answered but well it happens that those was not and frame was unclear so I also needed to State why it may be the case and most likely it will be the case that native code still needs to be included and then there should be a process for this inclusion I think we should move on to the next Point yep good to me so um but before we do that we do need to decide would there be who would be up for attending or contributing to a monthly breakout room call because we wouldn't want a breakout room call with just two people uh yelling at a

wall okay I would generally oh sorry go ahead Martin no I thought you you were asking how many people would be interested in attending or did I Mis understand yes no that was exactly what I was asking yeah I would okay and then Ry you said you gave a plus one so it sounds like Basu could have some representation or was that for a different message that was very different thing I I was plus oneing Micah's message that like clearly the BLS 384 thing was just like a instance of the issue of like more um of you know just like pre

presetting requirements um you know which does sound like an aord Dev kind of discussion which maybe we don't want to have today but just like it's not a breakout room kind of discussion um and it would be good in the future so that this doesn't keep happening yeah so you're saying it's a process discussion more than maybe technical on some level well I answered it in chat but it's actually both so okay we can continue writing okay so um Pua if you could um kind of talk to some of or James and Pua or whoever can coordinate part of this talk to some of the client teams about participation in maybe some something like a monthly call just

to both get updates on fuzzing on um Alex's stuff and uh I guess whatever the evm 384 updates are I think that would be beneficial and save us time in the all cord Deb meetings in in Mass sounds good yeah I'll connect with Alex James and James PR as well okay and yeah the 384 team I can get a heads up too I think they have some area of the e&d Discord where they hang out I think okay um thanks everyone for that the next one is EIP 2937 um that is the S set indestructible op code by vitalic

uh and oh okay theic's here today um if you want to go ahead sure uh so it's the set of sestru indestructible EIP is meant to be a companion to the account abstraction EIP the goal is basically to allow um people to create contracts that guarantee that they cannot be self-destructed which basically means that they guarantee that their code actually will exist and get to exist in in basically the same form forever and this is valuable because it allows account abstracted accounts to have libraries like basically they would be

able to make external calls to these contracts without the um nodes um having to redo those calls if the industry if the libraries like get uh like basically without worrying about the possibility that the libraries get modified and then I believe um someone who could maybe provide some more um info on this Angela and Tyler are here today um and I think um they can if whoever wants to go first uh yeah so um initially the spec was to create a um transaction wide Global set variable but we ultimately decide that was unnecessary and

implemented it as a local variable to each execution frame okay and uh is Tyler here I didn't see oh Goodman okay yes um yeah I think balic covered it h why it's why it's useful why we implemented it's just to make sure code can't like do some rug pool trickery through delegate calls to self-destruct and kind of ensures your code will always exist and be there K do we have questions on this uh Mike I think you raised your hand yeah just can someone give a very very short like one or two sentence

reason why we don't just remove self-destruct seems to cause us no end of trouble and I think we've already discussed this I just need a reminder why don't we that and and wanted to ask this same question too to be honest uh vitalic can you answer that or either that you or Angela or Tyler the the I guess the reasoning behind removing self-destruct is that the right question Micah why don't why don't we remove self-destruct like self-destruct continually causes us headaches there might be there might be vaults that can only have exit with a self-destruct this is the the age old

issue of worried about their's contract break correct yeah okay so I think just very briefly chiming in there because I was also somewhat involved in like the kind obstruction and and and and self-destruct discussion there I I I think basically like General agreement is that it would be really like the best solution to get rid of self-destruct completely but I think the said indestructible uh like the beauty of it is that it's like really really simple and and and noncontroversial so you can basically already just have that in the next for after after b or whatever it would be quite easy to to get there I think of course that theps always have

some subtleties or something but um um and it just gives you like a lot of tangible benefits already not completely outside of the con obstruction um um um context so um so so basically the idea is if someone else wants to really Champion completely removing self-destruct I think we would all be happy to kind of join behind that effort but it's just not non-trivial and so basically just not doing other things because we want to get rid of SE completely but then we never do because it's complex yeah I feel like then then it's just better to get go with the second best one that's just really easy to get as a it's easy win compromise and and indestructible doesn't prude like removing self-destruct entirely at some

point later right like that would just turn the op code into a noop um and what's the expectation that uh the solidity compiler would emit as like by by default um indestructible and I guess you would just need to add a flag and it would just like the idea would be that you would just set the first bite of the contracts to be in uh the indest the seven destructible op code and then like move all the offsets The Code offsets by one and so forth but in effect we will be adding additional complexity in order to dance

around something that should have been removed long ago I wouldn't call this non-controversial yeah mean I personally am in favor of just removing self-destruct like I think like yes it is egg breaking but on the other hand like egg breaking an egg now is always e is easier than doing it any years from now especially given that we're in a rapidly growing ecosystem but like that that discussion would take a a lot longer than this a single call okay um and this is also something where we plan on improving the process for um discussion around eips um such as so so

that we do not have people coming in to the calls and proposing an thep and then it kind of suddenly being stuffed in when there might be other higher priorities um so that's not to say this isn't important but just to asage anybody who has processed concerns um around eips being brought up randomly or kind of anything making it into the agenda um there there's likely going to be discussion and maybe even changes uh to how that works at a process level yeah um it just hit regarding that removing self-destruct idea uh I think that would

be extremely breaking not just From the Vault perspective but actually the whole new upgradeability pattern which is possible with create 2 I think there are several upgradeability uh contracts which rely on self-destructs to be able to upgrade themselves in general I think this that indestructible uh looks nice but I think there are it's lacking a lot of specification but I wrote most of that on The Magicians so guess we can take it offline okay uh any other comments on this um the fact that it's used for

upgrades is basically that this feature was intended to be something different so it's it's used it's I would say improperly used essentially because it was not supposed to for this and uh maybe we should discuss better ways better future ways for upgradeability yeah it's bit late for that now you mean so you mean for like future hard Forks Beyond burlin artam um well the sooner we remove self-destruct uh the better but my question was not about the some specific time frame but rather that if the a

problem where that removing self-destruct will break uh upgradeability of contracts then we should discuss the Alternatives yeah that's should we do that yeah I guess I'm kind of confused where that's coming from too well I think it's more about the fact that it breaks contracts that are already deployed than it breaks the general pattern yes exactly yeah that was my point uh that there there are most likely contracts which have been programmed to use this feature uh and if we s distru we're going to break it okay uh any other

comments okay thanks everyone uh I want to go over the last two decisions made and also uh make sure because I think we have Piper from Trinity now just get a word in about any related to Berlin or future updates and what Trinity's up to um but evm 384 basically the um for the note taker uh Pua and James are going to coordinate on a potential monthly call um that could happen to discuss both process and technical issues and concerns that were brought up in this call uh in order to save time in the allore devs calls from repeated um discussion over similar issues um P 2937 was presented today by some of the team

that has been implementing it and um there will be a sync discussion uh primarily on The ethereum Magicians forms for um continued iteration of this EIP um and then finally let's go to Piper um Piper did you have any updates um that you wanted to discuss with everybody or uh announce of anything like that Piper might actually be away right now I think he might have had something sorry I was tying a string on a balloon for my daughter it was very important that's a really wonderful excuse uh it uh I don't have any updates

at this time no uh okay no problem just want to make sure you got a chance um the final uh piece of this uh agenda um after Berlin I'll be stepping down from the role of coordinating and recording and basically all the things related to the eth 1.0 uh cordev calls uh if you click on that link there is a tweet thread that I put that kind of outlines uh explanations as to why and things like that but basically I've been doing this for three years I guess and it's grown tremendously and I think that although I could keep doing it there are

other things I want to pursue uh inside the ethereum ecosystem and also in other ecosystems such as zcash um that could take up some of my time um but I've you know Lov doing this and I'm really excited that there was behind the scenes coordination to um have the role replaced by Tim boo um who's on the call so um everyone uh welcome Tim to the new role once we do the transition it's going to be a multi-month transition uh um where Tim takes on more and more responsibility and uh he already does a lot for agendas and sometimes recording and stuff like that but um it's not going to be till the plan is kind of

tentatively after Berlin would be when I'm kind of at least shift it off if not completely done uh with the allore dev calls so uh Tim did you want to say anything uh sure real quick uh first of all you know thanks for doing this for salong Hudson um it's uh pretty big shoes to fill um but I'm I'm very excited about uh getting started on this um because I'll be doing this full-time you know over the next couple months right now uh my priority is finding somebody to replace me on the Basu team uh to work there um but I'm slowly ramping up part-time into this and one of the first things I I want to do is

just chat with a bunch of folks about how we can uh improve these calls and just the processes in general I think that's you know kind of been brought up today a few times already uh so I've started you know having some chats informally uh and I'll probably be doing more of those over the next few weeks and and months um and trying to share kind of the the the feedback uh as I as I get it um but yeah excited to get started on this awesome and I want to give a special shout out to James uh Hancock and Pua uh Ronan because uh they've been uh tremendous help uh you know James has been the hard hard for coordinator for a bit uh through good times and rougher times of discussion uh and pu has been

great uh coordinating a lot of the um ethereum cat H herders related coordination problems that have occurred uh with discussions in the past and some of the stuff like breakout rooms and eips and Peep and EP uh video calls that have been good at explaining to the community the importance of some of these low-level protocol changes oh James did you have something you're unmuted oh I was going to say snaps for Hudson this has been quite the long ride for all of us well thanks and it's been great having you and I'm sure I'm not the only one with that sentiment awesome um so yeah that's pretty much it um I'll also paste what

did I have I had Tim's tweet thread it's not even that long uh but the yeah my in there if you have any questions just let me know uh but yeah I'm not leaving the ethereum ecosystem that that's also the last thing I want to say because there was some confusion that because the Tweet thread was me leaving a role that a lot of people knew about they thought I was leaving the ecosystem but that's not true I'm still doing stuff internally at the ethereum foundation and different roles and with stuff with cat herters and um other community things so uh yeah that's it for me in that announcement um so yeah thanks everybody this has been great honestly I I've loved doing this for so long and uh I

think the new chapter is going to be great with Tim uh let's see is Tim gonna grow a beard o no I've done it in the past and I've shaved it could we get Hudson to send Tim his beard you know I think we need an EIP and then a lot of discussion I think this is a good use of gitcoin Grants yes uh or or a prediction Market actually more so good get whatever augur poly Market on this um okay so that's the last item what else is there anything else that uh anyone has that

was not on the agenda uh yeah if I may take a couple of minutes to go with a quick announcement uh that is related to the E that are considered for uh Berlin um in the upcoming weeks we are going to have two calls one with Martin and vitalic on January 15 for EIP 2929 and EIP 2930 at 1300 UTC and another call with Greg on January 20 at 18:30 UTC for EIP 2315 so if people have questions or they would like to have an overview I think that would be a good time to to interact with the

authors itself and recently we have also recorded an episode with Gom ball that is on binary try that is not related to uh Berlin but if people are interested uh they can watch the episode I just pasted the link to the playlist and uh thanks for doing this Pua I think it's been really helpful and uh to be clear if you're in this call or if you're a Community member who is interested in this type of low-level development reach out to Pua so you can get the zoom link uh before the meeting starts and you just heard the dates um so feel free to ask if you if there's uh time zone confusion or anything like that sure thank you for

much okay uh is there anything else from anybody uh I have posted the link to the self-destruct removal e EIP which was posted uh in June uh last year it's 2751 in case anyone wants to take a look okay thanks so much for doing that that's that's very helpful to see um to see what the previous conversation was is there an e magicians post you're aware of or is that Linked In the EIP uh it's not Linked In the EIP let me just link it separately in the chat okay or even the allord devs chat if you aren't able to get it in before the zoom Callins um um that'd be helpful um all

right cool anybody else looks like we're ending early thanks everybody the next call is in two weeks on January 22nd at 1400 UTC and everyone have a great day and happy New Year happy New Year thanks guys bye happy new year thanks happy New Year [Music] [Music]

h [Music]