All Core Devs - Consensus #99

Transcript

foreign [Music] [Music] [Music] foreign [Music]

[Applause] [Music] foreign [Music]

Danny Ryan: we are live

thank you everyone for joining since their call number 99. this is issue 667 in the PM repo link shared in the chat um we will as usual hit capella for it for four then more General open discussion around spec and research um first of all I think there was a doozy of a call last week on the all core devs um execution layer call um I did want to recap what I think is maybe the most relevant conclusions for this group um obviously a lot of us have opinions about what

goes into the evm but let's keep it targeted on the kitchen Slayer and what we see is the next couple of upgrades coming um my understanding is that we shall keep withdrawals independently specified and worked on in Capella um and that 4844 will remain its own specification um and that I think importantly even in the event that these things were say in some World ready at the same time even though that's not the intention right now that we still wouldn't combine the specifications and and stagger the upgrade

um but I think that crucially you know I think what was made clear by consensus layer teams is that um they believe that 4844 is not in nearly the same Readiness as withdrawals coupling them would significantly delay withdrawals we will not couple them we'll work full steam ahead on capella uh in its current form um while parallelizing the 4844 work still um is there any is that correct is that the general understanding of the teams on this call does anybody

that's not what we like

from nimbus

Danny Ryan: sorry what was that

yeah

Jacek Sieka: that was that's what we like from Members yeah okay makes sense

Danny Ryan: great I will instead ask instead of affirmation any dissent okay cool um again most of that was hashed out on the previous call if you're listening to this you can go check that out um great so let's move into our items for today capella does anybody have uh just a general progress update with respect to test Nets and other um coordination items

Barnabas Busa: I think I would be uh responsible for

that so we are currently running two test match uh for withdrawals this does not include any 4844 implementation only uh strictly individual part So currently how it looks like is we are able to do uh full withdrawals we did the testing with the load star lighthouse techu and uh prism uh prism is not able to start from post-genesis merch just yet uh they're working on it and that's why we have currently two different test Nets so one of the test matches is uh the premise and the other one is the post

merge and the post merge has president low-star uh sorry those star Lighthouse Taco guess never mind on them and the other one is we just started that today uh started over again and we started to uh begin testing BLS to execution changes so that one currently around the prison Lighthouse deck 2 and guess and another month because the bezel is still uh doesn't have the Shanghai uh by Epoch implementation we are awaiting for that that should be done quite soon again and as far as I know Nimbus and Eric

doesn't yet have any implementation for our jobs that's why we able to

test with those a couple things there what's the

Danny Ryan: what's the Nimbus status I mean I I said from the Nimbus team uh where we stand on getting withdrawals

Zahary Karadjov: were this a request regarding the consensus layer or the execution layer on the consensus we're currently building out the spec or we are pretty close to kind of running local simulations and the immediate next goal would be to joining this uh the internal

Opera

Danny Ryan: great and then on the uh the BLS change operation uh do we have tooling for

testing that what are we utilizing for that

because it

Barnabas Busa: it do uh and prism is just testing it right now and but they should light off and Tech also uh lowstar has something in draft and should be available I think within a week or two so then we can also include low star in the test not for that

Danny Ryan: great I would recommend we um so there's obviously getting into local men pool and block packing with those operations another is testing the gossip operation so it might be valuable to insert them into a node that is not running validators and then if it's

picked up by other nodes we know that the gossip is is working well okay cool um anything on the capella test Nets right time

then this

Barnabas Busa: this is the capital test or yeah sorry anything else anything else uh not really uh so this this BLS execution it's very fresh like we started uh maybe two hours ago that's that's why I didn't have that many uh yeah I'll say about that yeah but but the full video we tested a couple of

weeks ago already and pull withdrawals work just fine when uh the visual address is 0 x

0 1 Style

Potuz: so BLS changes are being submitted and we tested that we can submit to the pool more than the allowed maximum on a block and the pool is accepting them and just sending them uh on the maximum per block other other nodes are taking this we are not broadcasting them yet on the P2P on go zip uh we'll test this right now

thank you

Barnabas Busa: so basically the future plans are uh that we're going to migrate these two

thousands into a single test net and we would like to include all of clients in that one and that's going to be a bit longer left one also but for that uh I would like to wait for bezel to implement their Shanghai based on Epoch and I would like to include Nimbus also and we will do that once the prism is able to start from a post merge Genesis which also should come very very soon

Danny Ryan: great okay next up let's talk about issue or PR 3095 we did talk about this two weeks ago I think I've generally had agreement um on doing this bounded sweep Alex is

there any update or any questions with regard to this before we do a review and get it released

Alex Stokes: I don't think so uh I've made the bound very small uh in response to some feedback and added some tests recently that was a little more involved than I was expecting but uh yeah it should be ready to go final review and then yeah the only thing is um yeah just a green that we all want to change

foreign okay I

Danny Ryan: believe that was the General agreement two weeks ago um and he spent on a bounded sweep and it being

on the lower end of size okay so I know we have a number of additional tests of work in progress right now around um some of the more edge cases on multiple balance updates for validators within a single block so we're going to aim to get some of these new tests and this out by the end of next week for consumption sound good okay anything else regarding capella

okay on 4844 there is a weekly call on Mondays is there anything that uh needs to be percolated up to the larger group today

Sean Anderson: uh so that line actually raised an interesting issue recently that I thought was worth bringing up um it has to do with syncing where like syncing blobs um the general idea is that like we have a lower bound of blobs like our men whatever request epochs for storing Bobs but like the actual lower bound seems like it would be the point of finalization

and if that's the case then do you have scenarios where the chain hasn't finalized within this sort of like prune depth we've defined then when you're sinking from Genesis you don't know where the point of finalization is until you get all the way to the Head so this would mean you'd have to sync like all the way to the head to find where you should have validated all the blobs and then go back and check that you um actually got blobs and blocks from your peers in that space between like where the chance to finalize and where the like prune threshold we have is

Danny Ryan: so why why are you saying the that you should only need to get blobs are you saying that you only need to get blobs since finalized

Sean Anderson: I'm saying like the minimum bound of where you need to get blobs seems like it's either the point of finalization or like this prune depth that we've defined and when the point of finalization is like further in the past than this prune depth there's some tough scenarios that make it seem like you'd have to sink to the head and then go back and double check you've got all these blobs correctly because you don't really know what the point of finalization is apart from like what your peers tell you

their like finalized Epoch is right

Danny Ryan: I don't see the interplay between finalization and the prune depth if you have what is you think is a finalized chain but you don't have the available blobs you would consider it unavailable right

so the following gloves um well so

Sean Anderson: I think it's that your uh peers could tell you an incorrect finalized Epoch and while you're sinking to the head you sort of have to trust this until you're able to just to determine for yourself whether it was finalized so they could give you an incorrect finalized Epoch and then not give you blobs where you would have

needed it so then you'd have like blocks that are actually unfinalized with no you couldn't check that the data was available

yeah yeah so I

Danny Ryan: I claim that I don't I don't see the interplay between finalization and data availability meaning even if you think if something is finalized you should still be checking data availability so that a malicious majority can't fool you about unavailable data but I maybe I'm missing something here Proto you had your hand

Protolambda: so to clarify we are talking about the periods of time uh past the pruning period so like more than 18 days ago but if the chain is not finalizing for all the time then there's a point where

you might have part of the chain that you don't have the data but it is sorry yeah I mean I'm sorry okay so there's just this part of the chain in this case of non-finality that we will not have to bloop data for anymore so you cannot validate whether or not it should have been considered for finalization is that what you're saying

yeah

Sean Anderson: yeah that's what I'm saying

Jacek Sieka: just a quick question why aren't we tying the period the the removal of the blob data to finalization instead So like um oh like that um maybe we should

Sean Anderson: so in the specs it's actually specced out that you should have data until the finalized epack as well so it is there but the case that I'm trying to get at is where like your peers are I guess lying about what the finalized Epoch is and you don't know that they're lying about that until you sink to the Head and so then at that point you would have

to like go back and ask good peers to like double check these blocks that you you thought you didn't have to check whether the data was available for it and then like reprocess

it because

Danny Ryan: the network the spec says do the maximum length whether that be 18 or time since

finality right so like you should have them in your database yeah

Jacek Sieka: but in general we we can never trust what the other clients are telling us I mean how is this unique right so we always assume

so yeah benevolence but uh verify that

Sean Anderson: yeah so the the thing about this is like you assume this but you're able to verify this as you sink forward in sync usually but in this case it's like you'll be sinking forward as you're sinking forward you have to like trust about the the validation of the block that like uh your peers aren't Gonna Give You blobs according to like uh their view of finalization I guess so the difference is that like you can still sink to the head and then at that point you know what the actual file finalized checkpoint should be and then you like can reprocess those blocks but the complex like

I'm bringing this up I guess to uh I guess make more people aware that this scenario could introduce a lot of complexity because we don't have to like reprocess blocks during sync in other parts of like the consensus layer like we have to do it for alchemistic sync for like consensus layer execution layer sync but this would be like unique to a consensus layer um a strange a touch case that potentially introduces a lot of complexity is most of my point

Protolambda: I'd like to understand it better so we have this this for choice three

you sync One path of that from some pair the pair can claim whatever you verify the data that you pull and when you verify you verify all the state transition you verify the finalization that happens during the state transition and for the at least the last 18 days worth of data you should have the blobs and download it and if notes then you cannot persist that part of the chain and then there's this Edge case with non-finality for more than 18 days and

then there's another Edge case with um the if we can get this right I'm not sure how to best describe the size class where the [Music] um but the blob data periods is shorter than the definitization and and you want to download more blobs um in that case I think we might not even want to download the plops and change the specter so where does the complexity where where

does it get introduced assuming we can simplify this back to say always verify the last 18 days and just verify the finalization like today without

foreign um yeah I'm

Sean Anderson: gonna have to think about that but I think generally it's like we'd have to introduce another form of like uh optimistic processing of blocks but yeah I'll I'll think about what you're proposing more

I guess

Terence Tsao: wait so the spec says that you cannot import a block unless there's a blob

right so for Forward Thinking case that if you don't have a blob then you just cannot import it are you talking about potentially moving that into more like an optimistic model

no so

Protolambda: you should require the blob for data that is less than 18 days old but then there's some doubts better notes to change that based on finality especially in the case of like long

non-finality

Danny Ryan: okay so there is a PR open with I

believe this um foreign on 3141 on the consensus specs repo um I need to take a look at this to have a more intelligent conversation about it um do you think that we can make progress here today or that we should move to this PR

ere

Protolambda: yeah I agree

Jacek Sieka: I would just ask the question is there any problem time uh removed of blobs to the finality instead of I guess wall clock

Danny Ryan: um do you mean even in the event where you're finalizing into epochs to removable blobs

Jacek Sieka: yeah I mean you're finalizing into vbox so you keep data for you know

20 bucks

Danny Ryan: yeah so I mean one argument would be that a malicious majority can fool you if you're offline for an Epoch and you come back online um there are certainly debates as to what the pruned up should be it also removes our guarantee of constrained State growth theoretically

Jacek Sieka: no it doesn't

because the chain can only go on for what is it a month before it dies

let's just hold a week for a month but then the new side can continue leaking so from a theoretical standpoint this is unbounded like you can just have you know 75 leak out and in the remain 25 then failed achieve finality and they start leaking out and remain 25 the other two finality lately go yeah and you're gonna repeat this forever theoretically I recognize this is very low odds but no because finally everybody looks up but you know

Jacek Sieka: at some point right

and the second moment is that like some of the validators stay in there those that didn't leak out and I guess reasonably those cause finality at the point where uh The Leaky ones are finally exited

Micah Zoltu: yes that would be a reasonable expectation of what should happen but if it's not theoretically guaranteed again my migrant here is just like it's an edge case um we are currently asserting with very strongly that there is a very finite amount of states that can be contained by these blobs this would change that to a you know more of a economic guarantee

rather than a hard guarantee which is probably still fine but I think we should just recognize that

Jacek Sieka: it's a fair point and it's that kind of risks that I was curious about

Danny Ryan: okay I'm going to read this and move my comments to 3141 if you are interested in digging into this please do the same okay uh Trent I just saw you added um kcg ceremony update can you give us

that while we're here

Trent Van Epps: yeah real quick uh related to 444 most of you are probably aware that it requires a trusted setup um but for anybody listening to the call live or the recording or reading the notes later on just a quick update we're finishing up the uh the second audit with Sigma Prime um that'll be done probably this week we'll respond to their changes and then shortly after hopefully in the next few weeks or at least um at the start of the new year we'll be moving into the public contribution period so um if you uh any teams or individuals communities want to participate please start sharing this

um we're starting to ramp up some uh uh education Awareness stuff we'll be doing Twitter spaces so if you have a specific community that you want us to come talk to um Carl and myself will make ourselves available we're more than happy to do that um yeah this is as you probably know trusted setups are uh we want them to be as credible as possible and that means getting as many people to participate so that's where we're going to aim for this to be the largest summoning ceremony uh in the crypto space at least um probably uh let's say eight to ten thousand contributions that's what we're aiming for so yeah if you have any communities

um that you think might be interested please reach out we're we'd love to come talk to you and if you are uh someone with let's say an academic a amateur or professional interest in cryptography we're also running a grants round to get other people's right implementations and um that'll be happening after the public contribution period but we want to get people aware of it and please reach out if you're interested in writing your own implementation from what I understand it's relatively straightforward not too crazy maybe a day or two of work so we'd love to have as many implementations as possible contributing to this again to make sure this is as credible and

legitimate a ceremony as possible okay that's uh that's all I have

Jesse Pollak: thanks Trent do you know how long the public contribution period is going to be open

Trent Van Epps: we're aiming for at least two months we're right about there

Jesse Pollak: got it so like early to mid-January to like mid Feb mid-march or something like that

Trent Van Epps: yeah roughly uh well we'll definitely have like a tighter a better idea of what the the bounds are as we get closer

Jesse Pollak: great cool and just a quick update from my side because because I'm here um I've been talking in terms of coinbase we're all aligned on the kind of like social content side so that will all happen for sure and then I'm working on the call to actions in the product

um I think that's gonna happen as well

Trent Van Epps: oh awesome thank you

great

Carl Beekhuizen: one extra thing to add here is that like if you do have any questions or doubts or whatever about this like please don't hesitate to ask um like this is a weird and fun thing to to be doing so like let's make sure everyone understands it and is comfortable like don't hesitate to to reach out if you have any concerns about all of us or whatever thanks

Danny Ryan: thank you um any other four four discussion points for today

great uh we have a number of specification items across a few different domains uh age you had a a couple one the first was the atnets revamp um can you give us a quick on that

Adrian Manning: yeah um so I just wanted to raise a few things that were um planning on I guess releasing or or adding into Lighthouse that can affect everybody else um so that Nets revamp thing uh so this is where we get a bigger node uh so I guess if we just do Lighthouse a

specific Beacon node subscribes to one or many subnets rather than it being tied to the validate account um so this is entirely backwards compatible we can kind of just release this kind of thing tomorrow but the the overall effect on the network is that the the density of the subnets of the assistation subnets is going to be reduced depending on how many Beaker notes um you know Beacon note to subnets we have so yeah I want to just gauge other people's thoughts on doing this before going into

anything

Danny Ryan: any of the simulation analysis that was that completed I know you're working on it

Adrian Manning: yeah so the simulation so we've got like some simulation stuff but it's not really for the uh gestation subnets so I guess fundamentally the question I want to ask are the other client teams is how they're managing um how they're managing peers uh in terms of like collecting the ones that are on subnets that you need because if we make this change and if you have just like a one-to-one mapping one Beacon node to one subnet then if you have let's say 60p as and you you kind of uh collect them so that they're uniformly distributed across the subnets you you still should at least have one on every subnet I'm not sure if other client teams are doing this kind of this kind of logic if we if we could also say one Beacon node should subscribe to uh six subnets

and you'd have roughly the same density as you have on Main mainnet at the moment and you shouldn't see you shouldn't see a drop you might actually see better improvements because um because every bigger node that you connect to will be will be subscribe to a subnet rather than having these small groups of big nodes that um you probably can't connect to because everyone else is trying to connect to them so just trying to gauge other people's thoughts on whether it's a backwards compatible release that can kind of happen slowly in one client that's not going to destroy the entire network in one hit potentially is there any thoughts on this by any of the other client teams is it going to do we think it's going to drastically affect

um other people's implementations

Nishant Das: is it possible to test this out on Gurley first before

meeting that

Adrian Manning: yeah of course like we do it on for sure we'll do it on test Nets to begin with um but it's it's mainly about uh no no distribution which is very different between the test Nets and mainnet

Danny Ryan: so like on testnet given our assumptions on node count we might have to make the minimum 10 or something whereas on Main net the target would be the minimum would hopefully be one right

Adrian Manning: yeah exactly yeah exactly yeah

Danny Ryan: so it would be ma semi-artificial test it'll show that the functionality works but it won't show necessarily that the

distributions work for me

Parithosh Jayanthi: I mean yeah the most interesting thing about this proposal to me was that it also um changed the way we did zinc committee subnets because currently getting on the sync committee mesh is actually problematic I mean at least from what we've seen that the sync committee meshes are are sparsely populated and difficult to get into now if this means that a lot of Lighthouse nodes suddenly will

be less interested in forming meshes then then obviously it's going to have two effects one is that uh Lighthouse will use less bandwidth than the other clients uh and then I'm hoping that we will not end up in a situation like the sync committee substance where where like we get reports from people we look into it and then they couldn't get onto the mesh I don't I don't really know what a good model for releasing that is but um right

Danny Ryan: I mean I wouldn't mistakes even though we can do this in a backwards compatible way I don't think we should

do it unless we're confident that the entire network can do so um and that this is like the new specified honest behavior um the goal here would be to make sure all nodes are helping contribute while also um you know having so having a better distribution and also potentially reducing bandwidth for the average node as well so I'm although I proposed that I don't know the best way to 100 validate it before we move forward

sure I

Adrian Manning: can post some statistics which doesn't entirely help us all that much

one of the other uh I guess important metrics that's a little bit difficult to find is uh you've got these bunch of nodes that are subscribed to a lot which is the the ones that are going to be reduced so the ones that are subscribe to 64 subnets essentially we would reduce those down to one and that's where the damage would mainly be but the the interesting metric that you kind of want to see is um how many how many peers can connect to those nodes at the moment because if they if they for example they only accept 50 peers and they're all their peers lots of fallen and you know it's kind of connect to them anyway they're not as valuable as what we what we think they are um I can try and get some more information and well but there's also there's a couple things here

Danny Ryan: one you

can't like you can just lie so nodes can just lie about adnets right now um so this by making it just a function of your your ID or some sort of external uh piece of data about yourself you can now make it whether somebody's like doing their job or not which is good and it also it scales with the network so the meshes you know naturally kind of become reinforced as there's more nodes in the network rather than right now if you had 100 times more nodes uh than than validators then you have even more trouble finding kind of like a sparse validator nodes um so like to to reiterate like there's a number of

reasons even in future constructions that uh we don't want to just be relying more heavily on these nodes that are just connected to everything

Adrian Manning: yeah another semi-safe way of doing this uh if you just want to go and like kind of rule subnet density numbers is if we said one week you know connects to six or seven subnets then the density should be the same but you should have a greater connectivity so it should be a strict Improvement in principle

Danny Ryan: yeah I get worried yeah just that would be a drastic for a home validator with one validator

that's probably addressed that's the dance I got with so I

Danny Ryan: I think that I would only be comfortable moving to this if we can

convince ourselves that only order one or two is is safe

Adrian Manning: okay um I'll I'll post on the issue and try and just post the current statistics and we can make a decision on the issue um I can move on to the next one unless there's anything else on that

Jacek Sieka: uh two more small things one is that I do think that clients should strive to follow the specs so I'd love to see this added to this pack and then we start releasing it to mainnet otherwise uh we're we're on a slippery slope blah blah

uh the other one

Danny Ryan: yeah I agree that's what I meant but we should be agreeing

to this even if it's backwards compatible rather than just shipping this

Jacek Sieka: yeah the other thing was I think something we talked about at Defcon which is that the guarantee I mean it's still based on honesty even after this change like um and I think what we discussed at Defcon was basically that you can signal that your you know part of the subnet and and then you can just not join the mesh even though you subscribe to the topic so like if you want to be dishonest there is still a loophole um the verifiability is let's say nice but I wouldn't take it as foolproof like

it's not proof you still need to verify that they're actually transmitting messages and stuff like this and that's that that goes into difficult territory

Danny Ryan: it's difficult but not impossible territory at least on a heuristic zone right like if I think you're on a mesh and you never give me anything from being on that mesh then I can down score you and move on

Jacek Sieka: no but I can say that my mesh is full I can prune you and right and that's that I can't tell anything about which is another reason to move on

Danny Ryan: but yeah

I mean the worst the the main thing you do is if if somebody's lying to you about this is to not connect to them and if they're also simultaneously just pruning you from the mesh that's also a reason to not prioritize them and not connect to them so yeah

Jacek Sieka: yeah

Danny Ryan: and like because they're doing that everybody they're going to be disconnected from most people

yeah yeah that's fair but still okay we'll age another one um

so

Adrian Manning: there's another kind of two ones uh I won't take up too much uh time for everyone but the one of the other issues in terms of like connecting to all these peers that that we need for for the subnets is that there's a lot on the network that uh behind Nats at the moment um there was a drive in Disney 5 to build like an automatic Nat hole punching thing which we're close to having kind of a a version working but that involves specking out uh some extra fields in the enr so anyway that there's there's some work towards this and if the other client teams are kind of interested in doing this kind of it'll translate over to TCP at some point after a bit of specking

but um essentially recycling some enr Fields modifying Discovery five and adding like a TCP automatic hole punching in something that we're we're kind of working on it would be hand if we get some other client teams for interrupt um I'll post something about that if anyone people can reach out if there's anything interesting

they're interested about that oh no yeah okay um the other thing is one question

Jacek Sieka: yeah uh I saw that little P2P themselves are specing out what's it called Autonet 2.0 is this somehow related or

integratable

Adrian Manning: yeah so I'm standing with ordinet 2.0 um yeah it's it's a entirely b2p thing so it's entirely over TCP and you have you organizer relayer and Via that relay you you you organize the whole punching on TCP um so there was this yeah so there was a spec yeah for portal in particular that wanted to do um some that hole punching which is semi-spect in disb5 fundamentally what happens is that you you do a similar thing using relays uh that the whole punching usually works better over UDP and once you have that you essentially have a connection with a node over UDP and I think quite easily we can use

Discovery V5 to then essentially organize a a hole punching through TCP so we don't have to have the the relay that you would need um with AutoNation like we can we can skip a step all right because we have discovery okay uh yeah

Nishant Das: is there a link to the spec for this

e kind of um I'll I'll

Adrian Manning: post it so there's there's some stuff that we're we're here semi-making up and some stuff that's in the dsp5 spec so if you go if you go to the district advice back in PRS I think

um there's there's a proposal there that's not entirely stable at the moment

Nishant Das: okay sounds good

Adrian Manning: yeah um so the last thing is uh IPv6 support there's been people kind of hassling us for quite a while um which we have mostly figured out but the first step to kind of onboarding IPv6 nodes is is having IPv6 compatible boot nodes um so we were considering um just enabling uh the lighthouse boot notes to having IPv6 which gives an onboarding for some nodes to then use IPv6 if they want to we won't have IPv6

enabled in Lighthouse but just having the boot nodes capable of doing it allows us to upgrade at some point in the future I'm wondering if there's any thoughts about that whether we should do that I should not do that it'll be dual stack so it's entirely backs compatible which means that it has an IPv6 and ipv4 IP address

Nishant Das: it just means that in the enr you then have the option so all clients would have to update their boot node in

our answer no no no other

Adrian Manning: clients need to do anything but if we do the lighthouse ones it just means there would be of all the boot nodes we have two of them um can advertise an IPv6 and so other IPv6 nodes can kind of

um advertise off them and and contribute to the DHT it's just an entry point

Nishant Das: yeah but uh like uh Lighthouse is both known to like hard-coded to different clients right so uh each client would have to update their Lighthouse booth now to have the IPv6 in Argent them right

Adrian Manning: um yeah so so we would uh we would update the anrs in each of the clients um so that it's they're hard-coded into the client but it's I don't think that's entirely necessary because when you initially connect it that when it does the handshake via ping it realizes that the sequence numbers out of date and it

downloads the new One

automatically okay all right yeah

Adrian Manning: so as long as you have the the node ID essentially in the in the keys to connect to it it'll it'll update it automatically even if it's not hard coded but we should hard code it

sounds good to me

Danny Ryan: so this doesn't require any sort of spec change um does it require anything from other clients or are you asking them to also add IPv6 to their boot notes

Adrian Manning: no so it doesn't do anything um uh yeah so no one else needs to do anything the reason I'm bringing this up is in a previous conversation I've had

with everybody there was concern of having a network split if uh if there's IPv6 only nodes then the IPv6 Only Knows can only kind of talk amongst themselves essentially by enabling IPv6 in the boot nodes you you now semi-enable the possibility for people to try and run these kinds of setups in Lighthouse we're only going to allow dual stack to begin with to not segregate the network but it opens up the possibility that um IPv6 only knows that start joining can can kind of partition if anyone's attempting to run that kind of thing so so that's kind of why I'm

raising it I don't think that there's a downside other than that it's just uh forwards compatibility and if we update the nodes now then we can upgrade later

Micah Zoltu: if you launch a dual stack version of a client and the operator runs it behind a Nat that doesn't have some sort of Auto hole punching won't they naturally fall into IPv6 only because in most cases because of the abundance of IPv6 addresses lots of people get an IPv6 address but they're netted behind ipv4 and so they may only have Public Access

via IPv6 so is there a risk that they might accidentally partition even if you do dual stack

Adrian Manning: uh yes yeah so I think that's right in that case and so then those nodes probably won't find any peers oh they might yeah they might start petitioning themselves yeah if there's if there's a bunch of them doing it

Micah Zoltu: they find all the IPv6 peers and they wouldn't be able to communicate with anybody the ipv4 not due to maliciousness just due to their network was set up such that they're netted with ipv4 and they didn't punch a

hole right correct yeah

Micah Zoltu: at the moment yeah it would end up accidentally being IPv6 only nodes even though is there anything we

can do I guess what I'm asking is there anything we can do to try to make that not happen by accident like if someone wants to do IPv6 they have to kind of really go out of their way to do it they can't accidentally fall in type of V6 only

Adrian Manning: uh I'd have to think about that there's a bunch of changes in this stuff that I'm talking about where we the local nodes identify what kind of nuts they're behind whether it um in which if we had that functionality potentially we can we can do some stuff but I probably have I don't have an answer right now okay I'd have to think about a way that we can do that but in principle yeah add adding this support allows that kind of setup to petition themselves right at the moment they would just not connect

to anything on a similar note

than

Micah Zoltu: related to the previous point about not whole bunching can we a node that is a dual stack can they use the IPv6 to establish that hole for right for their own

ipv4

Adrian Manning: um yes I think so in principle uh I think I mean yeah yeah I don't see why not it depends on the relayer if the relayer in between supports ibb6 uh in in Discovery yes I think it's possible yeah

Jacek Sieka: out of curiosity are you using a single

socket or us or or two sockets like a single dual stack or uh it's

Adrian Manning: uh I think it comes out as two sockets in in the Russ the rust Library uses a single socket but you you have like essentially a loud map address which gives you a second socket

Jacek Sieka: all right yeah we're looking to get IPv6 in there at some point as well

Adrian Manning: okay um yeah I think like semi-enabling it is uh One Step Closer I guess or at least just

doing doing the boot notes early so that they're in the DHT but not having functionality otherwise I I'll make some noise on an issue that people can can post just giving a heads up cool that's it for me thanks guys

Danny Ryan: thank you okay we have an old Beacon API PR on checkpoint sync apis uh Mikhail I think you raised

the screen

Mikhail Kalinin: yeah um um so checkpoint Sync API that has been opened a while ago as they said

um so yeah just want to give an update on it and uh [Music] um yeah just before we move on on the apps with the update and the current state of the Arts uh with the checkpoint save so I'll give a quick reminder on what was this PR about uh so this PR basically proposed two endpoints um the first one was for State providers the second one for was for trust providers the goals the goal of State providers end point was to make it convenient poor as actual State providers to to provide the state uh basically it allowed to provide any

finalized date that the state provider wants which is uh which which is within a weak subject to period the other endpoints allowed to allows to use the um whatever Trust uh trust nodes that whatever knows that you trust um and the trust is the subjective thing but it allows you to verify the state that have been that you have been inspired with uh and obtained from the showstate providers so that's that's the um this overview of the proposal and

yeah since that has been opened there was the checkpoints tool developed and yeah it basically the tool provides a convenient way for State providers to supply the state comes with like those protection it comes with um it it can talk to a multiple Upstream Beacon notes and decide on whether the state is finalized whether they agree on the finalized State and then expose it also it comes with the caching so it's basically it suits very well the first goal of this proposal and also it provides more data than the

state only because some of Steel clients can't bootstrap with the state only yeah it's the problem that orthogonal to to the checkpoints in API proposal but anyway the checkpoints tool also solve this problem as well um and for the second part for the trust part for the verification part uh the checkpoints still also yeah provides this functionality my main concern about that is that in this case checkpoints still become the um the single point of failure if everyone will use this for um for for providing the trust for allowing to verify the state

that has been given to to start with and we have another um PR that has been merged to burlesque recently which equips every response in the beacon API that responds with some chain data with finalized flag so it basically the reason endpoint a simple endpoint that can be used for the state verification and yeah probably the other way without creating a single uh point of failure would be to for those who wants to be a trust provider to make their own custom

configuration and those protection and what uh what not and utilize this um this finalized flag uh that's the other way of doing this um yeah and basically uh the intention is to my intention is to deprecate this proposal unless there are some I know so some other opinions on that and that's why I'm bringing it here just to announce that it's about a bit deprecated and if you're interested in it because of whatever reason just yep uh post the comment in the issue or say it here on the

call thank you

okay okay

Mikhail Kalinin: yeah I think it makes sense to keep it keep the issue of keep the pr open for I don't know until the end of this week and just close this um if somebody appears

Danny Ryan: got it foreign this uh let's see can you give us is the person who posted this here

yeah I

think so it's me

Denny

oh I'm sorry how are things

Oisín Kyne: how are things guys so um the um pull request that I'm looking for kind of review and feedback and acceptance on relates to um distributed validators and the aggregation Duty and I'd say a lot of people on this call are familiar with the idea of distributed validator technology it's making a you know one logical 32 either validator run across multiple machines with you know threshold BLS keys and multi-sig like signing and the this PR addresses specifically the aggregation Duty right now

um the aggregation duty is decided by you signing the Slavs which is called a slot signature and then hashing it and doing like a modulus check and the problem is with the distributed validator every individual validated in a different BLS private key so they all have different file signatures and then I'll try and aggregate at the different time and the proposal or the kind of tweak we're working on we've been you know discussing this a few people for a lot for a good few months now shout out Danny Ben Terence and some of the others but basically as it's refined now if it's one extra API call that um the consensus layer doesn't have to implement it'll be implemented at the middleware layer and it would be opt-in to be used by validator clients if they

turn on a feature flag and it basically means when you're trying to decide if you're supposed to aggregate you just send your partial slot signature to the consensus layer and then it returns you a full signature which you then hash in modulus check and then continue on the flow as normal so um yeah ask is have a look have to answer questions now but um if we can get it um accepted then we can kind of talk with the client teams about getting this implemented in a branch kind of behind a feature flag excellent

Danny Ryan: okay so the decision was to return whatever may be a full slot

signature and the validator client still does the local computation rather than just the middleware or the beacon node doing the computation on the full slot signature and returning true or false or a list of indices right

Oisín Kyne: correct the reason we return is is because at second age you have to make an aggregation proof and in that aggregation you have to actually put the the proof which is like the fully assembled slot signature so that's why we're sending it back instead of just sending back

true foreign

Danny Ryan: and if you're implementing this on the would you implement so would Beacon nodes actually implement

this and just like have it essentially a no-op where you're just returning the value that was given so the validator client doesn't really care if it's connected to middleware or Beacon node or would you not

expecting those simple methods

Oisín Kyne: uh I don't really mind I think in the polar Quest I'm suggesting we don't implement it for Simplicity um and I was suggesting that uh consensus client either return 501 not implemented to like explicitly say no we're not doing this or potentially like a 400 to say hey you're potentially sending like a this endpoint's interview for distributed validator and you're hitting enough of a consensus client you probably want to 400 to see what's going wrong here um so so yeah I I it could be

implemented and be no up but I was thinking either kind of a 501 or 400 depending on if we want to kind of tell the quote-unquote user that something is up

Danny Ryan: got it and in the event that this is not added to the something like this is not out of the validate API then that's going to make EVT teams probably be forking validator clients um which is not what we want

Oisín Kyne: yeah that's that's really the thing the other option is that distributed validators don't Implement aggregations and they don't get penalized themselves but like Network Effectiveness would gradually decline if thieves make up like a larger percentage of the network so yeah you'd prefer it to be you know additive to clients

rather than be kind of pushed into making a kind of a custom validator

thank you

Danny Ryan: got it um there has been a bit of conversation I see on this issue um even through October um what do you see as the blockers here is it primarily um generally thumbs up across these teams or are there sticking issues on sticking points on some of the time

Oisín Kyne: happy to ask them but I think we're mostly aligned I think the the main change between the last 30 of stuff was this was suggested as a V2 endpoint for the subscriptions one and it was going to be just like returning true and then we said actually let's just bring it

onto its own endpoint of Standalone rather than have one endpoint kind of do two things and normally when we move to V2 that implies for deprecation in V1 which isn't the case here so the the I think the main changes have been addressed but you know good for client teams to cast a final I bought over then see that it's kind of all good and happy with the proposed changes

but

Danny Ryan: got it um so if your team is not taking a look at this I do request you do so maybe by the end of next week and if this issue is not resolved by the next call then we will attempt to resolve it live sounds good

sounds great thank you

cheers

Danny Ryan: okay and Mikhail engine API spec Improvement

component

Mikhail Kalinin: yeah so there are two main questions for making this proposal right to the spec um yeah so the first one is the um engine gate capabilities method uh do we need the this method at all so the um the default and lazy in terms of like probably not lazy but less complex in terms of specking out and Engineering is

the optimistic strategy suggested by yatic it can be already implemented so we have everything for this so it's basically uh if CL knows that they're going to be an update on the L side and it starts to support the for example a new payload P2 method and yeah it starts to send the nucleot we do method to the El if El doesn't support this method that Returns the corresponding error and then clful falls back to to the previous version so that's basically the optimistic strategy try and fall back on error

Danny Ryan: some scenarios fallback wouldn't even be

an option right it'd just be kind of a critical failure depending on the functionality between the two versions right

Mikhail Kalinin: you mean that at some point the V2 will be a must right is that what you mean

Danny Ryan: right you could imagine certain structure of the data is just critical for the V2

Mikhail Kalinin: yeah that's correct yeah that that that's correct but uh uh there is like a rough consensus that that we should try our best to um to make the version the next version backslaughters compatible with the current one

so it's uh somehow yeah it it should support and probably in most of the cases we can do it

Micah Zoltu: um when you see the current version we say current version record compatible with the previous one you explicitly mean only one version back so we would not support backwards compatible with two versions back

[Music]

Mikhail Kalinin: um basically that was the agreement uh I don't think we should if if there is no need for this I don't think we should support the engine API versions that are like pretty old older than two two versions from from the current one I I actually doesn't I actually don't see any um any reason for doing it so

okay

Micah Zoltu: I just want to make sure we avoid getting into the situation that like the executionary teams are in where uh their gossip protocol is uh very frustrating because you have to support every previous version that would be nice

Mikhail Kalinin: yeah yeah that yeah that's that's that's the main point of not not supporting because this is similar to support an all hard Works uh that have ever happened like in terms of engineering environment Okay so it um and getting back to to to the engine apis tough to to get build this method so get get get build is basically

returns you all methods that currently supported by by the El and what clken does uh can do with this method is just you know calling this method in the background with the same time sometime out say like five minutes or whatever whatever number of minutes reasonable and once it sees that the new method is added and see I'll just switched to to the new one and uses this new one once it's available so that that's the one of the ways to to utilize this method so the main question is like to see Alpine deaths will they use it uh is it useful for for them um if not if not so we'll probably will

likely to to to use the uh this optimistic strategy as it does not introduce any additional complexity so still climate apps here please go to your code basis and check out the engine API clients and try to try to in order to understand whether it's the weather gate capabilities method will would be beneficial or not so any questions or comments to this for it yeah as Danny said that probably

sometimes we will have to prepare the um payload for El that will not be able to the and we will not be able to make it backwards compatible this thing works considering so I'll take a look at this edge cases potential edge cases okay and the other part is the um the basically decomposition the way that we want to decompose the spec documents obviously we do not want to have one specification document for every methods ever expect out it's just like not it's

just an inconvenient so there are two approach to to the breakdown one is the break down and buy Fork so whenever new Fork is added we have a new document let's check out the new new methods that are related to this Fork was proposed originally the other uh way to do this is to break down by functionality so if method Works a group of methods working with payload goes to one document the other group of methods that works with the focus updates goes to the other one um was proposed by likewise I just did like a couple of examples you can take a

look at them and uh yeah both have downsides and upsides so probably functional is more more [Music] convenient for Developers just take a look add those two

Danny Ryan: I'm a bit biased towards Forks because it's the Beast that I know um but I'm sure both end up working fine

Micah Zoltu: in my experience with documentation you should always pick the one that the person actually writing the documentation wants to do because it is really hard to find people to write documentation so bend over backwards to make things easy for them

Mikhail Kalinin: what's good about functional thing is

that you will have like uh say new payload V1 and then we two and with three in one place and you can incrementally uh Define the specification of V2 based on top of V1 so that's probably and it's it's easier to read and easier to reason about when you have everything in in in the same screen yeah that's that's the that's the main um upside that I can see in this approach

Danny Ryan: yeah I get it I think my bias comes from the writer's side you know what am I what I want this new thing to look like and assuming the writer probably knows what the old thing looks like uh but I'm

I'm that's just my opinion I will cast into the wind I'm pretty happy either way also uh this uh this is really good

still

Mikhail Kalinin: yeah thanks and also in this functional breakdown I try to you know to add we have uh the proposal also has this table of methods where they described uh and the statuses of those methods whether the method is deprecated or final or a draft um so instead of this um I I just try to you know uh I write a

status of each method alongside to to the specification of this method so it's probably easier to to maintain and easier to to work with do not create more entities that you have you should you know spend your attention on thanks everyone okay

Danny Ryan: that's so those look like we're honing in on this um I know that you did want to present it to awkward devs is that kind of the final Blocker in um getting this ironed out Mikhail

so sorry then can you repeat so I I know that you did want to present this on Awkward devs as well um is that the final Blocker in getting this iron ironed out or um what are the substantial blockers in this point

Mikhail Kalinin: oh uh yeah I I don't think it's blocker actually so um I would like to see all devs to chime in on the get capabilities and basically we can debate on the um break the decomposition the way of the composition like uh in a chat or whatever um and yeah um if get caps is uh going to be beneficial so we'll have it and then we will need

to ask your client apps whether they like really um want to implement this okay and support as well

Danny Ryan: got it

Mikhail Kalinin: yeah we do care about ldaps as well so yeah it probably makes sense you know to just give a quick quick uh quick announcement on ACD but I'm sure that I don't know yep that's up to got it probably quick announcement

probably as well

Danny Ryan: so if you have strong opinions ASAP but I would not say that not now since

this on ACD is a blocker okay any other items for today

that they that

Micah Zoltu: small click one real quick um clientiversity.org has two data sources for consensus clients and they're wildly different do we know which one's correct or which one's closer director which one's most likely to correct

Danny Ryan: um is this this is the lighthouse one is the one is a crawler and one is a crypto one is a a blocked proposal attempt to figure out

who's proposing blocks so one's going to map to the stake weight one's going to nap to node um I do I'm looking at this crawler data and it looks very wrong uh based off of my understanding and other crawler data so one they're different to one of them looks wrong

Micah Zoltu: and you know which one is the one that looks wrong because one that says lighthouses sorry

so

Danny Ryan: so block print is the one that tries to analyze validator stake distribution the mega Labs one is a crawler which would give us the node distribution and I'm pretty sure that is wrong and I think our understanding is block print is pretty good there's going to be some error but okay that was it

Micah Zoltu: thanks

mm-hmm

Danny Ryan: yeah I'm not certain if there's a crawler that's in good shape um there is node watch which is presumably against their crawler as well but I don't think that's been updated or maintained in a while so but gives a different View okay yeah anything else for today

Jacek Sieka: I can just make a quick announcement about Nimbus so we'll be pushing out a release I think today hopefully

um big change in it we're finally publishing a separate validator client like we've had one in testing for like forever but this is the release where it makes the official cut so um we'll keep the integrated validator mode around um we welcome everybody that wants to run a separate validated client to join the Nimitz family as well

Danny Ryan: nice yeah I think the machine separation is pretty valuable for a number of users cool anything else

Saulius Grigaitis: just you're just a

question for a member so as we also working on separating the world and so the built-in uh is going to use the API to run or or did you or did you internally did you keep the internal access to the beacon

model that's a

Jacek Sieka: question for members uh so from a period technical architecture point of view the internal one uses um like a private version of the API

obviously it doesn't go through Json or any of that stuff and it also uses a couple of shortcuts which makes it more efficient like um a lot of efficiency in numbers and initially was based on on these assumptions and like gradually what we've been doing is um making sure that without losing efficiency we can expose the same kind of data to the validatory client um so internally there are a couple of assumptions that one can make when running the validator client inside the beaconode which makes it both a little bit safer like there are errors that

simply cannot happen uh so from that point of view the the internal validator client code remains more simple and and and we're going to keep offering it um but that said like like the external validated client uses the same implementations shall we say it's just that there's a couple of extra failure modes that result from the fact that there's a socket in between and from the fact that um there are some like tiny pieces of information that are not exposed vrs that

a validator client running inside the beaker node can can make use of

okay so just as always so you will try to keep the internal will data client the more or less as is that the title leverages this position of being the internal in the client button in the client right yeah

Jacek Sieka: and I mean it's still a great mode to run if you're just running a few validators because you only have one process as well now you have two or three

Saulius Grigaitis: but um I believe other clients are not following this approach and in the more

like going with this public API approach is it right yeah I think also offers internal

what are electrons um um Perry you want to know is the internal gonna have long-term support on nimbus yeah yeah it's sticking around I think

Jacek Sieka: there's no reason to remove it what we've done is generalized the internal one to to external one and I mean it's also possible to mix and match numbers with you know techu or lighthouse uh validator clients

because they all use their the the same rest API

Danny Ryan: got it okay anything else for today yes happy Beacon chain on the first screen ah yes very good so far so good all right on that note we will close

thank you everyone and we will meet two weeks from today and then we will um take off right around New Year for this call so I'll talk to you all in two weeks thank you bye-bye bye thanks

to everyone [Music] thank you [Music] [Music]

Jesus [Music] [Music] [Music]

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