All Core Devs - Consensus #2

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music] [Music]

[Music] okay I went live I'm going to ask the troll Bach

they can hear me hey people in the chat can you hear me No give me one second good as the video just switched over to the grid okay cool maybe it's just uh delayed how's the phone in I think they can hear you yeah they can hear you great and y'all can hear everyone else on the call

to write chat people all right um let's get started everyone has a Chindi let me pull it up okay cool so we'll do things normal to things your client updates and research updates and then get into the stuff for this week who wants to start on client updates how about harmony previous two weeks we've been working on block processing and block proposer we have a solo node so far so means that it's able to

propose blocks and process that them everything is stored on disk so the state is preserved between restarts but for now it has it has a placeholders for state transition and for for choice rule yep and the next steps we are going to work on it's our state transition and attestation so what I am personally doing now is trying to understand the state transition and the things that happens around it because I'm not fond of the design of state that is suggested

in a POC and maybe next week I'll try to outline something and so we can discuss it for example I think that it's pretty straightforward to use a miracle tree for to store validator set and so forth but to make this outline and it some time to understand everything that is happening around stage musician so that's where we are okay thank you connect Danny we can go next step pragmatic labs so we we

basically finished a bunch of the different PRS that were aligning our repo with the latest P point one spec finish all the processing at the station system we created basically the entire infrastructure for applying the for choice rule and updating the head so we do we know we process incoming blocks you know we we store them and then we apply a for choice room and we basically keep an in-memory kind of cache of the of the latest process block of the unprocessed block caches and just go through them and update the head when we receive a new block at the moment were basically wrapping up initial chain sync so I'm getting you know two notes to actually you know one that advances the chain another one that starts from

scratch to get up to the same height or at least the same slot and then we are basically working right now on the whole proposer tester interactions to make sure that once the proposer is a sign of a slot it's able to receive at the stations via p2p from a testers and right now we know we're thinking about how we're gonna do that we're probably gonna have one big shard as the network and and essentially just get the proposal the proposal responsibility fully implemented that's basically cool and by one big shard you mean in terms of the p2p layer yeah yeah for the

further validators interacting with each other gotcha sorry guys a good question do you use the same state structure that is described in POC respect yes we are we try to we try to be as aligned with respect as we can oh okay okay cool thank you and I what American litter so an RN progress has been slow and steady I've been quite busy at work we're starting to implement a state-transition functions and trying to understand

everything around that also trying to get gossips of implementation started and I also have several questions regarding the random beacon implementations in community selection that we'll go into later but in terms of updates that's it Tara yes so we finished multi signature BLS implementation and now I've also implemented like 80% of the per block processing what is left is what is in to

do in the customer shop inspect and while waiting for his to do I started to implement ghost RPG no IMD protocol and so and I provided some feedback to the testing procedure Assad so that it's best for for us in the face Els minty signature now in NIM so if needed we can also export it as C library for example cool and curious are

you using like a common test infrastructure or test cases from the rest implementation so this is a kind of it's a bit tricky because we didn't find like sterilization tests vectors to compare to so hopefully we can agree on some I can show those notes on the implementation because so that everyone agrees on how to serialize right yeah as we have more implementations of this

curve I think we're gonna definitely do come around as standard so that's good okay thanks how about Texas yes outside you've been working on on body as you know we have hiring and with new people new people will be arriving next month as well and we started to look in details that test there including its last version and we're going to formalize always some likely would have some some questions or feedback next week or the week after and that's of course protec like hell yeah yeah we've been

working to kind of bootstrap the project and get the get some team resources aligned we've also been working on some research for PDP serialization we'll talk about later we've been eyeing out the state-transition stuff's pretty hard just trying to figure out you know what the motivations behind that and if it's efficient and next up I think the next thing for us is just to start pushing blocks around the network we're just going to pick a serialization format and just run with it for now that's it Russ cool thank you did I miss any of the client team I don't think so let's move towards research we can start with is there any update from the US on

team yeah if you can hear me so we have in the last last three weeks worked really hard on the test net we are trying to launch and that's going really well and then the next step is that we would like to it's kind of like a project between the u.s. and / - MJ's team I would like to in the next two months spend some time on do some kind of simulation of execution engine on charting where we take the the lower layers the black box hmm so the the book ordering anything coming in and that's just a given and we

are trying to do some kind of execution energy simulation on top of that which maybe he was it may be just EVM for the time being but that's like the next step cool sounds good any other another plenty of research updates and others work on PPP adjustments here with us as well as anybody want to give an update on follow on Friday in b2b EOC we last week we did a condom foundation with the editor in Kosice and also introduced the communication between I can go so the

contents can be sent from going to Python and they did and the result can be written back to the goal and also you can sing convinced from Python to go and they are down through G RPC and it can be changed in to the other mechanisms like ie on the pipe or other IPC in a Fisher and they also use another tracer traggert and added more tracing and our to do is in the next week and then in the next two weeks will be we will survey more about the connection

manager in consistent and we'll try to introduce the repetitions system and survey the simulator for kosice and that's our update thank you great thank you Yannick do you have anything from your side of the simulation not really just progress I'd say they're finished implementation of gossip sir and alright so off this push push pull protocol and which I described in III search poster couple of weeks ago

I think give packets a size so that I can measure propagation times and not only how constant yeah I hope we have some results in two weeks thanks to call export just phone anything on your crowd yes I've been yeah I've basically continued doing research on the video and the randomness pecan so I think last time I joined was actually a month ago and that was possibly before the vdf day in Stanford where we invited a bunch of DTF experts

generally I'd say this event went very well some new results were found during that day just by having different people in the room and and sharing open problems in particular we have a new way of aggregating the proofs of EDF for the the construction that we're looking into it called by Benjamin whistle on ski so you can take two vdf proofs with different inputs and aggregate them into single proofs that's it's very nice the other thing which was nice is there's a new way of doing water mocking and by water mocking I mean tagging you proof a specific public key so that you

can do incentivization and give a reward to a specific key another thing that happened during that event is that then when they told me and encouraged me to look into the idea of a ceremony to build the RSA modulus so in a similar way that Zeke has had this this trusted setup and ceremony where they have I think over a sequence and if you have at least 1,000 acts honestly then the whole thing is secure so I I will be looking into the the viability of this approach for for RSA and so the idea is you have

you know a few hundred participants and if at least one of them acts honestly the end result is a 2,000 bit RSA modulus for which no one knows the factorization and and it's important that no one knows this factorization so that the vdf scheme that were looking into is secure I guess another thing that happened during that day is that we had people from ipfs and and Chia come in it's looking like ipfs more and more wants to have a random beacon just like if areum for their blockchain and the they're looking at you know the the same

VDS that we are so it's looking more and more likely that that we will collaborate with them which is good because we want to build a vdf ASIC and those can be quite expensive if you if you use state-of-the-art process technologies so collaborating there means we can collaborate financially and also in terms of engineering resources one of the things that I guess one of the rabbit holds that that you know is we've gone down pretty far is an approach to build RSA modulite restlessly so the idea basically is that if you pick a 4,000 bit number let's say

at random and you make sure that it has no small prime factorizations otherwise you kind of you trash it and you you pick another random number four times on bit random number then with with some reasonably high probability something like 60 or 70% this this random number will be safe to use as an RSA modulus and and what I mean by safe to use is that there's a a 2,000 bit component of this of this random number which is on factorizable so is the product of at least two large enough crimes so they

cannot be factored and so if we pick enough of these random numbers then we're very high probability none of them will be completely factorizable and so long as they're not completely factorizable the the scheme is secure so that gives us a nice way of having a trustless set up for the to be DF the main sorry putting that in that case you have do you have to run multiple videos for one yes exactly so basically your your high-level PDF is made out of these mini PDFs which are run in parallel and for you know what you do is that you concatenate the outputs and you

concatenate the proofs and each proof must verify at the same time the the main downside here is that the you know your proof sizes and your outputs are are not optimal in terms of size so each the output and the proof per video output would be on the order of 50 kilobits so that's about eight kilobytes so you know that that is totally workable but it's slightly suboptimal and the other worry is that you know we need we need quite a few of

these of these moduli and you know on the order of ten or twenty and so if we were to build an ASIC we might have actually to build to have several Asics on the same board and that might start consuming lots of power which which not might not scale very well but you know this is still part of the feasibility study time that I'm doing right now right so it doesn't scale poorly in the sense that the whole world is gonna start running them and use tons and ones energy doesn't scale well in the sense that it's hard for you know a hobbyist or altruistic participant to just like get a set up and run right exactly so

right now we're looking if we want to build like a totally optimal 4,000 bit multiplier modular multiplier we're looking at roughly on the order of 10 watts so if you would have you know 10 of them or that that's 100 watts which you know is less than some graphics cards so it's it's definitely small amounts of power but my hope initially was that you know we could have this this vdf ASIC be you know run a ball on a on a USB stick that you can just plug into your computer but it's looking more like it would be like the graphics card that you'd plug into your desktop

computer if we want to get this this low advantage between between the hard way that we deliver and other world is what can be built with with unlimited amounts of money so the other piece of research that I've been doing is basically looking into the modular multiplication algorithms which is the basis for the the EDF that we're looking into and it it turns out that this is a pretty long and rich line of research you know it might seem innocuous but it's actually non-trivial to find the optimal parallel time algorithm and over the years

there's been various approaches you know Montgomery Barrett's antibodies use already sorry terms of residues but there's this one specific team in Australia essentially a research lab part of the engineering department one of the universities there are looking into so-called residue numbers system and that's that's kind of nice because the basic idea is that you can take your your 4,000 bit modulus and you can in a way break it down into many smaller moduli and it means that when you're doing the multiplication and the additions you don't have these these long carry chains which which makes

everything complicated so instead you work with with small a bit bit with multiplications and that's kind of nice so you know I'm at the early stage of of approaching this this research lab but they you know from the initial discussions I've had they seem quite keen to elaborate so that that's nice sorry so as you've dug into this vdf research are you becoming more or less confident in the approach it varies from did from day to day I'd say

I'd say in the last few days I've become more confident and you know I am also confident on instantiating a specific vdf you know the whistle or ski construction and finding a suitable setup which is I'm at restless or trusted or we could combine the very selects what was the the biggest point of uncertainty is basically the DD ASIC now what kind of a budget do we need and it is it actually possible to to build an ASIC which is close to optimal and

you know a big part of that question was can we use exotic processes that are different from CMOS silicon to insulate these eight-six so one that that's quite famous is called gallium arsenide which is a type of semiconductor with for which you can build these these high frequency transistors and then another one which is which is more available commercially and it is using one more it's called silicon germanium and for both of these it looks like even if you had unlimited amounts of money it would not work and part of the reason is that the the the complexity of the the ASIC

you know in terms of number of gates and would be so high that the your power budget would go through the roof and there's there's no way you can feed enough power to the ASIC so in the way that I mean it is good news that we can kind of rule out hopefully rule out these exotic processes so that we can focus on almost available mainstream which is the the CMOS silicon and so now we're looking into okay can we actually instituted on a CMOS silicon chip and it looks like the answer is yes but you know with with carefully looking into relative

considerations and diarrhoea considerations and power considerations and stuff like that and we're also looking into you know the various process technologies like 28 nanometer 20 nanometer 16 etc it looks like one of the the most state-of-the-art process technologies that we could shoot for is a 60 nano mixer by tsmc so that's that's one of the the processes we're looking into the other one that we're looking into is 28 nanometer by GlobalFoundries but yeah I think overall the it is it's too early to tell but I'd say there's a

high chance that the project can be done successfully I say maybe slightly more than 50% chance in terms of the the amount of money that will have to be spent it's still unclear but I think 10 million or 20 million or maybe 30 million is kind of the ballpark area and so this is why you know the collaborations are so important and in addition to IP address and Tia looking to do the same thing as us there's also a new project that I learned about called Solana and they have this proof of history and it's you know the whole thing is built around the vdf so I mean

they they don't have the kind of budget that ipfs and I if you're gonna have but at least they have the the will to to see it happen and and they seem to have a very good team of engineers behind it so potential collaboration there I think Paul and his team have done some work on some research into the p2p p2p serialization format the fall wants to give us an update yeah sure so we we ended up kind of benching of several serialization formats we looked

at captain proto flatbuffers message pack protobuf simple serialized by metallic and also applies in pickle just because it was easy we ended up getting sizes for all of these to compare you know what they're kind of on wire size is we started on Tommy we didn't get anything but we did come a lot closer to a conclusion so in terms of looking at the like on wire size of an attestation record and a block between all of these these um formats I think it's simple serialized pretty much wins hands down always except for the pickle which is like crazy small but you know no one really wants to use pickle which PDP

minutes think so see a simple serialize is always as smallest I guess that's really not surprising because it gets to make all these assumptions about schema so we've been thinking about like what benefits you might actually get from from from using like captain proto or something one of the things that we keep coming back to is that you're probably gonna want to hatch you're gonna want to hash like if you get a message off the network you're obably gonna want to hash it pretty quickly at least whatever you do you're gonna hash it so we're talking before about that you know this two different serialization formats one is some for the consensus style stuff's you know when you hash it it always needs to

be you know the same the same order of bytes but if you're looking around the network it doesn't have to be so what kind of thinking that if you have this different byte ordering on the network and then you have to get it then you have to move it into the hashing format and then hash it you've probably lost any benefits you got from having that other p2p type so given that given that the requirements we have for writing our own serializer it's pretty small like we only really have to push like a handful of objects around the network at this time just boxing attestation records I believe and also that even if we do find like another third-party package that does to deterministic serialization that if they do happen to update in the

future it's just going to be a real pain in the ass because choosing French you're gonna have to like have clients handle that you know it's like you pull something out of your database and then serialize into the new format and push it out give it to someone they're gonna have to like know these two different formats or just thinking it's kind of kind of difficult so from our perspective we'd say stick with something like simple serialized we're gonna just play around with it for the next couple weeks see if we can make it faster otherwise them I think we'd probably go with that be keen to hear anyone's thoughts Paul a quick question did you compare it to our LP I know we

didn't compare to our play that's that's a good one and there's a simple she realized in the current Python repo yeah yeah that's right no not the one in the S research repo yeah um I mean I'm that sounds like reasonable arguments for me to move in the direction it's simple so you realize does anybody have any thoughts on it right now I'm going take it offline cool no thoughts right now thanks for

the work no they can do a little bit of lime all right the next thing on the agenda is the beacon chain testing lang we've gone back and forth a little bit on a prismatic issue talking about some of the pros and cons of this format proposed by AB italic versus a more structured kind of like JSON desk format or protobuf format I think that I last looked before we on this call metallic was of the mind that the easily writable although may be more difficult

to read format is beneficial to him and maybe to some others that may be writing these tests but the compromise might be just to have a parser that turns that into JSON or some other format I guess I lean in that direction the JSON tests are easily readable and thus more easily audible by the people who didn't write it I know Preston had some thoughts on this and press tonight we can talk about some of that plot stuff right now or offline but we can talk about the format first yeah you know I sort of agree with what you just said

this language proposes you know at first had quite bizarre it's kind of like you really need to think about it to just try to parse it in your mind like what is actually going on here and it just makes think when I first saw this I thought you know is this what we're going to be ingesting you know you can use you know photographer puzzle to create the test data like it how we drive the data doesn't matter you could have maybe you could have a GUI or you could use this thing ographers whatever if you know if we go with like a JSON sort of standard we're like we don't

need to build a language specific parser for this data then you know it kind of makes things a lot easier a lot of the back and forth I think was you know in our discussion is maybe a misunderstanding like what we're actually testing from the initial example we had like some like scenario of what the blockchain looks like and what the different Forks look like and then we wanted to decide like what the final head would be like given all this data so I was a little bit confused why we needed references to other slots and things like that they

just didn't understandable why some of that functionality is there so maybe if you want to if somebody can give it like a high level of what are the goals of this test and you know what are we hoping to achieve yes I mean the goals are what is the head what is the most recent justified block and what is the most recent finalized block at its core this is you know this is a fork choice and finality test that brings in the particular construction of beacon chain along with this epic list Kaspar so important to note and why this notion of slot sir is important is because when I when I make an attestation for a block at some slot I'm making I'm casting an

FFG vote on that block and any of its ancestor blocks that are in the previous cycle length slot and so you can have these you can have gaps and slots where there might not be a block for a given slot in a chain and so you have to have this notion of slots being skipped to really capture the full breadth of what can happen in these fork choices because I might I might cat I might make an attestation of a block at height at slot in and it might only cast votes for five blocks because there might be so many empty slots so that combined with these I know we've talked a little bit about whether R and G has really any any

use here and I don't think it does it really it's more a matter of we're dividing we divide validators into certain slots and so when I say validators zero through nine that's a test to slot and I'm not saying validators in this test I'm not saying validator is zero through nine from the global set I'm saying the validators that the subset of validators that can attest to that slot and so for the test writer they don't have to think about is that validator with the index 10 through 11 or 10 through 19 or is it the validators with index 20 through 29 they just think about you know starting the indexing at that subset of alders which is a committee for that slot so that's

kind of the general motivations we can we can talk a little bit more about that offline I'm I'm definitely in the direction of we have this we can easily we have this easily writable format we'll just we can make a Python script to the outputs in JSON and we as a community can come around a JSON standard selected and how do we keep that consistent across right so in

because because in this testing link at least currently there is no notion of these are all equally weighted validators it doesn't really matter so you can have your shuffling as being non shuffled so you know you just slice your validator set and apply them to your slots accordingly you know the zero flight goes to zero o'clock a slice it slice it by the stick by the cycle length with whatever shuffling you choose shuffling likely will reset on these dynasty changes but we don't have that currently expect and that even if you reshuffled still the shuffling doesn't really

matter in the conduct of this test because you know you think it would be a problem if the like the scenarios would be different either like on each test run or for each client if they're not selecting the same global indexes um well it was in the it does it will not matter as long as those validators have the same weight it matters that you keep them where you put them right so if somebody you're not you're not reshuffling them in between you know blocks or slots but because these are all equally validators you just need to

know that you know whatever the zero validator means locally that the zeroth validator voted from the global set so you still in it you need it when you're summing up votes you do have to keep think about the global validators but you don't care who they are as long as you're not moving them around that makes them a lot of this is simplified by the fact that everyone's equal weight now one thing regarding testing language currently there are two issues one in as Efrain become train repo and one in the

prismatic lab repos just to make sure should the discussion go into the promised ik prismatic lab repo because in the last two responses by a Vitalik and person welfare and second thing the only issue I have with JSON is that it doesn't support comments and I think it's important for research and two or two comments in or out quickly tests that test in lung support comments off of possible text formats I think over to ml or yeah ml are also good and they are

very wide the language supports yeah yes sir I I agree and we that comments are very worthwhile so Gamal or Monday's others probably makes more sense Makai

oh I just wanted to say that Danny just mentioned that it would be convenient to write maybe a Python script or just to read that language and so we can add now put in any formats like JSON llamo maybe some something else right but I think we want to we want to come up with a standard because it sooner or later we're gonna have a shared test suite and so we want to have a standard format that we're all comfortable reading from [Music] okay I see but I don't see any problems

with the heaven to form it's like but anyway it doesn't matter yeah mellow JSON is for me okay I mean in terms of where the conversation I I think will probably be well I'll probably be talking on the prismatic one just because it's where we've been conducting some of the conversations so follow it follow that one and we'll try to hone in on some of these decisions next week or so cool let me see what is that um cool there's been a lot of questions on b21 around some of

the stuff around attestations and some stuff around shuffling and we've talked a lot on the getter so we might not have some stuff to talk about right now but if anyone has just like general questions on v2 one that have come up that you want to discuss in person now it's a good time yeah I had a question when I was thinking about this the other day um just about to say say you have like scenario right where you have your cycle linked at length of 10 so you're a block 40 or redoing crystallite state you look at your shuffling when you do you're shuffling does that apply it to blocks a like 48 to 49 or is that apply to blocks 50 from 59s biggest another

way to ask it is is there like a look ahead here currently the shuffling is not handled in the SEC Adal so nothing's reshuffled because no the validators aren't changing we're just not handling the RNG reshuffling is likely going to occur on some multiple of cycle length so that's a dynasty change was when you do some of these more you do dynasty changes kind of a subset or extra stuff on a state update and dynasty changes when you bring some new validators in and out it's also when you do recompute shuffling and some other stuff so some

multiple cycle links and if finalization has occurred then likely that will be the trigger for a for reshuffling and at that point yeah you'd have you'd immediately have you reshuffling because because because you're ready to move you're ready to you finalize and you've brought in new people you've now have kind of this notion of a new validator set although you still have some overlap still have a majority overlap but you have this notion of like here's our new validators that what they're shuffling let's begin finalizing stuff okay thanks um this is Terrance from Kris making of

that I have a question regarding um if let's say you receive an incoming blog and that's safe there's a few bad at the station that's within the blog what do you do with the plot do you like do you do you just like ignore the plot bad attestation can respect malformed Adam let's see that's probably just a bad signature or lie yeah yes that's an invalid block and should be discarded okay I see something like that what we're gonna say Justin I was gonna say if you have one of the votes with a bad signature then it's going to pollute the

whole aggregated signature a thousand people voting and even just one bad signatures and the whole thing with the whole signatures gonna fail so it doesn't really make sense to have a single signature which is roll that a single attestation could fail the signature so the block producer should have known that and not included it and not broadcasted unless they were trying to spam or something like that but if it is you know it's it's like having someone produce a proof-of-work block that didn't have an acceptable difficulty I could discard it oh cool that is that needs to be considered for

me now this kind of you because you know proof of work is very easy to check well these signatures might be more heavy and so if you have multiple signatures block and you know just the last one is invalid and it's possible and you spent you know some time checking everything and at the very end have something failing um basically a proof of work is not so easy to check if you don't have a pre calculated data set I mean that it takes time to calculate data set and check the clock it's not a little amount of time in the sense that

you you could put you could have a correct proof of work but you could have bad data at the end of the calculation like bad transaction data okay yeah I see I mean the proof of work for example if he is not so you know like it's much easier to validate the transaction like then what I dated block in terms of calculations so I don't have a numbers of like be alias signature verification or attestation verification but I think

the truth compared to proof of work verification if we calculate if we we take an account that it takes time to calculate the data data set of occasions should take on the order of milliseconds like two three milliseconds that kind of thing and so if you have you know 64 cross links or just multiply that by a few milliseconds it's possible if you use multiple cores that will go down but yeah maybe 100 milliseconds is like the worst years so just amazed we talked

about the like a affinity style zero knowledge groups to be privileged actors in the network a little bit last week as you know one way to mitigate a kind of a DDoS protection I know you were the one that has originally told me about that do you have any thoughts on that I was meaning to dig in a little bit last week when I did not enough time to do that yeah I mean I I learned about it by going to definitely meet up and from what I understand they're actually going to write a white paper specific on the the Pittsburgh networking and you know

it seems that the affinity has done a lot of innovation on the pittsburgh networking so not only have they written their Pippin library from scratch and you're not using the PGP or ipfs in any way they also have as I understand these their own eyes proofs to prove that you're privileged actor but I think they're also innovating on network relay policies and so I'm at this point I'm I'm mostly speculating but as I understand they want to release seven or eight white papers and then only release

one right now on the consensus and I as I understand also the next one will be younger explain that's working so I guess keeping my out of that any other p-21 question yes so just going back to what Terrance was asking before I guess say you get like halfway through the attestations of a block and you find an invalid one it's probably worth hanging on to the other s station at the stations that you did find in that book though would you agree Danny if you haven't seen them yet and they're valid they're probably worth putting in your database for to add to your fork choice rule and for potential inclusion

if you're a professor Google you know it's you would likely be seeing these associations you can outside of blocks but that might be a worthwhile optimization and depending on what we start seeing in the wild thank you cool the next thing we have is tactical details of random beacon and committee selection nikeyra you proposed that right can you give us involved in what you're thinking so right now we've been mainly focusing our discussion on p2p

serialization and how the particular will look like which I think ties into this a little so given that you kind of know a little bit what that looks like well would how would the nodes actually come to agreement on the random number so I know that they're using that Justin have proposed in a different talk I'm using R and L and then entering the results of the round out into PDF so I'm just wondering how would that look like in practice from an implementation point of view and community selection is because the spec mentions committees but

has no ethos on how that would work my initial thoughts and community selection are that using the random number from the beacon we could potentially use that as a seed into some random sampling method and then randomly sample nodes for committee selection those are my initial thoughts for now um does anybody have any input on the second part and then just answer the first part so the second part we have this field and crystallized States called indices for slot it's an array of arrays and so it's the length cycle length or it might be cycling sense no thing is cycling and so you have a you have an array for each slot and that

array is a Chardon committee an array of Chardon committee objects and so a Chardon committee object has the committee inside of it and this is all an output of get new shuffling which currently is not is only used I think the beginning to seed this entire thing but would be used on the dynasty changes and when you have a new RNG so they get new shuffling shuffles validators and also puts them into committees and committees are different that are

assigned to certain flight and are assigned to certain shards and so it is happening in this spec and so take a look at get new shuffling and take a look at sharding committee objects and they all get placed into the indices for slots array that said we're not really doing much we're not really doing reshuffling at the time in the spec you're just kind of doing an initial shuffling and placing people statically if Justin wants to get some more concrete details on what like a Rand our class PDF would look like in production right so I actually linked to some sly I prepared in yesterday and there's some

time which might clarify what's going on so [Music] basically you have the the random reveal period and that's pretty standard in the sense that at every slot you have a block reducer and if creates a block which gets included on chain then that block will also have a random repeat and then once you get at the end of a certain number that it's like weak source of entropy in the sense that it could be biased by some of the last reviewers some of the last basically block producers and then you take that random output and you feed it as an input to the PDF and then basically

there's there's several things going on so if you look at for example slide 11 there's going to be this notion of a target delay so the the protocol is going to have a difficulty adjustment scheme which goes up and down according to the performance of the network and the the target delay is going to be what the the difficulty targets so let's say that's going to be 10 minutes and at some point the the block producer was some block producer somewhere is going to find the the output of the video for the proof that it is the correct output

and he's going to include that on chain and when this ink on chaining fusion it I will happen before the target delay or after target delay and the difficulties are just accordingly so you know in terms of practical things to consider you know we we need to put a bound on you know how long the the vdf evaluation could take so even though we're targeting ten minutes you know it's possible that in the worst-case scenario it could take 20 minutes or 30 minutes and so that that's something to take

into account and then another thing to take into account is it is you know revealed off chain you know broadcasted and gossiped the whole network it still needs to be included on chain and and so we have the notion of an inclusion buffer on on on slide 13 and you know you know that those are most of the the practical considerations from implementation you know it is a simple simple protocol I guess you know some of the subtleties that you want to understand is it's from a protocol

designer point of view you know one of the questions is how long should the evaluation period what is the worst-case evaluation period and it turns out that it's it's on the order of a a squared where a is like the the maximal advantage that an attacker can have and the reason is that that's if an attacker ramps up to you with with you know hardware which is let's say twice as fast to everyone else then because to prevent grinding you have the you have your your evaluation period needs to be at least on the order of a and if yes I

guess suddenly goes offline that everyone is to catch up and they eight times slower so you get a factor of a square by kind of thing you know on slide 16 I have you know how the incentivization works with the idea of having two parallel PDFs one on the public seed and and the second one on the public seed ex-ored with the public key and that gives you a way to if we incentivize well attach the the video to specific public key which can't be stolen the thing is that we will probably have a better construction for this now this is something that I've

mentioned you know that happened during this this research event where we found a way to do so-called watermarking where you in the in the proof of the primary vdf you kind of construct a special proof which is linked to specific public key right so you know from a from a implementers perspective there's going to be some details out of the spec that are there'll be probably another field and a block where people can include a PDF output there will be some rules about assessing whether the BPS vdf output is valid like if it's from the

correct cycle or epoch and whether it has the it's whether it's satisfying a solution to the expected input which would be some of the R and Alex ORS and then Plus that you know that when a when an output is included in a block that can serve as a seat of randomness and there will be rules around what seat of randomness and when to use that seat of randomness to reshuffle things you know and then there's a couple of things on recalculating difficulty but that's more of that's the end of what theater recalculating difficulty for future videos so not terribly complicated and kind of like handling access stations

but on just rarely handling this like extra input to block and bloody around that and then exposing it to the other part of your processes that need the RNG the next thing on the list is the practical beauty of implementations I think Justin kind of handled that in his research update talking about the two primary ones with the RSA modulus moduli are there any other questions around that right now not really is there any results from the PDF Meetup

that are public are being made public [Music] and Benjamin that he was going to update his paper which is on eprints and it's possible he's already done it I haven't checked but I expect it to be some sort of appendix to his cool you can check or share the link so it'd be helpful the next thing is discussion of some of the cross short communication

proposals asynchronous and synchronous maybe Casey wants to give us an update on maybe the the recent proposal for metallic and are you on that thread yeah sure yeah there's a really nice post from metallic on my favorite topic there's still two main issues I feel like one one I think we have a good answer to which is so the first concern is usually when people propose synchronous cross yard a synchronous

crush our transaction protocol the concern has been that the state execution gadget won't be able to keep up if there's you know too much if it requires too many rounds too much network communication and too much latency then state execution can't keep up with the block proposals happening at the at the data the data the data layer but the and the second issue that I'm worrying about which I left a question in the thread I guess it doesn't have to do even strictly with with crock with

cross yard transactions but even just the the face is one a naive phase one design itself treats data bob says just generic so they don't you know contain any transactions and there's no distinguishing between if data blobs have any useful data or if they're just junk so what I'm wondering about is if and the naive phase one design is there is it and is it considered a problem if if validators who are proposing blocks just stuff the data with with junk if

you get my question so a I know it's thought more about blogs than I do have any sauce showing well I think yes it's possible that rock will be for junk but I know the application that Eric my want most is that like so far the first one application might be very limited okay see but isn't that the kind of the point

is that it can just be filled with junk and that there's no structure well the problem that comes as then you know how do you if if validators you know malicious validators could could stuff it with junk and you know there would be no room left word for anything useful like like tweets or you know transactions or plasma data or anything I mean if if if validators can just stuff it with junk then what disincentivizes Valladares or what incentivizes validators to include

useful data isn't the move when you do formalize the execution layer the move is to move to more structured blocks this is a little bit out of the scope of what i'm my understanding of those APIs so my understanding was that you have data blobs at the beginning and then move to more structured blocks as you formalize the execution layer in phase 2 or 3 or whatever yeah I guess from my perspective it's the problem is that I mean it's an easy you know oh it's easy to design a protocol you know an

execution protocol if you assume that the data blobs are useful but it gets harder if you allow you know if it's possible for validators to stuff the card blocks with with spam you know useless data blobs and it's not clear how much of a problem that is or or what ways there are to prevent that from happening right I remember seeing something somewhere the notion of maybe flagging blobs as when we add execution they are flagging flagging blobs is a bit to say whether they're part of

whether they're just data or whether they're part of the transaction execution layer again I've read some stuff about this but it's not some the corporate of my mind on that I'm not sure on the point of view of starting phase one no I think we want every block to be the same size and so in that sense every single block will be 100% filled with junk and by still doing that with junk I mean that you know they will not be interpreted by the evm once we launch the EBM so everything will be ignored in what you know what goes into the blocks

is ignored until we launch DBM and then when we do not EVM only the the new blocks will be intestate so in that sense every will be 100% junk in terms of what decentralizes you know proposes from just filling the blocks with junk well it's the exact same answers with Bitcoin Experian is like putting this opportunity cost on lost revenue from the execution fees and the gas now yes you know it maybe the question is what is the gas mechanism prior to having an EVM well it is possible that you can

have out-of-band fees to incentivize the inclusion of things so you know you could imagine for example a a plasma chain which for which you can you can pay the next proposer to include or tweet and that payments would happen through the plasma chain so even though there's no concept of gas and the point of view of the ABM is all it's all junk you have achieved something useful okay then so it sounds like everything's just up in the air still which is which is yeah what I thought so that's don't

but you know when you add when you add an execution later when you're out of BM you do move to the notion of like block validity in terms of the VM so even if you do have some of the block you can carve out some of the log for data and rather than transition transactions if you have a portion of the block that's carved out for the VM it has to conform to the VM role orbeum validity right Earth's the block will be discarded if there's an insurance being so no blocks will well only unavailable blocks are discarded so by unavailable I mean a block full for which you know this well

basically I mean basically a block header for which there's no block body which hashes to to the block header and and the block body needs to be of the the exact right size so let's say 100 kilobytes and if your block is available then it will be valid what might not be that is going to put into the block civilization is that every every block will see realize you know deterministically and and without without exception without freeing an error to a list list of blobs and then when once the EVM is is implemented then

some of these blobs will be will become transactions and and run in the the default execution engine but of course you know one of the things that we mentioned in in italics blog post is the idea of alternative execution engine or layer 2 execution engine and in in that respect you don't need the blobs don't need to convert it to transaction they can convert it into so-called house transactions which you know from the point of view the default execution engine our junk but actually they provide real value for the user and you know this add sensitization and general comp limits of

its own incentivisation scheme cool so there there is a clean separation between phase one and phase the phase one data layer and the Phase two execution and layer so phase one has no gas rewards it only has block rewards but but no no transaction fee or gas mechanics so the only the incentive for proposing blocks is to earn a block reward but not necessarily a gas V yeah so if you talk about strictly speaking

layer one in terms of infrastructure that does have to be correct and that's something you know that's that's one part of the designer which hasn't changed for months like over six months that's even like close to a year it's been like that very clean separation between a one and A or two yeah but you know even though there's no layer one incentivisation scheme you definitely can have layer two incentivization schemes and in which case it would be against rational proposes to you know have blocks which are all zeros for example yeah I suppose that's the same level of

freedom for for validators or black proposers as with the current aetherium because they can you know there's nothing that stops validators from proposing empty box or from including a bunch of transactions that have a gas price of zero so yeah seems it's essentially the same the same level of freedom and terms what data blobs what actions they can include yeah cool and there's a lot oh go on no I just said

thanks cool yeah there's a lot more around crushed our communication we're gonna table the rest of the potential conversation for now and you know ask questions on the gator and we can bring it up next time it's a little bit you know we have some people like Casey who are thinking about this a lot but in terms of practical be contain implementation with a little bit you know in the future the next question the next potential topic was talking about proof of custody implementation and whether that part of the spec has been finalized and I think I noticed in some of the channels there was maybe a little bit of confusion about the person of custody and what it's in relation to

in with the building of the short chain but I think Terrence brought that up if you have further questions or thought just from the research perspective I've seen a few research threats that's floating around and both from the spec wise I haven't seen that much final ice pack in terms of proof of custody so I'm wondering is it because we haven't start really messing around with the short chain yeah that's why there's hasn't been much respect on it yeah that's fine really yeah I mean I should just sit down and try to to spec it one of the nice things

is that from a research perspective there there isn't that much more we want to go into so you know the the the the one bit custody scheme is you know is it's optimal you know it feels often like incontinence I'll prove it but I don't see how it could be improved at least in in terms of the the overheads to the to the beacon chain you know what one area where there is some kind of ambiguity as to how it could be implemented is in the challenge game my

philosophy there is it doesn't matter if the challenge game is suboptimal in the sense that the messages are slightly longer although slightly more rounds or oh you know it just it's the the reason is that it the mere existence of this and the reason is that you know you stand to win almost nothing you save a little bit of bandwidth and a little bit of computation by putting the custody at random but you stand to lose 30 to Eve by putting a wrong custody bit so my philosophy is just to have a

challenge game which is based on a spring roll a single challenge message and a single response message and and try and keep it as simple as possible simply because I don't expect it to be triggered very often and other than the details of the challenge game you know there's a question around which which hash function do we want to use for the Merkel is Asian and you know there's this it's still up in the air what we want to use here one of the the main questions is do we want to use a stock

friendly function and if so which one I am personally a proponent of of having a start friendly function and one of the the will have two candidates one is called mimic mi MC and the other one is based on on AES but stock where who we we've given a very large grants will be producing a report fairly soon and in making it public and you know encouraging feedback on that report where they will make suggestions as to what would be stock from the hash functions and at that point I think we'll be able to make a decision there's also you know some permits translational

and how long the the challenge periods should last and how long the this the secrecy period should last how long you should keep your secret secret and that kind of thing but these are mainly parametrizations they don't really affect the design that much and in terms of the they be contains back there's no stubs currently for the individual validate put them in you know on some stuff subsequent for yeah I mean if we do have a custody bit you know it would

make sense to just set it to zero all the time until we actually have a shot data right passing over you have some set hash or function the hash for the sharp block cash in the cross things crime right um all right cool the last thing so I've kind of I don't think I got a response from everyone but in some of my discussions it started to seem like the the 26th it was kind of a an unreasonable ask to get people to prague early as DEFCON starts the 30th i am looking into whether we can secure

a space on the 29th rather for like a you know good good chunk of the day starting in the morning through the mid-afternoon that would be around the conference center and so i think it would be a little bit more reasonable in terms of getting people there i know there's some conflict with status but i hope that they can still have some representation not finalized yet but i'm gonna i'm going to check into that and hopefully on monday i can give you an answer whether we're going to be doing monday tuesday where they're going to be doing a meet-up on the 29th cool any anything else anybody want to talk about

before we close meeting we have a few minutes left not really happy with custody from the decentralized staking pools point of view but you guys are already familiar with that so yes right can you remind it so my my two assets and is that i distribute this secret of the people or some way that you can in a

trustless manner allah or no single person to have access to the entire secret which allows you to compromise everyone's or basically everyone in the pool / and you can't really compute any of the stuff anyways you buy a multi patient you just compute the Merkle tree between all of the Earth's I see any proposed solution my head itches I

mean there was one issue around you know the the hash chain and the hash one you know where it's that's difficult to do in in the pool context I think that the solution there is just to forget about the hash onion and have separate commitments and reveals there and then in terms of building the proof of custody with all the hashing you know the right so I are you saying that it right one thing if the the degree to

which you get slashed is is minimal for exposing your your secret in the city if it's minimal we'll just relatively small then I can eternal to my pool a sign basically every pool member and then they have a different secret for one in time and if your secret is exposed before the point of time I can punish that individuals within my pool provided that that individuals share so then the punishment that will be received and I assume at some opponent of the number of people being punished at a given time but if it's on average the water of that is relatively small then that you could

paste as a size limit on the amount of each person in the pool but the hour and a half mark generally I think really protected meeting stay in touch on the getter ask questions and it has been kind of a really good lively discussion recently and we'll humming in on some of these details that we discussed over the next couple weeks thank you so the core death calls got a little bit off they ended up stayed in a meeting last week and they're doing a meeting this week so they're doing a meeting tomorrow I don't think we have a ton of

overlap in the members of the two people that attended both meetings or whatever and we'll try to plan it on that but I'll early next week I'll have the call scheduled yeah thank you thank you thank you [Music] [Music]

[Music] [Music]

[Music]