EIP-4844 Implementers Call #26

Transcript

here is agenda very cool uh anybody want to give us devnet 7 updates I saw something akin to stability yeah um so we have a foundation definition um we mainly have lighthouse in Tech who as majority validators on the network with gets it and Adam and sharing the base load um we have a stable fan visit Network so we can use it for all sorts of blob tooling updates and one of them has been the blob Explorer it's been updated to the spec now and it works

um yeah besides that any other blob repeat testing can happen on this testing Twitter where you consistently spamming load uh avoiding doing too much right now because we did trigger an issue with basil and we want to give it some space to figure out that issue but once that's done we have everything required two consistently spend yeah we had a couple of uh periods where there were like 2 000 blocks of motivated and whatever makes it makes at home cool just waiting for the Explorer tool

but I can give you some more accurate stats there any questions for Perry on the main pointer on the client split is that because the clients are the the clients that are not taking the majority load are not as stable or because they're not online or what because they're not as stable and uh some clients are just following the chain they're not um they're not producing for the testing uh there's an issue tracker here so you can see who's the testing who's proposing who's following um and you can scroll down to see issues you've already triaged and a couple of

unanswered ones hey Perry uh do you know or like what the next steps would be for dealing with that deposits issue yeah I think that's the big one also wanted to bring it up today I'm also not really sure how we proceed with that one um to to give some more context just to meet a couple of deposits last week I think it was 20 and last we checked on Friday they still hadn't made it on the provided data set and we're not really sure why they seem to have been noticed according to the lighthouse each one voting stats so they should have moved it but yeah is the

um was there consensus on the East one data voting and process deposits or we don't know all of the tooling I have for debugging deposits are Lighthouse based and as far as I can tell Lighthouse sees everything okay um so either it's an issue on table side or it's something completely new if that's the case then Lighthouse shouldn't see network Lighthouse does see it so I I guess the the summary there is can someone from Tech who help us figure out how to see the equine

voting view from Texas perspective and that should already give us everything in there that's because technical plus Lighthouse is majority already I guess to follow home on Proto's Point Lighthouse would see it the voting would happen those deposits would be added to the chain but they'd be a no-op because their proof of possession would be incorrect so it could go through the whole flow and then you don't get new validators because it's a good theory to look into yep will will investigate a bit more adjustment

cool um other updates or discussion points for devnet7 I can give a quick status on Basu um we have an issue with the data hash operation uh we've got it expressed in our traces and we think we have it covered under Hive tests so um we should fix for that any any hour now I would say we expect to continue proceeding on the Chain once that's solved this is a regression because this used to work on um the previous demand sorry and this is something that is in Hive or can be in high

yep um we are currently failing 19 Hive tests in the Cancun suite and they all seem to orbit this issue and I'm just posting a message about the current status of all the devnets so something about that net 7.88 specs that I'll release it unknown so we'd stick to that not something until everyone's comfortable moving on and just a sort of long-term deprecation warning I guess we want to stop doing better fixed Genesis and move to Capella Genesis and we won't do that for devnetic eight but we would like to do that for devnet9

um we're also gonna be testing it offline to make sure and create some issues but we just wanted to bring it up so that there's a bit of a forcing function there um any other updates people want to share about devnet7 um dominate there's a few discussion points I'm gonna we can do the easy one first the should

override Builder flag which is a new flag making its way into the engine API that should be relatively straightforward again um I believe there was some discussion on the Discord about if this should be in devnet8 um I believe that was the kind of General takeaway from the past to all put depth calls but it would be good to hear if anyone is opposed to that make the end of the devnet you'd expect going once great okay I believe that at the

consensus uh that will make it into the devnet8 spec cool there was an item put here by Tim and there's not a link to if what what the discussion is but it's just apis for l2s um so if anybody has the relevant discussion points for that by all means yeah so I guess two weeks ago that team has this call to action they want feedback from their two team on whether the current API or the current Beacon API is good enough for Layer Two so as far as I know I we haven't heard much uh feedback from the other two teams um just like the just like whether the

current beginning API is especially get blobs is is good or is um is um useful enough but I went back and I surveyed around um Arbitron um just to be gave their feedback I guess the the most the most useful feedback I get is that like um instead of retrieving blobs using block ID it is very nice compelling for them to be able to retrieve blobs using version hash till I created this Beacon API issue essentially to um yeah to basically enable like um blood retriever using version cache um yeah um because the current their small

contract is transported um instead of using a block ID a version hash will become much easier so yeah so I mean I don't know if like I don't know if this is like a mandatory endpoint that all clients should implement or this is like optional but yeah but but I guess if Clan do implement it then that's very nice because there's some plant diversity there and then because yeah I'm sure that the Air 2 team will be very happy for this okay and if this isn't implemented then essentially the team has to identify what block or transaction made it into and then can do the retrieval from there right right

right right and there is an additional layer of mapping involved yeah yeah I understand it looks like there was at least a little bit of discussion here is there anybody else uh I think it says Larry that wants to chime in on this would it looks like it would be an added endpoint because of the ambiguity of the 32 by hash rather than using the same endpoint yeah yeah okay yeah anybody have discussion for this one Proto or anyone on the optimism side have uh opinions on how they believe they're going to use this

okay I see credit I'll just read this introduce the API by block ID in February source of optimism with L2 ideally we can fetch it by something that can be identified by El identification by slot and then consistency text result Works additional endpoints would require indexing right so this does slide this does bring some like CL complexity right because now a CL client needs like just additional mapping for a block ID to version hash so there is encryption so there is some increased complexity there so therefore I think like an optional endpoint makes sense but yeah

yeah optional endpoint is gonna end up fragmenting use so I I'd prefer not to go down that path and figure out what's needed here I guess my my question is when does an L2 when is an L2 not aware of the blocks their transactions made it into you know because that would that would be when they're they'd have to do this extra mapping right because like for office from currently only version hash is is stored on channel they don't store any block ID related things on Shin so to verify the blobs they can just get the version hash

from the onshine contract and do a quick lookup versus like some like another layer of mapping to map block ID with the version hash foreign yeah okay probably zoomberg

further discussion on this thoughts on direction we can take it or at least take it back to this issue yeah or yeah if there's any additional comments please comment on the issues very cool thanks brother is arbitrim on testnets on our assessments or have a plan to join and same with uh thank you optimism I get yeah I can speak for our big strong I there's definitely plan to

join as soon as possible just we're waiting for things to stabilizing a little bit just because I know definitely a is coming so I'll probably wait for definite a when we have most of the things in there okay cool yeah okay this is probably I will bring up again but in the context of uh as we get into the more and more serious chestnuts we should be inviting more and more teams to do prototyping and getting feedback hey brother I saw you reach on anything you want to toss on

okay I'm sorry now sorry about that okay so about the API thing it's either indexing or from time step to slots current API works it just isn't like ideal no for their two participation we are looking to replace our prototype in the latest version of perfect firm um it's just timing we need to figure out like when to to execute on this and join a definite right um we'll keep this conversation going in

the coming weeks uh either on this caller on awkwardness anything else on the api's discussion and Terence if you do on a surface that issue on the consensus layer call to push for more feedback we can um if we don't get sufficient input there anything else on devnet8 next up is

a PR to the execution apis um clarify Cancun payloads handling by early apis reorder checks um I guess this is not even necessarily for four specifics and we have the context here um hello uh so uh helps to clarify some Corner cases uh help we handle okay three uh payloads by V2 and it also reorders checks uh I would say defines order of validations needed for a new

payload uh get payloads methods so we um it's now it becomes more clear uh interest of in terms of testing and implementation on what error codes we should expect in different situations uh connected to timestamp and um other fields are passed to their apis so it is expected that um V2 and V3 methods should not

um should decline requests when timestamp is not of correct work and additionally if any [Music] in there additional fields are passed or fields earned Bust or contain null values it should be declined with the different code of invalid params and this request well orientation was to clarify this is Kernel cases so is this non-substantive

like does it make any it's all clarifications uh yeah mostly clarifications and it's very um like useful for characters and when we have some and find like behavior and you should it would be good to have an idea on the next illness okay I saw Lucas just approved um and that make a little too why don't we have this up for another day or two for eyes and then get it in that's good

MX estimate it might require a slight modification of checking the constraints so this PR makes El to check that this strict set of fields is passed onto the method so if more fields are passed should be rejected this is to Aid find inbox um in on the earlier stage of development icon devnets um ifclass is up with the the structure or with the method or with the timestamp meaning that it sends a payload of say Cancun on tuition High method and vice

versa so got it okay any any questions here great thanks Mario thanks Lexi okay we did slate uh sometime if there

were any updates on some of the CL gossip sub uh modifications that have been under discussion um both flood staggering I do not want and other things to that tune um anybody that's working on these r d Avenues have any updates uh yeah hey uh can I say a few words about and working uh so yeah uh actually uh there is uh I don't want PR uh but I must say that I don't want this not like a silver bullet it's just a actually a slight um quite optimization or uh of course large messages

uh it mostly it mostly reduce the total a lot of network so uh not not not a great uh latency Gainer uh we also uh go into add another PR to uh Ghost Ship it's uh ping pong uh yeah it's uh it's actually could be used for several things uh yeah and uh those are also like uh small uh all of them so all of them it's actually small small optimizations uh yeah which which we probably need to uh to do testing in real in a real world um yeah the main uh uh actually the uh

like my general uh impression is that uh the block block decoupling which is also which is already done uh and uh like it's what publish uh fix uh would probably be enough or uh or or eight or four uh and uh yeah and probably um maybe maybe all other optimizations could be done like uh asynchronously uh for a promo client because they don't need the like artworks uh uh so about what published actually I have

like a simple simple idea for uh for uh resolving this issue is just all right uh just the disabling of what publish for uh blocks and blobs uh topics uh it should probably work quite quite okay so we we have no security issues with this I believe uh yeah because I actually don't yeah actually I'm not sure I'm not sure uh at which point we uh enabled what publish I think it's it's like for uh for more efficient station uh publishing yeah probably soon before phase zero it was

enabled because it seemed like an obvious optimization and people didn't think about the parallelization issues too much yeah probably probably it makes sense just to disable it for uh blobs and blobs let's see I have a question uh when you disable it do you still send the messages in parallel to the peers on your mesh so you still might hit all right but just not yeah right Crazy Ones yeah right right but it shouldn't be big deal for uh for a good uh for good bandwidth uh but uh yeah but actually staggering uh uh staggered standing uh like would be

good to have but as I say that probably another optimization with that we could uh enable uh later should we in the um clp2p spec actually make a note that flood publishing should be disabled on those topics uh yeah but uh yeah but actually currently currently what publishes like a global option for gossip uh yeah so there are there should be uh it actually my um another another approach is just to disable it for uh for messages uh

larger than some thresholds is that but that would still need to go into the P2P Olympia yeah I'll give you something yeah right kind of configure right yeah right okay I think I think we had a discussion that we don't have to disable the the fat publish right it's like uh we can't stay with remote but we can just uh send the message to the non-mesh PS like later instead of like immediately so right yeah but it's more of just this is those are that's not like an easily

configurable thing for libpdp like that any of these require going into and making deeper modifications right yeah that uh yeah that also the uh like the question later is uh it's kind of um uh I don't know how to say it's funny because you never knows when your uh when your message like was maybe you should just stop instead of sending it to your 50 other peers yeah uh actually for large messages uh like uh uh I have uh I have message already when uh

uh like during the game because uh it signed into 100 peers message like of size half of a megabyte would trick would most likely take more than one third beat so you most likely will be sending I I have messages from in this stage does I just realized I was muted did you hear

any of that do all clients have like an r d path to like do either the disabling or the Staggering or is that is still an unknown for a few clients I know age is working on this for Lighthouse but I don't have too much in the way of specific updates I'm not sure yeah I have to check I I actually think age is planning to add like disabling flood publishing in the next White House release but I mean don't quote me on that got you okay okay so this is the

one of the single biggest things that could change the uh success of these large messages and definitely prioritize getting it out and it's I guess nice that if a client or two don't do it then it'll just affect the client in question and the proposals for healing from that client but it'd be best to probably have this across the board okay Anton you said on the I don't want you said it's it's not really a latency gain it's more of uh to

help reduce total bandwidth consumption total load is that do we have that Quantified at all uh sorry uh yeah right it's not so it's not like uh yeah correct but do you do you have an idea of the potential reduction in total load latency aside yeah we have so yeah we have it uh that at least uh of potential uh improvements uh yeah it includes staggerate I think that probably the uh the best gainers if uh

staggered sending could be implemented uh in a good fashion probably then we have like TCP gcp slow start issue uh yeah affects a lot uh yeah we we have a we do to work around and it's like like a frequent thing so uh yeah that that would be like not very good solution but it should work if we if for example if we Implement like goes uh if we can ping and gossip uh like once once uh like once per 200 milliseconds uh yeah it's actually dirty but it it works

uh yeah uh so yeah so I I think that the staggered sending and uh TCP slow start are the next things we could uh we could address yeah and uh yeah that that gossip in Punk messages I mentioned yeah they're helpful for staggered sand and TCP slow start of avoidance also yeah I I don't want just just like uh um easy way to reduce uh total load right on the on the reduction of load

for I do not want or I don't want is that Quantified you know is it a 50 reduction what's the it's kind of a uh it's kind of 30 to reduction uh it's okay yeah it's a it's my simulation results uh but yeah that's it's kind of three to five latency reduction so not huge other networking discussion points or questions for Anton uh do you think do you think we should

have uh uh do you think we should form the lipidopy the big level like so that we can we can have our own spec and like we can add anything we want to respect yeah I mean that's certainly a path um I think that we're we're better off if we can work with the larger lip p2b community and have shared tooling um and thus don't have to support the software as well but if we do hit a hang up that's definitely an option does anybody have other

opinions here yeah I mean and we could also if we're having timing issues we can fork and try to then merge a backup stream um if we need to to work around but I would try to play in the same environment if we can cool other networking comments

okay any other discussion points for today yeah I would like to ask other execution clients like about replacing of block transactions do we have some consensus on how much must be a bump of Maxi Burgas Max priority per gas and Max FIFA data gas but this is a mempool replacement yes Mars do you know the rules currently in

place in the gethman pool um I'm just looking it up and then I think importantly are there rules around I had a blob transaction and I switch it to a non-blob transaction I guess you want the replacement V to be on that high end rather than the normal transaction yeah so I think right now we have 100 for everything so basically you have to

uh increase all of the fields by 100 so double and that's to go from a blob transaction to a blob transaction and to go from a blob transaction to a another type rate um that's to go from a blob transaction to a block transaction I'm not sure yeah sheep to the other no so we have um we have one thing that the one one thing that we implemented or

the Peter implemented is that you cannot have um two transactions in two different pools so basically the The Blob full is its own transaction pool and the other pool is the normal pool um and so what you cannot have is one normal transaction one block transaction and then another normal transaction or something like this so um that's forbidden in guess so once I have a nonce in a particular pool for an account I can't swap pools yes I'm not sure about replacement though um and once once you're once the

transaction is mined um you can have a transaction in a different pool Roberto yeah we discussed this um quite quite a while ago at this point but I think one of the proposals that came up and I don't know if anyone followed up on it was to disallow any attempted replacement of a blob transaction with a transaction containing fewer blobs because in some sense you've already kind of taking the hit once you've processed it right and so it's just a potential denial of service Vector but that was just one idea that had been proposed before so like if you have a one blob transaction you can only replace it with another one blob transaction or something with more Trend blobs not

something less I don't think anyone's implemented that at all anyway from uh what was discussing it was even like and that for blood transactions only uh fields that we see content like all others must remain the same to replace it but making it possible to add more blobs my substance like it just needs to have consensus here um yeah I don't know I I cannot really

I don't really know what the relative rules in gatha right now so yeah I I basically I think that ansuka is right that um we don't expect many people to use these transactions and the people that use those transactions um are very Capital heavy organizations that can uh provide the or like write their own um transaction relayers and stuff too um to do so yeah regarding the rules I think we should maybe discuss on an awkward if

when when Peter is also part of the discussion yeah it'd also be great if I know Peter's done a lot of the thought and design up front and then probably has iterated quite a bit on the design um if we can just document what the rules are in Geth at some point might be useful for everyone try to bring it up in ACV e with Peter anything else on mempool they'll have transactions please

okay other discussion points for today great uh good work on dead net seven um excited to see it continue to stabilize and get some more you can climb distributions over time talk to you all very soon thank you thank you thank you bye thanks everyone