EIP-4844 Implementers Call #18

Transcript

okay uh welcome to uh 444 call number 18 uh a couple of things on the agenda today um uh some spec stuff around this is z around the Feed Market and then we can chat about our client teams are at um and what makes sense in terms of uh potentially setting up a devnet um I guess first on the SSD front so we discussed this on all Cortez last week um I think that so the the thing that came out of it is it seems really unlikely that there's a wholesale move to SSD that happened in Cancun alongside 4844 um so given uh 444 is already a pretty big chunk of work and uh moving

everything to SSD also would be uh quite significant uh to yourself like it probably makes sense to split those up um that said um because we are introducing uh some SSD in 4844 uh we still sort of have this open question of like what's the right format uh the the use um so there seems to be this uh disagreement between what are we optimized for the storage size on a full node of transactions or whatever we optimize for the uh proof verification um of transactions and that's results in two different uh SSC encodings um we didn't get to uh

solution or like agreement about that Donald cordatos which I suspect is still the thing that's kind of blocking for us um but yeah that's roughly where things are at so it would be good that you know whatever we end up doing with 4844 is for compatible with um sort of broader SSD roadmap um but we we don't have consensus on that uh quite yet um yeah I don't know if anyone has uh yeah thoughts on that yeah yeah it's going to be hard to reach my

consensus I guess without yeah a lot more eyes on that sort of more broad proposal I suppose yeah how yeah how big of a change is it to change DSS Z4 because like I suspect a lot of the engineering work is that just add SSD support in the El clients period but then you know if we only make this decision a month from now on all core devs how big of a change is it's the change you know the 4844 devnet at the time um to to a different like transaction structure um yeah it shouldn't be too bad I mean I think one the way it's specified right

now um what's nice about it is we don't have to bring in like the entire SSD protocol because it doesn't involve the mercurization um but you know I think most people have implemented immortalization anyway and they're frequent consensus layer work so bringing it in isn't all that bad um but yeah I think that's the main thing if it's just tweaks of the uh you know assuming we were going to bring in mortalization anyway and it's just tweaks of the layout I don't think it's a whole lot um it does affect um well it used to affect I don't know if it still does give them the latest tweets but it used to affect a little bit on the consensus layer side had to understand kind of where to extract the the um commitments in order to verify

um but that's pretty minor okay any other thoughts if not then yeah I think the path forward is like I would leave the 4844 spec as is um and uh you know potentially when we uh when we change this then we we we make the the change in in 444 but I I just don't think yeah realistically there's a way we can uh come to a decision it's like a coin flip like I don't know that there's like a

objectively better or worse approach um and yeah wait until client teams have spent more time on it figure out a decision if we're lucky we won't have to change things um if not we just make the transaction format change once uh once we have a broader SSD consensus um and I guess Terence so The ssz Proposal I assume this would be the transaction type as it's defined in the EIP right uh I'm trying to pull up the EIP right now uh

[Music] yeah so uh new transaction type so this is basically uh specific transaction type um and there's some other discussions happening around like you know potentially changing the withdrawal route on the El the SSD and stuff like that but again it's like once you make all those decisions if I don't know the withdrawal roots with effect the the transaction type I don't see how but um yeah we can retrofit um we can retrofit this EIP to the to just be in line with things but um okay did I hear that right so just stick

with the existing yeah yeah until yeah until there's a change if there is one basically yeah unless someone here has like a strong objection but I yeah doesn't seem like we do and okay so yeah stick with uh the current transaction type and um yeah well no once I was decision made on the broader uh SSD yeah discussion okay next up uh the uh Terence you posted this each research post uh

Roberto you independently said the baby as well uh the free market analysis I unfortunately haven't had time to read it yet I don't know Terence or Roberto Davido if you want to give a quick uh overview and and share your thoughts yeah sure yeah go ahead sorry it's fine okay sorry about that so yeah so I think overall it's a very very good post and I highly encourage I highly encourage people to read it because this is kind of one of the lesson known um lesson known um design space that people have been working on and it's definitely something that we do want to give right

um initially because I feel like we don't get this initial mini data I guess set correctly then we maybe encourage you like spamming applications and then this is something that like unfortunately like we definitely want to get we definitely want to get it right like uh as early as possible so basically the summary of the post is essentially saying that given the given the layer to demands today that it will take one to one and a half years for the usage to reach the target of data gas price threshold basically so um given that whether it's worth raising that mean in price because we want to

deter um spammy applications basically applications that's used in data I guess for the wrong reason and then because it's hard once they start using it then it's gonna be hard to move move them away later right and then another thing the post pointing out is that it uses it kind of assumes the layer two um their current usage is uh inelastic but I but I would argue it's more elastic than people think because of like their two users paste data I guess and the data I guess is also a function of the of their us as a function as the layer one cloud data so that's my main Audio Man other than that of course is

great with definitely one more ice on it yeah that's a good summary Terence um I left a little comment um I guess with with um some of those points at the bottom there um I it's good food for thought though I know I don't know if um um Don crowd is here but I know in the past he suggested raising the minimum as well so he would be a good person to hear from on this topic um I don't think I have a strong opinion I did push back a little bit though I mean I think ideally we'd want the market to be able to determine the appropriate minimum price um but one concern I have with the current proposal it's a little

underspecified like it doesn't not that proposable vip4844 itself doesn't actually specify what happens if there's a lot more blobs um kind of pending in the mempool than there's available space like an eip1559 we know that we have a priority fee we can sort by that and nodes are incentivize is to do so um the the obvious option with 444 is to sort by Max fee per data gas but since there's no priority fee there's no incentives for nodes to actually do that but then again I guess there's not really incentives for notes not to do that either so perhaps that's fine right I guess mophie's pointing out that the

priority fee applies here too that that's true but that's I guess that's on regular gas so but I guess it's still used to um rank it applies here too because even though there are two separate markets it's the same like uh it's the same same person that's um selling the uh I guess the product so you can use the priority we use for compute gas and uh bump up your um data gas to get shoved in got it that makes sense so if I'm

competing for blob space when we're in the saturated mode the 1559 priority if you kind of conserve that same purpose is that the argument foreign the blocks were full um already so you know it was a question

of like the the oh yeah Mophie do you wanna answer to Roberto I I missed this question my lost audio for a couple okay oh I was just um repeating your point uh to confirm that I got it right which is that um um the priority fee from 1559 can can kind of serve the same purpose for the saturated blob case one could just bump that up and so that's sort of the prioritization rule yeah yeah totally gotcha thanks right and I guess and then from the post

so one of the challenges is because the blobs will not be full and the price will be I don't know if I want to say artificially low but it'll be lower um or at least yeah for a while the price would like remain somewhat low because blogs won't be fully utilized and this is different the blocks where um prior to 1559 they were fully utilized so like it took a couple minutes to just find the right market price again yeah at Proto so I think it's a phrase strong

statement to say that the blobs won't be full like for the uterized like today the only reason why products use the amount of data that they do is because we're already maxed out the like the gas in ethereum to like versus the demand that there is in like fees right and right now these products including optimism they're paying the law for ninety percent of their fees towards data already so we know that users are willing to pay like a premium to to pay for data now if there are smart

data to provide to them and at a lower cost I think it's very reasonable to think that those fees that they are currently being utilized for less resources would go towards like utilizing all those resources fitting the gloves yeah that's a similar point that I had made in there um do you feel Proto that I mean the end result is that when this does go live we're not going to be in a situation where we're kind of Min pricing for a year a year and a half so at the tldr I guess

I think a year or even half years or quite long I do expect it to be like unstable for at least a week or longer where it is quite a jump in like in going from the current amount of data to the different type of data so it'll take a while for like usage to like adapt to like oh we can make more transactions or like we can call this contract more often these type of things that have to be they they find their way in the markets but I don't think it will be instant right but I

we don't we don't need it to be instant right it's kind of pretty much I guess what I'm trying to ask more concretely to you do you feel that the proposal is fine as is with the minimum one they'd ask me personally I'm more of a maximalist of markets where markets can price these I do believe that there's a certain lower bounds of two for safety reasons so if people are concerned that the markets don't find like a right price for this you can set at least some minimum that makes sense for the protocol to sustain this

but I'm beyond that I'm I mean sorry for just like not spicing the fee markets too much I wonder if there's a way to set the minimum I get like to do some sort of mapping towards like what's the real economic cost of like running this data like obviously we can know the relative cost like with gas prices but is there some like minimum but again that's hard though because you're back to the east USD exchange rate like we could set a minimum that targets you know roughly the like real world processing like Fiat cost of of

sending over the data um but we're gonna set this minimum in Easton so that's kind of anchored to whatever the East price is when you uh when you deploy the EIP and I guess this is also something that you could imagine I guess there's two ways you could go about it one is either you trust like the market the start and assuming that the minimum was too low you can then also uh change like the transaction pool rules and stuff without doing like a

hard Fork uh you know to uh to make it slightly harder to get these minimum transactions uh minimum fee transactions in them or you but you can't do the other approach right if we set the high minimum in the protocol um there's no way to then you know change things uh if we if if we think it's too high rather than a hard Fork so I don't know this sort of makes me means the words keep not having a minimum or keeping the minimum of like one way because worst case clients could just you know each hardcore within their transaction tool that they're not going

to accept transactions um you know with a one-way price or something like that I guess does anyone feel strongly that we should that uh that we should have like this higher minimum I think a higher minimum is fine as long

as there's like a case for like why this minimum pace for certain security guarantees because I do think with the target mechanism we know and understand the throughputs and this type of resources bounded to a limited amount of time so like office combines I think it's very reasonable for us to take low fees for these blobs so sorry are you arguing that we should raise the minimum or leave it as is like we are arguing that we sh shouldn't need the minimum here for the research limiting is bounded like the the whole thing

be we know how much expensive it will take if it is if it stays under the targets we know how much storage it will take and we know that it is a bound to this after like 18 days that this data starts to get pruned so even if there's a spike in throughputs this bike will pay for it so if the price adjustments and if there is a consistently below targets throughputs then sure the blobs are cheap but it is within our like model of what kind of resources are going to be used for this and after 18 days it's all gone again so like this is not the persistent cost to

ethereum yeah I'm I'm happy to not change the minimum speed as is does anyone disagree strongly with that anything else on the specs okay then um I I sorry I just going back to the minimum thing I'm just I I think I don't understand is

given we have such a small number of blob transactions that don't even get into blocks I don't really and maybe this is just me I need to understand a better 1559 mechanism but do we have any concern that the 1559 mechanism won't work as well here because of that small number of transactions like won't we just immediately go up to like a really really high price or stay at a very very low price of the mechanism is smaller like it's there's discrete steps of fill blumps so it doesn't adjust like a smooth curve like esp1559 but the curve is there like it does adjust the way you would expect it to adjust and so over a long enough time

frame if the usage targets some amount of blob throughputs it will find like a a price that reflects that doesn't the curve also look at the use Target usage since like the introduction of blobs rather than just the last block it's sticky yes so when you start pruning blobs it's like it doesn't take a it account in accounts the removal of these blobs but overall like if you look at 18 days worth of blob data this is quite insignificant it's like this small change in like the whether or not the excesses is

math like if the access is truly too expensive then you'll just see empty empty blocks for a little while and we'll go back down the the price for the blobs yeah this discussion has been had before in Erp about the I think in the original efp that's changed it to like from this base field like mechanism or I think it has to take up the pr number but then we refracted the fee markets we had this whole discussion about how the the price adjustment should account for like the pruning I don't know I guess I I'm nervous about

the one-way thing it just feels like we're leaving a lot of value on the table for ethereum that we could be capturing and I'd like it feels to me like we should be doing something like what Tim suggested where we do like an analysis of how much does this actually cost to network or something to set a minimum gas price but yeah so the problem with that analysis though is you can get you know some Fiat costs but then the network doesn't know that right like the network arcology knows it right it doesn't even know the price right yeah yeah but and then the other thing is like how I think to me the most convincing argument in that post is if the cold start problem actually is like

a year long right like whereas if if we're talking like you know days to weeks or you know minutes to hours then like I don't think it matters if we're talking for a year then yeah like it probably does make sense to have a minimum price because we we do hard Fork more than once a year we can change that minimum price roughly on that schedule yeah Proto so another like thing for context or as example would be to think about the Shanghai denial of surface attacks like not the not the one for the hard work but like the original ones um then there was this type of like dance I believe you can see still see it in

like when you're using like full sync and notes and see like this this slow down for a bit like this like gas usage is persistent whereas these blobs after 18 days are done so even if they're misused at a low gas price sure price will creep up maybe it creeps up too slowly but it will creep up yeah and the data will get removed eventually and it'll be like a a an obligation to the ethereum anymore so like there's a very different type of long-term cost than the gas resource studies

and yeah so I I was thinking you know one thing that we may wait a bit uh until this 4844 is deployed on some some test net and some potential users um starts to use it because in in my understanding there may be some some users even not Roll-Ups that are going to use these uh blob transactions uh so I mean maybe there is actually a much bigger usage than than we expected currently or is it or we are 100 sure that there will be under usage for uh for the first year or something like that

I think a lot of people are questioning that assumption that they'll be no low usage for a year that's I mean certainly I I would be surprised if there were more users popping up taking advantage of this feature okay so so even now there is uh there isn't much uh other greater ways to use these blood transactions okay but the the if I understand correctly the the worse what what uh could happen is that uh well somebody will spam at the full capacity of uh of what uh Network should handle uh so in in worst case uh well nothing bad happens or am I wrong

yeah I mean there's a max four blobs per block yeah I think that that kind of handles the spam case pretty effectively yeah I mean the the worst uh worse scenario is that we have some temporary spam uh which uh which doesn't generate much much revenue for the network in terms of fees but but it kind of tests the capabilities of the network and this is the worst case scenario you know and now push back on the even it doesn't generate fees because if you have a lot of spam then it starts competing for blob space and so the price starts going up and so it does generate a lot of fees like spam is almost like a yeah and that

this is like more I guess on the research post but it's like spam is almost like a weird way to put it because it's like if the transaction price is low people are like bidding up building it up but then once it gets bit up you know what's the difference between that and real usage you know they're like paying for the transactions yeah and this is in any case it's a temporary I mean the the yeah blob data will uh will be put yeah after a while so I mean I understand that this this question in general this this is interesting but I personally don't see too much of the damage uh of uh you know if it happens that the fees are too low

at least from my point of view yeah so I guess what makes sense is the next step like the the post is still quite new on each research you know we can see if there's more conversation on it but it doesn't seem like it's it warrants an urgent change to the spec yeah I agree um so I already left my thoughts on there I would love to the other people that have um um I mean uh you know orthogonal or similar points to kind of just can maybe we'll just continue the discussion there it doesn't seem like there's a rush to do any need to do anything though yeah I'll also

I'll link the the recording of This call once it's up on the thread so people can uh can see this discussion as well cool any other spec uh related issues okay uh if not uh on the client side um so on the last call we we sort of discussed that you know we probably had uh two to four weeks of implementation um and obviously with Shanghai coming out it wasn't clear if we wanted to get it that stood up before the Shanghai

where he says we're out there wait until that's done so we have kind of this this good foundation to build off yeah does anyone have thoughts on this or just you know want to share their progress over the past couple weeks I actually share crude progress on the prism side we are still working on um decoupling blocks and blob I started running on local devnet last week and then I ran into a few issues with Kev I believe it's fixed so I need to retry it but yeah I think majority of resources are in chappella right now so uh I think after like one week we will have more people looking into this but yeah I think we're probably on track for like multi-client tests now maybe in like two

weeks from today I think that's a good Target from us but yeah that's that's where we are cool and what would that use the would that use basically that would build on top of the chapel releases right I assume it's two weeks from today yeah um Terence did you figure out um was that you said you were seeing an all state route I guess is that right I haven't tested it yet so yeah that's that's all my TD today okay great thanks so on lordstro's side uh lots are is sort of ready in the sense that without including uh the changes to the blob signing and blocks and blob signing

endpoints uh basically where we are right now we are just independently so independently fetching and signing and Publishing the blobs uh so with without those without the latest discuss changes in the signing endpoints uh we are sort of ready uh to uh to basically sync with any other client that is out there uh locally I have been able to uh run a devnet where they they are there have been two nodes which basically uh were running saying they were they were blocked transactions and then there was a third node that could sync from request response and then would also

accept Blobs of blobs from Gossip once it got synced so we are sort of right now in the review stage of our work and definitely when the pr for blob signing and points is sort of clear uh with respect to Beacon apis then we can get that into the load server as well but even without that we are sort of ready to do a multi-client devnet or test net nice okay uh so for Lighthouse we've made a lot of progress on our decoupling

implementation but we still have something that's like fully workable uh I'd say that's our goal for this week is to get something that uh we can actually start testing with locally um yeah it's more or less it for us increment looks like his implementation that works with slowster but we of course would be happy to participate in some multiplayer network with this update wait uh ckcg work is going well

I've just been focusing on cleanup and stuff for the past week a reminder of the client themes that the audit will start pretty soon uh currently it's planned for April 17th but we're asking the client teams finalize their code like a weird ship before then so uh if you want to date like before April 5th would be great um on Peco side we are not yet in full speed on 44th floor we we but we are progressing a bit uh

hopefully a full speed this week let's start releasing the main net version guy and um yeah we're working currently in these mostly in the sinking and blocking port and we are starting working on the signing of blobs in the VC side but we still need to start working on the on the beacon node apis for the for Designing uh waiting for things to settle there yeah that's an update for this anyone else

okay so I guess does it make sense to you know keep working on the implementations maybe start some smaller uh some some smaller uh devnets in the next two weeks if if we can and then maybe try to use the next call to coordinate the launch of like a a longer live devnet um I'm not sure what number we're at but um and and and I feel like by that point as well maybe that longer left devnet also ends up being sort of a Shanghai or sort of a Cancun Dev nuts that we can start uh you know potentially adding under stuff to in in the future but yeah it seems like taking the time to publish

implementations and then um put it together something that's a bit longer lived would work with with the different teams anything else anyone wanted to chat about okay well yeah we can wrap up here thanks everyone and uh yeah we'll have the same call in uh two weeks bye everyone

sorry thanks bye