 Alright, welcome everyone and thanks to Barry and Ying Tong for the great introductions. So today I'm excited to tell you about this elliptic curve library we've been building in Halo 2. Okay, so first let me tell you what the library can do. So it's a Halo 2 library for doing various elliptic curve operations that in particular has a configurable trade-off between the proving time and verifier cost. So the operations we can support is that for a generic elliptic curve you have to put in a few constants, we can do addition, doubling, multi-scaler, multiplication. And then for pairing-friendly curves we can do optimal 8-pairing verification. And we can also do ECDSA signature check. So we've also put this library into the scroll and PSC aggregation circuits for the KZG backend of Halo 2. Okay, so before I tell you more, let me show you some numbers. So for ECDSA signature verification you can see that if we have a small proof size at the top, we have a longer prover time around 10 seconds, a little over. And then if we increase the proof size we're able to get things down to around 3 seconds on a MacBook Air. Weirdly we found that on the CPU the MacBook Air beats a fancy AWS box. For multi-scaler multiplication with 100 base points we can get things to around 56 seconds using larger proof size and as you can see that's still an improvement over the small proof size setting. And finally for pairing check on BN254, which is the curve on Ethereum, we can do that in about 15 seconds, again on the MacBook Air. Okay, so let me tell you how we build all of these circuits. So we have a very modular approach. So in Halo 2 you're allowed to use a lot of custom gates, but we're very simple-minded so we use a single custom gate. Our gate has four vertical cells and unfortunately I forgot to highlight them, but starting from the top our gate is just A plus B times C equals D. So in this example on the right if we want to compute a dot product of 1, 3 with 2, 4 we're first going to apply a gate on the top four cells so that will say 0 plus 1 times 2 equals 2. And then we're going to overlap it with a gate on the bottom four cells so that would say at 2 plus 3 times 4 equals 14. So this simple overlap optimization gains us about a 25% gain for all dot product operations which turn out to make up maybe 80% of all of the operations we do. So our setup is that we have a number of advice columns with this custom gate enabled. We have a single lookup table for range checks and then we have a bunch of selector columns. So we wrote a pseudo layout in Halo 2 which allows us to configure where these columns are placed in different regions. So as a configuration to our circuit we allow a fixed number of advice and fixed columns and we sort of tetris these vertical concatenations of our basic gates into the columns. On top of this we built a basic library called Halo 2 base of basic gadgets like inner product, range check, indexing into an array, doing various bitwise operations and doing comparisons on top of this gate and that allows us to almost completely abstract away the manual signing of cells that you may be familiar with if you've written some Halo 2. So on top of that we build our elliptic curve library mostly maybe 95% only using these abstractions. One thing to note is we found it's actually very difficult to outperform using this very simple gate using fancier custom gates. We tried a number of what we thought were very clever things that did not improve the proving speed. Finally I wanted to mention one very critical optimization that we made which is that we previously enabled lookup arguments on every single column and that was crucial in doing our range checks. We did one optimization to have special columns whose only purpose is to hold cells that are looked up and we copy all cells we want to look up to those columns. Although this sounds a bit trivial it actually reduces the proving time by about 50%. And again we can configure how many of these special lookup columns we need depending on the circuit. So just to show some plots on the results if we vary the number of columns as the number of columns grows the proof size grows and typically speaking the proving speed will increase. So you can see for the optimal 8-pairing for a single column setting the proving speed is about 250 seconds on the left and as we expand the number of columns to around 15 we get pretty sharp drops in the proving time but things sort of plateau after that. On the right you see a very similar phenomenon for ECDSA verification. We were a little bit surprised that things trail off at this small number of columns and we're sort of exploring whether there's something in the back end which could let us push it further. Alright finally I want to tell you how we plug this into the existing aggregation circuits. So if you have a KZG back end Halo 2 proof then to recursively verify the proof you need to do two things. First you need to do a bunch of multi scalar multiplication on the KZG commitments that comprise the proof. So these would be multi scalar multiplications on the BN254 curve. And secondly you need to do a pairing check. So in the current aggregation setup the pairing check is deferred meaning that in the aggregation circuits only the multi scalar multiplication is done. So our target was to integrate our library into the existing aggregation circuits. So to our knowledge there are two. One is out of PSE it's this Planck Verifier repo and one is out of scroll which is Halo 2 Snark aggregator. The way that both of these work is that there are various generic traits for an elliptic curve library that they use and they sort of abstractly write on top of these elliptic curve traits. So very nicely that allows us to plug our library into these aggregators simply by re-implementing all of these traits in our language. And again a nice feature is that both of these libraries are able to output EVM verification code for the final aggregated circuit. So here are the results so in a setting where we have seven advice columns and eight fix columns so of the advice columns six are standard columns with this basic gate enabled and one is a lookup column we're able to verify the actual ZKVM circuits recursively. So we just tried out the EVM opcode circuit and then the combination of the EVM and state opcode circuit and so even on a MacBook Air we're able to do the recursive aggregation of the EVM circuit in a little bit over you know around ten minutes. Note that the scroll and PSC numbers are not precisely comparable because we have slightly different versions of the state circuit inside. Unfortunately when we aggregate the EVM and state circuit together it exceeds the memory constraints of our MacBook Air but we'll try it on the server soon enough. Okay so that's it so in summary we have this library Halo 2 EZC we can support pretty much all the operations that we know of that you want to do on elliptic curves so some highlights would be the pairing check the ECDSA signature verification and the ability to configure the base curve without too much work and we really wanted to highlight that our base component library Halo 2 base which we open sourced this week which allows us to write these circuits in a much more modular and configurable way. Thanks and I'm happy to take any questions. Thanks E are there any questions? Okay I have a question so I am one of the authors of the Halo 2 library so if if you could change two things about Halo 2 what would they be? No more. If you ask me for two things the first thing would probably be and this might be very difficult to change so Halo 2 has a function called synthesize which constructs your circuit but the design of the library is that synthesize is called multiple times with different purposes and different interpretations of the input so when we're developing that's actually the biggest source of bugs because we sort of forget that on one of the times the mean semantic meaning of some of the inputs is a little bit different. I don't know how that would be pulled out but that's the biggest difficulty right now. Okay and also is there a question? No Halo 2 is a very low level API in the sense that you can configure really every detail about your circuit so have you found that to be more helpful or more annoying? We really like the configurability and that's why we're spending so much time in the Halo 2 ecosystem. Initially we found it very difficult to manage but the way we found to be productive in it is to sort of really restrict ourselves as you've seen here and then slowly add on more complexity almost as not really a pre-compiled is not the right word but just almost as a special addition to our library and then restrict ourselves to only work within this sort of constrained universe of the freedom that Halo 2 offers but the reason we like that freedom is that if we ever need something more fancy we know that we can sort of add it to our base components. Cool and my last question is what are you using Halo 2 ECC for? Yeah so we're building a new project called Axiom which is a Trusses indexer which allows you to take any facts a historic fact from Ethereum and prove it on chain for use in your smart contract. Cool thanksy.