KZG Ceremony Breakout #5

Transcript

welcome everyone to the fifth kcg ceremony call so uh i think most people know why we're here but i see jb and alex um if you're new this is the call to coordinate around the kzg ceremony which will make uh build the foundation for protobank sharding uh which is upgrade we hope to put into progress after the merge it'll be the next upgrade help some scalability um let's see so top of mind is the audit i guess we could start with that carl uh carl and kev do you want to just talk

about where we're at with that well i guess um so we're the audit is going to happen in a couple weeks that's when it's slated to kick off um there's some work that still needs to be done and maybe we should just go over that before getting into other stuff if carl or kev want to just give an overview of what what's left before that starts um i think kev can best speak to sort of the where where his repo is in terms of line of spec alignment um yeah

yeah so um i was reading the specs again um i think there are some changes that i need to upstream to this spec uh i basically created a new python implementation that uh to get some executable specs and i was going to send it to carl and then basically modify the rust code again and based on that um so yeah that's where i'm currently at as you have now sort of a further repo that you want upstream uh yeah just i should be able to push it by the end of just call um

just give me one second okay fantastic yeah i will review that asap um because i guess getting getting all these final changes in there and then merged into all your stuff would be well there's number one priority for the uh audit um i don't know if we want to discuss those changes now or after yeah i think that that's fine this is no time like the present we can discuss it now yeah yeah i don't know right so one change that uh carl i don't know if you're strongly for it is to have the cryptography like library only

deal with one ceremony uh so the context of having multiple ceremonies is uh sort of done by the client the front end [Music] so i guess this comes down to a like complexity on the the higher levels of abstraction so i guess more for more for jeff or other people implementing it it certainly simplifies the cryptography a little bit but also like i don't think majorly so so i don't have strong opinions either way like we're just shuffling around complexity um i guess the the the only aspect of this

i do like is the idea of just not having to sort of touch the the files like we just pass in the structure that is exactly as it is from the for from the interpreter json uh in terms of simplifying things but yeah otherwise it sort of gets touched in two places once when we uh we deal with it on the website side and then again once it gets passed into the krypton library right um okay so i'll just defer that to jeff to see the complexity um i guess also the json as well um for the crypto i noticed that we're

dealing with json uh currently in the rust library we basically just serialize the points in the binary file so it's just like 2 to the 15 g1 points followed by 65 g2 points but in the specs it's a json file i noticed the rationale was so that we can um basically uh i think it said something about touching parts of the transcript is that correct um

yes i mean look at the the my my fear is like you say you just just encode the points but like under what encoding usually there's like uh for points you can do like um like compressed form to just send it over like some they usually have this serialization okay but then like how do we pack the serialization into a binary format it's just one after the other so if it's uh 2 to the 16 points that you need you just do like 2 to 16 g1 points followed by 65 like g2 points for example i mean we

we can do that i think i'd prefer to stick with something that has a little bit of structure like that this is what i'm appreciating about the json so like the the what the the json is just basically a a string which contains that the the hex encoded version of those uh the the compressed form of the the points right the benefits of the json was just primarily just like it's like a a complexity thing i mean it's i agree that it seems relatively trivial that

like we we just packed them back to back but like this like no no i'm worried about like starting to to worry about like what what exactly the byte encoding looks like um right i thought it would just be the same as the json it's just that instead of the hex strings they're just basically concatenated together i mean in essence it is [Music]

i don't think it's super important but i do think it is like sort of simpler to like particularly for someone if they're trying to implement sort of the uh just the the website of this and and not the the the crypto so sort of up to the sdk then it's easier to think about like this um when i worry a little bit like about what like like worrying about now biting coding in um white arrays in um [Music] what's it called in indian javascript et cetera et cetera like i i i i

if you were writing this all in low level languages and like we didn't have this file to pass around or whatever then absolutely i'd agree with you but sort of given this level of abstraction i think it's much easier just to see and understand what the file means i don't know what does everyone else think about this um i guess the the main thing that popped up for me was that the json on the cryptography level seemed a bit off which is why i brought it up um yeah i tend to think there's less

less ambiguity with the with the json encoding so i'd lean slightly in that direction okay [Music] jason so is is your particular complaint from the like what the sdk looks like or just the idea of the these json encoded bytes in the first place uh yeah it seems that we don't ever need to actually look at the like what the points are doing it's just really a really flat serialization on the

cryptography side uh which is why i brought it up like for the i imagine the front end would need some like it makes sense on the front end for me but then for the cryptography part um it seems that we just need just the bytes and we just need to know how many points there were um yeah i agree but like again there's also sort of standards that seem to exist across the ethereum space if you go like right down to like how uh the el and cl talk to one another or how the beacon and vcs talk to one another um all of this stuff seems to be just via via basic json even if they're

like way more efficient or more sensical ways of encoding this it's all just pack strings um for for for for ease of use and i think this is an extension of that right and did anyone else have any thoughts uh duncred or jb i don't think so so i mean i guess one further thing here is that with the definition of the sdk what you'll be passed in is

an array of strings basically as opposed to the json itself so it's sort of string like string two to two bytes and then just from there so you're not like you don't need a json library or whatever in the cryptography it's just standard string manipulation and there shouldn't really be manipulation beyond just iterating of whatever you're passed in uh wait so the json is only on the client the front-end side i mean yeah in essence the the this is again why i was trying to have the the the what i was meaning when i was messaging the other day about exactly

how how would you like this interface to be encoded for the sdk um because now that the sdk defines all the same like the same types but they're defined now as native javascript objects as opposed to json right um okay yeah i think i can just put keep yeah json uh strings so i need to change that um okay yeah i mean it doesn't change much i think if the cryptography never needs to worry about the actual json file should be fine

yeah um i think i'll write this down oh sorry i didn't mean to send that i'll write this down as because as one of the uh part of the rationale because i think in other ceremonies they usually do this pact um absolutely right encoding yeah uh and i think that the the two differences here is one i'm very heavily trying to optimize for anyone to be able to write their own software and b that we just have so few points that like the amount saved over writing your own biting coding or deciding that it's just not worth it right

so the main reason is for redevelop for readability yeah like readability like insight into what's actually happening right happening where uh creation and because in a theory it's uh this is what you usually do yeah this just seems to be the standard that we use everywhere okay uh okay that's cool um looking at the notes another thing was the actual encoding um i was using pi ecc and they basically always compressed the point

but i noted that we could just use the uncompressed point i think with the json um idea we might not be able we could do it but it's going to make the file a lot bigger um the idea was that with the uncompressed point when the contributor gets the points he no longer needs to decompress the points which i think is a square root per point yep [Music] but i guess this is fine um i mean i personally think so

um yeah i think we should just run with what is that what is the trade-off here between uh like that's more more bandwidth at the cost of lower performance right yeah basically sorry at the cost of higher performance yeah um can can we quickly go through what that means what what is the what how much bandwidth do we need to uh transfer the full so so the ceremony right now uh the files like seven megabytes uh going for uncompressed would push this up to like 15 or so megabytes i see so it's a it's an effective doubling and it's as careful

what is the decompression time do we have any stats on that small relative i think to the other stuff we're doing uh right i think isn't it a square i think it's an inversion [Music] per point so about two to the sixteen and inversions i guess wait but in inversions can be amortized inversions are basically just multiplications um that's true so is it defined

right yeah maybe we can just yeah i mean it feels to me like the better trade-offs actually to keep it compressed because seven to 15 megabytes that does feel significant and you're saying the other side the decompression time is not significant compared to other stuff we're doing i don't know significant but if you can amortize it then i'd say com keeping it compressed would be better [Music] like what's the worst case connection that we are factoring like let's say it's

one megabit then seven extra megabytes is uh like a minute or something a bit more is that to download well or up i don't know i mean both sides right uh we also like i mean isn't it the same for sending it then i mean i mean i can easily imagine people even using slower connections than that like i mean especially when you consider that upstream is often much slower than downstream i mean i kind of hope we can be a bit bit faster than that

right but i mean if if we're using those kinds of numbers then then like absolutely we should stick with a compressed form yeah okay but i mean let's say like what is the internet connection where they would be equal i mean how long does it take to decompress let's say it's i don't know 100 milliseconds oh one second it's much i mean it's much less than one second the whole top of the whole ceremony i think we have down in like three seconds in a person of implementation right like includes

all the decoding or whatever well but not on not on not it was right it wasn't that's like 10x slower uh not quite that bad but yeah something like that five to 10x yeah okay i mean my intuition is that uh compressed is better because the worst case like i mean the worst case connection is just much much worse than the worst case like so so i i guess like in in in the in the average case it doesn't matter much like both are pretty fast and like we're both talking about fractions of a second but uh but if either like

basically you're unlikely to get 100x slower uh processor but you're quite likely to get 100x lower internet connection um right okay yeah i think that's like someone might be doing over 3g or whatever so i i feel like i mean compressed seems the right trade-off to me by the way are we sending them as json or are they like binary that's jason so that's another i mean that's another factor of two or something right yeah that's but that's that's how we at d7 make make file sizes yeah i mean so you could probably get another factor of two if you can compress that

like send them as gzip or something right uh yeah just remember the json discussion i don't know if you cut if he was uh not here did you have any opinions on that basically json versus binary [Applause] but i mean like it does feel like it makes a significant difference but i guess like jason will be potentially much easier to code and debug so maybe just compress the json that should give you pretty much the same because the problem is the problem is

that that numbers are stored as hexadecimal right yeah so and that should be very well compressible like they should just we don't really have any numbers right it's only points right and how are they stored they're they're strings hex strings hex strings exactly and so no no compression compression should pretty much eliminate the overhead of that yeah but wait but then we're going to have to introduce the compression algorithm but that's what i'm saying like i don't think this is worth it i think like we're arguing over sort of gains that if we were to no no no but but don't don't like i mean don't uh can't you get the

browser to compress it or something i thought we can but then we gotta decide on standards and everyone has to include this compression then what i'm trying to argue here is that like relative to the the like what we already have for numbers for participation whatever these are like not limiting factors yet so i agree if we're struggling to get all this done and we had gigabytes worth of files or whatever but i mean a seven megabyte file i download like i i don't think we're constrained yet right not not in the average case i'm just i'm just wondering about the worst case basically so i mean i agree in the average case it's trivial the the the other thing is that we like the how much time are we giving people

to participate is it five minutes or i think jeff can speak to that but i like a it's dynamic um but b i think the ultimate time timeline is something like three minutes okay wait that's a lot of time right yeah yeah i mean let's say let's say it takes one minute to compute so you would have one minute to download that upload so that's like well actually i guess it could be asymmetric like if it's asymmetric say you could do 30 seconds to download and one minute 30 to upload uh so something like i think the problem with um sort of

giving people a lot of time is that i can register like 10 000 github accounts and then now you've given me let's say three minutes i can put myself in the queue and then just waste thirty thousand minutes i mean the the time to initial check-in should be more limited than that so at the very least you have to start downloading the files [Music] right but you've but uh each participant gets like some upper bounds to do everything yeah yeah that's not sure there is there's a key point called slow race attack but like the sort of like do do the minimum viable to to to keep the server happy

wait are we only requiring a github account no no further have we decide on that you can do it yeah yeah i was thinking that we could have some some rule like that there's been a commit in the last month or something like that and and a repository that's more than two weeks old something like along those lines okay i see when did we decide on this github i didn't i wasn't aware of that uh came into it yeah but it's not really yeah like sorry i didn't get that these are all discussions that are still happening drug okay okay i see it's like because i thought we're doing something

like enos or ethereum addresses that's also that's also another option um we can get around with github accounts here's how you could do it make sure that it has a commit that is at least like well that doesn't that was made before we made this decision basically then it's very difficult to game because yeah you would have have already and that that still includes like a huge number of potential people so it's uh yeah i think that would be the weather jeff opened a pr five hours ago against the the reaper where he's put some of these ideas down and i assume we're going to discuss that later on this call but yeah we this is part of why i won't be going to get on github as we can have

these discussions sort of out in the open because there are sort of many ideas we've all been throwing rough numbers around but we actually need to make some decisions on these constants yeah but i think it's all too much in the abstract now to right when to complain but some some ideas like this are pretty reasonable okay so i mean like basically with a three minute seven megabytes file i think i get like you need probably like a 600 megabits upstream or something realistically to be able to complete this um giving one and a half minutes for the upload um it's probably okay for most people with a broadband connection but it's probably gonna fail for some people if they try to do it using a mobile connection [Music]

right i guess you could say that's fine i mean that's probably fine and just tell people hey like make sure that you have a good connection like either you go to a spot where you have like a good 4g connection or you do it at home wait you're saying you need 600 600 kilobits upstream okay yeah okay sorry i said megabit before yeah i was just like my number's done yeah [Music] okay so the the the other thing is uh my part of what i proposed in the past um is that at the end of all of this we

have a separate time where you can apply for longer slots etc etc so if you fail to get into all of this because your internet connection was too slow um you could apply for slots yeah but i really want to reserve those more for specials like for vitalik using pi ecc and stuff like that um rather than making that a general thing for like i i think i think you should get into these if you have a justification why your contribution adds a non-trivial amount of extra security yep um wait but then can't we say that we'd be sort of disallowing people who are so

who don't have um strong internet connections like maybe in countries that just don't have good internet right but is that nowadays is that a concern that like i mean how many countries can't you get a at least one megabit internet connection in i i don't know um [Music] okay yeah um cool

[Music] uh yeah so okay so we're keeping the json and the cryptography takes string extremes another thing was the mention of uh irtf bls draft um in the specs um i think that some people just won't have read the draft and they might not know what actually it is so in the implementation i did i wrapped pi ecc and just

exposed methods like pairing is in subgroup is identity so methods that don't actually um relate to this i to the draft so if you made your own bls 12 implementation you it doesn't need to be compliant or even relate to the draft so the reason i included the draft is the draft is where we have all the my constants etc etc um it's also like what most these libraries are are talking about but i don't think i say anywhere that it's required to be fully compliant uh and that's why i have the file bls.md was to define all these endpoints

[Music] yeah you didn't say it was compliant yeah i didn't mean to say that i i just said that there was mention of it um yeah but my mention was just like this is the curve like here is the document that defines the curve and defines what point compression is [Music] uh i think there was something on key validate but i can double check um i i i think i said like if you are using a a an implementation there then you could use key validate as a way of doing some of these checks i was just trying to offer another option but like absolutely if any of this is unclear i'm happy to make changes except prs uh but i'm not trying to like enforce you need a full um irtf standards compliant

implementation of bls yeah oh yeah sure yeah it's just maybe let's find them i just thought it might be better if we just had something very general like this is what you need from the from a pairings group and that's it um but yeah i guess actually if most libraries are irtf compliant we could have this extra section that says you can implement it using this or something along those lines um yeah i mean the irtf like really is just a fancy way of me pointing to the the the the curve curve parameters so if if that's not clear whatever then that's also just my

bad wording in the b specs might have been just me reading this incorrectly yeah but that the fact that that was possible to you is is sort of an issue to me but anyways um i think we're on the same page here um i guess the next part uh we said that the pairings checks it had a should so they should use the random linear combinations um i guess it will just be really slow if they don't yeah i'm not gonna like it's not wrong if you don't do that just ridiculous yeah i agree i agree yeah yeah um think that was mainly where

the differences applied um the witness continuity check i wasn't quite sure what it was doing but maybe we can take that part off line i think it's missing um a pairings uh pairings checked to check that sort of the previous ceremony continued from the current ceremony continued from the previous one by using yeah yeah so i think there's there's i was assuming some statefulness or something there okay on the the part of the the coordinator but yeah if again if that's not clear then that's just

probably wordings or maybe i've missed something but yeah sure let's let's check after the score cool um yeah apart from that i think that's where most of the differences were i changed up some of the terminology like i don't use the word transcript anymore i use srs or update proof um but maybe we need yeah maybe this is getting into the weeds and we can discuss this offline because i think that's mostly the things we've discussed are mostly where the differences in the rust implementation are and the

python yeah sure um i did i don't know if you saw i did a big change just before i went on holiday uh which sort of changed what was called transcripts and what wasn't um et cetera so the sort of change now is that the whole file is called the transcript [Music] and then there's a thing the notion of a sub-ceremony which refers to like the individual collection of powers of top plus witness okay yeah that that's actually a lot more clearer since the transcript is just defines the interaction between two parties yeah i managed to confuse myself once or twice and i know you've been confused in the past and i was like okay cool i'm

clearly being an idiot with my naming schemes here so i changed that um yeah so it's a bit different now okay yeah that makes a lot of sense uh yeah so i think that's mainly all of the [Music] where all of the discrepancies are uh while we're on the call i'll just try to push this python version and then modify it to just slightly to match the specs i just need to modify the serialization from binary to json and i think add this sub-ceremony api yeah

yep that sounds that sounds great yeah thanks um so i think that that covered the updates that kev has or expects to do is that um i'm assuming you're fine working on that on your own and it'll be ready by the 15 or hopefully a little bit before yeah yeah definitely okay

great um there's also the we had talked to previously about this idea of a rationale document is that something that we can also make sure to have it sounds like it would be helpful for the audit yeah i did add i was trying to bake it into the python reference implementation but i'll pull it out and put it in a separate uh hackmd document i need to modify some stuff now because we've sort of changed like using compressed versus uncompressed so yeah i think it would be really helpful to sort of explain why we diverged from uh previous ceremonies as well

yeah for sure and the more context that we can give people the better i think um is before we send it off or do the kickoff call is there anyone that you'd like to have review it or is the internal group here probably sufficient um i think it's sufficient what do you think um yeah i'm i'm happy that's sufficient i mean i haven't read i i haven't read the stock up so you know obviously i want to review it myself but like yeah i was just going to be made here aren't insane so right yeah i'm just thinking about um obviously we

a bad situation would be kev finishes it uh like the day before and there's no time for people other people to review it but i don't think that's going to be the case i just want to make sure that there's enough time for some other people to get eyes on it all right anything else on the implementation and prep for the audit if not jeff i'm assuming you have some stuff from the last two weeks that you've been working on do you want to give updates

there oh yeah um so i guess the big breakthrough is we have a solution for running the wasm in firefox uh it's um uh yeah so at least we can do it in firefox it's it's it's not multi-threading where it is in other browsers but we we've got time to work on that and get it multi-threaded i think but at least we've got a solution um uh what else yeah i've uploaded those those specs to the kcg ceremony repo there's a couple more to come through um yet but

i promised to do those last time so that's they're on the way um i think i think that's probably all i have to do updated about what's the single thread performance on firefox oh uh the issue in firefox is so we had we had russ compiled to wasm and running fine in chrome with multiple threads um but it crashed in firefox um and so we could run it was the multiple threads that were causing that that issue um so we could run a single threaded

model in everything in every browser and effectively what we've done is run keep the multi-threads in multiple threads in chrome based browsers and do a polyfill to run the single threaded um version in firefox right what i'm i'm asking about is uh what what is the performance right now how long yes i've got good figures on that um so in uh [Music] chrome it was it was like five to 15 seconds in that sort of range i think in firefox

probably more like uh 40 to 50 seconds okay single threaded yeah cool okay i mean that that's still promising what cpu is that oh that's like a laptop or something right is it online yet can is it on the trial website can i try it the the firefox version is not um the version that's currently online is the multi-threaded one that runs in chrome okay i would be interested in trying that once it's ready yeah yeah me too see if that interface is slightly nicer with the

apple um as well jeff yeah we haven't addressed that oh it's because of modules uh when you when you compile it with uh rayon it's in it insists on doing a modules build and firefox doesn't support web workers with modules um was he using comlink uh no unless it does behind under under the hood but i just use a wasm pack um which recognizes what you know wasn't by gen rayon

and insists on doing the the uh modules thing yeah maybe we can look at that offline because i i remember getting firefox to work but it was safari that just didn't support nested workers that was the problem okay yeah i'll get in touch with you about that yeah sorry to backtrack i i just remembered i had another um thing about the api can we allow a single person to make multiple updates um so contributor can uh

submit multiple update proofs can we like participate multiple times uh yeah yeah we're explicitly burning that yeah i mean you could you could with multiple identities like an ens slash github account or whatever but uh so maybe i should uh so as the coordinator whenever i receive a new srs it's i cannot there's only one update proof that comes with it what do you mean by update proof uh so an update proof uh proves that the previous the srs the coordinator

currently has um and the new srs it was changed via some secret yeah so that's yeah that's essentially my continuity of witness whatever the hell i was going to check right um yeah it was awesome because the api could easily allow multiple update proofs i think marius brought it up before it didn't bring any security advantages i think and i actually know that no actually never mind because i didn't that introduces a lot more complexity uh because if i do a sub ceremony i'm gonna have to have a bigger upper bound

than three minutes so i could easily dust this thing i'm still not following what you mean by yeah multiple so i guess the scenario is that i'm a contributor but then i'm doing a ceremony uh a sub-ceremony of 10 people oh like that yeah but then just just just get all 10 people to enroll separately or get them to contribute their randomness on your one machine if that's for some reason something you want to do yeah yeah exactly uh yeah i think it introduces a lot more complexity um i only act because the api allows is someone's internet connection

yeah i think it was docker yeah uh yeah i only said it because i noticed the api easily allowed it but actually it opens up a dos vector if because you have to increase the upper bound for this contributor because there's multiple people um contributing yeah [Music] i mean if we want we can enforce another check that the length of the continuity of witnesses or whatever they're called increases by one every time um i think it should be fine to just have one update proof uh if you look at the

actors.py um uh file it and then the coordinator you'll see that if it's one update proof there can only be one update from the previous to the current srs um so it should be fine i think yeah and that is that stateful yeah looks like it yeah so the coordinator only holds one srs at a time um i guess he can send off the srss to some ipfs place but uh he only ever needs to hold one srs yeah so all the uh update proofs are kept

uh forever in the the transcript json [Music] um and the transcript json is sent to each participant yes uh i think that might be a bit that might be a lot of uh mega megabytes in the end because if 10 000 people have come before me then i'd need the update proof from all 10 000 of them is that correct uh i mean that's that's that's what it's currently defined like in in in the specs um i think that might be more than seven uh megabytes um

i think we have this the the yeah so like 10 000 people um is gonna add um how much would that be i must double check but i like in my head i think it didn't get much over 15 15 megabytes for like 10 000 people right but as a coordinator i only need to know um yes agreed but there's a separate that like that ultimately to verify the transcript you need to know everything so now we need to store separate versions of like the abbreviated and unabbreviated transcript um

for verification after the fact right now are you sending an abbreviated transcript to participants i mean i'm happy to define this but this is just something that wait so after the fact all i need is all of the update proofs that were that are saved somewhere and the starting srs plus the final srs uh yes and that's basically what this file is right but during the ceremony i only need yes agreed but as i'm saying this sort of like the difference between this now abbreviated and unabbreviated srs and i wasn't distinguishing between the two for simplicity if people think it's worth it i am happy

to to define a secret a second object um i i'm a bit i'm a bit weary because uh having the file size grow with the number of participants i think we said ten thousand but i don't i'm not sure like usually we just as a contributor i don't care about the previous contributions i only care about my ones so yeah but we need like some some kind of intermediate outputs and if you want to now attest to your your contribution that needs to be verified against something which means

we need to be somehow posting this full file elsewhere [Music] right but you can only attest fully attest to it after the fact right like you can attest to contributing to some ceremony but until the srs is completed that's the only time that you can attest to being a part of this ceremony that this srs was created by i mean you just point you point to your uh your your contribution in the um what were you according to you put your point to your update proof right so i uh so i can point to my update proof but i also need to link it to the

final srs i mean you can do that by it your update proof being a subset of the total like if your attestation is basically this is what my update proof is and that's all that matters um no i think you also need to prove that your update proof was a part of uh sort of the last srs that gets that gets done because yeah but that's that's that's done by incrementally checking update proofs um i think i understand what you mean but to do that you can only do it after the

fact right like there's no way but your your update proof doesn't change between when you participated previously and at the end right so the attack vector or what the coordinator can do is you can take your update proof he can just basically create a different srs but then your update proof doesn't appear on it right so you'd have to attest after the fact you can't attest if i came it doesn't matter right you don't really need to attest during the ceremony so i i don't know well i think that's why i disagree a bit with that because

that's the time when people are already participating like it's gonna be much harder to get people to come back after the fact and still like know what their participant like where they were in this whole system like wait wait right right right okay but i mean the reasonable thing is during the what happens during the ceremony i think you should just get a signed confirmation by the sequencer you have participated and then if the sequencer is lying at the end then you can like cry both and get pull out the signed message like he was signed i participated but my contribution isn't in there right

right i think it's important that people attest to both participating and that their contribution was a part of the final srs um i guess the distinction here is between saying uh i participated in the trusted ceremony and uh my proof is dead beef and the i participated in trusted ceremony output thus and my proof is dead beef um but i mean you can post your proof

immediately after you have participated but it can only be verified when the when the ceremony is done i think that's fine right yeah sure right and i guess it would be even better it would be even better if like you actually got i don't know if that has been thought i mean i don't want to cause complications but i guess like in ideally the sequence i would uh sign that you have participated as well basically to like yeah increase trust in the sequencer because at the end it can't have excluded some of the contributions but um

yeah great um so i guess to go back to what we're just started it was including these proofs during the ceremony um i don't feel it adds anything like i think like they only need to be stored by the sequencer in a special database yeah in a public place and like look i'm happy to do this i just don't like the idea of having these separate definitions of these these files um [Music] and like this public case in in this essence then becomes a like distributed

storage amongst all the participants that you can see all the people who participated before you so like not only are you keeping the the coordinator honest by having like checking out at the end you're also doing it in the interim because you can verify other people have already participated right but i don't think the interim adds much i mean we're gonna run the sequencer like it's gonna be fine and we're gonna make sure that it's fine i don't think increa it increases anything like that you can check it while it's happening i mean sure but i'm uh wait so i think i'm in the middle of what so here if it runs over 30 days

and let's assume that optimistically most people complete it in one minute then we could have 43 000 participations yeah let's that that like i agree with that statement like but we're not going to have 43 000 participants i'd be ecstatic right we might like like like goals right as i said a few times i want to have more participants and we have points in the ceremony which would be awesome um but uh yeah right okay i mean i don't know i if it causes technical complications then i would say like whatever like keep it as it is but my

intuition is that it seems that we should be able to remove the proofs from the participant files i feel like i mean what's the participant going to do with it they don't do anything i mean realist realistically they're not going to check they're going to exactly so you can so to me all it does is it saves the complexity of having like two different files i'm happy to include that i just think it makes it more complicated for reading the spec where there's now one version of the file that you receive at one point and another version that you're gonna receive at the end and i'm fine with that we can do that i just think it's that's pretty and this easy to understand so just fine i mean it's basically just

two different versions of the same file like one says like one is without proofs and one is with proofs yeah like it's just a modifier on the same file like the json can literally be the same specification can be the same and yeah but to me that almost makes it worse because these are now almost identical things except you need to understand this tiny intricacy and that's like my concern here um as a contributor all i receive is the srs file when i'm doing it after the fact i receive two srs files and a bunch of update proofs um no no it should just be the same like one

transcript file the transfer contains everything [Music] at the end yeah i guess my only concern is that we say we might have just ten thousand but uh it's a bit weary that the the like this the proofs the proofs could be sort of an impact yeah i i was having a conversation just last night and uh with someone and they he said oh you're going to get a hundred thousand participants and my

initial reaction was no way but then he started to say well people think you know there's going to be some reward at the end or something i'll just dive in um and okay if we if we end up with a 60 megabyte file then we're kind of cutting off that that possibility because you can end it with a you know one minute two minute download okay it seems like i'm very clearly in the minority here i will define um a truncated and non-truncated version of this file which basically does it does the list include all the proofs or just the first and last elements in the proofs i'm fine with [Music]

and that as in the last update proof uh so i don't think it needs any update proofs right like if i'm confusing sorry this is like i think again just talking across terminology here because the thing you define as update proof is slightly different but basically the thing that the um the the the point which is basically the generator multiplied by all the secret keys actually you don't need any of that because that's that's encoded in g1 g2 right yeah i think it's just the srs but we can take it offline uh just because there's terminology differences there sure

yeah i mean if we if if we're starting with the generator then uh then it's the same but anyways yeah okay yeah yeah i did see that in the transcript so we start with the gener yes it's just a copy of uh the generator multiple times yep [Music] yeah okay okay i'll throw together pr with these changes and hopefully it's clear enough all right

cool we are at time and i realized jeff did we miss anything that you're working on or any updates that you wanted to give no i think i've covered everything no i'm good okay great um real quick let's just restate what people are gonna be doing obviously the audit is uh main main focus for the next week and a half um what else uh there is somebody from pse working on putting together a wireframe for the site um that's really exciting and hopefully we'll have that sooner rather than later

so we can start uh jeff what would it take to get that wireframe or the once is a prototype combine it with your existing site um so let's see how much yes see how much integration oh so um you actually want like the test data to feed into that dashboard yeah i don't know it feels like a couple of weeks work so like a few few of these meetings away okay that's fine just just to give me an idea of the ballpark timelines yeah um so yeah that puts us in the beginning

of september and i feel like by mid-september we should be when when do people think we should what's what date should we try to run initial contributions through this obviously there's still another audit with sigma prime for the coordination bit and we'll have more uh it seems like there's still some work to like package that and figure out what they actually need to see but um at what point do you guys think we would actually be running initial contributions end of september beginning of october

i i i'm just recalling the previous discussions we had had or would it only be after defcon no i think i i i ideally at the start of a little bit before they've gone right yeah yeah all right so carl i guess for uh to run initial contributions the only thing that needs to be um fixed is sort of the apis and the formats that we're using yeah i mean that's that's that's pretty much been my argument like as long as we can we can standardize all of those then then that's that's fine like even if there are some slight bugs in um

uh the the stuff running on top of it as long as the we can keep the coordinator up and running through all that it should be fine right right so even if there's bugs inside of an implementation uh we can just ask people to uh contribute again for example yeah and then everything like it that's us this is what i'm happy of doing it before the audit the the the zigbee audit um is for these reasons too i mean should they discover that there's a bug which leaks all the secrets or whatever then absolutely i think we should we should start again [Music] that's sort of as long as everything that that comes out of that is is reasonably sensible um then i'm happy with that and in the the

timelines i've posted previously i've talked about sort of a closed contribution which is where i think like we can have contribution but we're not just like throwing this up on twitter asking anyone to contribute it's more like hey we have this thing running um we think it's pretty good uh please participate but like don't be surprised if it all fails or something with with no expectation of actually failing but just trust the community members who aren't going to like spread fat based off of this or whatever right right under the assumption that we're comfortable in the cryptography yeah yeah okay

that makes sense to me um [Music] anything else i'm missing does everyone feel like we're on a oh go ahead cap yeah maybe uh i think we missed one way optimistic contributions uh i think jeff put it in carl mentioned it in the issue i think that we haven't actually finalized whether we're doing it that way or not um i'm still keen on this and i defined the api in a way that it's compatible with us those are the sdk [Music] so are we going for it or

[Music] what does that mean optimistic is that speed moment no no no uh this idea i came up with but the basically you assume that the coordinator is uh giving you an honest set of uh points to contribute on and you only verify after you've contributed oh yeah yeah yeah so you only add that and then if if if you're not happy with it you just don't attest to it yeah right i don't think you even need to verify it like it's like the final transcript will always be fully verifiable right

right uh so the the the the issue here is um it's a it's a subgroup check so if there is a low order group which gets mixed in with the points the coordinator gives you uh then you could be tricked to leaking a few bits of your security which they can remove after the fact by brute forcing all the the possible okay okay so that's i see oh so you're postponing the subgroup checks basically exactly so you only do the subgroup check after you've uploaded the file it's not we're not skipping it and the difference here is you just choose not to attest or you can or you can how i see actually i think uh we could skip it if

the contributor because the update the contributors also say this was the degree one element of the srs that i was given so after the fact if you check that none of those have a low do low order uh then you can sort of skip all verification checks until the end um so you're saying you check like the right but that's that's you you're saying the the yeah okay you you'd have to then post not just the continuity thing and so not not just your your pub key but also the

continuity uh you have to post the the towel at that particular point that's how that the the the coordinator sent you yeah but this information is like not oh yeah that this is yeah so this is my uh the the the um i call this the the the running the running product yeah right but what like yeah this this was the thing that was going to be lying around the the file size well like if you if you just post

your your pub key then to me that's a unique thing to check like now you need both the pub key and the running update that you need a store um so i think you need the running product after the fact um which is when you can also do the the checks themselves the coordinator needs the running update you don't need the running update yeah the contributor doesn't need it but if you're verifying it after the fact um you would need it yes yeah but because we're now not giving the like how do we know the coordinator hasn't messed with that after the fact

right um i think that they can always subtract out the low order elements that they gave people i think they need to multiply it i think they can't but i'd have to double check i think they changed i think they can that because they're low order basically yeah exactly you just brute force yeah so like if it's like a 30 bit or so um it's it's sort of a trade-off because you want you want it to be what powers what powers do we actually have in um can we can we avoid the low order checks

um with the um i mean usually there are tricks to avoid them right where you just was that a possibility at all um i think circum does avoid them by just checking one one of the elements and then they they do sort of uh they show that if one of the elements is not low order then the rest of them aren't lower low order don't have any but isn't there usually like you um like you exponentiate by the um cofactor or something uh but that would change the point yeah so you wouldn't know if it was low

order it just changes it it means the result yeah sure isn't low order exactly exactly yeah right so you we can't really that's not really applicable in the trusted setup right that trick i don't know i'm just wondering like because i think you can usually do that for signatures that's your knowledge proofs and stuff right but i guess maybe maybe because that's that's the yeah i see right okay but when if we need the actual points then it might right exactly oh actually maybe that's not true okay what if we just always multiply each secret

with the cofactor and i mean that's still a perfectly valid secret right because the cofactor is copeprime with our with ours uh with the subgroup this does mean for verifying after the fact you'd have to also do that sure but i mean that's not expensive right well it just means this is a thing we're going to carry on forever doing whenever we have this transcript sure sure i agree which i'm sort of envisioning clients that's not true no it just becomes part of the secret like it's including your commitment like your g to the

uh gtts that will also like you your secret is literally defined as like take whatever your secret generation process is now and at the end append a step where you multiply it by the cofactor [Music] i think that's valid that's a perfectly valid c you're multiplying it by an invertible field element that doesn't change anything right it's still a still a completely like if it before it was uniformly distributed still uniformly distributed um i'm a bit concerned about adding that because i've never seen it in any previous ceremony

like it seems fine yeah intuitively i agree it seems okay but um i want to run this past some people first yeah i mean uh i guess you okay you have to multiply without doing modular afterwards so the catch is okay here i realize what the catch is because if you do modulo the subgroup then it's not actually like inside the co-factor group uh it wouldn't be so so basically your secret becomes larger than 256 but your secret is now 381 bits this is a downside okay so it's imperf uh yeah okay so okay now sorry it that is this is a bad idea

there would be a performance penalty of a sport base basically everything would be 50 slower subgroup checks might be cheaper i don't know right um i guess we can because there's like three ways to do the subject right use the endomorph of them uh just do it the naive way by multiplying it by the the curve order or the largest prime subgroup um and then doing it the circumway which is just checking one element uh the circumway would be the cheapest but i guess we just need to write a proof that it's actually okay well but the circle no no but that only works if you are actually checking

the transfer that's the correct uh summary but we aren't doing that either yeah you still need to enter a pairing check for each of the points yeah he would still have to do that yeah yeah the pairings check with is always there um no you don't do that participant doesn't do a pairing check yeah the participant you you you can as a way of implementing uh the the uh the subgroup check but there's this

[Music] i think doesn't the participant do a structure check to make sure the srs is increasing in uh by by powers wait they don't do that no on the specs okay that's another uh difference because i hm shouldn't they do that i thought that that was quite important for them to make sure the srs has the right structure if they're verifying it i mean they should they should do this after the fact yes yeah well we need to check this for the final transcript

[Music] but if you trust the if you trust the coordinator yeah i agree i agree with carl here that's the right way to do it at the end participants don't need to do this yeah um [Music] so i mean in theory there's a way to to do the subgroup checks relatively cheaply right if you do a random multi-exponentiation of the whole string uh then you can just do this huh plus one sub group check exactly and so you can reduce the root multi exponentiation because um you can do it using local randomness so you can do it

statistically so like 30 bits my 30 bits might be enough but i mean someone needs to implement multi exponentiations i don't know if or do we have already um do do we have that ready in our libraries that's not that's not there yeah so that that's probably technically a bit annoying like theoretically you could do it very fast i think but yeah but that's practically this is i mean basically just a slight optimization over the the socom version kevin's talking about it's all the the same thing we're not gaining yeah right well it would be quite fast overall like i mean theoretically if you do a

30-bit multi-x over 16 000 elements then like that is uh i don't know like uh it is that faster than endomorphism i don't know what what sorry what's the anamorphism subgroup check so i don't know how that works under the hood but it's the way that most libraries do it these days um something the zcash people came up with okay i see right maybe yeah yeah i i guess it depends whether it's cheaper than an edition yeah i think you can do it at the cost of a few additions per element but maybe the movism check is already on the order

of one edition and you don't save anything yeah uh so i just need to write this down so contributors only do a subgroup check okay um let me recheck the roth code because if we was doing a pairings check that would mean the code is a lot faster if we was doing the replication right my other thing is i'm trying to not make a requirement that people have to implement uh pairings for the bls like you just need curve ops if you're writing your own implementation yeah i think that's good yeah um to be fair though uh we could like the subgroup checks um

we could make them optional right i mean you can put they're already optional they're already optional right right exactly but like basically if someone wants to uh run pi ecc then they just skip the subgroup checks well i don't know if you can still skip the subgroup checks from what carl said because the contributor could just minus the uh yeah that's your trust assumption does the that's the sequence uh sorry yeah that's the coordinator sign

so other coordinate coordinator messages signed no currently not right because that would also be a way to avoid the subgroup check if the coordinator signs all messages to participants then participants could later prove that a coordinator has sent them a message with a with a like element that's uh not in the subgroup and that would obviously invalidate the whole ceremony and then you don't really need to do subgroup checks immediately you can do them at your convenience and say like oh i got a slash that coordinator so the only thing is then this requires

us to have a signature library built into right the participant the chord the coordinator right i mean i don't care about complexity and the coordinator i only care about complexity in the participant you need to verify the signatures or you can simply uh use ssl like simply trust that the browser like you you do everything over ssl you certify everything i mean that's essentially i mean that like you you do already have like an encrypted connection for for downloading those but like you that's sort of a separate layer of the stack right

there's a difference between downloading something with ssl and then needing a full like being able to verify things against the certificate after the fact like that's do browsers uh store like the signatures when they download um stuff over ssl or is there some way to get this via javascript or something like to get the actual signature i don't know that i i don't know but then to me this is just like accentuated by people not running in browsers like even if this was the case if you're writing a cli implementation [Music] to be fair i actually expect that that is easier like like i think with curl or w get i think

you can probably quite easily get the signature i was ready i i would bet that's easier than in a browser possibly i don't know i'm just i'm but this is added complexity i'm not sure it's it's adding much and now we also need a mechanism for like a testing against the participant or whatever but i i i think the idea of you know testing to your participation if it goes bad i think is better so i'm not sure like i don't know i yeah okay so i guess we can say um yeah again this comes down to the trust model this will never come up

the coordinator is never going to do this so there's never going to be a reason for people to to to to to make this happen right i guess i guess the point is also uh we want we want to be able to claim that this didn't happen and then if someone said hey here is my file with a subgroup with the subgroup check with like invalid subgroup then uh then we want to be able to ask them hey yeah can you prove that it was asked can you prove that it was the sequencer right um yeah that's fair i also think that our trust assumption might not be fully justified because i heard that

coordinators might be other people than the ef yeah but they're still going to be trusted members of the community right but i mean the other risk is it might get hacked right i mean that's like i mean but i mean if like like the whole point of a coordinator is that you really don't have to trust it but you still don't have to trust it it's just what happens in the case when you don't trust it do you have certificates to prove it's not worth trusting or do you just have people you trust on twitter shouting about it yeah right right i agree and like now the key there's no key management and all sorts of stuff we're building into the

coordinator yeah i see no i mean i understand that the difficulty here i'm just thinking what the i i think it can practically be complex because practically the line where you trust someone on twitter and you don't just maybe not 100 um but yeah okay so i guess to summarize we're gonna do optimistic contributions and uh after the fact the user can

choose to perform a group chat or should we should you should still do it right so should instead of may perform a subgroup check yeah [Music] and if a user tries to say that the coordinator sent them a faulty sorry a low order point uh we just can't do anything about that we just have to see if the user's trusted and yeah okay yeah that makes sense i mean this is also compounded by the fact that to my knowledge we don't know any

uh bloater subgroups for for bls um probably yeah i should probably check up on that i think i was meant to do that i'm pretty well i'm not sure but i don't think it's a prime order group but i could be wrong guy okay i i mean i i sorry what's this guy just now what's the question i'm saying to my knowledge we don't know any low order uh bls subgroups um and then

i mean you can very quickly check that right i mean the the prime is small enough that you can you can for sure yeah sorry that's the number we can so we should be able to quickly check that is the question whether you can even attack it using the subgroup right yeah um [Music] right i guess

i guess there's no collision attack here right so it's really [Music] no actually i don't i'm not sure like yeah no i think it's i think it's a bit dodgy because it would still have at most like 64 bits of security or something so it's in this range where you're like uh it's possible yeah yeah i'm not saying it's a trust assumption we should rely on i'm just saying i yeah just many things stacked against us that

i don't think you could make a reasonable claim that this is not trustworthy but like we can't add this whole signature thing i'm like hugely against it right so i guess we'll just be open opening up ourselves to the possibility of a trusted person basically saying that the coordinator is uh malicious and the repercussions of that is that basically all of the contributions that were taken in by that coordinator could also would need to be thrown away i guess i mean they're not they're not you can't like you're not throwing away they're not useless

right but this person is trustworthy saying that the coordinator has been malicious so we don't really know yeah you just mock like assuming you you you trust this person then you just mark say it i don't know a third or however many that coordinator was involved in points as as as being being used as i mean you don't actually know how many bits of security were leaked because it depends on sort of what the the subgroup is right but even if you assume the worst case and that that adds no security you should still have lots of other points but i mean if people are worried about this we can add a signature it has it has lots it's quite smooth it's 3 times 11 squared times 100 10 177 squared

times a six digit number squared times a seven digit number squared uh eight digit number squared so yeah okay you can definitely get information from it um earlier statements retracted but i'll just write this down because i think this could be some way for someone reputable to possibly just invalidate coordinators uh the contributions made by a coordinator yeah um but you're you're saying that the way that we um the way that we sort of mitigate this is let's say downcredit is a coordinator

and uh trend as a coordinator if vitalik says thank great's been malicious then i'll just disregard the stuff that uh the code the contributions might be only there's only one coordinator no we're passing it around no yeah oh i see interesting yeah not not actively but there'll be like three coordinators over the period kind of thing oh is that really necessary yeah because it's an anti-censorship argument i don't think it like realistically it's not going to add much but it adds something uh well i think it's also good for this because if someone reputable says that this coordinate has been malicious then yeah yeah

and [Music] look i mean if if we want to add it we could like let's see um we could just add this as a like we could do this with the coordinators identified by bls signature because we already have bls in there all right i mean i guess we could just make it optional right because it seems something that can be done out of band yeah so can we stick we stick with we stick with optimistic um

and then in the case that it goes wrong you would have a fraud proof right what are you waiting for why would you have a fight proof well you can do optima i'm not saying optimistic but with this the signature oh i see we are adding the signature okay i'm saying i'm running through an idea here yeah by adding a sort of what are you what are you imposing extra work wise um and then so you um you opted you you run this and then you can do your own subgroup check and you can do it the like very slow multiplication way or whatever if you wrote your own library and then if that fails then you can go and call on a you you can implement pairings or

whatever to to verify that bls signature or something i don't know right so the coordinator always sends a signature of the thing he's sending and the the contributor doesn't need to implement the bls stuff he could just uh just ignore it if he wants to is that yeah yeah that that's that's sort of my argument and then we're not adding too much more in terms of requirements because most people will have some kind of bls verification in there right right if it's a may and not it should and i think it's fine okay yeah thank you

um yeah it does mean this is a separate sort of object that gets passed around but that's that's fine i guess it's just a blob it doesn't really matter i mean we say i'm always scared of saying those words like sure i agree with that but again like we still need to find encodings and like yeah technically it's true but it still needs to be specified and then implemented yeah yeah i mean i was saying i'm going to differentiate

between the like intermediate participation transcripts and the final output i mean i could make this further into the intermediate participation things such that this and i i can make that as a part of the distinction between these two file types right yeah i guess it's getting a lot more complex in practice uh than we wanted it to be yeah [Music] okay yeah i'll just write down what guys

just sign them [Music] yeah i guess just quickly refer asking jeff is this something we've seen in past ceremonies that like you you get a certificate that you can have a fraud proof against the uh yes yeah yeah [Music] but i think in past ceremonies they did

different types of um like signature schemes which is a bit complicated i saw something gpg and stuff like this yeah yeah okay cool written it down uh yes i think that's about it uh

yeah sorry for the sort of long i think trent was talking about uh next steps was it 35 minutes ago yeah we diverged uh quite a bit from that closing closing comments but that's okay um yeah i mean yeah i'm more than happy to stick around to hear discussion but it does remind me that we should try to have the these more discussions in the in the public channels which i'm assuming some of this is happening in private but just so there's context for anybody who's catching up in the future or just context for design decisions obviously we have this recording but

ideally it'd be happening in the public channel um we don't have to get into it now but i'm just remembering that there was this discussion around like bonding eth or something uh is this just a concept or something that people are interested in considering for this project i think i saw kev respond in there um oh all right sorry the person was mentioning that um basically like people gonna fear him can bond eve uh like a conviction to say that the ceremony was good

right yeah if somebody has um basically obtained tau then they can withdraw uh the if from whatever the contract that the bonded leaf is in um i think they rephrased it to be something like a bug bounty in that context i think it it sounds good like if you found something wrong with the trusted ceremony after the fact um i think it'd be reasonable to sort of pay you something if this could lead to the the towel being exposed in some meaningful way um i'm still not quite on board with the bonded eve

situation i think it introduces a bit more complexity than we'd need but the bug bounty seems reasonable it's completely independent right i mean anyone can could design such a smart contract so got it yeah yeah it'd not be directly related um to sort of the trusted ceremony but that doesn't matter like i mean anyone can just like once we have towers someone can just deploy a smart contract that that allows the payout of a bounty if you send a proof that you have found tau um yeah sure if it's not related to the

trusted ceremony in any way and we don't sort of need to do anything then i think it's fine if we can just we can we can just have it out there as a suggestion someone might do it and um and you can easily just anyone can just put ether into that contract yeah okay like it seems super simple agreed we can do it in a like have some do it independently i don't think we'll see it because there's just like what's your roi on this right yeah i don't think we should do it i don't think we should complicate things with something like that but i think like putting it out there for someone hey here's a cool little project um i think yeah yeah i mean i think just having having some some people publicly commit to a bug

bounty some far more meaningful and effective use of capital but yeah sure you mean rather than putting it into a contract yeah i don't know i mean people seem to have really uh enjoyed the little bounties that we put on our cryptography problems so i'm not sure like i i've always had good uh i mean possibly but given that given the value of the secret like to me the the mountaineer retrieve has to be very very large right and then i just like the capital inefficiency of having that all locked up in a smart contract seems insane to me but i could be wrong fair enough i mean that that is a that

is an argument yeah yeah like i just don't see this being meaningful but i again could be very wrong but [Music] okay so we can um we don't have to plan to include that in this ceremony but somebody could do it if they wanted cool thing about a smart contract is that it can be claimed anonymously like that someone like an amazon scissor admin who managed to like uh get the secret by breaking i don't know the coordinator could uh yeah i guess my argument there was that

i could just break ethereum first withdraw money and then go to the contract and then just withdraw more money i need to coordinate between the contract and the protocol right i see what you mean fair enough okay maybe maybe the contract is more interesting in the interim time between it being implemented on ethereum or it it being used extensively um sorry like before before that happens basically it could be interesting to have that out there but yeah i i guess the time between me done with the

ceremony and the launch of 0.44 yeah right i i agree that's hopefully short yeah exactly and i'd like to keep running this for as long as possible on the other hand uh there might still be several months until it is seriously used like the actual money you could get out of it in the first few months might be very very low [Music] it's up to l2 but yeah i mean i agree yeah all right now we're definitely divergent okay before adoption um okay so yeah we should probably wrap up the call now um is there anything any final comments i

think everybody is aware what what is going on and what they need to do um yeah anything else before we conclude okay um thank you everybody for showing up and having discussions um excited to get this into the audit finally and probably a couple weeks after that we'll start to see the first uh interface some of the wireframes and stuff so yeah exciting progress and yeah like i said let's try to put more

discussion in the public channels if we can um all right thanks everyone all right thanks everyone see you guys bye thank you bye