All Core Devs - Consensus #42
All Core Devs - Consensus · 25 Jun 2020 · 1:32:50
Eth2 client teams and researchers cover testnets, including Altona reaching its minimum deposits with a delayed genesis and the idea of attack nets built to be attacked, a research update on handling weak subjectivity checkpoints, and networking topics including removing non-snappy RPC, Yamux, Noise testing and the maximum clock disparity parameter.
Speakers
Topics
From All Core Devs - Consensus, hosted by Ethereum Foundation.
Transcript
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Applause]
[Music] [Music]
[Music] [Music] Stream should be transferred over if you
are on the YouTube box hey Alexander let us know that you can hear us alright I'm sure you all have the agenda no major surprises here we'll go ahead and get started as far as releases go we there's a few things in there that are conveying there's some additional test cases that have been added I think maybe a network clarification or two yes there was like a simplification in there which gave a method for doing some gossip validations
without using state totally not substantive change but you could be a solid way to structure things from the client side so there's a few things in there I do expect to do a minor version release totally non-substantive with additional tests pretty soon call it by Tuesday so figure out for that I think crazy continuing continued violence in phase one and testing on them so other testing items so I'm extending rumor to do change
testing the idea is to provide is more high-level commands instead of the current so in addition to the current more level are six months so we can do things like sync test more easily and I hope the US byproducts it's not the farming joke you can do some benchmarking and fructose stuff like a curveball Mack radius integration of clients all these different type systems that don't fit also into a client of the unit plans and so if you can reuse the network to thing for that that would be seen then us targets are coming along in the first
results are surfacing and like I want to stay updated with clients if you have any books or things that are being discovered and you keep back for aspect and crew fit please speaking outside instead of any other I fully move on okay test nuts next up I have two items in there altona and attack nuts I know there's been a flurry of discussion altona on the discord and maybe some
consensus on pushing back Genesis I don't know if we've actually hit Genesis deposits in Genesis pauses does anybody have the TLDR on that yes we have reached a minimum number of deposits we also reached previously agreed mini Genesis that was yesterday but we now have the situation that due to some invalid deposits that had to be redone last night that we have technically again as event happening during the night between Friday to
Saturday or on Saturday depending where Lewbert you are and there's this discussion to move this gap in Genesis time to Monday so we don't have to observe those Genesis on the weekend when most people are not available or not as available as doing these days but there's no new proposed Kansas time yet but other than that this test it was ready to go catch and one of the downsides there is the you are planning on being off starting Monday correct yeah but III believe that you will be able to portions Testament
okay I mean the for me personally it's very unfortunate yeah change it and what percentage is the validators do you control on the Genesis I didn't manage to get any in I was waiting for the clients to make deposits and I'm not was controlling the rest of the villagers but I didn't manage to get anyone so was probably fine so men so we're essentially deciding on a delay from what like eight hours ago what do you mean I don't the men Genesis
time like the the Genesis yeah I say in Genesis time what's first days per day yeah eight hours ago right yeah so we're citing on an offset than that yeah so probably just what four days right right yes okay I know before I went to bed last night there was a proposal of adding 72 hours which made 120 hours offset but that was also before the trigger was actually hit is does anybody
have a proposal right now or do we want to just take it to the Altona chat right after this call actually we can take those offline yeah okay let's reconvene quickly after this call in the Altona and toss out a couple of times great okay I circulated a document about tack nets the intention here is to create a specific text Annette you know Altona is probably more of a Deb net attack nets for developers tag nets or for attackers and test nets would be
largely for users the distinction here is for I think most of the users don't really care about attacking and really want to get a feel for validation feel for like what this is you know how things are gonna work in production whereas there's probably a subset of users that are interested in attacking and trying to break things so we'll create a specific zone for that I'm thinking once we see Altona reach some stability we'll take the stable set of clients from that whether that be a subset or all four that are participating at the time and probably to start just have EF internally spin up
a handful notes validators and run a test net that's separate put out some specific bounties just try to get our feet wet and see if people are interested we can also attack these which I think would be fun from there I you know kind of get it up quickly fail quickly see what's up and iterate obviously we can bring in client teams to manage these things as well but I figure at least to start not bringing in client teams and putting the extra burden on them would be probably the way to go it's just generally an update this anyway have thoughts or questions on
this the idea is probably next two weeks have something up have it publicized have some smaller reasonably sized bounties for some particular things and see if anyone gets involved I'm a quick question for the attack net are you looking for client who supports it in an RPC endpoint for example double post double a test and is and and if yes is there a spec or for that right now there's not and opening up these RPC endpoints is potentially dangerous obviously if you keep them in like a isolated debug zone
that don't reach main net that's okay but I imagine that the first attack nets that we put up we might not even make deposits available to really isolate the scope so that we run all validators and the scope of attacks are more things like DOS and other things that aren't related to consensus messages just to keep the complexity reduce I think over time I'd like to open up deposit some of these types of things but I also am happy to put the burden of making bad messages on the attacker rather than order ID for I'd like nuts
was to gradually release sets of keys to parties would like to attack so at first the network can only really be attacked from like a network level but honest this network grows you will see more higher and higher levels of like degradation concerns as level let's see if it falls over right they're equal like I said we're going to
try to handle mostly complexity there rather than adding another burden to the client teams plate but I will keep going for and sure there'll be plenty of questions and stuff okay moving on to client updates let's start with prismatic hey guys been pretty pretty good to week so we completed an audit from constant they found a lot of really great stuff we've been focusing on cleaning all those up and and really just patching up all the serious vulnerabilities that they found onyx
doesn't has been pretty stable so there's 20,000 validators we only control 15% and the metrics are pretty good so now memory has been really really nice prism notes don't use more than one point five gigabytes with default flags and we're further optimizing that I think it definitely correlates with with kind of higher P accounts so we're trying to fix a lot of that and we've been working on also improving /ur so /ur has is using basically flat maps for for basically for for tracking the historical detection and kind of like the epoch span so that's been really nice it's improved disk i/o significantly and make it a lot more variable to run and now we're able to catch a lot of slashings
that have occurred on the onyx that's net and we're also working on kind of planning eval data accounts revamp following the discussions around the IP standard for the keystore and just what the other clients are planning so we've been really really tackling that aspect yeah and we've been also focusing on helping stream duties so be able to better handle reorg situations so that's gonna hide likely help out in situations where networking might not be doing too well and we don't want people to be complaining so yeah overall that's pretty much it just excited for Altona seeing you know hope you can see what's coming next great thank you and congrats on getting through that first on it
Trinity hey grant here some things we've been working on we've gotten the chain components up to date with spec version zero eleven three that's from version zero nine four and we're also getting up to date with zero 12:1 I think we're mostly done with that alex is working on some preliminary refactoring before getting into fork choice updates and I'm working on getting the beacon o'dwyer it up so they can sync with other nodes once we get those things done then we're gonna try and connect to altona but we're anticipating some performance issues
which will then have to resolve that's it cool thanks grant tech ooh hi everyone so we replaced the blocking code in network RPC with like non blocking code started adoption of supranational blast Els library we also limited the number of blocks we keep in memory because that was always an issue for us like if the managing like memory during non finalization periods we would have really affected for choice management and started work on improving efficiency of storage and lastly we merged our 12.1 branch the master in
preparation for supporting Altona as our default Network thanks lighthouse so we've been focusing on preparing for altona you know just sinking prism and deco and all the different nodes we could find to make sure things go smoothly in the past two weeks we landed spec version 12 it's pretty much ready for merge we're running it on our own test net alright well we'll ended a rewrite of our disks v5 library that uses orders of magnitude less CPU which is great we landed a refactor of folk choice which basically covers all the
folk to a structs above the proto array so it's nice to have that we're upgrading our peer management and adding a scoring system in there we're planning an authentication scheme for the valet DUI so that the validator client knows that the UI is authorized to talk to it and the UI knows that it's getting messages from the canonical CC the client that is adding atomicity to add data base to prevent consistency and then the next steps for us is we're going to start integrating the new blast VLS library we're going to implement it with a fullback de Mille Agora we're gonna implement the standard API
get asylum planning an API on the bc we're gonna start /aa gonna review that key management - and hopefully we can start doing more analysis unless hg jamming that's it from us thanks Paul another mind has the most weekly improving the performance of the heat deposits processing and why they trust creation and starting to become known I think comparing it bring our clients who are somewhere at the level of pre-processing to the beginner and obviously a lot of more work waiting especially around the fearing and
finalizing called the latest spec updates we're working on this now great Thank You lodestar ok so we've been mostly working on 0.12 updates we're there except for gossip stub and about 85 percent there on gossip subfield features remaining we're probably not going to be ready for Altona Genesis but that's kind of our near-term goal is to be testament ready there's still not confident that we can reliably sink and and transition over to
gossip so there's still some more work to be done there debugging we have a duty member that is on part-time so that should help us move a little bit faster and we upcoming we're going to be rewriting our validator CLI with some from some of the feedback that we had in the key management call gvsig oh cool thanks kami and nimbus hi so like everyone we're getting ready for
Alpana this comes with improvement in particular we had an issue with startup and reloading times especially after long-running note and it has been improved by about 2200 X this was due to uselessly checking cryptokeys in particular when reloading we had memory leaks improvement of back wall sync now is faster than forward sink we also fixed bugs that were detected by become firs some progress on the valley a true split we have ongoing revolution of the
BLS backends because our back-end is now a bit more than a year old in terms of Milagro and we are regulating between memory Milagro miracle which was open well I made Apache last month and that in has a lot of hash to curve optimization be LST and Harriman's and we also switched to 12.1 by default and when we build Nimbus on the networking site progress on noise goes observe this v5 and also introducing metrics for this v5 on the test net sites we can finalize
on onyx of the onyx Testament and that we are also we also add in the past attested zero and test net1 with permanent nodes and we will be duplicating these nodes for this that one to the weekly test next and Altona on lunch and that's it for me great thank you moving on to research updates does anybody have anything for us I can share some stuff about the week
subjectivity period discussion yes so I'm working on a dock that recommends how weak subjectivity checkpoints are handled by clients and the gist is that new nodes that start up after Genesis if for safety reasons we want them to be sinking starting from a more recent state than Genesis and after some calculation this recent period comes out to be around 14 days so come deployment time it's going to be a very standard thing in the client workflows to release these checkpoint States and distribute
them to new clients probably every ten seven ten days or something like that and I think we need more discussion on how these checkpoint states are to be distributed whether it's in the client code base or some endpoint p2p or otherwise so I guess I'll share the talk in the eats our indie discard and we can probably discuss there and then maybe discussion more in the next call for this so it's a mix between getting security right and a UX problem also but I checked out the talk it's really great
thanks a ditch ax and get that soon Carl where do we stand on key stores VIPs standardization things like that I know how to call last week anything to share following that you sounds very far away from your bike you might be on your computer Micah said your headphones or something that clearer way way better and we had
this issue I got a call the other day so maybe it was that like that as well well thank you ah I see great yeah so much much much care on that front and the lots of new lots of new things discussed obviously due to time trying not to push too many of these things through that aren't necessary and not targeting a new test net for now alternate specifically the changes that have been made yeah P 2333 has a breaking change which is how you derive the keys how much is fearless pls V to key derivation as an how do you take AI K and map it to the
key and then they have been changes to the other yeah peas the paths relax the requirements on where you need to store your paths or which parts you have to use for signing in withdrawal keys not that you can just choose anywhere but if you can't use the pot specified in the EIP for whatever reason then you may use your own but you should try follow the parts recommended to what is a reasonable extent and then the final thing is on the key storefront written some stuff up on how to do you handle unicode and unicode passwords it uses
the same mechanisms that are used already in the mnemonic generation if you use passwords in the mnemonic so you already should have those dependencies if you're doing the mnemonic from scratch of your implementation from scratch there shouldn't be anything added there from a Unicode standpoint and also there's no a description field because that was requested to help users or validators clarify exactly what all the key stalls are for and doubt those are the assets in a current awesome and in terms of key stores versus while it's being what clients are considering is it was there
any agreement on this and is there room for a standard around this to exist so what came out of the call was basically that key stools are the minimum that should be supported by all clients and trying to restrict beyond that's probably not wise we should draw the let's more standards evolve over time so for now everyone that was on the call at least agreed that 23:35 style tea stall should be the standard for exchanging and storing keys at least at a minimum and then stuff on top of that can be
built in terms of standards it would be I would like to maybe add something to the easy to stick switches in a similar vein to honest that annotators and basically just explains what is expected as a minimum not that you're required to implement this to be compliant with the specs but this is seems to be a what is done regimen that I think would be a good approach just pointing to these standards there was some discussions as to hard to lay out these key stores the port all those that they should be located in but all of that is fairly simple but it would be good to have a
description of that and I think that would be a good place to put it okay I know we're kind of in a mix between standards and research but is it any research things that people want to discuss I meant to me I mentioned this in the other other call but that in post on eighth research about using a g'kar to improve hash as much more quickly is something that happened in the last couple of weeks since it seems to be really to be really worth following basically and of the shore well the
short and medium term some relevance SB is basically looking at witness compression and trying to figure out how to make o Witnesses faster and we were looking at polynomial and commitments advert and every coach degrees for some time but this could end up making the sonars darker morkul morkul proofs throughout and if consumed that considerably as more efficient again right more person than the other methods described or I think so in terms of data size that's definitely more efficient
like vertical trees or having overhead of depending on what you do like seems to be about a hundred bytes per obviou you're proving this would have a fully like minimum size like zero zero overhead witnesses I mean like what we have to keep in mind though what it doesn't solve is the security problem with like using we using algebraic hash function and I think that's actually currently the major stumbling block for witness compression so it's like I'm not sure just really I mean I don't know I
still don't understand how much it brings I don't know if there's any reference implementation that would be interesting to know but like my impression is that it might not make a major difference on the time line which seems to be a lay like three to five years anyway witness compression possible mood it might mean something like there are also kind of options in the middle like using Pettersen hashes for the Merkle tree and so forth yeah yes that may be an option to do Patterson instead does it does that play
it lied to her Patterson in the same way I guess it's also there was like a section in the thread and buried but can you drop the child I'll drop it in the telegram one second you know there's a spurious bracket at the end so we can oh that sorry okay yeah just a quick note to mention that starting the devaluation
on gossip shop and and we are evaluating the different types of attacks and yeah so we will be producing I mean showing posting on our sourcing the Euro that I'm just posting right now in the chat but now with the eternal it would be good if also you know plant kind of approaches to ask us for you know different types of we are things that they see in the network so that we can also leak into different things beyond of what has already been done independent in the past regarding gossip so got it yes just some context leo in a master student candidate who are doing a
deeper investigation of gossips of attacks hopefully it's sending to the research that was recently done by the protocol labs so yeah if you have some types of attacks or some particular areas of Gustav that you're concerned about be good to get in touch with you and thanks for showing up you 3po thanks Joseph hey yeah so um tx/rx has past two weeks we've worked on validator beyond minimization and you can see that right up on III search Johnny were a series of there he's been writing a
series called packet ology and the first one is about kind of din and the anonymizing validators and this is kind of like the I'd say just kind of the the rough draft approach and he's been able to do naanum eyes or essentially it connected IP address to public key and we're also working on a face one client using some of the research from Alex's on atolls transpiler for the by speck and that's it other research items before you on great
okay networking open discussion but we'll start with these items that proto dropped firstly Raul no mentioned on an issue Ralph who's not a question on the issue and the specter ago that we're inspect currently supporting a snappy and non snappy specifically non snappy was removed from gossip but both are still supported on the request response domain actually when we were removing when rude inter up I did notice that this was not
kind of under an dropping was implied to be from a net but does anybody have a strong use case for leaving non snappy request/response support does anybody remember why we had supported intended to support both in the beginning and I'm thinking we ever intended to support it was merely so that clients would have time to implement nightly support right after day because in in gossip it was kind of both were stated as Interop was stated
as non snappy main that was stated as snappy whereas request response and just kind of had both and not a distinction so I thought maybe your intention was to support both I don't have I don't see a reason to not remove the non snappy but waiting for someone to say if they have it you know like plaintext debugging or something like that I'm not sure that's it so basically even if we remove it two kinds can keep the book for if they want and it doesn't pretty matter I don't add that like we haven't really run any
numbers on that before I mean yeah everybody have the feeling that like it's kind of a nice thing but it you know we put a finger up in the air and I'm felt which one way the wind was blowing but we don't you know there's enough zeros in those blocks that we have relative confidence but you're right maybe yes do a compression on argument is at the station format it's just still on victims even though on the sickness there's only really one bit so that could princess sweet even well yeah but like then you could argue that
if we move too quick later on that also compressibility layers you could potentially press but but all I'm saying is like we should perhaps just look at the numbers once and see like whether they're yes and yeah because there's the difference like you know 50 50 bytes then you might wonder whether it for at the station so you might wonder whether it's really worth it because still fit within the thing good you know thank you creme on on a normal network so the benefit is then like mm-hmm negligible whereas if it's significant significant
obvious you should be trying it you mentioned quick just quick have you seen the apply that quick has compression built-in is that the case actually I'm not sure I only have it they have encryption but now that you mention it I don't remember if they also through a compression in there I mean it's a layered format so they had like onions that you can add to it alright not let me let me take that it's fine I just had her do that but I also am NOT a quick expert okay I'd say action item is Ron sandy check
compression numbers on single single user attestation relatively full auto stations and then a series of different blocks and just sandy check that we're seeing reasonable compression ratios and if we are I see no reason not to remove the non snappy from request response and again it already is from a from the busted okay does anybody you want to raise their hand and run some quick compression numbers y'all get I'll take Leah raise the soon
are you raising your hand you're like rushing numbers are you raising your hand to say something yeah yeah I would be interesting to look into take a leap into that yeah cool the easiest way you probably need to take a client you know open up whatever they're using for testing and simulations and just produce some objects and yeah I think I think we can try that um which should I fill up with this after the coin there is an open issue on the specs repo a recent issue I'll drop down the chat in which we the suggestion to remove nan snappy was made and we can have done everything okay now what you gonna coming to them thank you very much okay let's yarmulke
support from what I can tell it looks like so not everyone sports Yonex this is like the advanced presumably better and why advanced multiplexer only that is hearsay I can't qualify that with data or an explanation but I think there works there's some issues between White House in prison yeah like support which yeah that's that's the state of things um did anybody have any follow up on that I think the easy thing is for White House
to keep it keep Yonex disabled until we can debug it but otherwise anything else is missing that's the state of affairs as far as I know on that note while we were kissing noise in Witte it was kind of hard to find nodes to connect to because this back has changed the noise back itself so many clients were running probably an older version of this back mmm I just distraught always everybody
updated to the latest one I don't know sorry it'll be an Adrian question a follow-up is is this is the noise effect currently being burdened and if so we should probably point to a specific reason I'm not sure actually I just know that between our first implementation and our second look at it it changed significantly they remove some framing and perhaps this worth taking it to the networking channel so you can get
Adrian's inputs I do know that we can't speak noise with prism at this point I don't know why yeah indeed right it was really hard to connect to people with noise except sometimes I I don't I don't have the details in which kinds work but I have doesn't really matter what calling back to Seco this is the network primarily running on psycho right now and say yes okay you know Noren it's running on tech I oh yeah and the thing was that we're preparing for our audits and ideally we want to disable that IO completely we don't want that surface but obviously
that's not curable now in order for you know general client compatibility let's take this to the safes that networking channel first of all I think we need to figure out if the updates they're making the noise Becker versioned which very likely could not be which we should push for subversion in that and so we can easily confront conform as for I would imagine prismatic go implementation if any has the most up-to-date versions and but I could be wrong there but let's let's just get some info I would really like to not have sec I Oh enabled a new domain that
I'm so thanks well you know it was very lonely out there with knowledge yeah it's easy you know it's easy to conform so with yourself if you can't hear anyone else true yeah infinitely secure chip okay you're just those three points or the other you have a question to ask in aspect maximum clock disparity parameter
that has like a note in there that basically mentions that you know it's set to 500 milliseconds kind of tentatively until the numbers can be verified on the test net didn't even have an idea of like what sort of verification we're looking to do the code we want to validate that number I know that one of the tweaks we did in order to improve our with the performance was to increase that number okay discernment yeah but that's purely how do you say longer searching total thank you it was what sorry I missed
that anecdotal meaning they change the parameter and things seem to work better there's not much okay well that's that's interesting so so basically what you're what you think you're saying is that there were packets or sorry that were like maybe blocks or at the stations that were arriving sooner than been expected and when you lowered that but that number you were yeah exactly because when validating packets for gossip sub one of the criteria is that the package is not to reason
with regards your local clock and if we like there's two ways to and let you can cube the back it up or perhaps you can we go to mother and on the clock and and we didn't want to build the queue so we're just thinking a little bit more tolerance on the clock but obviously like build the queue thank you well yeah the queue is the better solution but then you need to like predict that you were going to do but it's also large and large may not make that number the more validators militia powders and trying to exploit it more
play they have any attacks and things so I had a child I took a look at the email at the numbers just when I was listening for blocks um and and my code was agnostic you know to the clock disparity like you know it would just accept it you know obviously like I didn't see anything that came in earlier than 500 milliseconds but obviously everyone else is respecting that so I guess it didn't surprise me but it didn't really seem like compelling evidence that it was valid either I can maybe open an issue and just throw that chart in there you
can talk about that okay are there any other constants looking like that pass on like let's evaluate this later yeah oh that's a good question the networking items okay any sort of expect discussion
outside of networking great and anything and all stuff go cool I hope someone's taking good notes as we have a bunch of little follow ups yeah you have cold erections hi auntie select thank you then okay I hope you all have a great day and a great weekend and that Altona lunch is
very successfully on Monday let's shore up hop in the outside of Shop Channel right now we can shore up a Genesis offset or to imagine assisting thanks alone bye it's Erin well bye thank you [Music] [Music]
[Music] [Music] [Music] [Applause]
[Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Applause] [Music] [Music]
[Music] [Music] [Music]
[Music] [Music] [Music] [Music]
[Music] [Music] [Music] [Music]