All Core Devs - Execution #110

Transcript

by a yacht so you just move your whole house some of us didn't get it to eat that early so mike do you prefer micah or vika i don't actually care my mom calls me micah so i will respond in fitness testimonials which will give you a slightly slower response [Music]

is [Music] there we go [Music] [Music] yeah you also get a faster response in that they tell you the answer faster

when [Music] and like if you're indian and you can pronounce that then go for it [Music] all right you get a nice long answer [Music] [Music] so

so mike i remember um over like the holidays there was that interesting discussion about where to live have you um what's on your short list for like places that have the most desirable properties in your mind the space right i guess your short list is very short because you're tied [Music] [Music] [Music]

[Laughter] [Music] i was reminded of it because i uh i read the most reviews in astral codex 10 about prospero this like charter city startup thing in um in honduras and i was like i wonder i wonder if this has any other properties that michael wants so they made some sacrifices that i understand why they made but it kind of walks it down my list for example they allowed uh [Music] [Music]

like what i've learned in the world is you have two choices you have a very effective and efficient government but also you know if you go against the status quo no one cares basically and so it's not necessarily just an immediate write-off having an effective government um but yeah it also might be because the things the ways in which you again go get the status quo are probably too nerdy for them to care about whereas there's a bunch of people going against the status quo that they would

absolutely care about and shut you down like or taking the money away from them exactly so like if if i'm you know building a censorship resistant blockchain in you know honduras the honduran government probably doesn't care i'm doing the same thing in usa russia you know they care because you know they have the global financial power that they want through things and so you know it's yeah this is definitely part of the factor is what set of things are you doing that's outside of the social norm [Music]

[Music] [Music]

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

hi everyone uh welcome to all core devs number 110 if you've been hanging around you might have seen that we accidentally streams of the audio of the pre-conversation chat um so now on to the official agenda um let me just post the agenda in the in the zoom chat right here um so i guess the first thing uh is that berlin happened yesterday uh as most people on the car are probably aware there was an issue with open ethereum around the berlin uh fork block or slightly after um i don't know if anyone from the open ethereum

team or or anyone else wants to just give a quick summary of what happened and and where things are at now [Music] um did you have someone in particular in mind no uh i i'm trying to look at the screen is there anyone from open ethereum on the call oh hello i'm actually uh yeah i can give you a small update i don't have the full picture but i have some because i i think that marseille is not here now so

it seems that we had a bug in the way we implemented the 2029 [Music] and it was at rest i mean we uh thanks for uh everyone in the community for helping us debug it and uh helping it with helping us with fixing it and um yeah we pushed the fix to 3.2.3 which should be now publicly available we have made a postmortem today and we will be um publishing a

written uh postmortem for the community most likely next week with all our conclusions and findings so yeah that's i think the the message that i have right now sorry the time late basically i'm sorry if i'm iterating again what crime said but yeah uh we may be you know uh basically everybody knows last uh yesterday that operatorium didn't had concern and could propagate one block uh we investigate with help of

basically everybody from other client teams and humanitarian guys came to help and we are very very good for that thank you uh it was completed at one perception uh basically asked for was wanted to access recompile address that is bls12 in our change pack that big address was disabled basically block is put to something in the future and it had different behavior than it had on the test specs that basically was removed there and then that the section wanted to

access those that particular um that particular of brick topologies basically it because of 2929 it calculated gas different than it should be and that's basically what happened is we got different uh different results than all the clients is made in three two three and it seems it worked basically yeah uh addition of that

uh we noticed that um yeah martin yeah martin was the one that found the problem and thank you very much for that is the one that was fast created the puppets yep yeah i just wanted to add um like from a process perspective like what can we learn from this um i just post more than one like larger level so first i thought that this was an oversight in the fussing and then i realized or rather a way tang pointed out that this would just not

have been caught in passing this could not be caught in passing because it's more like this edge case where the uh the chain config the peri open ethereum chain config how it interacts with the with the evm consensus engine basically uh and also the reference tests similarly operate on well-defined uh yeah specifications so the reference test also failed to find this and i was kind of thinking how could we possibly have found this and kind of the only thing that i could

possibly think of that would have caught this would have been if the hive destination chain high chain configuration had been identical to the mainnet chain configuration with the only difference being the numbers [Music] but otherwise i i find it kind of hard to figure out how you know the how the whole process that led up to the hard work and that led up to this consensus issue uh i find it hard to see how it should have been

better in order to avoid this problem basically what i see we thought that disabled vehicle file is same as remove and that was not the case disable i mean just put some block in the far future and that that was the oversight and that's why yeah that was that's why it is different change spec was different between testing transplant and the main expense pack yeah

i'm not sure how exactly you need to get that a little bit better in the future just to be not that the same just be a little bit careful yeah there's i think there's one more thing that we can also uh take away from this and it's that in order to to debug things when they happen it's very good to have tools that enable a node to import like force simply import and trace a non-canonical block which was previously rejected [Music]

tooling or procedure at this site we should really really look at it because it will help us be but if we click upon the problem you cannot click fund wrong but that was just a happy coincidence but we didn't have procedure that could lead us to that all right kareem i see you have your hand up is that related uh yes so this is also something we uh kind of discussed today when we were

doing our postmortem perhaps we can create like a little working group or where we define a set of integration tests um so all the clients actually talk to each other through a public api that is completely language agnostic in which they are implemented and we might have some sort of a staging environment that has perhaps a kubernetes cluster where you just swap clients before releasing them and have this sort of a certification process before actually marking a client as ready for a fork so that at least we know that all the clients run against a given set of tests and whenever something like this manifests in one of the clients that i

will just add a test case for that and we run it again against all other clients so is that i guess i'm trying to understand is how is that similar or different what we have with hive i'm not very comfortable yes so what we have is the this thing we call hive it's on hype tests dot devops dot io it takes uh well i think four clients and these another might get an open ethereum and runs executes all the state tests on them basically start the client import the

blocks as rlp and checks if the latest block after this import step is what it is expected to be in the blockchain test the earned high walls that has i mean there are other tests as well that test the ease protocol that has the graphql implementation if there is such um yeah they made it has a lot of things um and what you're describing kind of sounds like something which could be done in hive oh that wasn't really i didn't really understand if you were

talking about specific like debug analysis calls or if you were talking about testing in general um i was talking about testing in general just to have so each client has their own set of tests so if we sort of delegated all that integration testing to one repository where we combine all those tests together yeah i think i think that basically is five i'm gonna put the link well i'm sorry i'm not really much aware of it kind of even for this ecosystem but yeah that was my suggestion yeah no worries but i've added a link in in the recorded [Music] and reach out to me and or felix

if you have any questions about it i'm happy to talk more of channel sure thank you thomas you had a comment yeah sure i think that whatever environments we define they will always end up having some configuration elements that will not be consistent with mainnet even if we shadow the mainnet there'll be something with chain id and it can still make a mistake so uh what we did when we had an issue with the config file compared to the code used for testing that was from merger here sorry where we actually had the block number read properly in the tests but not from

the config what we did we spent a lot of time adding um internal network specific tests for the config file formats and we've added that for like literally for all the config files that we ever use for different networks we make checks if we accidentally didn't comment the modifications from like death tools to the production if we didn't make anything unexpected uh some some crazy sad tests that are like thousands of lines long that confirm that's the test that the conflicts are are tested in in two or three different ways for everything like this

and i think it's really hard to to do something like this for all the clients because there'll be always something client specific and and it's it's a matter of just like adding all of those config tests and you will still i'm pretty sure that we missed a lot of things and it's just adding it and starting to treat those conflicts as something particularly critical just for example it helped us a lot probably in in many situations so we discovered many times the things that we missed and they actually broke those tests uh james

yeah i just wanted to like take a second and say that of course it's a that it's not ideal for no bum for bumps to happen and things for for issues to come up while having a hard fork but it's also important that like the issue is handled really respectfully and responsibly and it's something i really admire about this group um and something that i think makes us really resilient in how um the when issues come up how they're resolved and then how we work on them in the future so i just want to like give a

congratulations on the open ethereum team on how they've been handling the situation yeah agreed this is never fun when it happens and it's good that we were able to get it fixed uh in just a few hours yeah and the way we've been able to come together and have cross team help on the issue all that stuff is really more important that that exists than there is that there is no issue um thomas i don't know if your hand is still up or you just forgot to put it down sorry

yeah uh jogan your hand is up yeah i want to repeat the same basically it was really great when all the guys came to one zoom and just debug it throw it ideas and that's the reason why we why we respond to this very quickly and it fixed relatively quickly and shout out to everybody that was there thank you very much i think uh in general the main problem of planetarium is basically it's a client that is maintained that is built by different team and it is now maintained by a

small team that still needs to learn what's inside the there but in dark corners and we spend a lot of time uh basically debugging making it work checking what's going on and how it's going on and they that takes a lot of our time and because of that we don't spend basically there i could say that's one of the reasons why we didn't check our foundation and why we basically make that mistake for not removing it and leave it as it is it's hard to be perfectly honest

i want just to say that um basically me was only two guys uh working on berlin now there's a little bit more of us but still a new team and that's why i appreciate a lot of help that we were given in yesterday and today thank you thanks for sharing that and yeah it's a pretty massive effort to come and step in to take over an old code base with a with a new team and obviously as we've seen yesterday there's a ton of people in the community

that still depend on it so yeah it's really valuable work that you're all doing um i guess just before we move on i understand i guess from this conversation you know this is not an easy thing to catch and and uh there's not like a silver bullet there's just one thing martin you mentioned around having a hive run with like main net configs is that something we should look at uh should we take like a next step on that uh i guess it's more like a note to self in the future to try to make the the hive specs more closely aligned to the

actual main aspects got it and i mean that's something that we just fixed in hype and yeah it's not a big cool um so yeah thanks for that uh pooja has already put together kind of a draft public post mortem so not necessarily uh from like open ethereum's perspective but just from kind of a broader perspective uh when uh the open ethereum team has theirs i'll make sure to link it in there um and also make sure to write down the idea around just the the hive specs so that we at least have it written down somewhere

um anything else that people wanted to bring up regarding the issue yesterday or just burden in general now that it's it's deployed uh yeah from operating side again uh i think one one guy from the get noticed that we were not sending a typed section in the proper wire format and [Music] in 3.24 version of pentium this is fixed this bug is something that we should in the future at least should be able to

catch this is basically wrong formatting on on the output of a new transaction but yeah but we only notice because it is on the minute maybe they will not a big amount of the section and because of that it was like harder to notice that in the destination but either way yeah this is fixed in the new new client new version is the ver so the version i think you put out yesterday was 3.2.3 right with the hotfix is that version still safe to use or uh yeah i would recommend users to go to

the next version 3.2.4 it is created last evening yesterday but we publish it today okay so people using your ethereum she's 3.2.4 got it [Music] cool and uh thomas yes um so uh i was asking before if you could maybe put some effort into setting up part of hive that would just test uh the encoding of all the types of deaf devp2p messages um and it would be actually very useful in the case like this of testing whether

the access list or rlp encoded the same way by all the network implementations and this is one area that we only test in high everything in the synchronization test but we could do every single message separately encoding and decoding uh for each client just testing together because yeah i think we do we were discovering like these issues with the encoding of transactions to the very last days before berlin and and the open ethereum missed this uh this encoding of the type transactions so i think this are you passing the hype test done for the heat protocol yes we are all um high test okay that's

the question we're looking at our integration tests and may not include hive maybe okay uh having started something that yeah probably probably the new transactions are not in high because i don't see that many failures as i would have expected otherwise yeah what happened openly i switched one part of the broadcast section properly but another part was still uh not properly complicated anything new to sections

yeah so there is there is a failing hive test in openness broken ethereum which is called test transaction test uh transaction propagation and it errors on some unexpected message i'm not sure if it's due to the actual error that was present or if this is uh an always failing test though so i can't say but but um yeah if it is not yet in hive it should be added and the goal is yes to have all the network packets tested in hype and fedex and rene lubo has been working

a lot on that i think conclusion is maybe that clients including operators should focus more on the high and be familiar with high in interworkings and one more just comment from the chat uh i'll highlight is the idea around having a standard tracing format so i think that's something that caused an issue yesterday because different clients use different traces um yeah it can be harder to to find where the the divergence is between two implementations if if the trace outputs

are not using the same format um yeah wait so there is a standardized trace format that martin pushed really hard for every client to have which one is that is that the yeah chase so yeah they all put trade and i think the parity virtual machine um they have this switch std json i think it is which means that this output in the standardized json but i'm not sure if the actual block processor supports tracing in that format but yeah i would say that we have a commonly defined standardized

op code format and does oe hold on to the bad block as well so that you can easily get at that trace i know that apparently implemented that back in the day i suppose you guys still have it but i'm not sure oh you need to look okay so i guess yeah that's definitely something that's worth looking at uh offline and then yeah thomas i see your hand is still up is that still an accident if

you have a final comment oh hand out anything else on berlin okay well thanks everybody it's done uh after over a year it's on my net um so it wasn't the smoothest deployment but um at least we got it next up uh so i just wanted to get updates from different teams about london i know we have the elute i hope i'm pronouncing this right uh a loop integration network um a couple client teams are syncing to

it right now i i believe the get fork is thinking baisu is thinking and nethermind also is um did anyone want to give kind of a quick update of where things are at there as some of you may know i'm from another my team i'm working on 1559 among other things basically we are ready with our client and we are in sync with uh london devnet so that's it from another mind

and i guess what um what do people feel is like the next the best next step here um so i know that in the discord there was a lot of conversations around json rpc handling uh do we need more time to kind of set those end points up and and just make sure that uh all of the 1559 stuff is exposed properly um i know that on the previous calls we've talked about you know potentially having it another devnet uh once 1559 was kind of implemented and fully specced out um so i guess what the people feel is is like uh like the the next step here should we look at adding more stuff to

a new version of the devnet or should we uh take another two weeks to just make sure that like the json rpc stuff is all all well handled um yeah and then it's just more i guess [Music] ready um before we we add any other eeps is the jason rpc changes fully defined now so not that i've seen yeah i think my understanding is that most things would continue to be like optional

fields there was the one outstanding question i know at the top of my head is how to um how to bring the effective gas price to the transaction object and we could either have effective gas prices as an actual element or just replace gas price with it uh thomas your hand is up yeah i think there'll be some some work on the json or pc that will have to pick up for the eap1559 so this is um already a bit of discussion and focus for the next month or two

um and when you think about the current set of changes for the for the july and the amount of preparation from the community from the tool uh to creators it would be very reasonable to actually suggest even now uh some dates for july for test nets and for or maybe even start we've tested one of the tests early testaments in june set the july date for london and let all these people work against those dates and have very clear planning for when they have to prepare tools the wallets they json or pc integrations and so on instead of adding things and i'm gonna be able to use the remaining vips and start talking about them for shanghai or

after i'm not sure whether we can't do that and also continue working on these eips and if they can make it by those deadlines we set now then you know we do that but if not then they don't i think it's not only us we need to do the work for the uh for the release like even if we continue and suddenly we'll include them that introduces a bit more of the uncertainty of the mountains cup of work for the tool providers and especially with the big change like the ip1559 they want to have a bit of better

planning around it and testing if we introduce something in june as like new year food and suddenly they'll be having to focus on the new changes that get distracted and maybe they'll miss some critical testing at the last stages and so i guess just to make it a bit more concrete this was a bit farther on the agenda but we do have like kind of a list of eeps we've been discussing over the past few weeks um and uh so the list uh i'll just read it out there was 3403 which is uh disabling the refunds 31.98 this is the base job code this is already in uh the the devnet 3074. this is off and out call

2537 this is a bls pre-compile and 2677 that was limiting the size of init code um i guess out of those i know that uh 3403 had been mentioned as kind of needing to go alongside 1559 for security reasons um is that still the case and if so should we just bring it in now so that people know they have to implement it william you have a comment specifically regarding the forex security previously we agreed that with presence and gas limits

brief spurts to forex throughput would not be an issue but the concern was raised that miners would increase the gas limit in london to minimize the base feed perhaps to an unsafe level the initial proposal to fix this was to hard code the block gas limit that proposal was defeated in part because miners have responsibly managed the gas limit if that is changing with 1.559 a hard limit would be better dos protection in this proposal but we can expect miners to continue to be responsible because they wish to minimize dos blocks if they are responsible we expect their consideration for forex possibilities to be a harder protection for the base fee

um so to review uh if we believe miners will push an infinite gas limit it won't matter if the elasticity is 2x or 4x if this is a major security concern we should revisit the hard cap though i would recommend a much higher limit than the original proposal on the other hand if we assume miners want to prevent each other from submitting dos blocks the base fee would be more secure with the possibility of 4x than just 2x i also have some comments on storage but uh currently this is contextualized to uh security for scope inclusion i think we mentioned that in the past that miners really are showing uh great

care about the network security they also um using the opportunities to look at mev now so this is offsetting already some of the potential losses from the eip1559 from their perspective um and even in this implementation nmev we say a huge majority of the miners behaving in a very um in a very cautious way when treating the network say i would say they will continue to cooperate with core developers and community to make sure that the network is stable we see some uh some of the side chains now uh actually losing the a momentum because of going a bit too

aggressive with the block sizes and i think this is also a big warning sign for the miners we've also heard over the last um last month or so some kind of threats that the miners would actually pick up some aggressive actions against the chain nothing like this happened and i think we're very very very far away from that because we simply don't see this kind of behavior for minors so i guess so we'll go ahead now so i'm obviously in favor of 3403 um but not only because i mean i don't see

it as i'm not sure if it is security requirement for 1559 although i think it probably is i also think that it is correct because currently we have this stipend for clearing state but in effect it means that you can do two try rights you can write to one slot in one part of the try and you can write do a deletion which is also right to another part of the state and suddenly you only pay for like half a right while in fact you did two rights and

resource wise um it's two writes that is going into the try that the note has to deal with um so this that we're giving for delete rights um yeah it causes this skew between the resource expenditure and cost and i think the benefit of having this the perceived benefit was that it would uh yeah we wouldn't have as much state bloat and i think it's not fulfilling that so therefore we should simply go ahead with 3403 and um uh and remove this uh resource imbalance i think that uh

teachers logi was the one who first like connected 1559 with the refunds i don't know if you have anything to add to this later nope so the gas pricing for storage as before my time is that when the gas pricing when it was decided what gas prices should be for storage was that based on long storm long-term state growth costs or just just the reads and rights to disk cost or some combination of the two

do we have anyone from that time here did you read the question maybe so there's storage has two aspects to it right there's the long-term state growth and as state gets bigger you know things kind of deteriorate in various ways over long periods of time and then there's also the immediate cost of when you write two states or reads from state you have to do a disk access and that's expensive so like there's the short term immediate costs like the operational costs the you know cost of an s load and a store is that just the short-term operational costs or is it just kind of trying to represent the long-term costs or is it some combination of the two

uh so the cost of an s load was intended to represent just the short-term operational cost the cost of an s store was intended to represent the combination of the short term operational cost and the growth in storage for an archive node and and then the 15 000 uh penalty for fill and use watts is obviously just for increasing state size gotcha uh william i don't know if your hand is just still up for last level yes it is so i agree that uh the long term cost is the major component of store

and uh for that reason we should consider uh keeping the stipend in order to continue to incentivize good behavior and good design since the last call three protocol engineers were concurred in the ethereum magicians forum that this proposal punishes state cleanup and would therefore make state growth worse here's some excerpts sorek writes quote the idea that users are going to get no refund or even discount for setting a storage slot to zero and yet are dinged fifteen thousand gas for setting it from zero to not zero feels really horrible it is the kind of ridiculous special case one that absolutely will change the way i develop contracts as that fifteen thousand gas transition

through zero penalty will light up my test cases as a very large and annoyingly avoidable by using one as the new zero cost that should make one pause and realize we have incorrectly modeled this end quote boring crypto of sushi swap concurs writing quote in this era of very high gas prices protocols will compete on gas deficiency one will be the new zero for me end quote therefore the storage block motivation for 3 403 should be replaced with an acknowledgement that the proposal incentivizes protocols interfaces and users to bloat storage the long-term costs of s-store should be considered especially while we don't have a firm proposal for uh

the long-term garbage collection and cleanup thank you okay so i just shared uh the comments that you quoted william from from the east magicians thread um and then in the chat uh there was a request to to try and uh have kind of think through this stuff async so is that is that something people want to do kind of try to think through that before the next call

async and and then make a decision about it because it seems like there's a lot of information to consider um i remember martin on the last call you said the implementation of this is is quite small if we actually want to do it um so if there's been you know new comments from the community as as there seems to have um yeah maybe it makes sense to just take two weeks to think about that one and then come to a decision yeah i'm not sure if this is i mean this is not like i have a feeling that this is a somewhat contentious thing some people want it one way um

other people want it differently uh sure debate is nice in offline form but i don't i don't think it's going to be resolved at some point we're going to have to make a call we can push it forward fine but i i very little hopes that this will be resolved and like everyone agrees on some outcome got it so in that case i don't know do people have strong opinions already on the uh i do i do so what so what we are seeing right now is and uh what we're seeing live is extensive lobbying by certain people

like the august talking businessman who don't want to see their old precious business model turned to complete garbage i don't think we should pay attention to it and we should just proceed with as planned and i agree okay so turbo yes and get just people listening and and scar you have your hand up yeah but i just like wanted to ask basically in case we don't make a decision today and i i think i tend to agree with what people just now said i i would also prefer like a decision to just include it and today but like if we don't do that the question would just be

what does it mean for the devnets would it not at least make sense because if we say it's at least still potentially part of the core even minimal london then i think it should maybe be included in devnet as soon as possible together with 1559 and the base fee um even before all the other kind of more optional erps and if those ever kind of make it into london or something so i would um in any case independent of whether we make a decision or not i would at least propose that we try and edit for the definition as possible got it oh sorry no i just wanted to make a comments that just reminds us that like whatever choice gets made on the 3403 issue is just inherently not permanent

simply because of the state expiry roadmap that's uh at least my understanding is likely to be one of the top priorities after the merge is going to reform state into a structure where like state being removed is not really a concept that exists anymore in any case um and so like basically the costs of making the wrong choice are not that large and if you are a contracts developer and you optimize for the present reality then or or and you optimize for the post ones in reality and then just keep in mind that it's very possible that after one to one and a half years the incentives are going to change again hey james

yeah i just wanted to say that over the last couple we've talked about it like i i understand the position that william's coming from but it does feel like we're going through permutation a lot of the things that he just discussed we have addressed in previous calls and going through additional permutations of those same things i don't think it's gonna get us any more helpful um and i'd rather just go ahead with it from the perspective of the design isn't working as intended and then with vitalik's statement of the state stuff is being worked out on independently um it just seems like we should we should go through put it in

and if and revisit if needed after after after implementation and the fork i mean got it and thomas oh just question for james when you say we should just put it in what do you mean by that oh to have it go into the devnet and then have it be part of what goes into london that's your i'm against because this is particularly uh contentious one that people will need to change the tooling change the trading strategies uh as william here right like he he's fighting for a cause of like something that that they've built over the ethereum right they're interim users they're part

of the community there might be some more people that are trading around this gas in a way they want to prepare as well right so we can actually communicate that we come with this change and if we have the devnet which is very operational if we actually proceed with it that smoothly um then having the date set for london already for for july we can be so so sure that we can deliver everything quickly that we can set the next days for uh for august of september it will be probably much smoother process and if we start pushing more and more things then it may be that everything all together come on in october which we want to avoid yeah and it's worth highlighting we

i'm not sure what the latest calculation on the difficulty bomb is but um i as i understand it like october is not even possible the network will probably freeze before then um so it seems like uh i don't know uh turboget and get there obviously strongly in favor of this eep uh uh [Music] i i'm curious i note that uh piper has said also strongly in favor for and uh on the on previous discussions yeah um basu and open ethereum do either of

you have a opinion it seems like thomas yeah and i guess yeah thomas do you have like a yeah generally in favor not not for london um open ethereum base you any any thoughts yeah open to your site yeah remove this should be perfectly fine basically in favor of this lp [Music] 3403 but this thomas set should be pushed for london

or maybe we can period for one is basically 59 and base feed it's going to be included besides of that this third thing that you want including one that this shouldn't be a big change but either way um yeah maybe we can plan it for the london but if something happened we could just remove um yeah yeah i see this i was just gonna say mike this point actually that we can include it in the devnet and have it not be part of what yeah which will be fine

uh and i see martin uh couple man i hope i got that right it's on the call do you have a comment yeah i just wanted to bring uh one perspective on this issue i i don't have really strong opinion but um yeah i definitely also want to yeah show the perspective from the from a smart contract developer so i saw as one of the reasonings to remove the refund is that it was not used so basically that that i mean of course it's guest token but contracts didn't use it in the way as intended i can say from from our perspective as smart contract developers that simply really took years so basically in the last years it was not that important to

optimize for um for uh for yeah for kind of a little bit of gas so obviously in the in the last half year it became really important so when we designed our last contract that was written um like roughly half a year ago we definitely tried to fight for every uh well every every bit of gas so what i'm saying is those contracts were written half a year ago then well it takes audit back bounty so those are the contracts we see deployed right now and and then we will see only the effects um yeah over the next months or i guess what i'm just saying is uh the

effect of smart contract developers and seeing things eventually in production chain uh takes takes quite a while so i would definitely expect that we see more and more contracts that are heavily now making use of well deleting unnecessary storage if i can answer that sure and someone was ahead of me and i i just i don't want to over stress or i don't want it to be too much focus on this thing that oh contract developers are not doing it right because that may be an unfair description i think the main problem is rather the various

gas tokens that just uses the state as a battery for to charge up and get back later on um and then yeah there's a comment from gary on basically that if we included in a devnet but not london we might open the door for another bls pre-compiled type of issue where we don't all remove it at the same time and yeah artem james you both have your hand up do you still have comments on this um yes so basically uh we are not aiming

for london but then we are aiming for the merge right after london which i think i said it before but if we're not aiming for london then we're aiming to bury this effectively we must aim for london yeah i guess i do think that's a fair part uh but if say after london there was not another hard fork with with eeps uh activated uh thomas would that change your perspective or not really and it's uh that's what i was mentioning that we need to have the clear clear list of the upgrades and ethereum upgrades including the merge and how

they uh how the timeline looks emerge because exactly when we mentioned the merge as the main focus and it's we see it happening now i mentioned that everyone will suddenly start to push so hard for their eips to be included in london because we kind of created this scary environment that if they don't include them in london then they'll come after six or eight or nine months so i want to avoid it i want to say okay the merge will be the focus it's already being the focus but in parallel we have the the list of ethereum upgrades that tell us where we put the aps that don't go in london and i should be listed either in shanghai or cancun i would say we moved into

shanghai uh share the the plan that we actually can move uh properly with things that we've already tested with the things that we've already prepared for the last almost a year with vip1559 then we can set the dates for july it will increase the confidence in the ability of smoothly delivering the network upgrades uh doing the devnets use all those improvements that we've done uh and also we'll show people how they deliver the remaining eips whether security related improvements around products and they'll start to think okay maybe it's not after the merge maybe it's in august or september october at most um daniel i see you have your hand up

for the first time today yeah so i the the contentiousness kind of kind of bothers me i think we should step back and see if there is a compromise that can be made and the one that crossed my mind is um the way that we we account for refunds right now the refunds account to the accounts and also to the total gas for the block which is the source of the elasticity um would a compromise be to just apply the refund to the account and have the total gas used in block always go up and never be benefit from refunds this would in some cases kind of reduce it for some very heavy defy operations but at the same time

preserve the market for um in the utility the contracts have and these refunds it's one one thing i think worth considering but i don't know how well thought out it is it's something i you know i've been sitting on for a while but haven't very extensively uh war game on it at all i've thought about things like that a bit and i think the challenge is that like making refunds anything other than globally scopes just it introduces a lot more complexity in a lot of special cases into vip that would have to be tested so it would just kind of complexify and bloat the whole thing pretty significantly yeah and that's what got us in trouble with bls

[Music] all right i see you also have your hand up for the first time uh yeah i was just uh curious because i don't understand it fully but do uh gas futures with the introduction of base fee do those help with uh there being less of this uh battery usage of the state or is it is it equivalent in some sense they'll still be just as much state [Music] claimed i can answer that [Music] so being in the market making for gas price um largely the motivation is to increase

the throughput during congestion uh the motivation for using them uh specifically gas tokens uh so if you're using them uh in that context then the futures market isn't going to help you it's going to perhaps uh allow you to speculate if you aren't using it uh still but if you are it's not going to help you that's all thanks um yeah i think james and garden artem i just put my thought in chat of that thomas's plan works if shanghai is an eip

fork and then the next and it and it happens in the fall but if shanghai is the merge and it's not really an eip fork then that likely wouldn't happen in the fall and so then we should expand the scope of blended and i'm okay with either of those plans i just i feel like we need to converge on one of those two tracks i mean there is also just the third track of like just being willing to wait one and uh to wait a year for eips because none of them are that critical which is the and we've been the theory of ecosystem has been willing to wait a year for eip for pretty much all of its history yeah yeah that's fair

i agree with that that's like the third trend i feel like we should just uh we shouldn't focus on the merge too much i mean there is nothing there's not a lot of concrete at this point how how exactly it will look like like we don't have the finalized eep for the merge for for all the interactions between the beacon node and the ethereum one node i think we should introduce like at least one hard fork between london and the merge and uh if we want to stagger eeps if we don't want to include everything from london fine

but we should still consider ibs before the merge uh enscar yes i just wanted to just maybe uh kind of like talk a little bit about timelines here on the on this question so so i think we all agree that we'll have to have london in july right because the difficulty bomb i mean of course details yet to be seen but roughly july or something i think yeah um yeah the latest is like august and you know maybe in august the bomb goes off a little bit but it's not like uh you know the first the first steps in it are not too bad uh and i suspect september is definitely too late yeah okay so it's okay there might be a

little bit room that's good to know then but that basically like uh with regards to this plan of a potential feature for between now and emerge i think like in my view at least community sentiment seems to be really to have merged as soon as possible and i mean maybe as soon as possible means that there's still room for future folk before then but if there isn't i don't think like the community would prioritize feature like as it's like an another feature fork if that would virtually delay that much and i think at least right now the match is still exploring if like uh emerge late this year would be possible and i'm not sure like it will be but like at least it's still an option and later this year would mean something like probably late november at the latest right now to get

into the holiday season and so then um if we have a like emerge fork in late november and we have like london in july or later i just don't see how how a feature would fit in between there like i just even even like in the most optimistic case i just don't see it and so if of course the merge would were to come and say like we can't we won't be like ready before let's say q1 of next year right then we could kind of like see about the future folk but like while while um november or something is still a possibility at least and we would not be willing to compromise on that just for future fork i feel like like a planning of with feature just isn't realistic um yeah thanks for that i'm not sure who

was next between thomas james and artem my hand was just up so i will okay oh thomas there's just all right well one thing that we don't discuss is that if we add the eips to london now this is exactly the moment when we started seeing momentum around the merge they caught f's already started looking at it actually it almost feels like the fact that we just delivered berlin and that the london is so well defined and so well tested already uh all of the corridors just started looking at the merchant making the progress we already see the implementations discussions we already see the calls so adding eips now to london will will actually start causing the delays on the merge itself

yeah and i think one point you know that i also want to touch on based on that and what artem said earlier about the merge not having eeps and whatnot i think this is the main challenge with the merge is because it is uh there's a lot of work to do to specify it core devs need to spend you know just like attention on it like the eeps will be defined by having people look at it and think through it it's not just going to be you know a set of eeps that come out of nowhere that we all just implement uh we kind of have to do this work uh to to spec it out um and that obviously takes you know time and resources um yeah

micah you have your hand up uh last week we talked about getting kind of a rough estimate of the difficulty of each of the proposed upcoming eips did we ever get that made no i'm not aware but i think we we just kind of went over the rough-handed estimate of is this how difficult we didn't like collect them but on the call we did go through that i i feel like that is a fairly critical input here um there's eps like 30 90 30 74 that are significantly larger than the base via opcode right like the base view up code you know is an hour of work and that includes testing like it's super simple

and then there's you know 3074 which is adding two also opcodes but they're much more complex opcodes and trying to say you know well we don't want any eips in london or we don't want any a something to distract people from the merge i feel like that's not quite accurate if you just kind of blanket say all the ips are equal because they are very much not equal um i think it'd be valuable if we could just put together you know be more clear what we're speaking of like are we talking about 30 74 are we talking about the base fee op code edition like there's just such a huge chasm between those two i think base fee is already in the alley

test that anyways so i i don't know if we're still real i thought we had already discussed last week that it was going to go into london uh potentially i was using that one as just an extreme example yeah yeah not to take away similar i think yeah i think there's two things there's two things worth considering here it's like what what's the expected uh amount of work to implement something and would it be the end of the world if we waited a year to have it right which is you know maybe we can sneak in a feature fork between london and the merge maybe we can't i i think people have different you know uh estimates on that so it's like a mix of like will this delay

london and uh would it be the end of the world if we waited a year for it um and i don't know maybe this is kind of a good question to ask folks here like is there out of the list that's kind that we've been discussing i'll copy paste it in the chat here um is there anything that people feel would be kind of the end of the world if we had to wait a year to have it in i don't think it's generally unless it's a security issue it's ever the end of the world but i would like to say that for 30 74 users are spending about 25 million dollars a month just on token approvals and 3074 is going to reduce that by at least 30 percent so

that's going to save end users um you know millions of dollars every single month so if we push that out 12 to 18 months that's millions and millions of dollars that end users are going to be paying you know extra gas fees so i think that's that's definitely a and that's just such a small part of 30 74 it will 37 before it's going to allow for a lot of better interactions with the ethereum network so i think that pushing it out a year is is not the best i think a lot of people very much want it right now uh did we do any calculation whether two months of delay of eip one five five nine or eight months of delay of eip-4074 is more expensive to the users

i don't i don't think we know the answer to that one 5559 we simply don't have data until it launches as to what the end result is going to be thank you that we can't get right now we have data about what the current fees are which are somewhere in the neighborhood of a of hundreds of millions of dollars a month so like for eip1559s and not be a yeah much bigger a much bigger deal that would have to somehow only uh skim off a tiny percentage of transaction fees so i guess you know we've talked a lot about 3403 obviously uh

3198 the base job code that seems like the least contentious and and and the smallest amount of work 3074 i think is something that's been pushed off by the community and then there's these last two 25 37 and 26 77 um it seems like those two have not had i guess as much uh advocacy uh for lack of a better term what is their title uh so 2537 is the bls precompiled um and uh 2677 is removing or capping the size of init code um and i yeah i don't know

code cap is just like a constant change yes i think so yeah i was gonna say it's i mean it's not a concentrate but i also don't see it as something that needs to be done that's 26 seconds not something that needs to be done right now it doesn't matter if we do it sometime later it's just it would be good to have it done at some point that's how i see it oh micah your hand is still up is that an accident and i guess

i i think there's a few folks on the call i see james and i think kelly was there i'm not sure if he's still here um about 25 37 i believe um is that something i i guess yeah i'm curious if yeah james you're on the call do you have any comments or thoughts on that um not really i mean this has been ready to go since yolo uh v1 if i recall correctly so there's not really an update here okay got it i would like bls in the next one if possible i see utility in it yeah um we have it active on one cello

testnet right now with no issues so we're just gonna i think the main net activation is in a couple weeks got it so just i guess walking back also uh to the timelines for london um if say you know the latest we could have it call it is like august first to be safe um that means we probably want to have the the um test the last of the test nets kind of fork a few weeks before that uh ideally probably three four weeks so that means that you know early july we need the last of the test net which means that

um if we want to have the first of the test net kind of at least a month before that uh we oh sorry i i just said uh so 1559 saying the latest possible date would be like august first for example um thomas um and and just right we're just going through hypotheticals i wouldn't want to like uh put that kind of pressure on him right now i wouldn't really feel comfortable with that yeah i guess i just want to see if if we did have it on august 1st you know when do we have to have client versions out ready for it right because assume you have it then it's like you want four weeks probably of test net

because this is like a huge change and then you want to fork if we fork the test nets against one one by one that's another three weeks so you know you're at july first for like the last test net fork then that means you're like the first week of july for the first test network and if you want uh you know client versions out uh a few weeks before that like two weeks before that it means you're looking at like mid-june um yeah mid-june for the first test net which is basically two months from now right um so in two months we need to have client releases ready with full support for london um whatever london is and assuming obviously this includes 1559 which is kind of the the the big

change there um so i i don't know if that changes kind of the nature of like what people think is possible in the next two months um and you know how much testing we have to do on stuff and what not um yeah thomas you have your hand up i think from erp 1559 it would be best to ask the open ethereum team how they how much effort is there remaining is it already fully implemented or because this is uh this is one place where i think eip1559 was least tested and it also defines like how how much capacity is there on open interior yeah that's a good point yeah i can answer it

um our implementation is i can say 90 finished we are in a sync with uh devnet um but yeah we have a lot of additional work to expand the rpc endpoints work on some improvements on the transaction transaction pool for example yeah but for the consensus part of the implementation i think we are we are good and um lots of tool producers will have to make significant changes to transaction pool

analysis because of the ip1559 yeah we we are ready we implemented the changes for it to work with the 50-59 but yeah we have some additional ideas how to improve the performances and so on so at this point it works but it could work better got it and just to ask did you also implement the base fee up code because i know or i guess uh no okay no we yeah we're still missing it for the for the uh the net yeah but anyway it syncs with it

okay and i guess the the reason i'm asking is because that's clearly of the other eips the the one um that's like the smallest amount of work that's already implemented by everybody else so would you have any issues bringing that into london would it change would it make things harder for you uh i would say no okay so this i guess that's probably one easy one to make a decision on does anyone disagree that we should have now that we have it in london does anyone disagree that we should have the base field code oh sorry now that we have the base job code in elute does anyone disagree that we should also bring it into london if it's not a significant amount of work for anybody i think it's so simple that there is

really no need even to decide now well i guess if we decided the reason why i'd like to have a decision it's kind of like what you mentioned earlier it helps tools and whatnot know what's going to happen because i know that there's a lot of applications that found it valuable if they could rely on it and if we can tell them now that it will come alongside 1559 i suspect they can start designing around the fact that it's there or not so that's the only the only point uh if yeah if there's no reason to push back the the decision i think um yeah it's valuable to just state it now so the chat says everyone's fine with base fee um i'll leave two seconds for anybody who

wants to okay so base fees in for london um and then yeah so with regards to the rest of the list of eeps um and and knowing you only have 15 minutes and they're all kind of you know pretty extensive discussions um i'm not sure what like the next best step is um yeah does anyone have suggestions about how we go about for 20 basically 3403 3074 and then it seems like the last two are much less likely to make it in just based on on

uh yeah people bringing them up uh one yeah one note on 25 37 it might make sense for 25 37 to be part of the merge work as well because that it's come up with that so it could wait or it could be part of the merge it seems like an okay thing uh micah i would like i would like to if possible i don't know if the open ethereum team has time um i would love to see their time estimates on each of those eips just very rough ballpark sort of thing um historically open ethereum has been a little bit slower than some other teams implementing just because they're a

fairly new team and they're taking on an existing code base which i know is very hard and so i suspect that in the end they're going to be the decision maker here as to how difficult each of these things are and so i would love it if they can chime in specifically like i think their voices matter is probably the most for when it comes to difficulty and timing and that can be done async like just i would love to see you know just on each of those eips someone on that team to say you know this is we think this is three weeks of worth work we think this is two weeks of work we think this is an hour of work et cetera and i think that's really valuable i can also follow up with all the client teams over the next two weeks and and

kind of chat about that like relative value and relative time and and further stuff that's that's still uh pending yeah can we spend a few minutes and talk about 30 74 because i think we talked about the removing the refunds quite a bit this call and there is a lot of community support for 30 74 so it would be good to you know make sure the expectations are being set correctly sure i guess yeah just uh we only have i guess 15 minutes left the three thing we basically have three topics that i think are important to cover the next 15 minutes so 30 74. i know thomas you've

been wanting to talk for 29.35 for a while and we've pushed it back a few times and then i know dana is on the call today to talk about a clique uh fix that that's pretty valuable um so is everybody okay if we just take five minutes for each of those um and then maybe just starting with uh thomas's one because uh it's been pushed back a few calls already sounds good yeah let's do it okay so let's do yeah 29 35 then uh clique i don't know what the eep number is 3436 and then 3074. um 29.35 i believe that we can skip the discussion for now okay

great um do you do you want to put it on the next call or not i would put it under after the london for the discussion after london okay cool um so dano then you had uh the expanded clique block choice rule do you want to give everybody some background i guess not only on the eap but kind of why the issues we saw around clique that led to it sure um so back in march gourley had a couple of chain holds um because of the way click works whenever it's time to produce a block um basically anyone within the rules can try and produce a block and everyone picks the block that's most relevant if you're the quote unquote in turn one you get a difficulty of two credit and if you're out of turn you get a difficulty

of one so the situation that the girly network was in at the time is they were not um they did not have all of their validators on so they were going to be blocks that weren't going to have intern block producers so there is no strict you know it's not like an ibfg protocol where you elect someone to propose and you wait for the codes and validate it everyone just puts one out on the network when they feel it's appropriate and there's a recommendation that there's some sort of random delay and some clients are better at implementing than others but what happened was essentially a net split happened half of the existing validators picked one block and half the existing validators picked another block because of the way click works um you couldn't advance either side of

the block because there was less than half the validators validating that side of it and because they had the same level of difficulty no one was willing to switch the first uh the first uh halt was a little different because one of the chains was actually shorter because one of the net split sides had an intern block and all the geth nodes were on that side because they have an extra rule to prefer the shortest block there's in their uh code where they do their their whether or not to do a reorganization um they cite a paper um about uh selfish mining and so they pick the shortest block and then when they have two of equal size they randomly pick one that's their current fourth choice rule um a lot of the other clients they just pick the one that shows up first so when

there's a net split or effective net split um you're stuck on the side until a longer or better block shows up so the way that uh so the first net split was fixed by another miner showing up and producing on the block that everyone coalesced around and then progressed and then there was another split of equal length and equal weight and so that the geth knows wrong you know some of them were on one side somewhere on the other so what i propose when it comes to click and click only is that there are a few uh specific block choice rules that go on when you see multiple equally valuable heads of course the number one rule is always pick the the blockchain head with the most total difficulty um that's not changing the second rule would be um to pick the one

that's the shortest get ready mostly has it implemented and i think if we even went there um we would get a lot less uh block uh block chain halts um but that's not enough because we halt it again with equal length chains so the third and fourth rule are designed to to fix that the third rule um you decide based on who is either closest to in turn or furthest from intern it really doesn't matter as long as we everyone picks on the same side and someone producing a block that is both internal um earlier than the other everyone prefer and then the chamber wouldn't halt and they would go down don't pick that chain there is at least one client however that will produce multiple blocks off of a previous head when they see that they

can't produce them so the last rule is to take the hash of the block convert it to a un-256 and pick the block with the lowest number that should prevent all chain halts at that point so mostly this call is to get a call for discussion there's a theory of magicians thread or in the eip threads themselves to discuss um you know are these good ideas or these bad ideas should we have the other other click chains implement these rules or not um baesu has a pr that's under review that implements these um to to do the various rules for basu so you know i don't expect the decision today most of this is a call to encourage people to go to the ethereum magician's thread and discuss it say good idea bad idea whatever and i'd like

that you know some participation before i move it into last call yeah so i happen to have a significant input this one uh but generally the positive i'm strong support of a supporter of what donna is um suggesting so because uh i was participating in the early girly setup for the uh for the multi-client testnet i was actually part of the team that was resolving those issues live on the girly test net they happened uh three times and uh after second time uh me and daffrey were building africa started and i later expanded the simulation tool that was generating thousands of blocks and uh simulating the behavior of

multi-client test net that was having different block choice rules and we could very easily prove that uh this behavior would always happen without the fixes like what dano suggested i was experimenting with different solutions of modifying the difficulty calculations like difficulty numbers from one and two to three and five and three and seven uh these were improving the uh the behavior of the network and but there was just improvement by like it was happening four five six times uh less often uh what that and also i was implementing on undermine some kind of hacks to help the other clients resolve the issues when they were happening so we were pushing extra blocks like forcing nethermines to

to mine on different branches than the ones that the mind was choosing and while they were resolving some of those issues we had one very serious one probably around one or two months ago when we got stuck for a few hours with curly network and what dono is suggesting i've was analyzing that behavior as well and i think it resolves all those cases in a most lean clean way are there any arguments against this that we've heard i wouldn't comment against this because i think i need to encore the spec first in general the

the reason why this you

okay yeah and there's the ethereum magicians thread thomas also mentioned uh there's a the gordy and rinkeby chat rooms i believe uh channels yeah so i guess yeah we can discuss it there and come to a decision but doesn't seem like there's a opposition to it um just to be mindful of time i guess we're gonna probably have to go over a little bit uh hopefully people can sound maybe five ten minutes sorry about that uh yeah like kind do you want to give a quick update on 3074.

oh okay so then thomas i see you have to head out so maybe just before we do the 30-74 update and you know you can catch up with that after um one thing uh so we had a kind of parallel conversation in the chat about the timelines for london um basically if we want to aim for mid-july um we probably need to have the client releases for the fork ready on may 15th which means uh that's like a month from now and the next call two weeks from now would be right before then so we'd absolutely need to make a call about the eeps on the next call there were thoughts about

uh there were thoughts about uh potentially oh youtube broke um sorry i guess yeah i'll fix it after um if someone can yeah i can re-upload the zoom after um okay just because we have a minute uh would people be okay doing a call i guess off schedule next week so we can discuss uh the the different um potential eeps or do people want to do that async um what's the best way yeah what's the best way to just move this forward so that we don't just get to a call basically when we need to make the final decision for london

and and that um yeah we we uh it's just too late so there's a comment about a sinkhole being the best thing next week does anyone disagree with that i think async is better but we have not been able to successfully achieve that historically and so i think falling back to sync makes sense okay so i'll organize a sync off and then in the meantime i'll follow up with the different client teams that ask about the sort of effort slash time slash value ratio for the various eeps um and and we can discuss that on the next call um

yeah so if people have to drop now uh please do uh but i think it's worth taking some time uh to go over the 3074 updates and people who have to drop can can catch up on that uh in the recording and i think i might have fixed the audio issue with youtube in the meantime but if there's still an issue with youtube i will uh i'll just re-upload the zoom recording after this call oh youtube says it's working okay so people didn't miss much except me uh fumbling and we're gonna have a call next week so let client over to you for the 3074 update all right if you're talking like

climbing we can't hear you yeah you're muted i think your mic's unplugged not gonna yellow green bars i mean the same on the call too yeah i'm here so the the first update is on uh monday march 26th at noon eastern uh we have our next 3074 community call um so i just want to put that out there right now i think puchika has the rest of the information on that on the cat herders blog um we also have uh our our second 3074 test net um that's going along right now we have gath on it and we're working on our open ethereum implementation as well

um it's going fairly well i think um cancer is there anything else that i've missed or hello hey now we can hear you matt okay yeah i think yeah it would be nice if matt if you could even update on the audit yeah so as discussed in the last all core devs we have been working on getting an audit setup to take a look at the specification for 3074 and to do some analysis on how it will impact contracts that are already deployed on mainnet and we've got a couple proposals and i think we're optimistic you know with the people who will be doing those audits and the timeline can be completed by the end of may so that's in progress uh we're also looking at you know finding teams to do the non-consensus-related work to

to have 3074 be usable by users and these are things like actually implement these invokers audit and you know statically analyze or formally verify them so those are all things ongoing the last thing to emphasize that you know i think our team is committed and i think there's a lot of other premier teams in the space who are committed to funding or providing developers to make 30 74 happen in london so the goal is to minimize the amount of work that current client developers have to have to undergo so if there is a concern of you know client devs not having time to deal with 30 74 i think that the goal is to make this as minimal of you know a task for client devs if we have this

audit if we have the implementations ready it's really about client devs going through and reviewing implementations and doing the sanity checks i know we don't have all of the teams on the call but um in general are people opposed to say putting 3074 into a devnet uh pending the results of the audit because it seems like that the audit will come in basically once everything has to be done right like we can't wait for the audit to come in digest it for two weeks and then decide to implement it it's almost like we need to implement this and then rip it out if the audit you know highlights some

some severe issue um what are people's thoughts on that i don't really care whether it goes into testosterone i just want to signal that i'm still at this point mostly negative personally got it okay um i think i'll go like on on that topic i think on that topic the the tricky part with 3074 i think is going to be getting everybody actually on board with it um everybody we talked to at first says the same thing as martin says and alexis says which is this sounds horrible this sounds like a security hole etc and then

you know once you talk to them for four hours then that kind of has historically has gone away maybe it won't this time but um the tricky part is you know getting a mind share of every core developer for four hours or however long it takes to convince them that this is okay i don't know how to do that i guess that's kind of the goal of the audit in a way right is to have a document do that uh i i don't know what would uh out of curiosity martin would an audit convince you or do you think you would need something more than that like an audit uh yeah right yes um sorry yeah i lost connection every way

uh if there was an audit made which you know covered both how they how depicts current contracts and also with someone which covers the ux and possible ux how people can shoot themselves in the foot with this and the audit you know uh yeah if the audience alleviates my concerns in these areas i am totally willing to be uh yeah [Music] yeah then i my concerns will be alleviated and i will not be against it any longer i just feel right now that the evolution of 30 74 has gone very

very quickly from like its inception to suddenly being just thrown into the next fork and i just generally think it sounds scary that it going it's going so fast um so that's where i'm that's why i'm negative right now it's not like yeah it's not like the principal stand that i'm willing to i'm going to hold on to it okay i think the value of making sure that whatever auto we get um satisfies uh in particular the second thing martin said which is the kind of the ux what make sure the audit report or whatever we have the outcome from that very clearly shows that you know these are the new ways you can shoot yourself

in the foot and this is why they're okay or this is why it's okay or this is why those things aren't actual you know issues or whatever and i think on that just like if that is actually the result yeah yeah exactly obviously assuming that's the result but on that note uh william posted this in the chat but uh dan finley who's the founder of metamask wrote a pretty long uh explainer after last awkward ev's call um so i suggest anyone who wants to start to understand that uh reads that like it seems like it's it's a good kind of explainer and and from the point of view of someone who actually will have to deal with the implications of 30 74.

and maybe just to like one last like final comment comment on this i just wanted to stress again it's like one of the yeah the authors as well that like i think martin's concerns and i think thomas although of course he had to leave the kong um but like i think he isn't in a similar position i think those are like entirely reasonable and the only reason why we kind of try to fast-track the cip is really just that like there's a decent chance that like afterwards it might be a year without it and it does as matt was kind of like highlighting early on the call and it does actually kind of like might make quite a big difference a lot of the application side people really are very interested in it and so while there's still some chance we just really want to

make sure we kind of try and take it but of course i mean if we just can't quite kind of like alleviate all the concerns in time then i mean so be it right then we just of course um we'll push it along and hopefully have it in like another feature folk and hopefully that'll be toonish or something by that i mean yeah that's that's opposition so we just really like the ip but like um i mean security considerations should never be compromised in any form cool so i guess to wrap this up um all as part of the kind of outreach or checking you know the different client teams that i said i would do uh 3074 will obviously be a part of that and i'll make sure to ask people you know from a work like implementation point of view assuming the audit was positive you know

how big can we actually do this technically for london um so we can actually sort that out um yeah we're already a bit over time but any final comments before uh we we head out uh yeah i wanted to say something that held 1559 stuff was we did the like the community grant for with get going to get a multi-sig to help like collect some of the people that wanted to give funds and that helped a lot so maybe that's something to think about like client or as part of a way to coordinate the stuff you're talking about i'd be happy to talk about offline for that and then yeah okay yeah ping me offline we're working

on something like this at the moment okay cool and then the other the other thing is i think this eip in particular is the the one for me that sits in the if we had a fork and fall it'd be really easy to do well to make sure all this work gets done having to try and get it into july is just like a lot more internal attention about that but having it go in like mid next year is all like uh like severely impacts usability and all this stuff so like the not being able to do this in the fall i think is i think this one to me fits the it's not worth waiting a year for

but it's still kind of like without the fall version it's kind of hard to reconcile yeah i mean the last closing comment for me is you know we've talked to a couple dozen of the most prevalent defy east ux tooling teams people who interfere interacting with and we're positive on pretty much every single one of them and we're looking to raise some money just to show that it's not just positive in words but they're positive that they want to you know put money to support the development of 30 74 or something some derivative of that so that's in progress and you know our team is always available to discuss any concerns related to eve cool um well thanks everybody uh

appreciate folk stay on and uh i guess yeah i will see you all next week uh to follow up this conversation cheers bye thank you thank you bye see you guys [Music] [Music]

[Music] so [Music] [Music] [Music]

[Applause] [Music] you