Ethereum Sharding Implementers Call #0

all right cool welcome to the sharding implementers call number zero this is quite the turnout hey Justin yeah excited to see all these people that are working on charting so just a few procedural things I plan is to do these every other week on the weeks that we don't have the chord F calls sometimes the chord that calls get push back a week like this call back a week so we don't have too big calls in one week I figured we have a lot of us but if you can just go briefly you know one by one say your name what team you're working with and that's that'll probably be fine you can say like where in the world you are and then we'll move on to begin talking about like actually the different teams and what's what's going on right now with the teams sorry I'll start I'm Danny I'm with these Arian research team and I'm in New Orleans I'm Justin also from the research to another foundation and hey everyone I'm Raul I'm with am with prismatic labs and I'm based in Chicago I am in Coralville from Paraty technologies I'm based in Moscow I can't my name is Mikhail and from harmony team based in Russia announced in Siberia I'm from harmony team and I am Ben Eddington from consensus Pegasus group working with Pantheon clients I'm usually based in UK but today in Switzerland I'd like to welcome Olivier bigots there who the call he joined our team yesterday hi there as Ben said I John yesterday I'm based in Paris and I work with Nicola usuals on vacation I'm with Pegasus hey Preston here from prismatic labs and miss in New York City hello I'm Yannick I'm working for brain but happening at the pipes of sharding implementation and I'm from unique it's very hot right now research team passing Taipei Vitalik will come in three minutes by the way hello I'm sorry I'm a mummy from studies and I'm based in Paris hello hi I'm Jared also from status with Nimbus and everywhere and I'm yet sick also from status right now in Costa Rica I'm Chris I'm doing research on developer practices in scaling across layer 1 and layer 2 solutions and my research is funded by the etherium grants foundation may may grants cohort so I just listening in today and taking notes I'm the poll from Sigma primal working on lighthouse and I'm at a Sydney my name is Adrian I'm working with Paul Sigma Prime in Australia as well I'm currently in South Africa either working on decentralized staking pools or at the moment tryna throw together a fiber BLS implementations some sub stuff I'm chicken I'm working on p2p with Kevin in a research in in Java hey guys this is Lane Reddick money II wasn't him and I'm in New York City where it's also really hot and humid right now hello I'm Kevin from Italy research team and I'm basing Taiwan because I've also followed the idea research team uh those are from Taiwan hello David oh I hey we're going around just giving a brief intro who we are and where we are and what team we work with okay um what was that where are you oh where am i I am in Toronto right now cool anyone else I'm McAra I'm from chain safe systems I'm currently based in Toronto right now oh cool yeah I'm Casey I'm with the theory ingest I'm based in the US state of Michigan but currently in Florida and surprised we went through and apparently random order without many collisions yeah pretty yeah we may find a new consensus mechanism here this is exciting just go and you feel like it make a buck say I guess I'm the last one oh cool um Alex from me was a man solidity base in Ireland great okay so I know there are various clients various kind of proto implementations working on charting or planning on working on sharding if one member from each team can go through and give a brief update on what's going on in their world related to that he was and could potentially give an update to well we can save that for I guess research policy but if you're planning on working on client working on a client working on a beacon chain implementation something like that coming from your team give us update I can call out teams I don't remember all of them probably off the top of my head but how about someone just go or I can pick a team Paul I'll give us an update on lighthouse good choice so you know it's coming underway we're just waiting for the spec to finalize because we got the first round the spec kind of implemented and this transitions in but it's changed so now we're like kind of in the next maybe week or so we're gonna get on to that we're playing around with PDP just trying to get like some PDP instance running and some interface with it so we can swap it out later I'm trying to play around to try and find some Bayliss aggregate implementations that work and then if somewhat safe at least at least a tiny bit safe great I'll get an update on the kind of the Python beacon change though that yes people working on I'm almost done with the v2 one update I have a PR there with some like proof that it kind of works testing I'm going to hand that today hopefully I'll have like a decent reference of the v2 one by the end of the week does anybody on or yeah okay who how about Nimbus okay so I studied the implementing become change V 2.0 on two weeks ago as a thing is at that point the reference implementation in Python was disconnected from what was in the hack and II stuff so I started basically from scratch and to get as far as possible and also I explored what we could use for BLS cryptography and studied the rapper in name for Milagro crypto though I have some reservation about I think we need to build something from scratch regarding crypto 2 of something proper great thanks and prismatic labs who renamed their client prison I believe yeah guys lots of updates so we you know I'm no follower but we might get away from death given the spec we realized that it's best just really have you know an independent that theorem 2.0 implementation so here's some of the stuff that we've done we have local network pedophilia NPMs gossip sub we fully transition into our own independent project we have a full beacon node running and the sharding client that runs to the separate process they communicate with each other via G RPC we finished the incoming block sync processing conditions we have crystallized and active state transitions shuffling of the testers and proposers obtaining the cut-offs and announcement of blocks to the PDP we have the validator registration contract that is you know through a deployment tool that we created we were able to read the logs and register and induct validators into the queue and then we also are currently working on the fork choice rule and kind of I'm doing initial chain sync aside from that we created a simple like kind of simulator tool that allows us to like basically simulate incoming blocks and we're going to be using that to basically try out and test our system from an end to end basis going forward we've been exploring a lot of different things and we have a lot of you know a lot of ideas around kind of p2p communication that's something that my partner Preston here will be able to talk about later but overall we have a lot more to cover but that's just kind of some of the things that we've done recently nice and is that the state transition the v2 one or the previous version of I believe into one oh cool great I am excited to take a look at that [Music] whoo Oh Pegasus have y'all done any work or any update yeah I can give an update so mostly focused on the team-building lately so oliviers joined we've got developer joining in a few weeks time the immediate targets to work on are the BLS implementation seems common theme we we're looking at random the random number generation we think there's quite a lot of work to be done there and also on a thinking chain implementation okay thanks and how about harmony we have started to work and then beacon chain implementation about three weeks ago what do we have by now is what are they the registration contract and it's possible to deposit your own well the data and a query for deposited word validators from transaction receives and now we we have already made glance on next step is block production on a beacon chain and the processing part also so yeah we're starting to implement like state transition functions block production and so on so yeah that's it for now by the way we have created a page that it contains all the progress and closed plans about our implementation and it's all possible to get some pull requests there to see a reference to implementation I guess it might be useful for other implementers I'll share the link after this meeting yeah if anyone any links we talked about if you can pop them into the get er sharding channel I'll aggregate the stuff after the call I chain see we've been working on the Loadstar chain which is our JavaScript of the beacon chain right now we've been looking at options to implement Billis signatures right now I've been playing with the Milagro crypto libraries available in j/s and trying to use the primitives to build ABN 128 curve to match with the current Python specs we're also exploring the option of possibly compiling from Russ to web assembly for that and afterwards we'll be implementing the state transition functions as per the v2 on point one spec and that's pretty much what we've been doing we started this project as an internal at an internal hackathon me.how three weeks ago so progress has been steady that's an update from our team great thanks is there any client I missed okay any research updates I know there's been various things so such the e3 search that and I know there's some different things going on with some some that you have people is there any update anybody wants to give right now I from my side have been working on these on the precursor for our justification for choice rules and I wrote out that post on his research a couple of days ago that tries to make a kind of minimal partial spec of the validators the beacon chain was before with the fortress rule and justification finalization and the auditor said changes but it like minimal in the sense that it tries to kind of focus as much as possible on just that it doesn't really focus on implementation BLS signatures aggregation short committees or any of those other details and the goal of this is basically to just have that in one place so that it can be run it could be a research to analyze for security hopefully formally proven and so forth so a brief on what order design goal is with the rpj sure so the design goal there's a few design goals right so one of them is to maintain the basic properties of life safety and aliveness as defines in which Esper FFT spec another is to make the algorithm be as simple as possible so one way in which Kasper FFG did not satisfy that is that it's had this weird Becca Becca go somewhere in order to choose in-between between different checkpoints you have one mechanism but in order to choose which chain is the longest with it from one within one procedure where you like to use some particular you some different rule and so that basically doubles the complexity of the thing and also it's another design goal is what I call stability which basically means that the fork choice is a good prediction of the future for choice and in general like hybrid fortress rules are very hard to make stable because it's hard to make sure that the what Evers fortress were using on the small-scale actually as protective of the fortress who you're gonna use the large-scale where a so recursive proximity to a justification basically gets rid of epochs and it uses the same kind of proximity to justification mechanism stitches choose between blocks in general and it basically allows any blocks to be a checkpoint the another reason why I started going in this direction is that I cared about maximizing resistance to manipulation of the Ransom of the random numbers so basically the idea is that even if the array is MV 10 is total crap so for example even if it's again basically choose the siege for like 1 billion possibilities then the American should still be secure and it should still even be secure enough that be chained basically never reverts even once they given one single block assuming micro network latency and so forth and the reenter there's two reasons for this one of them is that instead of the ransom to the random sampling being stale s the random sampling chooses permutations and goes through permutations so the total number of slots given to each validator is in the long run going to be the same so you can't maybe await that upward and the other property is that because it uses ghosts instead of longest chain as a fortress rule it basically means of the proposers which were these kind of attackable choke points of chain like sitting before don't really have that much influence anymore and so the chain is basically resistant against even like something like 80 to 90% of proposers that I am being taken over by the attacker as long as the majority of via testers is honest great any more updates from you vitalik or anyone else on the research team or at large all have updates on the 99% fault-tolerant stuff that i linked in the ERJ in the casper telegram soo and I'm just having a waiting for a goon to give me some review of a review in comments and I'll publish it and then if you are well think about that more but that's probably for later sorry otherwise since well accent errors we like pretty new to also shouting stuff I've been collecting a lot of blog posts research notes forum posts videos about shouting and everything else for a forum to chat basically it's a repo and if you think something is missing or you want to add material feel free to put a pull request so currently there is stuff about shoddy in Casper plus mastic channels BLS gossips with a video from a CDC blog posts and stuff like this thank you I've been focusing on the randomness beacon basically how to instantiate it once we have a vdf and the various security considerations but also in particular which specific vdf construction we'd like to use so I've gone through the whole literature and I think my favorite construction right now is by Benjamin whistle ow ski which has a actual proper vdf in the sense that there's an exponential gap between the the time it takes to compute the function and the time it takes to to verify it one of the the key questions that we're looking at is because it's based on an RSA group so at least that's one way to instantiate it we need to think about trusted set up how do we pick the the RSA modulus basically and one very promising approach is basically to pick relatively small random numbers and use those random numbers as the the moduli for parallel PDFs so the vdf would be kind of composed of stuff VDS each with its own module modulus and if at least one of the modulus is is safe in the sense that cannot be factored then the whole construction is is safe so you know it's quite multidisciplinary because I'm talking to the cartographers and actually we've the foundation is organising an event where we're inviting the the top the world's top DVF cryptographers to all meet in San Francisco in the in a couple weeks and almost everyone is attending so there should be some good stuff from that event but we're I'm also talking to two number theorists and also a very important consideration is the the hardware manufacturing so the the current plan is basically to build a vdf ASIC which is a commodity so which is is basically freely accessible and is given to lots of people and the this ASIC needs to be close to what a a no expense spared attacker can can be himself so the performance of the vdf in terms of speed needs to be very fast and that's to basically counter a couple of attacks that an attacker with a much faster ASIC can do so I'm kind of talking to a lot of people and tying everything together and I'm hoping that I'll have like more visibility towards a full spec and maybe a month and a half or two in about one month there will be hopefully a a report from Hardware specialists that is going to give us a disability on whether or not manufacturing a vdf ASIC which is is fast enough is doable so how much cost how much time will take and considerations like that Justin you mentioned the research library do you have a like a curated list of reading material to get into this problem space yes I do so I'm actually preparing for the event in a couple weeks and I'll tweet about it and I'll make sure that you can find it fantastic Thanks great anything any other research updates anything from the e azam team that might be relevant or some thoughts on charting as you've kind of been digesting e - oh I do have some thoughts about mainly we've been we've been focused on thinking about cross yard transactions so that for the agenda about cross card transactions if you're inspired to talk about it right now I think we can move towards that okay [Music] we're plant and building is a little bit unorthodox for most because we start or at least I say we but maybe I don't want to speak for the whole he was in team but at least myself honest when I focused on faced the phase two part of of the sharding spec the question is how can you implement Hagen e prototype phase two before without a phase one implementation already built and the answer is well phase one and phase two are are actually decoupled like Justin and and others are saying then the only thing that phase one produces is a bunch of ordered data blobs so these are chartered blocks and with cross links between them so if you just Vox phase 1 and of what but will be say a a JSON a big a big a JSON file that defines some de blobs in ordered in a given order and then the face to prototype would just process these data blobs and and achieve cross shard transactions and so that's our hope with with prototyping phase 2 well one of the advantages of doing this in JavaScript a couple of advantages over other languages that are working on research prototypes like like Python is JavaScript there's already have a PD library implemented in JavaScript and also JavaScript already has access to a native engine so I have to mess with any beautified workarounds to get access either Limpy to or to a blossom jet engine so yeah those are the two benefits of prototyping phase 2 and JavaScript and that's about it great and so you are a little bit more about what you're trying to prototype you're trying to prototype access execution like a probabilistic execution engine across but to be able to resolve crush our communication before the cross links are necessarily process or what exactly as I remain are you a queue you're doing the cross shard execution like through the through the cross links sure well so I mean think about it from a delayed state execution model versus the non delayed so the cross-links would already be there and at that point you know the face-to-face juice completely decoupled from phase one so the cross links are are put in at phase one right not Phase two so we don't have to worry about phase one we can just black box all the details of BLS signatures of you know putting in cross links of forming shard blocks we just accept as you know a Giffen here's a bunch of ordered blobs with cross links now how do you process the transactions so this is kind of the approach time I'm hoping to to take and and be completely ignorant of all phase one details great while we're on while we're on the crush our communication I know there's the the difference opaque starting transparent starting I can't ruin which is which but the idea of the users having to deal with this or not I know that in general right now the thought is to push it out to the application layer to handle dealing with the crush shard stuff is there any I know but this is kind of a contentious debate while we were in Berlin there any more thoughts or update on the research on crush our communication or is that maybe a little further down the line at this point okay we'll pick it up again another time great so the next thing I threw on just recently is the the v2 one spec are there any questions about this at this time I know I mean if it's as you're working on it if you begin working on it we can answer questions in the and the channel better there yeah go on become I was just going to give though or a bit of a warning about that that some parts of that's what it's parts of that spec are kind of explicitly provisional in the sense that like things about how the dynasty change works how these transitions work and so forth are gonna change pretty significantly with if they're recursive proximity to justification stuff gets included the main reason why I haven't in put those things into the specs yet is because I feel like I don't want to waste too much of people's time was like constantly redesigning you know implementing this in code ten times in parallel time is actually introduced and implemented more in parallel and would prefer to wait a bit more for the new fortress rule stuff to solidify more ideal again like get more of you from different sources before we try to actually put serious code into it like the word serve that's uh huh so given the current spec is there anything that yeah okay so it's about to kind of go into that so like the things that absolutely I think are absolutely worth working on and then number one is obvious we aggregate signatures number two is the general structure that you have this active state you have a crystallized state aggregate signatures can be included there is a bit there is a bit field that keeps track of all these aggregate signatures there's some probably for now maybe black box dynasty changes so I don't really have dynasties change and just have a one single validator said and like I feel like at this point if you could get even you know like half the spec like even a minimal version of the beacon chain that doesn't implement any of the dynasty stuff doesn't implement any of the wrandell stuff and then if you get to that points then probably just focus on the peer to peer and trying to see if he can make it actually work actually working as a network and the rest of the you kind of architect protocol structure and details will probably keep getting filled on over the next two months or so cool any other thoughts questions on the b21 as it currently is just in general the the one of the big things that happen with bg1 was combining the block the beacon chain block essa station and the shard cross links and so they they are one in the same and also serve as the FFG both yeah well yeah so in this spec well there is actually three things that better combines together one of them is FFG voting one of them is like small-scale block attestation and those things are what fully combines now with but with our pj and the third thing is the short cross link votes the MEC is the mechanism for like which what shards are active at any and during any particular dynasty and who ends who is assigned to what cross like that itself might end up going going through a couple more redesigns so actually if you're implementing maybe for now like I would even say consider just making it a stub where what were the simplest stub is probably to just say one height corresponds to one particular shard and then if the shard committees end up being really tiny will so be it yeah one thing I'd probably add is that these with the way our pga works in the specific case where the number of alligators is extremely small it does open up some other possibilities so some of the other possibilities would basically be that if the valid if the number of alligators is too small to support one distinct committee at every height then we'll basically just have the validators that's overlap and for and people in committee at every height but force their committees to be for some Bell Gators to be part of multiple committees those are the kinds of ideas that I wants to keep thinking about okay so b21 there's some good stuff there the bones I think are generally in place but as discussed there's going to be still some changes the next thing is the p2p conformity p2p messages dramatic protocol buffer is another piece of P related discussion anybody want to start us off on PG stuff yeah I can start on that so I put this on the agenda basically it froze Matic labs what we're doing is we're using protocol buffers for now because they are easy to use the you know they generate the stubs that we need for these clients to talk to each other they're really easily but the problem is that they have unordered fields which are unordered so it's difficult for for hashing if you're considering like sitting a block across with order transactions and it's not going to be may not come out on the same order for another client so or you know exploring other alternatives like flatbuffers which you just read the wire protocol like there's no hurry serializing that so we're kind of looking at that but what I wanted to bring up is can we start early on agreeing on some kind of schema preferably something that's somewhat was supported and can generate some kind of code for for most of the languages we want to use so I just want it here if anybody had any thoughts on you know preferences or or anything like that on conforming to messages earlier so that when we want to test it out we can already start communicating now do you have any prototype for a message like maybe you have somewhere in some public page yeah so in our prism repository we have our our proto messages to find when this is what our clients are using to talk to each other at the moment so if you want to look and kind of see how we're using like how the scheme is defined and like that's used it's in a repository I think that would be a good point for every one of us to start from like a discussion of you know scheme of message format I think you know what what it was before is we sort of just agree it on the fields and sort of what order they were in and that was just kind of like written down and then we all implemented that I'm kind of hoping for aetherium to we have something a little bit like smarter and easier to use hello took a look about the portal of stuff and I'm not sure if I'm right is that the best administrated sterilization only when we used when we are using the data structure map and that's that's when this happens about Odori yeah so the problem the problem is that when when one client one language or one implementation C realises this and regarding the ordering problem like the the protobuf spec if you look at the wire protocol itself it doesn't define the order it space yeah it's I mean it's unordered by definition sir yeah yeah but also the Spector way it works is that if you're reading a stream of protobuf you're supposed to look at the last value for every potential key like this is a feature robot that you can basically append a protobuf blob on at the end of something and you're supposed to get the last value back from your parser if you're a conforming protobuf parser so there's a lot of these little um extras that that make it difficult to use in a in the hashing setting what could possibly work is Kobus where you just pick a few features and and and probably others a little bit like us and we're floats are no no regarding that I think what flat buffer from Google was an evolution in that direction and also captain proto or Cap'n proto which was it was from Google but it was from the guy who implemented protobuf at Google and left the company later I have a question so prosthetic labs are using the proto path for p2p and how about how do you are using for the serialization of the database like how do you store the plug-in but which civilization are using for encoding a pocket my question is if we are using different duration of the data storage and p2p senior relation OD course that we have to do to simulation when syncing the box I mean we have have to serialize the black from database and then send to the peers who are asking blocks on you okay yeah we we still use proto for serialization and storing it inside of the instead of set of level BB so specifically you know we right now we also serialize the active state in the end this and the crystal I state with protobufs we use protobufs for basically all process communication and our sharding clan runs a separate process and connects to a beacon chain of here G RPC so yeah we serialize everything that we talked that that process talk to each other with through proto's and we currently see realized like I said the active state and the in the and the block data with proto our shell and these methods and then we store them in local storage wait one question like why does the Crystal Eye state even need any special serialization when you could just like AXA values together you mean just like get to get the bytes out of that so we just you know just also we because we were communicating the crystallized state between processes so well we create we created a pro for it that's why yeah otherwise we would just you know I just need to get the bytes from it yeah that was just like a wrapper a container for okay guys I have a question for you I'm we're interesting and how signature irrigation stuff will look like from Network point of view I mean how many messages it will be required to send for example Tucson to attest a block did you do any experiments in that we have it in the network now yeah go ahead I was going to say not much yet though you can kind of do the math and see how much you'll end up having a download probably that mean well the one kind of bottlenecks is you see right is that you have all of these valid leaders that are constantly publishing all this here we have your load of messages that then all get a grenaded every eight seconds or whatever into this so one single thing so that does seem like the sort of thing that could easily benefit from a separate ear to peer network but but aside from that I feel like the best one of them and the other number that we have is obviously all the different estimates for actually how many Bela Gators will adopt will end up participating and how many Olvia we're just participating during each epoch if doing it the naive way of just everyone broadcast up and propose their aggregates is too hard then there is a scheme for doing it hierarchically that could be that could be considered where basically you would have no no it said the network just randomly chose to specialize in a particular slice of know the addresses of an aggregate for that and then they broadcast that to the proposed or rebroadcast out and that's what the proposers try to download in addition to the hierarchical strategy you could also think of a kind of random path strategy where you you keep on tagging on your own signature and kind of the gradually aggregating signature travels through the whole network well that doesn't work because that takes so event time like we I think like if we want to get more times to be reasonably efficient then we need something that takes at like two to three rounds of network communication which basically by itself implies like a fan in of either square root of N or it's you've heard of that right I guess you could have a hybrid between between the right okay thanks guys maybe a prismatic laps already needs something like that or did some experiments and trig regression networking so we're actually in that process right now we're at the moment just setting up the entire communication between the shouting client and the beacon node and getting getting a testers and kind of proposers to figure out when they have to perform the responsibilities so that's in tailing you know doing some just like you know fetching fetching proto data from from the beacon node and aside from that yeah we haven't really even started exactly on the signature aggregation and the downloading of that so is there any consensus on the protobufs stuff or is that something we still need to talk about later um italic what do you think of using the simple C relation in the beacons re-poll as au p replacement this one by the way guess what's wrong with our LP any thoughts on ROP - Katie yeah so our our proposals not necessarily to get away from our LP but to have some like generative schema that we can all sort of conform to and if there's something faster that we can use like our LP is not very fast that would be great yeah yeah I'll concur there I've been missing a schema for all our LP otherwise any schema language goes cbor I saw Alex proposing and protobuf is one but we would have to get it there's being code from BitTorrent they have a scheme as well I think yeah okay I see schema-less is like very good point for to move from our old Peter son something that Kevin schema yeah got it thank you all right well you know if people want to dig into this a little bit of a next couple weeks and we can talk about it again next time hopefully we can figure out a and including that work stress um I've just open a kind of threads on those Ephraim Research Forum about that yeah I think that'd be a good place to to discuss it also for other teams that are implementing this and probably you know experiment to import proto bus or flatbuffers would be cool to try it you can try to communicate with our client the RPC and see you know see if you can break break any of these encodings you guys using gossip saw Brett yeah right now it's all locally network through mdns though so but we're we're we're quickly gonna start out exploring the other discovery schemes like the edge tease yeah okay but I don't know if that's a topic for later but we might want to try and pick um you know pick some some p2p network we don't have gossip sub in bross yet so it's gonna like add some overhead from a perspective before we could talk to you got it yeah is there I know there's been a few people on the research team that's been doing some keep digging into various p2p constructions for sharding and that's something we want to talk about right now or do the research that y'all been working on is that inform the B container is that more for actually when we have the short chain and are these two separate kind of bgp constructions you sir the beacon the beacon chin and what what other chain the the are we gonna be using the same p2p setup for the beacon chain and also the shard chain but there's no one charging you mean all of the short chains charging yeah plural so the beam difference is right that the beacon chain is for everyone but the short chains are only for well the short chain headers are for everyone but the short chains are for all the whatever subset of no it's cares about them and it would be a pretty serious loss in efficiency to have them all be in one Peter your network so the like we do need some kind of well I know there's already work being done on a short appear to peer network which is what it makes sense to put the charges onto and then the beacon chain go east I pigs should be on some kind of player that just everyone's downloads by default right anybody else working on PTP you want to give us some but Kristin do you want to share some of the ideas that we had about we compete I don't have anything particularly interesting to talk about I think we just I think we just had all the beacon of beyond like shard negative one or something and and basically you know have have have a network for all the different shards so okay so using using the same construction that has topics and just having the beacon chain stuff be on its own topic right yeah I think that made sense for us I think yeah a beacon nodes are gonna be on yeah like shard negative one or something you know some constructs that right actually in my in our original on thoughts the be contained in other ancient messages which is global to the notes can be can be serve as global gossip channel for each topic I mean for each like for the mention header it can be a global on it can be a topic and subscribe bye everyone so um in this way done and so that way on they are the the channel they are all in the same network but segregate by the habits right I guess one question is how many topics per shot do we want it might make sense to have one for the headers one for online blocks and kind of uh Nagre gated signatures and then one with we you know the the fully signed and aggregated blocks so I guess you can dive into whatever level of granularity you want just by subscribing to the appropriate channels does a number of channels or increasing the number of channels impact on network amplification rate but you will only receive I mean um if you want to broadcast a message are you will only broadcast to the peers who subscribe to that topic so we can design something like if we receive the messages from wish we're not subscribing so we can end up here something like that so you will not be affected by other topics yeah but if you're if you're in another one channel or I it will impact as I suppose it's gonna have an impact on discovery mechanism of that network so yeah maybe this impact is really small and we don't need to care about it but it might be that it's not too small you know that's what I am thinking about um yeah I think that it's worse worth testing in simulating to see the impact of this the mean yeah yeah okay I think one strategy to mitigate this is to have a common discovery layer for all the channels and then have kind of the the gossip layer be on top of the discovery layer you dooming are we already have a shark awareness channel or the discovery or I mean yes to do it but you have one kind of meta channel where people tell other people about which other channels their subscribe to yeah so we currently have trained over to do that we also we're also exploring other discovery protocols like um like the render food proko um they proposed by DP to be but it currently seems not so safe but I think that were exploring and testing okay so there's a getter channel that was opened up I think this week where people are discussing these things and working on some proof of concept implementations and testing and some simulation so it seems kind of like an ongoing discussion so pop in there if you have some thoughts or if you want to work on that is anything p2p related that we want to discuss before discussing the BLS signatures as far as like an hour this probably is going to run on very longer but if you have to go yet to go um regarding your Lupita P if we don't have any because there is no leaper to be implementation and Ivor C or C++ it's not worth it right now to try to implement it from scratch as long as because there is no goal like we will go in this direction right mm-hmm yes I think so I mean uh where is um for for our team we received Python so we're we will make the layer in mostly in gold and we will probably use um will choose swabs and that like Python bindings or entirely used using the PI PC or RPC to communicate from the Python and go so I mean because they only have to go link and drum screen so I thought you answer your question was the question or we not we don't have consensus on it so it's probably not worth implementing and anemia yeah that was a question I that seems to be my understanding of it in that you know if you want to start digging into it and working on an implementation that makes that you know that would be a personal decision but I don't think that we have enough testing to say for sure that that's we're going to be using at this point okay perfect thank you got it you wanna move on to the next topic which is Els signature standard libraries there were a bunch of links posted I know that's kind of one of the big things seems to been realizing is that there's not necessarily great standard libraries in all these different languages well for BN 128 there's standard libraries and at least some and like we kind of helped standardize them because we forced like we put it as a pre compile for Byzantium great so the one thing that I think is might end up being tricky is that if we intends to migrate from B n 128 to BL s 12 381 then and I'm still not sure yet like what level of difficulty it'll involve us which all these libraries over like if whether it's a five line code change whether it's something more substantial what's the benefit of changing the curve basically it's got a higher security parameter like Z cache is changing it basically because for okay I guess there's two reasons right one of them is that the curve has a higher security margin so it goes up from something like a hundred annika and in a couple of bits to the 428 bits and another argument is that in the future with Z cache and a bunch of other projects wishing to be a less full 3d one but this looks like this will be kind of D curve that people are gonna standardize around for sometime and so with that in mind it's worth it to kind of go with the flow I guess yeah it's also kind that Tia is intending to use yeah the chances of finding another curve I would say with the effort of standardization that's been going in like another curve would have to have really substantial advantages which would basically mean some kind of discovery if something broken in BLS walks 3:81 which seems like I mean it could happen but it's intuitively seems to be relatively low probabilities hmm I guess the one I guess one property that a new curve could have that would be better that would make it better than BLS for 331 without BLS for 3d1 being completely broken is if but the new curve actually pointed to a pair of curves which come where one was the modulus of the of the other and the other was a curve and the other one was the curve order of the other because that would be really nice for ZK snarks but that's and I guess it's plausible that people find that in like five a five years or whatever though even in that case like though there would be no reason for us to switch and there would be no reason for any application other than see he starts to switch thanks so and what further discussion do you all want to have about this and that there's there's a lot of implementations that someone referenced in the github link is there what what is the process for standardizing these libraries their work that needs to be done any other thoughts on BLS furniture I guess like fer myself personally to be able to update my Python I'd be on 128 library to BLS I would just realistically need like either like what all the parameters are and what kind of curve possibly like it possibly like a couple of hours of hand-holding by some cryptographers deeply involved in this would get it yeah get it done extremely quickly then another thing what's the outlook for a fully audited and would say low-level see the I kind of reference implementation of this curve the rest implementation which is being spearheaded by Z cash is has been audited by and also the the abstract specification of the curve has also been audited by a different security company and the rust library is relatively mature in the sense that in worked on for for many years and you know has been audited does it have aggregates in at this stage it it's mostly for the for the base layer curve operations but the aggregation is is pretty trivial on top of that yeah yep like aggregation of BLS signature is really is trivial let's just point addition yeah we kind of hacked together out on just just off you all and italic but I'm it's like it's about as safe as broken glass in my opinion Ozai thing like name a cryptographer if you go across it yep totally mmm-hmm I mean I did talk to the NBA about the algorithms in the Python and like he said that the hash for the hash to g2 function I created us fine [Music] we also talked about like issues around rogue via text and I think our preferred technique for dealing with them is this proof of possession at the positive time which is not currently implemented yet but it's fairly trivial to implement are you thinking you're doing that on the the proof of work chain or separate I'd say just do it on the beacon chain like basically my own philosophy would be to try to do as a widow on the proof of work chain as possible because that makes it as a little work as possible to migrate everything from the group work chain to the shard chains when the time to the time for that comes ok cool just a mild note to that I was um when I was going through that reference implementation I got I ended up down a rabbit hole finding that Rokia taxing so I don't know might be worth throwing into that reference implementation just a note about the root key attack and how the current implementation vulnerable to that Sheree and I could probably just add our proof of possession method in there yeah and it's it's at least reference in the d-21 spec but it's still implied that it would happen on the prefer chain if we move in that direction the purport chain deposit contract might just become a burn and everything else everything including the purse possessions we validated on the beacon chain and I think I think it does make sense just because eventually when people are coming in from the shard chains they're gonna have to be like depositing from the shower chains they're gonna have to be doing similar things so it would make the flow the same right so from a research perspective I think it's clear that we want to do as much as possible in the beacon chain one question that remains is how do we do the bootstrapping of the initial value set because you need validators to process transactions to onboard new validators at the beginning you wouldn't have any validators but yeah it's possible I'll write a research post on that soon and once more note on the rust so in addition to being audited it it's it's very performant and the the one kind of known downside of it is that it's it's not constant time crypto so it's possible that it's vulnerable to determine which could leak private information so one thing I think that's importance to add is that the computations that are private aren't stick that need privacy protection are the parents parents are just verification they are the elliptic curve multiplications and knowing how to make a look to curve multiplications privacy-preserving is something that there's been like decades of research on so I don't really see a fundamental obstacles in already reason why it should be more difficult than before right it just hasn't been done yet yeah one general note about rust would be that the platform support is sometimes lacking for more exotic platforms but that can be solved in other ways as well that's why I see limitation tends to be the lowest common denominators we can put on basically any hardware out there in just weeks more parts whereas with rust you might have to I don't know update the compiler anymore that's on the list signatures currently okay I wrote actual items for clients and research I don't really think we're necessarily at that point I think that there's a lot of separate efforts going on and you know what you need to be working on and in terms of timing for future meeting was at this time reasonable Thursdays at 2:00 p.m.

UTC every other week sorry Danny and thank you did you skip the current state of crush our communication research so I thought maybe we're gonna I thought maybe what was said earlier was what Google wanted to say but yeah that was more I guess we were talking more about your stuff at the time but is there people want to talk about crash our communication research or thoughts or anything at this point all right baby maybe the person who raises the agenda item wants to speak about it um so the current fetus doesn't really go through exciting communication as much so I was wondering if the research team has done any more formalized work on it or they have any initial ideas yeah so it's worth noting that the Viets you spec doesn't even cover the state transition fortune at all right so it's the purely at the data level at this point I mean in terms of how to actually run the state right make the state transitions I think there are all in the very I see the research posts on like cross or transactions and yanking and so forth and I think and I guess some of the research into the synchronous stuff and that's basically the extent of it at this point one thing I've like terrified Kishin on from the roadmap architects is if it doesn't make sense like I'm hoping to do is to prototype a Phase two execution engine you know in a way where it's decoupled from phase one and we can just blackbox phase one ignore all the details of phase one take as given you know some ordered set of shard blocks so an ordered set of data blobs with cross links and just prototype phase two are they sufficiently decoupled that I would say it don't like if there were really two be decoupled then one kind of thing that that would force is it would mean that execution and the data I can send us what actually have to be separate which would mean that blocks would not contain state words and there would be separate separate processes for agreeing on state routes and so on which we could do if that's what we want if that's what we wanted to do that's delayed state execution yeah like basically I think like if we make an agreement that like we're doing the wait said execution and that you are fully decoupled if like we decide that we're doing state execution at the same time as the etiquette said so basically the current be a current model then like that you are coupled what do you mean current Model S in like the etherium 1.0 model where blocks have state routes okay I mean one of the things we're considering is not shuffling the the proposes very often in the in the shots and that would be specifically so that they don't have to incur the cost of sinking the state but in a stateless execution model then you don't have that issue either necessarily except for maybe you know the caching additions yes yeah in general I think they the phase two you know the execution engine and the problem of cross yard communication crush our transactions is relatively understudied compared to the details of the consensus protocol so I'm hoping no yes spike more interest in in addressing this problem you know orthogonal ii and decoupled from from phase one and also even though even the names phase one and phase two gives the impression that you can't start working on phase two and still after phase one is already built so I was hoping to you know clarify that that we can start working on Phase two and we're going to in parallel while you know other people figure out all the details of phase one agreed we need to be thinking about this problem I'm excited to see what you have going on can you keep us updated an e3 searcher on the charting Channel yeah certainly it's a little slow going for us the e azam team because our top priority is the e wasn't test net so we're spread a little thin and trying to work on a phase to prototype and launch the he wasn't test net but we expect to pick up the pace once once the chestnut is closer to watch cool is there anything else anyone talk about before we close this first meeting yeah I just wanted to say sorry after you very good latency there just wonder if there any thoughts about having a get-together workshop wraps around DEFCON during or associated with it if anyone's got any thoughts or plans around that be good to know you I think there were plans potentially to have a shouting events and immediately before or immediately after that calm I think that would make sense so that people don't have to travel everyone's their OB so from status we're hosting a hackathon just two days before we could perhaps use that venue in Prague in Prague yeah the days before this is something I need to check with the rest of the team our weather will have room for it but but it's a possibility that that I can investigate I think there's probably general interest I imagine yes in terms of organizational resources will be tapped so someone wants to take a lead on it status or otherwise just kind of fill everyone in and see what the consensus is on wanting to do it I would venture to say I mean there might be some sort of breakout session around charting or something during DEFCON but before after we're probably more appropriate for a more in-depth session all those great names the update just wanted to plant that seed I think Paul and maybe roll the minister yeah I just wanted to touch briefly on the get shuffling function over before it had a little infinite loop thing that it did I'm just I'm just quickly looking at it now it kind of looks like it might still do that is that the case the witch shuffling function we talked about the alligator shuffling or something get shuffling in in part yeah but it has to have a loop that basically is no so though it is the case that like there's no there's no upper balance on the number of steps it can take but it's a like it's a it's a probabilistic algorithm and there is a very sharp probabilistic bounds on it like basically the problem is that in order to get an unbiased or random number from Asia from a random number that's larger than than the first number by something that's thought of also boulders like basically not a way no way to do it without taking on a risk of or without like throwing data we always some of the time so like the basically I don't think that's going to change but that's also like a not something that's dangerous okay so I'll check it out Thanks yeah I remember running into something to pile we can go check it out thanks to tow and Raul I keep seeing your on mute you ready yeah yeah I just want to talk about maybe having a shared repo for like testing infrastructure maybe like storing the contracts that we all have you know we can either everyone on the call can be made a contributor to that repo and then you know we could all just keep that as a shared place just to make sure that everyone's on the same page with regards like VRC stuff and open up issues for possibly like coming up with shared testing infrastructure kind of like how we currently have an ethe 1.0 for the different schemes yeah I know they were talked about happy shared repos and everything but would be cool that it's going to push forward on that more I I agree especially on the testing front do you think that we're ready to begin with some shared testing no not yet so I just wanted to bring that up okay will either get something together in the next couple weeks or maybe register the next call okay anything else charting related or anything else anyone has to say cool well thank you everyone for coming I think that was at least mildly productive we'll plan on meeting two weeks from today at the same time I'll probably just start making the meetings scheduling them for an hour and a half we break early that's fine I think we have generally a lot to talk about lots to do keep following a3 search if you have any questions comments discussion pop in the skitter channel or reach out to us directly or whoever might be able to answer that cool I think that's right sorry one thing I forgot to mention is a tomorrow with get coin I will be doing a small presentation on vgf and then there will be time for kind of Chardonnay ma if anyone wants to join I'll be tweeting about about it I'm sure what platform will that be on get coin I think it will be a zoom meeting yeah cool all right oh thank you everyone all right thank you everyone thank you thank you