KZG Ceremony Breakout #3

Transcript

welcome everybody to the third kcg ceremony call um this is a call where we are discussing the kcg ceremony for uh preparing the wafer tank sharp protodank sharding and future scaling of ethereum so hopefully you're in the right place if you're attending this call this is a bi-weekly call meaning every two weeks for updates in general progress uh from the people who are working on it specifically i've been working with carl on sort of organizing the approach getting people to uh work on things ahead of time we want to get this done by the end of the year

kicked off before the end of the year and that includes a bunch of things so we're gonna go through what those specific things are um if you have any questions i guess people can jump in and ask them in the chat or wherever they they'd like to ask them uh so the first thing that's i think new from this week is the timeline and uh i'll share it in the chat carl do you want to talk about that and we met with maddie yesterday to go over this and a couple other things yeah so this is basically what i was presenting last week i don't have transit the link uh but yeah basically last week i

mentioned some timelines of roughly where i'd like things to happen um and this is just sort of that that explained out um in in yeah in in in visual and written form um [Music] and uh yeah hopefully that's just for everyone to sort of agree on and or complain about slash contribute to whatever uh based on what you think is and isn't reasonable on there um the audits are of course sort of fixed dates on this so that's the one limitation we we have on on these things um but yeah that's that's pretty sure i saw you on mute jeff did you want to jump in

uh no just checking my um microphone oh okay all right no worries just wanted to check yeah the other thing or i guess next on the agenda is uh website interface so we want to start getting the ethereum.org team to allocate some of their their time their resources towards this as well if we're going to have them do an interface jeff i know you've worked on some of these in the past is there any standard

things that somebody implementing the website would need to know about or is this sort of you know you approach it on a situational ad hoc basis each project is different um i'm curious your thoughts because we i wanna i wanna start putting something together that they can look at and know what to expect oh yeah so um so it's pretty uh pretty pretty bog standard um website um so um [Music] yeah um i thought when we were talking about ethereum.org we were talking about the website that would like display the history and the results

uh rather than the the website that actually serves the interface so are we talking about both oh in my in my mind it was the website serving the interface where people participate from but i guess we would also we would need both um were you imagining that somebody else would take care of the the actual contribution interface or is that something you were thinking of doing um the the user interface stuff what we normally do with that is um we host we put up the hosting for the um yeah yeah yeah for for all of that and then hosted on a sub domain

of you know the project that's running it um so in that case we'll you know it could be like kzg.etherium.org whatever we choose um and then it's just re it's it's directed to our our servers um uh there's there's quite a bit of setup in service yeah especially at the moment we've got google firebase and it's fairly complicated like it's easier to to leave it where it is and just redirect i i think what what was more the

question here is like who's doing the the the dev on the site itself but it sounds like the idea here would be then that you're doing that am i correct oh yeah yes um the the dev work yeah i've i'm we're assembling a team so i'll have a few helpers in the coming weeks to do that kind of thing okay um cool so uh the the if if if you need help from the ethereum or team they're they're more

than happy to help this is a sort of kind of project that they'd be happy to do um but uh they are like again it's less from the sort of like devops management side and more of just actually having having a code base but uh that's i guess uniform or uses the sort of common ideas that they've been going through and uh ideally we'll include some translations of that kind of thing down the line um but yeah yeah we see this as part of an ongoing sort of development effort for the for the pse team to have

trusted setups to cater for all sorts of situations and this is this is one um you know one particular situation that we can draw build on what we've already got and we can build stuff that we want to uh carry on in the future for different kinds of setups you know plonk or phase two or whatever um so that's where we're coming from that's why we're putting a team together okay cool um all right okay if you're talking about uh js sdk do you mind elaborating a little bit on that

uh yeah sure sorry saying that um does it make sense for basically so if someone creates a rust client and uh maybe a client in c plus plus uh they both convert them to wasm and then there is a common javascript sdk that [Music] that connects to the wasm and then like jeff's website could connect to the sdk and then he knows what what methods are available and maybe the ethereum website could connect to the sdk and they know what methods are available so they so the front end sort of can be agnostic to whatever is happening

yeah i really like that idea that sounds like a an api that sits in the middle between the uh like the user interface and the computation code was right right right exactly yeah i thought thought about doing that it'd be cool in some ways yeah i mean there's really not much computation to be done outside of that sdk so like basically the sdk would look like the

the specs i've written just with the default like defining what that interface looks like and then you can you can put whatever you want around that right um the only thing that would probably need to be defined somewhere is um so these web workers maybe the sdk doesn't even need to worry about uh web workers um i'm not familiar enough with what deployed was on blobs too to comment on that but [Music] yeah

yeah i guess it's just a detail so it doesn't matter for the overall idea [Music] like i ideally the sdk wouldn't have to be aware of this but it might be useful to be something to to be have it be something that the sdk could like define i don't know okay um yeah i think it's um it's quite a good idea and that the sdk could could have something in it to uh or it could create the web workers for

potentially create web workers and just hand it over and over individual sections and it does the job of dividing them up um i think all of this is kind of lower priority than actually getting a primary api set up when you say primary api you you mean between the coordinator and yes okay yeah agreed but what what it would mean is if we define this this sdk then there's sort of a uh what it means to implement it is if you if you're doing a browser

implementation plug something into the the sdk and sort of map that onto the api and you're done pretty much yeah it'd be quite easy yeah which is appealing [Music] so is this this is an additional mini project within this larger thing that we're doing and who would be working on this if we decide to do it uh yeah i guess that's in my um

[Music] my area um yeah yeah it's kind of like a mini project yeah it's a good way of putting it yeah i'm happy to help working on that but i'm not familiar enough with web workers to make intelligent decisions uh on that so uh yeah definitely need some help maybe it's possible that you don't need to define the web workers um and it's sort of the sd it's just done implicitly so like if you have two different sdks one of them could be doing it single threadedly as long as it exposes the right methods i guess

so what what would be the normal way of sort of splitting this up amongst workers would you like chunk up the that you do like dude how many workers would you would you spin up for for a job like this you ask the hardware and it tells you how many threads it's got and that's the number you use okay and and the normal way would be uh the red well like with rust and rayon it sorts it all out so the

the sdk would just be handing over the whole job to it okay but yeah but that's one that's their approach other other approaches yeah other software uses different approaches but it's safe to assume then that we can like it can be implicit uh yeah and we can just leave it up to the sdk to decide all right so then it's basically just a the the this interface is basically one function then it's just defining how we pass this information across that's it

[Music] yeah there's there's there's sort of one call and then what whatever async stuff that comes back and that's it yes okay would would we need to put in the oauth stuff in the sdk or is that no i don't know that would be api side yep right yeah it's basically just that json file that needs to be passed across the the transcript file sorry ceremony file called it yes and and leave it up to that to the

was incurred to derive the entropy ah that is a good point i think we should pass in the entropy i think so yeah okay so there's a there's a debate to be had here uh passing in the entropy i think would be like less secure because there's just now more places which touch the the secret yeah um but that's a trade-off against things like allowing the user to keyboard smash or whatever to to to to feed in this entropy are you suggesting that the entropy is

uh created outside of the sdk and then you pass it in yeah [Music] right yeah i guess that's fine [Music] i think that i'd have to check on uh wasm's host functions because uh because wasn't the sandbox yeah i assume that sort of if you pass in a host function and the randomness is done inside of the wasm it might be easier to clear all copies of it but i'm not 100 sure on that i think either way it works uh it's it's it's easy to pass the function

in into wasm and that runs javascript and it's but it's probably just easiest to um derive the actual entropy and pass the password across right yeah i mean otherwise we can also just make this we can have two options here right this can be sort of the two different apis or an optional an optional thing yeah yeah i i think i like call your idea better because then i believe the sdk is deterministic

so it's a bit easier to test it i mean i i think in general there's a lot of understanding to be done on how we um zero eyes everything on the the memory side here and uh i guess now the sdk is included in something we need to worry about from that perspective [Music] i don't know if if your standard like crates or whatever for doing this how that gets handled once it gets compiled into awesome uh there are zero rise crates but

as far as i know you sort of don't have any strong guarantees uh sort of the compiler can do anything at once or yeah just copy copy just uh secrets whenever wherever it wants to so um yeah just hope for the best i guess okay um okay well i guess this is also fun stuff to to help that that we can have a look at in the order time to like make sure stuff that that's been done around the secrets is sensible and if not try a different approach yeah as a last resort yeah okay uh then let's go for now i think we're trying to pass in the secret

um so one of the other options that got touched upon now was uh the the the primary api um and uh yeah so i've done a fair bit more digging into uh some some of the options um and uh yeah i'm still not an amqp fan um they're like there aren't stable implementations in many languages like rust included for example um and i'm just not convinced that it's like the complexity is is is worth it uh particularly if we can shorten contribution times down to low

enough numbers [Music] yeah yeah fair enough comment carl um i've been putting it together and thinking about how look there's a pure rest api uh and taking some inspiration from from marius's api yeah [Music] yeah it's it's mapping a a uh asynchronous process onto a synchronous call but yeah it does does make the calls simpler like those in the api i i certainly agree that in some like if you're only writing one implementation

or it was the sort of perfect world we can achieve pi throughput by having a much nicer queuing system by using websockets or amqp or whatever um but i just the the simplicity of a restful api really appeals to me and from the standpoint um yeah yeah yeah so so um i've i've i've been putting together a draft of that api spec on that basis and it looks like it's it's going to be feasible yeah fantastic uh do you do you have a place you're working on that you can share either publicly or privately um so you can yeah uh

yeah sure um uh i'll i'll put something in the telegram chat probably tomorrow fantastic thanks [Music] um like on that i've been thinking about like a little bit on how to make sure that like the the the pits we take for this the skewing system aren't too bad then based on like switching to a a restful api um and to me the main thing here is that the the time slots for when you are going to participate participate become fixed so you will register in the queue you get some token back

but then after that it's there is no fixed point in the future a time where you will participate and we can't sort of move that up or down very easily um and so i've been trying to think about like how like hey what does that mean and how do we minimize mitigate the the downsides of that um so one idea i had is that we could allow a parameter which is how long you request your time slot to be so if you're going to attempt to do this single threaded or you've written your own implementation that's got some pretty slow bls library then you can request a longer time slot and then for the sort of like primary implementation that everyone's going to be using the the one jeff's working on uh we can uh

we can just make that we can set that to a more reasonable number based based on how long it seems to to allow participants so we can have say like timeout is 30 seconds up to 2 minutes or something and you can request that when you request your slot um the other idea i had is that we are we could be quite strict on when you arrive so if you've registered in the queue and you're saying like five seconds late or something then you'll you lose your slot and someone else can if they request proquest to slot in the queue they could immediately slot in at that point i mean these are just some of the ideas i've had trying to

minimize the effects of the sort of static queue [Music] yeah i thought we'd um a couple of points there um there will be a lot of variation in the computation time even with even with any particular implementation because people have different number of threads in their machines people have different some people be running on a laptop some on a powerful desktop whatever and just an update i have i do have multi-threading running with wasm

um and i ran it on a desk desktop which has um a fairly recent process toronto nate threads uh and it got down to like 25 seconds the competition time which was not as great an improvement as i was expecting like on a single threaded it was just over a minute um but yeah there's going to be lots of variation um so um yeah so the i was thinking along the lines of um

the client checks in and then progressively checks in to assert that they're alive at increasingly increasing intervals towards the time that they're expected to run and then the server kind of coordinates or the coordinator tracks the progress and the number that are currently in the queue and it can give a better estimation on each each time they check in as to whether what time that will their time they're expected to run and then and then when it's kind of five seconds out it'll say okay are you alive

yes i am okay let's go okay so the that's that's an interesting idea uh i think it's a the philosophical difference between that approach and what i was thinking along the lines is not to say one's more correct or whatever just that so you might understand correctly your idea is to sort of have a cue that's where your position is important like where you are in that queue and then we we keep updating the time versus a thing where there's a fixed time that you you're going to be participating in which was more what i was proposing [Music] um so your solution is definitely better

from a having a high throughput in terms of number of participants per time unit [Music] at the cost of complexity [Music] [Music] yeah yeah so the the the the thing i'm always trying to optimize for is like a person writing their own implementation here and i worry that the timing requirements are a little bit difficult to get to get right if you're doing your own

implementation particularly if we don't have like a server you can test with to make sure that your your timing is good [Music] oh yeah so i wouldn't be too precise on the timing it's just like a deadline where if you don't check in by that time you're assumed to be no longer alive and um [Music] it's going to be generous well yeah okay so yeah um [Music] [Music] yeah but the trouble is always you don't

this coordinator doesn't know doesn't know they're alive and unless they're unless there's some sort of active communication so if you're just expecting them to show up at a given time then a certain percentage will have shut down and left and just won't show up so then you have to take some sort of corrective action to uh you know allow them time to to show up or else to just abandon and go on to the next next person but if that person's not expected to show up until it until a certain time slot which would be

later then you're going to waste that time [Music] i guess for [Music] my you definitely waste that time um but like in terms of complexity of implementing this it's a lot simpler you don't have to worry about like a whole complicated timing mechanism it's just wait until like you you get a one time that you have to run it for and you can just put an infinite for loop before you so in an infinite loop before your code that just checks against whether the current time is like wall time is greater or less than your participation time kind of thing it's it's very simple versus having multiple times you need a check in that

[Music] oh it's really just one loop it checks checks in there's a request gets it gets the next check in time okay yeah set the timer for that time and repeats yeah i guess that's all right it's a little more complex yeah yeah yeah no i agreed all right i i've been to okay i'd be interested to see what what your your api looks like and uh i think let's let's discuss it a bit then async i hadn't thought about this approach and maybe it's not as bad as

as i think [Music] but yeah okay uh just on a side note jeff you briefly mentioned that you got 25 seconds um i think this is about twice of what i got on my laptop so maybe we need to um sort of have standard hardware specs so that the benchmarks can be normalized um i'm also wondering if how you did the multi-threading part i used i think comlink library that might sort of be a reason for the variants as

well multi-threading i used uh rayon and and uh just left it i need to decide what to do where does the commonly come into it javascript [Music] it constructs the javascript for me oh i believe there's another step um i remember doing another step where i had to uh install a library called

comlink then i loaded the wasm code and then it was multi-threaded or at least it was at least the web workers were being called efficiently but it just didn't work in safari yeah yeah i found it didn't work in mozilla um but it's definitely multi-threading it just doesn't seem to be very efficient [Music] and yeah it's working progress we can figure it work on that yeah yeah um i do yeah i do still think maybe we need standard hardware specs in order to analyze the benchmarks um i don't know what then those are to

be honest like the normal computer that will be contributing like maybe four gigabytes four gigabytes ram or something i don't know yeah i think that sounds reasonable i think like one of the problems is like ram speeds vary a lot and like just just defining sort of ram and cpu like doesn't normalize all that much unless we get very specific about exactly what combination we're using um i mean it like if if if it helps we can

try set up a server somewhere that we use as our common test bench for for for these kinds of things like some standard instance that we could try use yeah that would be probably good like some aws instance that we can roughly get what the upper bound will be on the ceremony okay um i can i can reach out to our devops team to see if we can we can organize something like that for us yeah sure i could just figure out if you just like tell me what the instance we should use then i can do it on my end as well yeah probably a medium yeah something like that

jeff does that work for you as well uh yeah yeah that'd be fine but i think in the real world we're going to have a lot of variations you know benchmarks are going to be it's going to be a widespread from yeah agreed yeah i think this is less to set an expectation of exactly how long it will take but more just to have a common reference frame for talking about participation rates and that kind of thing yeah sure okay um [Music] that sounds good um

do we want to jump to the next the next item on the agenda yeah one thing i wanted to ask jeff is you said there are a couple people from pse that would be helping you with the interface um should they at what point should they start coming to these calls or should we start interfacing with them um like getting the design ready making sure it's plugging incorrectly stuff like that oh yeah well um i'm getting one guys starting in a week or so but i i really just want to start him off by um uh i'll have a bunch of github issues and we'll work on it together so i don't

know i think if they need to be on the call straight away but down the track we'll get them involved okay so i'll just check in on that next week then or sorry two weeks before the next call yeah um next thing on the agenda is that i know the spec has been circulated to a small group of people but um carl do you want to give an update on like where it's at and what we need to do between now and the the audit in uh september um so

i mean a few there are a few things there one is uh like the like we needed to find this api uh which which jeff was was talking about uh the the one he's working on and i'd like to get that then integrated into into these specs um and now also include this this sdk um and then yeah the the obviously between now and audit then is obviously implementations which would be the uh the big thing that needs to be done on top of that um the specs themselves i mean like it sort of just defines the the computation that needs to be done and i think that's that's

fairly stable as to [Music] uh what what what needs to be done there so like this can be shared and people can work on it or whatever that's that's all good got it yeah um i'm pretty you've probably done this with with some people already but is there anybody that you want to put it in front of that hasn't seen it yet just to review it um he's thinking like it'd be better to do that get that out like check that box earlier rather than later and then we can yeah uh not think of anyone off the top of my head now but i'll do some thinking and put on people's desks this week that's a

good idea sure um yeah and then you mentioned the implementations which is one of the next things um so for the audit are we going which implementation are we going to be focusing on it will it be tess or a different one so the first order is just targeted at the the quote-unquote computation so it would be from what we're now calling the sdk like sort of in and out of that that sdk uh the first script i thought the first one was related to the cryptography side of things yeah but that's basically the snow sigma prime was the all the other bits that plug into it yeah but the sdk basically defines what

happens at the quote unquote cryptography level got it okay so um i mean it it sort of depends on where we are benchmark wise i'm not like i'm unsure is how to compare the the stuff kevin's been doing versus jeff's thing in part due to not having a common like common device we're testing on [Music] and also like what checks are being performed when etc etc but i mean that the sort of foster of those two implementations would be the one i think we should we should reach out to audit okay um does picking

do we need to make a decision now on which implementation we use or can they both be i mean i think it sounds like what we're working towards is something where any implementation can be swapped in um is that true or am i mistaken yeah that would be the idea okay and then the the benefit of that is hey we can swap it out if at runtime or whatever if if if there are issues or preferences and b we can just choose whichever one is looking stronger at the time to to order it at the first order so i think mine and jeff's implementation are essentially the same apart from like a bit of javascript code

if i understood correctly uh just like javascript code that calls the the wasn't part uh we both sort of rely on the rust library now okay well then i guess that's the that's the underwater tip then okay that's good to know [Music] anything else to add here about the implementations cab or jeff [Music] no sounds good all right um has anybody been in touch with the circum people about updating the library

i haven't played anything [Music] yeah i think last i heard was that they could do it there was interest and maybe some availability but i didn't have any idea of what their timelines are and whether those match up with ours and whether we need to put some resources on that specifically if they can't do it yeah and also now that the scope's a bit better defined whether they're still interested right yeah any thoughts on this carl or kev i haven't heard from them but

um i'm wondering if we do need them uh [Music] i guess it doesn't seem like we currently need them they're not blocking anything than yeah i'm also agreeing with that so it's that we don't need it now or that we won't need this library to be updated that we won't need this library unless we're looking for a second crypto implementation oh okay so that's good we're reducing the scope of things we need to worry about yeah i love it

um and if they if they do want to do it later if they do decide this is something i want to get involved in they can then quote unquote implement this sdk and that would be fine okay and so what changed between two weeks ago and this week when we were we we thought we needed to update this library and now we don't need it uh before uh i believe jeff was connecting his frontend to uh the circom code but now he connects to the rust code yeah yes that's right the the snap js was was

working was multi-threading uh we could have we could have run with that if we were going to if we wanted to get going in like in two weeks or a month or something but we've got a bit more time to play with we've got some some good progress on the rust side so that's much less important that we have snap chairs as well okay that's great um and we already touched on the implementations yeah go ahead uh pretty imp uh so i noticed the specs were using a python code do we need the python reference

implementation um i can add one if it helps and i guess it will allow us to do things like differential fuzzing so i can sort of implement the sdk in in python if it helps um but the the specs being in python are just sort of because that seems to be the way we do things these days as in like all the ethereum consensus and execution specs of now being written in python right okay okay yeah i was just wondering that makes sense then and do we need a reference implementation or so i i guess that question is is is back

when used would you like a reference implementation uh i was thinking about sort of the it'd be admin to be quite nice but then i thought that what if everyone just copies the reference implementation and doesn't look at the specs uh so i don't know it would i guess should be nice so the the the the way we can do it is base is what we've done for the rest of the specs uh there is like the consensus specs or whatever is that the uh the specs themselves are the reference implementation so there's a script that sort of pulls out all the python blobs and turns that into um and into executable code right

and this is something that media asked about as well yeah whether it was executable is is this like a nice to have or something it's what we were looking to do already it's certainly a nice to have um and i wasn't exactly planning on doing it mostly because i was feeling lazy at touching those terrifying scripts for for for turning the the specs into executable stuff but uh it sounds like it's something that people really would like um and it certainly would help and allow us to write test cases more easily and do differential fuzzing so [Music] i'm more keen with that particularly if we have an sdk defined that really allows us to have uh very nice interfaces so sure i will

do that i'll make my specs executable thank you priority uh right now i guess but i was just wondering yeah no agree it's not uber top priority but doing it now seems seems like a good idea fantastic let's let's do it cool this does also mean if if socom wants to join the party later with an implementation they could more easily compare to what we have etc etc okay right yeah we've reached the end of the

the things i had on the list uh is there anything that we missed before i go into like what people are gonna be working over the next two weeks um i have some topics i'd like to chat about if other people don't have anything they want to touch on first because they might be easy to derail slash extend discussions i guess the only thing i was going to mention i i sent it to you in chat carl but generally i think it'd be better if we try to move more of these conversations you guys are probably having one-on-one into the public kcg ceremony chat just so other people can if they're if they're catching up you know after a month or so of checking out

of this project it'll be much easier for them to understand why decisions were made in certain ways obviously not every thing has to be public but if you're [Music] trying to make a decision about something think about putting it in the public channel i think that would be helpful long term for anybody not coming out of these calls regularly agreed um particularly haven't been good with that i've been trying to as of yesterday improved that a little bit so um like i've opened issues on my specs repo for discussions kind of things on on apis or the point i was raising earlier on optimistic uh contributions etc etc so yeah between

the chat and hopefully issues we should have a better history of this and agree that's something that that i'd like to do awesome yeah and then i guess really quick before we jump into what you were going to talk about is just let's get just a quick one or two sentence summary of what people are going to be working on the next two weeks kevin if you want to start yeah um yeah so i was it was sort of related to what you just said um i was reading the specs and i thought that it would be good to have this i think carl mentioned that last time

user another repo which holds all the rationale while the specs reaper mainly this is for implementers on how to implement it um some of the stuff i think might not be intuitive as to why we're doing uh certain things so i was looking to sort of copy some stuff over from the notes into this new uh repro or if it's not being made already okay cool if carl did you have any thoughts on

that or whatever we need um i think you're not doing it on a separate repo and having it be sort of uh attached hack empty slash not ethereum nodes um and if it's more explaining how to implement things or whatever then we can we can actually put included in the repo itself i'm i'm i'm fine with that as long as it's in a separate section um [Music] but uh yeah no actually i i think i prefer to do it that way otherwise i think it's a little bit hard to track across multiple repos exactly what's happening yeah sure um so just put it in a hack md for the rationale uh yeah i mean i i guess it depends on

what level it is if it's like a this is why we made these decisions then it should be in the the hackmd but if it's a this is why you might want to implement it this way then i think it should be just in the specs themselves right okay yeah i was more thinking the latter's and uh this is why you need to do this check uh and stuff like that yeah i i think we should just include those on the specs themselves okay cool it'll be slightly less elegant it'll have a little bit of extra files lying around but uh i yeah i just think it's easier than having multiple repos and that a hack empty it might be a bit complicated for that okay sure

yeah and we can always change this decision further down the line yeah yeah sure uh yes yes i'll be looking into doing that uh it mainly will just be like a copy and paste and refactor and stuff i did in the notes that initially was there yep got it carl uh yeah sure so i guess i'm gonna be uh working on defining that sdk and trying to make the uh the specs implementable um and also uh reviewing slash commenting slash trying to make final decisions on the

api which jeff said he'd be he'd be sharing cool yeah and yeah so i'll um i'll continue on those specs i'll i'll announce a um url where people can find find find them as i'm working on them um and yeah there's quite a bit of work to be done in those specs and i'll get together some uh this just to start implementing

the apis okay how are people feeling generally with the timeline and where we need to get to um i mean it's it's mid-july crypto the audit is scheduled for oh did i read this wrong is it august or september oh looks like mid-august yeah that's when we have the the secret uh booking right um are we still on track for that like are we gonna have a crunch time in the

last two weeks how do people feel it all feels pretty pretty comfortable to me okay that's good i think i'd be a bit more comfortable if we had uh something like what marius had to something uh during the ceremony very quickly and then sort of wreath refactoring that uh just have everything up so i don't know i'm sort of in the middle like if we have a ceremony running with um what we like just a ceremony running that we can tear down and keep pulling up the refactor stuff okay would be quite nice

yeah good point kev i can i can actually release my um my my test site so people can play with it and that'd be good too because we'd see what sort of variation yeah yeah that'd be really cool yeah i mean no note for all the things here that's the the the first implementation is just of the crypto side of things so sdk input to sdk output right right so the it's like the the work that needs to be done on this front

is is sort of limited to mostly now defining this interface and and kept kept stuff there okay yeah that makes sense um because i i just wasn't comfortable assuming we'd have a robust enough uh like end-to-end implementation for for these first audits but uh maybe i'm wrong in that yeah i'm not sure because then the sort of order to the full system would be based on discussions with sigma prime um yesterday yeah the the order of the full system would be at the end of october

right i was going to bring that up they had actually offered to that they had a slot open up in september but carl um doesn't feel like we'll be ready for that in time um but yeah there was a chance that we had been we may have been able to move it up to mid-september right uh yeah i think that was a good decision i think had we given them something that it wouldn't have been complete so it would have been like try ordered this but they're one or two things we're still trying to fix and like some of the feedback they would have given us would have been obvious feedback because we we were aware of these weaker points whereas now we can

have a more code more solid code base we present to them right right uh the other thing which came to mind while we were talking is should we in the next maybe in the next two weeks for the two weeks to follow that um somebody else to come and do a check-in like danny or dankerad or somebody who can just give who hasn't been engaged in this so far just to check in on the progress and uh maybe we do a bit of a presentation to them um would that be useful or is it just creating unnecessary work um i guess i'm so i'm pretty far outside of

the development side of things so i'm would be curious what you guys think about if this would be helpful or not see if we're missing anything um things like that i think it would be helpful at some time i don't know if the next two weeks would be the perfect time for it but [Music] so yeah yeah i think it would be definitely really helpful to do it at some time but i don't know sort of if the next two weeks will be then the perfect time for it

yeah i share those opinions okay um so then i guess we'll just the next thing to prepare for is just the uh getting ready for that audit in august okay yeah that's that's it for me carl you had some topics sorry i took up uh i took up most of those last 10 minutes no all good is everyone uh fine to to chat a little bit for on on to run over time a little bit to discuss these topics uh if not just drop out that's that's fine [Music] and so one of the things i wanted to talk about was um my

black optimistic contribution idea so basically save the subgroup checks till after you've already returned the file to the coordinator um as a means of speeding things up uh i mean it doesn't change anything from like a security standpoint but it might change things from an optics standpoint i don't know if anyone has read that idea slash had any thoughts on that or would like me to explain what explain it yeah so um so yeah it's going to speed things up on the client side but the coordinator is always

going to be passing on the last validate it's going to do its own validation and only accepting yeah only the valid contributions will be in the chain right yes so it doesn't change anything for the coordinator it the the basically there's the attack kobe presented was basically using a uh low order group elements to like basically extract some information about the secret and to check this there we either need to do subgroup checks or

a pairing check with some extra assumptions on the pairing um but this just adds computation time so if we remove those those checks or do those checks after the fact then this basically means that the participant could be tricked by the coordinator into leaking some small amount of information about their secret assuming that the coordinator pulls off this malicious attack with low order elements which we don't know yeah and and uh can we assume that it's going to be quite rare well it it should never fail this test ever so as far to my understanding we don't

know any low order elements for 4bls or for this curve and so like assuming that's true it's not even possible and even if it is it would require a malicious coordinator so to me this this check is more just about like showing me doing the right thing than anything else yeah i guess it's on the assumption that you have a honest coordinator um the worst case uh for skipping the checks like these is just that a few bits of the secret

key is leaked um in that worst case if it ever happens uh i guess the person could retry or yeah so my idea here is that you don't attest to like this being your contribution so you still perform those checks you just do it after you've returned the uh the updated transcript to the coordinator and then yes you you would you would re-participate at a later date slash shout about it or whatever but as it's like as i said like i don't even think it's possible to do this because we don't know any low order elements for bls and requires a malicious coordinator um

uh right i'd have to double check the bls part uh about the low orders they order points but yeah the malicious coordinator yeah if we can assume that uh the coordinators will just be by ethereum tonight is that is that a correct assumption yeah so it's going to be run by sort of trusted community members uh because the coordinator always has the ability to censor you so there's there's some level of trust here anyway yeah yeah i think this is a good idea then um just do it after um yeah

and yeah so i think what you said is a good idea so you only attest if the subgroup checks pass so you optimistically assume everything is correct um yeah yeah yeah i think that's a good idea then you can sort of do the full subgroup check because it doesn't um hold up the ceremony exactly yeah okay yeah [Music] i mean as you say not entirely sure about the that my my my claims about law to be a less stuff i'm also not entirely convinced i've asked around and people seem to think this is the case but no one's yeah but yes um

i'll operate under the assumption that this is a good idea for now and implement that because obviously affects the sdk yeah i think it's a good idea we should probably put in the rationale if there are low order um points how much uh how many bits are actually leaked to the coordinator just in case but if if it's what you said there is no there are no actual um low order points then yeah we can just remove it all together um i mean that my mind decides there are no known ones but i think we should perform the checks anyway certainly from an optic standpoint [Music] and in case like what happens if five

years down the line we do find something now do we trust it or whatever um and then the second thing is i off the top of my head i think it's 2.2 bits the that that could be leaked i'm not entirely sure on that [Music] right so the group order would be um it'd be roughly two two times yeah i guess even even the group orders basically even two times some prime number i guess yeah i i i must double check it's my head is roughly two right okay yeah that makes sense

so i mean like even then it's not a dramatic issue but yes let's all go in the rationale this is this is exactly the kind of thing we should we should be explaining right uh yeah i think that's a good idea even if i mean as long as it's like less than i guess eight this is the worst case and it should be fine i mean if it just leaks the whole private key then that would be a really bad situation i know that's not the case yeah turns out the subgroup is minute i can count the elements on one hand exactly [Laughter] okay okay

yeah i think it's a good idea this will probably speed up speed up a lot of things as well um yeah okay i'm liking this i'm liking this um i'll then implement that and then the other thing i was wanting to check so one of the ideas i had was i was worried about the file getting too large after some of the discussions we had with uh marius doing some back the envelope calculations last week um but i'm no longer convinced that's the case so i was going to propose having a sort of truncated ceremony so truncated transcript where you don't receive all of the sort of intermediate numbers we don't send all the intermediate to pub keys as i've been calling them through to the uh the participants

but if we assume say 100 000 participants then the file is 22 megs mods which i don't think is unreasonable so i don't actually understand why we need to send the intermediate um oh wait sorry we need to send the pub keys of every are you saying we need to send the pub keys of everybody who's participated so i was going to propose not doing that because we do currently but then my thought is like is it is it worth the effort so like just the just the uh the piles of tile sort of comes up to to

seven and a half megs right and then like if we have say as i said a hundred thousand participants we'll never have a hundred thousand participants but if we do that's then a 22 meg file so the the delta there's not too large if we have ten thousand participants which i'd be ecstatic if we reached then the files nine megs so you picked up one and a half megs of sort of fluff and i'm not sure it's worth sort of making the distinction between truncated and non-truncated versions of it uh yeah i was also i was also under the assumption that you don't need to send those because as a participant uh you receive some srs you contribute to it you give your witness and then

you don't really care about the previous contributions you can check that sort of after the fact assuming that the ceremony the coordinators trusted it's like you just need to make sure that the thing you're contributing you're contributing to something valid yeah a valid srs um yeah so yeah in that case we wouldn't need to send the previous um pub keys [Music] yeah so i mean i i agree with that statement it's not necessary but like if if

if for ten thousand participants the the overhead is ten percent then like is it worth like making that distinction it also means that like it would be easier to verify that everyone's that you're like other people being included before you whatever based on the transcript you receive at the time um but then couldn't the coordinator just send you a bunch of random pub keys and then say you know these are different people who have who have participated yeah that's that's always possible yeah okay i agree it doesn't add it doesn't add anything right right okay

um jeff do you have any thoughts on sort of an extra overhead of say 1.5 megs to the file on top of the seven and a half meg five yeah i think you're right it doesn't it doesn't make any significant difference okay like if that i agree if the file was massive then then absolutely but for this amount i don't think it's worth it um okay then one of the other the other ideas i've been having is and i'm not sure about it is so what if the like so if you're testing to something that's basically saying that

uh you think this is your your contribution um but multiple people could claim the same contribution which could potentially like cast out on things so we could sort of do the inverse and have the contribution sign some of your own information so like we use the the secret to create a bls signature over some message that you want which could be your ethereum address or whatever um and so then in the transcript would be a reverse link uh do people think this would be a worthwhile thing to have so the problem that's being solved is if

i contribute and then you sort of say that that's that my contribution was yours so now two people are claiming um so it's a bit of a weird one because like if like someone else who didn't participate he's looking at the list of contributors and they trust like kevin then like that should be it it doesn't matter if someone else claimed they they participated right but it does and it does allow for another weird case which is where like you could pretend to be someone else so you could like the the message you you signed in the transcript could be like metallic on

ether now that appears multiple times and like it creates some confusion there it's like it doesn't add anything but the reverse link does allow like if if both links exist then we could have like an extra verified tick or something like that right um [Music] i think battalic asked this question before um somewhere and the idea was that sort of if someone's lying then you can't really trust them to even of participated correctly in the first place yeah um so i don't know i feel like it might add extra complexity without making it without like any extra security being

added but uh i'd like to see what sort of vitalik and bankrupt think about that okay um i will sort of re-raise that with them and get some input from from them i i do but if i remember correctly i think a lot of other previous trusted ceremonies did include a signature i remember somewhere that there's been places where we added a signature like what's that okay like what i suggested i've seen lots of like a quote-unquote like with just the forward link but not sort of the what i'm calling the backing the the ceremony pointing at you [Music]

all right okay yeah yeah yeah yeah i don't think i've seen that actually another new clarified yeah yeah yeah i'd probably raise it with vitalik and bankrupt i'm not i don't have any sort of strong opinions it just seems like it might not add any extra security but it definitely doesn't add any extra security but does sort of allow us to be very sure on who participated where right and that's like what you said they sort of put in i'm vitalik uh everyone just says i'm vitalik yeah yeah okay yeah yeah like it doesn't change like in in that

case it's all just malicious participants uh with dishonest participants which doesn't change the security assumption but might change the optics on oh now one person's participated multiple times like do they have all the keys kind of thing right um so i don't know if it changes the security because maybe i participate properly and then i put in like some a random input and i'll just start trolling people and say you know i'm metallic i'm vitalik so i'm still yeah yeah exactly [Music] okay i'll write it up properly and uh as a github issue and get people to to contribute right yeah that'd be great thank you

very much yep um yeah i think that's that's all that i uh that i wanted to discuss uh yeah all right i think we can wrap up thanks guys yeah thanks everyone okay thanks everyone bye thank you talking two weeks yep soon bye