All Core Devs - Consensus #1
All Core Devs - Consensus · 16 Aug 2018 · 1:10:31
Eth2 client teams and researchers share updates, then discuss the wire protocol, message serialization, bootstrapping the initial validator set, a sharding meetup ahead of Devcon, the shuffling algorithm and testing.
Speakers
Topics
From All Core Devs - Consensus, hosted by Ethereum Foundation.
Transcript
[Music] [Music]
[Music] [Music] [Music]
[Music] [Music]
[Music] you
okay realize okay thanks okay thank you everyone for coming to the yes the first of all is the zeroth cause this is the first all and it's been rebranded this d2o implementers coal because it's going it encompasses a lot more than just sharding i guess some people with data a change it to Jasper although I haven't fully adopted that term Malik Castagna well so I'll have the agenda is there anyone new here that once an intro Zak is here from quick box he's been doing some network simulation
stuff but we can talk about that later I think everyone else was here last time okay I am so happy to be this meeting great and Alex lucky you were here it wasn't yes and I wasn't in the first meeting I was traveling but yes hello I but I was at the the workshop in Berlin the one in the June June yes yes oh great we can go ahead and get started and the first part of the agenda is client updates and if we want to just go around and give it a
seat on what's been going on on our various plant okay so you're gonna do one if you ask some wasn't I can start I've been working on the beacon chain something tides on kind of a concept implantation the past couple days I finished the IV to one spec and at the same time have been working with metallic editing the spec as we found various bugs and little issues and showers and doing review on that there's a couple of minor things that have been added spec that are not represented in this PR now but the PR is generally up to
and we're going to get that emerges probably the next day or so someone from prophetic labs kind of give an update update we have deprecated the old shorty management contract within our client base so we have implemented a beacon node to our PC server as a service alongside with gr PC client for the sharding client and beacon no sufficient so the shutting client in the big and old our communicate effectively we have updated our proposal package in within a shouting client to basically to be able
integral with AB attention via the the RPC method basically on the proposal can be shuffled and determine which hide that that it him propose and then we also have bigger know simulating plots and HIPAA transition and then the shutting client can be sent to them and then Shannon client used this to your PC may 30 2009 can become a tester so then we after that we basically verified that Abella data's can be selected can be successfully so that did to propose for the net start using history opposition we also work on aligning our code base
with the 2.1 spec so we basically updated that blog and then a tip stayed and then the and then the crystallized a field we're using the latest shuffling and in the cutoff algorithm and then the helper functions we also open up a discourse server which is a which is a bridge with the collection room so feel free to join us there and think is not a hub and have in consumption forward we plan to work on for choice to - great sounds like excellent progress how about someone from lighthouse
so we spent mostly I'm all sort of playing around with a shuffling algorithm that later a little sandbox to sort of mess around with with different shuffling algorithms and say how they compared speed and output just being kind of building out so the ancillary stuff like databases and threading models and stuff like that sort of waiting for the reference implementation to get a little this day transition stuff this must have it remind we can talk about shuffling stuff later I imagine yeah with table all the shuffling stuff until after that updates but happy to begin great things
how about is anyone from parity here I don't how about harmony we are working on proposers and processing stuff somewhere in between the middle and the end of the progress morning if things will go yes they are going now than we it's muted so you guys don't have to be silent it's fine I mean I might be speaking at all so it's gonna me to the hosts alike at the end of the next week we are trying to follow this back in those points that are well defined by this bit and try to keep it simple for
those like for example for initial validators committee we decided to us to just use the first register rate validator as a committee that's a visible tool to make first bunch of box yep so that's it for now great then I saw one from Pegasus wanna give up - yeah I'll give you the
practical update which is in terms of team building and stuff we've made good progress so Olivier join us a couple weeks oh he was almost old pretty much his best days he's been working this is the PDF web job to go just in the lancet anyways and we've got two more coming on board in the next bar so we'll finally be able to thanks for subscribing we don't want illusions across it so it's our heads gonna Nicola all these next two weeks especially was published two weeks ago
after get being able to start a very climate issue when the team will be there in September of the next two weeks that's our plan that's about remember that would be nice so missus realization to try to add a model it's super sterilized and see how to implement that
in everything eh Research Forum basically used with the message is a bit too heavy I think and also I focused on the BLS implementation I continued using a Milagro library and it still we still have some okay but I've also put a long forum post with all kind of tips and thing you must be aware of when you implement BLS through Milagro or any other library
otherwise it's not 2.0 but more its to 1.0 so we had some PR on meme and Nimbus and also we can now sync with proof of fraud blockchain at least the first early blocks so progress but on its went on oh can you share that sorry is a blog post about the discrimination any any update from you often hey Danny yeah
quick update from our side so obviously no sort of farting related progress at the moment we're mostly working on tooling for developing and deploying smart contracts in two stacks which is rust in assembly script primarily rust we're also working on adding support for multiple VMs into Hera which is our sort of sandwich layer that connects to CPP aetherium and death as well and when that work is done we can begin working on an execution engine prototype for sharding phase two or whatever phase that is now great and I think I forgot the website annotations so we've been working on the JavaScript
implementation of the beacon chain so right now we're working on implementing the state register functions and we've been directed by mummy on a pure jazz implementation of bilis signatures are you've been looking at um we're most likely going to go with that and then your future even though it's not really one to one with the iPhone implementation but it's a really good start within the next two weeks we're also gonna start complimenting gossips up in JavaScript I'm just up to PGP layer and we've also started doing our own R&D research to help along with the ministers that metallic and just have
been worked on and I'm choosing committee sets and proposes great any updates from research from The Shining pgoz site we already had basic functionalities available so we can better note join the joint yet live and broadcast messages and received
something in those but the debauch the vision it's not finished yet so we'll keep working on it and we also had darker image available and we work on open Tracy - um we serve a home tracing and used app - as tracer and collector and we met some problems so there are some issues about the GS of it is in this package management management
tool for our DFS and on some issues related to the p3m we recorded in get it fixed and we also has more documents so we there there's currently they are currently summary readme file and the document in the PR and will be merged soon and currently we're doing the refactoring and restructuring because the previous code is not so merger so we'll make it more readable and yeah and and understandable yeah and more
debugging because there are still some issues not sure if it is on the PDP side but we'll we will find it out and to do in the next two weeks well focus more on communicate our current code with the python site so because um we want a workable program that can communicate with the final sites so that we can do some experiment in the Python side and we will also serve a more about the deployment tools
and testing tools and that's my update excellent I'm getting some bunch of typing sounds if you're not speaking can you please mute actually so I carved out ppvt research into a part of the agenda that I think it makes sense right here Yannick do you want to give us an update on your network simulation yes sure thank you maybe a little bit of background my goal here is to compare different gossip and discovery protocols and see how they perform and if they're suitable is fast and also maybe what requirements they have on the nodes in the network regarding latency and
throughput for example so that eventually we can choose the best one from all the opportunities we have and to do that I'm using a framework called domme net it's a C++ framework for discrete event simulation so there's actually no real networking going on everything is running on a simulated on a single machine which of course has the disadvantage that it's a little bit less realistic but therefore but what you get for that is that you can basically scale as much as you like you can add as many notes as you like and you pay for that only by simulation time and I've done some performance tests that was the first thing I did and it's it seems to be possible to run simulation with up to
100 thousand nodes which is very nice because I think that's roughly the size that we are trying on roughy the number of validated you're trying to support yeah and I got some first results and first I looked into a piss-up which is basically the proposed successor of gossip table and proposed by the lip Adobe team it's still only specified there's no implementation yet so implemented in in my simulation and what I looked at is and the number of nodes of hops it takes for a message to propagate through the network or to reach more than 9% of the network and unfortunately the result I got was a bit negative and the numbers quite large it
takes something between 20 and 40 hops to reach to propagate for the network for network sizes of 5,000 to 20,000 nodes and I think that number is yet too large to to support the short work times we want to have and therefore I just think we should not use this office ft sub at least not in its current state in the spec they mentioned that they have some optimizations in mind but they're not there yet so when they do we have to of course revisit that but for now I think it's not not a good idea yeah oh it's taking why it's taking that many hops or do you have any theories yes I
think that's just the idea beyond the protocol that you I mean it's not a bad protocol it's just it makes it trader which is not suitable for us and the idea is to basically trade efficiency for propagation time so it takes while it takes a lot of hops it takes very few messages see okay la la la a fewer redundant messages being passed around yes exactly and I was named epi sub epi sub units used to be called gossips up attacked the same name as the old protocol but where they renamed it to a visa yeah then no after that I'm right now looking to gossip something and yeah try to look at the
same metrics and see what I get there yeah that's my update thank you awesome so I want to introduce Zack from white box Zack Zack and I have been talking for a number of months he was actually going to begin to do some network simulation work on the FFG contract side of things he's been a year to help out I know he's been spending some time getting to play with the research this week and I wanted to let him just kind of give an idea of what he's interested in doing so that we can reach out a little bit now or maybe offline y'all can give him a hand quote so that yeah hey how's it going yeah I
think it's important to also clarify that unlike e annex work we're actually capable of emulating Network behaviors and activities so we can like functionally replicate that activity in a in like real-time with like accuracy so you can realistically observe performance so we spent the past week going through the code in the in the charting PGP POC repo and we made some changes and made some pull requests and I opened an issue number 43 for testing methodology that kind of provides like a high-level overview of what we're
capable of doing what I think would be the most relevant to this particular use so I just wanted to put something out there so I could get the ball rolling because I think like the methodology and test cases should be established using you know community input and not just like dictated by me and what I think is best so I want to be the the most useful so we got everything running and it works and then we also fixed the dev build the dev build wasn't working there were some issues that we addressed and we also got it running on Mac it wasn't able to run on you know OS X environment
but uh we we fixed that so yeah give a couple examples of some of the metrics you might be able to test yeah yeah so I listed them all out on this thing so like the ability primarily the ability to like observe the the abilities are like validators to subscribe to new topics and send and receive messages pertaining to that topic and like the allotted amount of time so some things that we would do is like number of nodes latency between those nodes what's the maximum amount of network latency that each individual node can tolerate before performance begins to degrade and what are the security implications of that
like latency between shards intermittent blackout conditions it's like high degrees to packet loss or dand with the constraints adding and removing nodes at random and adding and removing them at set intervals introducing a high volume of nodes simultaneously we could also like test observe like partition tolerance like when segments of nodes are prevented from communicating with each other and just also performance like sending and receiving messages but in the set period of times and repeat so we could essentially stress test it and also the process of like joining and leaving shards like subscribing and
connecting to other nodes with the bird and synchronizing collations and shard preference tables and unsubscribing so pretty much all of those practical functions we can test at scale and test them realistically because they would fully be performing so we do it in our network we actually observed them perform in real time real life so we're not really using simulations which are like mathematical assumptions we're like functionally observing these these these behaviors and these performances so I think that's about it right there but if you guys want to check out this testing methodology that I posted I mean it's just a high-level document to just communicate what we've
done so far we've only been actually working on this for like the past week or so but I'm assigning a couple guys from my team to help out on this so feel free to give us whatever you got and well we can run all of these tests and so since it'll be run locally in our lab we could also provide access to the tests network to any of you guys if you want to access it via like SSH or something like that we'll set you up with an account so you can come in and run your own tests if you want oh my god Emily will will be willing to donate that to the cost so it's just all you know what you guys would think it is
best and if you want to see like a demo or like check it out or something like that or have any other questions we could just talk about that off offline and once you have anything pressing right now great it sounds like really really interesting testing does anybody that's been working on testing researcher or otherwise have any questions for Zak right now okay maybe maybe not a question but more like a suggestion and it might make sense because now we have quite a few number of implementations already - yeah test the various implemented implementations together in the same
network would that be possible yeah yeah anyone if you'd like to collaborate because I checked out your work as well and I think that we could actually implement a lot of the same flow but within an emulation rather than a simulation so you're talking like earlier you mentioned like how it's not entirely realistic because you know it's a simulation well now we can implement that same workflow with it and actually it within an actual emulation so that way we'll see an observe performance with high accuracy that's very similar to what it would how it would be in the real world so yeah so yeah I'm not talking about my my simulations but
rather like and the way I understand is that you take like an existing client implementations and just put it in the network and let it run a hundred times or something yeah whatever you want to configure it for so we can get functionality is like you know chef or something like that we can like established automated workflow but for now you only use the networking PLC yeah yeah but maybe it would be nice to try different implementations for example I don't know okay yeah yeah I mean let's do whatever we can you know whatever you guys want to throw at it you know and
well we could set up a network that premier network that and you one can access if you guys want to run like some of your own tests this scale definitely came for that once where I'm able to sync with other nodes yeah yeah yeah yeah and once once we have so this is this can be useful for the kind of proof of concept stuff but this might also be when we actually have a number we can chain client we can do other types of simulations on actual clients rather than just these kind of proof of concept testing definitely cool okay I skipped over a little bit of research
the research updates because we go into the p2p stuff Vitalik do you have anything that you'd like it on the research side not that much well most so far it's been mostly refinements to the spec so I think see on the main changes that we've been that have happens to this back in the last couple of weeks pretty much have I think been made fairly small modifications right like the fortune roll is basically the same and I've been looking into your
some kind of Lewis crime were speculative things around like 51 percent mitigation and data availability checked in for sharding but that's not really relevant to and in very short term clients an element all right but like you probably will become relevant in me at some point when we start actually building at the sharding side and building the short charting laid claim code so it's not weird it'll be in the very first version of it got it and I know on the rng vdf side of things justin is still he's waiting on kind of a detailed hardware analysis like
real-world analysis of hardware and potential attacks and that's going to be have that report we're going to be able to make more clear decisions on the rng design hopefully probably the next three or four weeks we'll have that report oh cool research so back to the p2p stuff Paul had mentioned that you want to talk about the D containing wire protocol apology you want to give a high level on that yeah yeah sure I just been assigned to play around pushing it around the network um and I guess maybe it might be interesting to hear from prismatic labs what they're doing I mean I guess the easiest thing to be would just be kind of like copy that they eat 1.0 by a part
of them now but um I just kind of wanted to raise it because it's you know having that thing specify this is something of my hair I do our prismatic one of maybe mention what they're doing in that own that way hey Preston here from prismatic so what we're doing right now is for just where we were until week and a figure out what messaging format we want to use for just using protocol buffers because as long as it's a single client implementation and we trust the packets from ourself like it's gonna work so you know we are aligned on the same I do know we need to like figure out what the performance
gonna be but right now we're just using protocol buffers okay cool thanks yeah don't you have like different types of messages you know like blocks get blocks but you know like the one little bite to have specific types of messages yeah so we've defined specific messages for I guess each topic so all of our communication is going through like gossip sub or flood subtopics and so each topic has its own message type that's associated with it so if you doing like a like asking for a block
then you're sitting like requests and getting a different message back which is a you know give block response or just a block yeah okay cool I'll just go poking around in yours and try to follow your lead Thanks yep as for the East 100 our protocol is are there issues with that wire protocol is is that can it conform to what we need does anybody have a familiarity with the ephoto wire protocol to speak to it basically we were thinking about the same way as Paul just mentioned and from from now I don't see any issues in using
each one Oh protocol or we can chain data structures so it's gonna be pretty straightforward I guess we'll have to change some stuff because the the common wire protocol talks about difficulty in these things that aren't gonna be suitable to this chain yeah sure but it's I think it's gone when we start talking about why though in the wire protocol it might also make sense to start thinking about denial of service resistance because like that's one thing that proof-of-work does fear early easily and we should probably try to think about it like
whether or not or look how we would do that for the state for Au state protocol would there be things that want to modify and so forth and they're now service out there isn't easy so unity is arachidonic on the prawn wave program work because no ml of service attacks consisting of extending proof of stake blocks that are male formatted in some way they're just wastes that's argit's time I see I'm look slightly worried about this because we have these big hulking BLS signatures that all take well oh you know I guess it's not that bad if there are sizes bounded but once their size goes up to like a few hundred
each I guess it's still doable but I can still worth having in the back of our minds so I was talking to some of the Definity people as you can and they're doing some they're using zero knowledge proof to prove that you're a part of the validator set does the network but without that without really revealing who or what your actual identity is and this is to allow for some sort of like privilege network so like I can privilege listening and receiving we're listening and and listening to and forwarding packets or messages from known validators or from people that
have proved that they're validators would that extorter solution fit the bill of resisting the denial service stuff well I think if you if this proof could be replicated somehow then it sort of defeats the purpose I think like if you if you produce the proof once and you can use it multiple times yeah I think the idea would be that you would kind of weave the proof in with whatever set of messages that you're making which see put sort of something I should be able to do with a make this standard scheme
say yes I mean problem without those they overhead yeah I think they're very using proposed bullet group so we know I think so here you can you can amortize it right so you can have a scheme that basically is says when you make a proof you Kimya inside of that through actually known well if you wants to do this right when you make a proof like inside of that proof you when I came it's no more coal route and then for any message you would review lemarchal branch and that way you can make each proof counts for um messages but you don't necessarily need to do that because like what you do is the point of the proof is to basically prove that
some particular public key like some newly generated special-purpose public key is owned by the same entity that also owns one of the bit was some unknown one of yeah big a validated public use and then that's better you can trust messages from that special for was public you once you verified the proof once where is she interesting well would it be enough to do this part connection in the bridge bear lair I would say probably yeah I think it's definitely an
interesting enough solution to examine over the next over the coming weeks I'm going to I'll dig into it a little bit you probably want to keep the separate like you'll you'll validate the key and the key that using two sine beta P messages because they might be like in different processes oh sorry I just kind of figured out after I said I was just saying you'd want to keep your your main validating teeth pretty far away from your p2p message signing key but I think we're just talking about like you know creating some signatures or something so just discard that
see comments on wire protocol or sauce issues around 50 messages I guess just to sum up maybe I'll just start poking through a prismatic lab staff and then I'll also try and use the existing wiper ball and I'll do my best to document its witness time to start from excellent okay so we have the message serialization and there's been at least a mild amount of chatter about that with our last call does anybody want to discuss that I have not been keeping up with it so I
am not the person to give an update on that I guess I can say something um I've been looking into a little bit I keep meaning to run like some some comparisons between different serialization formats and how long they take and the message size and the network and stuff like that but I haven't got around to it the flames were though but I'm kind of liking the idea of these I like infinitely times faster algorithms where it's like you can basically go straight from the network into your database without encoding and decoding it seems it seems appealing but it has to go kind of check into those and I'm kind of I'm in favor about SSA personally for simple serialize form
consensus layer stuff because I think it's just really simple when you say ESS Zed like I think I accidentally made two versions that I both called simple so you realize where one is basically a very simplified version of our Opia where the lengths we fix as always to be bytes and the other is the thing where things that are constant size like this or make everything is typed and things that are constant size map to a constant byte position so which one of the two were you talking about yeah I was talking about yeah so I do mind meeting in here but I do mind
reading on your cut thanks to just fit echo yeah I noticed I think the f3 search one in the eighth research could get help the older one I that's the one with the new one because I figured that was no yeah let me sense I've got it in Ross doing encoding but I haven't done decoding yet cool okay well we can continue to think about message serialization it's not super immediately pressing but something we should come to agreement on over the next few meetings um okay cool so we I think we've discussed
everything through for has anyone given any thought to bootstrapping the initial validator set and not something we need to immediately come to consensus on today but it's something that we need to figure out and at some point so the idea is how do we have our initial validator set in I guess our Genesis block and the beacon chain there's kind of a chicken-egg problem because especially because we were discussing having the beacon chain validating all of the incoming data from the validators so like dating their existence is a signature the
what's it called the DLS road key attack stuff but if you don't have an initial valid or set to validate these incoming messages you don't just issues there I know a number of chains are kind of dealing with this problem or at least from like a first from a jet that necessarily porting from an existing chain but they're they do have to deal with the Genesis a lot of problems are probably interesting to work to look at what other people are doing but does anybody have any immediate thoughts on this issue right now a prismatic lab we just initialize a bunch of validators upon
the creation of the new chain but we're discussing on this core about having like a comfy JSON file to to go from right so that would in practice that would involve some sort of enshrined initial I'll intercept yeah do what they fear him did in the beginning to use some sort of test net to seed well if cerium did not use the test net to seed
the Genesis board right well the way etherium seeded the Genesis blog is that basically there was a Python scripts that anyone could run which would scan the Bitcoin blockchain and check who participated in the sale and automatically assign them eath so I mean if that's what we want to do that's Pro actually a totally fine approach as well right so the idea was here about how I can remember how I came yeah so the idea would be to have the register registration contract that would broadcast the data via receipts and have that open person and component yeah basically like it's exactly the same
like or it's like purely isomorphic to a league and a Bitcoin to etherium a process mm-hmm okay so it would be you'd have a start and end date in which people can initially register they need then you don't necessarily need to have an end date because you could say that like oh when we enable the feature the the feature for a validator rotation than everyone asked for the end data will get included as well or something yes I see cool do you imagine in the launch process to have a six validator set for some amount of time for flipping a bit I don't know I feel like that depends on like how fast
development goes you know on the different sides okay yeah I think that's a tentatively reasonable approach and so in terms of development just think about the Genesis block is having an initial louder so cool okay so quickly we've been discussing it was just last time about having some sort of Def Con charting Meetup so I camera the exact date of Def Con but a day or two before that status was has a space for their hackathon there's
a potential that there might be some space there if anywhere for status has any thoughts on that at this moment you sure yeah so we've discussed it internally and given the hackathon and other things happening at the venue the best date for us would be Friday the 26th which places us a couple of days before the DEF CON event it's out I'm also wanted to check with the group how much time we would need this is a day half they more or less anybody have any thoughts on how long we
I guess we've in the past I guess in Berlin we had three days of client stuff one day of sharding stuff we got a lot done although the client day is also had sharding related thing and we're also going to be a Def Con for many days and if you're there other 26 you'll probably be there for a few days before Def Con I I would lean towards a day and not do multiple days on this thing to anybody but it would a you know a good long day of gathering does anybody have any thoughts on that you
thinkin yep yeah the meetup is is it more just communication of knowledge is it a chance for people to ask the research team questions to be helpful to understand that before trying to forget how much time we might need yeah you're right I imagine kind of a long-form version of this in which we can dig deeper into some of the some of the things that may be in the meetings really okay this is what's going on but we haven't really like thought about all the way through this is really a good time to catch everyone up meet everyone and kind of facilitate collaboration on some of the things that we have been meaning to dig deeper into
into some things that maybe we've been talking about on internet but we haven't come to full agreement on so you know updates some sort of like research QA and then maybe a few things that we specifically want to spend some time digging deep into to get progress on that's just off the top of my head what I think would be useful anybody have other comments on that would it be in the format of the previous Meetup where everybody went through their client updates and there is a research update and was filmed and there were notes afterwards or is it more just amongst us and then we're posting notes at the end
of it in terms of like sharing a stream yes we could stream it I don't know but if we have the resources to do so I don't see why not at least recorded but definitely notes after can people realistically get to Prague a few days before Def Con this Def Con start the 29th anybody have the date on that offhand it's the 30th through to the second right right so that's a reason that's like you know are people going to be in
Europe or people going to be in Prague that much earlier than Def Con okay so there would be people in Europe and close to Prague so that's promising I think yeah that's I'm just kind of perfect for us because it's like a dead zone between web 3 and DEF CON well I'm sure we could fill it with fear but yeah good to be productive yeah there's all sort of fellowship of a theory magicians need up happening I think around new 2627 maybe I don't have the latest dates
on that but that's going on as well okay well I think one day is reasonable and I think the 26th is probably reasonable for at least a good representation why don't we yeah I think we can kind of take that offline and check on some of the other events and see if this will start to make sense for us okay and if there is faith in the venue yeah we should be able to get space for well at least a limited amount of people like not hundreds but something along the lines of Berlin should be fine great
okay figure that out a little bit more uh they're coming I think some amount of knowledge sharing might be interesting that people present what they've been researching as well I would at least be interested in having a short section on that but compared to Berlin I agree most here that that more focus on discussion and solving issues would be interesting as well cool okay so we're at that part of the meeting where anyone can talk about
anything that wasn't on the agenda that is pressing or interesting or questions or whatever yeah I might might just bring up the the shuffling um algorithm I was playing around with that I totally totally forgot about them yeah I made an issue it's it's number 57 it's just about like there's a modular bias in that and it's doing an extra iteration so if you get a chance to have a look at that it'd be good to know that's right what repo sorry bacon chain I made a little lay on out github there's a link
in that in that issue - like a little sandbox I made just to like that I was using when I was cheating around with shuffling algorithm so if anybody that likes it yep so anybody fancy is playing around with shuffling and that's the place for it yes it'll be cool just to get you get some feedback on that you probably look at it right now yeah you probably want to skip down to the bottom of italic most of the top is just on like introduction that you already know you
yo hold on doesn't my here could already do the fill the the filtering the for module bias that you talked about yeah that's how I came across it but it does it filters for that like the odd result it's based on the entire list size it doesn't filter the map based on the remaining amount because that that's good or hold on oh no I think I figure it out it what's a it's a typo it's not supposed to be if all I know is does less than random acts it's supposed to be if M is less than R and Maps there that that's it it was a typo oh yeah oh I think the ran max needs to be dropped
down inside the loop too oh why no one with the static uh uh uh yeah let me check yeah no no I ran max changes based on the remaining not not it doesn't just a static sedan this size I believe oh yes you're right you're right you're right yes and modern you're very right there there again or actually no that's technically the wrong code did
you just updated somewhere in there yeah by a stratum it's you point once back oh cool I made her like a reference implementation in in that shuffling Reaper that is slower but it kind of like separates the RNG and a shuffle are adding two separate components to make gives me to understand and and I got those two matching so I think it's right thing you know I've been wrong before yeah also ultimately we'll just have like special-purpose guests for the listener will make sure it matches up yeah cool and for the other implementers to the a little shuffling sandbox thing I have it'll output reference it'll
output a shuffled array given a seed and in the readme there's a couple of them so you can use that like to test like if you want to just put a test in there with your array burst that won't see if it matches and that's that's an easy way to do it to save you like pulling apart the be contrarian implementation you know one thing I wanted to ask about is and have we talked about the testing at all in the census testing the DG chain we have not brought briefly last time but there's a little too early well and I feel like since we have two
implementations that are basic we're running a full vegan chain we can pin it it probably is too early to keep expecting consensus but there's two proposed add testing Lang spec that idea had made a few days ago and I thought I'd bring this up and see I guess that thing but basically the idea is I'm Sierra let's see if I can imma throw it into the chat no not not that sorry wait what is it oh you know that and that's what it is the idea is it's basically a way that all that would allow us to write tests much more quickly and have clients automatically validate them we actually started building out yeah
beginning on our platform yesterday I could share those results with you guys once we get it up and running if you want us help tackle the testing inspect sure I guess like the thing I'm asking right now is for people to look at that dog and see if that's an approach that makes sense and if it is then like you know make sense to start like that little part of the implementation should be an implementation of interpreting the test the tests and running them yeah so the things that are just shared is a testing Lang where we can specify you know the creation of blocks the attestation of blocks and things and
kind of check on the pork chow and very high level component we have a client we can use this as a referent of rotation file allows the creek final the automate a lot of the workflow cool so homework take a look at that testing thing and see if it makes sense and if it's an expressive at least enough to start and expressing the different states of the contain that's something that we'll be implementing in
the Python like for the next week or so should we just share your results in the repo share what result like our evaluation yeah you can you can I'll make a I'll make an issue about this testing lang and the be container ago and people can complement on that or we can also talk in the sharding I get her guys I have an idea on initial water they'd or said Wow we can take a word blog and get all whether there are the daters that were
registered before that block and then I use a hash of that block as a seed or shuffling process and finally get the initial whether they'd ever said like and we can just put this Bach hash into Genesis or we can change that should be okay it's just too raw idea hello can you mute okay so the idea is to have the validator set before some block
cash and then at that final block cash use that as a use that black cash at the feed of the initial shuffling yeah so we can see the initials that said with the just some a hash of some proof of work chain block so that's the idea at them creature type yeah and we can choose that block randomly yeah I think that's probably reasonable approach to see their internist
rather than using you know zero surely you could just throw random commitments when you register in the registration contract or whatever that is instead if we go with that approach then yes you could do the XOR of all the random commitment which might would require a little less coordination on grabbing a specific block both opposing agree reasonable I just ran doubt was very likely but there's you know there's the RNG still a little bit up near
you okay anything else any other thoughts comments questions concerns you great okay next meeting so are we I wasn't the last chord alcohol is their Accord I'll call one week from tomorrow everybody know they didn't they should offer great then let's plan on doing another one of these one week from today I will
create an issue did everyone see the new east to OPM repo where this is all all belong I share the blank a couple times in the gutter so it'll exist there I am trying to take me a couple days to get these notes up but I'll get the notes up shared with all the links and we can I'll put up a tentative agenda and we can rally around an agenda for cheeks you know until then plenty of work going on in various cuter channels and repos exciting stuff thanks everyone for coming I'll talk to Elif in understanding it was two weeks from now is that right
sorry that's the current plan is to meet two weeks from today thank you [Music] [Music]