All Core Devs - Consensus #116
All Core Devs - Consensus · 24 Aug 2023 · 37:31
Ethereum consensus client teams and researchers meet on the All Core Devs Consensus call to coordinate protocol upgrades. This call covers Deneb, with devnet-8 updates and an overview of Dencun testing.
Speakers
Topics
From All Core Devs - Consensus, hosted by Ethereum Foundation.
Transcript
foreign [Music]
Danny Ryan: I am remiss and put the agenda up last
night before I went to bed uh and so it's a pretty light agenda but if you have items that you were not able to add to the agenda decision it did not exist please jump in uh drop a bunch chat or just chime in when we have time
okay uh so we'll take a look at the NAB um and then one of our open items that's not currently denied related is I've never said this word out loud polisky um the test net launch oh so we have a couple things on that and somebody can correct me if that was totally wrong um Okay cool so there is some space for devnet updates um I believe there is a devnet out and there are things running none would
anybody like to give a current status update
Barnabas Busa: yeah sure uh so definite eight is running we onboarded all the different clients and currently Aragon and bezu don't have any validators every other client has a validator they are doing very good uh I just made some deposits for Brazil this afternoon and this should arrive soon to the chain uh bazoo has been confirmed to be able to do block production on pertussis and uh I'm working on Aragon right now trying to figure out what is uh going on there
and the other Thea client that is not working right now is prison so hope hopefully we hear something from the prism team on that one
Terence Tsao: I can give a quick update so uh we have a fix out there already we're planning to merge it today so yeah you should be hopefully working by um by the by the end of the day
Danny Ryan: I'm always just kind of curious what sort of failures we're seeing in this state
like yeah
Terence Tsao: yeah yeah definitely I can give an update so the prism issue is that we request block by root example that we are missing Blood by basically a
short range block day to day you get an authentication you don't have a Blog you basically request a Blog by Ruth but we forgot to request blobs by root after that so essentially the processing of the block gets stuck
Danny Ryan: I see so we could potentially catch this upstreaming kurtosis and if we do get some CL networking tests in Hive can catch it there as well
Terence Tsao: yeah
Danny Ryan: thanks um any other questions or comments related to devnet8 are we regularly sending blobs and doing
anything other than just steady state
Parithosh Jayanthi: at the moment there's some blobs but it's basically steady state
Danny Ryan: gotcha
Barnabas Busa: maybe Mario's can begin hardcore fuzzing on it no because they are pretty stable
Danny Ryan: cool um next I wanted to go over this thing contesting overview that Perry and mothers put together some of this is pretty standard but some of this hopefully covers uh some of the
components that we are new you know for example exceptional blob networking cases um Perry or are you the appropriate person to to go over this document
Parithosh Jayanthi: I can go over it so we've created this testing sure I can yeah thanks does it look okay
Danny Ryan: yeah thank you
Parithosh Jayanthi: so we have this testing overview talk and the main aim of this is to create a list of different ways we're approaching and we want to know if we're missing something early on so that we can
allocate resources to get that done ASAP we do have a couple of needs at the current stage none of them are Urgent so we will be getting to them over the next couple of weeks but if someone's free and wants to take it up please feel free the test net verifier for example would be used in kurtosis and a lot of other places essentially something that we can use to verify that the test net is healthy Sig test coordinators the same one we used for the merge tests it just needs an update and some loving care after about a year of not really using it and the other ones we we do have some sort of testing in the pipeline so please reach out if you're planning on
working on them but besides that it's just an overview of different categories of testing so we start with spec tests shall we um I think nothing is really new there for ebm related testing uh we're banking on hive evm sizing execution specs and I think Mario and Mario's Etc would be kind of points of contactor um with sync testing since we will be having a couple of new dependencies with the blobs we wanted to make sure that we can sync test the basic scenarios so regular syncing after blockage blog expiry Windows checkpoint sync syncing when blobs are inside the window but missing and Optimus fixing tests
we still need to figure out how we do it with the sync Target we might need to wait until we have it on a public test night before we can get this up and running and of course Hive also already has a lot of sync related tests built in um kiosk tests are something we have been doing in the past with antithesis um I think Tyler's kind of been the main point of contact a lot of you might have interact with on the topic but Barnabas has also banned this and I have also been looking at chaos mesh along with kurtosis um so the idea is that you can cause a lot of network level instability uh resource level time related faults and you should be seeing something on this
topic over the next month I think we still have really Alpha ideas on this but it seems to have some legs and should be able to help us with testing um and public test nests so we have devnet shadowfox and begin metrics Gaza that would help us with some optimization related topics um we have Mev related tests so ketosis now supports two modes first mode is mock Meb and that would use Mario's um mock Builder that has an implementation of the Builder API so if you are a client team who wants to have a Target where you know the API has been implemented you can use it with Mev type
mock and knock out a lot of local bugs that might be happening or versioning issues and ideally once the relay side of things are up and running you can switch this Mev type to full and that would spin up relays builders the relay API endpoint and everything so this is literally uh the Meb workflow that you would see in in main net ethereum and there you should be able to test the entire integration end to end I would see that more as making sure that all the different entities work together and we don't see any surprises when once we hit the foreclamp in it the other thing that the mock Mev Target supports
is invalid payloads so you can configure when an invalid payload happens and this is really useful for checking circuit breaker conditions so that if something does go wrong we need to make sure that nothing happens to of ethereum clients um and yeah a couple of uh more tests we have were regression tests I think historically we've tended to Hive for regression tests but if they're more complicated ones courses also supports a golang SDK now so you can orchestrate a more complicated test scenario with ketosis still really Alpha and we're working out some PRS here but um but actually something to know about and then anything related to bad blocks
bad blobs we have TX fast that Marius is working on and should be relatively up to date as well as some internal filing tools by the security team and we've list listed down a couple of uh blob specific tests this is largely based on this really nice um PR from I think Peta where he talks a lot about the blob strategies of the goeth theorem kind and we kind of took everything that he claimed as a issue from there and made it as a topic we need to test in the future um it would be great if client themes can also kind of coordinate and tell us more things that we should be adding here we're still not necessarily sure
which tool these tests would end up on but it is something we would need to look at um if there's something on this document that you um would still like to see please reach out if there's information you want to add there please reach out and um yeah we just wanted to kind of use this as a way to so that everyone has an idea on what sort of testing is being thought of and if we're missing something that we can catch a double
Danny Ryan: awesome so on these blog specific tests definitely um talking with a number of consensus client teams like the uh exceptional networking scenarios I think
are top of mind and so things like staggered sending you know I got blobs I didn't get blocks until later I got blocks I didn't get blobs till later you know I got this message not that message and um I guess Network partitions or other types of like reorgs where I'm going going to have to backfill um I think that's like top of mind for concern you know seeing devnet 8 run relatively stably is great and then but I think it's these like exceptional pads um that people are pretty pretty worried about so if you are a condensed lawyer team and you have been thinking about some of the P2P exceptional cases that you're worried about I think this list is is top of mind to review please
and yeah Mario's like the the bad blob generator from like the transaction gossip standpoint I think is important and also insertion into blocks that we have some failed blocks um but I think there's also some tooling and things we want to think about like on just the CL gossip component of these you know sending one without the other sending um things in like very asynchronous staggered ways
Parithosh Jayanthi: yeah in case someone already has like malicious client ideas that we could use please let us know um I know there's a couple that we've thought of I'm just not sure if it's a perfect tool for the job
Danny Ryan: any other questions or comments here
should people leave comments in the doc or should they reach out to you directly if they have things that they want to uh they have questions about
Parithosh Jayanthi: I think to minimize chaos we've set the permissions that anyone um I can actually just change the permission such that anyone can comment maybe that's easiest okay if it's something sensitive then please feel free to reach out to me or potentially anyone from the testing team or security team and I'm sure we'll be coordinating on pretty much everything
photos
Danny Ryan: is that
an addition or a concern
Potuz: I don't know so they were asking for malicious clients those two would be the first ones I would implement
Danny Ryan: yeah cool okay anything else related to testing Cancun great anything else related yeah go on
devnet 9 in relation to 4788 would it
actually change anything now that the kind of spec on deploy is set um I guess because on devnets we might still deploy in this kind of like genesis configuration although I suppose we could create the Genesis have a significant delay before dencoon and actually do the like manual deploy method so maybe that's worthwhile doing in devnet9 is that the only difference in the specification at that point
Parithosh Jayanthi: I think so I don't think there's anything else that's changed since the last event
Danny Ryan: okay so I guess it would give us peace of mind that like this uh synthetic transaction or address method Works
um but we would also see that certainly on uh the next couple of
test
Parithosh Jayanthi: then um yeah so we wanted to kind of decouple that a tiny bit and kind of push everyone who thinks they're ready with the Builder's law to start using kurtosis today um or maybe tomorrow because I know there's an open PR to the mock Builder um but the idea is that by the time devnet9 or devnet 8 with with the builder workflow is ready it should be a
nothing burger like we should have tested everything locally already
Danny Ryan: yeah it's almost like devnet9 if it even exists pretty much is should is probably short-lived it's probably like testing the fork testing all the load testing it looking like mainnet um whereas like devnet 8 we really should be we're pretty much at spec other than the deploy method um and can test everything here
Parithosh Jayanthi: this is one of the kind of open question so the past folks we always had one long living test net that we kind of publicized for people who are working on Integrations um examples um do we need one this time around or
since we would have hurts key soon or girly you should be just Fork it
Danny Ryan: I do think we need a place that we are
telling validators to test their setup um and it could be an A1 of those I think we just need to like make that clear like at some point we're at production what we think is production setups and say if you do want to test your setup this is this is the place
Parithosh Jayanthi: there's just one other point I want to add we still don't have a final decision on two four or three six um and at least my talk on the topic is that we should experiment with 36 on girly if it goes badly then no big deal but if we try it with three if we try three six on whole ski and it goes badly then we kind of have a lot a lot of coordination for nothing
Barnabas all the claips are in
Barnabas Busa: uh yeah but we haven't written it down I I guess I will add it to this
Danny Ryan: because yeah okay if you're pointing to the CL spec release that encompasses that but being explicit is probably better
Barnabas Busa: yes sure
Danny Ryan: yeah what's the reboot cycle on ephemery
weekly yeah I mean that honestly is probably the appropriate place to point people to but we just need to integrate once we have specs finalized integrate builds over there um yeah I agree Tim why don't we work on like a straw man proposal um and that we can debate on the next call and kind of have an agreement by them uh anything else related to devnets testing test Nets that we want to chat
about today
Barnabas Busa: I think there's another topic about holistic that could go through yeah let me just real quick
anything else on denab dencoon
small proposed change for the Builder's effects uh this is just to change the constant used in defining the blinded blobs bundle struct instead of using the max blobs per block constant which is like the three sorry I think it's six right now and it's sort of the networking limit
for blobs the consensus layer limit use the constant that's actually used in the body of a beacon block and the reason is this struct is actually signed over so in creating the signing route the value of this constant actually like will change the signature if it changes um so using the max blob commitments per block constant makes it so across a hard Fork like signatures are the same we don't have to worry about this um that'll be the reason to do it but if you take a look at the link which I post in the chat it's very small change
um yeah
Danny Ryan: yeah that seems to make sense um does anybody have any opposition or want to review and throw a comment up in essentially we have a value to keep the the tree the same shape for the consensus so we might as well use it here okay cool um yeah take a look Stokes and uh seems like we can probably merge this pretty quickly
thanks Sean other uh didn't have related items before we talk about
husky okay Byram
Barnabas Busa: so there's a couple of topics regarding we initially thought that we should uh be having Chapel on apoc 10 just so it's convenient for us the winter if anything goes bad but there was an argument uh to make to change that to 256.
uh there's an open PR about this I'm just curious what the different CL teams think about it
Danny Ryan: what was the opposition of 10
Barnabas Busa: that is not power of 8196 slots
Danny Ryan: so if we were testing error files and things uh it would not have the same kind of conformance that we've sought on mainnet
Barnabas Busa: right
Danny Ryan: I'm not sure if yasuke's here but I'm sure
um you would very much appreciate that and anyone else that might be testing error file distribution and given it's like kind of a one-time one-day cost and it seems to make sense to me
Barnabas Busa: is there any opposition of doing 256 because then I will get it merged ASAP
Danny Ryan: okay yeah sounds good
Barnabas Busa: next the next topic would be ejection balance so I will did some
calculation and we derived that we should have 28 uh ejection balance of 28 instead of 16. so this would lead to a nine-day ejection period in case of non-finality any oppositions against using 28 instead of the 16.
okay none for me
Barnabas Busa: and the last one is regarding Genesis
State uh currently the uncompressed Genesis state is 198 megabytes and we are aware that this is probably not something that client teams want to include in their binaries and uh there's some different ways to get this Genesis State one would be just an S3 bucket and have a URL pointing to that S3 bucket and each client would just fetch that Transit State on Startup or from checkpoint sync but we would need to have an agreement regarding whether we would want to offer this Genesis state in a compressed or an uncompressed format so the benefit of having it in a
compressed format is I think it reduces the Genesis size to about half of the current size maybe a bit more than half but it would require more compute from every client to decompress it
Zahary Karadjov: I personally tested some formats such as Snappy and zsdd and indeed they took the sizing out and my own suggestion would be to use Snappy because every client already needs to have a snap implementation anyway
Danny Ryan: I'm sorry was Barnabas were you
suggesting using a different compression algorithm
uh I'm
Barnabas Busa: I'm just curious whether we want to support a compress or an uncompressed Genesis state for checkpoint C
Danny Ryan: yeah a person notes that this is just a one-time thing as you get your client um up and running and so the compute probably isn't a worry and it's probably easier to well I mean I feel like the implication is the compute's not a worry and it's really easy to reduce the download um especially because as disease Snappy is already embedded but maybe you're implying otherwise
Barnabas Busa: I don't know that that's fine just uh
then you should make sure that every client is expecting an uncompressed or a sorry a compressed Genesis ssz file yeah I don't think seku is currently supporting that but if there is consensus and everyone other and all the clients are is already supporting them we could start thinking about that another option would be a is what about what about this exposing the the Genesis state in in HTTP gzip Stream So the the compression will be on the on the HTTP side instead of on the file
makes sense
Parithosh Jayanthi: yeah I think the idea is just that we wanted to use as much as we can um purely because Genesis is in like three weeks
POTUS
Danny Ryan: notes that the spec tests are Snappy compressed States so there's some path that techu is using there okay so on the SD file format it's not
just a zip version of this okay we can double check that
Barnabas Busa: okay so the journal consensus was that it can be compressed
Danny Ryan: yep okay are you implying that there's a there might be some tooling and configuration mismatches that the server needs to be aware of
Zahary Karadjov: no no what I'm saying is that um they're
not so kind of already available tools that you can use on the command line and say the devops scripts but there are some just I'm mentioned this because it may be not obvious
Potuz: yeah I second that I try to look for a command line uh tools to use snap it directly and I couldn't find anything yeah I had to write my own
Zahary Karadjov: I did find some and yield them successfully but still something to be aware
Parithosh Jayanthi: thanks for that could you maybe post some links of how you guys came through the problem because then we can Upstream it to zcla which is typically what we're using to inspect the SSC files
Danny Ryan: okay anything else on this one
Barnabas Busa: that's it thank you very much
Danny Ryan: um that is the end of the agenda as I noted I put the internet up pretty late so are there any other discussion points for today okay excellent um thank you all for joining uh we will talk on acde next week or good luck with all the
test nuts bye thank you bye bye guys thank you
bye thank you [Applause]
Speaker names adapted from ethereum/pm, CC BY-SA 3.0.