All Core Devs - Consensus #41

Transcript

[Music] so [Music] okay cool i just transferred the stream

over i actually don't even know if anyone watches these but nonetheless hello everyone and hello if anyone is on youtube um pretty standard got a couple of items that are not on every schedule like quickly discussing key hygiene even in the context of test nets and i know that ran couldn't join us but we'll quickly talk about the api working group i think that we had some blockers but now have some pr's up through here

so let's go ahead and get started testing and release there are a couple of minor clarifications i've made it very clear if anything is in dev that you need to be aware of um i think there's maybe just one thing right now there's a couple of um non-substantive but clarifying and potentially optimizing prs in the well with respect to the fork choice that are up right now i expect those to go into dev soon i will make note of them to all the teams

so you can take a look um and probably do a release sometime in the next week or so but again they're not substituted um other than that uh i think that lighthouse integrated alex's uh four choice tests um we are still going to take a look at figuring out how to actually officially release these um but it's getting some good use out of them today uh other testing and release updates sure um for test nuts i've worked on this validator tooling

which enables you to build these mouse separator wallets to deploy manufacturers for like stress testing or just if you want to deploy your ventilators to different clients easily it's definitely touring though so we weren't too many bugs and it brings up this whole wall of debate and i wanted to talk about how clients either the earlier directed towards a wallet or towards a key store they should try and like convert to this design and light us as some strong points to use a key store specifically instead of being welded centric then

i made some changes to serenity will be integrated into rumor i'm planning to make a chain test to process many blocks and i have some more like that's not like testing instead of just the unit testing of the spectra i worked on e2db it's just this open source explorer wrapping thing which so you explain the latest currently as an api that exposes some functions information and blocks and this passion tooling can interpret this process it into a database for you to analyze the whole business and i've given our users access to this

to build more statistics and figure out where if one photo thing goes wrong where fork secure was taken from looks like all these kind of statistics and yeah that's pretty much it cool so if you want to get your hands on some uh sql testnet data um other testing updates ready yep uh beacon fuzz update um making some good progress on fuzzing lately uh

prism now supports native go builds making it go gettable uh thanks freezing guys for for this much appreciated uh it allowed us to progress significantly in integrating them into our fuzzing framework which already yielded two bugs a panic due to out-of-band slice ranges in go ssz found in at station passing and another panic due to a new point with their dereference found in proposed slashing processing uh we also found the panic in lighthouses in our crate when decoding non-ufa characters which was fixed almost immediately by age uh we've been working on integrating load star as well and we've identified four unique bugs two type errors in the

enr library and two other type errors in the block ssd generalization um i guess in other news we've also been helping with some bls fuzzing uh on the e1 front with the guest team reported a few uh issues there but i guess it's not really in the scope of this call since no one here is using that school library um but it was worth mentioning um we're working towards dockerizing e3 fuzz and we'll be pushing this to lockerhub so that the community can help find bugs and i guess speaking of dockers we've analyzed the oss fuzz requirements and are pretty confident we'll be able to have our fuzzers running on the google infrastructure very soon that's pretty much it

cool yeah so google provides free fuzzing on their infrastructure yep that's right for uh open source projects that are uh highly used and quite popular so we might want to coordinate and uh submit one sort of unique request for all clients um but the docker approach that we have is very much in line with that requirement which is good nice great cool thank you any other things on the testing front all right moving on to test nets updates here

when's the onyx genesis sorry after you can go okay uh the update is prismatic has a test net launching and we will talk about where the clients are with respect to getting a multi-client up but i threw up an item here um validator key hygiene there's a lot here and maybe we'll end up having to take some discussion

out but the original reason i put it up there was the practices that we're going to want validators to take we need to start training them to do them today with respect to our test nets rather than um giving them uh higher requirements on our different requirements once we reach maintenance for example um you know not storing your withdrawal credentials or even maybe generating your withdrawal withdrawal credentials um on the same machine that you're going to be staking on thinking about air gap machines thinking about some of the trade-offs here there are also other components of this conversation including um well it's first key stores

how tied all your keys are together all that kind of stuff so the first again is is a psa to start shifting the docs and shifting things in the direction of um favoring security rather than ease of use even on the test nets but does anybody want to get more into this the keystore verse wallet discussion um related to that for audit proposal we asked the auditors to give us some guidelines on uh secret management so i suppose this is

something very relevant as well and maybe they are the best one to ask about do and don'ts yes absolutely and we're actually we're talking with another security firm to do a top-down look at validating for hobbyists um which would be include some key recommendations but also uh include things like dos mitigation and managing reports well and all that kind of stuff so there is some some work certainly some work to be done here um uh for some prism here uh we've we've had a lot of we've been thinking a lot about this and we're currently

working on a whole accounts redesign um and how people deal with their keys i think we're planning on maybe uh like name spacing kind of basic commands versus advanced power user commands and yeah i agree like like we're going to focus a lot on making sure users know what to do with their withdrawal withdrawal credentials where to put them um but overall most of the feedback comes down to like you know kind of commands are not intuitive like how can i move my accounts from one computer to another um you know where are my keys like how do i how do i safely move them around so that's we feel like there's a lot of friction there and that would be super helpful if we can all like kind of uh think about that together yeah absolutely um

right proto can you talk a little bit more about the wallet verse key store discussion right so this uh this question uh started when i was diving into a philadelphia stores how do i deploy thousands of federators for like stress test networks um with all these different clients and so um the this tooling i built was first gear smarter which is very wallet-centric this means is that you have this option to like specify an adjacent file where to find accounts

right how to uh what the passwords are for these accounts and these kind of things it loads it from this wallet system from eve to which is great but it's not really like meant for clients so much as just managing your keys outside of the client and so how lighthouse differs is that it's very key store-centric it loads all these metadata directories which hold these keys for the photographers that's just a bare json file no gimmicks no not no clutter no index files no nothing it's just the json file with the key which makes deployment very easy if you

can just produce the p and the secrets are managed separately and are managed well in the sense that you have them in some foul you can protect this file from various kinds of problems and you are very explicit about including federatives or not and it checks if new 5 datas are included by accident there's a lot of practices here i'd like other clients to look into for their security so and then i know baku is following suit there it's like doing similar things except that the it's looking like it will be more flattened structure so

not like one there are three verified data but more like a few files per validator in one directory and this all it's more of the same that my point here is what uh account or what t-star type you use uh carl has been working on this new in this standard you should ask him about this um that key being here is it can be minimal and it should be organized at all and we should try to standardize this at least two points where we can reason about deploying keystore files and finishing secret saw carl do you have any follow-up on the

erps and some of the changes coming uh yeah so i've got a few points um one is that i'd like to update the uh yapi 2333 to the new arguments that you solved basically from the vr standard so that's this pr yeah it should basically be a one-liner ball or most people implementing it the challenge here and that's just what i'd like to make everyone aware of and see if anyone has any strong feelings about us and that's that eips aren't very

mentally versioned so it is a bit hard to propose this and i'm a little more concerned about there being multiple versions out there so if as client teams you'll see this and it's something you'll do it then i'd like to go ahead with it and then we can just sort of ignore the earlier version but otherwise i'd prefer not just have a sort of form of variance here then there's been quite a bit of discussion on eip 2334 which specifies the sort of the paths and when the tree that keys exist and a lot of this discussion comes

comes around this idea here which is whether the the sort of the path specifies that keys need to be included uh and which way the keys must exist and that this indicates that uh the withdrawal key is the parent key of each shining key and the argument here is that that's a little bit too stringent because it sort of limits your your possibility but i'm not so sure i agree with the argument so the arguments that the benefits are supposed to be three four one is that the last multiplying complication as in secret shared keys secret shared key scheme is ever going

to be able to follow a path anyway so it doesn't really make sense for me to talk about parts if you can be using secret shared keys because by definition you don't know where they exist and then things like staking services will uh staking services you can still use this to generate your keys so say you want to have your withdrawal keys and the staking service is going to separately derive you well then your withdrawal keys are going to be yours anyway and you can derive the card to not have or not use the signing keys uh for hardware wallets and so that the the one approach would be to have two

separate mnemonics but i would argue that that just gets very confusing and increases the scope for losing keys and so the other option would be to have hardware wallets uh be able to export key stores which would be my personal preference and if this is done then we can just agree that key stores are of the standard for transparent keys and then you can keep your withdrawal credentials in the hardware wallet do any hardware wallets provide that ability at all yeah yeah it seems they do not want to release any of the secrets inside

which is understandable that's the design yeah design goal there yes and of course i'm a little bit concerned because i'm not so sure if they have the power to compute the escrift hashing required to produce a keystore uh i don't know but there may be a limit there uh certainly like the keycard key stores or does the keycard wallets wouldn't but those don't work for bls anyway so help me understand um in the in the argument for clients not knowing or caring about wallets and

instead just caring about key stores that provides kind of maximum flexibility in how you ultimately manage your keys right the more you put a wallet embedded in like wallet standards have to be embedded in a client the more you've become one opinionated on how people generate the keys and two likely if you use this key generation where uh withdrawal credentials and and uh signing keys are generated from the same wallets you've now like tied the withdrawal credentials too close to the client are these the reasons that we proto or carl or anybody's got this why we want clients to only think about key stores uh yes those are the basic ideas it just allows a lot more

flexibility and um i'd argue for simplicity furthermore i really don't think that clients should necessarily want to hold on to uh withdrawal keys yeah no not again that's just scary um and i think the few secrets you can hold on towards the client better but i'm open to part arguments on that point okay i think we definitely agree here for a little house we uh if you decrypt the wallet seed you can pretty much access all possible keys from from that wallet you just derive them um it's probably not something we want okay so and just to repeat

compatibility is also like this main problem i think i have many clients of managing key stores if they all have their own voted system it's not going to work at all yeah okay so there's a handful of things here um one is the evolving discussion and standards the eip standards two is potentially some standards or at least common guidance on how to use keys and key stores in clients is there anything else i mean i know the first encapsulated a lot um

i i think that we probably need to take there's a lot here to discuss we probably need to continue the conversation in other threads and potentially get on a call and hack through this i think we have a lot of other things to cover today um carl can you make sure to share any links where conversations happening is there anything other than the uh the two links you sent that you want people to have their eyes on um for now not really and one other point i'd like to bring up is what clients need in order to start up their validators as in do clients need

access to deposit data or withdrawal keys or is just giving it a key store enough a key store should be sufficient but i know some people have preferences for having more information there right meaning if i handle my deposit in a totally other place how do i actually onboard into a client yeah um yeah anybody you want to share i think lettuce was a neat approach where they keep a directory perfect return have at least the keystore file then optionally you have these other files for depos update uh

about notes um that gets generated only when you need them and so you can start your fabric to register keystore or you can go through through the deposit process with the client and keep the data together which is why i'm like deku is doing it slightly different with this flattened structure a lot of like smaller choices in there and i think paul was planning to write something about his choices and bypass and we should try and discuss the design here yeah um does the uh key store management within the context

and the key management within the context of a client does this warrant its own standard a doc for guidance and eip uh are there any opinions on where this information should be standardized if it were to be i think considering these other things or eips i think we can we can have an eip for standardizing maybe we should organize just a call first of the interested parties and see what they think focus on like the problem before we start from the eft yeah um is there any appetite just yeah i'd be very interested in

seeing like what from you know from minimal operating perspective would be the like the absolute minimum support needed so that we can clearly divide into things that are necessary and then things that clients might add on on top of that this division yeah agreed i mean i think obviously the the minimal is someone can give you a key and you can run that validator likely in the form of an encrypted key store um and anything else is extra because you can handle them with third-party tools and other things well and secret management some very basic management very low

file would be like the very first mice to have basically secret management in the sense of uh how i decrypt these key stores yes yeah yeah that one's that and stuff um so one other small topic on the decryption of key stores and secret management is is anyone opposed to using or allowing unicode passwords for encrypting and decrypting assume a lot assuming we use some form of normalized form what would be the argument against because now but like there are multiple ways to

encode so so that's that's why i'm suggesting a normalized form right yeah but even those like if you take into account their critics and stuff like this very quickly it's heavy my understanding is there are formats which flatten all of this or at least have have one consistent implementation although i'm very nervous too i just don't feel it's fair from an internationalization standpoint to not allow unicode characters are there i mean do password systems commonly allow you to code characters uh many of them don't to avoid this

problem but the arguments for are basically normalized forms should get you around this and it opens your key space to be much larger so if you want a dictionary attack or when i log into like a standard website these days would they let me use unicode not that that's our standard but yeah as far as i can tell like even chinese people are like normally just have passwords that are english if you're letters and numbers so i mean that that's true but i think for like other languages like

german or so there it would not be uncommon to allow things like homeland also and passwords so i'm not so sure if it's that clear card and i feel like the only reasonable way to allow that is to have unicode support so the uh denim the format that's used to generate uh mnemonics um for ethereum right now and that's been used with all these eips and that's you are allowed to use a password and that

password you can use unicode characterism for example so it is sort of an extension of that okay well this is so there is president in this space but we can take this discussion further into that other channel i would be very incredible for this yeah cool um i i was thinking maybe tomorrow but i maybe we want to gather ourselves a little bit more uh let's plan on you know mid next week i'll um i'll organize something in the next day and try to get a good time for everyone uh maybe this time on thursday

but maybe a little bit earlier cool well there's a lot there and it's standards are important but uh even of the utmost importance is getting people to have just good hygiene regardless of the standards um and not allowing them to make really bad stupid mistakes um okay thanks i'm trying to think where this conversation can happen organically over the next few days does anybody have a discord channel key management that's a

good badge yeah okay yeah cool i'll pop one of those up in there all right thanks everyone um great now we move on to client updates we will start with tecu all right that is me uh so version 0.12 update is going well uh bls is done gossip sub 1.1 is done fork choice state transition validator changes are done just finishing off the remaining networking changes and we'll be there we've had a big focus on our memory footprint in the last sprint and we've managed to reduce the

remarkable memory use for hot states and we've just merged a big rework and refactor that limits a number of states stored in memory and regenerates them as needed so looking for some good improvements there other than that mostly fixing bugs i'll spare you the the details um you can check our pr's if you're interested reducing the noise in our logs and improving usability generally i think that's pretty much it excellent and i guess the memory footprint reduction is contextualized by the fact that correct me if i'm wrong the java uh

garbage collection is will essentially expand the memory uh as much as you give it yeah we've got we're talking a lot about how much you can you can trust the information shown on eth2 stats for example um that that reports a kind of whole usage of the java process but that's not reflective of what's actually being used and what java will get out of the way if somebody else needs some memory so um it's uh it looks bad but it's not in reality that bad yeah i got you yeah having run some of the various clients it does seem like most clients are still slowly leaking are slowly growing over time regardless

of that but cool thank you um nimbus hey um so in the past uh two weeks we've had a few exciting changes uh first of all we made the block and attestation processing about 10 to 50 x faster by caching a hash reroute so it's not fully remarkable we took the easy part that didn't need too much refactoring or multiple states to get up to speed we have the validator client split in progress uh

also uh we have our first pr on the conspec 0.5 point x plus the bls part and you can toggle uh at compile time between uh number 0.11 or numbers 0.12 uh still defaulting to 0.11 so that it's easy to just do a mac witty and connect to the testnet we have eip 2340 uh it is uh implemented or in pr uh also uh the audit uh that will be um over four months

uh will start in ten days we'll have an announcement uh with all the details uh plus or the firm that we will be uh engaging with um on the visualization side we updated the graph and monitoring so that it's a bit clearer to monitor a single node before you monitor the the wall fleet uh on the test nets uh witty so we had uh some exciting news for mobile users now you can start nimbus have your computer your phone sleep for a night and on wake up it will re-sync without any issue well at least it did at least once

no on the technical guides so uh we have updated the guides to install the nimbus in particular on phones uh so what was changed in particular was that uh all setup and instructions were referring to the goalie p2p demon but now you don't need to use go or install go at all we have a few platform specific bugs or regression so bug one is on windows 32-bit i really hope no one is using that but we are still testing windows 32-bit because uh it's uh the best way in ci to test 32-bit platforms and we have a regression on arm 64 that

we are investigating and overwatch we had a lot of bug fixes uh our async framework lib p2p in particular memory usage and links and that's all great thank you thank you mommy and does uh does nimbus sink witty to head or is there still the issue with getting to the uh yes when uh when i was mentioning as what's called uh sleeping and uh on wake up precinct it wasn't witty but there is one thing uh we have an issue with the four choice right now uh we have the prototype for choice that

is being living in a pr and somehow when we switch to it we don't finalize anymore and um the fourth choice that we are using right now is a guaranteed split if there is a tie break because we are using as a smaller um hash as a tie break while everyone else is using the bigger hash but it didn't happen yet so yeah tie breaks tie break is generally unlikely but uh yeah you'll be on your own um okay cool load start oh hey um see uh not

too much exciting over the past two weeks um we're probably two thirds of the way through the 0.12 update um most i think fourth choice it's been updated um the bigger thing that's still left is gossip style 1.1 it's in progress we're working with the js the pdp team on that we've been working on tooling to help us spin up ephemeral test nets uh just for our purposes and um as far as like syncing with the test net goes we currently um our initial sync is um fairly stable but we have a bug where

we're not switching over to gossip um or you know from like fetching blocks by range to fetching them by root and relying on gossip and so we're working through that right now and uh becoming we're going to be working on a validator cli we've been holding off because of this wallet versus key store kind of situation so um i'm sure once we get more consensus on that we'll try to follow kind of a standard path towards that great thanksgiving um lighthouse

um yeah so we've been implementing 0.12.1 on a dedicated branch um we've been passing all our tests but still a few more changes to add michael's been doing some great and thorough work on the state transition logic and kirk updated our bls library to suit the latest standard changes paul's been busy rewriting of choice uh too much 0.12.1 and it's now fully separated into its own crate which is good and makes it much easier to hold it um he's actually raised two interesting issues with the spec uh the first one removes a redundant database lookup and the second one addresses an issue that can potentially lead to a corruption of the fork choice store uh

it actually also removes a redundant function call in other news we've made our memory usage available to each to stats uh so not all lighthouse nodes on which key have that updated enabled but for those uh who have it on you can see that the optimization efforts over the past few months definitely paying off um we are now natively supporting raspberry pi's uh big thank you to an external contributor who managed to get level dp to build on arm we were waiting on that pr to be merged upstream for a while and it's been done recently so we've updated our docks to make it super easy for people to build on raspberry pi

um age has finished rebuilding this v5 some people were noticing massive cpu usage on schlesi and it's now completely resolved we also have greater concurrency uh pretty solid boss resistance structure and we no longer require enrs for peer connection uh we can just use multi-others and i guess finally uh trail of bits have completed their first round of the uh external security review they're just waiting on few of our comments before releasing the report um i guess we're happy to say that they haven't found anything critical at this stage they'll be performing the second review targeting the networking stack and the changes introduced since the first review

and also the process of interviewing and selecting another security firm for a second independent review that should most likely take place closer to mainnet great thank you is the um the cpu fixed is that on windy right now or is that a stage for gcr12 no it's been merged uh to my stuff a few days ago okay cool yeah not in lighthouse yet oh there you go i thought you'd it down to my stuff apologies yeah sorry there was there was an issue with the dis v5 uh we merged we merged the disk v5 down into master but uh it hasn't actually hit master in lighthouse yet so that's still coming

ah sweet gotcha um and the dnr verse multi-adder bit uh let's we'll talk about that right after um but it's good to hear that y'all sorted through that um prism hey guys so we are lined to spec version um 12.1 we have shot done the topaz test net we launched the onus test now with version 12.1 we're still 4 000 deposits away from the genesis cons so from the looks of it i think genesis will be sometimes saturday afternoon pacific time we also doing some um

sanity testing on multi-client compatibility with them own it so so far we have tried taku we verified that it sees that either one deposited the same way prism does so that's good news we will try lighthouse next and then and if anyone's clients ready for um 0 12 feel free to ping us we'll be happy to launch it and insanity test it we now have offer of peer go support so you can run go get and start developing in your favorite test editor and then run your tests and stuff and lots of people are happy with this we have full support of netherline and other if one node implementation on prison so previously prison

require access to both http um and then the web starting endpoints so right now we refactor our eth1 code to just use the http endpoint we added a few more um debugging related rpc endpoints such as you can query photo array for choice store you can query individual validators both status so this should come in pretty handy for debugging in the background we're also working on um revamping the validator uh key management so like people said we're researching the uh we're researching the eips we're studying how other clients do it in the current tooling landscape we have been getting lots of feedback from users

on that component so the new ux is very important there other than that i just bunch of minor bug fixes total health improvements and then optimizations and yeah that's about it great thanks terence and good to hear that taku and prism agree on genesis time um another mind we cannot hear you if you are speaking uh sorry sorry i wasn't mute um so the the thing that i'm working now on is the

ethereum 2e2m1 uh integration in nethermine so both of them working on undermined and accepting deposits and the whole flow going through and then i'll be updating also to the latest spec so this uh auto form i believe and we start looking at some of the updates to the um api yeah so these are the main projects at the moment and the testing full testing they want to read all the tests uh to run them automatically they were added to the beginning and then they were neglected and now i have a person full time on testing that will be picking up this project next week great thanks

and trinity hey everyone uh let's see so the main work over the last two weeks on trinity has been spec updates to get up to 11.3 uh grant's been working on that uh some work on looking at optimizations so that we can comfortably run the mainnet configuration and working on implementing an efficient fork choice uh we're looking at using the proto-array implementation that seems to be pretty popular and that's about it uh while i have everyone here i do want to also announce that we are working on a proxy contract

for the deposit contract basically to verify bls signatures and so if anyone wants to talk about that or help review the contract uh just reach out to me offline after i'll put a link in the chat cool is this deployed to the yolo test set actually is it the yolt test net now uh it's not deployed yet but yeah that was something i was looking at doing nice cool okay i think that's everyone on the client updates um afri has an update after your mic's still not working

okay um schlesi's chassis has history uh afree purge the last validator in boot node uh woody's been fairly stable 100 000 slots uh liveliness is generally almost perfect 75 to 90 validated participation um no major issues have been found altona which is the v012 uh next test set to be launched um expected to happen in the next week and a half but right now there's still only one client that's like fully either 12 that's prison so looking at ideally we could launch the four clients this time uh nimbus will be able to hope avery's confident that nemesis will

write a genesis validator as well um that said moving forward uh we'll invite the client teams for genesis so they have a chance to run their unknowns at launch a little bit larger nets um a little more chaos uh and i'm adding vanilla flavor to this and uh if alternate works out then um we can prepare for i won't say the word but a larger scale public it's a client testimony um okay cool thanks alfred and moving on to the api working group update uh marin is really had us been leaving this a lot um he wasn't able to join us in the call um his quick update is uh merge the slash node namespace endpoints there's

openpr's and the slash beacon slash state and slash beacon slash pool endpoints in progress is slash beacon blocks and missing is the slash config and the slash validator endpoints um if you are interested in this stuff there are two open cars for review they've gotten a little bit of review so far i'm going to take a look at them today and like immerse them very soon and again keep your eye out for as you review things that are difficult to implement and things that you know people need to be able to do and it's difficult for it would be difficult for them to do um that would be a signal that something is not so elegant or something is missing

in this api um in terms of uh timeliness completeness uh i think that we generally have the roadmap for uh kind of the space b1 um and that most of it likely by the end of next week will be in this rebo um and at that point uh we can kind of go back and forth if there's any continued issues but we can do you know we can do a release and call everyone um as for remaining discussion points which ben pointed out i am not quite sure what other points are currently being

debated but we'll um if there's anything contentious we will drop it in the api discord as a note for discussion great um research updates anybody want to go yeah um so myself dink rat some uh with the help of some uh academics and justin and other people have been looking at uh virgo trees which are and other like basically

alternatives to merkel trees for estate storage uh that how uh and so i wrote an eighth research post that basically kind of specifies what the problem is about a couple of weeks ago uh the problem is basically that you want something that has all the properties of a merkle tree so it can it's a commitment it can point to a whole bunch of objects that you can make proofs for any objects um if a small piece of the data gets changed that you don't have to like recompute uh over everything to make uh to make proofs uh for kind of relative to the to the new commitment or the new state route um and so forth um except adding the requirements that we want witnesses to be compact

so with merkle trees witnesses are going to be about like even uh well right now they're just completely crazy but even with like optimal binary trees and even it'll be somewhere over 700 bytes per object which is like a bit too much for comfort uh so uh there the main kind of alternative to this so far has been the cave commitment which lets you have a 48 byte proof for basically an unlimited number of elements except it has this a kind of fatal flaw that uh if the data changes even slightly then you have to do a huge recomputation over the data in order to be able to continue making proofs

uh and so we've been trying to figure out how to kind of move past that and the more recent kind of direction that at least i've been going and i mean the ingredient was there even ahead of me as uh virgo trees which is basically a kind of merkel tree style construction made out of cake commitments so basically a tree where the width might be something like you know somewhere in between 256 and uh 16 000 they haven't decided yet and you would have a tree of these and so you you would make a proof by basically just having like the same way you would make any other proof except because the tree has a much larger width and because that gauge

groups are single objects so the proof size would be like basically something like 96 bytes per element is uh isn't looking likely uh so i mean still evaluating this uh but it's also a potential like candidate to uh replace uh things uh even uh merkel tree uh binary merkle you split up the state space into subsets and make a uh taken into each of those and then mercalize them right except well you you can do multiple layering of subsets right so like i would probably favor three layers uh so the the width of each uh commitment

would be like say a 2048 and then you'd have three layers 2048 to the three you'd basically have space for eight billion elements gotcha cool that's it there's a small bug fix uh from when process slots was refactored uh thanks to alex lasso for catching this and i just made a pull request for for that fix it's a small one you can check it out in the chat and this is in um the fourth choice

yep this is a full choice box and is this um does this affect normal or is this an exceptional case um it prevents uh certain target checkpoints to be added to the store basically the ones which haven't been pulled up so when you know you're getting blocks every slot and you could just cross an epoch it prevents those targets from being added to the store okay i'll take a look after things and thanks alex any other research updates

okay great um networking um age you managed to get connected to uh this v5 with multi-adders was there any substantive changes that needed to be made both either to the protocol or your implementation uh the spec supports it um but yeah the implementation so it's an implementation specific i guess uh we had we had we had some issues with our cpu usage now so we pretty much just kind of re refactored everything we kind of rebuilt it from the ground up so it can support it um i think you can only support inline peer key uh

like peer id so like sep 256 k1 and ed25519 keys um but we're using those anyway so so you can do it yeah you just have to i'm not sure how it's it's implementation specific okay um i think the ux around passing multi-adders here for direct connection to the nodes and direct connections are is valuable so if you want some insight on how to do it chat and discord any other networking items great um general spec discussion

anything here okay and open discussion closing remarks anything anyone has cool okay well uh we will have another one of these in two weeks uh we have we will get an api not sorry api a key management discussion on the

calendar and otherwise run some tests soon thanks everyone [Music] [Music]

so [Music] [Music] [Music] [Applause]

[Music] so

you