All Core Devs - Execution #181

Transcript

[Music] J

oh [Applause]

Tim Beiko: okay welcome everyone to acde number

81 um bunch of things on the call today so first uh just going to go through Denon updates I know some of the El clients already have releases so um yeah shout about that and see where everyone's at then U Martin had an EIP uh he wanted to discuss that uh should be retroactively applied from Genesis um and then so we can discuss that there was another one by Peter uh who can't make it but left the big comment in the Discord uh that also is a retroactive viip um so finalizing those two discussions after that moving to Prague Electra um there's three eips that

people wanted to present and then tomorrow we have inclusion list breakout room so go over those things and then hear from client teams uh how they're thinking about uh filling up the rest of Prague given what we've decided around veral and Osaka and uh one thing there as well so we had sort of committed to 2537 but uh yeah just confirming that we're still good with that um yeah hopefully we get through all of that

uh to kick it off uh anyone have any specific Denon topics they wanted to discuss otherwise uh any clients want to share where they're at with regards to client releases

Barnabas Busa: thinking some may not notes for

the of the main sh should probably take place on next week the not that have not seen yet are and rest which are expected

Tim Beiko: you're breaking up a bit but I think I understood 90% of what you said so you're thinking maget nodes you're missing W and another client

Parithosh Jayanthi: yeah it's just the archive notes take a bit longer to syn but we should be hopefully ready sometime next week and that should be in time for when client teams have releases up nice oh okay yeah R in Aragon are the one still sinking got it um sweet

yeah and how are I know I think G and Basu have releases out um nether mind Aragon bre uh yeah how are things looking there

Marek Moraczyński: yes we are testing our release we plan to release tomorrow or on Monday

Tim Beiko: nice

Andrew Ashikhmin: yeah the same with Aragon will publish a release tomorrow or or on Monday

Tim Beiko: sweet uh r r is out um so one alpha 18 is the main net release for Denon and then Basu get what was the release number for your

clients

Basu is 24.12

Tim Beiko: got it

Justin Florentine: at least yesterday

Tim Beiko: and guess anyone um okay I don't have the number quick but uh I think guest release came like right after the call last week so uh it's been out for a few days now um any CL folks have updates on their release uh I know that on the call last week uh teams on the CL side needed a bit more time but yeah any updates people want to share

PRM

Terence Tsao: is um going to release um by

next thir thday but um just to heads up we're still blocked by the CL release cuz we have this uni test that basically um set a Manet for art but it puts the Manet Upstream um releas so until the um C back does release for the main4 part we are currently blocked so so so so yeah just wanted to flag that

Danny Ryan: okay um I was a bit AFK the past couple days I know we did approvals on the little PRS that needed to be done um I'll check in with Shia and we'll get it out by tomorrow morning

Terence Tsao: thank you so much is already can you hear me sorry

yeah we can oh cool um yeah teos is already releasing so we are in the final stage of releasing

Tim Beiko: nice

uh Lord star is

Gajinder Singh: is also ready to release so we are we are just doing some final things so we most probably can release early next week

Tim Beiko: sweet um anyone from limus or Lighthouse I think those are the two we didn't hear from yet

okay um and then yeah there's a comment in the chat AB Barnabas saying we should wait until we have all the Y pairs for the release I think that's reasonable so probably means that um we we have all the releases out by say like late next week and then maybe we schedule the my net Shadow fork for like the Monday after that or something so that we can put out the blog post uh one day after uh once we're sure everything's all right um does that seem reasonable having like the last mainnet Shadow Fork on say Monday the 26th

I

Barnabas Busa: if we can have all the by Thursday then we can do it on

Friday because expensive not to run so we wouldn't necessarily want to wait over weekend if can do it by by next week thday releases are out and we can do it uh next week Friday

Tim Beiko: yeah I I like that um yeah okay so let's aim for Friday the 23rd and then um yeah we'll have the blog post out uh early the week after assuming there's no issues that we find on the shadow Fork um would argue even try to do the Shadow from the okay

um sweet I guess anything else on Denon oh yeah Carl

Carl Beekhuizen: uh yeah I know there's previously some mention from l2s about not quite being ready or it might being a while after that uh we had a looll call yesterday there lots of discussion around this um it seems like we're uh at least going to have uh uh one of the l2s ready being polygon but many others are still trying to have uh some kind of main release ready um very soon after or even on the

13th

Tim Beiko: nice so that's looking looking nice see anything else on

Denon okay then next up um yeah these two retroactive eips uh first one 7610 uh I don't know if Martin is on the call um if not there someone else he's Sor

he's not here today unfortunately yeah can you can you give the context on this Maris um or someone else I could probably

Marius van der Wijden: try but I think someone else might be more equipped to do it

Danno Ferrin: I'll take a stab yeah so this is um looking to amend the contract creation rules right now if a contract's being created in address and it has a non-zero notes it fails um this rule would extend it to say if that address has any storage it also fails and there are a few contracts that existed before on the Shanghai attacks that have a zero noce

but have storage but also have no code um so I think yeah the two things need to have no code and a zero noce for it to succeed so if there's code it'll fail if there's a notes of one it'll fail and they change the rules and the shangai tax require notes of one on all creation attempts successor failure um well not successor failure but if they if they leave code or not so there are a few Cod code there are a few addresses prior to Shanghai that have a zero Nots no code and storage because of failed creates and um these are all coming from create one attempts now because it's a create one depends on the Nots the Nots has been incremented by rule it is impossible to recreate the situations to create that already so this can't be created unless there is a hashing

accident um of one of those you know impossibly large hatching numbers where the collisions are basically impossible so we're so to change this rule we make it so that we don't care if there's a hatching accident or not if there's any storage or any notes or any code the create will fail now um what's not mentioned in the EIP that we realized on the basic team this week is this have positive impacts for vericle trees because when you do a create you're supposed to delete all the storage and that's why we got rid of self-destruct is because enumerating through all of the storage and deleting it is prohibitively expensive in veral and we'd have to either change the rules for create or prohibit grates like this so I think we should just retroactively activate this there's going to be highly

unlikely to n impossible for it to happen on Main net and formalizing this rule will make a lot of client code simpler when it comes to the create process especially in vertical

Guillaume Ballet: uh if I may add some descent in um in the vertical part it's not it's not that self-destructing is impossible in ver is uh is prely ly expensive is just impossible we just don't know which uh storage slots belong to what and that was going to be my question actually uh you also can't figure out if a slot belongs to an account so how do you ex I don't think that will work for veral uh Gary who proposed the the EIP is aware

of that so all I'm saying is if this CIP makes it which I'm fine with it solves a lot of problems on the way uh on the way to verco it will not be able to to work in

veral

Tim Beiko: so what would we have to do when we switch to

rec

Guillaume Ballet: yeah that's the question and that's the the thing that's missing with this uh with the

CIP

Danno Ferrin: oh so they there's no State re kept in vericle anymore that feels taken out of the account

Guillaume Ballet: too sorry I didn't hear or what you say

Danno Ferrin: uh there's a state rout hatch that is kept in the current um account Su that's taken of

verle

Guillaume Ballet: uh yeah I mean you I the problem is that you would be potentially able to access older um I mean you can no longer delete accounts anyway so it's not really a problem but if you were able to recreate accounts you would potentially have there's no account there's no rehash so you would uh you would automatically access the old um the old uh storage like the storage of the contract that had just that has just been deleted

Danno Ferrin: so there's no way to tell if a addess has storage

Guillaume Ballet: exactly that's what that's one of the reasons why uh self-destruct is deactivated

yep

Danno Ferrin: um and also you can't do a triac of storage slots which the um the Dows are really going to love let me tell you that um so maybe when we do the transfer the the uh the translations we put a flag that you know it's it's had storage in the past I mean we need to adjust this for vericle when we do the transition if we see that it has a root hash that does not signify empty stay we put some sort of a flag on there that says you can't create a this address

Dragan Rakita: so why don't why don't we just like removed stores when we transition to the vle we good opportunity where we like to transition from One Tree to

another tree and the hashing is going to be it's like State change that we are doing in some yeah in some way

Danno Ferrin: because that opens Pandora's Box that opens Pandora's box of an irregular State transition which is a larger discussion

Dragan Rakita: but we already doing that with the V transition

but we're not deleting any yeah

Dragan Rakita: but this storage is not accessible because you don't have code for it it's not something that can be used seen or like fetched from the state is just that data

Guillaume Ballet: yeah I think that's a good idea I'm

not sure I understand the denos reason not to not to like that it would be possible for sure although I'm just wondering but we're going to talk about this uh later uh if 5806 does not uh does not uh cause this would not cause a problem with that

Tim Beiko: so I guess I know because yeah yeah sorry yeah just um because we have a lot of VIPs to cover today I think it's it's uh not obvious that we should just go ahead and include this as is like it seems like there's more conversations to be had on it in the the final design so

does it make sense to just continue those conversations over the next couple weeks and discuss this on the on the next call

Danno Ferrin: yes it does uh Peter will be back and be able to answer more the the deeper issues on not Peter Martin

Tim Beiko: yeah

Dragan Rakita: just say I don't have any like um I find for thisy to be included my uh statements were mostly how to how to remove it fully with like verition that we have

Danno Ferrin: well I think without the veral issue it would have been easy for us to just go ahead and do it but because there's vertical implications I think we need two more weeks to mull over what it means

Dragan Rakita: okay makes

sense

Tim Beiko: sweet um and the next step so Peter Davies is not here for 7523 but this one seemed pretty uncontentious last time um there's some tests that have been updated um and then he mentioned on the Discord the only thing we should potentially discuss is if we want to do an independent verification of the deletion of the empty accounts um he checked but it would be nice to have somebody sanity check uh that there actually are uh no more of these accounts before we we sort of finalize this um any thoughts any volunteer car to um yeah run another sanity

check okay um okay if there's no comments um I'll follow up offline then with Peter and we'll try to find somebody else to uh run another check on the chain and publish those results and ideally the script that they use whatnot and um yeah assuming that's all good we can we can finalize that

okay um moving on to Prague so uh there were a couple IPS that uh I added last minute to the agenda because we said we would cover them last time and we didn't um so yeah I think it probably makes sense to briefly go over the five

or six that we had uh for discussion today then hear from client teams how they're thinking about all of this um and see if yeah we can make any decisions about what we want to include um yeah so the first one we had on the list was 5806 which I believe uh Adrien is here to chat about

yes hello uh so thank you for allowing me to discuss it here I think you have wanted me to present it the context being that 3074 is actively being suggested as a candidate in inclusion prag and 5806 is

a potential alternative or at least ANP that would somehow implement the same the same functionality for for a user resp the point of the CIP is to enable EAS to be more expressive in in what they they can do in particular allowing the multicol pattern uh it's been discussed at length I'm not going to go over why multicol is good to have uh but 5806 allows that in a different way than 3074 so there are big differences between these two eips uh and I think uh 5806 which is my proposal has some strength that should be considered uh

one of them in my opinion is the fact that unlike in 3074 where you sign a hash and you rely on a smart contract to tightly associate that hash with an intention uh like bugs can happen at the contract level in 5806 the transaction that is being signed is very explicit about its entire context there is no external factors that that should temper with it I can go into more detail if if you want but I think it's more secure in that regard also about the conselling think it's since it's a normal transaction done by an EA it can be replaced by a du transaction with higher fees and tips so

that it it's being cancelled so I think the model is is better here in the predictability of how it's going to be executed uh then 5806 also has a lot of of things that it enables in terms of what I use a e way uh can do in the sense that it may allow it to access op codes like log to emit an event or create two to create a smart contract in a very predictable way uh the question then is about uh longlasting uh changes like storage uh for a long time I was an advocate of storage being being useful in that context like you could store something

under your account that would stay there and be provable I understand that this can create challenges and and security issues if anip proposed to put code at an EA address uh because using this uh 5806 you have the ability to put code before creating the contract and that might hide things so I'm completely open to the idea of preventing s store to being executed in the context of Ana through 5806 I I'm not exactly sure what I should say more

Tim Beiko: yeah this is a good yeah this is a good overview definitely uh yeah if

there are questions it's uh we're going over them now there's a comment uh in the chat um by like client but okay Andrew has his hand up so let's s with that

Andrew Ashikhmin: yeah I think if we disable sore um then this keep sounds like a good simple um improve and like it will be reasonably simple to implement and it will bring a non-trivial ux Improvement like one in one of the our previous course we discussed badge transactions so still our batch transactions yeah so I think we should have it in in frog but with the sore

disabled

Tim Beiko: so meaning you disable sore you disable transaction types those transaction types to use

sore

Andrew Ashikhmin: uh exactly yes

okay yeah I'm having a look at the at the comment from client on the chat and I I completely agree with with point two and three uh 5806 doesn't try to do social recovery uh and I think that's partly because the signatures are are it's like a transaction like if it it's supposed to be Min straight away and if you keep a assigned transaction for a while and you do all stuff with the same

Nots it's becom invalid so it's not something you can store for social recovery uh also it doesn't allow bundling transaction from different users uh and basically impersonating multiple EAS in the same transaction so that's something that 3074 does that that 5806 doesn't do uh because the signature pattern is different and because signature of 5806 are way shorter LIF than 3074 which I believe goes into sense of security here but yes it's different approaches

Tim Beiko: okay any other comments

questions

oh G

Guillaume Ballet: uh yes that's in the light of the discussion we had about the retroactivity IP so I understand that uh yeah you would very unlikely you would be very unlikely to call it if your nons and balance are zero but assume you just have the key to an account that does not exist yet so you you generate your private key the account the associated account does not exist yet on the on the chain and you sign a transaction that sends uh that calls a contract the delegates call to a delegate calls to a contract um my question is have you thought how it would fail because

clearly it doesn't have any fund so it would very quickly go out of gas I mean it would immediately go out of gas but my my question is more like what um what State Should Be Touched in that case and yeah the question is for veral trees and the in the cont how do you make it work in the context of veral trees and and how and also in the the EIP that that Gary was working on

uh I'm not sure I really understand the question I mean if the the sender has no gas uh it the the type of the transaction here is is in my opinion irrelevant part of of my of of the ver

of the verification of a transaction is that the account has enough funds to to pay for the amount of gas required multiply by however it cost you for each unit of gas and if you don't have enough like type two transaction and type zero transaction will fail and this type of transaction will fail the same

Guillaume Ballet: it's not about the type of transaction it's how it fails

but um would it be a revert or would it be a an out of Gess uh it would be I've not thought of that I think it would be the same as what happened with other typ of interaction

Guillaume Ballet: yeah okay yeah no just uh just asking if you had thought of that I I would have to consider that uh but

yeah it's probably it's probably fine

what I was thinking was that everything that is part of the verification of the transaction including the the signature and the encoding except for for the value part would be handled similarly so any any revert condition that exist for type two transaction would just be dealt similarly here

Guillaume Ballet: yeah I mean just maybe because my question wasn't very clear but if you try to access a contract um that should be deleted under those new rules you know um what what should happen and should it be different than uh than what we do but okay it's just it's just me thinking out loud here um

yeah I'll come back to it if uh if it turns out to to be problematic

Tim Beiko: okay any more questions comments on this one um otherwise we can move on to you the next

CP okay

okay thank you for having me and feel free to ping me if you have any questions

Tim Beiko: sounds great and thank you for coming on

okay so next one is 7557 uh which uh yoav was also asking to discuss so uh this is for Block Level

warming I don't know I don't think y have is on the call but I don't know if there's another oh you are yes no no I am

Yoav Weiss: I am here but Alex but Alex is also here and and going to present it

Tim Beiko: um Alex please yeah

Alex Forshtat: hello everybody uh can you hear me

Tim Beiko: yes

Alex Forshtat: uh yeah great so I'll try to give a like brief overview of what we are proposing here so uh in EAP 2929 and 2930 edited concept of war and cold storage and accessing a cold storage was made obviously way more expensive than the cold the warm one however this

distinction is only made on a transaction level and like if you look at the terms of the block the same storage may be accessed by each transaction in a block and it becomes cold access for every transaction which is not exactly the case because uh the block Builder only needs to uh look up this data uh once and can reuse this data so uh while we have uh a concept of access list which is an information about which slots might be used in a transaction uh that is available outside of transaction execution just as part of a transaction payload so what uh we are proposing here is uh after the finalizing the block when when feeling

it basically to iterate over the access access list and build um a table of how to redistribute the cost of accessing the C sech uh between the transactions that actually access the same storage uh or the same uh addresses uh and uh to issue a refund in a way uh that is U similar to maybe Bon chain withdrawal like a system operation they just inject value to to the code uh after the block not in the scope of a transaction uh mostly because otherwise um doing it as a refund is not really feasible because

like then you give like there is a retroactive effect of uh of the last transaction can has an effect on the first transaction uh so that's that's a high level view uh like it's quite simple with a base fee because uh it's just the same across all transactions it gets a little more tricky with priority fee because like each transaction can pay different uh priority fee so we what we are proposing here is a like proportional uh distribution of the priority feedback according to the like marginal contribution of each transaction to to the amount that is

being refunded uh like uh it's similar but not same to uh chly values uh that are like used to define such things and uh yeah that it so yeah it it's uh especially like not especially but more important in the context of uh ERC 4337 and maybe like an AP 7560 that we are working on that will make it native account abstraction where many transactions are very likely to access the same slots uh within the block and also like reference to uh like there is veral 3 EAP that

is suggesting that accessing uh contract code will also be be priced in and in this case such an EAP uh would also be useful because we expect that many uh transactions will use the same like wallet implementation uh in the same entry point uh and it would be beneficial to uh just share this cost among the transaction instead of like each one paying full unjust price for it um y you like to add anything

Yoav Weiss: um yes so basically basically the idea is to make it uh first of all to make to make the pricing Fair because

to make the pricing Fair because the the validator only pays once for a reading from the database and then it's already already warm so it makes sense from from F fance perspective but also for commonly used for any commonly used contract mean account obstruction is one example but there are many examples of contracts that are used many times during the same block so um including including them in the including in the exess list of multiple transactions and sharing the cost I think makes a lot of sense as for concerns that I've seen in the chat about parallelization uh this EIP does not affect evm execution in any way because it's not visible the uh the change of

pricing is not even visible to the uh uh to the individual transaction instead uh since we calculate it at the end of the block we calculate the calculate and do a refund at the end of the block similarly to how consensus layer withdrawals show up in accounts uh it should not affect at least I don't see how it should affect things like evm parallelization

Tim Beiko: thanks uh Andrew

um I

Andrew Ashikhmin: I haven't looked into this EIP in detail but on the surface of it it sounds like a bad idea because it's again it's like we will will be spending time a lot on tweaking the gas instead

of making fundamental improvements to either ux evm or whatnot uh and uh as to badge transactions we should address it properly like with a mechanism to allow badge transactions rather than trying to twak uh multiple transactions in the block to work as as as a batched transaction I didn't quite understand the part about B uh it's not about a b transaction in this case um but I think one of the motivations that you mentioned is that you you exactly badge transactions or maybe I Mis

misunderstood

Yoav Weiss: now B we talked about it in the about the previous EAP about about 5806 uh this was the Bing transaction uh for this one we're talking about uh we're talking about sharing the cost the cost of cold of cold access to accounts and storage slots across multiple that use them so

Andrew Ashikhmin: but essentially you those multiple transactions they because they they will be you there is a need for M transactions because you cannot batch them that's what what will one of the use cases if you could batch them you don't

need uh this uh this tweak that much

Yoav Weiss: if you could batch them I mean they transactions for multiple users they just happen let's say in the most common use case would be proxies you have many proxies that use the same implementation so it doesn't make sense that each in each transaction accessing the implementation is the called access because it was already loaded once so these are not so these are not going to be in a batch because they are unrelated they just happen to use to be accessing the same contract at some point

it it's I well okay maybe

Andrew Ashikhmin: maybe that that's

right but another thing is that now transaction pricing depends on the other transactions like depends even more on the other transactions included into the block um and it complicates uh gas estimations it complicates transaction pricing complicates a lot of calculations but doesn't help us to SK the evm doesn't help us to scale the through I guess yeah and one question I had is do you have a feeling for like how much gas is wasted here like what's the assuming we went ahead and did this like what's the amount of transaction

fees that you you imagine we could distribute back to users

Yoav Weiss: so yeah we didn't run we we didn't run a simulation to see how much it happens block but I did look at some at some blocks and uh see some contracts some contracts are accessed dozens or sometimes even hundreds of times so uh it's um I take for example Unis swap suppose you have I mean yeah in the in the Unis swap case it's probably going to save users a lot of gas and I agree that during estimation you will not be able to know it so you're going to overestimate you're going to assume that it's called acccess but uh at the end of

the block there's a refund so so I assume that in blocks that have a lot of Unis swap trade there's going to be significant gas saving for users

Tim Beiko: yeah I guess it it would be useful to see numbers because like first there's like the breakdown between the base fee and the tip second there's like yeah how what's like the median like how much overlap is there in the median Block versus like say the max block um and I can imagine you would save more in cases like say there's like some new nft that drops or some new like pool on unisoft it's like in the cases where the priority fees surge you'd probably save more but is that like yeah if you if you if you put this like relative to all the

transaction fees paid what percentage or amount does it represent I think would be useful to know like is is this worth the complexity basically right yeah that's I think it's a good idea to run some simulations and but also I think that some use cases will become more possible once once we do it so we may actually see patterns like usage patterns changing a bit but we can't know that for sure so for now we should only measure what we can uh what we can on the current blocks and I think that one one another thing that we need to keep in mind is what happens after veral because in veral there's going to be a there's going to be an increase in the

cost of running contracts because when you load contract you're going to pay for the code loading per chunk so uh now it's not I know it's not finalized yet we don't know exactly how the cost is going to be calculated but it will become more expensive to load uh uh to load contracts and there if you can uh and then if you can uh split the cost of loading the of loading the contract it could be significant saving got it yeah that might be also an interesting to run like if we you know if it's a smaller part of transaction fees now but then it grows a ton after veral and that's yeah that's really

useful to know um Gom you have your hand up then Lucas

yeah

Guillaume Ballet: speaking of verle um I mean I don't really have any comments on the Merit on the intrinsic merits of this of this EIP but what I can uh say this is the typical thing I would like to see after veral not before uh precisely because the gas model is already quite complex as it as it is and this is going to make things even more complex um it's nice to it might be nice to have although we have very specific model where every transactions precisely pays the cost of warming their their state up so that would go against what has been specified and what we are used to we'

we've been working with for for like uh three years now um I don't think we should even consider that for for prag or Osaka it should really come afterwards and yeah it would make it would make verle way more complicated than it needs to be already

Yoav Weiss: if if it makes verle more complicated and I uh and I we don't want to make a I I didn't think it's going to affect to affect the calculation for veral itself if it does then it takes a second priority of course

Guillaume Ballet: uh I mean I'm I'm also happy to change my mind but this is exactly what I said for eof last time I would like to see a demo of this happening on

on the veral test net

first um Lucas uh so to First me

Łukasz Rozmej: let me ask one question to summarize it up so it works um the transaction Deion Works uh as usual and then at the end you look at the access list and potentially just add some uh cost back to some some uh to some sender addresses that correct that how it works or I missed something

Yoav Weiss: uh yes yeah you can see the EIP there is a pseudo code of of how it is handled so you can see exactly how we how we propos to do it now of course we don't know maybe there's a maybe there could even be a better calculation but the general

idea is that yes you collect first of all you only split the cost you don't look at actual evm execution because that would complicate things so instead only transactions that uh that have the slot or the contract in their exess list H get get to share the costs if a transaction doesn't have it in the access list it's going to pay full price for a warming and and then you split the cost across all of like if you if you had 10 transactions accessing the same having the same slot in their access list then you split the cost proportionally proportionally across these transactions proportional to the priority fee and this happens at the end of the block only once

Łukasz Rozmej: and second

question would that complicate things for Block Builders because uh they kind of continuously can improve the block for example revert one transaction at another right uh at the end or something like that would that complicate this kind of uh strategy for Block building or generally building code

Yoav Weiss: so since since the calculation only happens at the end of the block after you finished kind after you finished with the block uh it shouldn't I mean you can you can keep changing transactions and applying any strategy before you do this calculation and uh we and also in order to keep it fair for the you order to

keep it fair for the Builder for the block proposer uh we also didn't want didn't want to create a situation where if you add another transaction you actually end up making less money because uh because of this split cost so the cost uh so the cost to everyone is actually the it's a derived from the from the cost of the of the highest priority fee so the Builder is going to get H to get paid uh getting ACC according to the highest uh to the to the highest priority fee so so hopefully it's not going to break the strategy for any block Builders but that's of course we need some input from h broke me

just

voice

Tim Beiko: okay let's do one last comment and then we'll move on

danrad

Dankrad Feist: um yeah like I mean okay I'm not sure how it works but it feels like it could actually Break Stuff if um yeah if you like have to run something at the end of the block to know how much gas exactly was paid and how much fees you get but I haven't looked at the details but like more generally I was wondering why why not like uh like why like it seems to be over engineered in terms of like trying to refund it to everyone why not like just do it so that the first transaction does pay pay the full warming fee and then the other uh transaction is just like get it cheaper and get the warmed up

slots like yes it doesn't seem as Fair um as a bit of a lottery but um it feels much more predictable and much less complex to implement and it's still like on on average you pay the same amount

Yoav Weiss: so first of all since since the refund is not a transaction it's a more like a consensus layer withdraw there is no execution at the end of the there's no execution at the end of the block you just collect the numbers and then you divide it in the end and do the refund but uh as for um what was your other uh so your other comment

Dankrad Feist: well I was wondering why like

okay like here's about fairness about fairness yes simply just like uh considering all the all the slots that have been used by previous transaction as warmed up so then it's exactly predictable what happens at the start of each transaction execution and you don't have to do anything complicated at the end of the Block it's less fair but on average it gives you the same result right

I

Yoav Weiss: yeah it gives the same result except that like you said it's a it's a lottery

it's a it's a lottery where the

Tim Beiko: first it's not an a Trey because in practice if there's like contentious access or like in demand access for some some part like it's maybe because there's like some Arbitrage or some like profitability so I think it would be

interesting to look at that but I feel like for a lot of those you would just see it's like you're taking away from the Mev profits if you're taking it from the first transaction in the block which might be fine

Yoav Weiss: um yeah of course it's yeah in these cases like in in the cases of when there is m contention around some slot it makes perfect sense that the first one that also pays the highest priority is also going to pay for the warming that's fine but in the case of a proxy implementations for example let's say in the in the account obstruction case where you have many users many users using a wallet with the same implementation um it's May it may be less fair that one user uh one user pays for warming for all the other users so

it's uh we could do it this way does simplify things it also makes things a bit less predictable for users

Dankrad Feist: right and I think like that makes a big difference whether that's like there a 200% variation then I see your point but if it's like say a 20 30% extra cost for transaction then it feels over engineered to me

okay uh Lucas

Łukasz Rozmej: uh so I think this is actually uh the current proposition is simpler to implement and simpler to uh parallelize because uh it doesn't depend on the uh full block uh order it just at the end uh turns some funds to

uh to the transactions based on the access list if I understood correctly so what proping okay uh it is actually a complicating parallelization for example a lot and because you and you have to track the access uh patterns across the whole block in order which you don't have to with this proposal so it's actually in my opinion uh easier to implement and easier to to paraliz in future

Tim Beiko: all right thanks sweet um thank you you okay next upep uh I guess yeah Danny you had your hand up but then took it

down was there still anything on this

oh

Danny Ryan: I just was going to mention that like a it the asymmetric strategy where the person one pays for it like a builder could pick a user transaction to warm something up and have somebody pay for it and then insert their transactions to use the warm but again like if we're talking about marginal differences I don't think that that strategy matters too much uh but I think the paralyzation and asymmetry comment previously is important

Tim Beiko: got it thanks okay next

so just um sorry one very quick uh note that um if we introduce anything where

basically execution of the or the cost of a transaction depends on transaction before it another issue that you might introduce is gas estimation issues because all of a sudden if your gas estimation runs in a certain context and you during a block execution you change the context you might end up with uh basically fail transactions

Yoav Weiss: uh that couldn't happen if you only do the refund at the end of the Block it's because you you have to assume that you're going to pay the full warming price and then if you are if you are not alone and others also share the cost at the end of the block you get some you get something back but it cannot cause the execution to fail because uh during execution you're not

even exposed to this information

Danny Ryan: yeah I think that was an argument against the asymmetric version that dun could proposed

Yoav Weiss: oh yeah I understand okay

I I

I'm not necessarily saying it as an argument against either version rather it's um what I'm kind of saying is that uh this kind of means that during gas estimation So currently what the gas estimators do is that basically you have this um previous state which is either the latest block or the currently pending block which whatever it means for a client and then people just run estimate gas transactions on top and uh that might get wonky

so basically just the only thing I'm seeing is that gas estimation needs to take care that it's uh estimating on top of a clean slate and not this partial warmed up thing

Yoav Weiss: oh yeah in during estimation you should you should not assume anything about this it's uh it's like maybe you'll get something back maybe you wanton but you have to assume that you're going to pay full price during estimation otherwise stuff is going to break

yeah of course but the point is that the gas estimator is just a dumb thing which takes a a transaction runs it against um a pending block or a pending State and just spits out the gas value it doesn't know anything about uh anything and um so basically what So

currently the gas estimator is kind of dumb and such a feature would require the gas estimation to be a tiny bit smarter so as to um basically know that know about this refund mechanism and make sure that it doesn't interfere

Yoav Weiss: actually I wouldn't want to know to know about it

Tim Beiko: I'm sorry yeah yeah I think um yeah I think there's clearly like more discussion to be had on this if we went forward with it but uh we do have a bunch of other eips so I would table this for now move to the rest um yeah sorry to cat you up but uh I want to make sure we can cover most of stuff um yeah thanks y for for sharing this

next up uh we had uh 23.95 or 20 29:35 sorry I had a typo in the agenda

um so this is uh the veral related one I don't know G do you want to give a background on this yeah I

Guillaume Ballet: I even have a tiny presentation uh it's I promise I'll keep it short um can you guys see my screen

Tim Beiko: yes

Guillaume Ballet: okay cool yeah so we have this uh EIP that was initially created by tomash and vitalic uh which is about storing the the contract sorry the the historical block hashes into a contract or the contract storage more more exactly um and it's been stagnant for a while um looks like a can't change yeah it's been

stagnant or stalled for for a while um and we discovered while uh working on the on the veral test net that we actually needed this for uh for um well for stateless clients to execute and the reason for this is because uh you would need to somehow pass the historical block hashes and um either you pass it on a side channel uh but they they sort of need I mean they definitely need to be part of the proof uh and we do have a way to to provide uh we we know how to do proofs so it looks like the perfect the perfect EIP just needs to be updated so we created this revival PR uh to like

8166 uh which is to yeah just meant to to update it because it's it's quite old um we it used to be a like block number based we now it's a Time stem based and there were some fairly complicated things I mean things that were not necessarily complicated at the time but now that Forks are uh time stamp based it got very complicated so the the gist of the of the update is really to say once the the EIP is activated uh you just take the 256 ancestors and you insert them right off the bat into this contract uh which is really simpler than uh than the proposed uh version until

now I mean once again it was meant for a different Fork model and uh you no longer like the other major change is that uh in the in the initial description you had to wait 256 blocks after the fork to to be able to use the contract now with this new approach because we insert all the historical uh block hashes that we need we don't need to we don't need to uh to wait so you can start using them right off the bat uh what doesn't change and this is something think that is uh that is going to probably create some push back but let me explain why it doesn't change um unlike the the beacon hash contract the

4788 contract we don't want to use a ring buffer and in fact the argument is that we might actually also have to give up on the ring buffer for 4788 um we are still gathering information but the the reason behind this is because well okay first uh this whole EIP was created to be able to access historical block hashes and so that would be really hijacking the CIP if we did not provide that and uh the other reason is because hashing in a veral context is way more expensive and takes way more time than it does in a kak or Kack context and uh so we feel that an

attacker could potentially increase the depth uh of that ring buffer in the tree and therefore uh for relatively cheap make uh make block production um slower um in the future so this still needs to be confirmed I we're working on getting data to confirm if this is a problem or not but until we have not confirmed this is not a problem I think not using a ring buffer is actually the the best uh approach because then it will move in the tree and so it will make the attack more expensive um we also considered putting all of the data uh during the the vertical transition but we uh decided so I mean

all the historical hashes during the vertical transition but I think it's uh it's not really useful unless there's a there's a clear use case for that and we also didn't want to do any uh solidity implementation so it's just at the beginning of the block writing the contract that's what's specified in the initial version of the EIP and we we want to keep keep it this way um yeah there's a couple discussion points what address should we use Cu uh yeah like for example uh I mean we don't want necessarily to use the one that's currently specified in the AIP uh EIP 158 currently deletes every contract that has a zero nons and zero balance so

we in our implementation we had to to create an exception and yes uh current ly it's deployed the first time it's being accessed but we we could uh we could change that if people disagree uh just want to point out that it has actually been tested uh it's currently uh tested it's uh the bar uh prevents me from uh uh from showing the other tab um here we are so if you look at kelen so this is the block Explorer for kelen and you have a St that tells you what what gets touched and if you look at the first slot use I mean okay if if you're not

really uh familiar with veral most of those uh numbers will not talk to you but basically this is this is the location of the first uh slot in the in the contract the suffix is 64 that's normal um I mean once again if you don't know veral you don't care about this number and what you can see is the new value is some hash and that happens to be the the Genesis hash which is um right here yeah exactly so um yeah so just to just to point out that that it's working um and yeah why would you consider that in prag well okay the first uh the first argument that it's easy to do it's already implemented it's

being tested it's uh necessary for veral and because I was explaining um the the trick of inserting 2 six ancestors at the fork Block it's not conceptually very hard but this is something I would like to avoid doing when the transition starts so that would be the reason why we would be pushing for this in Prague and yeah that's pretty much it

Tim Beiko: thank you um Danny has his hands up

hand up yeah um yeah

Danny Ryan: I definitely support this I would be curious to hear a bit more about the ring buffer argument maybe later after you done some analysis

um but I just want to point out on the consensus layer this we've had the design principle since a zero that the state transition be should be a function of pre-state um and block and no other explicit or hidden inputs um and so I'm I'm a major fan of the execution layer moving in that direction for the statelessness reasons but I also want to just elevate it as a design principle in general and when people are designing eips to think in that mod because I've seen I've seen EIP drafts where you know they'll assume access to some maybe the parent block uh or something like that but anytime that we we want to do that kind of thing we should be writing it into the state um to elevate it into this kind of stateless mode so just a

just a comment and definitely support it

thanks any other questions comments D

Danno Ferrin: yeah I'm still wondering how using a ring buffer introduces new attacks scenarios that storing everything in history supports um 4788 works it's out there you can't change the numbers um it's not going to get any larger than storing all of the history and it has a process that is already established and work we just change it with a different contract address and a different value we put in so I'm I'm wondering why why that simpler solution is not um preferable

Guillaume Ballet: uh so yeah the the right now it's working that's precisely the thing

because the hashing you use is uh is K well sha 3 based and um currently you don't see the problem but as soon as you switch to veral it's not uh it's it might like I said we need to to get more data we're working on it we'll get them as soon as possible but if it's confirmed that uh greatly improve increasing the tree depth is going to be a potential attack your ring buffer will uh and I'm talking about the one in 47 and 8 will be attacked now what do you need to do if you want to change it you have to um you have to

Danny Ryan: can you define attack like like is this an if you manipulate the beacon block Roots then

you can change the depth of the rain

Guillaume Ballet: yeah no you just need to create a contract because everything ends up in the same tree uh all you need to do is to find a account to slot whatever that will have that will hash to a same prefix uh as the as the the stem or the the PA to the ring buffer in the tree and as soon as you get that you can artificially increase the depth of uh of this ring buffer which means you will need to compute more levels of uh of um commitments and that means uh it might potentially make things really uh much longer to compute

Danny Ryan: and how is this

different than than targeting High use contract obviously this is system level and it must be it's going to be updated every time in hash but but why is that different than something that just has very high usage

Guillaume Ballet: exactly it's not very different from any High usage contract in fact Peter pointed out that you could do the same thing on a Gateway contract for example uh but the system contract is like this system contract is executed on every single block so you could do this and attack uh for example a competing app and they would have to redeploy and everything Dano talked about um so that's a pain but if you start attacking the system contract uh

you would have to do a new Fork to fix it and that's uh that's a bit more involved so that's why we would like to to avoid that and as it turns out

Danny Ryan: yeah if Unis swap is attacked like this does the cost of executing Unis swap become more expensive or is so cost in terms of gas or just cost so so they have no incentive to to like re to move it similar right

Guillaume Ballet: it's just in terms yeah that's true uniscope itself doesn't have to has no incentive to move it but uh people that uh client developers that see the the time frame getting closer and closer to the Limit the the block production production time getting

closer and closer to the Limit we'll have an incentive to change that

Danny Ryan: and what but they have no control over that

Guillaume Ballet: uh they have no control over that no

Danny Ryan: so they have more control over the system level contract probably than attacking the application there okay yeah I'm still wrapping my head around it

thank

Guillaume Ballet: sure and but what I was getting at is if you get rid of the Ring buffer you will automatically move uh those uh this target all over the tree so it makes uh it very expensive to to attack because you really have 256 blocks to find the uh a a um collision and then it's only it's only effective for 256 blocks and

then you move to another part of the tree where um where you have to start over so it's it's way more expensive

Danny Ryan: um the cost of Len State growth on the system contract right

Guillaume Ballet: yes absolutely

Danny Ryan: got it thank you

okay like time

Lightclient: I mean I'm just kind of echoing what Danny said I don't really see why this is a specific problem for the system contracts I think this is also a huge problem if it significantly is affecting block production time for any kind of dap I don't think it's reasonable to expect daps to go into some PVP battle where they're expanding State um State branches around the contract and then forcing others to

redeploy

Danny Ryan: sure but especially if the gas cost doesn't escalate

Tim Beiko: but also some apps just like can't and shouldn't redeploy right

Danny Ryan: yeah I'm not I'm not saying they should but they don't even have an incentive to because it's not going to even show up in their gas

Tim Beiko: yeah or I mean you know we have the deposit contract as well like yeah there's plenty of contracts that get used in yeah um Andrew

Andrew Ashikhmin: um yeah well of course we have to figure out whether to to include the ring buffer or not but in general I support inclusion of this dip into Prague it makes sense yeah do before

V uh yeah

Peter yeah

so just circling slightly back to the to this attack Vector basically my concern was kind of the same that uh um whether we use a ring buffer here or a um non- ring buffer I kind of feel that if uh if the attack is viable on the ring buffer then we will have bigger problems because I can basically Target any high profile proxy contract and make it super expensive and um if basically targeting Unis swap is uh so my kind of my point is that if the attack works then uh both attacks will be very potent and if it doesn't work then uh uh then it doesn't really matter then we can just keep the ring buffer so

I um that's why I was kind of suggesting that we should really have a a number on um on how effective or non-effective this attack is because I kind of feel it uh you cannot make an attack ineffective on Unis swap but effective on the ring buffer so it's going to be both or none and we should really keep this um this I mean I really like the ring buffer approaching that the state is kind of constant I really like constant stuff so changing it to a non- ring buffer would really need some some motivation and I think the problem is that the motivation that would prompt the ring buffer to be swapped out would also be a huge problem

for the D ecosystem in general so it's uh I think that issue is a bit deeper than just the changing a the data structure here

Guillaume Ballet: uh just to be clear I mean I agree with most of what you said but we're not changing the like DS change like switching from a ring buffer to something else should be completely um transparent to dep because they would just ask for their block number and they would uh they don't care where it's stored they just want their block number so it's really how the storage is laid out that the changes

yeah of course but my point is that uh if the ring buffer needs a change because otherwise it can be attacked then so can Unis swaps uh

proxies contract and any proxy contract and you cannot really I mean with upgradable contracts you can redeploy the implementation itself but uh you still have one proxy which is kind of your entry pointer into the system and that's the thing that you can attack and you can't deploy that unless you actually change the contract address of unit Swap and I mean that's that's going to be a huge pain nobody's going to do that so my my point really is that if this attack is realistic then we have to rethink big things if it's not realistic then the ring buffer is not relevant

thanks Peter um Denny

Danny Ryan: yeah I was say very much agreed uh with Peter like this is either fundamental and affects both or not um either so I I would say you know if there's a write up if there's numbers on like us being able to wrap her head around this attack in general system contract aside um it seems like very important to to the vertical conversation um you know rather than it more in the abstract I think Anar said you know potentially doing simulations where we mining maximally adversarial um depths might be important but it just seems it seems we need elevate it to a fundamental concern rather than like a system contract concern but I think

we're many of us are saying the same thing this

Tim Beiko: got it thanks yeah I think this is probably a good place to wrap this one up um given we still have a couple more eips to cover um but yeah thanks G for sharing in I think it was a useful discussion

um okay so next up we have two eips which we were going to discussed last call and and didn't have time for uh so Charles is on to discuss them first is the pay op code and then the second is a transient storage reduction um yeah Charles are you on the call yes yes hey hey I'm Charles um I work on

viper um I want to advocate for the pay op codee um which was considered uh last time for um Cancun but it was um deferred uh because of complexity um but basically just to give a a quick gist of it it's um a way to transfer ether without transfering calling context and I think this is just generally important because is um um sending ether shouldn't have to transfer the

call in contact because the the call the called contract can like do whatever it wants um one of these things that it can do is um of course re-entrance the attacks and um it's just a huge foot gun for for users in general and if we have a payoff code then an entire class of um smart contract vulnerabilities can be mitigated um I think one um issue kind of that's been brought up is that you can do the same thing by um creating a contract and then self-destructing it um but first of all it's like a kind of a a hack and second

of all we know that the semantics of self-destruct are kind of in flux so I don't want I don't think that users should have to depend on the semantics of self-destruct to do a specific thing and in fact people relying on this behavior um forces us to kind of make it forces self-destruct to actually be a little bit brittle in that it can't be changed as much um so yeah that's the the overview and the motivation for it um I can go over my second other thep let's maybe yeah

Tim Beiko: let's maybe just get the questions or comments on uh pay and then we can do the other one

just so uh yeah we can keep them separate um so yeah any thoughts comments on uh 5920

Andrew Ashikhmin: yeah I think it's a simple e and it's a nonrival Improvement for the ux so we should include it

Tim Beiko: thanks any other thought comments okay if there's not uh yeah we I think we'll we'll punt the discussions of like what we actually include a bit later and maybe next call based on how it's going so far but um yeah we can go over the second

EIP

Charles Cooper: okay cool uh the second EIP is um it's still a draft um uh which I just threw up recently because I realized that um we're discussing prog already um and basically uh the the the core motivation is also kind of Reen related um but basically transient storage in my opinion is overpriced and um the the reason it was priced the way it was um and it's of course too late to change for Cancun but the reason it was priced that way is first of all it's like kind of conceptu the same as warm storage sorry it's not the same it's

conceptually similar to warm storage um but there's important differences and um also there's some discussion of Dos so um you don't want people to be able to allocate too much memory on a client and I think in EIP 1153 there was some discussion and calculation of like how many slots you can allocate given that pricing um so I think it's fundamentally over price because it just um doesn't require as much resources as as warm storage and let's

see my notes yeah it doesn't interact with refunds and it doesn't interact with the physical database um you don't need a new allocation every call you only need an allocation when you touch a contract for the first time I also did some benchmarking with Revan and it seems to be just um compared to other you know relatively speaking it should be about 10 times cheaper to address the issue with allocating too many slots um I added um this kind of super linear component so that every time you

allocate a new Transit storage slot you pay an increasing amount so if you want to allocate like 100 Keys then you need to pay you know three gas for the first key um six gas for the second and so on until you're paying 300 gas for the final key and I think for most use cases um this decreases the cost of Transit storage for users um interestingly it actually decreases the amount the total amount of Transit storage you can use which I think is um good for clients because you know they have like stronger caps on how much

memory you can allocate um and I have the calculations and all this stuff and benchmarks in the in the EIP and the E magician so so I think we can open for questions

Tim Beiko: yeah thanks uh Andrew

Andrew Ashikhmin: uh well you know my position is against weaking the gas schedule unless absolutely necessary because my mind we have much bigger fish to fry uh we we need to somehow tackle the scalability issues because if we don't it's we can like have a super precise work and and

guess shle cannot be super precise because you have different client implementations but even if it's more accurate than what we have now it still doesn't help us much because it doesn't help with this with total throughput unless so yeah we should focus on actually improving the total throughput rather than tweaking the gas schedule all the time

Charles Cooper: um I don't think it's exactly a tweak I mean it kind of is like uh quote unquote micro optimization but I think it's a fairly easy to change to implement and it allows um compilers to and users to implement Global re-entrancy walks so re re-entrancy can be um mitigated by default instead of

people having to opt into it depending on if it's cheap enough um and I think 2024 you know we have the capability to prevent it um and you know make the evm modern I I think it's um uh in easy and fairly inexpensive win

Tim Beiko: okay any other questions comments on this one if not um Mike uh you wanted to talk about inclusion list right

can I just quickly add a very very short comment so

um I was I kind of also agree that it's a micro optimization and we shouldn't really go very very deeply uh on one hand on the other hand I think it's uh if these micro optimizations are simple enough then uh I mean if it takes um 5 minutes to implement or 10 minutes okay I'm being uh deliberately very extreme here then uh even if it's a micro optimization I don't think we should necessarily say no because we have bigger fish suppi I mean sure if it's an a big enough effort then yes but if it's very very trivial then I think it's it could be a valid consideration now the catch on the other

side is that uh basically the the suggestion I mean making transient storage cheaper all together I mean that's super easy to implement now making the the cost steered as to how many slots you allocate that gets a bit uh I think you enter into this territory where it gets a bit wonky because okay uh you say that the compiler could generate uh uh these re-entrancy locks super cheap yeah but if I call a big enough stack of contracts then already I'm going into this okay every every subsequent T store or or slot gets a bit more expensive and then if I have a deep enough uh stack of contracts then

this thing gets starts to get expensive and it starts it's uh kind of harder to reason about so uh I don't want to challenge this specific design because I haven't studied it so please don't take it as a specific attack on this design rather I think uh basically if this EIP can keep the modifications needed and the mental model needed simple and it I think it's perfectly fine to include in some form but the more complex uh gas mechanisms it includes the the harder it is to rationalize the optimization

Charles Cooper: yeah um and in the EIP I did do the calculation for like how much memory you can allocate um if you do T

store on a single contract versus like if you do this wonky nested thing and you try to like optim as an attacker you try to optimize how much storage you can allocate um another suggest and and I'm quite open to feedback on on the design U but I just would like to see it in some form being included um something that decreases the base cost for Trent storage um another suggestion um was to just keep the the the gas price flat and then just introduce a harm limit on how many slots can be allocated and maybe um I'm not a client developer so maybe for clients that's easier to implement I don't know um again I'm open to feedback

so I would probably say that

introducing a a hard cap would be uh very very problematic it's kind of like U with the hard cap on the stack limit that it's just uh very annoying when solidity tells you that okay some stack limit exceeded or something so a ideally you want to avoid these hard limits so I think uh raising the price is uh infinitely more preferable than just throwing or basically aborting execution because you reach some arbitrary limit

Charles Cooper: okay thanks Peter

Tim Beiko: um yeah thanks Charles for presenting the two eips um I'll move us

on the inclusion list because I want to make sure we can cover it um Mike do you want to give some context uh and then share the info on the breakout tomorrow

Mike Neuder: yeah thanks Tim and hey everyone um yeah I guess I probably only need like a minute here and all all I wanted to call out was kind of two documents I guess um the first being this is speec overview this is kind of taking the some of these unconditional design properties that that I mentioned two weeks ago and and trying to put it into the spec for the consensus um execution apis and the the E spec the eel spec um so yeah I guess the only other

thing to mention is the is the call that Tim brought up so you know this is scheduled for tomorrow at the same time as the beginning of the um of the allore devs I think there'll be kind of both U consensus teams and some execution layer teams there so if you're curious and kind of like want to want to know more I'll probably start by just running through the the spec do and then happy to to kind of take questions and and brainstorm and think through what what might make sense so yeah I think that's all I'd like to share um thanks Tim for floor

Tim Beiko: thank you um any question

questions comments in advance of the inclusion risk okay so we can chat about this tomorrow um we only have five minutes left and we've discussed a ton of eips today and so I think what might make sense in terms of next steps is um to not try and like figure out what we include in Prague today but give teams like the next two weeks to think through um and then maybe two specific things uh are one we had CFI 2537 last time and uh we moved all the

other eips to included once the CL devs plus one them but uh 2537 is the only one that didn't require any CL help so anybody object moving it to inclusion so that we can clearly have it part of the the fork

Danno Ferrin: I think it should be in I think we just need to revisit gas costing on it but other than that I think it's a good

ad

Tim Beiko: okay last call for objections okay and then the other thing I would propose so we discussed uh 5806 today and then 3074 and I know that in the past we talked about uh wanting to

do something around just like better account ux but uh not really being your line on like the strategy or um like if we do a single e how does it fit in like the broader account abstraction road map so would it make sense to have a sort of account abstraction eoa upgrade management breakout room in the next two weeks before uh the next acde so that um we can discuss that in more depth maybe have some wallet devs and some application devs joined um so that you know if we do want to do something whether it's like 3074 or 5806 or whatever like um at least we've we've sort of gone down that um that rabbit

hole a bit more um yeah any interest for that sometime in the next two weeks okay so there's some plus ones um I'll yeah um I'll 10 okay I I'll I'll I'll propose the time after this call because I I want to make sure we can at least ping a couple wallet devs and and uh other folks to see like when they can attend um but we should have this like before the next acde and uh ideally probably sometime next week so that like there's uh basically a week between when we have

this AA breakout and um when we have to make the final decisions um yeah anything else people would like to discuss before we wrap up

uh yes yeah uh basically just a very short note I'm not sure whether the de already mentioned this or not that um he was kind of a bit concerned that uh what we're kind of targeting for this hard Fork to be very very short so that we can next big thing being veral and uh maybe something I wanted to voice his concern to is that uh we usually suck at estimating when artworks should ship and what we should

cram in and not cram in because obviously everybody wants to crme in as lot as possible and uh basically just to try to keep things on track perhaps it would be helpful to try to at least guesstimate when we want the next hardw to ship in point of date and then based on that try to cram in as much as possible but uh try to enforce that date so that it doesn't really overflow by one more year

Tim Beiko: yeah and I think people like definitely agreed with that I think the rough sentiment uh i' I've like gathered is people want something to ship this year um and so yeah like this means and

we haven't started working on it so you know assum assume that like denune goes live in a month um it means there's only like nine months left to the year at that point um so if we want a bit of buffer like it should be something we think we can probably get done in like six months or less and then we know maybe we'll get it done by the end of the year um so I agree yeah that's something that we should consider um when when when planning to scope for Prague yeah anything else uh before we wrap up okay well thanks everyone um I'll

coordinate the breakout for the AA stuff uh on uh on the Discord and talk to you all next week

thanks Tim by Tim record SC

h s

e than

Jesus my

all you

w I

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