All Core Devs - Execution #195

Transcript

[Music] time Jes okay we are live welcome everyone to

acde number 195 uh I'll put the agenda in the chat here there's a bunch of stuff to go over today um updates on the dev Nets um lots of uh specific updates or proposed changes for 7702 um one uh sort of uh issue that was brought up around eof around ex Cod size and delegate call um and then getting some updates on the def Nets there and then lastly there were two more uh proposals for changes Rel related to the stuff that already in pectra so uh one for EIP 7251 um and then one for the engine API assuming we get through all this then

there's three uh proposals that um we have on the agenda uh the first is a 7623 uh which we CFI for Petra already increasing the call data cost uh in certain cases second is 7742 which is about uh having the blob count only Set uh on the CL side we discussed this last week on the CL call and then lastly uh there's pre-ip idea around raising the reserve price price for blobs so hopefully we have the time to get through all of this uh maybe to kick us off uh Barnabas or Perry do either of you want to give us an update on the current state of devet

2 and um what the plans are for devet 3 yeah um so the current state of devet tools pretty much still on the interrupt Channel we haven't been able to recover the network uh there was a gets bug last week that's since been patched but that's led to at least one or two other bugs one in prism and the other one in uh te uh if someone from the team is there maybe they can briefly go through what the bugs are or if are they still active on I think they're still act at least the prism one radik has said he was able to

narrow it down but I think the te one might still be active under trient um yeah either ways uh we haven't been able to get the network back up and running but at this stage I think we're going to just leave it at this level and figure out what the bugs are uh we're waiting on client teams to have to pass all the tests um before we can launch the next Network so DEET 3 and there was a spec a spe spec test release Yesterday by Mario and I think if Mario's there maybe you can just quick please speak about the spec test yeah of course um there's not much to talk about there's a couple of interesting test cases there which I

think should be clarifications in the EIP I will try to if no one else is working on it I will try to make a PR to the EIP to make these clarifications but other than that I think it's it's just 7 7702 focused released um yeah I think um thjs is passing because we we fill the test with them um R reth yesterday sent a message that they were passing on our ebm but they have to Port it to ref and the rest of the teams I think are working on it um but yeah if you guys have any updates would be nice to know yeah I think Oliver mentioned that they've done it and they have a branch ready for us to use um so yeah we're

we're mainly just waiting on client teams to pass the spec us and then once they're ready we're ready to launch the network that's the current status got it and so we yeah we won't relaunch devnet 2 basically we'll just move on to devnet 3 once we have confidence that the new test Suites are um are all passing exactly because most of the issues that were triggered in dnet 2 were 7702 related so there was no real reason to fix it got it and then in terms of the spec changes for defit 3 I saw there's a dock but um are there any other notable additions um it I think the only uh big change is 7702 and on the CL side we've done a few

um changes with uh the consolidation bug Etc but as far as the C side is concerned I think those changes were decided weeks ago and nothing has changed there and for the El side we've switched to uh pinning to a specific spec test release version um I will just update that right now to whatever Mario released last night but essentially if you're passing spec you're probably okay awesome anyone else have updates or questions concerns about uh devet 2 or the the path towards devet 3 no 7 212 is not considered for defit 3

um and then I assume like yeah once we get all the teams passing the spec test will will launch the deet um hopefully in the next week or so is that realistic is there any team that thinks that you know Say by next Thursday um they couldn't have they could not be ready to launch them at 3 okay sweet um well yes let's continue chatting about this as we fix the bugs on Discord but thanks a lot Perry and thanks everyone for the work uh yeah on all the implementations um okay next up uh 7702

so we have three open PRS on it um that I want to make sure we discuss and then potentially make a call on uh including in devet 3 if we uh if we decide to the first is around uh the behavior of self-destruct in 7702 uh by uh suep I think I saw you on the call yeah you want to give some context on your PR uh yeah that's just a clarification being included in the IP I think the execution spec tests is already uh following that behavior where we restrict uh uh the self-destruct of EAS um so just a clarification being added and I think there's a general

acceptance to it so it's yeah it's just nfy I here okay and so the execution test that Mario just shared like the last version which is already in devet 3 followed this Behavior correct yeah yeah okay cool any questions comments on this um and then may yeah maybe we should uh just have it uh in the list for clarity so I don't think yeah I I don't think it's part of the devet three spec so I would maybe just add this one as well to make it clear especially if it's already in the

test um okay then next up uh Eon had two PRS is unfortunately not on the call um I'll go with the first one which was about changing the um signature domain for 7702 so using 0x1a instead of0 0x05 um basically in his post he explains um that uh this would allow future transaction types to use uh 0x05 and then um if we ever get past 0x uh 18 we already have some issues because zx1 19 is already allocated um I don't know if anyone's reviewed this um

or has strong opinions uh light client commented that he was you know different but um but um yeah generally in favor but anyone else um anyone else have thoughts on this I guess if we did do this do we want to do this for devet 3 because it's like a pretty small change but I assume it affects a lot of different parts of uh the code base um okay yeah and there's one one comment about waiting uh Daniel yeah exactly I I wanted to say

the same so I mean the change in the account base I assume for everybody is very small because it's just changing a constant but we have to change all the spec test of the words because when we because all the signatures are changing so I don't know how much work this would be and yeah it shouldn't it shouldn't be that that hard they are uh there should be dynamically updated once we update like this one constant it should be one line okay but yes the filling process it takes an hour uh that that will be the longest wait I think

so would people yeah would people agree that we should do this change but then maybe just plan it for definite 4 or something is that reasonable um okay and light client says he'd want to look uh a little bit more into the prefixes and but then assume generally assume it's okay so um okay then in that case um yeah let's not do it for devet 3 um let's just leave the pr open you know a bit more for people to review in the next uh week or two and then uh when we're scoping DEET 4 we can uh yeah we can for normally add this in um and if

there's any concerns and people can just debate this on the pr any other comments or thoughts on this okay um and then last 7702 PR uh this one was by uh Jan um which wanted to restrict the chain ID to either valid existing chain IDs or zero um I don't know Dr are you on the call yeah uh in general we are still having that currently we having that check inside evm I want to move that check outside of EVN and for it to

be uh validation of the seuality we already have some checks on the signature and this will be one additional check on train ID it will make any authorization list that has authorization with chain ID that's different uh from the current chain ID or zero be invalid any I guess yeah any concerns or objections with the general proposal if not I guess one question I have is are there some cases where like

test think this could be more complicated I assume not but yeah uh there will be need for some test just to cover this case yeah and that's why I would like to do it after DEET three yeah uh but this is very localized and small change to be honest there are some t I think the Mario is maybe better to say this but um there's some test that covering uh different chain IDs inside the authorization list those needs to be changed and I one or two test needs to be added check this case yeah I agree well it seems easy

enough to test I wouldn't include this in dep 3 uh because yeah it needs additional testing should be small enough though okay and then there's a comment by light client saying that we shouldn't make the validity of the transaction dependent on the valid validity of the authorization list um but I guess maybe there one question I'd have is that um yeah like previously we just cared that this was like a 256 bit integer what like yeah I I guess we yeah we already

have some restrictions on this so uh I don't know if you have access to mic but it might be good to just expand that a bit yeah I mean I think in general constraining the inputs based on a data type integer is different than constraining the input based on chain data for configuration data so I don't feel like we should be combin ining the fork into this kind of like serialization logic of the a got

it and yeah there's a difference between stuff that the things that are invalid because they can't be deserialized and things that could be derer authorizations that could be deserialized uh but then like aren't valid as authorizations and like if someone on ethereum gives you a authorization with chain ID3 like you could deserialize it but it's not a valid authorization though it doesn't authorize anything uh this very similar what we are doing with transaction signatures basically we make it invalid if s is more than half of the field and if the V is not in correct form

so it's not a lot different from having those checks right but those those checks are again based on like I don't know data types or like you know data like constraints less than like domain types is that correct like I assume the the signature data is like formatted the same across all the chains um and and we want to check that it's like a valid format but that's different than checking that like it's a valid signature on this on this chain you know for example uh authorization list enables us to have those check sbm for the signature on the transction level that

was not the case that's why it's optionally we have option to make it to make those check inside evbm but the what I'm arguing is we shouldn't do that we should do it when we are distalizing the lp and making those checks before to not yeah to not have uh yeah to not have uh invalid data inside authorization list not just invalid but data that we can check easily that we know that are not going to pass I guess does anyone else have strong

opinions on this and I sorry and then yav has a chat comment uh saying that um otherwise there's like uh if we if we do this change there's a potential dos Vector where we have end transactions using the same authorization which can be invalidated in 01 um you have the H maybe expand on on what you see as the issue here um yeah I was just yeah I just acknowledged the what like client wrote

about not making the validity of the transaction depend on the validity of the authorizations because uh I mean as long as the EA that's send the transaction can pay for it the transaction is valid it should be included even if the authorizations themselves are are invalid because uh otherwise it's a otherwise you could invalidate you could have a Dos Vector where you send a large number of transactions all of them using a certain authorization and then you can invalidate the authorization with a single transaction and cause and cause many transactions to become invalid after propagated so the validity of the transaction should only depend

descending EA not the authorizations it's okay it's okay for authorizations to fail the transaction is still valid I think that's what meant right just want to address DS claim I don't think that's valid because even when you receive the section you still need to do recovery of it to check Val of the section work to check uh recovery to do recovery and check those uh basically is a lot bigger than just iterating on authorizations authorization list uh I mean that the authorization the authorization can become invalid because it is non dependent right so if

if you send if you send a thousand transactions and all of them have the same authorization and after the non gets incremented and like all of the transactions except one become become invalid that's what I meant about the uh about that that's true but we are talking about now only for chain ID not about nons and not about if the sign is valid or not valid you're talking about validity of chain ID yeah yeah that's fine about chain ID that's fine I meant I meant the validity I I thought that what what last time meant was a about the validity in general and I think that the validity should not depend the

validity should not depend on the validity of authorizations it's okay to just uh these authorizations just won't work but the transaction the transaction will still go through uh doesn't that make sense it does but this is not something that we are discussing now yeah we are talking about just check and train ID yes okay right and so okay just to be clear like yes this would not oh sorry please go ahead we can't hear you really well sorry I I don't understand what the

difference is I thought that we were talking about the validity of the transaction as I understand it what we're so what we're talking about here is when should the check so we check the CH at some point we have to check the chain ID of the authorization is valid I.E it's either the current chain ID or it's zero so it's valid on a chain the question is should that check happen before accepting the transaction so if authorization if the chain ID is invalid the entire TR transaction is non includable or should it happen after the transaction is accepted so the transaction is included in the check

and I assume then immediately fails because the authorization is invalid my kind of feeling on this is it probably doesn't matter because like transactions that include you know if you have a transaction for chain a that includes an authorization for chain B um that transaction is like trivially malformed for like under some trivial static check that doesn't require you to know anything it's like obviously wrong so anyone who signed such a transaction has already screwed up really badly and I'm expecting that like it will be basically impossible to create these sorts of transactions using like any sort of standard toiling it's not a mistake that people are going to make in

reality but on the other hand the check is like so trivially cheap that like if we say reject the entire transaction if authorization um is invalid Mak sense um the only concern I would have which would lead me against this is that currently all of the checks you have to do um to make sure that the authorization is valid are completely chain agnostic like either the rlp bites you get given are an encoding of an authorization object or they're not encoding of an authorization object and the only check you have to do is you decode it with the rlp and if your rlp

decoder throws you in error then it's invalid whereas what this does is it makes the validity of the authorization yes I did get mar mar um makes the authorization um invalid um you know depend validity as a decoding exercise depend on what the chain IDE is of the current chain um and that just seems like adding a little bit of complexity whereas we're going to check the entire authorization anyway in a minute after we've accepted transaction okay I think yeah clearly there's probably a bit more thinking to be done here and because this is not

going to be uh added to devnet 3 it's probably fine to move this conversation I thinkc um so there's the pr there and um I think in the next yeah in the next ACD we can just uh if it's not merged or closed by then uh follow up on it but um yeah we do have other stuff on the agenda so unless there's any like pressing comments or on this I think we should probably just move on okay um yeah and thanks for bringing this up um okay anything else on 7702 before we move on from that IP if not uh eof so um I forget a frano

uh jordano I hope Francisco jordano I hope I said your name right um put together this dock uh with some concerns about eof and especially how it behaves with regards to uh token transfers for nfts um do you want to take a minute to maybe walk through your Dock and what the concerns are I know it's been discussed a bit on the Discord in the past couple days as well yeah sure so first as a preface I'm very excited about eof uh improvements to static analysis and code generation so I feel like that's important context I think these are just improvements um to make uh so I I do have these concerns

that come from the application layer um so ERC 721 and ERC 1155 are the two major uh nft standards and essentially they need an is contract operation to uh because of some behavior that they have on transfers so when a token is transferred to an account um if the receiver is a contract it has to sort of explicitly declare that it supports receiving uh this token um by implementing a call back and the token contract will invoke this call back and expect some special value in return this is only done for contract so if the

receiver does not have any code it's assumed to be Anya and the token is just transferred without calling any call backs um but yeah so the purpose of this check is to prevent the loss of tokens um which are transferred to contracts that can't handle them this is an error that happens a lot um and so it's kind of debatable does it belong in the evm or not but the fact is these two erc's which are final already specified they require this operation so what that means is that in eof which does not have ex code size or ex code hash it is not possible to implement m m this so the uh current proposal is to work around that

by dispatching to a legacy contract as a sort of escape hatch to get exd code size um this is possible this works but it uh is a bit of a hurdle for Library authors because now they have to hardcode this address or in in in the code that they they Shi to users um they you know we as an ecosystem have to make sure that those addresses are widely deployed and available everywhere which in itself in its own as its own issue because there's like no 100% reliable way to to get deterministic addresses across all chains um and then there's also the problem of like development chains on on

users local computers which also have to have that so anyway it's it's a big issue um so in my opinion this needs to be addressed just in eof uh the fact that it can be uh worked around in this way so easily and also the fact that these two main standards require that so it is going to be used um widely uh this sort of escape hatch mechanism to me just says well why don't we just enable these up codes EXT code size and or EXT code hash in EOS um and uh just just fix that so that all of this work around is not required

this is one issue um the the other issue that I describe in the in the um notes Here uh is regarding delegate call there's currently a limitation to um so eof contracts cannot delegate call into Legacy contract and this in my opinion qu realistically cause some bricked uh uh contract bricking situations could become that could become sort of like a new parody wallet situation where a proxy that is working perfectly is accidentally upgraded from a neof contract to a legacy contract and then

it becomes unusable completely Frozen um and it will require some sort of well or or no recovery at all would be possible um so it's not really clear why this limitation is in place that um I think it's about just avoiding um things that any contracts that are not supposed to happen there um for example anything related to self-destruct um recently there was a proposal for 7702 to sort of change the behavior of self-destruct in that context could that there's now a discussion to to apply it in eof as well um and to just sort of lift this restriction and just allow delegate

calling into Legacy contract um and uh that would prevent this situation but this is sort of related to the previous issue because if we had EXT code hash we could Implement at least a check like to prevent the situation in the code itself to um see if the uh Target that we would be delegate calling into is eof or Not by using exd Code hashes behaviors which just allows you to detect that um so these are the two issues that sort of related to EXT code size and hash um and they call it its own uh discussion and we we've been talking about this in the eof Implement SC but um so far no change has been made and and we're sort of

heading towards the status quo um and I think it would be better to make a deliberate decision uh that with like convincing arguments as to why choose one thing or the other I'm happy to hear any opinions thanks for sharing um then know so one of the we've got a couple constraints be working with with e F to uh to get it to ship um one of them is there was feedback given from multiple people in ACD that we should strip out absolutely everything that is not absolutely necessary to ship it and we come back in Future releases and add those features in so any feature that didn't involve breaking something that could be added additively in the future

hard Fork is something we made a conscious decision not to put in to reduce the scope and the testing impact of eof um this is one of them how to detect a contract we can add that with a um is contractor unlocking the old op codes in a future Fork um there's also a couple of other features uh TX create which allows us to um create transactions from to create new eof objects arbitrarily from transactions um was also removed as well as consideration for EXT um data copy which allows us to copy data from other eof contracts um those were pulled because those can easily be added in in future um in the next hard Fork we can add those OP codes in without breaking you

away without invalidating any other contracts so that's been our guiding um Northstar for at least eof V1 to see what goes in and what goes out and while this this issue with um building uh 721 or 1155 contract in eof um it does kind of prevent it right now from following the specs um it doesn't break anything outside of B you can continue to write these contracts in Legacy and we can add these op codes in um the next hard fork and then you can start writing them in eof so that's kind of been our pH ophy of of why we chose the status quo um but if we get feedback from ACD that this is important to fix now um we'll we'll you know work harder on the consensus as as the efter is called to get it into this

release but I'm my overriding concern is acds already concerned about the size of this release as it is and I guess maybe in in that case uh assuming we did add those you know uh more features like in the future version if something did um if something did get Breck through like some weird update um like like we were just talking about is that something where then exposing that functionality in eof allows you to make the same calls you made in Legacy VM and therefore sort of unbreak the contract so that's the case of the

delegate call limitation we already put that originally put that in um most mostly it was around self-destruct but in generally it's around any feature and any operation we Bann inside of eof um self-destruct is the most easy one to to demonstrate um but when it comes to the other op codes that we're Banning inside eof as you know as fio pointed out you can just do a regular non- delegate call to get EXT code copy and pass it in as return data so a lot of those have non- delegate call Solutions I think only self-destruct and the side effects are what is impacted by it and we didn't want to propose changes to self-destruct but with 7702 that cats out of the bag and you can write your proxy

contract to do the eof detection via uh those jumper calls if that's if you feel it's important to have your proxy in eof but I think until we get these features you shouldn't write a proxy in eof um those will come down the line and we'll get those addressed uh yeah CR you yeah I feel like there's a significant difference between uh something like TX create which is a actually new thing versus something like EXT Cod size where it's just um it's not additional effort it well that's easy to say but it's not like a

difference from um Legacy contract and um in in my view you know we're go we're making all this effort to ship eof now um while removing stuff is good it's also good to make it useful and ensure adoption so that all of this effort pays off my concern is that with these limitations it's going to really harm this adoption um in in languages and and libraries um and and we're not going to really kind of reap the the benefits um so in in in the direction of like reducing it as much as possible the the simplest possible fix would be to just

enable EXT code size um and um I think that'll that'll be a much better situation for E to get adopted oh uh Ben um probably code hash also because then you can actually detect this nef contract specifically um whereas you can't do that with code size alone so code size would say oh it's to bit but that doesn't tell you it's BF to bit if you're worried about

proxies detection so one of the things that we're um developing in the UF implementers is uh we don't have the pr out yet but we're contemplating in is contract do code um and one of the design options is have it return 01 or 012 zero for legacy no zero for EA one for legacy and two for eof so in one op code we solve both of these problems um but we're still there's other design issues we want to make sure we're covering spaces and not um pulling back on some of our commitment to remove code introspection because if we if we just blindly turn on the XT code hash EXT code size and EXT code copy we probably don't need copy but I mean if we're

removing the other EXT codes there's going to be a lot of pressure to say well why don't you just do code copy all of a sudden we're needing to keep all the old bite code or at least metadata about the bite code AS was originally implemented um which is going to make things difficult for ZK systems because they need to keep some extra data um but there's already issues around that anyway um with calculating the addresses so we're discussing this um in in in our chats and um I mean we we could if it was just as B simple as just flipping an OP code or implementing one other thing I'd be a bit more um willing to push um the rest of the implementers to a solution but I think one of the big issues is we don't have the exact Solution that's going to

solve all of our commitments and fixing in a subsequent Fork um gives us the space that we need to make sure that we're doing the right thing not necessarily um the time forc thing and as far as you know if we're shipping something that Dez can't use 95% of contracts never need to know if you're calling an eof or EA um the exceptions is the 11 55s in the 721s um but if you're calling Unis swap um it's you know presumed your contract um the call backs they work it's a lot of the contracts and smart contract use cases that go with this um these features are not essential and they're not breaking um so that's you know we're

we're covering 80 90% of the people who could use it you could deploy Unis swap today and not have any of this concerned so I guess maybe um one related thing to to think about is just like yeah how far along goof is right now what the diff is to add these features and over what timeline because um there's clearly like a design space to explore here uh whereas we've been kind of exploring the rest of the design space uh for for quite some time now um so I I guess I don't know if that know you the right person to to give this updates but like in terms of the eof dev Nets like where are we at now um how stable are the

implementations um and then you know like what do you think uh it would it would take to like uh add you know add these up codes um yeah so the big issue for the app codes aside from coming to consensus on what the correct solution is is we need write tests for them yeah um and that is a couple of days to write the tests and then all the clients need to implement the code and and conform with the tests as far as devet 4 Readiness we're at least two weeks out um the clients aren't 100% on tests right now um every client has at least one test that they're failing um some of them it's because there's some of the some the specs have been changing underneath it a little bit um and they had you know

implemented it to a spec that was correct a year ago um those are some of the issues that they're working with plus um the work on 7702 is taking a lot of Engineers time right now how you know things are getting basically designed on the Fly um it's taking a lot of their time to reimplement these changes so um as far as far as Readiness you know I think we can be ready for when devnet 4 ships um adding the op code would push us back probably about a week for devnet 4 at least okay um my sense is that yeah given eof is already such a huge huge um change um I would lean towards integrating the version that we're already testing

thoroughly as a first version in Dev Nets before we add anything uh more and then you know potentially in parallel start uh targeting sort of an eof I don't know extension that we we can potentially add in say Dev de 5 or something if devet 4 goes goes smoothly but my um yeah my biggest fear here is this is already such a massive massive change um and that if we just try to add everything now and constantly keep changing the spec uh we don't even get to a point where like clients have a stable implementation of like the current spec that we can

test and yeah it does seem like we we don't necessarily need to make a decision on this now but um ideally before we ship we should have like a you know taken a the right decision here does that make sense to people any objections or concerns with that um okay sweet in that case what's the best place to continue the conversation around like the specific issues I know that people have been using like the evm channel that seems right and I assume there's another EF implementers call if not next week the week after is that right yeah next week there is one um yeah the eof compter

calls are opposite weeks of acde okay um so it'll be Wednesday and E the evm channel is a great place to do that um I'd like the ipsilon team to get that draft out um as soon as they think it's ready um preferably as soon as possible so we can have discussion on what um their ideas are for um how we can address that um so yeah that's the best place to continue this and I I do like the idea of doing devet 4 with what we have right now and then contemplating whether we add this in um in Petra or whether it becomes a fusaka Target yeah that sounds good any other concerns comments about uh eof or the specific

change okay uh yeah thanks Daniel thanks fro for coming on and uh sharing the doc uh moving on uh we have a proposed change is the CL uh change uh to fix the correlation penalties that Mikel um that that Miguel um put together um and you just wanted to get a Last Call on people reviewing this I don't think miku's on the call today but anyone else has comments or contexts want to share about this please do I can a little bit uh uh yeah it's kind of fixed as an edge case with the

penalties on the seal around slashing uh under the max EV change and yeah if uh especially SE teams could just take a look at the pr and approve ideally uh that'd be great but yeah it's it should be in a good pretty good place so I guess the ask is just uh for SE teams to take a look is this something we would merge into devet three or devet 4 question um I would just say it'll land in CL specs release when it's ready and then from there we can just see which dubet is ready um it shouldn't yeah it doesn't really matter this isn't something we're going to hit in

testing at least in three or four okay sounds good um so yeah let's try and get this reviewed async and then uh merg before next uh week's call ideally um next up we have a proposal by light client uh to unify request objects in the engine API uh there's been a fair bit of discussion on it uh with um yeah with the last comments uh coming after the start of this call right at the start of this call I don't know like clients do you want to give some context on this and um if others after that want to chime in that' be great

if not as I understand it is that the current design requires uh yo clients to be aware of the fork schedule um through the engine API and um this design would I believe remove that requirement but there was a recent comment um yeah that came right at the start of this call saying that it seems like the E actually needs to be aware regardless um because uh of some uh of of some old methods all right any comments thoughts

if not we can also continue the discussion on the pr um and potentially give people another week to review it okay uh yeah in that case let's move on um okay so Petra eips um we had uh 7623 which was proposed a while back and then subse sub subsequently CFI uh Tony wanted to ask about uh including this in the hard Fork similarly uh Alex had an EIP to decouple uh The Blob count

between the El and the CL um and then lastly uh Max has a proposal to uh update the blob um The Blob reserve gas price um and so it's probably worth going over each of these uh in more detail but I just wanted to flag that like um it does seem like we have a fair amount of like small proposals that people still want to put in the fork there's others that uh you know we've discussed on previous calls like 7212 for example um so like if making decisions we should make them in the context of like um yeah none of these are like the only thing we potentially want to add as a small addition to Petra

um and I mean we're just discussing a couple new off codes for e as well um yeah so to start I don't know Tony you on the call do you want to give a bit of context on 763 and um yeah any thoughts you want to share there yeah sure um yeah as a reminder EAP 7623 proposes to increase the call data cost for call data heavy transactions and the main motivation to do so is to reduce the size of the El payload because already today we see certain Big Blocks and with big we're talking about 400 kiloby that receive way less attestations and are then more often three ored and also today the

median or the mean block size is around 100 kiloby plus blops but the maximum size is 3.5 megabytes so 100 kilobytes versus um 3.5 megabytes and as you can see this is super volatile and by increasing the call data cost we can basically reduce it also I think the AAP is um in a good position now because we have blops all rollups are using blops already so no one relies on using call data for data storage on chain yeah as Tim said the EAP is considered for inclusion and I would propose that we um include it in definite 4 um the AAP itself is super

small um the El specs are done and I think Mario also started implementing it in G and yeah would love to hear what the CVS think about it so there's two comments uh saying that uh you know they they see the AP as addressing the vulnerability uh I assume this is the fact that we can have these huge uh heavy blocks on the network um and then a plus one from nether mind for the CIP any other thoughts comments okay lots of plus ones for the EIP

um I guess okay before we make a call about this um it's probably worth at least going over the two other proposals um just to see how much support they have um and then if we uh um yeah if this is the one people feel strongest about and they think we should still include stuff we can um yeah we you know we can decide to include it and and figure that out um but yeah before we make that decision um Alex do you want to talk about uh 7742 sure so I think most people have seen this EIP and some sense already but ultimately so today how it works is

there's a Target value for the buls that we want in the protocol and a maximum value and right now both these parameters are specified both on the CL and E so uh you know a couple things this does at least one thing is that it just couples together like development of both these layers um also makes a little more inflexible to change uh say Target or Max wherever we want so the CIP proposes to uncouple these constants between the E and cl and essentially have the CL Drive the values then provide them in the necessary way to the E so we've gone through a few rounds of feedback at least more on the SE side of things and

I think uh the things are ready to go meaning the EIP engine API changes and the seal specs so yeah um I think there's generally I mean there was really good support from the sale call last week and yeah I'd like to hear what El dubs think any thoughts on 77 okay so re uh is in favor doesn't

feel strongly about included in yet in pectra or not any yeah I guess one other comment is that it supports you know pios and just generally The Blob mechanics and so you know we could imagine coupling this with pios then we can decide we're P ultimate lands I was just saying they want impos it would be a little messy to like

have a separate puros spec but no we would have we would have one spec and uh just point to that basically so uh hopefully we could launch like uh yeah I'm I'm not sure about the correct order what we would do like backra defet 4 would come first or p devet 3 uh we are currently still waiting for p devet 2 uh for client teams to finish the implementation uh once that's uh somewhat stable then we can add some additional scope to the P Des testing which would be also the time when P would Rew base on top of Electra so um at that point it would be very

nice if we could play around with a different number of blobs in in each uh like different Target and different uh values and and just experiment of like how it would look in P death all we would need is just uh a single e to implement this and then we could use that for testing and then every other e could uh implement this uh later or whether we decide to include it in Petra or not yeah so there's a comment in the chat by dran about uh potentially leaving decision making for the next acde so

people have time to digest um I um I I feel like that might be the right way to go about this so that we can at least uh list out all of the all of the like potential additions um and some of them are like formal EIP so like 7742 I'm not sure if we've CFI it but it seems like it probably makes sense to CFI that for the fork given you know the relatively strong support um but then in addition to that uh potentially list out like the less formalized proposals like these eof changes and uh potentially what we're about to um to talk about um would that make sense to people

um or does I guess does anyone feel like there needs to be a decision taken now for um e either of these okay if not uh does anyone object to CFI in 7742 just so we can have it there in the list alongside everything else um so we already have uh 7212 there the the R1 curve we still have the inclusion list thep which uh I think we pretty set that we're not going to do and we already had 763 um and so yeah I I think um I think having 7 742 there and then I can put together a list of the other proposals

that aren't quite as formalized and um people can review that and ideally even share their thoughts I think prior to the next call okay um yeah thanks for sharing Alex and then last one on the agenda um max wanted to talk about raising the reserve price for blobs uh Max are you still on call yeah uh so this this change would be a oneline diff the reserve price is actually already implemented it's just that it hasn't been set other than at one way so it's a it's a oneline diff just changing that constant to be uh a

value that I proposed the value was chosen so that the cost of a blob would be pegged to around the cost of a simple transfer so 21k gas at a one gay base fee and so that comes out to around like 5 cents USD per blob at today's prices the goal of the change is not to raise revenue it would be like even if we had three blobs per block it would be something like uh less than 400k a year in total cost uh if we saturated all the blobs uh but the goal is really to have the reserve price be at a point where when blobs do enter price Discovery they do

so faster than they do right now and right now it would take basically 32 minutes to get from one way to this level of like reasonable 5 cents per blob because of the way that the updating rule works and you have to Traverse like all these orders of magnitude of of fees to get to the right spot and it just takes a long time to do that uh with the updating rule so this would be kind of like a oneline change that addresses that and of course the reason that we might want to do this is that there's some chaotic uh stuff that happens when blobs ater price Discovery where there's a lot of uh weirdness that goes on on the fee markets that we've seen a few times when they do enter prise

Discovery thanks um ongar yeah I just wanted to uh say that basically um the reason why the parameter is in the specs right now but not set was just that we weren't sure it's worth the complexity and initially we just assumed that uh BX Bobs would only really go through price Discovery once relatively shortly after shipping for it4 and then would stay above some sort of minimum price from then on out it turns out that that was not the case it takes a little bit longer to basically um hit that adoption level and so we we might actually go through that that phase several times um and and we've already done that a few times in

the past when when when when demand spiked and so I personally think it makes a lot of sense and and particularly I think that Max is specific I know it's not an EIP yet but kind of the the specific proposal he made seems very sensible to me because it is actually somewhat important that we hit the right trade-off that we don't set it too high because the point specifically is not to raise revenue or anything or like price gouch or or anything like that it's really just to like shorten the amount like the time to sensitivity basically um and and so I think basically the proposal as is is basically already ideal and if it was put into a full EIP I would support it thanks uh

Ben um I'm not double checked Max's math but um I'm trusting it blocks to go from uh one oh sorry one way to One Way seems like a extraordinary load on the validators for you know no um unresponsiveness to get to a price that's you know pretty low anyway at one gu so I think it makes a lot of sense yeah and that would be at full load and actually there's like a bunch of weirdness that happens usually these price spikes happen around when other activity on the chain is high and when like there's trading going on the

builders don't want to include the blobs so it actually takes even longer than that because they're they're periodically producing blocks without any blobs so that's the it's even longer than that that's kind of the the best case scenario any other thoughts questions or comments about the proposal you mentioned someone mentioned that blobs um are not being included um for like efficiency reasons related to trading um is there any concern that well like we might not get price Discovery because like people are so reluctant to include blobs that they

don't get that they're just not being included above the target rate anyway because that Mike suggest we want to do something more sophisticated than just proposal uh there some other sorry I just clapped instead of raising my hand I want to chance and repeat this question I don't think I think I don't think that's the case because at some point drups will just pay more and more and at some point the Builder will have an incentive to include them um no matter how big the blobs are yeah I agree with Tony the the priority fees will start to escalate uh there have been some changes in Builder

API points that allow a more efficient fee market and allow you to basically replace your bid with a higher one with a higher priority fee without rebroadcasting the blob uh whereas before you had to rebroadcast The Blob and in order to prevent like dos attacks on the network you had to increase the fee by 100% so there have been some positive changes in that direction on the Builder front um besides I think a change like that would probably be too big Petra any change that's that's more in the fundamental structure whereas this is just kind of a oneline change to a parameter so I think uh for this

specific proposal it's clearly worth drafting an EIP and uh considering it along with the other uh changes we were just discussing in the next call um max do you have the bandwidth to do that uh in the next say a week or so yeah I'll have it awesome ready by the end of the week thank you awesome um and I guess one thing uh related to the 7623 that I wanted to bring up um is that Anar said you know it might be worth considering just the raw call data increase if that's simpler than 7623 um I don't know if anyone wants to draft an

EIP for that as well for us to consider or if um yeah Tony you have thoughts about like if we were to just do a simple quote oneline change instead of 7623 um what would that look like yeah you could basically look up the EAP first version um it started exactly like that by just increasing the call data cost of but just for aing the call data cost for nonzero and zero bytes the main problem back then was that the community was basically saying so I reached out to um a lot of community members and teams and the main feedback I got was that this is kind of

then a a bigger change because it impacts tooling because not not like in EAP 7623 where 99.9% of the transactions would be unaffected so every token transfer any NF transfer anything you do with def5 would be unaffected not touched but with a dump increase you touch basically every transaction and yeah this was the the main um the main rational why to do it in a little bit more complex way but also having the advantage to not touch um every transaction and also there is this follow-up proposal by vitalic to do it um fully M multi multidimens

dimensional which is probably something we might want to do in the next years so I would see 7623 more as the quick fix that is a little bit more sophisticated than the dump increase but also um far away from multi-dimensional gas pricing got it thanks um okay I guess in that case yeah um we can have people review 7623 and um if for whatever reason people think it's too complicated even though it seems relatively simple we can cross that bridge when we get there um but thanks yeah just wanted to make sure that we we touched on that as well and I think this was everything we had on the agenda for today is there

anything else people wanted to bring up that we quite uh that we that we didn't get to today okay if not um yeah we can wrap up here thanks everyone and I'll share a recap uh uh yeah shortly after this call and uh yes if people can review all the proposals before next acde H and ideally share our thoughts about them ahead of time we can hopefully make some final decisions about the scope forra in two weeks yeah thanks for coming on everybody and talk to you all soon cheers everyone thank you everyone byebye

J