All Core Devs - Consensus #7

Transcript

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] okay I just transitioned the stream let's give it a second to come on

someone from the chatbox let us know if you can hear us usually there's some latency I think they'll be able to hear secondly all right welcome I believe everyone has the agenda I will share it you know chat box there cool so first thing on jinda client updates these can be as long or brief as you want

I know we've been fiddling with the spec a lot which we can talk about so I don't expect suits much progress and what people catching up so if anybody wants to start us off go ahead I always make me call somebody out nimbus give me an update Hey so we caught up with latest spec changes so now we are at most three days off it's I guess a quite a feat given all the changes that were going on we have a name wrapper working for Ally p2p demon so now we tested we can have two

team members chatting freely p2p demon with name rapper we we have mini target of running kind of demo become node for December so in order to do that we reorganized a repo and we cleanly separated what is spec and what is client implementation or network protocol and only Nimbus so it should be easier to track what is custom and what is spec in Oracle and also we will start

implementing Orford BLS signature aggregation scheme so I hope there won't be a fourth but we feel real need for common tests for that we checked Z cash and really tests but we are using your RNG Janet walk tests are good but we departed from Chia BLS signature scheme and as a suggestion I think if we can have test some kind of Alice Bob and if he tests like what is done in ETH repo I will add the link in

the chat box that would be nice and I can after at them as sanity check - yeah ml test file could be in like in appendix of the BLS spec some kind of sanity check it would be to be nice so for me great awesome progress yet the testing step is something I want to be focusing on the next couple weeks so I'll I'll get in touch with you and we can coordinate on the BLS tests thank you in your I'm talking about

pragmatic pls aggregation in your post on ETS research she is using big and slow one and small G - and in a date from L expect it's the opposite for eth 2.0 this is a topic I raised yesterday actually get some clarification that's kind of strange because I thought doing the same thing maybe I'll double-check this back maybe there's some sort of confusion you know

and if there are differences I wonder what their rationale is for having a big puppies and small signatures it would be a definitely good just cross jackets you know whether or not our situations are different cool who's next how about lighthouse we're going to be hard at it next week something for you next next meeting great how about parody no cool so now

we're since we're trying to look back I know stabilized a bit we've been focusing on converting to typescript so we've been trying to create native types for the different types in that Easter - Oh like you and patch 32 and all these different types that's the main thing that we've been working on we're slowly starting a beeline signature um aggregation library as well so if my me later if we couldn't talk about how that's going for you I'm that'd be great otherwise we have no other major updates okay thank you

how about the IBM side me right so yeah I both were helping the ruling of the spec in these two weeks oh not much big process IDs I accept reworking on the data structures and help her functions and the other side we have a internal consensus of the test net the help the Trinity test Nate just fortune at the end is with MVP and what will

what are the components of the MEP will contents so I post the link track and that's our updates I think or anyone else going to better comment no I think you covered how about harmony we are catching up with this back latest updates and we have integrated Milagro and am using it for BLS verification implementation have some some numbers and word for

aggregation and for verification and with the relate to Nimbus it's like one and a half to two times slower but not sure we can judge about these numbers at the moment it's some simulations or test network to to understand whether they are good or not yep so yeah that's that's all for now optimized things yet so even those

numbers are to be taken with a grain of salt yeah but as I understand you you have used Milagro right or did you switch yeah and that's why we used yeah yeah like like a reference to some low level implementation oh all the same stuff right I have a question I remember a few months ago there were concerns over licensing in Milagro because maybe there was something that was unattributed that had been copied into the repo am I remembering that correctly does anybody have any details on that because Milagro is attached 2.0 fully but its release

and a Janet Walker library that can have optional dependency on the new multi precision mat library and Valls will bring either LGPL or GPL requirement and but Monroe I don't think there's an issue okay but are those to utilize the BLS or ensures you don't need to bring in those dependencies it's best if you bring them if you are using your relic because there is three times speed difference like it's a three times faster if you use GMP in with relic or

DNS segregation okay I see things like that clarifies it for me and do use those dependencies I don't because I use my leg rope due to the licensing go okay I was prismatic I'll start with some of this would be a less given that's the topic of this session so we're using the Hiromi library which is you know created by xD Finity person they're using an underlying cryptographic library called

mcl which uses DMP however he actually just removed the dependency on GMP yesterday so we'll have to do some benchmarks to figure out if you know removing GMP is how how slow that's gonna be a session that he is also working on optimizing a Miller loop so that we can have kind of signatures in g2 and then public keys in g1 so we'll be doing a lot more work on that kind of once once he pushes those changes hopefully in next few days yeah I think we should probably see a speed-up on the order of like 3x without GMP way which is unfortunate but that's still left that's the left to be seen aside from that we've been refactoring a code base to match having a single

beacon state that was really nice it cleaned up like it removed like thousands of lines from our code base and we also have a kubernetes kind of configuration in place for a test net we have a basically a DHT discovery working with a relay mode that helps traffic that kind of you know inbound connections to nodes in the cluster and we also have a boot node for the beacon nodes so Preston from our team has been to putting a lot of work on that front I said from that we've mostly been focusing on aligning with respect there is there been so many changes a lot of refactor to be done but yeah I think we're just cleaning up our repo fixing things up and then after that we'll be ready to put in new features and work on

more of that we also have a bounty worker working on a pure gold VLS called 3d one implementation so he's he's basically basing it off the rest implementation and trying to get close to the same amount of performance but yeah that's still kind of to be seen he has some benchmarks but still a little bit slow so hopefully we can get more optimizations on that front but yeah I think that's that's all thank you great thank you have a Pegasus hi hi I'm Jen long with the Pegasus team in the like past two weeks we brought in three new team members to work on that so we have about five people working on this we

started an implementation of simple serialization but then we put that on hold while we implement some of the permanent types that were laid out in the spec because you can't see realize about having the thing so we start writing em a solidity version of the validator real a contract and a team member of ours Johnny ray worked with Raoul from protocol labs on a live p2p daemon as the compile is a like a shared object library so that you can interface with p2p you know with your client regardless of the language and I'll post

a link in the chat box shortly of that repo and that is our updates great thank you curious why are you implementing the contract in solidity for fun so we're yeah it's part of our understanding of how the validator relay contract works okay cool yeah that makes sense thank you did I miss any teams before we move on to research updates I don't think so okay cool we'll move on to

research who wants to start I guess I can start so Justin Danny as Yahweh and ayah mostly have been work working quite a bit over the last ones it's you weeks to like basically get the Prague get the aspect to the point of it kind of big sheets you're ready for what we wants to have for phase zero and it's so the most recent things that we added include there is the tree hashing mechanism the accident crystallize state bird Jing then switching back from using cycles to using epochs which is just a

fairly considerable denied gain in simplicity that and a kind of modification to Kasparov fg8 addictions to cut a couple of bugs along with some code that adds in so that kind of adds in preliminary placeholders for a proof of custody and a couple of other other various small things so it's basically at the point I'm at the point where phase zero as I kind of going through sort of spec rewriting in spec like basically Queen queening up making it making it easier to read attractor I love fixing bugs and simplify and so

forth on the face of one side there's definitely still quite a bit of work to do it adds a couple of Caraway's significantly there's different ideas that I probably want to try try out and think about in terms of exactly how like what data roots get committed into the beacon into the across the data hash that goes into the crosslink but that's something that we still have quite a bit more time for and one of our intentions with the phase zero first phase one is to get all of the data structures needed for phase one all of the beacon chain

related data structures ironed out so like the proof of custody bits are in phase zero so that we don't have spaghetti code with respect to the data structures when we launch phase one but you know everyone always signs a zero so that's kind of the separation of concerns there but why we're driving forward with at least integrating those data structures yeah we're definitely designing phase zero for kind of future compatibility with the array of things that we think will likely ends up one things you accrue for phase one and phase two right I mean I think it is possible even

though we will do our best to have a future compatibility that we might have to change the format slightly there's something we we find after launched I'd agree with with italic that we are nearing future complete there's a few things we want to tweak but at this point I'm now in basically cleanup mode and finding bugs I just the heads up I think there's a still a lot of bugs in the spec I'd say at least 100 bucks so it's just a matter of finding them and squashing them Raven as you were we're gonna try to get on the forefront of doing that and the Python side but if you're implementing and you see things

that are bugs note them because they probably are yeah that'd be great and also I'm kind of thinking about edge cases from a design perspective things that and I've also started a pretty large cleanup in the it's a PR but something like 20 commits so I would just maybe wait a day or two for things to settle before looking too closely at currently the current spec one of the things that I'm working on and it's kind

of helping me as well with the the fine-grain review is that I'm actually rewriting the whole spec in something that I'm calling the transparent paper so it's meant to be a little bit like the yellow paper for if you're in 1.0 but instead of being super formal and unreadable it's meant to be designed for insight designed for readability for transparency and in addition to the spec it has things like definitions of every single term and it has explanations about the sign decisions and things like that

so I'm hoping to get that out in January probably ends up January that's my target and hopefully end up January we will also have you know close to finalized there's speck on github I have a question there how do you prefer your bug reports as like requests then fix them or or just if it needs discussion then an issue but if it's a clear if it's what you deem of clear bug fix then

a pull request is fine and we can discuss there may be I mean just use your judgment but whatever makes sense on that particular yeah I mean if you do a pull request I think we'll try to move fast on the pull requests especially those that are on controversial so I think every day I'll just go through the pull request and just merge what's low-hanging fruit and on controversial so we should be moving faster on that from Leo from the I think Barcelona BSC Barcelona supercomputing has joined us

today he was at the client workshop in Berlin and presented some of his work but now that the spec is getting into more of a stable place he's interested in collaborating again and Leo if you want to do a quick intro talk about some of your previous work and some of your potential intentions for future work sure so thank you yes so what the idea that I have that I had for research and on the chart nothing was to try to build a simulator that can

run in a supercomputer to simulate that we are at this position right now in a in a higher level so we don't even simulate before you're cutting on an ally transaction of any kind of real minor but ok um we try to is that because of the microphone output of the connection and not totally clear I'm not sure okay I would try to talk slower maybe that will make it fear so I have already a first prototype of the simulator that

can run in about a hundred of undress however this this prototype that I have at this point is not completely completely up to date with the last developments on the spec it does include the basic things like the big hunch thing and you had all that more basic stuff but nothing has been added in the last couple of months so yeah I the last few weeks I have been a little bit busy with my other hat which is the supercomputer hat so I had a conference

we had to do some of papers and and I was finishing a European project so I there has been no much progress in the last couple of weeks on the chart in simulator however I did give a talk about shardene in a meet-up in barcelona with the last the last aspect is changed a couple of emails with Justin and Vitalik and on that for that talk so I think I have a their vision of where we are right now with respect and I hope that in the next couple of weeks I would be able to get up to date with a and with respect on this monitor great thank you

and what type of data do you have to report on so the idea is that we want to try to see different aspects of you know how the particle chain will will behave following disrespect and flight simulations that cannot be done easily in a test net for which we are clients so for example the kind of experiment that we want to try is like maybe in different latencies to different different nodes different clients on the on the on the on the net worth trying to say that I don't have to change and put

rate trying to see different loading balance between the number of transactions to see how that affects the number of example number of cross card transactions and basically there is the medians a wide set of ideas that of testers we can run a decimal editor well I think initially the idea is to is to have something that runs more or less in a in a similar way on on on what we'll have today I mean without shots of course but that we can say that more let the simulator that we have running in

the supercomputer kind of really represents at least a block chain without charts and then after that we can more or less say okay this could be like of a baseline and we can assume that the relations are accurate as well any questions really up for move on oh and George from Claire Maddox I think you're unmuted we have a lot of background noise from you Thanks

cool any other research updates anything going on with the Pegasus team I know you'll have a lot of people taking into some Network research yeah so on one part we continue to work on the Trish based aggregation so we've got something working but it's still very basic you can go in the public repository and we will do mock test in the next weeks as a part of this we would like to try a quick photo curl in leap into P so it's something that is

currently under implementation and will appear to be Tim and we've got some packaging issues so we will need to wait so I work for this we will not try quick I ever we will find with another library so we don't forget stuff yet we need to discuss we spent some time on with similar tax as web-based to peer level so that's a good issue and the p2p heater but recreated and the idea is that on one we've got 15,000 node so it's very difficult to take a control of

a network why a theorem to English sounds we've got a few on words of nodes so you can add you can add two thousand three thousand three thousand nodes please to another and they can delay the messages and it's quite important in a time too because we know that for example for blood producers we have a few seconds to send their blogs so you can clear it a bit network so it's it's small topic to take into account but the big issue but likely when we need to follow up on that and the obvious solution is to have a

lot of pills which way we can avoid being a text but it means as well but you unless boundaries available because you're going to speak to a lot of people so if you're interested in this topic we can have a look thanks they need to keep originally I'm working as well so something but it's still in the thinking process applying like onion protocol at the p2p level to increase anonymity and a little bit more it done on the network so thinking about this kind of stuff likely will create a

few issues in the near future sorry yeah hi you Adam sorry continued presentation of a tool that we are using for the consumer protocol simulations wittgenstein so I will likely put an invite on Twitter on Twitter if you're interested on this it would be next week like this and I finished it's great to see that you've decided to experiment with quick I wonder if these packaging issues that you're encountering have you been I've been able to open an issue for

this in the community I think so I think it's watcher who created that we saw a description between you and Sebastian maybe and Sebastian water to white on this issue until it's totally finished where implementation is totally finished okay yeah I'm participating in order fishes three days so if you can just send me the link through the chat or somewhere else I can make sure I keep track of that that's great and then on the on the other hand you mentioned something about the tour of potentially tour transfer and onion transport just wanted to point out that we this is on

the Libby to be a road map which is a point in the agenda for later as well so it would be great to have you pitch in as well and raise the fact that you know you are looking into that as well this is for us it also feels a little bit like you know scope creep feature creep

so there's the question how much say quick for example is that something that we want to target for I don't know March or is that just a fun thing to explore right now and to keep door opening for the future yeah I will quit as well an issue I wanted to do baton quick good as a subject to be discussed and I don't have any opinion for March it's likely to be aggressive if we wanted to have this form up I my opinion it's difficult to have it for much but it's an opinion

yeah so from let me to be quick is definitely a priority for us it is true that the spec is in finalized yet I think upstream so it will be we have been closely following and tracking it and we're working with the Libby to be in the Libby to be teamed as there's a member that's actually engaging with a working group of the IETF working group and keeping the implementation up to speed with all the developments there so we really and it is being I think the latest one of the latest releases of ipfs has a flag to enable quick the quick transport as well so it is being tested on an experimental basis out in the open I think it's good to target or

to potentially consider quick in the long in the medium-term so to speak yeah but I don't have any say regarding specific dates or or anything but yeah I think it's definitely something to consider it to keep on the map but what exactly is quick transport thank you so much Jessica yeah sorry so quick is a UDP based transport that provides many of the guarantees of TCP in terms of pack of congestion control in terms of reliability and a few other things it also implements multiplexing protocol stream multiplexing and it also includes security and encryption constructs on

top of the transport itself so it's basically the best of many worlds over UDP it allows us to basically allows us to to keep multiple streams open and an assembler ways HTTP to at the same time it implements TLS night security guarantees and all of this with potential with a number of features such as session resumption zero round-trip bring negotiation and certain cases and so on so it's it's very it's a very promising protocol going forward and the reason why quic is important in this case is because the p2p for now is mostly a stream oriented it has three

more as a as a primary abstraction so implementing so using UDP constructs so this is message oriented transports right now is not feasible with the current abstractions we are this is on a roadmap we do want to create potentially in the future stream orientation on top of UDP so it's really it's really promising in in many in many directions reasons for us to use it when it's something that is going to be used for HTTP 3 so it means that it's universal protocol and you won't be able to distinguish between basically our

communications and standard HTTP communication so in terms of this question being a little bit hidden on your network it's useful and the second reason is hopefully it's not sure it's something that we need to look at but hopefully we will be able to use it to connect to a lot of peers without consuming too much resources ok and it can be interesting for example for a testers if a tester believes that someone tries to Samsung BAM it's interesting if it can push we're at the station to as many nodes as possible so without maybe being

connected full-time but they can connect a lot of em just sending a very small message with signature and then the other so it's very interesting from this point of view and so on this so format but slightly difficult but in one year of two years it's likely to be very very interesting and aside aside from that as well the fact that is udp-based allows for much better opportunities to to pierce through knots and to perform hole punching and many more and different techniques that allow for better connectivity going forward so there's really many many advantages cool and to be clear due to the modularity of

the framework that would be once we decided to move on that front it would be a matter of adding that transport to the p2p yeah that's that's correct it's intended this way it already exists the transport already exists and it is operational that's it's being used by ipfs already in with this experimental flag so so yeah it's it's it already exists and it works in that way yeah it's just you just need to add it to your host cool thank you very much any other research updates for a new on Hey oh yeah this is Joanie ray I was I was gonna see and specifically asked for Oh

about adding you know a flag to the p2p daemon to to expose that quick transport would that be something that's fairly easy to do yeah I think I think so I think that's that's something that we can do if you can just find an issue for that well we'll get it we'll get it moving cool thank you great on the topic of p2p the next thing on our agenda is discussion of p2p discovery protocol I know that in a lot of discussions especially around DEFCON there's been a general coalescing of

thought on moving towards discovery v5 as the p2p discovery protocol I just wanted to bring it up in this meeting so that we could talk about it decide if it is ready if it meets our needs and if it's feasible to start using now and for people to start building it does anyone want to speak to discovery b5 and it's used in our protocol I can maybe say something about it I like it

my initial concern was that it's not fast enough but I don't think that's correct I estimate it a little bit and I should yeah not be too slow I also think that it's not too difficult to implement as long as there's a Kodama explanation because it appeared on top of Kedah me and when SCAD amia is ready then reading it on top should not be too much work and the only problem I see is that this Beck is not very yeah well written at the moment and there's some stuff missing and there's also no wire for the coronation about this but that's something that I guess

we can work with Felix and the existing serial networking team with and source that I think and discovery b5 specifically implements this future that we need which is topics advertising the topics that you subscribe to are there any other protocols any other discovery protocols that are that do give us this feature set and that are under consideration is anybody know hi in this site

so I'm looking into a similar kind of a vertical where there is a peer-to-peer discovery so last week I have figured out I did a lot of research and I figured out that there is something like there is some startup hooded hoho bill does something like in SDK it's a like and peer-to-peer network system which basically connects either the Bluetooth Wi-Fi and okay I think I'll send you the link on the chat so basically it requires the Wi-Fi Bluetooth or Bluetooth classic it's especially built for the IOT devices and they are working

it so they basically the mode of connecting is there are two modes of connecting the system first one is a proactive protocol and second was the reactive protocol so the problem with a proactive protocol is that it's good in the finding the nearest devices but it's difficult when it comes to the scaling so they are right now looking into the reactive discovery protocol model so and I'm bit curious if anyone is working on the similar kind of approach or something I would like to collaborate on this vertical so what was this call sorry what was the name of this protocol

yeah it's it's holic or hula brood of all and I'm sorry I'm not sure if I understood it is are you proposing this as an alternative to discovery b54 suiting our discovery purposes and their entry point oh no I'm just trying to understand how it hit him to window he's trying to walk on this sorry I'm not I think certain is surely please continue I mean I'll just message those stuff cool thank you okay so let's figure out for the next call what needs to happen

and maybe just get in touch with Felix to make discovery b5 happen so that people can move on it Yannick does if teams were wanting to use a discovery protocol right now and only use the beacon subnet instead of using all the charts and that's would targeting discovery before makes sense and that most of the feature set of before like the underlying components of before is what d5 uses I would say so I think the main before discovery version 5 is Kadhim via thing and that's also

what discovery version on the earlier versions of the discovery was used I'm not sure if like particular discovery version 5 is a good idea if we should should if we should just use Kodama ADHD as part of Libby to be because the discovery version 5 is built on top of the desk PDP second as far as I see we are not really wanting to go in this direction correctly the wrong that the the discovery v5 could be utilized within pity correct so from from our point of view I think we could and I can help

with this we can do a gap analysis between our DHT implementation and the behavior of the etherium 1.0 of the deputy B DHT implementation and because there are some differences in behavior and these ultimately Libby to be intends to be a stack that is usable for a number for any downstream user that is intending to build a peer-to-peer application so really these different behaviors should make it as customization or configuration flags into the let p2p getting the implementation so I would be happy to do and to to collaborate with others on this on the short analysis identify

those areas where we defer and and push tickets and purse changes on our DHT implementation to make sure that we are aligned or it is possible to align our behavior with that of that p2p so then you'll be able to build you know anything that's necessary for discovery version 5 on top of the p2p this is this is just an idea curious to know what you think um that sounds reasonable to me have you there has anyone from Limpy to be been in touch with Felix to this point oh yeah yeah of course we had we had a meeting with him with Guillaume as well and and yeah we're we're super

happy to collaborate ok cool well maybe we'll push forward on that outside this call yeah I believed a critical feature at least it led to the adoption of the v and status was the fact that you could negotiate peers with specific capabilities so that you know that the period for has support for a particular feature but like that's that's something that that that I think we should name as a hard requirement for any every protocol we have that it has this built-in capability of feature discovery of the peers that you're talking to that

that totally makes sense and eglantine the Libby to be a road map there is one goal one point that speaks very loudly to this with service discovery right so it is not we're intending to build an abstraction for so this discovery that can be that can be driven by khadiyah but can also be driven by other mechanisms and other discovery protocols which might be local or might be connected or it might be over a local network they might use different mechanisms and one of one of the one of the protocols that came up as well in Prague was some research work that had been done in a group membership protocol called Brahms and I know that

some other some other teams that were also looking into that so yeah that definitely warrants more investigation okay we'll try to dig deeper into these things between now and then it's called hopefully we can coalesce some decisions relatively soon okay anything else p2p discovery related before I move on okay great the next thing is validator privacy and

roles there's an ongoing discussion around validator privacy in the p2p research Rico does anybody want to speak to that and the conversation student that's been happening there so I think we agree or their that validated privacy somewhat important there's no concrete outcomes of fire but maybe one thing we should discuss this one suggestion to have multiple proposals for each slot and they answer that one if one proposes detect and

there's another one who could replace him yet just wanted to mention that I think Nicola proposed that italic you had some thoughts on area I mean I briefly mentioned the possibility of using some ring signature or some other or link some other linkable one event here at all which proof to prove that you're a validator without revealing anything else but I don't think I said anything more detailed though I meant about multiple proposals per slot oh sorry

yeah I think it basically the it's just terribly complicated say implements at this point and also it runs into and potential race conditions where like what if one proposed or ends up getting delayed by one second and that another proposed are kind of opportunistic we decides to I may you cut out sorry I'm back yeah so it's like those kinds of things that I'm trying to look that we risk if we yeah kind of pushed for to medieval or start doing those kinds of

things like the nice thing about the one validator person alot approaches that it makes it sort of pretty simple that you have this nice big fat six second window within which to either propose or not and if you don't put someone else does right and the zero knowledge proof or a ring signature like construction was in an effort to fight against the potential Eclipse tax of like The Shard subnets right yes I think that's definitely a valid train of thought to consider I

suppose the design goal right now is to make the validator as distinct from their position in the network as possible such that validators can create whatever node set up or set of nodes set up that makes sense for their security concerns I know that's slightly just kicks the can down the curb but I I would err on the side of simplicity on the base protocol unless we have a very compelling solution to increase the privacy native to the protocol will you talk a little bit about yeah respective

like the role of validator with respect to syncing so like you I mean we we spoke a little bit offline about kind of how perhaps the beacon node could be in charge of syncing the shards and then they can hand off to the edge of the validators however like a prismatic we've been discussing this and we don't understand why why this is this sidecar approach is that really is that effective why can't validators just be in charge of syncing shard teams I think the general distinction in the software is that we have a client piece of software that can run and process the entire blockchain the beacon chain and the shard chains and that the validator is

this special user piece of software that connects you and talks to piece of software I think once you put in shard syncing and no peer management into the validator piece of software you now have to client you have new two nodes now rather than you have two node pieces of software and you make the barrier to entry to create a validator piece of software very high I think the distinction of the validator being very thin the validator controlling keys controlling secrets and signing things allows for incredibly diverse setups a validator could talk to ten different

nodes controlling them via commands sync this shard sync that shard ask information about the shards sign information and broadcast as they please but putting actual block processing and consensus rules embedded into that piece of software I think is not going to give you the diverse I think it's optic not the design decision that gives us the most optimal set of potential setups another thing that this does is that the as long as you keep the validator secure he can talk to whatever notes he wants

those nodes don't I mean if he has five notes that he's communicating with and one of those becomes hacked or one of them is dosed it has redundancy and talking to multiple ones if it's instead in charge of syncing its own of data and connecting it appears then it becomes a single point of failure I think that's my general design philosophy is that the validator is this user piece of software that connects to a node or many nodes just like any other user piece of software that might connect to a node and a node should be just general purpose and be able to sync the beacon chain which is this is some mobile stuff and sharp chains that's my general design philosophy obviously it can be

debated thoughts yeah we actually a very very similar discussion the other day when we were looking at the set up and and we haven't quite concluded that discussion but but the same thing was brought up the centralization of all responsibilities to the beacon all including sinking the shards is a little bit odd in the sense that the validator exists to unify what's happening in the shard with what's happening in the big new chain basically and perhaps a way to address this is that you keep the to command API so a little bit apart the

one that controls the shard and the one that controls the beacon or the like the API commands that we don't conflate them into him it's a single unit and what that allows is basically running a beacon node the validator and a shard sinker separately if you desire to do so but it also allows you to implement the beacon mode sure the shard sinker cannot exist without a beacon without the beginning of like a shard needs to know information about the system level stuff for it to remain in sync yeah but that that information can be passed somehow between them right separately it would need to be passed between them basically

in real time and then all of a sudden you become like the validator becomes this like middle it's more than just a this entity that's participating in signing and consensus now it's be kind of now it is like a core piece of infrastructure for a node yeah we can debate this to the end of time I'm sure so we found we've been talking about

this a bit too and something that the way that I was thinking about it was that a validator has this schedule that they need to they need to offer right on so they need to kind of they need to gain from the beacon node this idea that there's like over these periods over these slots they're going to have to to create some actions and there's like this scheduling system so the the solution that I came to that I thought was most sensible person was that the scheduling is inside the the validator client so it's up to it to retrieve a schedule and then to maintain it and so it should kind of fraud the beacon node and say hey you need to sync these shards hey I want you to produce a block and I liked that because it means that the validator can swap around

between nodes and something that I thought would be quite important for a validator service is it needs to be able to have this idea of the quality of service that it's obtaining from beacon node so if it maintains your schedule it can kind of start to have this idea that it's not getting responses from the beacon node and it can swap around whereas if that kind of schedule lives inside the beacon node then you know that then if the beacon Road falls over there's nothing really checking on it so I think my um what I was thinking seems to to link in with what Danny was saying is that right yes yes and yeah so if you decouple shards and beacon nodes as two separate pieces of software that need a

validator to kind of control both of them you now can't run a beacon node without you can't run like a char did you can't run a shard chain beacon note without a validator because you need that piece of like middleware I I see again I see the validator as it's a user it's definitely it's a core user piece of software but it's a user piece of software in the same sense that like the commands the validator has as Paul said as a schedule it knows it got it's asking the system the beacon chain you know what the current shuffling is and it sees there's an update and it knows oh I need to sync this shard so issues a command to the to the node sync this shard and then when the slot comes for

it to attest to it it says what is my to station candidate and the beacon node so like for this certain piece of data the no passes that it signs it and passes it back yeah I definitely support the budget were approached by the UM by the way I have to head off so why great chatting and once in hang with you all later metallic okay let's pick let's pick a place I'll make an issue around this and we can continue to talk about it and maybe even like set up a call next week where we can dig in and debate even more clearly there's a lot of design decisions going on here and to be

fair if you write if you create a client and a validator and it executes the protocol that's fine the reason that we would have this conversation right now is so that we can call us on some sort of standard interface such that these systems become more modular and people can create more sophisticated validator setups but again at the end of the day if you create a V software that implicit all that have less peripheral I was going to say there's also implications for you know the impending staking pools you know and how and how this design you know could could affect how that's implemented you know we also want to kind of I would

think you want to encourage you know a more decentralized approach to staking pools rather than you know some sort of like monolithic setup like how mining pools work right now so maybe that's worth you know just at least keeping that in mind yeah absolutely I think by exposing the minimum generic functions to operate and control these things that we can move in that direction but any any other comments before we move on I clearly I'm I'm very opinionated in this but we I'd love to continue the conversation and

maybe a an issue and then we can get all our ideas in one place sounds good that's great cool sounds good what is next ah yes Raul has mentioned a few times that with 50 P is figuring out their 2019 roadmap mainly just wanted to make ya'll aware of that but since Raul is here you want to give us just a briefing on that yeah so this is really an open open call for participation and in the roadmap we are defining together and this is really the community as a unit

when defining together what we want to focus on in the future not just for 2019 but even in terms of vision and in terms of where we want to take the technology and the future of peer-to-peer networks as well going forward we are expecting to we ideally want to knock down kinda the wish list of all the items and right now we're at a connection sort of like a brainstorm point what week letting connecting input from many communities and of course if you're in being a very good friend and a primary primary straits stakeholders when and to be I think it's very important for you guys to to pitch in to look at what we have so far thanks you know for posting the

link and and yeah definitely point out where we need to pay more attention what is a priority for you what you know different ideas or different things that we should take into account and really we as a community in general so right now as I said this pretty much reads like like a wish list so far and yeah basically the process right now looks we are connecting these ideas by next week or the two weeks after this we hope to have prioritized these ideas and in general build roadmap and a timeline to deliver them for 2019 and and forward

and we really want to we're also working with what the milk' are closest to keep us elves accountable and to keep the community in general accountable as well so so yeah we basically at this point that's that's all I can say just invite you to collaborate read up on this and we hopefully will have locked down kind of like the wish list by the end of this week great thank you so much for joining a call and helping out earlier and tell us about that please take a look at that as he said you know we want to want to get the features in that we want okay next is just general SPECT session questions

about the spec in general things that have changed anything on those lines and as always I'm generally very responsive on the shard and get er or direct message if you have any questions outside of this call I have a question regarding persistent chain splits so the spec doesn't really go into this much but what happens if something that could thou thou situation that happened several years ago which happened and people would want to split and East to - oh how would that work there's a general

versioning structure in there to handle splits and to handle works whether they be contentious or not and so what the versioning does is it essentially puts signatures into separate domain such that people running in a previous version of the software are not colliding their signatures with newer versions of software so in the sent in the case that somebody wants to coordinate a permanent persistent fork they would use that mechanism to essentially run a slightly modified version the software and to ensure that

their signature is there in a different domain that's the short answer these things depends on the nature of the split why this what happened what actually what people were changing with the protocol and with the code but in general there's kind of a with the versioning mechanism for the signatures I think it's kind of under the the idea of domain and version in the in the spec if you want to take a look at that there is a built-in mechanism to handle forking a replay reproduction in terms of the shard data chains and Static yueshen I don't know I I imagine they

obvious this mechanism will be utilized for the signatures across and so in general that would be that would satisfy the shark chance as well as the keychain another question that I have is does anybody have the notes from the starts working group from frog I just shared them yesterday the guys from Starke where got me notes last week that I cleaned up and added to that document I will share them in the chat and on the Gitter again shortly

thank you mm-hmm so I've been greeting just like a little bit intense in since there's a lot of changes going on now I maybe I should just mention a few things they're more like general comments but [Music] one thing is the use of unsigned integers right if you're looking for bugs well one good source to find them is basically unsigned arithmetic you know the few places where simply because my son uses integers you know the order of operations might not matter whereas would sign types you have to consider

these things I don't know how much the spec wants to deal with that really but it's something to look out for I guess a broader issue is that now that we have you in 64 everywhere whether we can get some guidance on reasonable values for Fergie's like take something like a slot index for example slot number we don't expect that to span the whole year in 64 a range but what would be minimally acceptable numbers to for implementations to accept to be called you know conformance respect for

whatever it would be on my wish list another idea I had was that some of the data in beacon in the state is slightly redundant and I think the biggest one would be the shard committees basically this is something that's derived from from a different field in in the state so as far as I'm concerned it would perhaps be more simple if it wasn't in the state but it was but rather that it was fetched at the beginning of processing and then

what time implementers can do is cash it if they wish to you're right I that's an interesting one we've debated a little bit internally by removing it from the state you lose the ability to serve it and to serve portions of it say to light glance and you put the requirement of doing the shuffling and maintaining the shuffling at all times on every client that is in the node in the network so I that's why we have kept it in it at this point but I do I do agree there's there's a trade-off either way it doesn't really add to the entropy of the

block hash or anything and it does add a bit of complexity to keep it maintained like it adds a bit of complexity with respect itself keep it maintained and later we're gonna feel that complexity in test phases and if we ever wanted formally verified respect and so on thoughts on the losing the ability to serve it to light plants if you take it out of the state I can't see that I was a separate service to be honest if it's needed I will though I was also thinking about some parts of the state that could

not be in the state like recent walk cash for example and after some time I realized that for example in the fussing for in its 1.0 you download in the state and you have to download like 256 previous blocks to serve to to run to run the VM correctly and that's what you will have to do after download in the state and if there is no showers and committees and recent walk hairs and all the stuff that you could possibly calculate from some recent blocks you

will have to download those blocks and process them but if you have everything in the state you could download the state and storage syncing from from that point something like that so it's it's pretty handy in the in this case right and one of the one of the general goals has been that the states plus the previous state plus the recent block you can calculate the entire state transition function from the state and that's why those recent block caches are in there because they're to utilize to verify attestations on these epoch

boundaries once you take that out then you put a lot more you make the state encompass multiple blocks and kind of caching and you have the state the states still there and to process everything you still need the state look but you just you've kind of hidden it rather than making it very explicit what this what their requirements for that pure function are III think that we should keep as much and stated as needed for processing and for this kind of rule for transition that you can get you get

the state from just the previous state and for from the current block your processing and until this we can become a bottleneck in some I'm sorry yeah maybe I picked a shorting committees was because it stands out as being very large in the sense that yeah it's the over a later set repeated twice yeah in terms of numbers of items and it's also trivial to sort of computed from from the other data in the state so it's more of a question really and and and I'm not

I suggest I'm just wondering what what the thinking is here yeah I agree we but we need some numbers at least in terms of how much disk space we will need for storing like I don't know some generations of this state so just need to understand how much it will take yeah the the sharding committees if we store the shuffling hash very explicitly like what shuffling hash they came from you're right it's it still satisfies that pure function in that the state transition function takes the previous state and the block it computes the

shuffling and processes the block and act outputs a new state so in that sense it does still satisfy that requirement it just puts this kind of inclusive it puts the shuffling requirement on the on every node let's we can open up an issue and debate that there sound good gave it to me yeah we're cool any other spec related items so issue 129 there's some some debate going on around the use

of simple serialization versus heard of off and you know I'm not first enough on not to speak to it but I'd like to kind of like get some thoughts because you know a simple serialization implementation I think regardless of what we use on the networking layer if we move toward protobufs that we're going to use simple serialize with the tree hashing algorithm for the actual hashing of the state and so I wouldn't I wouldn't say that's a blocker on you right now and that you should empty much simple serialize as for the ongoing network serialization debate or is there

any I haven't been following that one closely is there any updates on that and you new thoughts I saw that some people wanted to run some numbers may be on protobufs I'm not certain one of the main concerns regarding simple serialization from my side was that it's not forward compatible in terms of Eden and you feels to any structure a good example is the chain ID field from is a 1.0 it's been edit and every and it had to be encoded in an existing

transactions structure fortunately it's been done there there was a way to do that but it would be creative simple seriously and has this feature but it's not essential just something that was chain ID retro actively added to existing yeah the transaction transaction the I data structure had been changed and chain ID had to be added but it was at it at some block number not retro actively because that would have messed up the hash chain

yes but the format the new transaction formats the transaction format had had to be preserved because mmm it was not possible to change the format I mean it wasn't possible because all clients had an implementation of this format as an rfp and call it golden and yeah it wasn't possible just to change format I mean to add some new field to that and it had to be encoded as with one of signature parameters within one of the

signature parameters so that could be a good feature for for serialization protocol good feature to have but not not not requirement I think maybe what Dan is saying is that there isn't built-in versioning feature in the in the protocol already and technically it could be handled through that yes yes yeah got it okay cool anything else for today okay thank

you it's incredible to see all the progress going on a super super exciting for me as we said Lots we think we got most of the major changes and additions to the phase zero document done and but over the next probably five days there's going to be a series of just ongoing edits fixing some naming reordering some things things like that to make it a lot more readable so there's still going to be a handful of for requests coming but then after that I expect much more stability from the spec side as always communicate on Twitter hit us up here

any questions thank you everyone for coming thank you [Music] [Music]

[Music] [Music]

[Music]