KZG Ceremony Breakout #9

KZG Ceremony Breakout · 29 Sept 2022 · 1:06:00

KZG Ceremony Breakout #9, held on 29 September 2022. Researchers and developers working on the KZG ceremony, the trusted setup that EIP-4844 relies on, meet every two weeks on its progress. This call covers progress on the sequencer implementation and the interface, and preparation for Devcon.

Topics

From KZG Ceremony Breakout, hosted by Ethereum Foundation.

Transcript

welcome welcome everyone we can probably just get started um I get in the habit of awkward ifs where we wait like three minutes but this is a small enough group wow a lot of new people um let me just scan the names quick uh why don't we just start with the overview of where the people working on sequencer stuff have gotten um uh Remco slash Carl whichever you'd like to go there okay uh sure I could take it um so we've been

making good progress on the sequence third we have a test instance up and running and we're kind of implementing the final things I guess from my side the biggest missing thing is the entropy generation I actually know this is client-side stuff from the library the sequencer should be mostly done we're still doing a blst back-end implementation so we can easily switch between using artworks as a backhand and blst and then decide whichever we want to use in the production version or maybe even run both of them in parallel okay so yes that sounds pretty good any other people doing sequencer work

have an update or some other context they'd like to add so I think one important information is I've updated end-to-point documentation in sequencer specs but we still haven't finalized all of the fields that are coming in the requests and response bodies so if you're doing client work and want to interface with sequencer you should probably use the and the version is deployed to fly i o to make sure that the data that you're getting makes sense okay great I I just have a comment there

um on the front end part we are integrating it and everything is going good a the only thing that we were having some issues with the deployed version was the the redirect we need a you guys from the back end to authorize us um on on the domain to to redirect you right is that did I express myself correctly uh yeah I think this makes sense the redirect might actually be defaulted to localhost where it should be now also allowing the fly i o redirect uh I was uh I was responding about that

on telegram yesterday so the redirect us URL doesn't really matter because the front-end can make it whatever they want uh but Remco you need to uh you need to whitelist them in in the applications you have configured so the the application that you are running on GitHub and the one inside ethereum.org you need to whitelist all the URLs that the front-ends will be using yeah isn't this um problematic because this makes it closed um can we instead just whitelist the sequencer and then have the sequencer do another redirect to whatever the front end wants uh we could do that I was proposing that a few weeks back and then kept suggested

that we skip it for now but uh we can get back to this okay I don't think that's a part of any of the old flows I mean you can just rub the old flow so that it makes it's it's easier for the front ends to use because uh yeah if you want to be truly decentralized you probably want to have independent contents without needing to whitelist each of them uh no I mean like there's like specific oauth standard flows and I don't think that's one of them if you want to do like arbitrary front ends it's either a white listing them or you have to have the people running the front end on their Local Host no this is great this is like why we

need to um why we need to have an additional um redirect outside of oauth um to to circumvent this oauth limitation yeah I could like we can we can do that in app so the we got we got the Callback from the off provider to the app and then our app response very direct to the front end hey how I I don't understand how you do that because the the redirect needs to redirect back to like my client but everything is right okay I I try to prepare a proof of concept today and then let you know if it works I I have a good feeling about it it should work

uh I I probably suggest to look at the oau wolf um standard fluids that they have because they have like a lot of standards and they've sort of made things the way the way to this or I don't know about security if we're doing something outside of the standard I want to I want to plug in after all like I I off is already done and then I'm redirected exactly this digital not intact oh at all um okay maybe I need to look at the document uh yeah I think the main risk here is that you will be transferring the better doctrine that you got from GitHub or foreign

so this is something to consider sorry I didn't get that you'd be transferring to so so once you sign in with GitHub uh you receive a secret token right and by default it goes to the front-end app but now what what matching suggesting is that you go to sequencer and then that sequencer would forward that secret token uh back to the front and that's initiated the call uh so no this is the sequencer the sequencer can redirect with the session ID already so I can I can do the I can exchange the code for the token and then I can remember the token in the back end generate a session ID in the back end and then redirect to the front and

password parameters yeah yeah that makes sense um yeah maybe I need to see the document I'm not fully uh rocking how it exactly how it works at all right I'll try to build the proof of concept uh today or tomorrow tomorrow and then let you guys know in the diagram if it works and then you can take a look if you find it insecure in any way all right thank you um yeah on my end I was trying to test out the end points I couldn't get the flight.io version working I think I was getting an invalid CRF token uh so I was doing it offline instead

um I did just to make sure everything was interoperable I used the cryptography library at the sequence it was using and uh it seemed to be slow on the clay I think from what I was using I was doing ad entropy which is doing validation checks before the um the contributor added the entropy so I think they were sanity checks some of them are not in the spec uh like uh ensuring that all of the srs's are unique and there's another comment to say that the public Keys need to be distinct um I think some of these checks we did

say we were not going to include um and I think most of the checks anyways should be done after the contribution is done I think Call me may have made that optional in the specs if I remember it correctly yeah I mean just one second that sounds like you're talking about two things because those checks should never be performed on the front end anyway like if you're being passed a contribution file you don't have the information to do uniqueness checks you don't have the full transcript you do have some uniqueness checks you can do for example unless you're the very first contributor all the points should be distinct

um otherwise you're in some small order subgroup which you want to avoid all the points should be distinct relation to small the subgroup why um I mean I agree all the points should be distinct but that to me the subgroup checks cover the subgroup thing independently this is not a subgroup thing this is a let's say I make a Tau a root of unity of order of order let's say 256 then you get like a repeating pattern every 256. okay um great I'm so my question towards this is

um aren't all of this on all of these things covered by the subgroup checks and the structure checks that we do and they are not these are these are additional checks that are relatively cheap to do that do prevent some failure modes that are not otherwise covered and why um I mean this is just going the extra mile and we can remove it if you don't consider it necessary or otherwise dangerous but um what I'm doing is I'm just like I'm just taking the raw binary encoding of all the points and I just make sure that

all of them are distinct and what this for example covers that is not otherwise covered is that if Tau ends up being let's say some root of unity of small order um that would pass all the order checks but it would result in a repeating sequence of values in your ceremony instead of distinct values well only if all the participants do it yeah correct and like I said it's not particularly important to do this um but I mean any participant who like I mean there are many ways in which I can add no entropy right I can do it by just setting my secret equals one I can do it

by setting it equal to a root of unity um or I can do it by choosing it randomly by publishing it and which one of these is it it is doesn't matter at all so the only thing you're protecting is is against possible implementation Falls that generate the root of unity which seems I don't know I agree um this is why we are not protecting it against dishonest participants because these are those participants have other ways in being dissolved I don't care about that I I agree these these checks are not there to um guard against any particularly

sophisticated attack they're more sanity attacks that guard against um stupid mistakes so to say uh or implements just to be clear there's only there's only helps the very first participant because after that even if someone chooses root of unity that their group elements will still be different I mean you could do something you could have two participants colluding and like one multiplies by a random factor and the other multiplies by the inverse um there are tricks around that but you know but I mean as soon as it's getting

into extreme scenarios as soon as you have had one properly random contribution you agree that it should be impossible to make it a repeating sequence after that I agree okay very low value in my opinion if this is something you're worried about I think we should check it on the sequencer side sure um well actually no I think the sequencer does that it adds absolutely nothing for the sequencer here no like I you could still be the first honest participant and please basically leak some information there how

like if I mean if if you use a root of unity then you are not uh not an honest participant um so the people in front of you use roots of unity and then you add on the first valid contribution on top of that that doesn't matter that doesn't harm you your current your contribution is still perfectly valid yeah yours is better yeah no I agree I agree I'm not seeing I'm not seeing the value here this adds nothing in my opinion yeah um okay it also costs very little I I see this more as assertions things you know that should pass and um should they

not pass you're very happy that your application crashed crashed instead of proceeding come on uh yeah I guess I wrote them up just because uh when sorry when the code gets audited there might ask why is there a difference between uh what's implemented and what the specs uh specify okay um right uh from reading it is it also correct to say that uh before adding entropy the the contributor validates the SRS as well

um in what sense we do something new subgroups subgroup checks yes I think uh was this Benchmark because for me on the clients like taking quite a long time to validate um all of it uh that your use is that using the crypto lip uh yeah I try to basically use the same lip as the sequencer so um gotcha I just did not add entropy yes it um the subgroup check is about half the time consumed uh it uses the endomorphism optimization so it's decently efficient I think blsd is a bit

faster here um so when we have the working blsd back end that might be preferred by clients although we haven't done a proper Benchmark yet in in a multi-threaded awesome environment uh oh no I'm so I'm implementing uh Clay did you have any numbers for Clive because um maybe my numbers are just off right it should be it should be any order of one or two seconds uh okay and maybe something else with my setup what are you what are you experiencing because you seem to not be happy at the

timing heck have what numbers are you seeing um I haven't sort of benchmarked specific numbers but they were like noticeable I could say like five maybe seven seconds so I think maybe if something's off on my setup all I do for all the contributions running running natively yeah exactly I just called this um yeah yeah that's longer than expected um yes I need to debug what's happened and uh there uh Hardware difference yeah could be actually I'm running an

Intel Mac um eight core Intel I9 foreign yeah I need to debug what's happening there yeah strange did you did you get substantially better performance with the uh with your own powers of Tao lip uh yeah but I wasn't doing any subgroup checks uh up front okay now just those are expensive um that could explain the difference but without the subject checks I was getting one set like maybe one or two seconds I was expecting maybe like three three seconds maybe with

subgroup checks if there's some optimization being applied but I haven't looked deep enough to say anything else which yeah um can I ask one more question about the sanity checks so no one I thought would be useful is checking that all the pop keys of the individual contributions aren't I think which I don't think is currently part of the spec right I think I brought this up as well and uh I think me and Dan Kratz said we was on Telegram and it was agreed to not do this

um okay because it's just an over Edge case sorry Remco your audio cut out what was the last word you're checking for public keys oh okay checking that the puppies are distincts to just catch implementers that use the same Tower point in each sub-ceremony which seems like a obvious front-end mistake um and catching that might help build better front ends yes this was a discussion we had earlier it was less in the context of front-end mistakes but more on doing it like maliciously and then it was argued that that's no different from just leaking your secret um and also they're like more complicated ways such that like combining multiple contributions could

add up to being the same for one contribution etc etc but as a way of catching people this might be something worth adding to the sequencer as and as you're saying hardening front ends oh wait I Carl I think we did say to not put it in um yes to not put it in yeah okay um but I'm saying I'm saying like as a way of hardening front ends I could see the argument for it yeah maybe um maybe we can leave these enabled um for the test version while people are developing and then just remove them for the production version or for the audit yeah

yeah that makes sense um just to make sure implementations aren't accidentally not being compliant um you know I mean if we just specify a particular error message on that like that gets returned there then we can just include in the specs and make a canonical too that doesn't seem like an extreme thing to do um actually uh ramker could you clarify um you're checking for distinct public keys in a certain contribution and not in uh sort of the whole of the transcript

right honestly my Approach here has been values need to be distinct unless I can come up with an argument why they should um so like all all G2 points in the whole ceremony and transcript file need to be distinct unless the um they're not demands otherwise that's that's kind of my Approach towards these energy checks it's basically like taking it from the other direction but yeah in this in this particular case um it catches a number of things like for example the uh the roots of unity um or like cosets thereof um but also

um uh so you know of course that's not work anyway um but also um contributing the same Tau value um in all four contributions which to me seems like a common like plausible mistake a front end could do or having an algebraic relationship somehow between them right um I guess it's sort of hard to catch all of the edge cases and you can sort of do like what if um for the transcript I don't know I think that would probably be something we should skip just because that's uh it goes linearly with the number of

contributions but for a particular contribution hey I wouldn't see a reason why not to check yeah I think like again I don't think room crackery it makes sense at some level and we should see uniqueness here but um it's sort of hard to argue for this as being good standard Behavior if it's not in the specs and it seems a bit weird to specify okay um yeah I can just jump in I think the um generally given we have a high profile demo in a couple weeks I'd

rather leave any other changes out for now and just get to the simplest working interface with sequencer that we can and then I think post Devcon we should have like a week or two just to tighten everything up and get it ready for the public reveal and then maybe we can add anything else uh at that point but for now I think we should probably limit any other last mile things though it though it is appreciated Remco um sure now it can be um can be disabled I can I can see two ways forward here so definitely disable in production I can feature flag it in Rust and just have the code be uh disabled

for the production person or do you prefer to have it actually physically removed um just so it's obvious for Auditors or whatever I think probably removed uh just less code um if it's not going to be used in production unless someone else thinks it should sleep but yeah I'm on the remove train okay yeah sorry back to what Trent said uh so back on this double Eve sign-in thing that's not going to be included in the

um the demo is that correct um I haven't actually implemented it in the clay or looked into implementing it the double signing thing or the eighth sign the double signing series oh sorry yeah you mean the um where you sign your contribution through with the ethereum address okay exactly and then you sign the ethereum address with your with your well one of your titles um I mean I guess this is up to everyone here implementing whether something they think they can do

um I have the specs of 99 complete I'll put them out by end of today um basically on the one side it's a um eip712 signature shout out dremco um of the um the four public keys that you're using and the other way around they're just uh um a BLS signature of your identity which is just uh either eth appended to your name or GitHub appended to your GitHub address it's the the I've got some argumentation as to why we only basically there's only a double signature for

um the eth stuff and for GitHub it doesn't really matter so in terms of implementation it's uh just being able to to sign and verify each signatures plus the BLS stuff uh BLS signature should already be in the BLS libraries people are using um the one complexity here being for the sequencer whether um we can find a decent hash the Curve implementation for artworks either just copying the copying hash the curve out of blast or something like that or using one of these other implementations particularly if it's running in parallel that seems

okay um but that becomes a bit more complicated than for the wasn't blob what are we doing for Azure curve there and then the other side is the um the ecdsa signatures but most web free apis slash Json apis should offer sign type data by now the exception here being web3.js but I see that the the ZK party front end is using uh ethers so I think we should be all right on that front

so I guess I opened this for comments to the floor right but for Dev component seems like there's probably not enough time to include this double signing um like it probably be a bit of a stretch to get everything done with the double signing what needs to be done um doesn't need to be implemented in the sequencer and also the client the front end I think Nicholas has started on this I think sequencer and we move really

fast um that should yeah that should not be a concern so on the sequencer side assuming you can get around the hashtag thing um and you guys are doing the awesome stuff as well so the hashtag things on your side there too um the changes should just be calling like two extra API calls that's fairly simple on the um I guess there's more effort on the front-end side um again it's two API calls so that's relatively simple it's uh I guess just incorporating it into the user flow as one extra step but the logic is very simple here

[Music] wrong to implement that um but we we were considering that you call was was that the question sorry uh yeah kind of just just like what's if if is there something you think you that that could be done in time um I guess you don't you don't know the specs so it's hard to see but assuming it's like three lines of of code or five lines of code in terms of like spec logic um is is there something that we could see done by Devcon because I think it would be really nice

um I I think we can do it on okay so regarding the the front end we have all the entropy input interaction that is Charlie's doing a really nice animation work a I am I already have the contribution like I am using the rust code uh using a router so if everything changed from the original code I can simply reuse it right a and on the integration part it's almost finished I am just uploading the the contribution and trying to check that everything went smoothly right so I think we can do it yeah we have two weeks for them right

yes yeah two weeks and I'm happy to blend a hand making sure that this is easy to do for everyone under this particular implementation thing okay I think the question would be what what we have to do with this information and how is it going to be handled if it's just some Json that we we download and suggest the user keep it for future reference uh that's that's not a big deal so it's it's not it's not even that um the basically what it is is you take either the user's GitHub handle or the um their ethereum address

uh feed into a function which gives you the byte encoding of that like the the standardized byte encoding and then call a function that requests a signature from the user's wallet which exists in in ethos so yeah and then that gets added basically into the the contribution file um yeah so that the work here is more just that it's a an extra step that's sort of like after entropy generation but before you

start uh uh like before you start pinging the coordinator to try contribute that you need to get an extra uh ecdsa signature from the user uh an ethereum signature from the user okay any other comments on this double signing I think we're good

foreign I'll push the specs probably two two or so hours after this call um and uh we can we can have a discussion I'm happy to help run people through it see what whatever like wherever the pain points are that kind of thing and uh hopefully we can we can make a final call by the end of today but then I'm gonna operate under the assumption that this is not too difficult to implement and therefore we can do it sounds good yeah sounds good to me as well thank you

do any of the I mean we sort of segued into it naturally but anybody working on the interface want to bring up question comments or anything that's come up in the work that they've done so far so that's Charlie Nicholas Jeff um takamichi Now's the Time if you guys want to bring anything up oh yeah so um yeah so uh takamichi has been working on that on implementing uh design as as design change has gone through uh nick uh has been working on the um bosom stuff as he mentioned

question about the wasm if we end up with uh uh blft version should should we be looking to use that or uh at the moment we're implementing kids code um uh and and when we do include the subgroup checks it does add quite a bit to the time so should we um and we haven't got a good feeling for how that's going to pan out at the moment you haven't done all the checks to see if the multi-threading is yeah working properly and everything but um

uh still we'd be looking are we happy sticking with that or should we look to the blst um so the checks should be done after the contribution is um sent off so the timing for it shouldn't uh necessarily be counted um for the blst uh it's possible to just add it as a dependency to the rust code just for the hash to carve part um so it's not too bad to just include it that part in what's the advantage of doing the

subgroup check after contribution why should it happen after um the argument here is it's basically optimistic contribution so that in terms of the queue processing speed uh it doesn't get added as in you you already upload the file once you've contributed without having done the subgroup checks and because the sequencer is signing everything you can chat about it after the fact that signed messages from the sequencer if they sent you something where the subgroup checks don't pass so we could then be checking the

contribute like the initial values you received are the ones where you added towel I mean if you if you generated your your Randomness correctly then it shouldn't matter foreign it's a like it feels like a slightly weird thing to do but because like a because we're trusting the sequencer not to try screw with everyone and B if you do be managed to pick up something here that means something dramatic has gone wrong um and we have a like authenticated way of proving this happened with the the signature from the the

sequencer then that seems yeah this was deemed acceptable makes sense um yeah I'm just wondering if if adding Tau by itself doesn't Force the points out of the subgroup does it I don't know I don't think so enough in an elliptic curve math do you have the answer here right here sorry what is the question like if if you multiply a point by some random number and this point has uh is a part of a load a subgroup was a lot of subgroup component mixed in

um is it still does it still have that low order subgroup component in there and my answer is yes you think no yeah if it has the low order subgroup and then you multiply it by a point that's a multiple of the low order subgroup sorry what are what are we doing are we are we are we talking about so Omega how many guys in the water um field element right and we have omega times G and now we take a random number R and

compute R times Omega times d is that what we're talking about that was my yeah that is definitely not in the lower subgroup right it would just get rid of it since I mean otherwise yeah I mean G itself isn't lower like subgroup it's one right that's a lower subgroup of order one G yes the generator no it's not yeah it is one one as a field element is a low order subgroup I thought there was a prime order

subgroup oh you're talking about the additive group I'm talking about the multiplicative group okay so what okay so you're talking about the difference well that then there is no law like the the additively there's no law of that subgroup because we're we're working in a prime field right I think the Assumption was that the was that you added a low order component to some prime order um element yeah basically you make you you mixing in something from outside the uh so you're talking about your point that is not in not in gy yes

all right yes it is it is on the Curve uh well yes yeah yeah so okay right well yeah I mean that depends on your definition of the curve I mean it's not on it's not on G1 it's not a G1 I agree with that solution to the elliptic curve equations yes yes okay uh right yeah so so here if you mix in a random Point you're still going to get basically this the output is going to be slow composite of yeah the slow order component and the field component yeah you you can multiply by the cofactor to get rid of that

yeah I know that's like right yeah yeah as long as it doesn't need to be the perfect there just needs to be a multiple of whatever the order is right but you don't know what the law order is okay if it's like I mean assuming that this is controlled by the attacker then you just have to right your stucco Factor oh sorry is this about the sequence they're trying to find out uh some bits of your entropy yeah okay I'm saying yes apparently Remco saying no so if if you say no then

what's the I'm saying this is this is about whether um it changes anything if we move the subgroup check on the contributor side to after adding the new Tau value but what it is the reason what it are scenarios what it would give a different outcome for the subgroup check oh okay yeah sure oh I see well I mean what I would do is I would I would still check it on the inputs but still do it after the contribution and if the sequencer has cheated like I'm assuming the is the message signed of like the yeah that's the whole point that's the reason basically yeah you

have proof that the sequence uh cheated yeah yeah so the question is is this still acceptable if we do it after you've multiplied I guess the other reason it's important is to be able to prove to this to other people uh that there isn't it before is to prove it to other people you need the message that the sequence are sent to you because that's what signs the secret show that didn't send it to you with your entropy mixed in and presumably you've deleted your entropy at this point yeah I would I would but what's the reason for for doing it with your contribution rather than the input just too files to keep track of okay but I mean I was saying like we're running out of storage here or what like

I mean like just store just store it and then do the check that seems trivial right I agree with you yeah I would I mean I would just do it on the original first it's signed so we need to do it on the original and second um there's a small chance that your contribution might erase the like for example your contribution could be a multiple of 32 or something and that yeah so it's possible that you are in the subgroup that you cancel the sub proof right sorry low order but foreign I don't think the messages are all signed only the receipt as far

as I know we also removed the signing on the ID token that we used to send it was automatically signed by JWT but that's been removed but wait what was that wasn't the sequence of doing eth signing of messages understood things yeah yes we can eat signed messages and it's trivial to add a couple more signatures on responses if you need them okay I'm not saying it's not done right now okay um in that case can we add a signature to the um the the Json message basically that gets sent the the contribution file yeah

great uh that might change the API of course because now we have a signature field to add right um yeah and as I said we also removed the signature on the ID token I guess issued I don't know if it's a massive problem with double sign being implemented but I haven't checked completely what's what's the the attack vector or what what's the scenario imagining here so usually once you do the oauth the sequencer gets back your GitHub ID and then he sends it back to the client

uh with a couple other information and that used to be signed whereas now that's not signed so the sequencer could just say like you're consent because like collude of two people and say you're vitalik or something and then yeah that's mainly the attack director you can just basically say I didn't send you the GitHub ID vitalik but it does no it's not over uh it was just that the ID token was signed but I'm thinking through the attack vector and I think that because they send the receipt it doesn't matter

because they have to sign a receipt at the end I mean I can always lie about having authenticated a user without them unless I'm doing some action that like unless I'm I'm posting something on your GitHub account I can always say that I authenticated you I don't know how how would you define defend against it it's just an ID right like it's a string that I can make up always you can always lie but before it was signed is what I was saying what's the difference well if you're assigning your lives I could say that you lied if you're just not signing your lies then you could say it wasn't me you sent it to you but

like back to the original I think it doesn't matter because the receipts are signed so once you contribute I sign your receipt which includes the ID token so it doesn't matter actually still on Martian side here I'm not seeing like what what what what the value is that the ID is a random string so there's no way of like authenticating it after the fact oops an authenticating verifying it after the fact uh you're not all friends you're basically it's basically the sequence of saying that this is the the GitHub ID of

Kev and this is the one that he he authenticated with yes but I can I can always do this like I I don't think you can defend against it except you can look through the transcript and see there is an entry that that you didn't create so this gets into the a bit of like my argument for the the whole double

signing thing and I was arguing against doing it or I argue against doing it for GitHub um basically with your identity you just trust the coordinator not to have lied with your identity there and if they do we can chat about it right but in this in the GitHub case still because we signed a receipts which include the ID token uh you can at least hold the sequencer accountable uh yeah sure this is an additional way of holding them accountable I guess um yeah so that's why it's not that's

why you don't need to sign the original ID token because it's signed in the receipt um I mean yeah that and like if you are signing the like if you BLS sign your identity your your GitHub ID then that's tied to to your address anyway right like when you put it out in the transcript it'll be obvious right but yeah as you're saying it's in the receipt as well it's like in several places yeah I'm not like I'm not seeing an attack Factor

right right yeah like at the end of the day we're only going to know this once the full transcript is out right or whatever incremental transcripts we output before then yeah come over here um yeah I did have a few comments on some sequence of stuff but I think we can probably do it async since they don't affect most people um and it was mostly UI

um basically integrating the front end with the sequencer uh just some endpoints that would uh disinvigorate sort of what the front end gets so yeah okay yeah if you want to write that up for the interface people to check on that'd be good uh Charlie do you want to do a quick demo I think we'll be talking sorry yes I can meet you okay yeah thank you um yeah up to you takamichi on my side um

I've been working on a sort of a some adjustments to the interface so it's just has a little bit of a different graphic style and so this won't show that um uh so it's on me to get that done ASAP and properly transferred over to the interface team but uh takamichi if if you want to do a demo now that that'd be fine or any other interface comments if you'd like to bring them up now yeah um can you hear me yes oh okay so I can show some quick demo now and um actually it's not

um complete yet so but for now it it can um sign in and uh contribute to contribute to the sequencer calculate calculating the contribution using the Watson web worker so for that part I can show the the quick demo right sure yeah okay now let me share oops can you allowed to to share my screen

okay oops look oh does it still not allow you to or I mean it asked me to to turn on my video um how about that I made you co-host yes all right so here is a the front end um of the the ceremony trust is set up yep here is a landing page and it has um uh descriptions of the trust is set up and there's a if AQ

section here and some footer yep and it's and um so here is a design in page and once you click the sign name for the ethereum um can you see the key pop-up of the assignment ethereum no I'm okay um maybe I need to share the whole screen yeah yeah okay right can you see the yes okay so once you just click the sign in with the

ethereum button um this pop-up will show and you can proceed by assign sign indeed the old provider yeah then the entropy input page uh shows and as you can see here is the progress board that um they capture the mouse Movement Like This and also here's a some problem but and once the the progress uh are complete you can enter to the lobby and

um now so your screen is still not showing up for me it still says it has started screen sharing but it's not showing up oh I really I can see it it might be oh no now I can see it Okay so now it automatically um pulling the the try contribution um API endpoint and once it gets um accepted um it automatically start calculating the contribution uh backend uh I mean the in the washroom webworker then this is going to take a while so maybe we can uh I can stop here

but yeah after this finished and uh posting to the the sequencer endpoint uh yeah that contribution is done great um I have a question was the e623 in the top right hand side the session ID yes uh yeah I need to I need to um fetch the user data from the old provider but yeah for now I am recording yes yes yeah you should get it back from the sequencer um uh yeah like the authentication uh

endpoint right and they give you back an ID token which includes the GitHub uh like there's a something called a nickname for affirm it's the firm address and for GitHub it's the GitHub user ID thank you yeah thanks for sharing thank you yep great yeah um echoing that uh it's nice to see feels like 90 we're almost there um which is great given how close we are are there any big blockers or challenges

you're having implementing stuff it that haven't been brought up yet um I think there's not that big blocker for now um yeah but I I need to modify I needed to modify some uh sequencer code like adding some course layer to the Axiom or the the disabled right limiting the body size of the the API or something like that but it's I think it's not that program and yeah everything is going fine I think okay

great if you need um help or you're falling behind just say it sooner rather than later so that we can find some more people to help you or any anybody on the interface team um yeah yeah thank you could you pay me about the rate limit disabling that you did um I saw that you used an experiment dress which looked like it was new so I'm guessing you also disabled the validation checks um okay is that correct um because I had to disable the validation checks for new accounts um the error that was coming up oh um

uh actually what I meant was uh the the body size limit of the post um uh requests so it's it's um not about the the limiting The Ether others from the same ethernet address okay yeah sorry I brought up two two two issues and just skipped over so for the first one the rate limit uh could you ping me about that okay and then Freddie for your address I I think you used a new one which means that you disabled the ethereum validation right and um sequencer card no for for the sequencer I I'm

um uh resetting the database uh every time I try so okay all right thank you yeah uh also it would be it would be great if you could open GitHub issues or write on telegram or in any other way let us know that there are problems you are facing with the sequencer um because my assumption was no nobody is actually testing this now it turns out that people are testing it and just not letting us know about the issues that they cut which is not optimal okay I will thank you yeah sorry about that I was sort of um collecting them uh they didn't they immersed the UI issues like if you use

the newer Freedom address when you call the Eve get transaction it gives a error and then that error propagates up to like could not fetch user data um which might not be beneficial for the front end yeah I agree so yeah open a GitHub issue or a request but if if you actually fixed it um would be great to to have it working please so the issues who gets found all right we are at time really quickly um given given how close we are to Defcon

um I think it might make sense to have another call next week just optional I mean these are all optional but uh if people want to show up and hopefully we'll have a demo by then or we can do this the same type of demo next week same time uh and that would be good just to continue ironing out any issues that come up um I'll go first but over the next few days really I'm gonna be really pushing hard on any of the interface updates to get them to uh the people working on that as soon as possible so they can make the modifications um anybody else have some pressing concerns other than like

getting stuff done uh in preparation for this demo if anybody wants to say what they're going to be working on now would be the time so I I don't I I'm pretty sure I haven't met most of you uh guys but um I did an implementation of both the sequencer and a client uh for each Prague and I would like to do at least the client part for the real ceremony as well I've been just trying to go through the specs

uh the the open API ones um and there's a lot of stuff missing or kind of weird in it um are you going to update uh those or should I just look into the implementation and see what the others uh using it should be the uh Mars there was a fairly big change where we switched from a queue to a Lobby might be one of the larger things which makes it look like some of the endpoints got deleted it was quite a simplification yeah no no that's fine it's it's just that

um some endpoints like data types yeah like the data types are not really uh specified or some endpoints lack the data types that I would suspect um so for example the the uh ceremony status uh it's just not specified yes that is correct um I think this is also but because there was Debaters to what should be included in that um but uh yeah I don't I don't know if uh

uh the sequence of people have a have a comment on that uh I would just say once once again write it in a GitHub issue or in either the specs repo or in the uh in the sequencer repo and then we can if you find any discrepancy between between the documentation and the actual Behavior we will reconcile it by changing one of them it would just be good to have have a list of what doesn't work for you yes I I don't have a link to the sequencer issue can you put that in to the sequencer GitHub I think this is a something that needs

to be added to this specs uh the open API um yeah added the status but I didn't add it into the specs um so the specs needs to be modified yeah no you're you're correct here Mars that's a that's a great um in general there's this other repo which has got links to everything else you should need to find uh Marius um but the two replays you have now should be sufficient that's that's a really good thing thank you Marius the other work you've done at eat proc uh public somewhere and can you share links just um uh I'll put a link in chat

thank you awesome it was the towers of power Reaper written in go okay I don't know if you've seen that ram car this was yeah I think I did actually yeah all right so it sounds like yeah there's still uh still some work to be done um like I said we'll plan to meet again next week even though it's uh usually every two weeks we'll meet again next week and everybody will probably continue with the the regular async coms uh over the next few days in the Discord telegram Etc

uh this is I'm pretty confident this is coming together and um we do have a slot so I just for context uh the Devcon slot is on the main stage the opening ceremonies um there are three speakers and we are just before vitalik so this is going to be very high profile very visible and hopefully get a lot of people exposed to what we've been working on for the past few months and um you know it'll be nice to have the work visible by so many people in the ethereum community on such a high profile place so um great work everybody so far we are at the the last stretch before the public sees this and then

um you know it's going to be really exciting I'm I'm pretty stoked um so I was talking with Carl and I think if we can make it happen if you're in Bogota while we're doing this presentation we'd be happy to have you on the stage logistic issues um assuming we can we can work it out but it would be really cool to have people on stage um that worked on this so that's where I'll leave it we're a couple minutes over thanks everybody for sticking around and uh we'll see you next week all right bye bye bye bye bye