EIP-4844 Breakout Room #4

this meeting is being recorded okay we are now recording um hi to the couple more people who who just joined um okay so this is our fourth uh 4844 breakout uh we have a lot on the agenda today hopefully we can we can get uh get through it all um but at a high level I want to discuss kind of where we're at with the implementations uh get and presume being the two main prototypes working on and I see some folks here who like signaled they wanted to potentially work on other implementations as well um so talk about what occurrenceville ones are what are the potential blockers and and um what should we do next uh to go beyond the current devnets we have um I know there was a lot of conversations also happening about the libraries to use for kcg and clients um so if you could get a quick update on that that would be great and then uh Danny you put out a doc about uh sync yesterday that was quite good um so you can probably discuss that and then the last thing uh I really want us to get through everything else just kind of a bonus but it's uh there's a bunch of people from the community who want to contribute to this so if we can take a few minutes to kind of walk through wonders and tasks and where where people can be helpful um I think that'll be good um I don't know if we have time to do updates on the ceremony um that'll be that'll be great but uh we may not get there um I guess to kick it off uh Roberto or Mophie do either of you want to give a quick update on where we're at with uh the current prism and guest implementations I'll let Mophie take that since I've been out a few days cool of course yeah sure um so where are we at yeah so there have been a couple of spec changes um both in consensus and execution uh for one the free market updates we um we have like a fully fleshed out um specification for how like the free market and gas pricing should work and that is being implemented in um our execution client yes in this case um I have a PR open I had like APR open that was merged but there were some bugs and then I have like another PR to like fully flesh out and iron out the changes there um this change does not include um ascar's most recent updates it includes uh this changes like targeting what my client already like merged into the spec repo um that is to move the state uh from the um from from the evm to the block header and um have like a simple um gas price targeting rule for the um for the blobs um so that's currently in progress we're also currently working on the um corresponding change in consensus in this case would be the prism clients um this work is uh has been going on for some time now it's taking a little bit longer because like we kind of like to be having a framework in the Discord Channel there's some compatibility issues we need to be mindful of when implementing this change and integrating it with uh yes um so those are the two main things um where were you currently working on got it um and I guess on the point of that uh that second uh PR that angsgar isgar I know it's been open for uh a while now there's been like a lot of back and forth on it um yeah you're on the call do you want to give us a quick update of where things are at there sure so um I'm not sure basically uh how many people have had a look basically um it's a I don't know moderate uh moderate size change to the to the fee Market just basically introducing so so in in the in the EIP SS right now um we used to want to um basically charge charge and eat directly um so basically like we we had this with this floating floating gas price for for plops and now we're moving we want to move to a system where basically we introduce a second type of gas that after some back and forth we want to call a data gas um and and for now blobs are the only thing that that is being charged in data gas basically uh I think the the the the piaz is kind of most already there are some small questions still remaining around um uh well well one big one is just um that uh if if people remember there was this idea that we also wanted to to bring 1559 over to a time-based uh targeting system away from a block-based targeting system so that we have constant throughput over time even if they're missed slots uh I had an Erp there in the past and it turns out it's easier to do um if we do the success accounting that that we want to do with white for four and but there's still some open questions around do we want this to be per slot or do we want this to be per second because what if start times change in the future uh they're a few kind of attached um questions around there um just because ideally once we lock a design in here we also would want to move the main base fee 1559 mechanism over to this design as well in later fog so we have to make sure that it also works for for the main 159 mechanism and because the gas limit there is currently voted on every Buck it's a little bit more complicated so so again so basically this this whole kind of sub question around time-based targeting is still a little bit open um but besides that I think it's um yeah it's it's um most already and again it's I I don't think it's it's a big change um from from a conceptual point of view of course implementation wise there are some some tricky issues um but but yeah so so I I would expect this to be to to be merged say next week got it yeah yeah I think right now this is probably the main blocker for like launching your next version of the devnet um what is the yeah yeah is yeah so if if we can try and get this so in terms of yeah go ahead right just just from my understanding like in terms of implementation I assume you'd only want to start kind of implementing the changes once they once they're merged right because before then it's kind of tricky especially if if it's unclear whether you're gonna go with a time or slot based approach right I can imagine that that changes the implementation quite a bit okay makes sense uh would it would it be preferable then to maybe try and just uh merge this PR and then light on uh have a separate one for for moving to to time based or would it be better to just resolve this first so that we then wouldn't have to change the implementation again there is a stub in the implementation for testing we could merge and say use the stub for this Dev nut and uh have a warning on the other part um what do you mean by a stub in the implementation how would that work well there's Don's Car isn't there isn't there like a section on quote for early implementations just do X oh that's so yeah but that's that's in the existing API already that's not a new thing okay and that's a constant price right yeah that's kind of like what we're relied on for the first devnet but I think one of the goals we want for the second death net is to have like a more concrete um representation of what the spec is so we can start building tooling on top of it and start collecting meaningful metrics and having using stubs or something like that wouldn't be very useful for the second devnet right I guess if we're just balancing trying to ship in the next couple of weeks some sort of devnet then it seems like there's going to be uncertainty at least for the next five days on uh on this gas market so you know we have to find the right trade off there yeah I guess from an implementation perspective uh Mophie I'm curious like if we were to do it all block based like the current um like yeah like like the current PR uh kind of points to and then switch it you know in like a few weeks to time based um is that better because like we could move forward and at least have a second version of the devnet or is it like going to be so much work but then rip out all the block based key Market um that it's it's not worth it um it would certainly be way less work than the initial fee market update where we had to like change the payload and um update both consensus and execution so yeah I think we could we could merge this or implement this now in the devnet for the upcoming devnet and then if we do move to like a slot based um gas pricing time then that could easily be integrated with the updated devnet and we can iterate from there so yeah it will be easier I think sounds sounds good and I think they're like some partial changes that are unconfercial like changing instead of charging one data gas per block uh we wanted to go to something like basically one data gas per per block byte or something uh just just so that it's easier later on with with the time-based changes but I think that part is uncontroversial so I think uh we I yeah I could get the pr into a form where hopefully can be merged pretty soon um um and then maybe have like a very small separate second PR a little bit later if that's that seems like the most practical way to go then yeah I think that makes sense yeah um and I think the the time base versus like slot based might be something that like requires broader discussions so like yeah I want to make sure that we don't like move to time base and then there's some pushback by client teams for a reason or another and we've implemented all of that already across the different prototypes whereas like slot based seems pretty uncontroversial right that's my thinking as well basically it's split up into the uncontroversial pr and then when we have some more time to debate okay yeah that I think that sounds that sounds great any other thoughts comments on that yeah when do you think we can iterate on the the last couple little changes in this PR OnStar um yeah I was basically holding off a little bit to to get this the time history is off but then if we want to just basically fast click this PFS then I'll uh go through whatever remaining open comments there are um later today and and then we can hopefully get this much by you know early next week with the latest so I guess we'll get this region right before Devcon um and then either during or right after Defcon we can launch another definite uh using this but um and yeah if anyone's like looking into starting an implementation or like continuing one of the existing prototypes I think it also just reference that PR foreign okay alphabet okay uh there was another PR that got merged on the consensus spec by George uh about the reverse bit ordering um and uh I think the question was whether we want to include scope uh yeah whatever we want to include this in the next version of the devnet as well um yeah I forget what's the reason we were thinking why we might not included uh Mophie D you remember I think it was more of a not exactly cosmetic change but it's a change where that we're making to make proto-denk sharding fully compatible or more compatible with um full dank sharding and this change tweets the kcg crypto a little bit to make that happen but it's not critical for the for Proto dank sharding itself yeah that's correct um but the changes are also extremely trivial in that I think um you can Implement everything by just reordering uh two constant arrays like the LaGrange setup and the roots of unity um so in a way it is very easy to implement but I mean I agree you can test everything on 4844 only without implementing this thanks for that color okay so does it make sense to hold off on implementing this in the next version of the devnet okay no no strong objections um sweet and then on last bit on the implementation I know there's a couple people who like wanted to start looking at different client implementation so we have guest and prism have prototypes now um but as we get more that'll be super valuable because we can do some cross-client testing um and parents and I believe with the help of Danny you've put together a really good uh CL implementers guide um I'll link this in the in the chat here but parents you want to take a minute or two to kind of walk through that sure yeah hello hello everyone so um high level wise I have been just been thinking about like um what does it mean for a client team to implement 4844 like at a very high level so I basically break down the documentations into like several portions such as like storage requirements like what like what does the storage increase because like when we first started the big hand chain right we were advertising people to get one terabyte SSD and that's probably not gonna fly anymore with the merge and now with 4844 so that's something to consider and also the networking requirement as well just currently we advertise like 10 megabyte symmetrical and recommended 20 25 megabits per second so how does that affect that area as well and um as of syncing which I think Danny will cover that a little bit later that whatever what type of validations we should do for syncing especially just right now we can do forward seeing here we can do backwards thinking and then you have this like edge cases that you can have a block without a blob or you can have a blob without a Blog so how does that work basically and then last but not least like like uh how like how do we treat the Fortress mode with without a blob that's definitely something very interesting because right now we have this notion of optimism mode which means that the cl client can still ping the El client to sync to head but this doesn't make much sense with when a block doesn't have a blob so that's something worth considering yep so that's pretty much it take a look at the documentation and feel free to give feedback now yeah that's that's a really good overview of all all the bits um and if someone's yeah looking into another CL implementation uh hopefully it's it's useful um regarding the bandwidth concerns is um anything we can do to like um not have uh not have every note consume roots of the name of PS bandwidth of the for the block distribution are you talking about the gossip amplification Factor yeah exactly it's not root on um the consensus layer like six to eight Target rather than failing totally but it still seems value-based for given the amount of data that we're now considering like I mean I I think that certainly I would say one megabyte two megabyte is maybe untenable given the gossipation factor yeah exactly so do we have any ideas on how we can could reduce this you know so I guess the basically the two options are either you gossip the less people um or you gossip smaller things right and yeah or you yeah smaller things doesn't help if they have the same amplification Factor like whether you make it like one megabyte or like 128 kilobytes uh times eight actually just having less of payload Max but yeah I mean you can reduce you can you can reduce the fan out um or distribution Factor but then uh that potentially one increases gossip times and two uh I think begins to reduce the results are nodes aware of their own bandwidth like do they do they do clients or does the P2P somehow know this I do not believe so um because one way if if notes knew this information right then we could simply say nodes that know that they are on a low bandwidth connection say less than 25 megabits per second just reduce their uh outgoing amplification and maybe they can also set a flag to their peers saying hey like uh don't just send me the payload like just give me a notification that is available and uh and I'll ask for ask one peer for it right I mean my suspicion is that we have a very dense network of high bandwidth notes right like I would say like most notes probably easily have 100 megabit or more and quite a few will have gigabits um and so if we simply make it so that these nodes just distribute among themselves very quickly then the other nodes can easily get it from them I mean that may not be like the perfect solution for like the ultimate sort of um sharding implementation because it certainly introduces some centralization vectors among nodes but like I think 4.844 which is kind of a temporary thing it may just be good enough yeah um so I mean implied in your statement was also you know push versus pull essentially like can some of these nodes pull it down rather than getting it got exactly and this should be the lower bandwidth notes and then we can still get extremely fast distribution peer-to-peer Network because all the high bandwidth nodes just cause of it as you do and the others like with exceeding probability will have one uh of those high bandwidth nodes among their peers right so the easiest way to do so without doing deep changes to gossip sub is essentially have the blob um assuming that these are two separate Network payloads having the blob sidecar be it an optional um topic and that if you get a header if you're not on the blobside car and you get headers um or beacon beacon blocks then you then go and ask your peers for one of us and you actually know which peers to ask for the request because you know which peers are advertising that they're on that topic right they could potentially work it you know there's trade-offs here and it's kind of a hack and you know how do users configure that value and then you're kind of like Shifting the honesty of like the the healthy mesh and that kind of stuff but um there's there's so the one thing to note is that um the blobs blog for low DD is tied to the blobs now and we're curious to know like what what were the average arguments if there were any to for the beacon blocks to like always like gossip them rather than do like a pull-based model as we have now the beacon blocks yeah so I mean I guess in general it's very important this is a very important message that literally every node gets um there is a pole based backup with the gossip sub chatter I want I have uh but it's also just a product of kind of using the gossip sub stuff off the shelf you know it's primarily Augusta protocol gotcha so and and yeah so in terms of Designing like push first pull like you can always there are strategies where you're kind of like us doing some amount of peers and you're chattering to others and that's kind of what's Happening Here um you have to but because it's a high value distribution message you you have to gossip to some of that like you otherwise it becomes very slow you know you pretty much you're pretty much gossiping but just in a slow method right so I asked this because doesn't that rationale extend to blobs given that we cannot like validate Beacon blocks until um the associated sidecar is available right I mean I mean my argument here the argument here that I bring is not that they shouldn't be gossiped my argument is that it's enough to gossip it to some of the nodes at the same actually I mean I think I think if we wanted to we could do the same thing for uh for the beacon blocks um it's just less urgent because they tend to be smaller right so there's likely maybe I think I think the current system in my opinion is very wasteful like I mean they're definitely like I mean given given more engineering work we could build a much better system for this I think that that has much less overhead but some of the overhead here is also in resilience to attack like that like that's part of the Gospel redundancy is not always yeah but no but well but I mean this this is Extreme like I mean there are better ways to achieve redundancy than just sending copies right so basically Erasure coding so I think they're much better assistant than what we have now this the system we have now is just very simple the better system would require more engineering but yeah setting that aside Murphy I think um it is very important that both these messages are widely gossiped the network um you know the quote the data availability check is get all of that data um I think the intuition here is uh if the strategy becomes partial push versus pull rather than just full push or full pull then maybe there's a there's still a a distribution time in that trade-off there that still is reasonable you know it's like if 50 network is is pushing and have waste and 50 is is pulling and thus is a little bit slower we might still be able to get a distribution model that's like set up that four seconds that that we're we're good with but that's just a you know a Hope on that trade-off space gotcha thanks is there is there a way to um to only tell one of your peers uh that you're subscribed to a subnet so say I I know that I'm a low bandwidth note I still want to get the blobs but I don't want to get a lot of copies from them so I only tell one of my peers or maybe five of my peers so that the expectation is I get one block um that I'm subscribed to this I mean it's a bit happy but um that might also I mean off the shelf probably now um yeah you know you could imagine somewhere some additional configurable parameter that wouldn't be too difficult to get there and get into there but then the kind of analysis of gossips have all the attacks that it's presumably resilient against you know I think you begin to degrade something there what's is this something we need to test somehow like obviously we know we're introducing a bunch more requirements uh the gossiping level it seems unclear how much more we can introduce and what the effects of that are on the network um we need to figure out what is a safe gossip distribution number you know what is a safe number for this or you know if we're not happy with that safe number then we need to be making engineering changes pop on our end is do opening up and beginning to do some simulation analysis and hopefully we'll have something at least on the Bare Bones if we assume X distribution of bandwidth and one megabyte two megabyte blocks then this is this is what it looks like uh before Devcon but there's definitely some additional work to do here this is like one of the things I'm most concerned about um on current 4844 is that we don't know what the network can handle in terms of pushing this data around the one megabyte two megabyte safety assumption comes from Stark Wares I believe Stark wears Big Red Dot analysis from 2019 or 2020 where they pushed around large blocks and paid for them large relatively uncompressible blocks on mainnet and showed that the uncle rate was not greatly affected that's that's the best we have right now um I'll share that link yeah by the way uh so maybe now because it is somehow related look I like I'm not really comfortable because uh the fact that we don't know those numbers and I I feel that it has impacted the choice of kcg and for example if when I read the argumentation that says that we cannot use an alternative to kaziji the main argument is that either it won't be compatible with that availability sampling or it will consume uh more data but I'm saying that the impact of kcg the fact that it requires a setup is huge so I think we should spend some time to do those analysis and see how much we can handle in terms of bandwidth and storage and stuff like that and then decide if we can use another uh polynomial commitment scheme I don't know if that's fair but yeah can you can you can you name a concrete commitment scheme because we have we have done this on others so that's been done for years right okay this is not not a new idea like I mean we we have for a long time thought about stacking marker routes we have sort of using fry directly they're all very far from being practical like verify okay very far so it is very true that you can choose them and Doctor the ipas are in order of magnitude larger yeah ipas are definitely quite a bit larger um and they also only give you uh yeah so proofs would be like several kilobytes I think like around five to ten or so depending on which exact scheme you use and uh there's lots of big problem in that big proofs there's no efficient algorithm to compute the proofs uh so that's a major downside as well which we have for kcg um yeah so ipas would also only solve The Trusted setup problem and not be post Quantum so to me personally The Trusted setup is a much smaller problem than uh it not being post quantum [Music] um somewhat related to uh bandwidth concerns I'm I'm working on setting up sort of like a community cluster for observability around the 4844 test net um so I'm essentially only running it on my on my nodes but I am measuring a bunch of uh infrastructure metrics um I can also add Network metrics to that um and then hopefully some point next week I can I can give broader access to some dashboards and things like that so at the very least we have some baseline for what the current test net is using the only concern and I guess question I have right now is um how how good of a signal is um or how good of a signal are these metrics from a test net considering the test net is fairly small right now sorry if you were to run like large blocks on a test net yeah uh I just I think one they're small and two the distribution of nodes is not necessarily reflect that of main net main net might have one way more highly powered nodes and way more home notes you know like even people that are running on test Nets for that are homesteakers might not might be using Cloud instance because one they don't care about the security of that and and two you know they don't want to overload their local bandwidth so like I I don't think it's super representative and then when we get into same it doesn't mean that it's it's not worth doing the experiments but we just have to try to actually but given you know and then we go into simulations or anything like that and then we're going to be guessing the distribution of of what nodes look like um we can certainly do some worst case I'd say there's 10 000 nodes and they're 10 megabits per second and see what happens and you can also do some pen and paper analysis but uh it's it's hard can you um remotely analyze the in the um the app stream of node somehow or you can I'm not 100 sure I know you can do you can like try to measure late round trip latency but I don't think that really gets you yeah yeah yeah I just was just wondering if you basically just like does each note for like a second and see uh how much you can get through or something yeah so one of the related uh things uh that was being discussed in charted data was writing sort of like a spammer tools to just Spam um blob blob data to to a node um and the primary reason I'm setting up some disobservability stuff is so that I can spam my own node and measure performance that way um and some other analysis later on but just for this like I don't know we could we could set up some we could set up a spammer for to to do like a certain size of blob at a certain frequency on just a single node and see if we can extrapolate anything from the metrics we see from that but I'm not sure how again how accurate that would be I think that'll be helpful for a different reason though because you want the throughput on the networks to be like well below what a node can handle in like the worst case so would you think about I think spamming a single node you know if you can if you know that your nodes can process I don't know like 20 megabyte blobs per slots and we're you know considering going with two then at least we know we're like safe on that front but if like at three megabyte blobs per slot your node has issues like staying in sync or or anything else like I think that's really helpful to know um so it's different from the gossiping but it tells you like you know can your node actually process the amount of stuff that it's receiving on mainnet with like a really large error bar um or margin the safety basically yeah um okay yeah another potential idea that dunkard and some other guys what we're discussing was assuming we stay in a low gas Paradigm uh maybe even on the weekends doing some sort of analysis you could potentially abuse call data in a way like starkware did a couple of years ago um and send large blocks on mainnet but potentially do a better analysis so maybe have some Sentry nodes see the different timing uh maybe go to various client teams and other operators and get logs of like when things were received um and you know better data on mainnet I mean the best possible metric you can get is actually just seeing at looking at the stations so I would argue that uh setting up a few notes that just watched all the attestation subnets and see the delay uh for each validator of the attestations um can give you a lot of information already because it basically tells you at least for all the staking nodes how well they are doing at processing those blocks so we'd want we'd probably want to know when random nodes around the network get the blocks when random networks around the network get out of stations and watch chain data for blocks and enter Solutions yeah and would uh would 1559 make this harder to do um I mean you only need to do it for like 10 blocks or something right okay so your gasket will just go up like a little bit okay maybe 4X blue Burns yeah about a bit more that 2x yeah yeah yeah yeah it'd be a good experiment the thing is if the experiment doesn't do well it's hard to iterate on that experiment but it could at least give us some information and know kind of which direction you're going yeah I think that would be actually a really cool thing to do and do we know how much the Stark I mean Abdel uh yeah now if you could find out how much it costs from the gas price we know exactly how much it's gonna cost yeah yeah it's very easy yeah and you can have the experiment wait until some minimum gas cost to start exactly yeah so I have a follow for a question um Can Can we leverage the efficiency of kcg to improve the I mean like for example uh Edo from stockware which is on the con I talked about a system where you could do some random queries based on uh random data like Ronda for example and to do some random queries that will be included in the block to to enforce because for the moment we we we trust and we rely on honest validators implementation but can come to we leverage the efficiency of PCG to I don't know if that's clear maybe you don't you want to jump in and explain what you had in mind and yeah sorry this is completely off topic it feels at the moment but I'm happy to answer that question private messages yeah just because we have only 20 minutes I would agree if we can move this to the to the Discord um yeah um yeah but yeah I think it would be worth it to try and back to the stock where thing if someone wants to look into like how how we could replicate and adapt it I think that would be that would be really valuable um and and also I mean creating those blocks is trivia right like I mean I I can create a script that will do this um the only the only thing that needs to happen is that someone needs to set up the instrumentation so that we actually get good data from it I mean we will get some on on-chain data just on-chain attestations would already be pretty interesting but it would be a bit wasteful not to have like some notes that simply record all the attestations and give us much more data yeah so using Sentry nodes or using the diversity of nodes that may be client teams are already operating I think they also operate that's why we do this like we basically like watch the whole peer-to-peer Network um so just getting in contact with one of them if they could simply like be part of the experiment and give us that data yeah and then have to do it ourselves yeah what's the easy like if somebody wants to do this like what's the list of metrics they should be asking uh we want yeah we want for a given node when did they first see a block when did they first see every single individual attestation that they got off the wire and I think that's probably it because then everything else is chain data because then you want to see Roblox orphaned and did you have high attestation inclusion rates yeah okay so just first time to a block first time to ever at the station for each block um as well it's best if these are well it's best if these are maybe fully connected nodes that see all attestations because they're on all attestation subnets but then all of a sudden that's potentially a biased node with respect to where they sit in the mesh because they're so well connected um but I I don't know how much data coupled with many of those nodes across the world I think would still be very very good and should we try and like replicate low ish bandwidth like you could imagine doing this with like a 10 megabyte you know the 25 1 100 Gig 100 Meg and then a gig yeah I mean a few railings you know just use other people's nodes but yeah provide our own Sentry nodes then I would do a distribution of synchronous yeah pretty simple we can do that pretty easily in our uh from our main notes and then I mean I also have a few at home notes I can set those up as well I think we have the infrastructure to monitor those data already nice but do you have like do you have a way to record it like is that exactly yeah I mean yeah okay today we capture the arrival time for everything okay yeah and you have nodes that would be powerful enough to just subscribe to or uh Gossip sub channels yeah that's not hard either we just have to basically upgrade the instance and then just add more peer and stuff I mean if you think that's easy for you to do then I think like yeah I mean that would be great we should just do it and like who knows how long gas will be cheap so like let's do it soon yeah and I guess for a guests like we can find yeah to pay for the gas that's yeah um and okay and then yeah the thing I was skimming this darkwear one uh the star core post and they said they did this over a range of like 6 000 blocks is that roughly the duration we'd want um I think we'd want like a burst or a handful of hers I don't think we're gonna be doing a 6 000 block test six thousand blocks is like 20 hours or like it's like a day basically on proof of workbox yeah yeah no this is like a I think the shortest and most uh most intensive burst possible is what gives us the most information right okay like we'd rather have 10 2 megabytes blocks than 21 megabyte blocks and it's something that we can do this for a minute or two and then see what's going on and then if we want to do additional analysis assuming gas prices stay low we can I guess questions also ask ourselves before like is there any chance that we had might actually break it should we do like a one or two block test first and to see like yes yes I guess Define break it I have no worry that it would recover right yeah yeah but then those those elevators might want um okay compensation for them their statisticians okay we're going downhill quickly here um okay um I guess um parents like on their prism side is there anything like like do you need help from anyone else or is this something like your team can just set up and and and then uh we can get you know somebody else to work on just building the blocks and scheduling when the actual kind of test would happen right I think a good place to start just like a one-pager like a requirement so we can put those on paper and then share with the necessary party and I think that's a good place to start and once we have the one feature I think relatively it's it's pretty easy cool um Terence is it easy for others that are running prism infrastructure to get similar data uh well I will probably publish like a branch with style multiplication so as long as they update to that Branch it should be fine yeah yeah and then one thing that would be neat is yeah if we maybe ask like if we ask across that or find teams it would be good to sanity check that like at least another if there's another time for whom it's easy to get this data um you know getting just two that like roughly aligned uh yeah would make at least me feel much more comfortable yeah yeah prism might be like really well connected or really poorly connected due to something that we're not aware of so getting another yeah [Music] yeah um and I'm sure like we can find some other like node operator somewhere like who's not a client team who wants to do this or already basically records all of this um you know whether that's like a staking provider or like a team like uh block native or like someone that's like has highly connected mode uh yeah um yeah no this was this is really good um is there someone who feels like they want to take on writing this one pager of requirements and sharing this with uh with the group here I can help I'll make a document right now and start filling some notes and share it here okay okay awesome thanks um [Music] sweet I think yeah so we spent we have only like 10 minutes left uh but I think this was this was quite valuable um oh yeah Mega slab that's it yeah that's a good one uh thanks Terrence um okay so yeah we had a couple more things but quickly uh on the kcg library side are there any notable updates there that people wanted to share I know there's the C kcg uh effort that's going on uh thank God you maybe want to quickly give a quick update on that yeah so uh Brahman and I uh used built on top of uh Benedict miss work ckcg a library that has uh low-level implementations of all the functions necessary uh for um four four eight four four um it's built on blsc so it's all pretty fast and um everything's supplementancy um and yeah I mean right now we're just uh basically looking for a client or clients that actually want uh to use these functions so that we can build an API together basically like uh people where I think a little bit unhappy with the blast apis so like I think it would be worth like making something that actually works for clients and makes their life easy so like if there's anyone on this call who says like right now we need to we need a library for this or we need a faster Library than what we have now then would be great to connect nice and I I guess yeah I'm loafy on on the get side do you think that's needed right now um possibly um so one thing I just recently realized uh from Terrace's uh write-up of the implementation note is uh the current implementation of uh to Computing the proof from the blobs is not quite as efficient um as as I would hope and um I was gonna look into like what we could do to like optimize that um once I've done with the devnet but um I'm not sure if there are any further so we have the we have the proof computation implemented in ckcg and it's called optimized so you can use that yeah the only thing is not yet it's not parallelized so but we could do that like there's a simple way to make it uh paralyzed as well but it wasn't a priority so far okay yeah I'll definitely but it uses like uh pipinger for doing the multi-scale multiplication so it's it's quite fast cool yeah um Alexa I said in the chat uh they're from nethermine and they're looking for an implementation so it might be need to like yeah uh for them to use that to start and so we can get some some feedback on it and it might be easier to use it from the scratch to this swap whatever is it gets already cool yeah um Alexa I assume you're in the Discord and and the yeah the telegram is better for contacting you than Discord uh sweet um uh okay and then next up uh Danny you had a document about uh sync coupling uh which is something we've talked about uh for many weeks do you want to quickly yeah I was just thinking about it the other day and wanted to jot down some notes um pretty much there's two things it's gossip and historic sync um gossip we currently have the sidecar approach rather than coupling um historic sync I think is still to be defined um are still being debated more um and there's two things that I think we want to minimize you know it's the the complexity of the change going into 4844 and then the potential complexity and the change going into full dank sharding um I make an argument that on the kind of Gossip approach with the sidecar we this does mimic some of the potential problem that we're going to see and given kind of like the race condition between these two type of message Types on Gossip because we will see it in full sharding because we're Distributing pros and columns rather than the full blocks but you still have the kind of the same thing but I also argue that the signature approach that we're using today doesn't actually really mirror um what will happen in full dank sharding unless Builders are bonded and they have a signature and they could potentially be slashed um and so because of that I do question on the gossip and I've I've I think originally was arguing for decoupling as they are today but I do question the value of the decouple now given that I don't think it Maps directly to what gossip looks like in full tank shorting that said the decoupling does allow us for alternative push versus pull uh methods that we've been discussing today so in that context my argument you know I'm more just kind of laying up the trade-offs and if we are going to be engineering some sort of push first poll we certainly would want uh them to be decoupled uh additionally with the um historic sync you know we have these like blocks by root blocks by range requests where we can request one or many blocks um by a range or by a specific route um I think coupling here is is bad because I think it it kind of messes up a relatively robust mechanism by putting in a bunch of additional conditional logic especially because the pruning depth of blobs is going to be different than the pruning depth of Beacon blocks and so now you have kind of this stuff you have to handle maybe there's not a a root maybe I mean there's not a blob maybe there's um Duo you want the blob like different kind of stuff so I think it's easier to put it as an adjunct protocol with kind of these parallel methods rather than coupling um and uh if we coupled today we would add that complexity and then we'd have to remove it in full dank sharding so I think it's it's much more clearer to me that the coupling on the historic sync uh requests does not adds more complexity today and adds more complexity in the future the coupling on the gossip I could potentially go either way I think that if we weren't doing any sort of sophisticated Push Pull great we probably should just have them coupled I think it's much simpler um and doesn't bias too much in the future by doing the decoupling but if we do want the push pull we should keep them decoupled thank you for coming to my TED Talk any thoughts on that um I guess like I'm thinking it makes sense but I also think like if we do couple either a um distribution or peer-to-peer we have to like it has to be consistent otherwise you end up with a case where um you gossip like the block and for some reason the site car doesn't the appear doesn't observe the Sidecar and then the node has to like make a request for it would you rather have like the full coupled payload or just you know just keep them separate that's an argument I think again like I call that quote historic that's not quite historic retrieval but like that's also another argument for keeping them decoupled on historic retrieval just because you you you're more likely to get a beacon block than maybe this blob um and if you have one you don't have the other you're going to want to make a direct request and you don't necessarily want the thing you already have um so that's like a beacon that's a blobs vibrate requester Beacon By Request um and so but I don't necessarily think that if gossip is coupled that you don't want to decouple the historic requests because decoupling the historic requests kind of it seems independent even if you receive these things in tandem on Gossip no problem if you're getting the historic requests um you can you're you're saying specifically what do I what I want and so it doesn't have the same issue of like information being missing um um I don't think I was very clear in that response yeah I apologize no no you said makes sense I'm just thinking it like through yeah yeah yeah that makes sense and I guess just for clarity like for the next version of the devnet we probably don't need to change what we're doing for sync um but then probably the one after that we would want to um does that does that make sense I apologize for my ignorance do we have these like signed blobs by range requests in the P2P spec right now I don't think they're assigned I think they're just blobs okay but I'm I do put a note on me like there's probably no hurt in making it a signed variant but um I don't know if it's actually that valuable to have them signed for the historics because of you don't necessarily even know the proposal ID when you're getting these historic blocks so like you can't necessarily validate them independently where is it when you're in the head within a certain slot range you do know the proposer ID so you do you can pre-validate before you get the beacon block I guess another thing I was thinking of the other day which is interesting because like right now the blobs are are not chained right they don't have the parent field so for example for blob for a Blog today when you backtrack syncing you can just get the children if the children is valid then you can ensure all the ancestors about it but blobs don't have this property and I wonder if it's useful to add a property in there foreign variant or just in blobs in general just in general where you can just say if the children is valid then the parents must be valid but for now you have to verify them one by one by one by one great I I don't know if you could actually shoehorn that into the commitment scheme I see I was thinking like hashing all the commitment and just made that as a parent move or something but that's probably a bad idea um right now I'm sorry yeah thanks Danny um yeah if some folks can stay on another five or so minutes I think the last thing that would be important to cover is there's a bunch of people who've like aren't part of uh client teams and uh want to contribute to this and it's kind of a a first to have this many folks uh wanting to contribute um and and and the heartbeat is I think finding you know what are like useful tasks that are pretty uh well defined or that like no one is already on where uh they can have an impact um I guess you know I'll just open the floor here does anyone have like something they feel like would be really important that nobody's looking at and if somebody else could like take it it would make their life easier okay yeah product yeah please so in terms of implementation there are the obvious candidates around already we have for some graph prototypes and then apply those prototype that was started during Berlin in terms of tooling there's a lot to build so if you want to start smaller I would recommend starting there one of the things um is more tuning to create blobs and insert transactions or integrate it into existing tooling like Foundry and just having some kind of Explorer to view the blobs that are being confirmed on the def nuts will be really useful yeah explore to visualize the blobs that would be great um and then yeah in terms of the implementations themselves so as I understand it prism and gas are obviously the most uh Advanced uh Lighthouse uh if there's yeah if we can get a link to the Prototype I'll I'll keep track of that the nethermine Alexa I said uh they're starting to look into it I believe Trang who's on the call here is uh going to start looking at an Aragon implementation as well um so I'll try and keep track of all of those and I've put together a sort of checklist like we had for EIP 1559 if you start working on an implementation um you can just open a PR and Link it there and then if you have like issues on your implementation that you need help with um I think that's helpful because people can kind of go through that um the other bit I think uh that would would still be really good is just uh testing um so we don't have we have a little bit of consensus tests uh that I think Danny uh put together I don't think we have anything on the execution layer yet uh unless I've missed it um so if if somebody's Keen to like look at basically the hive or the state tests um and and dive into that that would be quite valuable um anything else um and then oh sorry and then we talked also about the the sort of uh um not uh basically the the spamming of like a single node a book learner I believe you were talking about that I think that would still be quite valuable like kind of getting performance metrics on one node that's being spammed by blobs and see if it you know stays in sync and whatnot uh yeah I'm working on that so I can continue working on it if anyone else is interested please reach out um I'd be happy to give you access to my note and stuff yeah um someone was saying something and yeah I was just gonna say that I think like something that's more generic that's generally always useful in these kinds of scenarios is writing either summaries or comparisons of like open issues so if somebody was interested in contributing uh I think it'd be cool to write like uh just an overview of the different ideas that you know maybe for a sink like comparing two different things and just like laying out the conversation points that have been had in calls and on the various um different threads that we've been discussing and I think yeah Danny sort of done that first thing I think the bit where it might be helpful is like for the the the kcg libraries um yeah um yeah just like looking at what's there and what they're they're yeah what the the trade-offs are I don't know if there's any other um areas like that yeah that's that's good uh I just wanted to add um something that is we get like more client implementations um alternative um tooling it would help to have like uh test vectors against um what we have in the specs so that everyone is like on the same page of like what certain outfits should look like um so for example like I think um was it Mario's brought up like a bug in our implementation of the um SSE route for the nearly updated beacon block and I think like there was a mismatch between theirs and ours and it turns out there was a bug in our Fork of prison and with the test Vector it would have been easy to like cross check what we're doing was correct thank you got it and what's the right like format for those tests like there's just like Json test or yeah I think Json is works fine um yeah I know Marius had like the ones for Emporia I can't find the link now but um yeah I think if we if we you know if I I'll try and find a link to those um and and kind of share them as an example of what it looked like for the very early merge ones um foreign okay and then Proto added some thoughts on the Explorer I'll copy all of your comment Proto in the uh in the notes for this call um anything else in terms of tooling um Mophie you have like this blob details uh repo is there anything there that you know you've been meaning to do but just never got the chance um well sort of related is so Proto has this PR in prism to um so right now the only way to download blobs is if you're the peer-to-peer network but ideally um this should be done using the beacon API even if it's like an internal API so you can just talk to your um Beacon node directly and just download The Blob that it already has I would like that PR merged I haven't had the time to take a look at that it'll be helpful if someone could uh I can link it in but um we could like oh I can repair some positions I just need a a Target to test against so I need to be clear which brands to use and which does not okay I'll stick with you offline then Proto um and I think the one other bit that's like uh that would be valuable is like a Mophie we have like your devnet guide uh for devnet one I think if if someone like wants to polish that and uh make it you know like if somebody's like going through that basically and like stuff is you know not obvious or anything like kind of extending that I think over time like making it easier and easier for people to like join the devnets um and and and like you know not have to run a bunch of custom commands or if they do you know knowing like what like the failure modes are um it's really valuable so um yeah I'll I'll link that as well but just like documenting if you're like playing around with this stuff and and finding some edge cases or issues like documenting what you uh yeah what you did to make it work so that's the next person it's slightly easier for them is really valuable yep yep totally I think yeah a couple of people have had like issues connecting to the devnet and like a troubleshooting section should uh like easy way to like figure out your problem should be really helpful cool yeah I think that was that was worth having as a conversation um anything else people think uh we need help with okay if not um yeah just uh as we're closing I've put together to sort of checklist like we had for 1559 um I mentioned it before but like I've just entered the chat here if you are working on the client implementation or start working on test vectors or whatnot uh please um add your stuff there and so other people will be able to see I'll try and add all of the stuff we discussed and mentioned on this call uh to it uh today so it's it's it's pretty up-to-date um and I think that'll be just like an easy place where we can track all the different things that are that are going on um and then would like less than a minute uh to go uh Trent where's the best place for people who want updates on the whole kcg ceremony there's a timeline document uh but generally there's a best place is the repo in uh ethereum Slash kcg ceremony repo has a bunch of resources and a link to the timeline document cool but the tldr is that it will launch post Devcon run for two months and then there's a special contribution period and we have grants available a whole bunch of stuff if you want to make your own implementation or create a unique Randomness generation please reach out sounds good though anything else before we close okay yeah thanks everyone for joining um yeah talk to you all on Discord bye bye thank you thank you all right thank you