All Core Devs - Consensus #32

Transcript

[Music] [Music] [Music]

[Music] okay

transition stream over people of the youtube let me know when you can hear us um welcome to the call let's get started the agenda is issue one two three sharing right there first on the agenda testing release updates

Danny Ryan: uh as you know if you've been trying to work on e010 we had some issues with the bls test generators we didn't update them to the new apis and there was a failed soc generic tests which messed up those

generators uh due to some like import issue there is a pr up for this the tests the tests for the bls tests are being stripped down to just those of the apis that we're using um not asking for any potentially internal calls and things like that um thank you for the review from mommy chang and ben on that one uh and carl uh so that is to be released uh because there are a few bugs yes sorry there were bugs in the b010 release um we're gonna release a minor bump to v0101

that has these bug fixes and the fixed test generators um essentially it's v010 um with a couple of bug fixes that are very very small not substantive stuff it's substantive in the respect that they fix bugs but not in like we're going in and changing things that will be released by the end of tomorrow sorry about that but uh thank you for everyone helping me get it out the door um proto is not here but proto's been doing a bunch of work uh getting the repo updated to 3.8 also uh integrating his remarkable

which greatly greatly speeds up uh the pi spec um to something like uh i'll let i'll let him share the numbers uh if he joins us but very very fast uh to the extent that we can start doing a little bit more interesting tests and things with pi spec so that's great um in addition to that i've been working on uh integrating those structurings into what's going on with the phase one stuff and phase one at least as it stands today will be uh finally gotten out of that pr into dev um still a lot of work to do but the build passes there's some some base

sanity tests things like that uh cool none of that will affect most of you too much um except for that release any other testing or release updates yeah sure um i've got a beacon fuzz update excellent um hey everyone since our last update on this goal uh we've published comprehensive blog posts detailing our approach and current challenges with beacon fuzz um we've confirmed that the crash identified on nimbus is indeed a bug related to the committee function as part of the eiffel station processing so essentially when passed invalid or out of bounds community index the

compute committee function raises an assertion error which leads to a crash and we've just identified yesterday an issue in trinity uh related to the validate proposal slashing function and it's actually also affecting the validate voluntary exit function so basically these two functions crash went past an operation with an invalid validator index so essentially index errors exceptions are not handled as validation errors we've opened an issue and submitted the pr for a fix and it was actually approved a couple of hours ago so it's always exciting to see beacon fuzz finding more issues out there uh we've revamped the way we're building fuzzers uh we

made the build process a lot more maintainable uh basically less coffee basting we've deployed a few more fuzzers on fuzzy we're still exploring ways to fix the namespace clash we have been dealing with basically two goal-line implementations so the blog post explains in detail all the possible options and prashan mech is currently essentially trying them all we should hopefully have this resolved by next monday alternatively we might have to deploy buzzers with production clients only so essentially removing the executable specifications we are we're currently looking at integrating the java client uh which should be done by the next update

uh we'll be reaching out to the harmony artemis team over the next couple of days we've identified another difference in the block header processing function on nimbus but it actually turned out to be related to the fact that bls signature verification was enabled for nimbus and disabled for the other implementations so we've therefore submitted a pr to introduce a compile time flag to skip the ls signature verification in nimbus we'll have a new blog post detailing our progress either at the end of next week or beginning of the following week and as soon as a couple of clients are upgraded to the latest version of the spec we'll be updating our fuzzers accordingly that's it for

beacon first thank you

Danny Ryan: awesome that's all great um so presumably those two tests uh two crash inducing um errors highlight paths that we're not testing in the pi spec tests um so i'll circle back with you or something like working on it and see if we can uh add some tests to the spec yes sounds good we have the corpora both the beacon state and the actual block objects that trigger these crashes so it should be easy to add them to your uh your testing

screen sweet thank you any questions from eddie great other testing release updates

Terence Tsao: um is there any update to the fortress um sped test

Danny Ryan: great question um there are now two independent uh formats floating around one that paul is working on and one that members of the harmony team have been working on neither of which are integrated into pi spec but both of which can be used to begin to work on some kinds of conformance again i said this two weeks ago um i've had trouble uh proto and i have had trouble prioritizing that in the in light of just making sure that the uh

current spec and things uh are ready to go for y'all um so i will circle back on that today

oh that's

Terence Tsao: no problem because we actually have pulse testing framework implemented

because paul and i are in talking about using a portal array for a four choice so that's fine yeah go on not a different topic you finish first oh i was gonna say

Danny Ryan: if you do um integrate tests that are generated off of lighthouse i'd love to know if y'all are in conformance

Jacek Sieka: i just want to go back to the fuzzing a

second um i'm curious how we should approach states which would not result from normal block processing so basically i don't know some random data in the state object yeah that means that's one of the way that an invalid validator index might happen right that something in the state is already wrong but nothing in the state should ever be wrong because all the blocks reply to it limit the space of possible states yeah that definitely makes sense that's something we sort of had to do with in lighthouse as well

i think our general recommendation would be to propagate these errors um the right way and you know checking for these assertions uh and not basically crashing when they happen so allowing your your client to recover from that um which should not be too uh complicated so we almost have a pr to fix that particular bug on on nimbus um the trinity bug is again as i said already already fixed just the pian just needs to be managed but um but yeah you're right some of these bugs are triggered from what someone could consider invalid beacon states

so the

Jacek Sieka: beacon state is invalid what's like there's really nothing better you

can do than exit no because the better yeah sorry go ahead like any at the stations and and blocks that you produce will be uh weird yeah did you did you guys have a chance to uh investigate that particular input on your end um no okay but but we've had we've had something similar where basically we ended up um ejecting all the evaluators and then when you try to find you know that later index you get an empty committee and then

there are places in the spec where empty committees are not checked for yeah so i think the case like that's that's kind of realistic-ish like if you have really bad luck with no i shouldn't get i have not much bad luck with the something but if but if if you have very few validators some of the committees might be empty and some might go on so technically there's a chance that this chain could recover but it's not very meaningful because there are social validators um and we've had we've had to do like fixed cases like that and those those were handling

as part of normal processing even though it doesn't really make sense and neither from an economic point of view to have a change with so few red letters or you know to keep going in a meaningful way if you don't have any validators then you can't introduce any new ones so you can screw it anyway yeah but i hear you make sense um i think i would say generally if if we can make sure that the uh the clients can recover from these cases um i would strongly recommend implementing those fixes uh again for for nimbus for that particular test case i think the fix is relatively simple um and definitely for trinity that that's actually the invalid index is

is caused by a a mouthful basically a block it's not it's not a problem with the state itself it's a block processing issue

um so yeah

Danny Ryan: yeah i'd at least angle towards not crashing and if you are in some weird state knowing it um and then going from there but that's almost got a pr for you guys um we're just not sure whether we should give you some time to investigate uh internally but uh we can we can circle back and have a chat on the fuzzing channel

Jacek Sieka: yeah let's do that i mean i think the

best thing you can do in that case is basically dump the state and stop because somehow you got threats there and you want to probably log some diagnostic information or whatever but yeah certainly you can't really continue to meaningfully work right

Mamy Ratsimbazafy: it's basically the um in programming language where's the question of error versus exceptions should you crash now to avoid further corruption or should you hand over to the caller who's supposed to know better about the context yeah it's almost a yeah philosophy question in in software engineering right um depending on who you ask people tend to adopt an approach as

opposed to another i'm personally inclined to propagate the error and let the caller handle it in a hopefully safer way

but definitely debatable okay let's debate offline thanks justin thanks petty okay yeah for the record i'm not disagreeing i'm just exploring yeah absolutely sounds good great client updates um let's go with artemis

Ben Edgington: right that'll be me um so we merged

0.9.4 into master earlier this week uh we're also we've made all the changes for 0.10.0 as well including all the bls changes uh we would pass the reference test if the tests were correct um we won't be merging this just yet we're going to wait until there are some joints multi-client test nets uh at that level and before we do that we're hoping to join some of the existing test nets with 0.9.4 in the meanwhile we're continuing to implement the e1 data changes for 0.10.0 and we are debugging and improving discovery and sync all the time and we've also started

putting some serious effort into optimization we've sort of put it off until now but that's probably underway so expect some good performance improvements there's plenty of low hanging fruit there and finally you may have picked this up elsewhere but we are officially changing the name unfortunately nasa stole the name artemis for their latest space program um that's not really the reason we have a trademark clash unfortunately so in future artemis will be known as teku t-e-k-u uh alongside basu which is our ethereum one client so it's basically um and at some point we'll get around to

renaming the repo and all the rest but it's not top priority just now that's all i think from us

long live tekku thanks ben lodestar

Cayman Nava: hey y'all um so past few weeks we've merged in our initial 0.9.2 branch and we're working through 0.9.3 uh we are working on integrating our new ssc library into lodestar um working through a few bugs and uh getting it up to the

up to uh passing all the spec tests um and we've recently got a new team member uh frankie uh she'll be helping us out and we're getting her onboarded right now and i believe that's that's uh those are the major highlights

uh do you that

Danny Ryan: that ssc library has some major gains right

Cayman Nava: oh yeah kind of uh underplaying that there but uh yeah uh sse library it's we've been working on it for like a month or so now um it it has a lot of gains kind of across

the board so um serialization deserialization is roughly five times faster than before um it also lets us operate on immutable merkle trees uh as ssd objects and in that in the like when when we're doing that um hash tree rooting is a lot faster because we have the tree there and uh we're planning on swapping out our beacon state object with a merkle tree backed object um and if you guys have been looking at the

there's a certain spec pr where they've updated the pi spec to do something similar to this um they've been like really significant gains we're planning on doing the same thing basically so uh for a preview you guys can you can look at that pr but uh we're we're planning on going in the same direction

this is typescript or wasn't

Cayman Nava: uh it's typescript we have um a very experimental wasm uh based merkle tree but right now like the gains are so big that we don't we don't really need to go there

yeah

Danny Ryan: the gains are like on the order of

1000 x for many operations right

Cayman Nava: yeah yeah exactly a thousand x and then so when you when you have like such a fast hash tree root like hashtag root uh i don't know we can do like 4 000 hash hashtag roots of a merkle tree of a beacon state per second um so when you when you have such a fast hatchery you can use that as like a uh as like the the key of a of like some kind of cache so you can do like um what do you call it uh you can basically cache a lot of these different um state transition functions even if they're naive you cache them by the hash

free route of whatever piece of the state you're dealing on and uh memoization i guess is what you call it um so you can memoize these different functions and like just that um speed is like enough to speed up the state transition by like a lot um basically for for us it's like we're right now we're just not fast enough for mainnet to being like i would say pretty uh competitive for mainnet so we're working on um just actually benchmarking out getting real numbers for that so we i can say instead of saying a lot i can tell you exactly how how much faster what exactly that looks like

um is the website simple serialized.com updated with the new um functions

Cayman Nava: no it's not uh so right now i there are still just a few i'm i'm not passing all the spec tests and i want to do a little more polishing and uh so it'll probably be a week or so before at least before i can get get to that

all right cool yeah

Jacek Sieka: at some point like we have the state transition function in wasm publish somewhere on the web which would be cool to compare

them yeah i'd love to i'd love to see that

great thanksgiving yeah um another mind i'm mute okay uh never mind where are we at with my notes um so we've

been working on peer-to-peer uh using the rust library for a quick [Music] a quick solution for that with some help from johnny ria we've got a dot net example working on os x so having issues on linux but we just got

to implement it for windows and then integrate in with our main application but because it's the same library obviously once that integrated it should just talk to the other of our implementations so yes that'll that'll be in the coming weeks

i guess great thank you glad to hear y'all got the rest of b2p going yeah the only example so far but we've got to work on os x and it's talking with the native stuff so it's good great um trinity everyone uh let's see so

a big

Alex Stokes: chunk of work has been updating our client to uh zero nine three which we've landed most of that uh moving ahead to zero ten we have a couple big prs to migrate pilot p2p to trio which is a python library that showed up a lot with stability in terms of the currency of our networking layer we have another pr for the validator client to pull that out and then some work on our beacon node apis to support that uh and probably our most exciting thing this week uh ionic has been working on our disk v5 implementation so he's doing some experiments connecting to lighthouse we can successfully put on enrs from their network so that's pretty cool

and yeah that's those are the main things working towards public

test nuts

Danny Ryan: thanks alex okay and the next three i think y'all all have some version of a public chestnut i'm curious along with your update the biggest hurdle if there is one that you're currently facing with those assessments uh let's start with

prismatic yeah hey everyone from christmas so

Raul Jordan: we've been running our mainnet test net for two weeks uh with not not really significant issues so we have 32 000 active out 29 thousand active out there is 32 000 total

um and at the moment we've been just working through rapid iteration with users on a lot of improvements to kind of the user experience fixing up memory and cpu consumption which is currently the biggest problem based problem a lot of it has to do with copying state fields due to a lack of immutability and go so that eats up memory at an alarming rate and also of course the biggest bottleneck ends up being some parts of hatchery route so there's multiple efforts working on this to resolve one of the biggest optimizations that we did was uh offloading expensive competition that's done many many times to background workers that cache it so you know if we have like a thousand validators on one node you know one validator request or some

piece of data there's a worker in the background that kind of delegates and and returns that value to any other any other future validators that might request it aside from that the other biggest bottleneck was four choice uh but terence worked with proto and paul uh to get that implementation and and fixed it into prism so now we're basically seeing it disappear from our frame our flame graphs um yeah we're working on a lot of unit testing coverage and we added uh some interesting stuff like flashing protection to the validator client so for double double loading surround voting um and also double proposals aside from that we have this slasher architecture that is listening to at the stations and things happening on the test net

and essentially we'll you know we'll track slashing offenses and submit that to the beacon node so we're still working on wrapping up that uh that aspect of slash of uh of this last year itself um yeah so i would say the biggest issue right now is just fixing up resource consumption of the beaker of the beacon nodes at the moment

Danny Ryan: gotcha and that's uh computation seems to be the uh the bottleneck

Raul Jordan: yeah so we fixed memory already now at this point it's just really cpu there's so much so much stuff going on and like the lifecycle of a single slot

Danny Ryan: right gotcha do you have an estimation on the amount of nodes on the network

Raul Jordan: yeah so on average notes have around

80 to 100 peers uh there's a new one there's a website that came out uh recently called to e3 stats dot io created by alethio so essentially they show people can register their nodes so you know we only run on the order of like seven or so we know the community runs a lot more than that so yeah so you can see kind of which ones people have registered on there um but you know aside from that we haven't done a recent topology mapping

Danny Ryan: so given pure counts more than 50

Raul Jordan: yes i think that's that's accurate

Danny Ryan: okay okay great thanks rubble let's see lighthouse

yeah that'll be me again um so we've been adapting for lambda's proto-array fork choice to work in an e2 context uh we're in the final stages of testing and it's been running on several test net nodes uh we're seeing some great improvements there by the way we still need to investigate one era we've been seeing uh polls on it and uh yeah paul's a big fan of the right approach and he definitely recommends it to the other teams he's gained an appreciation for the nuances in the choice role and we're super keen to see some cross-client testing and hopefully very near future we're in the process of updating to 0.10.0 our bls implementation has been updated in the last couple of days

uh we're now working to pass test vectors and i guess a rough eta for a first working version would be late next week we're adding the http api to our validator client to allow for the management validators creating validators deleting validators exiting etc we're currently dealing with some locks that occur during heavy api usage while the node is syncing so we found that we were essentially jamming our scheduler with long-running block import tasks which was causing chaos with mutexes and we've implemented a workaround for now until we can swap over to the latest iteration on

rust async programming which uses a work stealing scheduler we've identified a fork choice bug in our testnet that actually allowed us to discover new bugs and new issues in our syncing logic so we've been addressing all reported bugs from the previous zest net and patching lighthouse as new ones uh discovered um we built a new dedicated thread for block processing that takes the load out of other lighthouse processes which was causing some unexpected issues with timeouts we've added some more robust thinking logic to handle malicious invalid peers we're now testing our thinking with some custom adversarial appears on the testnet it's going going pretty smoothly so far

uh we're continuing to make progress on what we call our v 0.2 which will introduce a significant network upgrade with the introduction of subnets we're seeing a lot more community engagement in lighthouse which is great we've been taking lots of feedback and implementing lots of small ux fixes we're also seeing significant interest in our validator client ui proposals you guys might have seen the rfp that we pushed out a few weeks ago we're still processing the responses the deadline to respond is the end of next week 31st of january to be precise and we'll be announcing the winning vendor uh shortly after uh we're also making great progress on

the hiring front uh so we're looking at hiring one to two more russ developers um late applications are still accepted but time's definitely running out we're looking at moving fairly quickly on this and finally we're also still looking for people to help on a contracting basis with some devops work primary primarily sorry around deploying and maintaining test nets so we're looking to deploy test nets with hundreds of nodes especially thousands most probably using aws so please reach out to paul via discord or twitter if you're interested or if you know someone who's interested that's it for lighthouse biggest hurdle in those test nets um i think we definitely had a lot of uh

a lot of issues uh when dealing with folk choice so the the work that paul's been doing lately over the last couple of weeks i'd say with proto has been quite instrumental to uh fixing those bugs uh but apart from that test that's been running fine um we took some validators offline which resulted in some um skip slots uh which highlighted some bugs that we haven't actually seen before in our sinking so that was that was quite interesting um but um yeah no everything is going quite smoothly on the test net front uh still about sixteen thousand validators uh looking uh hopefully at upgrading to uh v0.10 as i said perhaps late next week

uh and

then um you know upgrading the boot nodes and uh going from there you have

Danny Ryan: an estimation on the number of nodes on that network right now um if you give me a few seconds i think we're about 40 um don't quote me on this i'll have to double check my dashboard yeah we've got about 20 nodes 20p sorry 20k is connected

right

Danny Ryan: yeah i see the 20s per node i guess implies somewhere in that range if not more um okay cool thanks i ask i just you know i think we're all keen to see

test nets with more validators but at this point even more keen to see test tests with more nodes i think you know the 20 to 100 range is still slightly in the the toy range um of the amount of nodes we expect to see on mainnet you know somewhere on the order of a thousand ten thousand if we're in the same range as uh the current ethereum network uh and so i think there's gonna be some interesting stuff that falls out from gossip and discovering things that we're not yet seeing yeah our test net is still actually semi-public right we haven't really communicated around uh the the relaunch

of the test nets i

Danny Ryan: i blogged about it last week so fair enough cool thanks betty

thank you and um nimbus

yes so

Mamy Ratsimbazafy: uh in nimbus we have the spec 0.10 implemented except crypto the crypto bls part should land in by monday i think and it's implemented using milagro we passed through contentus vectors uh waiting for the new test vectors that danny mentioned at the beginning of the talk on bls and ssc on ethereum one we started to implement uh

something called evmc which is an api to be able to switch between gef ls as a cpc plus plus implementation a java implementation and nimbus so this is work in progress and we are looking into how to reuse nimbus ephraim 1 code for ethereum 2 phase 2. um with regard to test net we are in now we can use a mixed ep2p or goalie p2p demon with nimbus and i'll hand over to zari after the other updates so that he can explain the huddles and the number of nodes uh what your questions danny uh otherwise

uh most of the team will be in brussels for first day and the week after between february 1st on february the 7th so if you want to chat or meet us physically you're welcome to reach out to us on our discord and we will be holding a kind of interrupt-like event and we will in particular clone other clients uh test nets and repo so prison and lighthouse so that we can test uh with everyone uh physically there uh that's how to connect to those

uh clients um we also had some uh weekend projects from one community member and he managed to build a nimbus on android and run it on the phone and otherwise uh jasec also had some kind of weekend project and we now have something called n bind gene that can generate bindings to rest libraries so you can easily use rust libraries within nim and now i'll hand over to zari to explain what we have on the

test dates all right

Zahary Karadjov: on the testnet's front we've

been trying to balance between uh implementing request needed new features such as discovery five in knife at the station aggregation and so on and the effort the long washing effort of making the test net more stable in discovery e5 we've merged the latest code and we tried to integrate with with both the daemon and the new natives developed with p2p and we are currently experimenting uh with connecting to the lighthouse uh testnet and obtaining energy from there on the stability problem that i mentioned we've seen for a few weeks already various issues that arise in longer running test nets for example

where nodes are restarted or joined the network later or we've seen various issues with the data structures um the database maintained by the node and the algorithms that initialize the data structures for what we call vlog pool and attestation pool basically we are seeing that uh sometimes when the nodes are restarted their data structures are not initialized properly and the node starts misbehaving so that's our part of the focus is fixing various issues like this uh on the number of nodes we haven't been advertising

our network but it's running on 10 different servers with two nodes per server so we have 20 knows online at all times

gotcha

Danny Ryan: thanks audrey okay i think that was everyone great uh proto did join us um proto do you have anything to add i i went over a little bit uh the fact that we're bumping a three eight a python three eight and um that you're integrating remarkable and that the phase one stuff is going to be in depth soon anything else on your end

red

Protolambda: it comes

pretty well and then gammon explains the ssc changes as well so having a binary tree backed as a cd library or at least using this technique for some parts of the state is really effective especially when you use this to come up with the keys for your memorization of the state properties so fastback gained a lot from this as well speed and this plus phase one changes this usability the thing all gets to be a lot easier to install and to play around with was a outside computer

all lands in dev pretty soon

right

Danny Ryan: right that's something i forgot the ability to just pip install the specs repo um is going to be there and much more easy than it currently is uh thanks

berto um research updates doctor do you have anything on our end you're muted if you're talking otherwise yeah go on um yeah um so i guess

Dankrad Feist: on my end i'm currently um one of the things i'm currently

looking into is like um whether we should um uh change the proof of custody to 256 bit um blocks which um seems probably like more elegant options um odds more performance and i'm looking into whether that's doable in the mpc um yeah and otherwise i guess the other thing i'm currently looking at is data availability where we just got a team to uh to implement um the binary fast free transform um and um and hopefully get some good performance numbers from that to um basically yeah make some decisions

for example what the binary field size should be and also whether we can do that in a slot or if even like the block producer can immediately do all the data availability stuff or if we have to outsource that to like sort of super nodes to provide the data

available because

Danny Ryan: gotcha thanks so much um yeah i mean i mentioned before ongoing work on the phase one specs um really hoping to see something relatively clean and stable in the next couple of weeks um i want to give a couple teams something to dig into on that so we can start

seeing some prototypes but we're not quite there yet um txrx

Joseph Delong: hey how's it going okay so um uh over the past few weeks uh we've been working on a couple different projects um so uh mikhail has been working on this uh e2 bridge and i have some notes from him about uh what he thinks about that if anyone's interested

um and kind of like reviewing the proposals and documentation that's out there right now um alex has been working on um some decentralized time sync uh i have been working on uh crosstalk transactions just mainly like reviewing literature and working on this python the tester for it um then i think that's pretty much oh i'm sorry anton and um uh dimitri have been working on uh discovery v5 testing um and i think that's it for now

yeah

Jonny Rhea: i'll jump in and say that i'm

working with um this is johnny by the way i'm working with matt garnett on ee tooling and so i've we basically kind of specked out a plan um for i don't know like a truffle or or an ee kind of test framework and um he's kind of working on an initial implementation um of like a transaction ee and i am i created the kind of like a a cargo plug-in to um for us to kind of generate the framework of an e but i'll let um i'll let uh i'll let matt talk more about this

so cool cool

Danny Ryan: thanks guys um

other research updates

uh it's

sam from quilt here um some stuff we've been working on since the last call um we hosted a phase two call and discuss the phase one to phase two transition plan and a general phase zero to phase one transition plan uh there's also a write-up we released to support that um anscar and i released the state provider write-up that goes over some of the details of push and pull models of getting state to state provider to block proposers we have a roadmap for our simulation uh is formalized and we're moving forward on it uh we're figuring out how

to attach that and simulate different state provider models uh what else we've been oh i've been working on a small write-up that makes the case for investigating dynamics get access um i'll be posting that soon so hopefully you'll all be interested in reading that uh we've been going through scenarios on our crush rod framework for managing ethan ee balances and i think that's pretty much everything we've been working on as well let me know if i missed anything

guys

Danny Ryan: thanks sam um great other uh research updates before

we move on as you're likely aware the runtime verification audit and formal verification of the deposit contract byte code has been published and is up for review um if you or anyone from your team has kind of the technical expertise to dig in and take a look at the formal specs and provide any input and feedback and review please do now now's the time before this thing goes to production always good to get some more eyes on it [Music] great

that's it for research updates thank you

um networking

Danny Ryan: so we do have a call um in about six days a networking call i think the core of which we will address any um practical items related to uh the sync current specs issues we're seeing and then move on to more researchy items uh if they if we have time um there's also this pr up for adding a response code um it looks like there's a lot of active discussion i didn't have time to

review it this morning but if it's still up for debate on wednesday we'll hash it out there as i said i'm i'm very eager to see some load tests load tests and number of validators obviously but more so in number of nodes so if you do any kind of that work talk to me otherwise we can talk about it a little bit more on wednesday other networking relating id related items worth bringing up today

Jacek Sieka: i think we might announce that

noise

has just passed into the spectrum which might have interested people needs to start implementing that

Danny Ryan: yes thank you um and you all have done some rudimentary work there right for some initial work on the noise integration

uh no not really okay i think adrian's been looking at it but haven't gotten around actually starting the implementation

Danny Ryan: gotcha and i think one of the reasons it

was selected is there's wide language support for the base protocols um but once somebody implements it i'd be curious here about the complexity of the the integration actually using it okay let me talk about it more on wednesday um other networking related items

Protolambda: yes so although i've been busy with lots of other things there are um the naive attestation aggregation technique is getting improved um so i want to do some careful improvements so like not directly pivot to like this one new aggregations aggregation strategy that completely changes things instead i

think we can at least get a lower upper bound on the like on the cost of local aggregation while still being ghost absorbed compatible and so this basically means we can i'm talking about collapse people to achieve this we can change how we track what other players know and what you decide to drop and doing this you can decide to drop messages that's already part of aggregates that are known by your peers and so you can try and reduce messages that way

while still being like able to propagate these aggregates so you don't have full local aggregation anymore you can propagate these aggregates that are that all fit nicely in a sub-3 so you know others that follow the same strategy you'll be able to merge them

Danny Ryan: cool thanks um maybe you can tell us a little bit more about it on wednesday or if you have some time to write up the basics of your thoughts it'd be good just good to see

thanks frodo uh anything else okay um spec discussion

Danny Ryan: uh i know there's a new version spec dropped very recently there's some missing tests there's anything come up in this that they'd like to discuss herman shared 1578 uh which was an issue posted by justin for dual key voluntary exits um which allowed either the hotkey or the colt key for the voluntary exit um i think the main pushback on that is that the cold key in the long run probably won't be

a key but instead a piece of code or a pointer to an e and a message rather than a key um i suppose the counter to that is just use it as it is today and then out of something more sophisticated in the future um but it's hard to know depending on what the structure turns into either we can add that more sophisticated feature in the future [Music] and i guess specifically it's worth highlighting the use case here um the use case likely being i uh i'm in a custodial staking service i have the cold key i do not have

the signing key and the staker starts doing something wrong if they do something slashable they'll be kicked out but maybe for instance they go offline they go totally dark i can't i can't talk to them rather than reaching the ejection balance i could instead if they were offline for two days or something like that just initiate and exit myself um it's a valid use case um other thoughts on this i i need to think about a little bit more on the implications of the future

um okay but herman yeah you brought up

danny

Herman Junge: now the thing is if we have the assurance that the president message is effective always we don't need to do a major modification to the protocol yes do us vitalik suggested

Danny Ryan: right so you can do that right the custodial seeker could give you um a signed voluntary exit that has that was for say your your activation um epoch which is fine and you can you can hold that there are some strange cases in which someone maybe an adversary who makes

a uh some fork of the chain could take some of these messages and make you exit early in this fork um and so there are subtle risks there that are not that detrimental uh likely in most cases i need to think about a little bit more um but that's probably a reasonable approach i forgot that was suggested there um if i or anyone else thinks of some deeper issue with that method uh then we'll share but we'll leave the issue open for another couple of days for any more conversation thanks herman

Mamy Ratsimbazafy: um not really spec discussion but

as a general comment i've implemented the hash two curve spec the new one for 0.10 and cryptospec is quite nice because it's it's blending high-level goals goals the design rationales and the implementation so you have both the implementation which is what we have and also why we are doing things like this and i know that uh we had some feedback about the spec being kind of obscure about uh on the intent uh and well that's just a comment about the

perspective

Danny Ryan: an implicit comment

about the terseness of the spec

Ben Edgington: it may be a good time to unveil my secret weekend project which is um to put together an annotated spec so uh i'm working on that with rationale and digging through github for uh all the reasons why we did all that stuff because this has been a pain point for a long time so um that is something i'm just doing as a personal project but there may be other efforts underway yeah i will publish the first fruits of that in in two or three weeks

Danny Ryan: great and we're continuing to update this phase zero for humans um which is not totally complete in all the things

that a spec probably needs but using it for helping people get on board with audits and things maybe some combination of these multiple paths will get us where we want to be other items spec items general items i think a number of people will be in

denver maybe we'll add like a channel to the discord for that and the number of people will be in stanford right after

for sbc um so yep

Joseph Delong: uh danny we're gonna do a workshop right the day after on um on uh february 22nd

Danny Ryan: great do you all have like resources around that or invite out or anything like that that we should be looking for

Joseph Delong: yeah sure i'll i dropped it in the chat but i'll drop it in again

great thanks there you go

Jacek Sieka: uh a couple of us will be at the ecc in paris as well

uh i'm sure it's worth doing something together there yeah

Danny Ryan: absolutely i will not be in paris uh but some people from my team certainly will be and i know others will so organize the way um i i'm excited to hear about y'all's individual interop effort to mess with some multi-client test sets um maybe when others get together at some of these events that might be a good target as well

Mehdi Zerouali: yeah i'll be in paris as well definitely keen to catch up

yesterday can we

Protolambda: maybe also just create a channel

for paris as well then to coordinate things

Danny Ryan: yeah let's put uh let's add those three channels to the discord um just so people can easily communicate and at least meet up for dinner when they're there

Mehdi Zerouali: um i saw somewhere that there's going to be an eth2 client summit potentially in vienna around headphone does that

confirm

Danny Ryan: i haven't heard of this who's but i'll be who's organizing it um i actually if there's gonna be enough of us there i will be there and i will organize something

um i haven't thought about it

Mehdi Zerouali: i'll be there as well i'll i'm pretty

sure i saw this somewhere on twitter but i might have just dreamt it's getting late here

Danny Ryan: if you come across the source let me know because i'll collaborate with them

um i'll try to pick it up now so shout out to maria paula she has to be like pushing for eve to to be have like a bigger stage on different hackathons conferences so i think she's organizing already like at least the educational part like the part where he hopefully like can answer questions to people who go to the conference and like collect like the death experience feedback

yeah cool yeah found it um yeah it was definitely mp who posted about this i'll link you all the relay post thanks okay um i

Danny Ryan: believe that we will have one of these in two weeks i'll have to look at that real quick i'm gonna be on a plane that day at the exact time of this call um so we'll schedule around that or someone else will run the call

um i'll let y'all know soon thanks everyone appreciate the good work talk to a lot of y'all at the networking call

um you know keep pushing on those test sets thanks everyone thank you thanks bye thanks everyone thanks guys bye [Music] [Music]

[Music] you

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