 So today, there are three parts. In the first part, I will talk about some concepts for modularized proof system. And in the second part, I will talk about how we are choosing proof system for our ZK ROPs. And finally, I will conclude with some practical considerations when you are choosing this proof system. So now, let's start with the modularized proof system. So when you want to generate proof for some computation, the first thing you need to do is that you need to do some optimization. So basically, normally, people call that surrogate. But more formal words are called constraint system. And there are many different ways for the circular organization to give you some example, for example, in R1-CS. So assume that you have a huge circuit and you put all the wires as variables, and you lay out that as a vector, like from, like it should be W1 to Wn. And then you lay out that all the witness as a vector. So the form of R1-CS is that you can define the linear combination of those, the vectors of your witness times the linear combination equal to a linear combination. So that's a form for one constraint in R1-CS. So for example, you can access any of those witness cells like using this linear combination. But the limitation is that you can only have one multiplication. So it's very good for some programs. For example, if you have multiple, like, large linear combinations, but with a few, like, multiplication. And so this is one example, like, if you want to access cell like omega 1, omega 2, and omega n minus 2. And another example is that you can basically access any witness cells using this R1-CS. So this is, like, the form of R1-CS. Another commonly used optimization is called puncture optimization. Basically, what you can do is that you are not lay out all your witness as a vector. But inside, you lay out your witness in a table. Like, for example, you have, like, three rows. And then, like, what you can define is that you can define something which is more flagrable. Like, for example, you can define a degree 3 constraints. Like, for example, you access some cells, and then you define those as a very specialized gates or specialized custom constraints. And another thing you can define is that you can define some membership relationship. For example, this tuple belongs to, like, two columns in the table. So using this, you can do, like, range proof really efficiently. For example, you can have a fit column, and you believe that you prove that this element belongs to that table. So that's another thing you can define. And the third thing you can define is some permutation. Like, you define, like, some cells are equal. And so why this is useful? Because that, in the first custom gate, when you are defining, after defining multiple gates, you need to connect them together. So you need this permutation to, like, for example, define the first gate's output equal to the second base's input. So those are three constraints you can define in a puncture optimization. So it's custom gate, lookup, and permutation. So from the modularized perspective, there are three, like, commonly used front-end. One is RNCS, as I mentioned, which relies on linear combination. And second is Planckish, which relies on custom gates, lookup, and permutation. And third is IR, which is usually in stark. It basically contains, like, transition constraint, which is very similar to custom gates, but only access two rows. And also some boundary constraints for, like, defining your starting point. So that's the front-end for a proof system. And after you get this constraint system, when you need to get a really implementable proofing system, like, in practice, you also need to pass it through an informational theoretical compiler. So what does this mean? So this compiler will define some, like, interaction model between a Pura and a Wi-Fi. So in this information theoretical compiler, you only define how the Pura and the Wi-Fi are interacting. And assuming that there is some oracle where you can, for example, Pura sends a message to some oracle, and then Wi-Fi can, like, later query from this oracle. So there are nothing, like, concrete, for example, what kind of commitment you are using. So you just send some message to the oracle, oracle, and the Wi-Fi can query. So that's what happened in this information theoretical compiler. And so this is an example for interaction oracle proof. And the short form is IOP. And another example, which is commonly used, is called polynomial IOP, which the message is in the form of a polynomial. Like, for example, you use P1x to represent your message. And then, like, what the Wi-Fi can do is that during the query stage, it can query at a random point to get this evaluation. And you also do some interaction between the Pura and the Wi-Fi. You can do multiple rounds, like, for example, there is a constant round polynomial IOP, which, for example, Planck is using that. Like, Marlin is using that. A lot of, like, a lot of proof system with stings of verification are using this constant round polynomial IOP. And then after you get this IOP to make that really practical, you also need some cryptographic compiler to compare down to an argument, which can be implemented in practice. So I will give you an example. So in this polynomial IOP, like, model, one pre-cryptographic compiler, you can do that. Because it's interactive, and you need Wi-Fi to send a challenge every time to the prover. So what you can do is that you can initiate this challenge model using some fair Shamia, and you just hush the transcript as the next round's challenge. So that's one thing you can do. And another thing is that when you are, because there is still a, like, magical oracle there where you are sending this polynomial to, and the Wi-Fi can query from, right? So you need to initiate what's happening here. So you initiate the concrete polynomial coming scheme to replace this oracle. So for example, there is a KDJ, and there is Frybase, there is Dory, there is Dark, there is many polynomial committance scheme. So you just use those schemes to come into a polynomial, and later open at a random point. So that's, you know, after those stages, you finally get your protocol. So just as a summary, for commonly used zero-node proof system, you have front-end, and you have back-end. So on the front-end, you have RNCS, Plankish, and Air. And on the back-end, you usually use polynomial, IOP plus a polynomial committance scheme. And a quick summary for the advantage between those different front-ends, so RNCS is really good for linear combination. Like one thing there, I'm specifically talking about Glow 16, because for example, your Mardin, or Spartan, or some other back-end which also supports RNCS, it's totally different because the complexity actually lies on the velocity for your matrix, so which is different for evaluating the efficiency. And it's also more general because each constraint can access any witness cell, like you do linear combination for that. You don't need permutation because all the witness are already in layout to a vector. And the Plankish and Air stuff is more useful for some uniform circuits. So uniform circuits are basically you have repeated structure, and you can define one custom case for those repeated structure. You just need to increase the length of your execution trace and to really efficiently prove that. And it's also more customized, for example, you can have lookup, you can have variable components. So that's the front-end difference. And on the back-end, what really influence your concrete property is that the polynomial convenience scheme you are using. For example, it will influence your tracery setup, whether you will have that and some security assumption. And I will give some example later. And also influence your concrete prove efficiency because like for example, if you are operating over group operation, it's less efficient than some scale operation. And also proof size and the verify efficiency. And some commonly used polynomial convenience for game is KDG, fly-based, and some inner-product argument which is derived from bulletproof. And another called multi-linear PCS. So for KDG, if you initiate your proof system with KDG, then you have universal setup, you have D-LOG security assumption, and the proof is relatively slow, but it's easy to parallel because it's mostly doing some multi-scale multiplication. And the verifier only needs to do pairing and the proof size is really small. And for fly-based, you don't need tracery setup and it's based on hush. You use the Merkel tree and the resultant code to commute to a polynomial. But the tricky thing here is that when you are really using fly-in practice, you also have some other parameter choice which will influence your practical security assumption. And the proof is mostly doing hushes and FFTs and the verifier is doing hushes and it has really large proof. But there are some improvements from, for example, Plunky 2 which can make the proof really easy to do recursion. And for the inner-product argument, it doesn't have setup because it's derived from bulletproof and it has D-LOG assumption and the proof and verifier are both doing multi-scale modifications. And you can use some technique like Plastic Curve where you have two cycles to make that easy to recurse and you have a middle-sized proof. And those are three polynomial commitments which are commonly used for commuting to a univariate polynomial. Like it's only one variable but the degree might be high. And another interesting direction which at least blockchain people or industry people aren't really looking to is called multi-linear polynomial commuting scheme. So it's usually commonly used in sum check-based constructions. So sum check is basically, so this multi-linear polynomial commuting scheme is basically you have a polynomial but you have un-variables. And you need to commit to this un-variable polynomial and then open at un-run points. And you can do some interaction to really reduce that to just one opening. So this is very useful for many like schemes which I will introduce later. And so just to decompose some commonly used particles, for example, you have to use Plunky Schalization, Plunky OP and use IPI as a polynomial commuting scheme or the commuting version is using QDG. And so basically when you are describing a concrete protocol, you can like divide that into three parts. What kind of optimization you are using, what kind of polynomial commuting scheme you are using, what kind of like IOP or like the information through electrical model you are underlined. And start it using IR and start IOP and some fly use as this polynomial commuting scheme. And unfortunately, growth 16 is not falling to this gate, not falling to this category because it's basically based on some linear PCP which you do some like you can call some trapdoor in your set up and do the query there. So it's a very special case. It's done falling to this PCS modular like diagram. And there are some new protocols as I mentioned like which is based on multi-linear polynomial commuting scheme which is showing one more potential. One is Spartan which use RNCS as the front end. It has its own IOP to handle this RNCS and the polynomial commuting is IPA. So the good thing for Spartan is that the prover is only doing one large multi-explanation. So you can use GPU to really make that faster because it doesn't need FFT, it doesn't need some other operations. So it's highly piloted as well. And there are another new scheme called breakdown. It's also RNCS based and it's derived from linear time in code work code which makes your prover time complexity becomes linear. So it's linear to the scalar operation. It's not to group operation. And also another advantage of breakdown is that you can use arbitrary field for your witness. So one thing like even if you are using a fry-based one you are only based on mercury and harsh because you use a resultant code because you need to do FFTs a lot. So you have to choose your field which has a large tool density to do in those FFTs. But breakdown can, using breakdown you don't even need to limit your field to be like FFT friendly. And there is hyperplunk which is from East Pretzel and they do this plonkage optimization and hyperplunk IOP. And you can use KDG or a fry-derived like multi-linear polynomial coming in scheme which has some potential. And there is also NOVA. And so for NOVA like you can't actually really fit into this IOP diagram. It's RNCS based. It's really good for doing recursion. And when you're doing repeated computation you can use NOVA to do recursive really easily. Has some nice product there. But unfortunately as you say like those multi-linear polynomial coming in scheme are most only support RNCS front-end. So that's why like you know, hyperplunk brings you this interesting property where you can define something more customized. Now after talking about the proof system let's take a look at what we are using in ZKROP. So the idea behind ZKROP is that you send all the transactions to one layer to prover. And this layer to prover is generally the proof and some means the proof on chain with some necessary data for verifying this proof. And so the proof system really matters in ZKROP because your prover time, your prover cost, your proof size all influence your money you are spending on each transaction and also verification cost which influence your guess you are spending. So now let's think about what proof system we should use for such a general purpose ZKROP. So as I mentioned like you first need to know that what you are really proving. So what computation you are executing. So for general purpose like ZKROP you are actually executing the EVM execution logic. So you need to think of EVM as some type of computation and you need to prove that. So to constrain this EVM virtual machine you have multiple limitations. For example your EVM word size is 256 unless you use some ring-based structure it will always be the non-native field. So you need some efficient ring proof. And there are some thickly unfriendly opcodes which means you need some specialized circuits because if you put everything in the same circuit it will be huge with a large requirement for the memory and for the machine you are using. So you need to decompose the circuit into different types and you need to efficiently connect different components. And third is that it's a virtual machine circuit so you need read and write efficiency so you need some kind of efficient mapping from read and write. And also like one last thing is that EVM is very different from static circuit you are using for some fixed program because the execution trace is dynamic because different transactions have different trace, right? It fills up this table like even in the same position it might have different opcodes you are proving. So that's why you might need some efficient of selectors. So the first three drivers to your circuit information have to support lookup because you know that you have efficient ring proof there you can connect circuit there and also you can do this efficient mapping. And the last one drive you to some more uniform representation for a circuit. You are defining some IR in between for the four instructions and also select at the point you want. So that's the reason why like we have to use punkish customization for static base because they can also support something more customized. And now let's take a look at the EVM we are actually using. So in the EVM we have like two layers. One layer is proving the EVM logic directly. For example, it contains EVM circuit to prove the state translation. It contains a RAM circuit to prove the read and write consistency story circuit for state update and other circuits for example, ECDSA circuit for signature and some other circuits and they are directly used for proving the EVM itself. And then because you're resulting so many proofs so you have aggregation layer which can aggregate multiple proofs and into one proof. So one way of thinking of how we are how we are choosing the proof system is actually two layer. So think about the requirements for the first layer. The first layer really need to be expressive because you need to express really large circuit. And so that's why like you have to support custom gate and lookup more lookup lookup tables. And also you have to use some hardware friendly prover to lower your prover cost because your input computation will be the largest one. You are directly handling EVM, not the verification. So that's why like you need some hardware friendly prover. By saying hardware friendly there are two things. One is parallelizable and the second is low peak memory because if you have low peak memory then you can run on very cheap machines. And also the verification circuit is relatively small because you get so many proofs and you need to aggregate that in the second layer. And ideally there should be transparent or universal set up because you might add some new pre-companels or add some new circuit to this existing diagram which makes the whole thing like you know if you are in growth thing you have to do set up again and again. And so there are some promising candidates for example Plancky to circuit and they are usually in try to do this like really efficiently. And there is a Hello tool but you know for the KDG version it's not that promising because you know although the verification side is very small but it's on another field. So one potential is that you can still use the pass cycle for Hello tool doing all the recursion for your ZK EVM and the content a lot of like prove a lot of computation and then use something like a bridge to bridge this Hello tool prover or verify to your final verification. And there are some new IOPs without FFTs because FFT you need like large memory and it's less parallelizable for example there is hyper Plancky there are some new constructions which remove FFT in your PCS and so that's two promising candidates. And also there are some check-based particle and like by design it doesn't have FFT it only involves some group operations. So for example Spartan, Virgo and all those constructions on Nova but unfortunately they only support R1C so if one day they can support Plancky stuff then like you know it will be more easy to use. And in the second layer as I mentioned like because the requirement is actually efficiently verification on EVM. So even if some Wi-Fi is efficient if it's not on EVM then it doesn't really make too much sense for the KROP. So and also the second is secondly that you need to prove the verification circuit from the former layer efficiently for example like if your former layer involves some non-native stuff then your second layer is better to support some Plancky stuff because you need some customized stuff to handle your verification circuit. And ideally it's hardware friendly and ideally it's transparent or universal. I said ideally here just because it's not a very harsh requirement because the largest computation has already been done by the first layer and then like for the aggregation circuit you need to do like smaller amount of computation so that's why like maybe not the big stuff. And so some probabilistic candidates is that one day to grow 16 which I think Hormida already using in practice and second choice is actually Plancky with very few columns. For example we can configure that to be just one advice column, one lookup and one fix column. It can be even sometimes even more efficient than grow 16 like you use KDG or you use F-Lunk proposed by the Aztec team which you, the trade-off is that using F-Lunk you might have a like more efficient verifier than grow 16 but the trade-off is that you triple your pruning time and also there is a catch up fry which with a large code rate and which you have a smaller verification circuit and you can basically do verification immediately. So this is like our construction. We choose the first layer to be hello two and second layer also hello two but the hash function uses is different because it has those nest properties. Since we are running a little bit of time I will just skip this slide and so it's just basically good performance with GPU prover and the verification circuit is more, since it's distinct. And the second layer is that because you need to prove for the first layers like verification you need custom gate. And so there are some future work we are like actually thinking of and I want to have some spec on is that we want to generalize this framework a bit. So we believe that the front-end the end goal of the front-end will be hello two because it provides really flexibility for writing circuit like you have different rotations you have different layout configurations. So we want to generalize this framework to support using the same hello two front-end but support different polynomial IOPs for example like Harbour Planck IOP and for example you can add Frye to the hello two. And also we need to significantly improve the hello two tooling support like because I heard a lot of complaints from developers who are really using hello two like there might be some DSL you need and the bug reporting is really poor and other like any feedback from developers who are really using that. And the one last slide I will talk about some other considerations even beside the efficiency for proven and verify. So there are some concrete considerations here. First is your ecosystem. So if you are using their approval to develop your application one thing you need to think about is that whether it's compatible with existing libraries. So if you for example and whether there are so many projects and the gadgets implement there because for example if you want to just build a simple application is there are so many implement gadgets you can directly use that which can simplify your development process a lot. So that's what I mean by ecosystem. And second is implantation. So even if some new paper coming out with very nice complexity you still need to think about what's the implantation and how long does that take? For example like industry implantation is usually like more solid and with better performance and better security consumption like considerations than the academic one. And you also need to consider the best practice like for example if you are running a benchmark it shows really slow but if you know from the algorithm side that it's very easy to parallel using GPU kernel then it's not a big deal. And also there's license and audit. And so if we can really standardize the framework for the proof system we're using and we will have a very large community and even have the ASIC specifically for making this kind of proof system faster and making that really great. So I think that's pretty much how I want to cover and thanks for having me.