All Core Devs - Execution #182

Transcript

[Music] this

thank [Applause] h for

in

Danny Ryan: let's go for

it I didn't know it do OJ done excellent um cool I'm subing in for Tim today on the execution layer call this is the execution layer meeting 128 that's issue 961 in the PM repo uh we'll spend as much time as we need on Danon as that's coming up we have a couple of touch points on these retractive eips I think there was some diligence that people wanted to do before they were put in uh then moving on to a number of Prague Electra yel proposals uh a quick discussion around in API Jason RPC changes from M and then um note about

light clients breakout room on the six okay well we have a an upgrade coming hard for coming Dan there is uh blog post out on uh the F's blog with all the latest releases I believe if you do have updates let us know we'll get it in there um I've also seen on release newsletters and things from client teams uh information coming out that way so great are there any other updates related to testing related to releases related to anything unexpected

bar yep

Barnabas Busa: uh so I can conclude what

happened with the min last week we tried to run uh with everyone's latest release there was a couple of clients that had an RC release uh that have since made a releases during the test we did a different kind of spam uh transactions and everything was handled uh very very very well we had very close to 100% participation but the machines are very much overpowered so each of the had 64 gigs of RAM and uh of CPU overhead just to be able to run the in that uh we had to choose a bigger instances

Danny Ryan: was that across the board on a

particular client combos that required 64 gigs or is that just firmly to get

so

Barnabas Busa: so the primary reason is the disk requirement so in order to get uh 1 Point 5 terab ofv dis we had to pick up bigger instance that's why we just had a few nodes with very big uh CPU

annoy gota any questions about the Manet Shad cool

Barnabas Busa: there's one more thing I would like

to mention that uh Gurley is going to be deprecated very very soon or it's already deprecated but it's going to be shut down and Cent make their exits three months after the dankun activation or one month after the Dan main activation whichever comes later that was the sentence we put out in the blog post so the girly Fork was on the 17th of January and Main netw Fork will be on the 13th of March which means gley is going to pretty much die on the 17th April about it so everybody has a date in mind

now

Danny Ryan: and is it I'm looking at it right now it it seems to have participation on the order of like 70% so fluctuating right around the finality threshold did it did people already begin exiting or turning their machines off

normal

Barnabas Busa: we have seen some large mod operators that have decided to exit their vors and uh this caused some uh finality issues uh last night starting from last night they seem to have recovered since then but yeah the participation rate is still quite low I do not expect it to even last till the 17th of April to be honest but

let's let's try and something

interesting to watch nonetheless yeah and that we kind of floating that you other Danon related items

Barnabas Busa: we could possibly also discuss devet 12 and when we want to shut it off maybe a few days after minet Fork

is anyone using devet 12

Barnabas Busa: it's basically just still place where we can quickly roll out some new client releases if anyone needs to test something so it's it's nice to have

around gotcha

Danny Ryan: yeah deprecation after soon after me that sounds great yeah just I'll Echo Justin's comment um just overpower machine seems like a repeat of mistake we made him Paris uh can we kick around with some ideas to uh in subsequent versions of this type of testing get to more types of resource machines that we'd expect um obviously there are probably extremely high powerered resource machines on on the network but seeing some sort of distribution there might be good is that because of the the cloud info that we're using

Barnabas Busa: yeah so the cloud infra basically offers us two different options if you

want nbme we have to go with a bigger machine they don't offer large disc low CPU and low uh machines alternatively what we could do is attach volumes to the different machines and uh think that way but it's possible that the iops of those uh mounted volumes are not high enough for me not to be able to syn it's something we are testing right now and uh possibly we could encounter going forward in the in the future

Min sh Forks

Danny Ryan: right okay yeah it's definely worth investigating something here and

we can we can pick it up down anything else related to the upcoming upgrade Co well in plus two weeks it will have happened so we can talk about it then uh and of course in one week um there's anything else to discuss we'll discuss it then thank you everyone okay there are a couple of

retroactive eips that were discussed two weeks ago let me look at my notes um I believe 7610 uh there was going to be an investigation just to to sity check there' be no ver issues did anyone look into that this is revert Creation in case of nonempty storage

Gary Rong: uh I think the the Blocker of this is this AP is whenever we switch to vericle there is no easy way to determ if the account has the empty storage or not and uh Martin has this idea that actually we can so whenever we switch to the vericle

and the deing the transation we can whenever we encounter a account has zero nouns empty runtime code and nty storage we can just discard the storage which means we will not move the leftover storage from the Merle to vericle and uh in this way um after the transition we can make sure that uh in the exer state this kind of accounts will no longer exist and uh we can then deprecate this um the idea is that uh because for this storage uh it is impossible to access them and also impossible to modify them

because of the empty rtime code so uh it is totally safe to discard them and U also um for this account they all have nonzero balance so they will still be kept in the state even after discarding the storage so um uh if we discard the storage then it will not be a blocker for verod so maybe GM you have something to add or want to mention

Guillaume Ballet: uh not really um yeah whatever um it seems uh it seems like it will uh

it will deactivate itself uh and it's not going to temper or destroy anything during the transition or impact anything during the transition so I think I think this is the right the right approach

Dana um have

Danno Ferrin: they taken the potential of EIP 586 I mean it's not committed yet but it's on the table and that's where you can do a delegate transaction from your EA eoas might gain storage how would that interact with that it might not we might not do the EIP but it's something that's been discussed in the EA circles

Guillaume Ballet: uh so I don't know if Adrian is here but uh if he's not I can just uh uh

add that I've been thinking about that as well oh he here okay go ahead

no no I'm leaving you

Guillaume Ballet: um yeah thanks uh so what uh my understanding is that those accounts have no code so you cannot delegate call them and they were created as the result of of a contract so there's no private key controlling them so you cannot use EIP 586 uh yeah they are not affecting 586 at least that's my that's my point of view

Danno Ferrin: but 5806 would be fine for veral if we put if regular end user accounts gain

storage

Guillaume Ballet: um right you mean in that sense um yeah I mean regular end user would gain storage yes um but so you would not be able to create oh yeah you should be able to create a contract to deploy code at this time right this is exactly what uh what um Gary was saying we we forbid this all the way to

veral

Danno Ferrin: um I'll follow up on E mags or somewhere I'm still a little

concerned

Danny Ryan: okay so um there might be a couple more things to talk about here uh if those are resolved then the intention is to U add this to pectra and with a note that in the event of veral it's deprecated or it would be an additional EIP at the point in veral to deprecate or does it auto deprecate can someone clarify

Guillaume Ballet: uh in its current definition it's Auto deprecate

yes got it

Danny Ryan: okay um so it seems like there's at least a couple things that people want to still mull over um this will likely show up again in plus two weeks to just

B around those hopefully final couple of issues okay uh the next one was 7523 which um I believe there wanted to be a final validation that there were no more empty counts on Main net uh because I think there was some unexpected ones found um previously that were handled but just a final check didn't anyone do that final check I'm also not 100% sure who was going to do

that okay uh we'll kick this two weeks Tim will be able to carry the thread better than I apologies all right on to Prague Electra um there was and account of traction future of eaaa breakout room yesterday um I think there's two things that we want to touch on here one is if one or maybe two people can give a recap if one person gives a recap and if anyone wants to fill in the gaps that'd be great um also yav was not able to join the call yesterday so if yav can help give some additional context on 4337 or I can't remember the number but the native

version of that um and open up any followup questions from yesterday's discussion that'd be great so let's start with that recap does anybody want to take that

Vitalik Buterin: yeah I mean I can just start by summarizing some of what we talked about um basically yeah I think one of the big topics then was just making sure we were aligned on longer term goals of account abstraction uh basically like the uh so the longer term uh just fundamental desire that at eventually we have to

have some kind of account system that is um like one allows key rotations and key deprecations two allows Quantum resistance um three allows batching um and look for allows us allows sponsor transactions and a couple of other smaller things and out of those of course the first two goals are like very clearly not satisfiable with EAS and so present a pretty clear case for for moving beyond the moving the ecosystem to a place where it's beyond EA Centric um but then this brought the discussion to what is what what are

actually the means to get there and like what like what are some of the specific details that are um less resolved here and like what actually is a shorter term road map that is like gets us goals that people want in the short term but it is at the same time compatible with the um this longer term future um so like one of the question is basically know like tradeoffs between like 2938 style design and for 4337 uh style design um questions around

like short-term trade-offs between 30 74 um and I think it was 5806 which is basically EAS being able to delegate call us from my inside of a transaction and like which would essentially let them execute code uh so I I don't think we came to particular conclusions on that though I think there's a general agreement that the longer term stuff is something where there's a lot some kind of medium urgent need for TR or to to try to like actually align on

align on that and like the and sort of figure out the remaining dis alignments and then at the same time for kind of there is this shortterm need to improve functionality for existing users um and that's uh something that has more urgency because there's up there's upcoming hard Forks um so I'm going to let other people continue from there

Danny Ryan: yeah before we move on to Andrew does anybody else want to add unless Andrew you want to add a bit more to the recap or or provide any sort of competing view on on what went down yesterday Andrew

Andrew Ashikhmin: if somebody wants to add something to the rec please please go

on

Danny Ryan: yeah go for it Andrew thanks

Andrew Ashikhmin: um okay yeah I I was thinking about because my my my worry about uh e 3074 is that it just you use you can sign a blank check forever but then I think it was uh that concern was addressed recently and now it's it's revokable um so and and light client during the breakout light client raised an issue like raised a question that if we want to do something in the short run uh then between uh 3074 and um the delegate transaction

5806 we should choose 3074 because it's more generic it allows sponsored transactions so I kind of think if if we make if we consider 3074 for Prague and uh if we have confidence then it doesn't prevent us from the end game Vitality um talked about then if yeah if we have um and the 30 3074 is a reasonably complex proposal but it's also it will bring substantial benefits so yeah if if there is confidence then

it will not break things in the future or like prevent things in the future I think we should do it in Prague or at least consider it for inclusion

Danny Ryan: right uh valal do you have a response to that before we move on

to Amad

Vitalik Buterin: yeah no I mean I think that's like one like good set of thing like yeah the security concern issue is definitely one of the big sticking points and I think it's like good that we're talking about that we're talking about and have made a lot of progress I think uh the other one that I feel like has been brought up less is basically that uh like one thing that would be good to avoid is essentially creating two totally separate developer ecosystems for smart

constract wallets and for um EAS um and like 3074 bit byes like the O op code is fair in its current form fairly EA specific and like I looked at it yesterday and it feels like there's a pretty a pretty natural path to um eventually extending it to be smart contract focused as well but then there's basically the long-term issue then which is like five or 10 years from now there's going to be a lot of applications that have this like extra entrenched workflow where things um happen using the aop code and are

we like does it feel right to um have that to have that kind of workflow just continue to exist and be part of the evm in the long term right basically yeah a long there's a long-term complexity concern and then there is it's like not an argument against 3074 but just like a thing that needs to be kept in mind which is like the POS the question of whether or not it should be extended to also cover smart contract wallets at some point

am man

Ahmad Bitar: um yeah um so just one thing uh that

I think wasn't clear from the last call I think there was a notion that uh in the call um that EAS are not uh to be continue with to be supported kind of um and I feel like this is not the way to go this is something I wrote in the comments but I wanted to voice it clearly that I believe that eoe EAS um needs to be supported up until smart contract account are properly usable and right now we're not there we need to uh if we we need to keep supporting eoas

and making their user experience better uh up until smart contract accounts are catch up to become user normal user usable um that that that's just what I'm what I want

it MH yeah

Vitalik Buterin: yeah I mean I think there's a lot of uh a lot of support for that and I think like that's exactly why both 3084 and 806 are being discussed um and then I think one other thing that's so that and that's short term right I think one other thing that's important for just people listening to this to keep in mind is that in the long term um you know like Bas if there is um an endgame

where like literally elas get removed as a protocol future then like that does not that will not mean any kind of you know like forced wallet change for users right like if that gets done the way that that would have to get done is basically that the EAS would get automatically replaced by uh smart contract wallets that have equivalent functionality

aric

um thank you um so yeah I think yesterday was a very interesting conversation and a lot of good concerns came up um coming from the wallet side uh I think one of the important things

for us to say is that sponsored transactions is a very important capability and for us at least this is one of the big differentiating factors uh between 3074 and 50 5806 um although they both bring value uh but I think so kind of one of the main things that came up yesterday is how could we possibly align the road map between 3074 and 4337 we've been thinking about this today we came up with some suggestions um I'm not sure they're by definition the solution but it does feel like there could be like vitalic mentioned there could be good alignment between 3074 and 4337 if we make the

effort uh to make this alignment um and so that makes me a lot more positive about this

Danny Ryan: a couple more comments and then I want to give y some time to talk um onar and then

Bal

Ansgar Dietrichs: yeah I just wanted to briefly mention that um back when we kind of first talked about 3074 three years ago that um and some of course we kind of G gave a pushing for it but basically this kind of forward compatibility with smart contact worlds was kind of the last thing we did think about um and we we basically were thinking back then that we could have invok has become the de facto standards for new features across smart contact wallets and in EA so

basically like say if there's a batching invoker right for Bing multiple transactions um then that could also we can structure it in a way where that same invok can also be used B my contact walls but that does mean I mean thetic already kind of touched on it a little bit that we would have to be okay with the future where for all of these features forever we are fine with smart contact worlds having to make this extra call to the specific invoker that that then does that for them or something it seems not necessarily like a very natural flow like it basically it adds extra overhead forever to the SM contact world and it's very opinionated on that side but it does give us this kind of interoperability and it does kind of keep keep us from fracturing these two paths so if we want to go with 3074 I

think it should really come with us with the understanding that that would mean on the smart contact quality side we also start using invus for for standardization for the of these features

valal

Danny Ryan: did you have anything to add before we give you off a minute

Vitalik Buterin: no I did not

Danny Ryan: yeah okay

y I just want to

Danny Ryan: give you a chance to add some more context around uh both 4337 as well as the native version and where you see this fitting into um either the short or even the the longterm uh ingame of account of

protraction go off sure

Yoav Weiss: so yeah I'll give a yeah I'll give

a brief overview of uh give overview for those are not familiar and then we can talk about what we can do now so can I share my screen

Danny Ryan: yes

Yoav Weiss: okay so

sorry can you see it y we can see it right okay so uh first I

Yoav Weiss: what we're trying to build in the long term is full account obstruction and uh so what are we uh what are we actually trying to to abstract sometimes in the

in some conversations it's not clear to everyone so our definition is uh we abstract all the aspects of the account which means authentication the authentication meaning proving who you are baring your identity uh to to the account then we have a authorization which uh is something that usually there's a separation in in every security system except the blockchain there is a separation between authentication authorization like who you are and what are you allowed to do so in EA this is implicit if you have the if you prove that you are the owner you can do anything otherwise you cannot do anything so um it's h so authorization we have a replay protection we want to

enable like a parallel uh parallel transactions when the order doesn't matter for example and uh we have in some multitenant use cases there is a gas payment of course we want to be able to to pay with lc20 you want to do gas sponsorship this is a very popular very popular feature and execution abstraction which is execution abstraction which means allowing things like like batching and uh like batching delegation that's uh the kind of thing that 3074 for example does so we want to obstruct all of these problem is that this is a this is a hard problem because um we have to u i mean doing a state doing State dependent

validation means that there are many ways to invalidate to do mass invalidation and therefore to do denal of service attacks against the against the system and the easiest way to solve it of course is by using a centralized relay but that's not what we're here for so instead we need to have a complex mol protection something that uh that allows us to have a to have a permissionless mol and uh the first uh the first meaningful work in this space was H 29 38 which really paved the way to uh to this line of thinking and we learned a lot we learned a lot from it but we also notice that uh when it hit a certain uh

dead end because some basic uh basic account obstruction features are broken by requiring the con requiring the AA prefix which is really a must if you if you don't have this protection then h block Builders can be easily can be easily attacked by transactions that invalidate each other and the the validation rules are also far more restrictive than in more recent proposals which actually preclude most of the most of the use cases that we're already seeing live in some 437 accounts so the goal ofc 437 and and later RP 7560 is to solve this problem and it does so by

separating validation execution so so that and since we have a separate validation H stage we can avoid many of the of the do vectors without uh without being to restrictive so 437 was never meant to be enshrined it's an ERC it's me it's meant to be the the test it's an experimental it allows us to experiment with with C obstruction of different evm chains without having to H to reach consensus on how a count of suction works and the focus is decentralization so there are no centralized U there are no centralized components anywhere anywhere

in the system and of course it has some it has some limitations because it's not native it's less gas efficient we have to waste some gas on some on overhead that could have been avoided with the native C Construction it cannot it cannot migrate e existing EAS it cannot add code so we'll need a separate EAP for that and there are already a few good proposals and uh one big one big issue since who really care about ter resistance is that uh it's harder to support with inclusion list if the protocol is not aware of is not aware of this so um LC 437 is launched actually here at East Denver East Denver exactly

one year ago and since then it's been getting a it's been getting a nice some a nice truction uh last time I checked there were 3 million deployed accounts like 11 or 12 actually 12 12 million user Ops and we see many many great projects many new wallets being built many projects that that use it so it's an interesting experiment to to work on now what is the rip 17 IP 7560 this one is a bit uh like it's a it seems like like like an odd animal because it's not meant for a I mean we are not fully sure yet about how

obstruction how account obstruction should work at a protocol level and yet we went ahead and wrote it so why did we do that turns out that some layer TOS were not willing to wait and actually wanted to have native account obstruction native account obstruction already for example ZK sync had it from day one stet also did and the problem is that each of these they they all took ERC 437 but they created an enshrined version of fit in different ways which in a which first of all caused a lot of wallet fragmentation suddenly you have wallets like Argent that only support one chain and you cannot use the same wallet on any other which is of course

not great for users and uh in some cases it introduced attack vectors because H we did spend a lot of time on a a lot of a lot of time on preventing the N service vectors and not everyone is and not everyone identifies every such case so the solution we came up with is to standardize like to to have a standard version that all layer tools can use and then wallets only have to be written once and can work anywhere and we can and we can help ensure that it's uh it's secure so in short it's um it's something that's going to happen with or without us so we may as well help help them get it right now it's going to be

it's going to be ec4 seven compatible so on chains that that choose not to implement this rip or on or on mayet it's uh you can use the same account you'll be able to switch to use to deploy the same account on a different networks in some cases it will work more efficiently with the rip in others it will use the ERC and this is all still early work so U it's work in progress and we are seeking feedback from core devs and from L tools we are getting a lot of great feedback now all of all of this I think is out of scope for the current discussion because right now we're talking about what can we do for the

next Fork what can we how how can we improve things and there is strong demand for there strong strong demand from for some EA improvements the most common the most common requirement I've seen is batching in order to remove things like the approve and transfer from flow so that's something that uh that's something that I think is worth addressing and uh there's also things like gas abstraction which is actually much hardle to do in a decentralized way but uh it's also something that there is a strong demand and we should be thinking about so I think that uh in this context it's a I mean if we ignore the really hard stuff like validation because that's where all the with the that's

where all the those vectors lie so if we ignore it and we only focus on these two then we right now we have these uh we have these options we're discussing the 3074 route and the uh and the 58 5806 so I'm trying to look at them and I see I mean what do they give us and what risks do we take and so as so as I said the most common case is batching and uh with batching is uh with batching both of them can support batching although I think uh I think that the latter the latter is more is a more natural way to support batching because with 3074 if you have a batching invoker the

transaction actually has to contain two signatures you have a signature for the EA transaction and and the signature for the off and uh of and then there's the and also the commit that is a part of the transaction so the transaction becomes bigger which may be a cost issue on on rollups but more importantly who is going to sign these two trans action these are two signatures it's not reasonable to ask the user to sign the batch twice in order to submit it so it's more likely that it will be used with a relay so like a centralized relay is going to sign the transaction and it has to be centralized because otherwise there are easy ways to grief it so it's it will have to be permissioned in some

way and then the relay submits the transaction submits the batch on your behalf with the 5806 it works um it works naturally just you just delegate this I see this CP as a way to run a script in your account so the user just signs the signs the normal transaction only once and it runs the script that does batching G sponsorship is something that 3074 can do natively unlike 50 real

Danny Ryan: quick on on the batch call um Can 3074 be used trustless Le with 4337 um or does that they had with each other and that

no it can be

Yoav Weiss: uh so I

wrote a post about the Synergy between 3024 and 4037 they are not mutually exclusive in any way and that's actually that's important something I should have said earlier that uh we we need to make sure that no proposals we introduce now no no no count APS make it make it hard for us to do a count of suction later and both of these eips are fine in that sense there are not nothing here preclude us from doing a counteraction later so you can use um so you can use an ELC 437 account on top of it in order to do batching but then you're basically using 4337 you're just using a you're using an invoker but it's still going to

be a 457 uh if you just want to do batching like you know you have an EA you don't want it to become a 437 account you just want to send a batch most likely you're going to use a relay because it's not reasonable to ask users to sign twice does it make sense

got it okay so

Lightclient: but you can use 3074 with 4337 so it's not centralized gas sponsorship

um I'm

Yoav Weiss: actually I'm not sh other than other than making it a full 427 account which means you are no longer using it as an EA I'm not really sure how you're going to use the uh how

you're going to use it for batching I mean if you have an EA and you're using you're using a 437 you want to do batching how what does it look like Ian what is the I mean

Lightclient: does the invoker not just Implement implement the interface of a 4237 wallet

um yeah

Yoav Weiss: you could delegate to a you could delegate to an invoker that is essentially yeah essentially like that but it's um uh um yeah I I need to think about it some more but it's um I remember when when I thought about it it it's not as trivial as it may sound but it may be it may be possible to do that

Ansgar Dietrichs: well well you couldn't have a desent man

pool then basically right so so you're still in the same position that you have just pointed out even if you did have the same onchain logic you'd basically have to also replicate the same mol Logic for these otherwise same problem not decentralized

uh um why I

Ahmad Bitar: I would like to address two things that I noticed on the table first batch call I think uh the signatures can be aggregated by the wallet so instead of having the user sign multiple times the wallet can uh make the user press a single button to Aggregate and sign all of the uh all of the um all of the signatures at once that's one thing the second thing is

Yoav Weiss: wait wait wait wait how uh it's two one one has to be a signature on the commit on the off commit and the other one is is a transaction signature it's not even the same signature format

Ahmad Bitar: sir I understand but the the the wallet can take care of that

Yoav Weiss: but the user let's say you are using a ledger using a hardware wallet you will be prompted to uh to sign twice on your Ledger right

Ahmad Bitar: I mean The Ledger needs to start upping their like instead of like when you're pushing this to ledger to sign there needs Ledger needs to support this new uh approach and it needs to uh or it will fall behind like

instead of having to press multiple times approve on Ledger Ledger needs to uh uh batch batch this information in a single go and have you sign the whole thing in in one goal or or what's the point that's that's one thing the other thing that I wanted to say about this table is the authorization is irrevocable and replayable uh which is not true with the nons uh suggestion that uh is going to be applied soon

Yoav Weiss: um yeah we can get to that in a minute but regarding so regarding batching I think what you're proposing is not that ledger will support 3074 in general because it's hard to do it generally when you don't know about invokers it means that ledger needs to

be aware of a specific batching invoker because it needs to show the user what I mean what are you signing so it's okay it's okay if Ledger prompts the user to sign only once and actually produces two signatures if it knows what it's what it's signing what to present to the user I'm not sure that every Hardware wallet will want to uh will want to do that but maybe they will it's definitely wor exploring so and um so regarding the um regarding a revocation yes it's a if we are if it's only valid for the next nons which is what Matt just just proposed in the chat earlier then uh it is much

easier to it is much easier to revoke all authorizations by uh by just signing but just submitting one EA transaction of course there are some downsides but it's but it does solve it does solve this problem it's replayable it's it's replayable and that's actually a feature not a bug in in the 37 before design some use cases you want them to be replayable but as soon but you but it is revocable so that's H so that's correct and um it's um and in 5806 it's uh it's One Time by definition for better or worse it's just you know just just a transaction so you have no way of making

it replayable whether you want it or not and it's and you don't have anything to revoke because it's a transaction now G sponsorship is something that 3074 can 3074 solves natively but again requires again requires using a centralized relay because it's really hard to do a to do to do it in a way that cannot be where the relay cannot be gri so it's it will requ require a lot of design and with and 5806 doesn't allow G doesn't allow G sponsorship in itself so it would need it would need the new EAP draft uh the new EAP draft we've seen the 79 14 49 which adds gas

sponsorship but it would need since it's a transaction type it means that it would actually have to be merged into a 58 or six which adds some complexity but can but then it will be able to have gas obstruction as well so um now there's um another use case that that people like to talk about is of course is of course account recovery now recovery can be the case of a lost keys or stolen keys and 3074 does does give us a way to does give us a way to recover from a from a lost key disaster if my key got destroyed I can have if I signed a if I signed an invoker that can

move the assets out of my account I'll be able to do that as long as I haven't used the the next nons if I'm going to use the EA as an EA and send a transaction from it then of course it's going to break this lost key recovery uh 58 5806 does not enable any form of lost key L key recovery but none of the proposals solve the case of a stolen key or in some cases you don't even know whether I mean you no longer have the key and you don't know whether someone has access to it or not so this this one so this this requ this requires full account obstruction there's no way to solve it with the by improving EAS um now something that we sometimes

this sometimes don't pay attention to is the principle of list astonishment it's um it's a principle in in user experience where you want to make things as intuitive as possible to the user and since I'm looking at I'm looking at delegation which both proposals do as a way to run a script in your account then what what 3074 ask the user to do is to sign an authorization to to authorize a script to run anytime in the future or now any time in the future as long as you haven't sent a transaction from the EA which burns the nons so that's um and the 5806 means just I want to run this script in my account right

now I'm going to send a transaction that runs the script and I think that the L is much easier for users to grasp than the formal where you are saying I'm allowing this script to run to run in my account now or in the future as long as they don't say otherwise it's a bit I think it can surprise users in some way now there's uh another thing complexity and I think that on all C devs we often um we often only look at at the complexity of the client itself which makes sense since I mean if if that's what you're building you want it to be simple but but I think that we have to look at the total the entire system the complexity like in

3074 the implementation is really simple which is great it's much better for the network but it does it does add complexity in other components for example wallets will have to White list we'll have to White list certain invokers the uh these invokers are not I mean every wallet will have to like audit decide which invoker it support and keep maintaining this list whereas I think with 58 or6 because there is because there is no future exposure it's much easier to uh it's much easier you don't need to maintain H to maintain this white L I think anyway that's the I think both proposals are both proposals can add a

lot of benefit to add a lot of benefit to EAS so and anyone has any questions about what we talked here

no one

Danny Ryan: yeah any any any other comments for y have there's a lot in the chat does anybody want to surface anything from there

oh okay I will I'll

Yoav Weiss: have to stop sharing and then I'll see

Danny Ryan: Andrew

Andrew Ashikhmin: yeah I just had a thought uh so in in if 3074 it says that um a

precompile was considered initially but that as as a means to prevent replay or what not but it was decided against because there is no precedent of um precompile with with storage but I think in in Cancun oh sorry not in canc in Prague 30 um 7,000 two actually introduces a state a stateful precompile so I was thinking if we actually entertain this idea of a state precompile can it replace invokers

uh can we just real

Danny Ryan: quick 70002 is going to

be migrated to look more like um the beacon route op code EIP such that it would be a a

predeployment okay

Andrew Ashikhmin: so it won't be a state compile I see but uh but say like the concern is that we that's that that smart wallets have to wh list invokers so can 3074 be redesigned perhaps with a state for precompile so that we don't like we have a kind of a standard invoker or maybe there is no need for an an V at

all

Danny Ryan: uh like CL or anyone an author on that one want to take that

Lightclient: yeah I mean it's definitely a possible Avenue and if that's the only way that we can improve EAS maybe it's something to discuss but I think it just goes against my philosophy and probably some other people's philosophy about what we're trying to provide to developers which is a powerful framework for building applications if we have a predeployment which is the only context that o and O call are available to be used and it's something that the the allore devs group is dictating then I think that we're going to miss out on some Innovation that could happen um at this layer but again like if that's what we have to do then maybe

that's what we have to do I just personally don't think that's the best path to go down for 3074

Danny Ryan: Gary

yeah I'm wondering um since y didn't really speak to 7377 um it seems to me that 7377 is a much lighter touch approach for enabling account abstraction and kind of getting users from eoas to u to a Smart contract uh account abstraction uh you know future it it allows uh you know 4337 can develop in parallel and this doesn't have to be enshrined uh early you know it's what we're trying to Target for Prague is light fork and it seems to me

that at least 3074 uh and 50003 in in combo would uh create a lot of test uh and kind of attack surface that we need to uh be careful about and that's starts to grow the fork starts to grow the prag fork it seems like uh in my opinion 7377 is really the the approach that is uh you know light touch enough and still future forward uh but also includable in Prague without making this into a larger feature Fork that is kind of against the the principles were set out for having a small feature for before

veral yeah so I

Yoav Weiss: agree I agree this uh

this is something that is isogonal to the other two proposals maybe I should have talked about it separately and it's uh because 437 or even 75 60 currently don't talk about migrating an existing EA and adding code to it and the end game for account obstruction does require solving this problem as well so yeah if it's possible to include an account migration EAP then uh then I think we should consider it

Guillaume Ballet: um I only have a side note for something that had been said before maybe uh if italic wants to talk to address what Gary said he should go

first

Vitalik Buterin: um yeah I mean I think uh just a kind of response to the general idea of like why not basically yeah give up on eoa improvements entirely and try to Fast Track making um like making it easy for while existing EAS to participate in 4237 um I think uh probably the biggest um objections uh to this are um you one one is I mean of course there's um kind of like general you know like fear of new things um and but that's something that's just like so continues to be being being

drisk with with every passing gear but another a really substantial one is uh higher gas costs right so 4337 does have significantly higher gas costs than EAS do and this is something that sort of some sense in principle should not be true because you could have a 4237 account that's like literally running the same workflow as uh in ecdsa based eoa uh but in practice like basically eoa gas pricing is cheaper than um the the storage operations that 4237 does and I think as I mentioned in the chat the this is something that can be fixed

um by like BAS basically overhauling the gas cost system and replacing it with something more principled that charges for storage accesses in a neutral way and the veral tree EIP actually does have a component which does exactly that um so that's uh I mean that so that so that's one big thing um but like the ver but that kind of goes goes against the idea of like doing something gives users functionality that becomes available pretty quickly and uh and before viral trees do and then of course the other one is

just like cross Layer Two stuff right like whatever you know if L1 has amazing 4337 but uh like but ler 2 is did not done like that's also an issue and like also a a thing that's going to contribute to like time delaying of any attempts like very rapid attempts to get everyone over to Smart contracts

G

Guillaume Ballet: um yeah so just a side note on what you said earlier that there was another contract that was going to be deployed the the 4788 I think way

Danny Ryan: um 7,002

7,000

Guillaume Ballet: yeah right exactly um the

the issue is this that might not be clear to everyone but it's going to have a huge impact okay at least to have an impact in vertical mode is that if you start deploying contracts uh that are part of regular block execution um you find yourself adding code chunks to the witness uh and so the choice actually no longer exists whether you want to uh use the the Sol the the evm bite code compile version or if you want to take the shortcut and and go right directly into the the contracts memory um I I don't think we should discuss this right now I'm just pointing out you might want to hold uh hold off your horses on this

one uh on because I think uh 4788 should be I mean the contract should still exists but the execution the bite code execution should actually be removed so that the so that the the witness get smaller

Danny Ryan: um I guess I I I kind of see that as a feature like when you put anything into the uh the evm here then you just get you get it by default but

Lightclient: um it does just kind of suck to send the exact same btes around the network every single block you know like if people are interacting with contract it makes sense but if it's

something that we as developers of the protocol just sort of enshrine this shackle on our Witness it's a little unfortunate um I mean 4788 contract is 86 bytes or something so it's not a huge deal it's just a weird thing

Danny Ryan: sure but if you don't then you're now it just becomes an additional input to State transition right that you have to be carrying around that's a fun pass blocks rather than just one

Lightclient: well it's not a function of past blocks it's just enshrined in the client like the code just lives in the

Cent Oh the code component got you as binary

Danny Ryan: okay um we can pick that up

another time so we are at the hour um there is a desire potentially to get small versions that iterate us towards um improvements here it's very unlikely that in the next Fork that we're going to hit some sort of I think it's maybe I'll change that from very unlikely to impossible to hit art kind of final account exraction goals um I do think in the next couple of calls we do need to hone in on if there's going to be one or two I won't even some amount of small um eips uh so we're going to have to pick up the conversation again um I think also in parallel There's A Renewed Vigor to try to hone in on on what does the

short medium and long term look like and to make sure that um both the eips that we might consider today as well as we want to layer in time um do help us get there so let's keep the conversation going um I don't think we're going to schedule another breakout at this point but it does seem like there might be an appetite to be regularly touching on this outside of all core devs um so um we'll we'll throw this on the agenda in plus two weeks to at least think a bit more about uh the strategy and and to consider a couple of discreet VIPs thank you everyone um we do have half an hour we'll try to get to what we can um next up was EIP 7623 uh Tony was going to give us a a

view on this increased call data cost

Toni Wahrstätter: yeah hi everyone Denny I will be very quickly

Danny Ryan: so your mic was really bad I think maybe it's a little bit better but make sure you're talking into it

okay let's I hope I hope it's been it's better enough

Danny Ryan: it's worse now um maybe you're going through your computer instead of your headphones or something like

better

Danny Ryan: seems pretty bad pretty bad

Toni Wahrstätter: test test

Danny Ryan: uh crunchy but much louder it might be doable

Toni Wahrstätter: okay let's let's try it um yeah so basically the E is the goal of the E is to ruce the maximum possible block size by increasing the cost of C data um particularly for nonzero call datab bytes um it does so by increasing the cost for call data for those transaction that are mainly using ethereum for data availability and you can you can look into the EAP it has this conditional formula so with a floor and a standard token cost and if you spend basically

enough um gas on evm operations then the call data cost will be um yeah it will remain at 16 um gas per call data bite and otherwise it will be at 68 um yeah currently the the maximum possible block size is around 2.5 megabyte something like that and with that EAP one could reduce it to around 0.5 megabyte um I just posted a link into the chat so you can see a lot of more details some analysis which accounts are affected but basically um normal regular users wouldn't be affected at all so they would just continue paying 16 gas

per call datab BTE while the data availability users would pay 68 gas per call databyte and I did some quick analysis for um the last um 12 days and it looks like that around 96% of the transactions would have remained unaffected which means only 4% of them would have paid the 68 um gas call data and most of them are data availability or users um writing comments in their call data and those 4% that will be affected it's basically 1% of the users and the large chunk of them is using call data for data

availability

all

Danny Ryan: there any um clever ways to try to get around this threshold like batching across multiple transactions or justes the 21,000 hit break break such strategies or are there any other things like that under consideration

Toni Wahrstätter: um I've actually not thought about um batching I don't think you should be um you should be um there should be a possibility to to get around that so the only way to get to um the cheaper price would be to spend money on evm operations which is then um yeah counterintuitive

right

onar

Ansgar Dietrichs: yeah I just want to say that I'm strongly in favor of shipping a um kind of call that a price increase in general uh in in the next f um so that we can limit the the kind of Maximum worst Cas BLX size and in this case this does this um very well by really go by going down from three megabyte maximum to.5 megabyte which of course is a huge Improvement um and that way it would give us also room to include an EIP to increase the 4 for four throughput like I think I mean ideally I don't know depending on how stable n turns out after we we ship T ideally I think something like 86 16 or so would be a good Target which still would in would result in a lower maximum throughput than than we have

today um I I do think kind of this question around this this this mechanism for for basically rebating I mean I know it's a bad word but rebating basically kind of the cost the the high cost for call data if transactions also consume more normal um gas I think I think it's interesting I could imagine that this is a bit more contentious so so maybe like this is in a way like an optional part of the AP in my mind at least um but but it's actually a very clever mechanism and just to give a little bit more context right like so in the past we've looked into multi-dimensional resource pricing and the idea is that it's kind of unfortunate that we always price things for the worst case and the worst case is that the block only consists of a sing like only consist of using that

one resource right so basically we press compute for the worst case block processing times if you only use compute operations and we price data for if you only have a block that's full of data and be price storage for if you only access storage like multiple times in a row right and the the beautiful thing here is that basically now it it still has this high price for for that bad case for the attack case basically but it gives you lower prices if you actually have a much more realistic mixed use resarch block and this is actually a mechanism we might be looking look into applying even for other types of resource mixes as well basically it's it's a way of kind of elegantly making making the total kind of resource usage BL more efficient so so I personally

like that part of the mechanism as well but I feel like basically even if people might take issue with that part I think shipping any form of call data price increases is very important for the next

fall

Danny Ryan: any other comments or questions I'm not sure if cl's had a chance to look at this before any initial reactions um for consideration in the next work

Marius van der Wijden: so I've implemented it in gu and it was I like a five line implementation I did make some mistakes

thank you vitalic for putting pointing them out but um yeah I fixed it now

Danny Ryan: glad we have good code R yours um any other initial reactions um if not we'll probably give give everyone a couple weeks to chew on it and and bring it up for more reactions in plus two weeks okay thank you Tony um next on legendo Antonio did put uh EIP 2537 on up for discussion I'm not

certain if he had seen that it was already L for inclusion in the Met EIP um was there anything else we wanted to discuss on 2537 or was that

it

Antonio Sanso: yeah uh can you hear me actually

Danny Ryan: uh you sound like you're in an echoey far away room but we okay

Antonio Sanso: one second

Danny Ryan: and if you can't get the mic working is there anything else you want

to discuss other than just see if it was going to be

includ is it in better Ben yes

Danny Ryan: yes great

Antonio Sanso: yeah actually yeah I mean finally this uh this VIP seems to be like getting traction and uh actually I will have a some folks uh mean me and some other people started to look at the at the this uh text more indeed and actually I will have a question uh if you guys have an an opinion on kind of uh not an issue but an implementation Choice basically like uh this uh specification is pretty different than uh EIP 196 in a way um because like we have operation like add and scalar

multiplication like the BN curve but um that uh the BN curve does is a prime order curve and uh this one is that is not so test Co Factor uh so now while it's clear that for pairing we want to do the operation on the magic sub group the one that we are using uh in the consens layer it's not clear what we want to do for the scalar multiplication and the addition uh for the CIP if you want to stay on the on the Magic's group or or acting on the full uh order of the curve and if you choose to stay in the group we have to pay a bit the price of

the validating the points so this is pretty actually I I've been writing start to read the test for this specification and it's not clear at all what would what we want to do here and I was wondering if anyone has an opinion um just like to give another perspective in in the in the consensus layer we don't have this issue because we are using only the BLS signature scheme but here we have as well adding points and scalar multiplication

per

Danny Ryan: if no one has any any comments here maybe it's best to write this down and

see if we can get some view on it in next couple so

an

Marius van der Wijden: right now we right now uh all of the libraries are using the are doing the subgroup check right at least that's as far as I go I saw for for pairing

Antonio Sanso: yes for for like the the operation of adding and scale multiplication not all and for sure it's not specified by the spec at the moment but I agree with Danny that we can talk about offline so maybe I will open an issue on the repository

Danny Ryan: okay that' be great Mark has his hand raised as well

um yeah I just wanted to add one thing on this EIP um that I felt that

maybe um it was missing the um the ability to do operations in the result of the parent group so the moment um you can do operations in uh G1 and G2 but then you can't and you can verif ify um the the result of two pairings are equal it doesn't let you do um to get the pairing result and do further arithmetic on it um which is useful I think primarily for verifying some like aggregated SNS so I I felt that this would be an improvement to the EIP

Antonio Sanso: all right um yeah I will suggest as well to like maybe discuss this on the

on the GitHub and uh we'll follow up there

Danny Ryan: okay yeah I I think to get the right set of eyes on this a written version of it will be helpful thank you um before we move on uh Charles wanted to bring up both EIP 5920 and EIP 769 both these were discussed on a previous call uh but we're looking for a revised kind of temperature check if anyone uh client teams had uh given them more thought or um wanted to bring in any comments on those uh so EIP 5920 is pay payout code

any any comments or further thoughts on that since it was brought up

Marius van der Wijden: yes um we kind of um had a team meeting with the eels team and the the east team the execution executable execution layer specs and the executable test no spec tests and uh one of the things that we did was sit down and talk through a random EIP and we picked the pay uh op code and kind of discussed all of the all of the implications it has and

um all of the texts that it can be um that that we need to think about that we need to test when when when doing this CIP um and it turns out it's it's quite complex um the testing the Erp itself um was underspecified but I don't know if Peter is here but he wanted to add some more specification to the um and uh um and yeah in in theory I think the EIP is okay um it's just a lot of stuff to test it

Danny Ryan: okay um and is Peter intend to do the

revisions in a PR

Dana

Danno Ferrin: one minor thing is that um the payop code and the aop code are current slotted for the same op code number so that needs to be resolved got it

Danny Ryan: any other temperature checks on this one

Marius van der Wijden: for the transient uh storage pricing I don't I don't think we should do it uh we should even think about it before we have the transient op code in the in the chain and see how it's used and then we

can start having a debate whether it's mispriced well we should have the debate whether it's priced too high right now uh too low right now but um I think this this uh EIP actually wants to um price it down

Danny Ryan: okay well we will begin to have data in 15 14 days

Charles Cooper: um I think please sorry yeah I think um it's good to wait for data um but the data won't be complete in the sense that there's use cases that revising the pricing down enables uh which we won't see in the

data so I mean you can kind of get some benchmarks or some ideas how much um resource usage you get but you won't get clear a clear idea of like how it will be used after the pricing change versus before and one very important use face is uh re-entrancy locks so uh Viper would like to enable noncy locks by default um it's like kind of iffy whether that makes sense if T store is 100 gas but if T store is cheaper then it's pretty much a no-brainer and I

think that's a big step forward for um smart contract development ux on ethereum

Danny Ryan: um were there any other thoughts or comments on 7609 um I guess one we can get data on usage yes that will be incomplete with respect to uh potentially not unlocked use cases but also I'm i' I'd rather T be here um on either of these to kind of better gauge consensus but but any any other comments on this before we

move on today

Charles Cooper: um sorry again but I'd like to also point out that the EIP actually improves resource usage um in that for small number of slots the pricing is cheaper but it actually caps the amount the number of transic slots that can be used at a at a much lower number so you go from being able to use like I think 10 megabytes with the current pricing to under one megabyte after the after the pricing change

Danny Ryan: sorry and this is just a function of the pricing change or is there another change

Charles Cooper: um it's a function of the

pricing change because um the pricing is super venar so it's cheaper for small numbers of slots and more expensive for large numbers of

STS

Danny Ryan: okay um we're going to move on uh like client I did not get this on the agenda I didn't see it this morning IP 7639 CE serving history before POS uh can you give us some context here

Lightclient: hey no worries um yeah so this is really a splintering of EAP 44s I don't

think that we are proposing for force to completely realized in the next hardfork but there does seem to be quite a bit of demand from client teams to improve the situation with how much data they are required to store on disk and since we have been working quite a bit on a standardized format for sharing Prem merge history I think that trying to Target this next Fork as a time where we can stop serving that pre-merge history over the network is a pretty good direction to begin looking and I just wanted

to uh you know get it on the call now and and to start discussing a bit and see if that see what the appetite is from teams to maybe make the commitment that in 6 9 12 months that it's not going to be possible to get that information over PTP and you will have to use some external data source the other big piece of this EIP which I think some people have left some comments on the pr maybe we'll split it into a slightly different thing that I think is important to have a green light from ACD is this header accumulator the header accumulator is really a interesting pre-merge uh interesting Prem merg data

artifact that is inspired from the historical Roots accumulator on the consensus layer and it just gives us an efficient way to communicate about the entire pre merg chain with just a hash stre route and then make proofs about about um the history of the pre merge chain in log size rather than in linear size so I want to get agreement both on this is something that we want to do we want to try and stop surveying this data over the P2P in the next hard fork and that we have been able to verify that this is what the pre merge chain looks like so in a sense we're like committing to a later um authenticated route per se of

the chain

Danny Ryan: sorry and I haven't looked at the AP where does this where would the the pre merge route show up this is just baced into the client or is this some sort of State transition change

uh it it's a lot more up to what

Lightclient: clients want to do with this given that there will be other ways to access the data if your client is going to still provide users the ability to download that historical data then it's going to be important for client binaries to include that root hash and then verify the data they're downloading is authenticated against that root

hash

Danny Ryan: okay so this just defines a canonical way to kind of come to that root has dictates that root hash in CIP such that it can be easily included and agreed upon in

by names yeah exactly I

Lightclient: I don't know this could possibly live outside of an EIP it may definitely live in a different EIP but I think it's probably important that if this is the user story we're going to provide for downloading history we should probably as a group agree that that's the route that refers to the data before the merge

I

Danny Ryan: see um any questions for like client or any um initial comments or temperature check on

this

Mikhail Kalinin: yeah I assume that this um um also about not not just blocks but also receipts right like all chain Data merge uh so I just wanted to say that probably the CIP is kind of like dependent on something like 6110 um yeah and I mean like because otherwise some C clients will not be able to reconstruct the deposit Tre um because they will uh logs will no longer be available

Danny Ryan: that's true are there any other consensus on

either consensus or extion layer that uh requirements on logs or is it the single I believe that's the single okay uh anything else on this one before we move on seems like something that uh is worth chewing on and surfacing in a call or two to see if there's any additional consensus here okay M engine API and Jason RPC changes

Mikhail Kalinin: yeah so I I want to quickly talk about um engine and Jon CPI changes um

potentially entailed by the confirmation rule uh the confirmation roof as a reminder is uh a CL construct that under certain assumptions allows to uh confirm a block uh within one slot U uh confirmed block uh um yeah it's it's assumed that the confirmed block will remain canonical will remain in the canonical chain and eventually get finalized if those assumptions uh are true so this is kind of like uh uh quite uh cool feature for daps and services that use uh blockchain data uh to get early block confirmations um and uh yeah obviously we want to expose

these information somehow to to those uh uh parties who use uh who work on D daps and services and uh the way uh that is kind of like uh we can do it is to basically uh take the confirm block hash from CL uh propagated to El as we do with the save block hash and expose this confirmed uh block uh on the from the outside YJ or CPI uh so this basically like the default uh way to do it and uh yeah there are a few discussion points due to a lack of time I think we can uh

go over them uh later on on some later calls I just want wanted to uh say that potentially uh if we decide to to you know to propagate this information and to expose this information to users in this particular way uh we'll have to do these changes to the apis and uh considering that the confirmation R research is being finalized and uh then uh we'll be able to to finish the spec work uh which has already been started um I anticipate that uh this kind of change will probably be required uh uh as a part of our work on Electro prog and I just wanted to rise developers awareness that there is yeah potentially

we will have this change alongside to EIP yeah and I can answer some quick basic questions through the time or we can move the discussion to you know

Danny Ryan: where the execution layer can be not care about this at all and it's the requirement where you you just get it from the RPC on the the uh consensus layer and then utilize that hash um for queries on the execution

there

Mikhail Kalinin: yeah exactly but uh probably Beacon apis aren't the thing that is commonly used by da developers yeah I I don't know I don't want to claim this

this more like a question to me so

um yeah I think you know

Danny Ryan: there are plenty of places where they're not accessible or just not not commonly use that's certainly correct

Mikhail Kalinin: yeah we could also uh use Save block hash change it to expose the confirmed block but uh was a kind of a point that the save block hash probably is treated by people uh more as a more safe you know uh block reference than the confirmation rule can provide so this why we would probably want to have a new thing

Danny Ryan: and that that was the int but I think given the use of that word safe uh which is probably an abusive

terms to begin most people are not my temperature gauge on that has been uh people are kind of afraid to to undo that also uh given that this might be rolled out at variable times um the confirmation role then all of a sudden depending on the client you're using and um the version you might end up safe might have very very different meanings um okay uh let's let's pick this up either on the contest later call and the execution later call next time um thank you m and the final thing is there will be a light clients breakout room March 6 at 2m UTC there is a link to this agenda in the PM repo uh this is issue

971 any other notes on that Phil you would put on the agenda

Phil Ngo: nope that pretty much covers it thanks Danny

Danny Ryan: okay great well we are any final comment we have

30 seconds

Marius van der Wijden: yes um I would like to propose in a new eth client version that uh where we don't send the bloom filter in the receipts um basically we we figured out that um no client is actually storing the bloom filters for the receipts um because this data is for the two and a half billion transactions that

we have right now or 2.2 billion transactions right now um this data is roughly 550 gabyt and uh the problem is whenever someone syncs um we will request the receips with the bloom filters so the person that we're sying from has to pull up the receipts from disk uh generate the bloom filters send it over the syncing Noe verifies that the bloom filter that the receipts are correct and uh then deletes the bloom filters and stores everything else to disk so instead of that we can just send the bloom filters with uh the the receipts without the bloom filters and the the

node on the other hand has to then generate the bloom filters themselves and not store them just to verify them um this would uh save us roughly 550 Gab uh of bandwidth during initial sync and also a bunch of bandwidth during normal plock oh actually no during normal plock production we generated ourselves so it would wouldn't save us any band voice there um but yeah so I'm preparing an EIP for a new e protocol version I can send the link of the draft and this will

also remove um this will also remove two other messages and the TD the total difficulty from the handshake because we don't need the total difficulty in the handshake anymore

Danny Ryan: okay um we're going to keep an eye out for that EIP circulate the draft Andrew I see you have a comment but I have to go I'm not sure other have to go um take care thank you everyone

Marius van der Wijden: we can discuss on Discord see you

thank you

up J

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