All Core Devs - Consensus #103

Transcript

foreign [Music] thank you

[Applause]

Danny Ryan: okay welcome to

census Slayer call 103 this is issue 731 in the PM repo we'll go over capella 444 which maybe should be renamed Dan on the agenda uh then General open discussion if anybody has any any points from there on capella uh devops folks or otherwise do we have any test net updates to share

Barnabas Busa: sure uh I can start you saying that we have shut down W7 this morning uh we did this as uh with the last uh big uh updates uh everything seemed quite all right we

managed to get 359 000 uh yes change it through so everything was good my only concern was that we were not running the final client versions yet so I would like to run one more large devnet just after Sequoia fork in the beginning of March just to make sure that everything is still right but everything's in okay

I'm definitely oh

Danny Ryan: so before the fork those were kind of pre-loaded into the pools and then uh were any messages dropped

Barnabas Busa: uh so the problem was that some clients knew some research to update their clients after

the uh after the fork so it's very hard to know that what was actually dropped before and what was that because uh when I restarted I was to republish those messages so I see that's why yeah that's why uh and you definitely might be needed here and uh you define versions without requiring any more client updates okay thank you overall overall was uh a very good test I think because we did catch some issues with the uh deposit cues and such so everything looked good

everything looks quite stable still

test net

Parithosh Jayanthi: we started testing relays and testing Mev boost in general we are good on the happy case so now all clients support um map boost and we're getting blocks built and proposed by all Clan combinations the next step is to have it running with the edge cases on on withdrawal main net Shadow folk 2 and midnight Shadow for 2 was launched yesterday but we haven't set the capella Fork yet we're mainly waiting for more relays to come online

so that we can test circuit breaker conditions as well as some failovers Etc but we'd most likely be doing this over the next week we're still waiting for so many days to come online

feet

Danny Ryan: fantastic thank you and uh we'll get into my Boost update shortly anything else on testnets before we move into some of the hive testing progress okay um and they're the the septemberia test net Fork announcement went out right

Tim Beiko: correct and um two updates to the blog posts that should be merged in the next

few minutes our uh Geth has put out the new recommended release so V 1.11.2 uh the one in the blog post now is still fine but they recommend switching to the new one if you can and uh Lighthouse uh had not put a lot of release when we published a blog post but it's uh it's been put out yesterday so uh the 3.5.0 for Lighthouse uh is the right version there um and yeah the blog post should reflect that in the next hour or so

Danny Ryan: great and if you're listening to this if you're a validator this is a closed validator set so Gourley uh will likely be the place to test your knowledge or stuff though infrastructure providers sepula is a great place to be testing

okay let's move on to um Mario let's you've been working on some Hive um boost Builder API stuff can you give us a update on that

Mario Vega: yes of course so I prepared this um this page with the results basically we build a we built a um Hive um have Builder API a simulator what this contains is a builder mock which basically simulates a working um Builder API module that uses the execution client to relay build payloads to the to the to the consensus client

um so yeah every time the uh the consensus client uh requests a builder API a builder payload it simply relates the information back to the execution API and with this we have like a simulator environment where we can crash or return um invalid payloads to the to the CIA to the CL on demand and in this page I uh is this is the result of one simulator where basically we have a working Builder up until capella and then after capella we um restart we start returning invalid pedals in a way that the Blended payload looks

legitimate but when the when the debate of the supply you you can see that the state route of the execute execution build is incorrect so what happens here um is that after the unbladen payload you can you you have return and design uh beacon block but this is invalid so it will not be added to the picking chain and with this we are we we can start simulating the the scenario where uh the slots started getting a start getting missed so um well after this uh we we are basically just trying to test the circuit breaker in this scenario and you can see all the results of this test

here um basically um the case for Lighthouse Tech in prison is that they start um correctly circuiting secret breaking the uh the the Builder after Knight missed slots in the current epoch and this is working correctly as you can see there's a maximum of 71 of the slotness in the in this scenarios um and then we have uh but but we have our log star enables we have this scenario that they don't stop requesting so basically under the big engine circumstances that the Builder API starts simply causing missing slots um depending on the on the client

combination we with the support with this here we tested um two plaintiffs per simulation and they um and then we have all combinations here for all the client types and um the the one the the ones that uh filled most slots even when the mouth with the malfunction Builder are the lighthouse taken prison uh but if else our numerals are included in the 50 on the evaluator key set basically the the the the default slot uh percentage drops quite a bit so um yeah to summarize the circuit breaking uh tests are working correctly for Lighthouse Texas prison but the

other other clients are exhibit in some kind of issues and yeah this is currently where irrepresentable is high uh I include all the steps here to reproduce it if you if you like and yeah we can run it again if you made any modifications to the Supreme breaking logic we can run any any test again that you that you require

Danny Ryan: yeah so importantly to note um we decided before Bellatrix that the circuit breaking logic would be left client to client on on the parameters and how they perform that and so um it's not specified that it is a must and it's not specified exactly how many slots so uh my question to Nimbus and low stars do you implement circuit

breaking logic or is is this the expected Behavior

Gajinder Singh: uh we actually implement the circuit breaking logic and we are on the conservative side in fact we start with the disabled filter and we only enable it when we see some percentage of slots uh properly uh being proposed in the network so we are basically on the conservative side and I can look into the test and see what's going on over there

okay great thank you any information so

Zahary Karadjov: this is actually a gap in our implementation we haven't implemented

the latest proposal yet

Danny Ryan: okay great so so Mario yeah given that the this is not specified you kind of will need to parameterize these tests on the expected slots per I suppose um so you know Nimbus I wouldn't say is failing and then this is doing as expected whereas it looks like lodestar you know is is not performing as expected but this is awesome thank you Mario any other questions for Mario or Mario did you have something

Mario Vega: no basically just what the test expects is just finalization which happens every time

um I assume it's because even though we have missed slots uh or both clients are actually attesting to the available slots so right we are always getting

finalization

Danny Ryan: um we might consider that being like a recovery of a percentage of slots rather than finalization um just I think that'd be a more valuable red or green but we can talk outside

the column

Mario Vega: of course thanks

Danny Ryan: okay anything else on

test Nets or testing for capella there was a new release primarily this deals with report before dencoon but there was an additional test for an edge case found by Paul I believe most of y'all integrated those tests in our passing but just that's relevant here okay great uh Chris I believe has joined us from um flashbots to talk about my Boost updates in

relationship

Danny Ryan: Chris hello great to be back I wanted to share a quick update where we are with my

Boost implementation on the virus cards and the testing we are successfully uh having the whole end-to-end system running on the chase young Network the changes are implemented in math boost and their in math books itself they are finalized there's also a release out there by the way let me share a document in the side chat where I put together the current status across all the projects and links the pillar stack specs they are merged and updated special shout out to Jimmy Chen on the map booster relay we have a bunch of open PRS that are leading one into

the other and that we are running on Chase young and it is working I think we are wrapping these up today tomorrow and then by early next week we have a final math boost really release but any other math boost related Builds on our code base can take a look at these rprs that are also linked in the documentation and and get a pretty good understanding what has changed or even any other reel that wants to upgrade and meet some pointers please take a look I think the this is for PRS they are nicely separated and the last one is to automatically switch between Bellatrix and capella that's the new functionality that we

added yesterday the Builder is also updated the validation node also prism we implemented the get withdrawals API in our prism Fork because they really need to know about the withdrawals to validate the biller submissions it would really be nice to remove our custom Fork we would need this SSE event that notifies about new payloads and payload attributes there has been a bunch of discussion about that and like a reignited interest let me let me link the issue here so if we could standardize these SSC subscription and I think this is on the agenda later to talk about that then there would be no need for any custom

prism fork and basically anycl client could be used to trigger block building and to drive the relays and last of all the types we had a special type suppository that had all the Bellatrix types and there was a big push to move everything into the attestance types repositories also thanks stream for support the these types are very well supported and then there is less repositories and duplications to maintain um yeah next up we are wrapping up all the PRS and merging the changes into the main branches there is no big changes expected anymore

and we are going to participate in the sepoli and gorilla upgrades running the new versions of all the software before and after and during the merge and the upgrade yeah and special thanks to Pari CL people James Sarah LX for for supporting this it turned out to be quite involved actually more than we initially estimated but I think we are getting everything now wrapped up nicely yeah thanks all I think that's the overall summary yeah thank you Chris this is very exciting to see this on the test Nets um any questions for Chris

okay thank you again um so we had Beacon apis uh next um Paul from techu had a number of points Paul are you here you know Paul is not uh here unfortunately it being midnight in his location um I understand uh does anybody that's keeping an eye on vegan apis want to discuss some of these points so there's uh the SEC subscriptions um there's another PR open up about an endpoint for expected withdrawals slot and the general generally the discussion about how to get the capella spec release out I believe that the neb has

kind of leaked a lot into this and then it's not as stable so um some questions around that

yeah so the substantive issue on the spec is I think he feels blocked in so Paul has sort of um assumed responsibility for uh curating the beacon API repo so um you know with plenty of input from others but uh he wants to get a release out of uh you know checkpointed API for capella um but there is not yet a stable capella release of the spec or final release of the spec so he feels blocked on that and he's also concerned that stuff from

deneb seems to be being pulled forward into the the release um and that is also making it complicated to checkpoint a sort of capella Beacon API release um I don't know the Rights and Wrongs of this but if anybody's got Insight that would be helpful um Paul is feeling uh blocked on it right

Danny Ryan: I can definitely reach out to talk um I think generally when we have like a simulator version on the consensus specs that certainly means the next fork and we simultaneously keep r d Forks in there that doesn't mean that uh that means that anything that's trying to be at parity with 1.3 should respect capella and not doesn't have to respect R D

um as for the server-side events and other points here I am not deep in them um but if we don't have much discussion Point here we'll have to take it to the issues

Pawan Dhananjay: regarding the service SSC even so Michael has started working on a PR for Lighthouse he also said that he'll be making a PR to the beacon API steps tomorrow for the SSC event implementation that he has described in the issue link tissue basically

Danny Ryan: got it would you call uh getting this SC

done a Blocker on releasing a 1.3 of the beacon apis or can it be layered in after I just want to understand the dependency here

I'm

Pawan Dhananjay: not sure about that

Danny Ryan: try to keep try to get a lot of this moving um and answer some of the unknown questions um any other discussion points on the beginning apis for the call today okay thank you any other capella discussion points for today

Terence Tsao: um yeah so I guess one thing to add is that for prison we're currently comparing block value in a way that if they use map boost and we will compare the block value from your local blog and then view the blog and then choose the one that's the highest value and I'm wondering if any other clients are doing that and whether um we can actually integrate this type of test case into hype because I think this is a great test um yeah the taco is doing that now and we also would like to add kind of a percentage where user could say

we not only just favor uh yeah local if is better or you can actually have a multiplier says I want to have I want to use the Builder only if twice the value of the local a lot of execute but this is not yet implemented but we do uh implement the comparison now yeah that makes sense I can imagine every client does it differently and that's okay but yeah sorry I actually brought this up earlier so I think this will be a very good uh High test case but then we can follow up offline um just to chip in

load storage

Gajinder Singh: is also

doing it so you just have to enable a flag uh minus minus Builder dot selection and see it as Max profit so that way basically it will choose if the local execution client has more block value then it will choose that otherwise it will choose the Builder so we can be tested we can be put on high test for this

Zahary Karadjov: nice open an interesting implementation if the engine API support this we get the information from there but if it doesn't we actually Leverage The our ethereum one code base to calculate the

block rewards ourselves

Pawan Dhananjay: I think Lighthouse also supports this

with the latest release now

Danny Ryan: okay great so it sounds like there's a bit of in some uh parameterizations are turning on and off uh but I agree this would be a nice case especially now that we have the the mock builder stuff in there

yes

Mario Vega: yes of course um so yeah I actually found those uh those circumstances where when I was writing this test so basically what it does right now is just basically bumps up uh takes the the the the block will work just to get the CLS all to always uh include the the build block and so what I found is that basically every every single client is

doing this so yeah I think we can definitely add the tests to the Builder API

isolate for this

Danny Ryan: cool thank you okay anything else on capella okay great uh moving on to the

neb

Danny Ryan: um there was a new release as I said this had a couple that had a test case for Capello otherwise was stable um this release did include the creating of the blobs thank you very much for

gossip for moving that forward as well as the networking folks who analyzed and simulated that it has some photography updates which on the call on Tuesday it sounds like they have been integrated into dkzg and I believe since then all of the um bindings have been released I believe there's some review on bindings uh so they they might be in flux a bit over the next few weeks as they stabilize and get things ready for audit but they should be usable now um a couple of other minor updates like the access data gas field on the end of the execution payload thank you Proto for saving our trees um and otherwise should be pretty good

any questions on that release or further comments on that release cool thank you again yasik and everyone else for that review it was a bit of a monster it does look like there are a couple of like copy pastas and typos that will be integrated and fixed but I don't think anything um breaking at this point there has been one more networking PR 30 to 42 that has did not make it in um at Edelweiss I think it was generally agreed by

engineering teams that they'd prefer to have no message sent if there's um no blob sidecar rather than an empty blob sidecar in these various messages a Docker does mention that the crypto is totally fine in sending these messages and you can evaluate these without any issue there were some notes that you know we're not putting these in the database so why send them on the network we've gone back and forth in this a little bit my gut is that engineering teams generally want this in there and I guess I'm that's my default based off of some conversations and I'm

probably going to keep this moving forward unless uh there's some strong against in this call okay any comment on this I think um on Tuesday on the fourth before call although it might be canceled um I'll kind of knock on doors of people that have potential opinions here and uh keep it moving any other comment here Tim is the 4844 call cancel next week

Tim Beiko: yes I was just typing a message we'll cancel next week we'll have uh one two weeks from now and obviously there's uh the execution layer called next week as

well which okay there so we

could yep anything urgents great okay anything else on the neb um one more thing there is a

Terence Tsao: beacon API for blob signing I know there's the older conversations are happening in the issue itself or sorry it's a request so yeah if anyone has left many feedback comments please um yeah add to those ideally I we would like to get this merge like hopefully by early next week so that we can unblock client implementation

Danny Ryan: thank you Terence yeah I took a look at

that yesterday it does seem it's still active although I can knock on Sean's door Sean's not here uh to ask what needs to be done to get this over the edge cool thank you Terence any other dinab comments discussion points great any other items to discuss today research spec or just open discussions or comments in general

okay easy everyone gets an hour back uh thank you everyone uh for keeping Capel internet moving very exciting talk to y'all soon bye thank you

thank you thank you thank you guys bye

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.