All Core Devs - Consensus #9

Transcript

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] okay the stream is likely switched over

people from the chatbox let me know if y'all can hear us when you can hear us okay thank you welcome everyone preciate you joining us soon after the New Year's the agenda is pretty short so we'll see I'm not sure how long the meeting velocity but I wanted to keep the momentum moving so I'm glad y'all made it as always we're going to get started with client updates how about we start with lodestar today yeah sure can you guys hear me well yes cool so it was

a little bit slow in some areas but our straight state transition helpers are pretty much complete at this point on the implementation side and we're just untested we started building out the like powa deposit contract listener side so they kind of like out of start functionality of the actual whole thing will work out collecting the deposits up to the chain start event and that we have a kind of stubbed and we're working our way through that to try and get the whole thing started so we can start generating like the genesis and slot 0 and all that that's out of the beacon chain we've

finished up our fixed size number library it's pretty much complete there's a few tweaks when you have fixed in the test cases but it works so we are gonna be importing new incidents and to the beacon chain probably this end of this week or early next week so we can be like as close to a spec as we can especially with types and outside of that we've got we started getting a couple of contributors which is nice outside a chain safe so we have like three people right now contributing actively everywhere from issues to pull requests so it's yeah that's pretty much what's been going on so far and we've

been working on our BLS a little bit more great I'm curious about your the monitoring of the proof-of-work chain are using web 3j s with some underlying climate or what we have it going right now using ethers we just to use ethers and most of our stuff because they also have a typescript he has a Richard credit extra version of it recently I'm and basically just monitoring it and collecting the deposits that way that's what you're gonna asking yeah cool yeah we're just yeah we're just our next thing is just switching over to a job so that we can have the the eath one deposit event being looked at all the

time and then we can collect them in the background and then and so if I'm going to like reparse the spark contract we may just like take it from what's happening behind behind those all right great thank you how about Nimbus hi so in Nimbus we kept in sync with the latest spec changes we also progressed on the I think we're like a one-to-one with the spec regarding state so we now have a state simulator and we can transition between states with for dissemination one epoch per second and the next step

is fortress rule we also have a network simulation working so it works a real time with machine to machine communication and the next step for that is a persistence also as tester generator repo that we had at Terry's has been up streamed to e 2.0 tests so as a shuffling test will the updated where and all the or the new tests will be added where also we also focused on giving the community some way

to reproduce and set up a name Efram 2.0 echo system on their machine so there is now a vagrant container available and a tutorial I will post the link in the chat box and should allow you to set up easily everything you need to run a name and a ferry on in your Linux or Windows machine and lastly if you we also have the development updates in a blog post form and that was done at the end of December so it's like from five days ago and you can have the detail on

everything we were doing India and the link is also in the chat box okay thank you hi so the past two to three weeks we are keeping keep trying to sync with the specs and rework our code based architecture and also we added more custom pipe hinting in Python code base and once it fully finished we can update the spec as well and make the expect

more readable and next week we are planning to give some input for the tree hashing test factors the PI SSE functions are almost finished and also add more documentation in the Python code base so that's our updates thank you how about Pegasus I just find that new button so so we open sourced Artemis over this you know you know

winter break time and we started getting some open source contributors I want to say we had to and we also have a open up the Gator channel for you know communicating with those open source contributors we kind of completed our VRC interface for Artemis we are starting work on GRP see our BLS verification and hash tree root so we opened a minor CR that was closed and merged 351 that was like a modification

minor modification to the validator relay contract and just yesterday we opened an issue regarding the validator records in that kind of in this slot club I think there's like probably update like 28 days ago where the validator balances were moved from the validator record I'm not sure what they call it in Python but I assume object right into a into the beacon state and yeah so that's where we are been still producing is what's new I need to if you don't read that you should and yep I think that's pretty much it for us for updates great thank you

how about prismatic yeah hey this is Terrance from Kris managed so um so I just yes been pretty slow due to the holidays but we have accomplished a lot over the last three weeks we deprecated the old code with the whole spec so it is some code and we align this bag we have implemented about 90% of the blood operations call processing and import processing functions we also finish implementing the function to process the well data deposits and on the libraries and we finish implementation of SSD and the tree hashing algorithm and the similar to Nimbus were working on the

stay simulator as well so we're using a simulated back-end to test per block a block processing like yellow format and yeah that's it awesome thank you how about Sigma prime lighthouse we've been a little bit smaller that's been slow over the holidays both progressing would be stripping out a lot of the old spec Adrienne's been progressing on rostered p2p got a PR waiting for tree hashing which we could we're looking forward to seeing those test vectors that we mentioned earlier so we've been stalling out some

of the new spec stuff to try and avoid duplicating work also we've been moving more towards ink and RPC and also kind of thinking about the architectural considerations around code being shared between components like validator clients and so forth that's better from us great thank you harmony I know in Russia they have their New Year it's the main holiday so they're not here today I know they've been continuing an activity working did I miss any other oh parody critic Hey

yeah we entered the opposite of everyone else we've taken the opportunity of relaxing holidays to do some work or I should say way s so he's been trying to update our previous implementation to the latest version of the spec I think we've run into a couple of snags like the change from Blake to makes it a little bit more complicated for us we have to introduce some abstractions that we weren't finding undoing at this stage the decision to not switch as is said to little endian basically makes it so that we have our existing kind of codec is the same except for endianness so same

thing they would have to introduce a level of abstraction we weren't really planning on overall though I think it's it's kind of phony ok and you know we'll see we're ghosts and if we can keep going on substrates and you know it still still pretty awesome and we get everything else for free but if we can't then I think in the in the new year will once we have like the final version of phase zero really now in January then we'll take a more critical evaluation on whether or not we'll continue in substrate or start a new project cool thank you do I miss any other clients great next up is research updates Justin you want

to start so I guess you know we're still finding bugs all the time in the spec and fixing them which is great another kind of thing that we're doing is trying to simplify the spec where possible and what I'm you know probably a most happy about is simplification of the status code logic so we used to have this somewhat complicated state machine with various value beta status codes and there were all sorts of edge cases when you do transitions that's mostly gone almost completely so it's been replaced

with and time stamps in the in the validator records and we still have some what we call status flags now so it's yeah there's only two flags so it's quite simple one of the things that we're looking to move towards is this idea of a locally computable shuffling so what we have right now with the the Fisher gate logic basically in order to calculate the shuffling of a specific validator committee

you basically have to - it does it scales linearly with what the side of the validator pool and we wanted to scale better and once we have this locally computable shuffling then it means that we can be light client friendly without all sorts of light client specific infrastructure so this means that we can also simplify the beacon state so specifically we had this in my opinion rather ugly shot committees at slots data structure we also had stuff like the persistent committee assignments and and this was

you know again infrastructure for like clients and once once now that we have this this news well now that we have more information about the validators with this time stamps and we're looking to have this locally computable shuffling can remove that we're also looking to potentially remove the the validator registry Delta chain and and rely on the the double bash mark or cumulated that was that was added recently so that's it's not a simplification which is nice I guess I've also tried to push for kind of a clean separation between phase 0 and phase 2 and phase 1 so

a few bits and pieces of logic and and constants have have been removed and I guess other than that I've tried to push for our clean apps of the codebase sorry not the code base of the the stack but yeah I guess that will take quite some time because we're trying to do it in in such a way that is not one big and uh pull the plaster in one go but make lots of small pour requests so I expect that to go on until the end of January but I think overall with world schedule for

having a very reasonable and my spec for the end of January I had a question about the phase zero case one thing I was wondering a little bit what the thinking is there because I saw that some phase one things are being added and placeholders and stuff like this like from a spec implementation point of view that slightly complicates things and I think that if we're going to do phrase one I don't know six months a year after phase year I think we will have learned many lessons there and will want to change it further so as a general approach wouldn't it be better

to focus on upgradability and making sure that the credibility of the protocol is solid and then leave the phase one step out so I would tend to agree so I guess what we've been taking so far is an approach where we're studying the the data structures in terms of the messages that are passed around and gossiped and the structure of the of the deccan state and the idea there was that once we do the upgrades we don't have to fiddle with that and then add special cases and and basically beyond these placeholders we try and

avoid as much as possible any logic for other than for phase zero I mean I I would be in favor of completely removing also the the placeholders but I guess other people in the research team have opinions I don't know what you when you think Danny I go back and forth a little bit it's the balance between you know trying to figure out what the future holds and try to reduce the amount of spaghetti code that will be in these clients I mean every fork if you don't really get get to get rid of logic and get to get rid of old code as you

upgrade a blockchain and so it's a little bit different than creating most systems so if we know something's gonna be there I'm not I'd like for it to be embedded in the data structure but maybe we can make a more informed decision in February it's like if before we launch the phase zero beacon chain we have what looks like the beginnings of a robust phase one spec then I'd say put the two data structures in there and put the components of the data structures in there and but if it seems like a major

unknown then just going out yeah because generally when you're like in protocols in general when you upgrade stuff it's always easy to add things it's much harder to remove them and that might be something to consider for SSD as well whether we want to include the mech like some safe mechanism for adding things agree I think we could especially on this is he consider what upgrading that looks like there's at least some consideration on what upgrading beacon chain looks like in terms of built-in versioning around messages and and data structures but I

don't know as I said my opinion on it kind of goes back and forth I think it's reasonable to have it in there if we have a firm phase one when we're launching phase zero but you can we can take that maybe in a month or so many other research updates pegasus team not to put you on the spot I stay on some researchers I'll speak on the team so main focuses on Stanford blocking conference where we're presenting a

paper on their less signature a Greg a shoe at scale I know that there's some interest amongst those present in seeing details of that so I think the team's busy just doing the doing the tests and the write-up that so hopefully in a couple of weeks we'll have something we can share ahead of the year the conference I think that's pretty much it but today unless the cloud guy II want to add anything no basically yeah we we plan on running a large-scale experiment next week so we should have some preliminary results by the end of next week or in two weeks

so far we only run large-scale experiment on the simulator we can stein now we're planning to do on Amazon ec2 instances so the development is almost is in pretty good shape now and our the experimentation phases is the next one great thank you nuclear I have a question yeah when you say you were running to run largest-scale can you give us some numbers or setup of what you're planning to run on Amazon yeah we so we're gonna try to run on like four thousand five five thousand

notes because after it becomes a bit more expensive so at least that we plan for up to five thousand notes if I remember correctly okay thanks any other research updates for the bunch of the PP update yeah just shorted updates here from BSC so we have we have open source monitors and so it's a Brady on github so we have a first version of this emulator that it's that is ready on running we have a

trident on the computer at this case well and so now we are planning to tackle two questions the first problem that we would like to study with this monitor where the the point that was supposed to the previous phone call about how fast or how slow different charts will evolve in the case of having a short low number of body laters so what happens if we do not when we switch to sharpen we have a lower number of alligators that unexpected then how this will impact evolution and evolution of

different sharks and the old imbalance between chats and kind of thing and the second problem that that I would like to study is related to a point that was raised by Alexey and it was about the relationship between because consume gas in the blocks and they incorporate so there is a there's already a an article paper that was written on this I thought it's quite it's about the couple of years old so I think it would be interesting to do deceptive conduct more take the data and

in the case of Sheldon so these are between the two points I would like to study with this image thank you on the the original of the the first point at which you planning on studying the the evolute you said the evolution of the shards in a I guess the low validator count environment evolution in what respect generally in a low value account environment you still have you have kind of an even distribution across the shards so what what exactly are you

planning on looking at there so if I understood correctly last time when you have a certain number of number of validators what happens is that some charts would have kind of they will take long longer time to be able to to validate or to to cross to the disclose communication between the chart and the beacon chain and for their for their the chart blocks would take longer time to be kind of committed into the beacon chain and that that is because

validators will be working in other charts and so some charge would be working in slower right slowly is this correct understand you know give me something right so the few nuances there there are there are always two shufflings validators so as a validator always have two rules and one of which is a long term role on a shard and I'm always committed to one shard in time and I'm if there's in shards there's validator count over in number of elevators on each shard and the shards regardless of the amount of validators on that shard until you reach

very very low numbers build at the can build at the the normal clip of one block per slot there is another shuffling the they're called shark committees they might change soon cross-linked committees because that's what they do they cross link and which is a separate set of validators from the persistent committees which are building the shards these valleys the time with which the cross links occur can become longer in times of lower validators so although the shard chains are still building at the same clip it is taking they're only getting a finalized reference into the beacon chain on some

slower so instead of maybe one scurry pocket might be once every 2d box or maybe once every 40 bucks and so again you're degrading the performance of being cross-linked in which could degrade the performance on crush our communication and it it might do some interesting things to the four choice rule of the shard chains I'm not entirely sure certain what they're but the pork choice the rule of the shark chain always starts from the last cross-linked reference in the beacon chain and so you might have you have these longer you could have these longer stretches without a cross link so you're

more dependent on the fork choice in the shard chain then then when you're quickly cross link again so there there might be some interesting stuff there around the stability of the fork choice rule but but these shards do are it was still able to build at the same speed they're not they're actually slowed down in their building so that make sense yeah correct for I was it was meaning about I was looking about the cross links okay and and on how they link today little bit contained yeah so I have if there are some there are some things do all right excited to see results Thank You Raoul

from whippy-tippy is here would like to do an update well might be 2019 to everybody I want to say thanks for all the useful an actionable feedback we've received on the on the boat lab we the core team the p2p would be meeting in Porto in two weeks time or an s2 amongst other things finalize the roadmap discussions and of course you're invited to attend if you're around yeah I just get in touch with me this is all condensed public to everybody we finished our goal setting for q1 2019 for the newbie to be project and particularly for the Koenji is the permutations for us to fermentation is

lagging a bit behind we hope we can we can gain speed on that in the next in the next weeks and of course supporting Imperium continued and continues to be a priority and a top level for us and other key topics that we're addressing our multi stream 2.0 to reduce the latency of establishing connections and leverage certain functionalities of new transports that we're introducing like quick which allows for zero round-trip negotiation we're also going to be working on a plan with recording THD 2.0 which basically introduces a number of new functionalities such as overlaid HTS privacy secrecy and other features we're also focusing on interoperability

testing and visualization tools and also we starting to hack well actually start discussing packet switching with a bit more death than we've done in the past I'll post a link to our okiya sheets in the chat box shortly then on the pilot be to be front we are waiting on the brand resolution to move the project into the net p2p organization I think that's gonna pick up some speed as well and January also we've got some some news on the front of the on the front of go package management this is benefit offer of a pain point for a lot of downstream

adopters the the usage of GX as a package manager and we are gonna be taking a spike this water to evaluate adopting go mod in general and even perhaps replacing GX if the hooks that go mod exposes allow us to bring in some features like content accessibility and so on some guarantees that GX gives us and yeah I wanted to provide a follow-up as one of the conversations around that we had in the last in the last call that I was present in regarding the native findings for the Libby to be teaming we have been working on a plan with Pegasus

as well or the contributors of this patch to to support combining native libraries with bridges to do other languages so one of the use cases that we're targeting is embedding the mid me to be demon in environments such as iOS I know that status in were easy 2.0 workshops in Prague somebody from status said that this would be desirable for them I can't remember exactly Queen so I'm hoping that by calling it out in this column president would raise their hand because I think would be able to support this very shortly and I really had talked to to to the Pegasus guys because they've been very proactive about getting this patch merged and

we're defined to find a plan with different with different different pieces to to make sure that this is done in an orderly fashion because it does come I but change a change in architecture and the demon that can post a link to the comment where it that plan is summarized that's all for me open for questions if you've got any sorry I missed the exact point that was pulled off by somebody from static yes yeah so somebody from status suggested that having a deplorable form of living to be for iOS environments and particularly

the little demon would be useful as a first you know experiment of running Libby to be an iOS applications basically the idea that came up with was well now that we have a demon and the demon is exposing local endpoint over IBC and apparently I OS supports IPC and UNIX a UNIX domain sockets then creating a native implementation an implementation of length of the Libby TP daemon that compiles down into a native library that can then be deployed on to the eye on to an iOS environment would be what we do as a first as opposed by Kari I think maybe the concern raised

was that we have to use it as a library we can't run it as a team in a separate process right right exactly so the idea here was to to find a form such that such that an iOS app can start the daemon and interact with it over UNIX domain sockets inside inside the operating system itself I think you're gonna have a pretty hard time actually with UNIX sockets on iOS I wouldn't recommend it I personally don't have any any positive experience in that but I'm open to suggestions there we are definitely out we are introducing the

tcp transport a local host transport as well to interact with a demon and to send control messages to do that back and forth yeah I think this is a good strategy just because of the difficulty of implementation of Lib p2p in in each of the different languages that may need to use it just having them a way it's a kind of like marshal requests into a standard daemon is a good strategy yeah so I can't really say more about the particular requirement on status I

think I think it was somebody from status have you guys been working or thinking about about adopting Libby to be in your iOS apps on our list of things to do we're not looking at it right now we didn't we can take it offline as well and discuss in another forum I would suspect however that the daemon for us is a short term solution generally we would prefer to natively implement particles so any like we appreciate a focus on on on making

language neutral specifications and protocols that can be reimplemented at a networking level as well yeah we are planning to get better at that as well in 2019 and becoming essentially becoming a spec first project that makes it easier for other downstream implement implementer easier to engage and to enter built-in validations we do so one of our focus for the next years is gonna be mobile adoption as well because this is important for a number of use cases offline use cases that we want to address what likely to be I do expect at some point we will be seeking a swift

native implementation of Libby to be for the time being while Swift and of course the Java one is already underway for the time being I think the demon itself so there so the problem with that with a current model of deployment of the daemon is that it's basically a binary right I don't think you can run a binary in iOS just as this so by compiling it down to a native library this would enable you to the demon to strive the demon as a library inside your iOS app and interact with it over you know it could be AI PC or it could be TCP on phones local

endpoints so that would be kind of like the first a first step on that ball yeah but like over time generally implementing a well-defined spec can be easier than bringing in the new higher development environment that is not native to the platform yeah I totally agree with that that is one of our focus for the new feature cool thanks yeah we'll get back to you on on getting eyes but it might take while we're currently focused more on you know spec updates and new stuff in general the

voice yeah got it thank you any other questions for Devon great Felix I'm very glad you're here I was wondering if you could give us a quick update on the state of discovery b5 and maybe give us an insight into what needs to happen before the spec moves into a production ready standpoint and what maybe we can do to help oh yeah so basically the thing in the new year is that so the effort in on the on the discovery of e5 is split into two

different efforts a11 is getting the whole topic thing worked out and then the other one is the actual protocol so I put Frank on the wire protocol so he's basically taking care of that now I don't know if you've met Frank at DEFCON but he is he's also been working on a on the new test tube for for the rest of the PDP so but now that the test shoot is done he's moved on to actually taking care of the wire protocol tasks like just basically getting a a preliminary respect in place and then when it comes to the to the topics yeah so over Christmas like not

much has happened but yeah I'm still at the point where basically I'm trying out the simulations that what's-his-name these the someone from from from brain board did yeah yeah exactly Yannick so Yannick did some some simulations with Oh Emmet and I've been trying to actually you know get this to run on my laptop so thanks that's that's approximately where I am right now but I don't have any sort of I've tried to kind of keep my cue clear on the gas

side so I have more time in the beginning of the year now to you know actually really look into the discovery version five because so far it's always happened that basically I just been swamped with like get tasks and right now I don't have any like big pending guest tasks left so yeah it should actually be possible for me to yeah I'll bet you pretty regularly on on this code by the way like how often are these codes is there like a fixed schedule Felice is are they like every two weeks yeah yeah we do it every two weeks we I think it's been three since the last one because the holidays oh yeah but every two weeks okay yeah I'll try to have you know I'll give you directly like a mixer

invites going directly to you know I I am actually getting in right I've been getting in like four for the last you know lost eight incarnations of this meeting is just you know I've never been able to make it and again like keep us we often work on created in the sharding getter so if there's something specific that you want some feedback on or input or help implementation or anything like that please they be let us know because this is a but really a top priority is figuring out this every protocol because one of the components that is still not quite locked down at this plane yeah all right

cool so I'll I guess I will have more to say like in the next meeting thank you any questions for Felix before I move on okay any other general just updates we didn't have a lot on the schedule today before we move on to any expect questions okay next thing is just spec questions comments concerns on things going on in the spec one question that I

have is regarding running beacon nodes so the incentives for running that there's an active issue regarding that and this is back and there is some concerns that Bruno brought up and the previous call I'm just pulling up the spec right now in which the and we would have to design the validator clients in a particular way in order to preserve piracy because otherwise I wouldn't be able to get piracy let me just search for that so there's just there's many incentives to run be

condemned one would be I'm a validator and I want to have my own direct connection to the network to get the state of the world and sign messages and to see crumpet another might be that I have some sort of service in which I have the state of the world and I provide information about the state of the world to others either for free altruistic aliy or even in some sort of pay model if I needed some more incentive to ride another reason you might run one of these notes is because you are running any sort of application you know a block Explorer II Thirsk and

would run a note or many nodes I mean it's similar in to why why do I run a why do I run a current group of work node one is one small set of people doing that as for mining and the rest are either altruistic actors and the network or people who have applications or whatever and so they again it's pretty much anyone that has a reason to be running the protocol directly would be running one of these nodes and again the the beacon node it's just really just an implementation of the protocol it's like the beacon chain is the core

system level stuff that I need to sync the application change of the shard chains and so that's just kind of the core piece of infrastructure and then I think whatever chains are relevant to my my needs whether I'm a validator or a black Explorer or any sort of application that might need to sync one of these chains does that answer a part of the question what's the question yeah I think that that answers part the question I'm still looking for that issue oh let me see if I can pull up real quick I know the issue I have not comment on the issue in a while but I

know I not closed yeah it's su-15 7ru rego asked a question in the chat is there a reward for running a beacon node there is no similar to running a so again a beacon node I don't know what the correct terminology is that is just an eighth - OH node there is no direct incentive for running one of these there so there's no direct reward for running one piece but if you do want to become a validator post up there seems to be more discussion about this on on reddit so I

think I'll just read through this and then the next call are just joined in next two weeks I'll be asking more about this okay thank you I wanted to ask again about an issue 386 when I had touched on earlier the validator balance is being moved into the validator record become and I guess PR three one seven which was the updates that made the changes to that kind of like doing some preliminary reading the two moving the my understanding is the moving of the validator balance into the

beacon state is for hashing optimization yes in is that language specific to Python you know so that so we should have two states the active state and the crystallized API could say it was small and had to get rehashed frequently the crystal a state was very large and would get rehashed every epoch the we had the separation because we were using a flat hash and really had no ability to cache the components of the state that had not changed her cash fashion when we moved to the SSD tree hash

we now have isolated the various components the arrays and the objects from each other into this hash tree and so you when you say update just the balance of one valid a or a neighbor to rehash most rehash the data structure most of the components of the tree remain stable and you have to do a relatively low number of hashes to update the this was generally perceived as good and fine when we were using Blake as the hash because Blake his house faster than Shawn fear connected

into six when we switch to connect 256 we decided that most of the validator record is not updated frequently but the balances every epoch are being most of the balances of nothing all the balances are updated via their rewards and penalties and so by moving the balances out we've isolated what needs to be the large component of what needs to be rehashed into a smaller data structure and so we're able to benefit from caching the validator record the hashes of the validator records a lot more and

isolate the amount of passion has to be done and this was in an effort to reduce the loss in hash time or the increase in hash time when we move attack 256 boy does that make sense yeah totally totally makes sense okay so maybe I'm proposing and I may open a issue for this maybe a name change for the validator balances just because kind of like because we moved it from validator registry there's kind of like I don't know I think like sort of a naming collision and validator registry

invalid in balances maybe like epoch validator balances or something might be more appropriate um ye but they are they are the balances of each validator so each there's a one-to-one relation between your indicee your validator indicee and and your balance in this validate your balance array it's just we moved it out of the validator data structure so that we can reduce the amount of passion that needs to be done okay I've got it but opens the name changes I don't know if he Puck does what we need to do it explains we need to explain them yeah yeah thank you and there's a few few locations in the spec where there's you

know note this is why this is happening this might be a prime target for a little note it's all covered in what's new in e to keep up Danny I've got one so there doesn't seem to be a lot of documentation about what the expected behavior of a block proposer it's supposed to be a be contained block proposer I guess it's possible to infer it from the spec because we've got the kind of valid validity side is down but as an exercise I I went through what happens you know how our block proposed are supposed to deal with deposit

receipts from the main chain and it took me quite a few hours to reverse-engineer it to try and find out exactly what the proposed is supposed to be doing and I'm still not sure I've got it right and it doesn't seem to be documented anywhere so I've done a lot in the shopping getter what my conclusions are and I'd be glad if somebody can check and make sure that you know correct me where I'm wrong but is there a plan to be a document or a place somewhere where we just spell out yeah talked over that in the past and that you're right the entire what a validator do is implicit on what is valid in the beacon chain which is good and that you can separate

these two things but I think that a an accompanying document of what quote an honest validator does just spelled out very explicitly is I think would be a valuable addition to the spectra though and maybe we can open up an issue for that and January's probably beginning to be a good time to put that in there and maybe it was a little early before just in that spec moving a lot you'd have to be moving two documents at once but I I 100% agree spelling it out makes sense cool I'll be happy to work on that you know it was totally not obvious what the proposer behavior was supposed to be from what's what's written in this back to be great

to write especially with respect to that proof-of-work yeah component yeah I agree okay yeah but if anyone's got time to look at get there in about an hour ago then and please check my working yeah I've been kind of on well I'm on vacation this week and now right now apparently but I plan on getting to the string and get her comments at some point today thank you more spec stuff yeah an equation on the body to client architecture so respect

yeah to validate that block stately physical to triage this thing so does that mean as a validated client you would actually have to compute the state transition from the client side and then attach it to the block then only you propagate the block you shouldn't block to the beacon mode no I would say that the in that relation that the the node is calculating that state route and providing it to the validator the providing essentially a block proposal to sign similar to an approved work minor the node provides a

proposal that the proof-of-work minor is supposed to try to hash so the heavy-lifting I think should happen in the node the the main information that needs to pass along to the validator is enough information so the validator can decide if this is a safe or dangerous message to sign I think strategies for the validator to assess the validity of the information I think that's more of a trust relationship and the validator maybe should be asking multiple notes or something there but I don't think that they I don't think that

that essentially the signing entity should be doing much of the heavy lifting obviously there's a lot of design work there I would say the you're not here you wouldn't nested er I think you're passing more of these block proposals it's a sign so that makes sense yeah someone else is jumping around question Daniel prismatic Janna shot was asked the same thing but with respect the

sinking chard canes I think we don't want we were talking before a lot of spec changes about having the beacon that's okay then send the information to the validator client however like we think that this creates this makes it a lot harder to be couple the two in the sense that you know you can't you know we want to be able to swap the underlying beacon load but if you're really really dependent on one beacon note for everything you do and in particular you don't really have that much data that you store locally without their client and that is and you you're also not fyodor p2p then that becomes a little bit harder to come up with some sort of architecture where you can you know you can easily swap the underneath beacon the having I think the episode I

think the more that I think that makes it much more difficult in that the the validator should be responsible for the data that it's signed and the data that it's signing thanks Jessica and can request that information from any node know that it runs a set of nodes that it runs a node that it runs and some know that it doesn't run it can get that information from any entity gather make local decisions on what if sign store any information that it needs to about the decisions that it's signed so it can make good informed Sims in the

future and then it can pass these signatures along to something that's connected directly to the p2p network to broadcast once you start putting p2p requirements on a validator you've now increased the scope of this entity massively and you've also now directly connected a validator with signing keys to the Internet and to a p2p network full of potentially malicious actors and so I think even from is just a security standpoint you've now moods the validator out of a place of isolation to a incredibly risky place so

again back to the swapping if the validator only asks questions about the state of the world and the state of things that it might sign then whoever whomever it's asking questions to it's easy very very easily swapped as long as there's a common interface to ask these questions once I've put in b2b requirements processing requirements all sorts of stuff I've actually I've started to just build a node inside of the validator when there's already robust notifications why am i essentially repeating all of this logic one of the one of the big things the

data requirements about it is that the validator any information that it's competing proof of custody buts on and it essentially has to store data over long period time it actually has to pull that data down but a node is already syncing data from the from the world it's much easier to just ask for that than for the validator to also have to sync data from the world and again you cannot sync shard data without a constant connection to the banking chain and so if a validator were to have to directly sync shards then the validator would have to constantly be passing

information between it's the shards and syncing and the beacon chain that it's connecting to and becomes all of a sudden becomes like this core piece of the infrastructure to sync assured beyond that a node needs to sink needs to be able to sync shards without a validator existent because there are many use cases for a node one is to be a validator others are to write applications to be block explorers to be a hobbyist all sorts of things people that aren't validators and so - so a note has to be able to sync charts like Evernote can sync shards it's not very useful and if a validator has to

sink shards - now we have to sync shard we have to we have two different entities that have to be able to sync shards which again is sounds like repeat work and kind of like a blurring of concerns that's my philosophy if you want got it cool we'll keep that in mind thank you yeah questions comments concerns I just have a couple comments on stuff that was brought up one point was about the engine nests of simple sterilized I

think credit report that point and it sounded like a decision was made I don't think it decision has been finalized and if there are considerations we should take into account and I think it sounded like there was I would encourage you to comment on the open for requests Patrick the other comment I have is on the honest behavior and I think it's actually very simple so I advise to try and just spell it out in like a couple sentences so basically step 0 is just apply the validating rules on the various blocks than you then you've

received and then you got this this block tree so you have various Forks then you apply the focus rule so you get a simple and single kind of canonical block chain and now your your your duty as an honest proposer is to build on top of the tip of this canonical chain and there's basically only two things need to do from the point of view of the deposit roots which I think was the the point that was brought up number one you need to cast a vote for a deposit root from the theorem 1.0 deposit contract and the rule there and I'm not actually

not sure it's actually spelled out in the in the in the spec is that you want to vote for the latest one which is contained in a block which has height 0 mod some power of two so for example you know every 1024 blocks on the firm 1.0 chain you're gonna have a corresponding deposit root for whatever you consider the if in one point canonical if you're 1.0 chain and then you just vote for that and then as soon you you have to require the threshold of validators who have voted with that specific rule then that becomes you know right now it's called process that

positive roots but it will soon be called latest deposit so you have this latest deposit route and then the second thing you need to do is that you need to include deposit receipts from it from 1.0 into a theorem 2.0 you need to include them in in order you need to include up to 16 of them so that's specified in the max deposits constant which is equal to 16 and you need to include them up to basically the latest deposit route that has been voted upon and I think that's it and I think we're currently missing a validity condition on ordering of those deposits yes that

is it there are complexities there so I think it is worth swelling you know in a document and there is going to be an increasing you know there actually are there are a few others there are a few other things I mean the the proposals but the associations when and and the the timing of when you're expected to do things with respect to a slot like you're expected to attest the head of the slot actually halfway through a slot rather than at the beginning this is just kind of knowledge floating around but not really stated anywhere and again there's gonna be more there's gonna be an increasing number of requirements on a validator as we move through phase one and phase two but thank you for the explanation piston

anything else open discussion I would just point out that the Nimbus thing will be congregating in Brussels just after custom basically on the date February what is it second to roughly eighth will be in Brussels in case anybody wants to meet up would probably have a little hacker space somewhere in where we'll be sitting and thinking I'm in this together awesome we have mentioned something

about a workshop in q1 are there any additional details on that over consensus on where slush when it will be we have general inside of at least from the outside of when we're going to be actually doing an event we've decided to work our asses off in q1 and to congregate in q2 and we don't have locations thrown out where Sydney during ed con potentially Barcelona but again more in the april/may range and yeah there seems to be a lot of people Aidid

Denver right I'll be there yes to do yeah if we want to get together day before just a hack and chat we can definitely do that yeah I think a lot of some marching will be there as well anything else before we post living great okay well thank you everyone for

coming and I was really close to the New Year's and the holidays but I'm excited to keep the momentum going as always when I say to reach out and the getter we'll schedule one of these I think to exempt it we have any conflicts I'm generally out the next few days would be a little bit slower and responding to things but I'll be back in full force on Monday thank you everyone talk to you soon thanks daddy thank you thank you thanks bye [Music] [Music]

[Music] [Music]

[Music]