All Core Devs - Execution #188

Transcript

[Music] [Applause] for

J

Tim Beiko: welcome everyone uh we're live for acde uh number 188 uh there was a ton of stuff on the agenda today we'll do our best to get

through all of it um I wanted to make sure there's a couple small technical things we cover at the very start so that if we get uh in the Petra weed for most of the calls we've at least gone through them so Charles had a um execution API uh PR that he wanted to get attention on and then uh Peter had a a concern around the minor tip requirement as we can do the two of them and then um last week uh all the L1 client teams got together to work uh on interop for pectra pias in veral so I've linked uh an update that we published on the agenda I can give a couple minutes overview of what went down there um and

then most of the call uh we have a bunch of Petra related things to discuss so uh we probably make sense to start with where we're at on deit zero um there were some spec changes done to 2935 um I think everything's been merged now but just want to make sure that we're all on the same page for this and then um a lot of the CFI and proposed eips uh for the fork had some updates so we can cover all of those uh specifically the account abstraction stuff around 7702 I know there's like an inperson event happening now um that is discussing this too so there's like a short window on the call where we can discuss this um and then re and the devops teams both shared what uh their preferences for the fork scope

should be so hopefully we can W up on that see if we want to make any changes to pectra scope um and then lastly um portal Network so we there were some discussions that interrupt about history expiry and if and how that would relate uh to portal so Piper is on to give kind of a quick overview of our things are out there um yes to kick us off uh Charles are you here and if so can you give a bit of context on the return data PR that you have

Charles Cooper: hey uh I just got here um yeah excuse me uh for context uh my name is Charles

I'm um the guess lead maintainer of the Viper language and also um I maintain titanboa which is an interpreter for Viper and also a framework for deploying contracts and interacting with the network um so this um I think is like a feature that every framework designer runs into uh which is when you ask for eth get transaction receipt you don't get the return data and so I made a pull request to the um what is this called execution API

specs and um to request that return data be optionally included in the receipt uh in the RPC call um I discussed this also with some people from reth and they said that this can increase the C the base cost of the endpoint and it could an alternative is to have a separate endpoint like eth get return data uh which gets you the return data which is a new endpoint gives you the return data for a um transaction and um that that also works I'm not as big of a fan of it because um there's some race conditions like you

can get the transaction receipt and then there's a reorg so when you could call eth get return data um you get a different return data or um there's other more practical issues like uh usually you're calling e get transaction receipt in a retry Loop and then you finally get the the receipt and then the server goes down uh which is like actually really common among RPC providers um so you get the receipt but then you have no R return data and then you have to like do another retry Loop and it's just a lot easier if it if you get everything back in one call and uh yeah I was wondering if I could get some feedback from client

teams uh and like figure out what is reasonable to implement

Tim Beiko: thanks um anyone have some quick feedback on this yeah

Dan Basu

Danno Ferrin: optionally stores the revert reason which is basically the same data as return data just on a failed call so it does have the wir to supported but as is mentioned it does um take more storage data because you got to store all the return data for every single call and um so it is doable but I don't I'm wondering if the uh revert Reon is a standard API if that's just something basic who did at a customer customer request years ago

Charles Cooper: so um also the way I SPC it out is uh like the client is allowed to uh return nil or null or whatever if it doesn't have the return data or it doesn't feel like recomputing it um so it's like kind of a request to return it on a best efforts basis and like my hope is that eventually everybody would just start returning it um but there's like a a great path

Tim Beiko: any other comments now or otherwise people want to take this to the pr

Charles Cooper: uh parody

traces these are non-standard I mean right now what everybody does is like they either ask for the parody trace or debug Trace transaction um or re eth call resimulation doesn't work because um you get the return data I mean the state could be different at the end of the block um so that's like a yeah e call is like not correct actually um but yeah uh the tracers don't work they're not or they do work but every client supports a different version of it uh there's a lot of variation between clients in ex exactly how it returns it and it again suffers from this race condition thing where you like ask for

the return data and then sorry you ask for the transaction receipt and then you ask for the trace and then like honestly like God knows what you get back um it's and it's just not universally supported got it

uh Merck

Marek Moraczyński: yes so the problem is that clients do not store this data and uh we clients have this data but after a processing block and there is no networking so we cannot simply add it as other fields um it would require consensus changes or our clients can store it after execution but only your local

client will have that uh when process the block so I'm thinking about more effective way than debug Trace transaction and what comes to my mind is as as it was mentioned uh if call or

part races

Charles Cooper: so yeah yeah um I understand that it's not um in the receipt database uh so I guess clients would need to like store in an auxiliary database or something and it's like yeah right not part of the consensus um but as I already mentioned there's like issues

with the parody Trace um Cena says support adding TX level state for eth call um that also works um but my question is like why can eth call return the return data but not eth get transaction receipt

Tim Beiko: okay I guess yeah we do have a lot of things to cover today and just does it make sense to continue this conversation on the pr um because it doesn't seem like there's a clear uh consensus on like do we want to implement this and how um Lucas you want to have a final

Łukasz Rozmej: so uh why if Co can return and get transaction receipt might

have a problem because we are obliged to serve get transaction receed but we are not obliged to Ser serve uh eth call if we don't have the state right so uh we might if we prun State already we won't be able to serve eth call so that's that's the reason right

Charles Cooper: right but uh so that's why it's optional in the pr the C doesn't can return nil if it doesn't happen to yeah we can take it offline my question is just like who what can we do to like fix this because it's like a major Thorn for like uh people who are using rpcs

Tim Beiko: so there's a

good comment in the chat by like client around just like trying to frame the motivation better in the pr because uh it didn't seem as big of an issue reading that in the on the call so yeah I think now that people are aware if we can rework the pr a bit um discuss this Asing there over the next couple weeks and um yeah if we need to bring it up on the call again we we can but hopefully we can resolve this

I thinkc

Łukasz Rozmej: if I can have one last thing maybe we we want ETF call but for traces that that would only return this without doing the big tracing and returning bunch of data and just returning the

result

Charles Cooper: yeah that was the alternative proposed by the bre team which is e get return data and that also works although uh I prefer the single call workflow single RPC call workflow

Tim Beiko: okay um yeah thanks Charles for uh bringing this on next up uh Peter you had uh thread around uh the minor tip behavior and I know there was a lot of back and forth in the chat uh or sorry in the agenda uh issue about this um yeah you want to give a bit of context uh on on your original thread and then uh the conversation that happened hopefully Peter's yeah Peter's

here we cannot hear you uh if you are speaking though oh I think now we can

Péter Szilágyi: can you hear me now yes we can okay it's really weird uh the microphone is using some other anyway here so um I will be kind of short because I don't really think this this deserves too much time basically the issue that was brought up is that uh G has pretty much since forever had this notion of controlling the minimum gas

price that miners require transactions to have and in the proof of work pre 1559 world that was basically all the transaction fees went to the miners and then miners just chose what they want as a minimum fee later after 1559 was introduced most of the fees were burned but 1559 still has this notion of a minor tip or a priority fee which goes to the minor and way back then the suggestion was that we should reduce the the tip to something like one gway because that seemed fair and U basically everybody as far ran with that and as time passed merge

came at some point I'm not entirely sure when maybe it was the merge for sooner or later there was some regression in G where this minimum tip enforcement was uh not passed from the from whatever subsystem to the minor so basically this led to get pretty much uh accepting arbitrary tips uh for transactions as long as they met the the the base fee of course and of course the tips were all ordered by uh by their magnitude so if Whenever there was some big congestion the the higher tips were always preferred and probably because of that we kind of never really saw this bug that uh smaller tips are also accepted

and a couple months back when I was refactoring the transaction pool I noticed that this tip wasn't really passed to the minor so I fixed it and we the release which all of a sudden again started enforcing the minimum 1 gab priority fees now the concern was raised that uh um this one gig away is inappropriate and it is causing problems for the network and which basically for this uh my suggestion was that we should bring it up to at all cord calls because um yeah for me it was kind of a surprise and the big question is that so this is kind of a client specific configuration

so any signer validator can control this via CLI flag and being just a client configuration there's Zero Effect on consensus however given that there seems to be an effect on on the network itself I wanted to just bring it up as uh if the consensus is that this value is inappropriate for whatever reason then um we're more than happy to to change it and before I before I give the the wor to anybody else just one more thing I wanted to bring up is that U basically we are we kind of uh uh can easily agree

that enforcing one gway is might be too big in the current climate where basically the base Fe is around 5 G so it's not proportional so I don't really have any issues with with lowering this fee however I kind of feel that uh having the local miners accept zero tips has thorny other issue where basically me miners can take a zero tip transaction and they have a chance to actually get some money out of it but naive local validators or local miners do not have M extraction so they can

only really rely on the tips to have to mean basically to have a meaningful uh reward for including a transaction so whil I agree that we don't want to um to mess with market conditions I think we also should take into account that uh local validator don't necessarily behave the same way as me extractors and we should somehow pick something that makes sense for for both the network perspective but also from a local block producers perspective any that's a short thing so

Tim Beiko: thank you um I think toas has his hand up

first

Tomasz Stańczak: hi few things so I think it's totally fine for G to set it one way it's not unreasonable um I agree that it's clear it was there it was removed I remember that from the old times and it's also reasonable for the local validators to have this set to one G and not accept zero g transactions uh because then you can sure I mean we we avoid spam because base fee is there anyway um but you don't justify the inclusion entirely from the perspective of whoever builds the block uh and they put some effort into building the block well when they are validators they are paid the reward

for the block construction so maybe they're Justified for trying to include as many transactions as POS possible and clean the mle so those different views but I think still CF can set the default especially as this is just a default and you can change it to something else I not necessarily agree towards the negative sentiment toward the entire M Construction within the context of this conversation um but this is broader topic and it's might be that we just have slightly different definitions here but yeah I'm definitely on Compu side but not necessarily also would suggest other clients to apply exactly the same defaults they may it may make

sense for another mind but we shouldn't have this in the spec or protocol design thanks

thank you um just to yeah Peter first

Péter Szilágyi: just one very very quick reaction uh basically I'm not really looking for to have a consensus on how all clients should behave rather I would like gu not to do anything where it's obviously bad for the network so it's like the consensus should only be on Behavior that's kind of considered healthy for the network not further specifications

got it um Anar

Ansgar Dietrichs: yeah specifically on that point I

want to to say that I don't think that the arguments I saw them in the kind of discussion for for in the issue for today that the concerns around the Network Health I don't think are valid I think basically G having a one way or whatever they want defa is fine for for for Network Health um I just wanted to find out because bab couldn't be on the call today he looked into this a while ago from one economic point of view and I'll post his right up in the chat but he was basically arguing that that it basically the the rational long-term outcome would be for even for solo bu um um Builders to set set the minimum as low as possible so like more one way than one gr um but again I think defaults are not hurtful in this case so

if gu wants to choose a higher default I think that that is reasonable um I don't I just the only thing I would say in the past with proof of work the tip was used to also basically account for the timing um problems that would be caused you would release the block would have more more chance of being un out unle like now with with the slots if you build at home if you solo build a block they aren't really these timing concerns anymore they're only really for like me extracting a Builders so so it kind of the cost for the Builder are lower now so basically you'd only have to account for the little bit of extra compute that you're spending on building the block so there might be an argument to at least lower the default below one way but I don't think it there any Network Health

conferenc thanks uh Lucas

Łukasz Rozmej: so from the network Network perspective right I don't see how uh if like let's say 80% of network is building with M how setting this in in clients would help with the network it will then cause even more of this uh small blocks followed by uh full gas blocks uh from the M Builder so unless we are uh we get M builders on board uh or we do something in protocol uh then I don't see this as being helpful to the network in any

way

got it uh fa you okay all

Fabio Di Fabio: so uh my point uh is that I would like to see some research on the effect of changing this even if a coordinated way or just by the the ster that theci side which is the value to set um uh seeing that because I see some possible side effect on this for example uh the impact on the burning of the base fee since uh could be that there will be

less burned fee as a result of uh user switching to some of the value of the base fee as priority fee so there will be more inflation in this case uh and also uh any case since you have also if the transaction has zero priority fee it will reduce the amount of the currency so uh we like to see in in case if there are any study about which will be the

prevision about that thanks

Tim Beiko: so I don't think it's relate like I don't think addressing if and how the base fee gets burnt is kind of related to this because um if we if we send part of the base fee to the minor it's just like saying you know the base fee was that amount lower and just from like a conceptual perspec persective thinking of the tip as this is what the minor gets is you know it's probably the the best way to do it and so um yeah it does feel pretty unrelated to like how much we burn because yeah

Fabio Di Fabio: um yeah if I can quickly explain better I

mean if someone has a target of spending three Giga away if we set the priority feet to be one gig away they will instead of using a b Fe of 3 gig way they will use a b Fe of 2 gway and a priority fee on one gig way and so there will be less burnt fee this is my one of the possible outcome I'm not sure of it for this I would like to see some research about that

Tim Beiko: I think there's there's already a fair bit of research um I I can maybe pull it off after the call but like when we were working on 19 59 we did have a lot of research around

like should we give the base fee to the miners and if so how much and whatnot um so I at this point I'm pretty convinced that um yeah whatever we give to the miners is effectively you can think of it as just having the base fee being that much lower and it just makes the base fee a less reliable Oracle for like supply and demand um yeah um so yeah I think I think anyways I think it it is valuable to like agree on what is the standard tip that we send um and you know do we want to standardize that regardless of whether that tip comes from the base fee or if it comes from like the priority fee um yeah um Ben I think you have your hand

up then Peter

Ben Adams: the suggestion on the base fee is because then that's sort of enshrined in the you know that's that's already the Oracle price in terms of it's still going to be whatever it's going to be um and then you can have um the priority feed be that I.E a priority um yeah sorry that's all I mean I don't mean giving all of the base feed but just like 1% or something which would encourage the um the minor to include trans

actions in the block because it's going to be hard otherwise

Tim Beiko: that's the whole reason we effectively have the priority fee is to separate those two concepts and the way you know it's exposing the transactions is we say like what's your priority fee what's your max fee and the max fee is effectively what you're saying the max fee is like how much is a user willing to pay for their transaction to be included and then the priority fee is how much are they willing to send to the minor and to get back the difference if the base fee is not high enough but the the max fee per gas effectively this value already

Ben Adams: um yeah um yeah but but the the minor is getting what 164th of the block reward for building

and

the

Tim Beiko: yeah that's a different thing

yeah yeah yeah

Ben Adams: so you get more for testing than block building um but you do get the priority fees on top and if it's not an enshrined that it's higher than zero then since most of the blocks is Mev and Mev does get a value for most of the transactions will become zero fee transactions

Tim Beiko: no because different Builders compete uh through the relay to send the block and I think so the question is given that because we have external meev Builders can effectively create these zero tip blocks that pay the validator through some other way um do we want to enforce a minimum on the

network even if it if it breaks with this mechanism I think that's kind of the point Peter was was trying to figure out it's like even if we we it is possible to still pay the minor a different way should the clients have a a minimum and if so what that minimum should be um I don't know Peter does this represent your yeah your concern correctly

Péter Szilágyi: yeah yeah so so basically if you want to push this to the uh this issue to the very limit then uh the worst case scenario that can happen is that let's say the base fee goes up and there aren't enough transactions to fill a full block but there are multiple zero

tip transactions so basically transactions that uh pay the base fee but transactions that give absolutely zero to the minor now is the minor expected to include those even though it gets absolutely nothing for it or is the minor not expected to include those and this is kind of philosophical decision because from our perspective from the Minor's perspective why would it include anything that pays exactly zero and from a ethereum network perspective I mean what's the harm in cramming them in if they fit in and um that's why it's it's not really a very very clear cut scenario and that's why personally I'm

leaning towards having a default that's permissive enough to not cause any issues but not too permissive to to really go to this extreme

Tomasz Stańczak: so I have a few comments maybe Peter for you directly I think that I I see some potential negative effects of that if you if you take some assumptions uh so imagine that everything everybody runs G with this settings that as default one way they didn't change it and uh and there's no m then it means that practically we moved uh one way of Bas feed to the to the priority tip which uh simply redirects the burn to the validators it's not

necessarily valuable problematic but it also doesn't feel like it makes sense now assume that there is 80% running GE nodes with this setting and 20% running the other client as solo validators with zero set then it means that the G validators actually decreasing are decreasing the propagation of the transactions that the other validators consider as valid because because the g notes will be a discarding those below oneu transactions from the network and other validators will have less chance of getting the valid transactions

prop

Péter Szilágyi: that is not the case so um way way back that was the case that gas transaction pool was linked to the fee

that the minina was doing but currently it is not linked So currently get uh the only basically we are our transaction pool is enforcing one way to avoid spam other other than that basically everything gets propagated independent of what you set your miners to

Tomasz Stańczak: but the the problem is that uh I think that even if this is not happening then imagine that all the all the gaps are running with one way default and 100% of the networks is it GS and then there is potentially uh a attack attack on the network when you fill the transaction with the with the zero priority fee

transactions that are not discarded by G but never included by the validator in the block so you have practically and you can set them in a way that they they seem like the best paying transactions in the sense of Max

Péter Szilágyi: I guess because the the best paying transaction is the priority fee so G will G transaction pool always orders everything by the priority fee that it actually pays

so get so so everything address thanks

Tim Beiko: okay so I guess it seems like people are generally fine with guest selling the amount that

it wants even though it's not zero um and yeah I I think at this point probably makes sense to move on to other uh other topics uh but is there any last yeah last comments on this

Péter Szilágyi: I guess for my takeaway is that if there's no nobody sees really a very hard reason for G setting it to zero then we will probably uh think about this a bit and either set it to 001 or 0 basically either 100th or 1,000 of a giga away I I'm not entirely sure what which one the idea to be the idea is to

be basically want a good enough default and then clients can just go wild with or node operators can go wild on top

Tim Beiko: yeah that makes sense

Péter Szilágyi: thank you for your time

Tim Beiko: and I think yeah maybe one last thing on that there were these uh analyses done during 1559 about what the amount should be um based on like the uncle rate and whatnot so um obviously it's probably much much lower post merge but I assume you can do a similar analysis where like you know how much the incremental gas usage creates like a a risk of being uh basically unold um and that might be a way that you can set the value yeah

Péter Szilágyi: well I personally I would pick a

much simpler theistic basically saying that if below some number basically it just doesn't make sense to have a transaction I mean if a if adding a transaction is going to pay you 0.000000001 Cent then yeah it just doesn't make sense so I think we'll try to pick a number where economically it's it's not a rounding error it's it's something that's meaningful and then people can go from there

Tim Beiko: got perfect um yeah thanks for bringing this up uh moving on so uh because we're already kind of late in the call I won't

uh spend too much time on this but we did have an interop event uh with client teams last week I posted a recap of it on the award devs or sorry on the ethereum foundation blog and then I linked this on the award's agenda um yeah there was lot of prod made n defet zero veral Pier d and a bunch of other things we'll discuss those topics specifically uh throughout this call and others um yeah I think probably makes more sense to just dive into Petra directly than discuss in a um unless there's anything else people want to bring up about it okay um so next up I guess uh on uh

the Petra front so on devet zero um we did launch a first version of it during interop uh yeah is someone on the devop team here to give a quick update on this

Parithosh Jayanthi: uh yeah so we launched uh devet zero on the uh during interrup and I'll link the spec sheet for devet zero on the uh in chat in a minute uh we have all the clients joined in but there have been some changes that were already proposed for devet one so we haven't done intensive testing on for example 3074 um and we we should discuss probably we will be doing that async as to all the chain sets for from that will

be active from DEET 0 to devet 1 and then do a relaunch on once clients are ready um there's one active buck that still needs looking into and fixing but otherwise the network has in general been stable

Tim Beiko: awesome any other comments thoughts okay um so yeah talking about devet one uh it probably makes sense to discuss just what we want the scope of pectra to be updates on the different eips and then that will kind of uh lay the groundwork for definite one um one of the things that uh did get a bunch of changes during interop was uh EIP 2935 which uh uh especially with regards

to uh the blash op code it seems like everything has been merged um but were there any outstanding questions or concern around 2935 okay um okay great so um then I think that was the only one with like uh significant spec changes uh that happened during inop uh 374 and 7702 is is kind of a whole different EIP so we can discuss that separately um and so okay on the topic of like stuff that's been cied or proposed for the Fork um one of the big ones is eof uh so there's been an update

shared on that as well uh basically by the solidity team uh that they would support it and uh ipsilon shared a proof of concept uh for solidity to support it does anyone on the call have any um questions comments concerns about eof uh or any specific updates

Georgios Konstantopoulos: do we have anyone from Sol here they said that they had it ready or that they would be supportive rather

of

Tim Beiko: Daniel the solidity lead posted in the R&D Discord earlier today that their team was uh very supportive

but I don't think that he can make it on the call um yeah I'll C I pasted the message in the agenda but let me just paste it in the zoom chat here

Danno Ferrin: um yeah this is Dan faren um sorry my internet literally just went down so I missed some UF conversation um but the numbers that I that the um ipsilon Team put up are better than the numbers I saw with what solidity had for the big eof I was seeing 3 to 5% we're seeing 6% code size reduction and um call gas usage down by 9% which is bigger numbers than I was hoping for um so I guess you know once again we're asking for you to be

included Prague Bernie Sanders thanks

same from the r side

Marius van der Wijden: I can speak on our progress from the guest Side Y um we had an issue basically we I implemented the a nonoptimal algorithm for the stckers ification um and I started uh implementing the new algorithm but that also means that basically most of my progress is mood um

so I start a new um it's almost implemented but um it fails like basically like half of the tests um the spec still isn't in a place where I would say it would be easy to implement for someone um that starts from nothing um I think at this point no of the no other client starts from nothing so um basically everyone has at least something implemented um for us it's still a pretty long way to go to be um to the

Future complete um but even then I'm not super convinced that our implementation is actually correct um or will be correct because it's such a huge huge change and has a lot of edge cases and um as I said in the during interrupt I only implemented it like I I I just took this back and try to implement it I have not really thought about what I'm actually implementing um so from the breakout breakout rooms I was in um also the one yesterday I

believe it feels like the um the the Epsilon team and Charles and um I guess Deno have really thought about the implications of changing the off codes in the way they are changed um so but yeah I don't at this point I cannot say if this is like if they missed something or not um uh at this point I kind of have to believe them that they they made the right decisions um for all of the changes that they are proposing I it kind of depends on when we are trying to schedule uh pectra but

um from my point of view adding EF would definitely delay the pectra um which I don't like but that's just my personal opinion that's it

Tim Beiko: thanks uh Charles yeah I assume this is R to

E

Charles Cooper: yeah um I posted my kind of current position on UF in the ethereum magician thread um basically you know I've been helping out uh and contributing to the spec the last year or two and um I'm supportive of anything that improves evm execution there's a

couple spots in the spec which I think could still be improved if we had more time um I think that uh that uh format would be improved if we use variable length quantities which I've been going on about for the last few months uh because it's more future proof um and I guess the consensus currently is that uh you know we don't have enough time to change the format at all and um kind of just want to you know make it known that I raised this as a concern so that when we can't it works hard to like upgrade UF to allow larger code in the future um yeah it could be

an issue the other thing is that UF by Design um which is it's a bit deeper UF by Design um doesn't have the same Global code section design as EIP 2315 so it necessarily forces the compiler to make some tradeoffs and with some recent improvements the the the the the validation and Allis spec um they're not that large but they are trade-offs um and think ideally this could use some more thinking um I also think that eof is nice like quality of life things a lot

of really nice quality of life things um I think that solidity is seeing um you know really good movements partially because UF has um things that are specifically or you know kind of targeted towards C's coent actually um and my position is I think it would be nice to have a a dedicated UF fork or something so that there's a little bit more time to finish some of these things I also think you know I see your hand up uh and I'm guessing you know that you know I can already hear Deno

saying you know we don't we can't get everything perfect in sh but um I think that user safety and I've been pushing a lot on recent you or sorry ACD calls for um either non-reentrant op code or improvements to transing storage pricing and these are user safety things that I think should also be in Petra and if there's a conflict between these I would prefer to see EF go in its own fork and um we're able to get trans and storage pricing improvements sooner

Tim Beiko: thanks um yeah then I know you have your hand up but I do want to make sure we get through the rest and assuming we move forward with eof we'll discuss the specifics uh later um the

other big one that's been uh heavily iterated on in the past couple weeks is uh EAP 772 which is meant as a replacement for 3074 so um 374 is still sort of what it's officially included in the fork uh but it does seem like there's been a growing consensus around 772 from both the the people who supported 374 and the people who had uh issues with it um yeah I don't know uh an I know ongar vitalic LCL the three of you had been uh working on this I don't know if either of you can give an update on where things are at um and yeah can take it from there

Ansgar Dietrichs: yeah I I mean I can I can give a quick

update just um so basically there have been some discussions um over last while um it inter opened in different other places on the internet as well and um there's been some iteration on on the on the EAP I think right now um light client has a PR pending with uh updates to to the EIP I can link that in chat um in a second Che here here we go um and so basically I can briefly go the The Count um variant of the IP so basically um um you would specify the address of um of the implementation you want to use for your account um in the transaction

body and not the code itself you would also sign over that address um it would not run any init code at the beginning of the transaction just copy the the code in that address over um chain ID would be um possible to specify but optional nons would be possible to specify but optional um there are there would be no upcode restrictions including no restrictions on self-destruct and including no restrictions on storage rights meaning that storage would also be persistent after the end of the transaction and for now there would be no initial um permanent upgrade capability so no flag or anything from the start at least to have the code persist in the EA after

the end of the transaction although of course the idea would be to add that at a later for there have been like some of these are pretty uncontroversial some other ones are still like there's pretty active conversation on I'm not sure to what extent it makes sense to have that conversation live here on alod defs um but so basically for example um to mention draw from the 437 team I've seen um be quite vocal about um saying that we should have chain chain ID um commitments be mandatory instead of basically optional um and uh also I remember having having some conversations with the Aragon team specifically around them preferring to have a more explicit split of versions

that are um revocable or like basically are committing to non Chad ver the ones that are not so we could basically have two completely separate signature types one of them basically for a version that is um with nons and with chain ID mandatory and one version that is basically completely without nons and chain that way we could have a more clean split so these are like still some of the questions that a little bit in flux but we are overall converging more and more on like a specific version of of the CIP oh yeah that's kind of my my take

Tim Beiko: thank you any anyone else have thoughts uh oh

Andrew

Andrew Ashikhmin: um yeah that's what we discussed at the interrupt so there probably there are several scenarios how this I can be used if it's a milestone towards um permanently migrating to a Smart contract then it makes sense uh to have non-revocable signatures uh but also this um I can be used for more Emeral things like uh badge trans transactions or sponsored transactions and in that scenario uh you want to play safely and uh have revocability and so yes we discussed

with ncar it would be good to have two types of signatures like one very generic without nons and chain IND and the other with a chain chain ID and nons to separate those two use cases and I think uh I would uh replace 3074 with this 7702 in pectra but I would only cify it until we kind of we agree on the revocability design because to my mind that's very important and uh I don't want to commit to this uh if uh like

100% until the revocability question is resolved

thanks uh Ahad

Ahmad Bitar: yeah just to clarify uh when he said the Virgin uh signature because Marius asked in chat this means that there will be two Magics for this type of message and message signature one magic will uh mean that uh it has a nons because uh nons cannot start with zero uh whereas the other magic will have no n so one magic with nons non magic without nons so if one someone wants to sign something without a nons they can do that and if they want specify the

nons they can do that as well and with chain ID we decided to go with zero for um not not specifying a chain ID and a number for specifying a chain ID and uh like this gives maximum flexibility to the developers to implement uh multiple pth conerns at at the same time allowing the user to have all the security guarantees that it would like to that he like the users that they would like to have on their accounts um yeah

Tim Beiko: thanks uh Daniel

yeah I I just wanted to to to add

something to what Andrew said regarding the the the revocability so I initially was also very much against not having revocability in the EIP but after some feedback from the metamask team um it seems they feel confident that they can still manage the the security of the of the use of funds without it so they for example are talking with other wallet providers to implement some sort of like a permissioning system I think they also want to do something like uh adding like modular permissions on the I think similar to 37 so before we are adding maybe more complexity complexity to the EIP but

adding more functionality we also should seek feedback from the wallet teams if they think that's a good idea or not or if this is something that they will use because the the worst case would be that we are adding comp complexity to the protocol and afterwards nobody's using it anyways so I think we we should do this first before we make decision on our our own

Tim Beiko: got it thanks um do vitalic and then Andrew again

Vitalik Buterin: yeah I mean I think one important consideration to keep in mind is that a lot of the revocability and chain ID considerations regarding 7702 are extremely similar to the ones for 374

which makes sense because the whole design rationale for 772 is to basically be a something that Prov the functionality that's parallel to 3074 but in a more like smart contract forward compatible way and so given that I think uh it's just valuable to remember that like there has been existing discussion about the like tradeoffs that has very similar reasoning and like the switch of e is that we're pushing is not a reason to like restart that discussion from zero and uh there's value in r resting things that have already been discussed over the last couple of

years

Tim Beiko: yes um Andrew do you have another comment or with your hand still left

Andrew Ashikhmin: yes I do so uh I totally agree that we should check with wallet providers U uh it's feasible and for them and they're happy with it but uh I am a bit worried that if we decide to rely on exclusively on wallet providers for a revocability or white listing or whatnot uh I my my preference is to have uh something built in the protocol

uh instead of uh yeah relying on on on only relying on wallet providers

Tim Beiko: and can you can someone please remind me what what we did for 374 like did we not have this trust assumption oh right okay the non increment got it thanks um Derek

Derek Chiang: uh yeah so so uh I think I think in 37 P4 um like the like the like the last the last finalized the last finalized version says that every time

you increment an nouns you'll be revoking all outstanding all messages right you know but but I do want to remind everyone that in our last call you know you know you know and also just like in all the conversations that that have happened since the last call um I think like all the stakeholders like all the relevant parties like whether it's like the the cevs or the 437 authors or the world teams such as mamas um you know you know you know as far as like the four to seven account Builders such as myself I think we are all aligned that is it's very important to support the longstanding um authorization use case right you know they're like they're like you know it's very important to make sure that like uh it's not the case that like every time the user makes a transaction that like all outstanding

revocations you know you know I mean you know that all all outstanding authorizations will be will be revoked I think I think you know I think like everyone has already aligned on that whether it's like in the last call or like in the subsequent online conversations that is very important that because like the some of like the most powerful use cases of account Direction whether it's like like adding like adding new signers to your accounts or whether it's um things like like transaction delegation permissions session Keys those all depends on having a way to keep authorizations alive despite the user sending transactions so I think like the only thing the only thing that we are not aligned on right now is like the the mechanism that uh that's enables that right you know so so

I think like there's proposals for you know things like introducing like a Max L mechanism um or like there's the proposal that I think uh that Matt madees in the in the latest updates about introducing like optional um you know you know you know basically just like making nons optional so personally I'm I'm fine with whatever you know but I just want to suggest again that like all the relevant stakeholders have already expressed that it's very important to to enable the longstanding all those cases

Tim Beiko: yeah thank you um let's do vitalic and then Eric

Vitalik Buterin: yeah I mean I think uh this is starting to get a bit zoomed in but one thing that's important to also think

about is like there is a particular way of using 7702 that a lot some people have uh have in mind for some of these longstanding things which is basically that wallets only ever sign one message where the one section message is permitting a standardized proxy and then the intention is for like any use case that's not like literally ifal could just be built on top of that and the the proxy would have its uh its own upgrading mechanism um so I think one of the side questions that's worth discussing is basically like to what extent there is there is alignment on

that approach right because uh you know if there is then like yes um like making unrev like complete unrevoke ability becomes something that's much safer but then like if not then there's a more discussion um but I mean I think in in general right this is uh definitely starting to get into some of the rabbit hole areas and so I think uh as a meta Point like realistically it's uh this stuff is going to get resolved through like one or two breakouts uh and that's like getting everyone to agree on things in the next five minutes of this

ACD

Tim Beiko: yeah I think I I would agree with that um I I

guess one thing so I think yeah one thing is we should schedule a breakout to like get this resolved it is worth highlighting that like if we can't get to a solution then like the sort of status quo outcome is we don't ship anything um so I I guess yeah maybe maybe yeah one thing uh to to figure out is just when we want to have breakout I know there's some inperson meetings happening in the next week or so uh on this stuff so uh if someone who has like context on the whole 7702 discussion can propose some like appropriate times for a breakout on Discord that would be great uh we should ideally have a final spec before the next awkward devs I think if we don't then it becomes very

hard to actually um to actually you know include this in the EIP um and then yeah there's two comments in the chat now about this like uh it seems like everyone would be in favor of swapping 374 for 7702 assuming we have a final spec um I don't know if we're if we're like finalized enough to include 7702 in implementations now but does anyone oppose removing 374 um CFI in 7702 and then on the next call we can potentially include 7702 if we have uh a spec um and yeah I guess that onar point like

we sh okay so people would rather not to remove until we switch over and I guess yeah I I think it was Aragon who raised the concerns with the um with the uh uh uh revocation like on your end Aragon would you prefer to like include this um include this and remove it at a future date if we if if we don't find a final spec um so that we can actually get started on the implementations

Andrew Ashikhmin: um yeah from my point of view it's fine to cfy it and start working on it and uh include it into like the next devet but yeah I mean if

we fail to find a solution dramatically yeah then later we should exclude it

Tim Beiko: okay so so I think then what what this would look like is we CFI 7702 included in Dev net 1 and then remove 3074 um and assume that um assume that uh yeah we can figure out the issues with 7702 now yeah okay and there's actually there's a final proposal by Justin is like keep both right now is it simpler for client teams to keep both in the next devet or

is it simpler to just do 7702

can we discuss the they Sy

Tim Beiko: yeah okay well I guess yes let's move forward with 7702

Marius van der Wijden: um so yeah so just one small thing um we didn't actually test uh 374 and definite zero um because Perry forbid me to do it um because we was so afraid that the death net will completely break so I would propose removing 3074 so we can just go wild with the Pu and and test

Tim Beiko: um so okay okay so let's do that let's remove 374 I I had to know my

oh sorry were you going to say something else no okay remove 374 add 7702 have uh um um yeah have that part of the next Dev net and then um if and create basically um basically have a a breakout in the next two weeks uh to iron out the spec issues um and I think onard to your last comment I and based on the Aragon stuff it's probably simpler to you CFI 7702 uh and then include it once the spec issues are finished but we also have it as part of defit one um that feels like

the best compromise to move forward actually get the work done and also make sure we have a final spec that people are happy with before we uh commit to it further um anything else on this before we move forward okay um thanks everyone uh for uh all the thoughts and comments here um yeah so please um Anar like client someone else figure out the time to schedule the a breakout or the 7702 breakout based on the burn in meetings um but we should aim to have all this wrapped up before the next allore devs um yes okay and then okay

there's three other uh eips that had updates uh that are a bit shorter so if we can get through those in like five minutes um hopefully we can then spend some time discussing the fork scoping um so 7623 um Tony are you you on the car

um yes I am I will be very quick so 7623 the latest update included reducing the gas cost from 1248 to 1040 this would mean that even more even less users are impacted um talking with people it feels like there is some demand to ship that in Petra U maybe we can do that already in the next um defet because it's a rather small change there were some

discussions on Eve magicians so Martin from G also voiced that um concern about this weird Market that it might create but yeah we could resolve those um those concerns and um Martin is now also um for the

EAP

Tim Beiko: awesome thanks any question otherwise we move on to the next one okay uh the other one is 7212 the ripip with the R1 recompile um I forget who was supposed to give an update on this

hello

hello I will give the update and I will be very quick for that and I wanted to remind

the current situation about the rip as you remember the first the IP has moved to an RP status and be implemented by some of the rollups and it has been cified to acds before and I will be talk about the current rollups that implemented and also talk about the current client implementations I'm also posting at the chat recently polygon has gone to main net with this pre-compiled contract and the casing is on test net and will be PES soon on Main net and in optimism and op secops including base and Kakarot ZK evm has merged to

their repos and I instument is on governance to implement the proposal in the next hard fork and in the client implementations get Aron B and R client implementations are ready and polygon and the other optimistic rollups are using this reference implementation arigon is following is implementation and also use it on the polygon and I I have just seen that best has a draft PR about the the issue and I think it's also ready and red implementation has been worked on Arium

fellowship and I guess it's also ready and I have just seen that n mind team is currently working on this EIP and I'm not aware of any implementation in eum J and that's all I want to mention for now and if there are any question about current status or CFI status I would love to answer for them

Tim Beiko: okay thank you okay and I guess uh last one uh was ssz I don't thinkon is on the call but he posted um uh yeah he he posted an update on the

agenda um I don't know if anyone has any questions comments about it uh yeah

C

Cayman Nava: I can just yeah I think this makes sense to discuss more in the context of uh increasing the scope or nonincreasing the scope of the fork so I think we should delay that delay the discussion until then

okay so I guess

Tim Beiko: yeah that is the next thing on the agenda um and maybe to start this so I know R put together a document uh with a bunch of different options and then the devops team as well so maybe um yeah maybe uh R you want to start and then

we'll hear from devops and go from there

Georgios Konstantopoulos: yep so um I'll share the dog in the zoom chat in case people haven't read it I would appreciate if people would have a chance to read it the next time we have such conversation um I'm trying to answer three simple questions which is when do we ship prag if we ship prag later on should we extend the scope and B and C if we choose to extend the scope what should we include I think the first topic that I would like to discuss is should we ship it 2024 or should we ship it q1 2025 in my experience um people haven't

been shipped hard Forks in novembers and December in particular because in December people go on vacation and this time because people people um will be in Devcon and my understanding was that people don't want to be doing work while they're at Devcon now I don't know I'm just raising that into presence I know that we ship when ready that's how definitely we ship um so if people are down for that sure but you know like just bear that in mind and my understanding is that indeed people don't want to be fixing a consensus issue at Devcon so I'm just caving cting that and beyond that my thinking is that

if we were not to ship it in 2024 um basically if there is any kind of scope change uh allowed there's room for one very very important thing that is p death um I'm not ancl developer and we don't run this C uh Team uh we do know that demand is arriving and we do know that the El and cl updates are coupled as EAP 4844 is defined right now what does this mean it means that there's no room for a CL only hard Fork um from the e because the El has a constant it says a blob count um so if you want to do a blob count increase um

you need to do it on the CL and the El and that's a problem um the final thing on why I think on why period is important here versus um just increasing the blob count is that and somebody from C should confirm that is that due to how 444 works and how blobs and the block proposal or attestation are coupled um there's already high bandwidth requirements so there's some blocking that happens during the CL process um and even if you increased blobs you wouldn't be able to have a solo Staker or a low resources modde operator to be able to not miss slots so it seems like

a problem in any case to increase blobs and it seems like it's worth including pure D to get around that and to the extent that we do that uh for cl it gives us plenty of time to also do it on El uh and in that case there's a question of okay what should go then and then we would pitch the scope for eof which we think deserves a whole conversation for it and we wish we had time so that's where we're at so the tldr is let's ship kagon q1 on the C side let's do p us on the El side let's do eof including whatever else we've talked about for 7702 and I would love to also hear the EF devops uh take on this uh from our

point of view small Fork is kind of a meme I don't know that this has happened properly ever um so it seems worth being present to that uh and not saying it is is something we could do it seems worth being very explicit about what our expectations are here

Tim Beiko: thank you um and yeah I before we hear from uh the yeah devop te I will plus one the like small Fork comment like there's a couple chat comments of like you know we can do just a quick fork with pi Das and eof before you know verco or Osaka then we should just call that thing and assume that like we've agreed to do more work and separate it into a separate Fork um and if it ships quicker great but like uh it's probably

a bad process to like assume we would only do this work if it's like a quote unquote quick Fork um yeah uh Barnabas or Perry uh from the devop side

Parithosh Jayanthi: yeah I can go um so we've also posted our thoughts on what we um on what the fork could look like and I think one of the differences is that we just wanted to Define all of the options that we thought were viable and then um towards the end just specify which option we prefer uh but also want to C out that we as a team could not even come to consensus as to what option we prefer so yeah uh take that with what you will um I'll just start with a bit

of thoughts and concerns that we had as well as counterpoints to them uh the first one is that right now we've been looking at most eips as just testing the single EIP we haven't necessarily looked into testing the edge cases of one IP with interactions with edge cases of another EIP a simple example is we're uh changing how deposits work but we're also changing what a validator is with maxb so we're going to have to stress test both of those edge cases in combination and not just um in isolation so that I imagine would increase the scope of testing uh but one of the points that pava made as a Counterpoint to that is that irrespective if we ship it together or if we um ship it separately we're still going to be doing

Edge case testing so it doesn't make a difference if it's in one fork or over two forks um I think me personally I would prefer it in two forks purely to reduce the risk but I think that comes into the mega Fork versus the um smaller Fork discussion again um another point that we wanted to bring up was that in all of the discussion so far we haven't included EIP 44s um I don't know what the status is of that if it's happening fully out of protocol if there's some sections in protocol and out of protocol and I think we also should be aware of how many research efforts we have that we want to ship so if there's a subset of the team working on 44s a subset working on veral a subset working on

pias that's a lot of subsets for small teams um yeah and like uh Ana said we just wanted to put all the options out there and see what people thought and then use it as a starting point for a discussion

Tim Beiko: yeah thank you this is really helpful um yeah any other teams aside from devops R has thoughts on how we should approach this

Georgios Konstantopoulos: it from the red side we generally defer to the devop team as the testers um yeah I think we've said we've shared our view in

rating

Dragan Rakita: yeah in general I would say the

TF as it stands now could be ship in 2024 because the uh I took just two months to implement it I know there is a lot of testing needs to be done some of test already written but evm is the component that's well defined all they have testing suits and Frameworks that we can reuse so I think the framing that UF is the big change and will take like a year to implement is not correct because I heard some discussions that relate to that

Tim Beiko: so I don't know if it's like a year but there's some comments my guess about like it would not ship in 2024 and I think yeah like obviously we have many

clients um but like yeah we we we uh we have many clients and we we need kind of them all to ship the fork so yeah so I think you know we should assume if we do e then we are probably delaying past 2024 and you know it's great if we are quicker than expected in in you know reship in 2024 but usually we're actually slower than than we expect with these things um Andrew

Andrew Ashikhmin: um yeah uh so I think uh if we include EF into pectra it will realistically delay it by maybe three months and got it but I'd like to say that we it's

better if we decided either on this call or the next one because we need to uh plan our pector work so we we shouldn't like prolong it indefinitely the decision

Tim Beiko: yeah thanks

Dragan Rakita: just said for discussion both the G and AR good don't have implementation so it's just estimation that they're giving that's going that that youf is going to push uh prag for 2025 it's like uh it does increase the scope but in my opinion it it's not that big

got it um let's do Yas and then

G

Jacek Sieka: yeah I just wanted to mention two things one is for a stable container which basically the way we were thinking about it in uh Kenya was that we could introduce it for the things that already change um this would be good for users because they like they only need to perform one smart contract upgrade then and then in the future they can have their proofs and everything uh forwards compatible so that's kind of like a stable container light way of including it in in Vectra uh for 44s uh the way I think about it at least is that a lot of it we can ship uh without a hard Fork uh

including experimental test nits and and things like this so I think it's worthwhile to start working on it now uh ship the parts that are shippable without a hard fork and then when it's stable we can formally like include um you know user documentation basically that the network uh all the nodes on the network will no longer be holding block history

got it um yeah gon

Guillaume Ballet: uh yeah that's actually not a bad eof uh I mean I do think like the rest

of the guest team that is going to push stuff to 2025 uh traditionally we have done the the test thing but I I would say that's not a reason per se to to stop e um the the question I I had because something you said Tim um did you you just say that uh you were already considering moving oaka yet sorry yet another Fork that's something that wasn't clear from to

Tim Beiko: what I said is that if we if if the decision is there should be a fork after Petra that has P us and eof we shouldn't call pectra 2 and lie to ourselves that like it's a quick fork and we're going to be able to ship it in

two months we should assume that it's going to be another full fork and the consequence will be delaying veral yes um I I think this is like the this is like the failure mode we get in when there's more stuff we want to do than what we can actually do so we you know try to like squeeze things between two forks but effectively they are two real forks and you know the naming should reflect that rather than like making us feel better that you know it's only pet Petra 2 and it's not actually Osaka in practice it's another Fork

Guillaume Ballet: but from what I understand from Perry's proposition at least proposal sorry is that uh he's talking about an a seal only fork which could perfectly cohabit with veral and

so whatever doesn't make the cut in Prague should make the cut in Amsterdam instead

Tim Beiko: sure like yeah yeah whatever like I guess my point is much more if we have something on the E between now and the next Fork we should just call that the next Fork it doesn't matter like you know what it is we just shouldn't like assume that we can just sneak in like mini Forks between forks because that's just realistically not going to happen um yeah um Andrew and then do Alex

Andrew Ashikhmin: um yeah I I think um between verle and EF I think verle is more important and uh we already committed to shipping vehicle in Osa so if we don't include EF

into Petra I don't think that we should have kind of a pectra two Fork we then we should postpone EF to Amsterdam

Tim Beiko: yeah thanks um Alex

Alex Beregszaszi: yeah sorry if the the mic is a bit noisy um it's it's kind of connected to what D said um I kind of feel like um this group on all cevs has maybe a tiny bit less visibility on on the application layer and what kind of benefits uh people using the evm could feel with something like UF uh obviously all the discussions here extremely important and Tackle different parts um but I kind of

feel like maybe the visibility of of developers experiences is is less um understood by this group and I do have a question because I kind of feel like what Andrew said if e right now wouldn't be included in Petra then I don't really see that it would ever be included because then having another Fork withf uh there wouldn't be just like a one or two or three month delay to Petra that would be a full for with you know however many months that takes and that in that case that would extremely delay work um because of that I kind of feel like this

is the the only opportunity to to Really introduce UF um maybe at the cost of one or two or three months delays I don't think it would be introduced otherwise and we and I do feel that we have really good um momentum right now with all the implementations um so it feels like this is the correct time uh to do it um I think that that's my summary

Tim Beiko: thanks um I do um yeah okay I do want to make sure we keep at least a couple minutes for Piper so we can do Gom and then Marius um and then wrap this up um and have you a few minutes to at least talk about the history expiry

Guillaume Ballet: yeah so I'll be quick uh I think

doing uh like it doesn't matter when you do eof either eof is important and adds value which I think it does the rest team for example in in Kenya has made a fairly compelling point about what they want to do to achieve with it uh so I don't think that you don't schedule EF in Prague it kills EF because if that was the case then e is pointless which I'm convinced it's not

thanks uh Marius

Marius van der Wijden: I wanted to say exactly the same thing if we if we think this is the only this is the only time um that e can ever happen then it's not a good future and we should just drop it um like there's no point in shipping something um if we don't if we're not convinced that um

that we can also ship it 6 months later and it's still important um so yeah do what with that whatever you you you you want but um I think I also think UF is a good feature and it should be shipped at some point um I do like the thesis of uh of doing it on L l2s first um they can do it right now because they have the code because we are writing the code for them um so I don't really see the argument of l2s cannot build this um because we basically built this for them already so they could roll it out if they wanted to

Tim Beiko: okay I guess um it does uh yeah it

doesn't seem like we're going to resolve all of this in the next two minutes I think uh as I said in the chat like pure Das feels like the most significant bit here and it'd be valuable to discuss on the CL call next week um how we want to Prior prti pure Das and or just like a a normal blob increase and then kind of structure everything else based out of there um assuming we do that um it would be really valuable for teams to Think Through you know the different options that uh the the devops teams put out and you know other options potentially of what they want to prioritize so that on next week's CL call we can make a decision about pure Das blob counts and whatnot and then use this to inform what

we do on the El side um it does feel like you know uh there's not a burning desire there's not like the same level of urgency I guess on anything El related than there is on potentially the The Blob count um and yeah I Joo Dragon if you can put your comments in the chat just because um I want to make sure we leave at least a couple minutes for uh the history expiry stuff um yeah sorry about that but um yeah tldr I think t teams thinking about this in the next week discussing on the CL call next week specifically related to pust and what that implies and then two weeks from now on acde we make a final call about the scope of Petra um from

the El side um and in the meantime teams can obviously work on uh devet one which would include um which would include the same eips as we had uh module the 374 7702 switch um yeah Piper

Piper Merriam: everybody how's my mic uh great thanks uh I've been playing catch-up this last week uh since I wasn't there for the breakout on for fours and history xre um been looking over all the notes and documents and trying to find out uh you know what happened there and and where uh what El teams are interested in um we're excited to collaborate with you guys on this um in

the notes and things that I've seen I've seen a lot of destion of a minimal portal spec and I'm curious if anybody has anything specific that they've identified in our spec that they are um uh you know uh wanting to cut out um I I I uh and I I haven't gotten anything specific yet and if there isn't anything specific I'm wondering if we can stop using that terminology um I'm pretty sure that our history specification does exactly what you guys want it to do um my questions I guess are kind of like what do El teams need from us to uh to move forward with

this um we're definitely like here and ready to answer questions ready to you know show El teams around that sort of thing um there's documents posted in the history XPR channel on the R&D Discord um I I encourage you guys to take a look at those if you're on an El team and you're going to be heading up uh implementation of this I encourage you to come say hello to you know our client teams and things like that and introduce yourself let us know what team you're working on or what client you work on um and we are having an in-person event next week in Prague May 28th through May 30th and if you are going to be diving into some of this stuff and you are able

to make it to that uh it would be a great way to on board fast um if you to come please DM me on telegram or wherever and I can get you guys added to that and I know we're mostly out of time here but uh if there's any questions or anything around this that anybody wants to raise um I'm here for that

Tim Beiko: thank you um yeah we are already a minute Pas time but um yeah yasek and then Andrew uh we can do your comments and then wrap up

Jacek Sieka: yeah so when we talked about minimal uh we talked about the block history and not so much the other components like

like Centon uh state so that's that's what minimo refers to like block history

so we already do this in our specs and so there's nothing that actually needs to be cut or changed for uh clients to be able to implement only history so so that is supported in the existing Network client designs

Jacek Sieka: yeah and the discussion was mainly around the like Cent protocol as well whether that is the dependency or not and it's not really from an execution Cent point of view it's more if you're running a full um portal node

that doesn't have access to any other consensus mechanism

Tim Beiko: thanks um Andrew

Andrew Ashikhmin: um yeah I just had the same comment as that we want some kind of mini portal spec for blog history only because um As I understood vitalik's warri is that uh we don't want to rely exclusively on archive nodes for Block history so uh as far as I understood the idea is that non archive nodes commit to store a certain chunk of block history via the mini portal

Péter Szilágyi: uh yeah uh our specs are history data like the history network is history data only there is no minification that needs to happen here uh we don't do transaction hash lookups in that Network it is strictly block history and to the best of my knowledge it does exactly what you guys want it to be so we can keep talking about it but the the concept of like a minified version of the spec I'm wondering if we can drop that language unless somebody has something specific in our specs that they've identified that is uh that's extra so um looking forward to answering more questions uh we're here and ready for it um we got a network ready for you

guys

Marius van der Wijden: so we already kind of have like a networking layer and as far as understand um Port is built on a different networking stack um do we need this different networking stack to be implemented in po notes in order um to join or would it make sense for portal to adopt the current networking spe stack that we have

Péter Szilágyi: portal does not work on dev P2P you need a DHT for this um and it is why we've built on the networking stack that we have built on um building it on a fundamentally different network stack is going to

require somebody to come in and solve a whole bunch of problems so if somebody else really wants to do that work they can but that isn't portal

Tim Beiko: thanks okay I think this is a good spot to wrap up um we're already a few minutes over time thank you Piper for um Coming on thanks everybody for all the conversation and again um I'll emphasize like please try to Think Through the scoping for the fork in the next week so that we can have a good discussion on pier Das um and everything else on the CL call and then finalize the scope on the El side on the next acde um yeah that's it for today thanks everybody

thanks everyone thank you

thanks everyone bye yeah

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