All Core Devs - Execution #191

Transcript

[Music] great

Alex Stokes: hey everyone this is acde uh number

191 Tim is out today so I will be filling in for him and yeah I dropped the agenda in the chat here it's issued 1080 on the PM repo and let's get started so first up uh let's just jump into Petra and and in particular if there are any updates for devnet 1 there's a link to a spec here uh with the latest in greatest eips um yeah would anyone like to give an update on uh their client's progress or anything like that

Parithosh Jayanthi: I can maybe start with some uh overarching progress update so we do

have local testing done for or uh two Els and three CLS and there's a bunch of happy case scenarios um and the CL seem to all agree on the happy case scenarios which is great news um I've posted the kosis config link to reproduce that so in case someone wants to test if they're following along the chain then you can have two clients be the producers and you can just check if your client is fing off based on the happy case tests um and the qu open question right now is do we want to wait for more clients to be ready before we launch DEET 1 or do we want to just launch DEET 1 and retroactively add clients as and when

they're ready

Alex Stokes: Andrew

Andrew Ashikhmin: yeah I can talk about Aron's progress uh we are still working on 7702 uh that's work in progress uh but uh I think launching devet 1 now might be the timing might been a bit unfortunate because next week is is STC and a lot of people will be there so I'm not sure whether we will be able to work because of the ECC

under the net one

Alex Stokes: Daniel

Daniel Lehrner: I can give an update for for b um so we were running the execution tests uh that were released last Friday we are still fixing some bucks um that we found with the test um I think we will be a bit slowed down because part of the team now is on holidays because of July 4th so I would guess we would be ready around mid to end of next next week um but I think for us it would not matter so much if we start def one already now uh or not so if not we would just uh Jo

later

okay thanks mie

Mehdi Aouadi: um an update from te uh we're ready for DEET one uh we have all the reference test uh passing so yeah

Alex Stokes: okay great Mark

Marek Moraczyński: yeah we are working on this uh Happy Puff scenarios bar mentioned we uh will update image before devet one because we uh have one bug in 7702 um but we should be ready pretty soon with this fix as well

Alex Stokes: okay cool

kind of sounding like to me we could wait another cycle of ACD uh to launch I don't know if Barnabas or Perry feel differently

Parithosh Jayanthi: yeah I mean we're fine to wait uh we still are missing a couple of happy case um asserter tests so we'll probably just be working on those in the meantime

Alex Stokes: okay cool but it does sound like soon we be ready with DEET one which is super cool anything else uh on debet one there for pectra there was a call out on the agenda for 7702 so we'll move to that

next unless there's anything else more broadly with pectra that anyone would like to discuss okay so let's move to 7702 to so I think Tim had this on the agenda just to ask for General updates uh I think the there were still some open questions around the EIP that would uh kind of be blocking its inclusion in Petra that being said I think we have some updates on those open questions uh maybe like client uh if you'd like to call out this PR that you had linked

hello

hello

Lightclient: uh okay I just posted the link to this PR in the chat basically this is something that we've talked about uh offline and in the last breakout call people were mostly supportive of this change both on the wallet side and the client side the tldr for those who haven't had a chance to review we're essentially changing 7702 to be less of a ephemeral deployment deployment of contract and more of a deploying a contract permanently more permanently into the EA's code and it allows the EA to continue operating as an EA because the

code that's deployed in their account isn't exactly the code which the user wants to delegate to it's a a designator that has a prefix and then an address to the code which the user would like to delegate to so that sort of gives us the ability to see that that EA is a special type of account that can both originate transactions and act as a contract this lets us get around the Restriction in uh 3607 I think where we banned e EAS with codee from originating transactions it also helps us get around if fundamental problem that we've had since

374 which is dealing with these permanent authorizations and replay protection and authorizations the fundamental problem there was that to get the functionality that which we felt was really important which was things like signing one message and then reusing the authorization over and over again required us not having replaced function uh replay protection functionality in the authorization this circumvents that by instead of the permanency of the authorization coming from the message it's being stored in a place in the account and that feels like the ideal path so now not only do the message do

the authorizations get to have the nons and get to be only single use but potentially tools like other wallets that are interested in acting as the eoa because maybe the user has put their private key or their neonic into multiple wallets they can then just look on the chain and see if the account has already delegated to a specific um to a specific piece of code so I think that this is addressing most of the concerns that were outstanding if I'm missing something someone please chime in but I'm curious how people feel about this and if people feel that it would be okay to move towards the merge this and move towards

this for

devet too

Ansgar Dietrichs: yeah I just wanted to to briefly expand on what met just said um because on the breakout call we discussed with at least the people present there in general feeling there was that indeed this PR would be a really good candidate for uh basically definite two um with the one caveat just being that um just everyone should should be aware should should understand this as like given that 7702 is so new we're still iterating towards the final spec like I don't think it's very likely that this PR will get us quite to a final spec yet for for for pectra and so smaller

changes might still be coming we already discussed potential ones uh it's just that we we all agree that it's likely that basically this PR gets us significantly closer so it's seems like a better Target for for a definite 2 than the old spec but just for people's expectation that there will be future small changes by in know likelihood to

IP

Alex Stokes: okay uh there was a question in the chat uh it looks like the chat is there um Daniel

Daniel Lehrner: yeah I was just wondering um because we said that we are going to

move def at one maybe one or two weeks uh in the future does it make sense that we Implement directly the latest version of 7702 so the one that is proposed right now or should we still go with um with the original one

Alex Stokes: I would say to keep it as is uh just because this latest PR is not merged yet and there could be some last minute feedback let me go see what was in here so yeah the deet One specs just link directly to the EIP so I would just Target that as as unless anyone else would like to argue for something differently right

now

Lightclient: I I feel we should have devet one ASAP but I don't think we should change devet one necessarily

Alex Stokes: yeah that makes sense to me

so

Lightclient: I think like most most clients have already implemented everything more or less so it's not like clients haven't implemented 7702 at all

right okay ium

yes has actually implemented it so we have it

Alex Stokes: great

Lightclient: so is there any feedback on including this in devet 2 like seems

like we're talking a bit about about timing but it feels that most people are generally positive on accepting this for devet 2 whenever that ends up being

Alex Stokes: yeah I would lean towards just getting it merged first and then we can discuss scheduling

Lightclient: but I mean it's because we're waiting to include inet to okay like I can merge it right now all right unless someone feels

strongly or says something in the next six to 12 hours I'll merge it at the end of today and we should plan on doing that for devet 2

Alex Stokes: okay yeah sounds good and there doesn't seem to be any negative feedback so let's move ahead with that plan

Danno Ferrin: um consider for a moment the most Americans out are on vacation should give a couple days for people to reply in chat before proceeding but I think a couple days is fair

Lightclient: they've had a week and a half

Danno Ferrin: true but you're actually pulling

the trigger here couple days would be nice

Alex Stokes: yeah I don't think we discuss this on the last ACD so you know process wise it would make sense to give people some time a reasonable amount of time after say announcing on the call but generally I think moving towards DEET 2 makes a lot of sense cool uh so I think that was it on Petra oh maybe this do up the next thing actually uh but yeah is there anything

on 7702 uh otherwise we will go to the next EIP 7212 which I think is the R1 curve

Lightclient: I think the last thing on 7702 is that if we're moving towards changing this spec for devet 2 I'm curious what people think about our testing strategy for 7702 and devet one like we do have some tests but I'm not sure if we're planning to build out more or if people are comfortable sort of leaving testing where it is for de one on 7702

Alex Stokes: can we just test common subsets

like whatever would apply to devet one and also devet 2 we could just focus on for

devet one

Lightclient: I don't think that there's as much common subsets like there is still a transaction tip we are still setting these authorizations I'm I'm just not really sure like what test would work in both cases

Alex Stokes: gotcha so yeah I mean if it's going to change and kind of be breaking in that way I would probably say just to test like whatever test we have now we'll use for DEET one and then otherwise we'll focus on devet 2 for

DEET 2 okay uh thank you for that everyone please take a look at the pr 47702

uh next we had a topic for EIP 7212 so this is adding a precompile for the SE p256 R1 curve and I think there's a few

questions here let's see is Andrew on the call you had the comment I look looks like you are yeah would you like to give us a little uh context there

Andrew Ashikhmin: yeah I think there was a discussion on on Discord and um that e was CFI and it's also used on on polygon already um and um because it's CFI basically we need to decide soon sooner rather than later whether we deliver it in pectra or not and if we do like do we actually take what's already on polygon

or do we Implement a slightly different version of it using because on polygon say the promile address is uh like uh 256 or something um and um so it's not it's it's in the range reserved for l2s as far as I understand yeah and the question is whether we keep that or or modify it somehow for ethereum

Alex Stokes: right is that the only difference between the rip and the Eep is just it's at a different precompile address

Andrew Ashikhmin: I think somebody had a comment that the return value is um unorthodox

like it's not aligned with what the other pre compiles do but I don't remember who that was

Alex Stokes: okay yeah how how do clients feel uh this would pretty much be a purely e change so how do any clients feel about uh the CIP Daniel

Daniel Lehrner: yeah so for B we we are definitely in favor of including it I mean it's in the end every mobile phone is uh supporting the this EC curve so it's like every most user already have like a built-in

Hardware wallet for us it definitely makes sense to to allow them to to use that instead of a traditional one so I think for for ux exit would be great to have it

mhm my Cent

Lightclient: I think on gu we're generally pretty positive like adding the R1 curve is pretty easy since we already have the K1 curve I think in general there's just still questions like why at another cryptographic pre-compile is this the right cryptographic pre-compiled to add you know we I think we would feel a little bit better if there was more work towards something to allow people to write their own efficient cryptography

in evm that's something that hasn't seen a lot of progress in the last year or two and there's still questions about like what address to use we sort of carved out an address space for rollups and now we need to figure out are we going to use their the rollup address space for pre-compile on meain it or are we going to deploy it at the regular address and there's reasons to do both

Mark

Marek Moraczyński: we are in favor of including

CP Great Dan

Danno Ferrin: so to address the why not do generally in the evm um there's a

proposal called evm Max and that's not shipping until at least Amsterdam so if we want the r curve anything sooner in a year and a half to two years to three years out we just need to ship it as a pre-compile so that's why I support it even though I think the correct solution is move it all to evm it's not going to ship in reasonable time frame

Lightclient: right but even if it's not going to ship in a reasonable time frame is the R1 curve the right curve to be shipping like some people are saying that the R1 curve is already starting to be replaced with Edwards curve

Danno Ferrin: um there's broad support for the r curve in a lot of places like um Pass key from Google so I I'm I'm satisfied there's always going to be new curves

and when Ed curve is ready I mean there's been a proposal for Ed pre-compiled but we could probably do an evm One Max it'll probably be relevant then when Max is ready

Alex Stokes: yeah personally I think there's enough value around this curve given its broad deployment in all these different contexts that it wouldn't quite make sense to block on something like evm Max although generally there is value in evm Max um but yeah it's unclear what those timelines will look like it looks like the EAP has the pre-compile address at you know the typical one meaning like the next lowest address fore on ethereum in evm and that does sound like something

we need to resolve if we want to keep that or mere what is used stay on l2s uh there was a comment in the chat to please please please please keep the same address in both places uh Matt like Cent you have something else to say or was your hand up

from com

Lightclient: yeah I mean separately from the specific concerns about R1 I get it's not a difficult thing to implement but Petra is already Mega and at some point we need to ship Petra and stop adding things and it feels like we're already way past that point so I feel a little bit weird that we're trying to add things where when we're

like talking about when to ship the second dep net of this Fork again it's not again it's not like a big feature but eventually we have to just stop stop and ship and there's a lot of other things that we want to do that aren't in the hard Fork that aren't really being encoded like doing history expiry uh maybe improving the situation with the public men poool for blobs that we just have no bandwidth to do because we are spending a lot of time figuring these Forks out so R1 is kind of a I don't know a little bit of a different thing since it is very easy but generally I would prefer to reduce the scope of pectra and focus on some of

this other stuff including like not accepting R1

Ansgar Dietrichs: yeah I just wanted to briefly clarify with the address so um in general because this is the very first time that we shipped as a pre-compile as an rip there was a little bit of confusion on on the the the procedural parts so specifically because this was first created as an EIP um right now we just copied it over as an IP so the IP has the exact same number noral in normally we we basically don't want like those should be this should be one uh yeah address bace e IP address bace so so so

basically the idea was to just delete the EAP and then create create one with a new number if we ever want to bring it to mainnet we just never ended up doing this but uh this now means that we we in this weird position where basically the EAP that still exists at the same number is now in an outdated version so if you go to the IP with the same number 7212 it actually for example had is now at a different address because that's the address where it was actually shipped on layer twos which is the the first available address in the layer 2 specific address space that we reserved a couple months ago I decided to reserve for l two use a couple months ago on orfs um so yeah I think we should basically just ideally if we if we decide to add this to Spector we should

use it as an opportunity to really make a general decisions around how we want to handle these Layer Two first features in the future um if if we may decide to make any spec changes to to the IP whatsoever um so for example there have been some concerns about the return value of the pre-compiled that it doesn't give a return value instead of giving a zero return value in terms of in in the case of a verification failure so for example if we wanted to make that change then we should definitely ship it at a different address because it would deviate from the layer two version if we want to ship it completely unchanged I think we should make a general decision whether we want to always in these cases retain the layer to specific address or ship it at the lay one specific address

um and then also in that um connection should make a a final choice on how we handle this IP EIP situation I think my preference would be to just completely delete the EIP because it's outdated anyway and has the weird numbering collision and then create a new EIP that at at a new higher number whatever the first available is today and just copy over the spec um but yeah so so just to flag that there are these these open questions that we would have to solve

right Adrien looks like he I maybe

disconnected uh iPhone whoever that is oh sorry I was muted oh sorry yeah please go ahead

Hadrien Croubois: yeah so sorry uh I wanted to give a user perspective here uh uh for the record I work at open zeppin and we just merged a library that supports the verification and the recovery of R1 signatures the demand for that comes from the account abstraction word where people want to be able to use 437 and other ACC abstraction systems uh using smartphone as Hardware wallet basically uh and the way we implemented it is we have a solidity implementation and we also have a version that checks the precompile from RP

7212 uh the solidity implementation is way more expensive and if people could avoid pending that code that cost that would be better so far our implementation tries to go to the pre-combine and if that is not successful then we go on to the solidity implementation we have big concern about this feature being available on multiple chain at different addresses in terms of precompile because we think think that for User it's better to not have to write code specifically depending on which Target chain you are targeting and changing the pre-compile address depending on what you're targeting it should be better to have one sing version that works on as many chain as

possible and unless this code start checking multiple precompile one after the other before then falling back to solid implementation it it would just be better for all the user if there was one address that Library could go to I understand that from a client perspective it may feel they may feel differently but from a user's perspective people that are going to write code that use this precompile it that functionality is better if all chain provide it in a similar way

Lightclient: yeah I think I generally agree with that I think maybe the only the only argument I could see against it which is

probably not the best argument for R1 because it's so simple but there is a possibility that we get into a world where we need to change the precompile and if we have the rollups pre-compile that they've decided upon and on Main net we end up needing to change it whether it's in the fork that we originally Shi it or in a later Fork now we have maybe even a worse problem which is the same address being used for two different

uh promiles

Alex Stokes: yeah iPhone you had a comment yeah I was just going to ask

about the Readiness of R1 in the client libraries I think most oh yeah go ahead yeah

yome

oh yeah sorry uh like I've just been searching but we do not have it implemented uh and it also does not seem that there's a quick JavaScript banging so I'm not really sure how long this will take

but that's just sing

Alex Stokes: Marius for us it's it's part of the go standard Library um so the implementation is uh really easy just add the guys costs and um that's it and

we also have a PR for already from someone um who proposed it for the for RPS um in general I'm in favor of it it's just yeah I think there's an argument to be had that we like it's nice that the the rups did this first um and so I don't know if we actually need it that much on mayet no one is really doing these kind of things on mayet anymore um using like uh smart contract

Wallets on mayet um and it's not because it's um it's impossible or anything just because it's too expensive anyway um so I don't think that adding this precompile uh will really change that um at Le in my opinion I think it's it's great that we have this on on rollups and people can use it on rollups um it feels again like like one of these things where we uh I don't know I'm I'm try in my view we should uh focus on um getting functionality and stuff

onto um onto rollups and um focus L1 on uh blob scalability um and and these kind of things and and not focus too much of the uh uh like evm feature set on every one but I would be fine either way okay okay Richard uh Richard you have your hand up

but you're not unmuting

a damn it

Richard Meissner: sorry forget to unmute the typically unmute for I wanted to say um from the standpoint of safe right like since we are one of these smart contract wallet projects that we would like to do stlees on L1 right like because at least currently a lot of liquidity a lot of teams are still on L1 they are still there and this is where in the at least in the current state L1 is not perceived as this we want to move away from L1 if we as an ecosystem agree on this I think this would be a little bit of a mind set shift which I'm not generally against but it's at least not the agreement of everybody in the ecosystem we had this discussion actually in one of the AA breakout rooms where it was not that clear that

everybody agrees to yes let's move away from um L1 where L1 is just basically this plop space um layer like this rollup Shain right like and this is where and unless we agree to this there is still a lot of Valu where a lot of teams are still on L1 and a lot of teams do prefer also to have better U and R1 will Pro will just enable this just as a general context there

Alex Stokes: okay thanks uh so ongar has a proposal to move forward on this point um it sounds like there's like a few

things we'd want to do so then I would suggest doing those things and deferring the actual inclusion decision to the next acde um just to Echo some other comments in the chat because I have the same view like Petra is already very very big and we should really be deliberate about including more at this point okay uh let's move on then so oh

actually Andrew had one other comment here let's just knock this out quickly uh the question was if we can Sunset goray so I'm not sure uh he had the question if we had like a Blog announcement or something like this I don't know if Tim was planning to do anything there um in terms of following up but generally my understanding is that clients already have started to deprecate G uh gor support so yeah should be fine to drop from your client and uh we will wave goodbye

Andrew Ashikhmin: and click is not used anywhere like for Hive testing or anything like that because girly you us just click and

with girl going with can potentially remove click as well

yeah I think the testing is

sorry

Marius van der Wijden: yeah we already started removing click from

from gu C pleas so

Alex Stokes: okay no more Gorly no more click great so then the next agenda item was a proposal to change the pre-

eploy uh we have these like system contracts or various functionality uh in this case that goes from uh when we want to move information from the e into the CL there's two eips that uses type of functionality in pectra 70002 and 7251 uh let's see I don't know if PK is on the call yeah would you like to uh give us a summary of your proposal yeah uh hi everyone um as said I would like to suggest a small change to these both contracts because uh right now both of these contracts do not trigger any event on successful

invocation and the problem is uh while this is technically not required for the new um functionality to to transfer this um to proce the information it makes it really hard for external toolings like explorers to track back the origin of these execution there triggered operations so if something uh appears on uh consensus layer we would like to trace back where this uh operation comes from so which um transaction hash basically triggered that uh operation and for that it would be really helpful if both contracts could trigger an event that the Explorers or external toolings

can simply follow on so yeah that's basically the request there thanks uh let's see are any of the authors of this contracts on the call maybe they could Chim in

Mikhail Kalinin: yeah um I I think we have discussed this uh before and this change makes sense and it should not result in a big spike of in gas cost for the smart contract call so makes sense to do and I've been discussed this with L client

previously and planning to to have this change one one of the concerns might be that they will produce logs for um just more chain date historical chain data but it should not be a problem soon and it will be expired but it would also align it a bit with the deposit contract because we have to uh lock uh there and we are basically introducing new operations that are triggered on execution day without that doc event so yeah it aligns it a bit to both contracts right I mean I I think we should just

work on it if there is no um other opinion and opposition

Alex Stokes: the only thing I would ask is just like you know again if we keep changing Petra Petra will never ship so there's some argument for leaving it as is just because it's not critical and invariably it will delay other things um yeah I do think this is like a pretty small change in scope so it's not the end of the world

Mikhail Kalinin: yeah for fortunately um this is handled by the smart contract itself so we just need to to modify smart contracts and then uh deploy a new code to the next devet so it should be quite

opaque to client development process right the only one thing probably oh no it's yeah it's going to be a regular call where and client will handle those log messages as usual log messages

logy panss sorry

Alex Stokes: okay so then we need to update the predeployment but generally sounds like uh we're all on alignment

here cool so next up on the agenda we have EIP 158 deactivation I think Yom has an EIP or at least let's see this might just be a PR2 158 yep yeah would you like to give us an overview

can you guys hear me yep yep

Guillaume Ballet: um so yeah a couple comments before because people started giving me feedback so as it turns out it's referred to as 158 inside the the guest code but it's actually EIP 161 so thanks for catching that um and yeah the as a quick reminder we already had a conversation about it oncd

a couple months back uh the one of the things that was being said is I should create ANP to to support this so I did uh it's EIP 7733 um and it's uh about uh deactivating yes EIP 58161 um so it's actually not the whole EIP that needs to be to be deactivated it's only the deletion of an account if it's code hash well if it's the empty code hash uh if the balance is zero and if the nons is zero um that is impossible to do in veral simply because an EA could have some storage

slots and in veral you cannot figure out uh which where an account slots are so that needs to go it's the same reason why self-destruct was removed or nerfed uh we have the same problem that can happen in the context with 772 in which uh an account account um has funds so a non a non-zero balance uh an EA has a non-zero balance so it has an empty code hash and uh it's got uh an empty Nots so it's just the result of a a transfer then with 7702 someone can

call into this account execute some code and the code transfers all the funds to a different account in which case the EIP uh 161 I have to get used to it uh the EIP 161 rules say you have to delete the account which is not possible because like I said and just to clar to make sure it's it's clear um if you execute the some code you could potentially create some storage slots so there will be potentially State and you will not be able to to find it um so yeah the the simplest way would be either to to set the nons of that account to one or to deactivate the IP

161 uh the proposal is about deactivating EIP 161 and uh yeah that's pretty much it oh yeah there's one extra remark about it uh it's that why why am I talking about it in the context of Prague we already had a conversation about it and initially I thought well we probably don't need it for Prague but there's one reason uh um to to include it in prag is and that is if uh people want to give some push back against the overlay myth method in the future um that means you will be able you will have to replay like to do the conversion at a given block height and replay blocks in a what I call a

counterfactual history until that replay chain becomes the official chain if during that period between the conversion and the replay and the and the Fork uh one of those things happen uh one account gets deleted that means you do have uh the existence of a deletion happening in a in veral mode that is going to be uh what that's a potential bug um that's a potenti that's potentially breaking the conversion and so I think it's safer to it deactivate at the fork before if we want to do well if we want to give some push back on the overlay method I am a

proponent of the overlay method so personally I don't care but I want to make sure that everybody knows that if you don't uh include this EIP in Prague you're effectively uh canceling this uh like removing this possibility uh yeah that's pretty much it

okay thanks uh yeah by Cent

Lightclient: I was just going to say this isn't really a problem with 7702 after the spec change so I think we should focus on this for its merits of veral since it's

not related to 72 now

Guillaume Ballet: okay so I'm not aware of the change in the spec but that means this could no longer

happen

Lightclient: yes

Guillaume Ballet: uh and what was the for my personal

edification

Lightclient: now with the new PR for 7702 the off message is consumed by updating the accounts Nots so the off message is only valid for the kns it's signed and then once it's consumed account nons bumped so you can't have zero nons accounts with code

Guillaume Ballet: okay cool yeah that's that works

I think in general we can accept

this e right because currently this whole situation of deleting these accounts is not really uh like empty accounts with storage that's not really possible anymore right

Guillaume Ballet: it's not currently possible yes and in fact come to think of it if the 7702 EI no longer uh leaves the nons as zero then there there's no problem to begin with so we can even withdraw the EIP Al together which is fine by me

Alex Stokes: okay so then we do not need

7733

Guillaume Ballet: nope

Alex Stokes: okay great okay that was easy uh that was it on the agenda for today is there anything else we'd like to discuss otherwise we'll go ahead and wrap up a bit early today

is

Potuz: I just wanted to Shield that we have a breakout room tomorrow for 7732 this is the number four and the agenda is kind of ped so if you're working on epbs uh come tomorrow and if you're not take

a look at 7732 that is already open and the CL repo has is an only C EIP and the repo has the pr

Alex Stokes: great thanks yeah I uh dropped the issue for the breakout call in the chat it's 1083 uh if you are interested please attend my client has a question did Gom have more to discuss on system contract

Guillaume Ballet: uh yeah good question uh not really I mean maybe just announc that we

we reached an agreement um so yeah uh there is an update to the EIP I made an update PR to the EIP to say to say in Prague everything behaves like uh everything in 2935 behaves exactly like 4788 um and then there's another EIP to talk about how things change but once veral is activated so that is uh that is a bridge that we have to cross when we get there um yeah no need to to hold pru for this

Alex Stokes: okay and there's a little more

discussion in the chat are we 100% certain there are no mainia accounts which are empty but which have storage

Guillaume Ballet: I'm not sure if that is going to impact 7733 um so there's actually um a few that were created before um before EIP 161 uh but we agreed on some call sometime ago that during the conversion those accounts will be deleted so yes then we will be sure unless a new mechanism gets introduced of course that will be able to create those those new those new accounts my understanding is that no we cannot uh we cannot create new new empty Accounts at this time or

in

prag

Alex Stokes: okay uh like client would you have do you have some things you'd like to bring up around Petros scoping

Lightclient: yeah I mean I feel like we are we go through phases of being heads down focused on fors focused on death Nets but there are these things that don't have the strict like devet deadlines that don't have the strict hard Fork lines which are important and we aren't

discussing them that much and I'm just like hoping to maybe get some more clarity from other client teams about where these things stack up in our priority list I think history expiry is something that is super important and we talked about it at the interop and it felt like we wanted to move forward with it and I haven't really seen a lot of work or thoughts or progress on that since then so do we need to like start implementing a portal like what's the next step here should we have a call where we have updates about what we're doing and try to do some Dev Nets like I really don't know and another thing that I think is not being

talked about really at all that is important is that if we're going to be doing pios and increasing the blob count and pcture some Fork soon after then we need to have a a better idea of how to deal with blobs in the public transaction pool because we don't want to just two or three x the total blob count and do nothing for the public M Pool because then the public me pool will eat away all the bandwidth improvements that we got from pios so these are things that I think we need to yeah and Mario s right we also need to revamp some things if 7702 goes in as it is so there are there's a lot of stuff that we need to be working on

and we're just talking about like surface level EIP is going into pectra and so it would be good to hear when people want to start talking about these other things and when we might expect some of these things to be updated I see everyone is very excited to talk about these topics

Łukasz Rozmej: uh so late time we uh are

experimenting with portal Network integration uh we have a developer working on it at the moment but we'll see how it goes it's like a experimental uh research right now

Marek Moraczyński: okay I'm about Ira exports import we are working on it as well so generally we are working on History expire

Lightclient: sweet how can we like surface more of the work how can we I like I feel like this is an important priority and I think most other people agree it's an important priority but I don't think that it's receiving the same

attention at least on this call as if it were going into a hard for what's a better way to make sure that the progress is being surfaced and that the progress is like sort of being forced Like For Better or Worse we do have a bit of a call driven development cycle and maybe that just means that we need to talk about our progress on History expiry every alore devs I'm not sure if people have other suggestions

Marius van der Wijden: I think my so my biggest problem was

that uh we don't have the scope of Petra tied down and since we don't have this we cannot really focus on other things um because we're still working on S on stuff that might go into Petra or might not and um maybe it would be nice to say we sto now we go with this spec that we have right now we ship it on definite one two three whatever and um and this gives us a bit bit of PR breathing room to work on other stuff as well um once once the stuff is on the death Nets it's not that much time anymore that we have to

spend

what is yeah

Potuz: so regarding blob transaction uh propagating uh I have a general comment which is goes a little bit beyond ACD but but I think it's it's probably a mistake to try to start looking into changes to the protocol without having all the information at hand I sat down at a war room on a rollup of a major rollup and I saw how the gas price was spiking even though the base fee was still at one way and this happens when you have a series of builders for example that are averaging three blocks per per block and home stakers that are actually committing the six blocks uh transactions and we have data for that

we have data that hom stakers are sending more blobs and Builders this breaks the 1559 Market that uh that we have for the gas that that price so if we don't have really good data onto how this Market is working how are the transactions are propagating and even how the the the miners are uh are calculating the tips because we see transactions with lower tips that are getting included before transactions with higher tips then it's very hard to try to think that we're going to solve this here at the protocol level we probably need to have more data on how the market is actually working today

Mark have a

comment

Marek Moraczyński: I want to just ask my client did you guys start working on something related to blob takes pool for p d or not yet uh we are not working on that right now but uh we will start if you are exploring

Lightclient: yeah we haven't started any development of anything I've basically just been having some conversations with mostly with Piper since he has looked into this idea of propagating transaction within the portal Network and like as you know in the portal Network you have very light nodes who only have a very specific view of the network and so he sort of come up with

an idea of having an over basically an overlay that says where to propagate certain transactions to and that feels like the right path at least for blob transactions where you sort of based on your node ID you know where you know what um transa like what transactions you're going to need to keep track of and it's I don't see a necessarily A blocker for it I think it's something that we just have to implement and see how if it works okay but I just don't really know like when to do it because you know we're we have a pretty high Cadence of pectra Dev Nets and adding things and it would be good if we had a way

to make room to work on this stuff that isn't specifically Fork correlated that needs to be done and that's kind of what I'm like trying to figure out is like what is that thing because it's really nice with the eips because we got the dev Nets the EIP numbers the testing team makes some tests and then we can just run it in cryosis or we can run it on the devet and that's like forcing us forward but a lot of this other stuff we just these are just ideas and we just keep saying this is important but we don't make a lot of progress on them cuz there isn't the forcing function

Alex Stokes: so is the answer more

breakouts

Lightclient: I mean I don't think it's just a more breakouts like I think that we need to have something at the all qu dev's level like I think we need to be sharing updates on how things are progressing yeah probably we need more breakouts to discuss and move things forward but I also feel like I mean it needs to basically be a requirement it needs to be something that is part of the dev Nets like clients are implementing the old version of 7702 because it's in the devet one spec and if we didn't have these things if it was just more free flow like we probably wouldn't have started implementing 7702 and you know we would just like start looking at this new vers and yeah you know there's a little bit of extra work that's done there but it

like it is forcing us to like move things forward and it is forcing people to get the context they need to like make more informed decisions I think right now everybody is saying these all sound great but we don't have enough context to make like really good decisions and have technical debates whether it's in a breakout here or E magicians and so we need to like be building that up so I kind of feel like if we really truly want to make progress on this stuff then we need to start saying like okay here's a devet Target that's going to have this functionality let's start working on some tests to make sure that that functionality is working um and you know not move forward until those things happen and I think part of it is you know even if we do have those things there's just like a finite number of

people and time to do this stuff and we're like pretty saturated with pectra so I would I would like to maybe to talk about either if not capping pectra then even reducing the scope with Petra B from what it currently is because at this rate Petra will not ship this year and if it doesn't ship this year then it will ship sometime next year probably without these things like history expiry and uh you know improved blob transaction propagation so then that stuff will only B start bubbling up like mid to late next year

Alex Stokes: yeah

I yeah so I agree but with history expiry if it's not a hard fa it doesn't seem like there is any pressure to get done I mean yeah with history expiry like it is an eth wire upgrade so it feels like something that we should be doing in a hard Fork like no we can do it without a hard Fork but because we are going to bump these wire for the requests anyways we might as well bundle these things together is has been my opinion and you know part of it is like me not pushing forward these things and like updating these specs and making them happen uh but like Again part of the reason is because there's been a lot of work comp

pectra instead okay yeah I think given that you said that it probably would make sense to have another breakout room because I thought it would just be sort of a add-on to the nodes at least that's one of the ideas that has been going about so it wouldn't actually affect anything to do with the normal P2P network

Lightclient: is anybody interested in capping this per Petra or reducing the scope or up

only

Guillaume Ballet: well it's not do up I am interested in

the Andre

Andrew Ashikhmin: uh yeah uh I think if we start revisiting our decisions like for no good reason then that's a bad practice so we we've been discussing the scope of pectra quite a a lot and I don't think it's it's a good thing to regurgitate the same discussions again and again I I am fine with not uh increasing the scope of pectra but I'm totally not fine with

kind of revisiting and uh reducing it for all good reason

yeah

Guillaume Ballet: uh yeah quick question uh if we don't need a fork for uh EIP 4 Force why not just let people Implement like what's preventing us from letting just clients implement it on their own time like some clients might be able to have it right off the right off the bat will take years but that's fine what's is is there something blocking us from

Lightclient: well I think we need to have a e wire protocol that says I'm not going to have that historical data because if we were to

just ship it in the current eth wire protocol you're going to have very heterogeneous set of nodes where some notes have the history and some notes don't but there's not an identifier in the handshake that sort of says do I have the history or not and there's been proposals about like having an identifier this says how much history I have uh I would prefer to just say whether or not you have the like one year of history as like this binary thing but yeah I think that we have to have some way of saying that so you know it doesn't have to go into a hard Fork but like yeah if some node if if gu implements it and no one else does then it's going to be harder for those nodes that are still full sinking the history to go and find that history

because you know there will be less nodes on the network to serve it to them wait I thought that if you didn't have the history you just proxy to the portal Network so nothing really changes I mean you can't really proxy to the portal Network for Network queries because the portal networ isn't really designed for these range queries that the the PTP would request right right it's more for if the RPC receives a request for like oneoff blocks then it could go and get that one-off block but if you're if the node request for like 10,000 headers you're not going to want to download 10,000 headers from Portal

Alex Stokes: Marius

Marius van der Wijden: uh yes this is unrelated to uh

the discussion that G and mat just had but related to the discussion that we were having in the chat around the blob transaction uh one thing we noticed uh basically today is that um the there are some issues around um the order in which we uh transact uh we propagate plock transactions um so what we need to do is we need to propagate the block like if if uh BL transactions arrive at our note in a wrong order we might actually throw some of them away um and that leads to

issues if a rollup sends multiple blob transactions um we operated under the assumption that rollups don't need to send multiple blob transactions per block um but apparently some of them are still uh doing it if it's uh might be out of uh um out of buxs or out of necessity um anyway we uh we need to make sure that we are sending and receiving blob transactions in the same order um in Mons ordered order um so that we don't throw them away um in the in the transaction in the

pl transaction Port just um just an FYI to um and and we are not doing that in G there's a there's a bug right now um where we are not receiving them in order and so we might actually uh throw some of them away um so yeah this is something that we're going to fix and it would be good if other clients also took note of this and and checked their block pool implementations to make sure that they are also only sending PL transactions and receiving PL transactions in in nons order and this will make PL block propagation quite a bit less painful because you don't need

to resend block transactions um all the time

Alex Stokes: okay so there's a client issue to be aware of but then also block users should be careful about how they send the transactions as well

Lightclient: yes they they should be aware that if they are sending uh multiple transactions um that these transactions might arrive at the at other noes in the wrong order and so some of them might be thrown away um because we only allow nonordered

transactions and and not uh and U transactions in the block pool so that there we only allow transactions that have no nons scap um in the block pool not in the in in the normal transaction pool it's fine um but in the block pool it's not

Alex Stokes: right I mean I guess how would you know as a roll up or like you know let's say I'm making a blob like I might not necessarily know that there's a NCAP somewhere else right you should know it because you know which which nons to put into your

block transaction so you know that there was a nons scap to the current state if you have okay but that kind of implies I need to either only make one transaction at a time like I I essentially have to wait for if I make a transaction I have to wait for it to be included right I can't make like three four five you can actually make multiple transactions just that uh so what people kind of tended to do is basically wait a couple hundred millisecs between sending them out so that the previous one has time to propagate in the case of blob transaction it it might take a bit more it's definitely something that we will uh attempt to fix in gu but

um it's still uh so the problem is that the transaction announcement protocol is very dumb it just says that hey here's a hash and you do whatever you want with it so what we can do in get we can make sure that we download announced hashes in in the order that they have that we have have received those announcements but we have absolutely no idea what those hashes belong to so we don't know what order we should download if if we have I know 3,000 hashes which one of them are I mean okay we know which one of them are blob transactions because we also include that but we don't have the nonsense we don't have the accounts so we can't actually prioritize or sort

downloading the blob transactions in order so um even if we we take care to do a better job in keeping the the announcement orders that we see the hashes in there's still no guarantee if if some other client announces them in a bit yoy way so Gap does take care not to announce them gapped or out of ordered but we can't really rely on other clients doing the same thing so there's always there can always be some weirdness there but that's a that's a whole new can of worms as to what could be done with the transaction propagation to make it more stable

so

Alex Stokes: right yeah I wonder if you could just

include the kns along with the announcement

Péter Szilágyi: I mean the thing is you need to include nonce and then you need to include the account but the problem is that you cannot really verify it until you download it so I mean it's still somebody can still feed you feed basically I can just watch what kind of accounts are announced on the network and just try to clash with fake announces and fake addresses so it's like it's kind of hard to make anything that's really robust

Alex Stokes: yeah that makes sense do you have your hand up from earlier or was that

resolved

Potuz: uh just wanted to mention that that batch posting on a rup is quite complicated and you change tactics on the run as other rollups also are changing their tactics if you have a transa if you're posting batches at six blobs per transaction and you see that none of your batches are being posted because some rollup is posting and paying more and posting only one blob and then the Builder cannot include a transaction with six blobs because they already have that one blob there uh then rollups start like resending batches with less blobs uh so I'm not saying that get should do this or do that but definitely there aren't that many users of of blob transactions today okay and those are the guys that are being

affected and rollups are being forced to try to talk to the relays to see how are they going to get their transactions to the Builder because the mol the public mol is not getting those transactions to the Builder so this conversation should be happening with the rollups and not among ourselves only I I feel like there's this thing that g is doing something to protect the mol and I understand I mean there's a Dos attack there but then on the other hand there's the users they dar that many users and they have their own problems into and they they try to adapt to whatever get the size of the mold should be and this conversation should be happening with them

Péter Szilágyi: yeah fair I think we would be

curious to know how rollups operate I mean how they send their transactions and what they would like support and not supported so I think that's a perfectly valid we're open to that but again I don't think it's fair to say that uh G needs to do this uh I think basically all El needs to be aware of these and do it properly

Marius van der Wijden: I also don't necessarily agree that we uh we need to talk to the rollups I think it's kind of we are not

providing the service that we are claiming um and so we need to fix it it's not really yeah like we we we should we should do something about it and we are going to do something about it but I just wanted to mention that that there is some issues there

Péter Szilágyi: yeah for sure so this is something that that affects the the normal transaction pool too in a bit so it's it's an issue we're going to fix it but I'm not entirely sure that it's going to make too big of a difference but we can definitely see

I

Alex Stokes: let's go ahead comment in the chat

that essentially Ro should think about how many blobs they put per transaction if you have a transaction with six blobs uh it becomes this like very bulky thing to pack in alongside other blob transactions and if you go

Potuz: there's a lot of literature to this this is not something that rups have been thinking about this way before we shipped 4844 they have a lot of literature as to what is the optimum strategy and also like depending if there's two three players posting at the time rollups know much more than we know about how to post batches the thing is that there's also this external constraint which is how the public mol actually acts and that breaks the assumptions of that uh body of literature but I would

say that the rollups they know much more what what are the better strategies for batch posting than what we know

Alex Stokes: maybe I mean if you if I make a six BL trans action and then there's some like M pole issue that means I don't see it in time you know like another rollups transaction then I just wouldn't know right and I think if you take this to the Limit like you should actually only put one blob per transaction because that's the most flexible way to pack

Péter Szilágyi: so another thing that I think people need to be aware of is that six blobs means uh 1 Megabyte of data what

is it one megabyte but maybe a little less uh little less but uh essentially that's a huge latency to to propagate over the entire network so yeah it's it's kind of we're entering in this weird territory and there's a there's also this talk that people would like to even further increase um incre increase the capacity of of block transactions and blocks but yeah uh I mean it's probably not really super healthy to create transactions that are that heavy because they just strain everything through the entire

Pipeline and then weird things start happening

Marius van der Wijden: so your suggestion would be to increase the maximum number of blobs in a block while keeping the limit of blocks per trans of blocks per transaction the same or something like this

Péter Szilágyi: no I'm not suggesting anything I'm just saying that it's it's another dimension that people everybody needs to be aware of that latency starts to play a role here

Marius van der Wijden: yeah but I I'm suggesting this now um that we should think about whether we want to

limit the number of PLS per transaction um with a different limit the number of BLS per block

Péter Szilágyi: I like a limit of one okay

Alex Stokes: no

what uh yeah I just going to say that uh yeah it looks like there are plenty of open issues with Bobs so yeah everyone keep keep thinking about it um generally the the feature and Market is immature so so you know we'll work out these Kinks as time goes on is there anything else uh we have a few minutes left on the call I don't think there are any other agenda items for the day okay let's go ahead and wrap up then

thank you everyone

thank you thanks bye bye

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