ZK HACK mini - Introduction to Plonky2

Transcript

but um yeah we're going to talk a little bit about plonky 2. um and so i think uh so we at polygon zero have built these two um ckp libraries 2 and starkey and so i think that we can look at them as representing a new approach to building vastly more performance snarks and starks so plonky 2 is a library that that combines plaque and fry and starkey is a library that focuses on stark run air based starks and supports recursive verification of air based stars

and so this approach i think is characterized by uh using small fields and then recursive fry and so what does this mean uh fry allows us to use much smaller fields than elliptic curve based proof systems so we can use this really interesting field that has that's characterized by prime order 2 64 minus 2 32 plus 1. and the difference is that that allows us to to take advantage of a structure and how cpus work and speed up field arithmetic really

considerably and so at the same time we have this trade-off that's really interesting that fry provides which is by changing what's called the blow up factor in fry we can have uh on the one hand either fast provers um but really big proofs um or slow provers and smaller proofs um and so up until now uh protocols that have used fry have had to sort of pick some point in the middle of this trade-off where like for instance if you're if you need to verify something on ethereum your blow-up factor has to be big enough that the proof size will be

small enough to verify in ethereum um but not so big that your statement uh takes forever to prove um and so for the first time um with plunky 2 we can avoid this trade-off using recursion so we can take the complicated statement that we need to prove and we could use a really low blob factor and so we can have a really fast proof uh but one that's way too big to be verified by an end user or on ethereum but we can wrap it in a smaller recursive proof and so this allows us to sort of take advantage of both sides of this

trade-off where we can have really fast proofs and still sort of shrink them so they're more usable and it allows us to sort of pick and go back and forth between using plonk and air arithmetizations um so like for instance for uh we have this virtual machine that we use to to compile uh salinity or yule to um to verify ethereum transactions uh and so we can use air for that because fundamentally like our routing model like each step of the vm only needs access to like the previous step and the next step and so we don't have to pay

the cost uh like in plaque where we can route gates to any arbitrary of the gate and so there's pocky 2 exposes this flexibility that's really useful so the result of all this is that we can have uh lightning fast zero knowledge proofs um with uh no trusted setup it's fully transparent just like stocks and on plunky 2 we have best in class recursion performance so it takes 170 milliseconds to generate a recursive proof on the macbook pro and we expect that this uh over the next

like month or so will will decrease pretty dramatically as well and so um a really interesting uh aspect of this like prior to working on polygon zero we were working on um this protocol mir which was uh used like the zexi style um single level recursion and then recursive aggregation and what we found was really annoying about that was that when you use recursion with ec based schemes you generally you either have to pay the price of using a single curve and having a non-native multiplication that's

expensive to to do in circuit or you have to have a cycle of curves and the problem is that like you sort of have to keep track of which curve you're in which is annoying because like we wanted to perform some computation in the inner proof but then inline some like computation in the outer proof um but still like using the same merkle tree and state and accumulators um and uh but those uh scalar fields were were different and so we weren't able to do that um and so with pocky two uh we only have uh a single field for

everything um and moreover you know not to take anything uh away from halo but uh we fully verify each proof like like every recursive step represents like the full verification of uh whatever proof is being verified and so we don't have to worry about having accumulators or deferred computation or combining accumulators um and so for us like th this is something that that makes sense and it's nice and so ponky ii is natively ethereum compatible so right now we estimate we haven't done the um the evm verifier but it's a very

straightforward port to um verify a bunch of ketchup hashes and it costs we estimate it costs about a million gas to verify although we're currently working on a project with hermes who's also using the goldilocks field to reduce this really dramatically so there's a really obvious trade-off whenever you use fry which is that uh the proof sizes um are really a lot bigger than um ec based schemes um i would say that uh that proof size is like eventually you're going to be like like a lot of

people are focused on proof sizes and sort of um you know how many proofs they can fit in the block but uh like past a certain point usually it's like 100 tps you'll still be bound by verifier time um and so with recursion like there are ways where you can architect your protocol so that you aren't bound by proof sizes that you can have proofs routed to specific nodes that can um aggregate and so uh yeah i have maybe controversial opinions on how much proof size actually matters but as i mentioned before we we are working on um on compressing

um proofs uh even further so that they can be verified uh cheaply on ethereum um one of the other downsides uh is that um on larger fields we can define an elliptic curve directly on uh on the scalar field of our curve that we're using in our proof system um the uh but the goldilocks field is too small to to define an elliptic curve uh directly which is um annoying because you want to be able to support uh verifying ec signatures and um pedersen hashes uh but there are two really interesting new papers that were recently submitted to

eprint where that show that we can define curves that are secure over an extension field of the goldilocks field and so we can still uh efficiently verify um uh easy arithmetic uh in wonky two and star keepers so i think all of this like the reason why we're so excited about pocky 2 and about this approach is that we view zero knowledge proofs as a sort of computing platform um and throughout the history of of technology whether it's been the pc or mobile or you know games game consoles uh whenever you increase

speed on a computing platform by 10x um you sort of like blow up in the design space for for new applications um and so plonky 2 represents like a 100x speed up in recursion performance on ethereum um we've it's like difficult to benchmark these things for other arbitrary computations but we think that for general statements it offers a 100x speed up relative to to other proof systems and uh i think that we're just really excited about um

about having uh like such a huge speed up that that is not uh due to hardware acceleration or it's simply um software and on cpu and um and we think that this is like a really promising approach for um for the space and for anyone building um with uh with zkp's and crypto um and so with that i will hand it over to blue william are you there

william i think you did yeah i just managed to i mean it myself okay um how do i share my screen uh there's a little screen underneath the red line yeah oh can you see my slides well no we actually i can if you go into a slideshow but then you probably can't screen um is that okay for you or that looked good to us oh that was okay this looks like

your slide looks great okay cool um so yeah i'll talk a bit more about punky 2 on the technical side and how we arrive at this design um after having tried some other approaches to recursion so a quick recap on proof recursion so in the proving system you have two algorithms the approver and the verifier and the approver outputs a proof pi and the verifier verifies it and the idea of proof recursion is to write this verifier algorithm inside the circuit right so and then you can get the proof capital pi that small pi is correct okay and

this might not sound too impressive to just do like a one layer recursion like that but this can apply to more than one proof um you can have a recursive proof that many small proofs are correct um and you can see how it can be useful in the in the roll-up context for example uh when you have a bunch of transaction proofs well you can compress them um using a recursive proof that all these transaction proofs are correct and so you can press all these transactions to just one proof that you can publish on the l1 for example in the roller context and so that sounds pretty easy to do but in practice proof recreation is quite hard the main reason is that most proving

systems are based on elliptic curves and you might know that an elliptic curve e has two fields so there's the scalar field fp and the base field fq and when you have a proofing system over an elliptic curve the actual proof will be over the scale field fp okay but the proof pi will be a mix of elements in fp and fq and that's an issue because when you if you want to verify this proof inside your proving system well you will have to do arithmetic over fq but your proving system works over fp so you have to do non-native arithmetic so stimulate arithmetic over fq in the field fp

and that's usually very expensive but you can still do it and people have done it and that was probably like the first approach to recursion it just simulates arithmetic over fq in fb but to make this more efficient people have come up with a solution which is using cycles of elliptic curves so a cycle of elliptic curve is a pair of elliptic curves e and e prime and the base field of e is the scalar field of v prime and vice versa and the idea is that if you have a proof pi over e you verify it over e prime and since the scalar field of e prime is q fq then you can do native arithmetic to

verify the fq elements of the proof pi and if you have a proof over a prime you verify it over e so that's why it's a cycle um so that's a nice solution but you still have some problems uh first one is that you still need to do some non-native arithmetic so as i said above the proof by is a mix of element in fp and fq so by going to e prime we take care of elements in fq but the element the checks in fp so those are the constraint checks in most powering system those you still need to do in fp and so these checks become very expensive on a prime okay

and so you could either simulate them non-natively on a prime and but that would be expensive or you could use some tricks that people have come up with which is to defer this non-native computation until you go back to the curve e but then that means that you need to to at every point in time keep track of the different computation um another issue with cycles is that there is no reasonable cycle of pairing front liquors so proving systems like graph16 or original planck are based on pairings and so if you want to use this um approach of cycles with these schemes

you will have to use uh very large cycles of pairing friendly curves so um these curves will have like very large large fields and will be like pretty inefficient uh to use um and so yeah i think there are some theoretical results that there doesn't exist any cycles of you know reasonable and efficient very critical curves um so since you cannot use pairing friendly curves um you have to use uh ipa based systems um so this is the line of work that started with bulletproofs uh it's a way to do polynomial commitments um without trusted setups but still on the elliptic curves using the discrete log

um and and that's that's fine that works but you have some issues because the verification in bulletproofs is actually quite hard and quite expensive so if you wanted to do the full verification recursively uh like the circuit would be way too large so halo was the first that came up with this idea of accumulation schemes so instead of actually verifying instead of actually implementing the full verifier in the circuit you just implement an accumulation check and then you keep track of this accumulator and if you want to finish your your recursion you still have to check these accumulators right

so at any point in time you're not you haven't really computed the recursive proof you have checked you have a proof of the checks but you still need to prove the accumulators yeah but still that works um and that's actually what we did in planky one we had a planck with halo-based ipa primal yeah another issue with all these elliptic curve schemes is that elliptic curves are in general quite slow because they work over large fields so yeah in 21 we had okay approval times but at some point we realized that we could do better and that's where we introduced plunky too

so pranky2 is very similar but instead of using adp curves and bulletproofs we use fry based polynomial commitments okay and we still use uh the planck arithmetization okay um and fry uh most of you probably know it it's the protocol that that's underlying most storks and it's a protocol based on hashes so it doesn't have any elliptic curves the only cryptography in fry is hashes and hashes are convenient for many reasons first one is that they're pretty fast to compute in general second is that they are defined on only one field so the input of a hash is a bunch of field element

and the output is a bunch of field elements but in the same field so in elliptic curves we had to deal with um two fields but we fly we have only one field uh which simplifies a lot of things all right um and um another uh good thing about fry is that we can use small fields yeah and as brendan mentioned uh we can take advantage of like of the fact that cpus are really good at uh working with 64 bits and so we defined a 64-bit field called the goldilocks field that's really efficient to work with and that makes the proof really really fast

and i think that's also the field used in maidan and um and other projects um so another feature is as brendan mentioned uh we have what i call full recursion is that as opposed to accumulation schemes at any point in time we have a full recursive proof of all the the chain of three um before so we don't have to check any accumulators any deferred computation it's like in terms of engineering it's like very simple uh we just implement the verifier inside the circuit and and we're done uh we use custom gates so um that's something that's called the turboplank automatization

uh so it's planck with custom gates and that's really useful because when we write the recursive circuit there are a few uh quite expensive operations and um we can just abstract this com these computations away by writing custom gates for every expensive computation and that's one of the reasons our proofs are so uh effective another reason is that we use a large number of columns in the plonk trace so in the original plant paper they use only three columns most projects will use around 10.

we use 140 columns so that's quite a lot but it allows us for example to do hashing in just one row of the trace um and think since hashing is such a is the main operation we have to do in fry it's really crucial to us that hashing is as efficient as possible um in our proving system and and with this large number of columns we can do hashing in in just one row um yeah and and yeah otherwise a ton of tricks um to make recursion efficient one of them for example is we truncate all the miracle trees so when we verify a miracle path instead of

going all the way to the root uh we truncate the path and and stop below the root and that makes the proof smaller and also more efficient to verify and the result of all this engineering is that we can do recursion in 2 to 12 gates and a hundred millisecond 170 milliseconds on the macbook pro um to the best of our knowledge that's by far the the most efficient recursive proof system out there okay um so afterwards i'm gonna dive a bit into the code base but i think now it's a good time to look if there's some questions [Music]

okay q a are there open source implementations of starkey yes um so starkey is a subcrite of plunky 2. i'll talk a bit more about that later can you explain a bit more about merkle tree optimization um sure um so so i'll do something that means okay can you see my image of a merkle tree yeah so here um the mercury usually you go all the way

to the top here and you have this miracle root what you could do instead is have this uh not give this root as the as like the commitment of the merkle tree but have these two nodes here these two nodes below and that will be what we call the miracle cap and when you verify your merkle path you stop at this second level and then you verify against one of these two nodes so yeah i don't know if that's clear um uh and they're also like for the proof size optimization we um so when you have so like in fly you have uh a bunch of merkle trees and you have

a lot of paths in this merkle tree and so there is quite a bit of redundancy when you go up the tree so like you will have many times the same node and so you can like do some tree optimizations by removing the red on that node but that's just about proof sizes not not really efficiency do you support lookups not in planky 2 we will probably support lookups in the start based vm yeah for like your run checks um that kind of stuff uh like uh bitwise operations we'll probably have lookups in the in the vm

but not in the blunky2 zero knowledge so zero knowledge we support zero knowledge now but it's really inefficient we just add a bunch of random points in the trace um it's not our focus right now because we don't need zero knowledge for the roll-up uh at some point we're gonna make it more efficient uh yeah i think right now like zero knowledge you're better off not using zero knowledge because it makes the choice a bit larger but you can still um do it what is the benefit of stopping just before the tree root one less hash yeah basically one less hash so like we have

to do a ton of hashing in the recursive circuit so like if we can remove a few hashes it's it's quite efficient yeah we we gain a lot how does plunky 2 compare with stark in future limitation so now we don't need periodic operations so like the the thing about starks is that you have to do this periodic stuff and all these um complicated things because you don't have wiring of um wires so like in plank when you have two wires in the trace you can uh connect them saying i have like what we call a copy constraint um

so if we wanted to like simulate a periodic operation we would just you know connect the wires periodically we don't need that to be like implemented in the proof system so i mean planck is really cool um because of that because of these copy constraints it's like very easy to use okay i think i'll stop now and have a look at more of the engineering side um so the blanket to code base you can find it in on our github um it's written fully in rust and we try to use to not use uh dependencies so like

all the crypto is is done inside plunket2 all the field operations uh fiat chamier uh iops like everything is done in planky two we don't need we don't use any dependency for that um and so if you go on the github right now and look at the project you'll see that we have seven sub crates um the main one is called uh plunky two uh it contains the the proving system logic uh the planck stuff the challenge the fiat chamber stuff um then we have the field crate which contains the the code for field operations uh for the goldilocks field uh all kinds of optimization related to field operations

uh then starkey so what um one person was asking about starkey's turkey is a part of punky two uh and so it's a it gives a way to define starks that can be verified by by 2 so that's quite convenient and one implementation of starkey is system zero so it's still work in progress but this will be our stork based vm uh so it's an implementation of starkey and so it's a stock based vm that at some point um be able to simulate the evm for our roll up uh and and so any proof uh any stock proof of this uh of a vm trace will be uh verifiable by pronke2 and then we can

you know use recursion in plankton and then yeah we have a few other crates uh which contain some gadgets so permutation gadgets insertion gadgets and one other so those are gadgets that we needed at some point but we don't need them anymore so but they're still there and if you need for example um a permutation gadget we have it on in the blanket2 repo okay and i wanted to do a bit of a live coding because we use plunket2 for uh polygon zero for our rollup but it's actually we actually tried to make it

a nice proving system to use for everybody right so like if you want to if in your project you need a proving system with fast recursion fast proving time uh then you could definitely use splunky too um and here i'm gonna show an example of how one could use planky 2 just as a as a proofing system for any kind of project um so and the example would be summer for so those of you who did puzzle one last week uh probably know about semaphore um so it's a really nice protocol from membership proofs and um some kind of voting so like you can give a signal that you vote for topic uh and that you're a member of this um

of this uh set uh it works uh by using an what's called an access set so the access set is just uh the miracle tree of a bunch of public keys okay uh and so you want to approve membership uh ownership i should say of one of these public keys um and so you have a secret key sk the public key is derived from the secret key as the hash of sk and zero the nullifier is the hash of the secret key and the topic you want to vote on and then when you want to publish the signal you publish this nullifier and that will be

very um crucial to uh to check that you haven't voted twice um you know that was actually uh what uh puzzle one was uh about and then you publish also a zkp of that all these relations uh are correct so that the public key is um correctly derived that the public key is part of the miracle tree uh and that the nullifier is also correctly uh derived okay and i've published this example on our github so you can have a look afterwards where am i all right so here is the repo punky to semaphore

um so it's a rust project of course uh here you can see you can import plenty too directly from git we're not on creates that io but we will probably be at some point is there any can make the font a bit bigger on this on that part of it when you're doing coding stuff yeah oh yeah um another thing that we can also do is if you turn off your video and brandon if you turned off yours i think it shows up bigger on the recording right so it's like a way that we're if you're in between that now be a good moment to just just turn off your video oh yeah cool uh i'll try to do that sorry to interrupt you though

yeah knowers um it's just the video screen or the camera yeah no that's here the little video camera no there's a video there's like a video camera where next to the microphone where's the microphone oh at the bottom of the screen i don't see it i think your screen is maybe it seems like the controls are maybe maybe i can do it let's see if i can no i can't do it for you hmm well i guess we're gonna have to do it as is

yeah sorry um okay yeah i'll make the phone bigger okay thanks for that yeah there is i don't know how to do it though anybody knows intellij how to make the phone bigger maybe a pirate's way oh yeah i can just use my mouse yeah that's all right all right so okay so you can import 2 from github then the access set so so

basically um for those of you who did puzzle one i just transfiled the code from puzzle one to planky2 so it should be pretty familiar if you worked on the puzzle um the access set is just this merkle tree okay and the leaves will be the public keys um and then i have a signal struct the signal contains the nullifier which is a digest and the proof which is a plunky proof here i have a bunch of types so my field will be the goldilocks field the goldilocks field my digest will be four field elements here i have a config c which is a

possible deluxe config so that's the main config we use for recursion because we use poseidon uh which is a arithmetic hash function and the goldilocks field and then the plunky proof will be um so that's a that's a proof struct in clunky two and it takes a bunch of generics it takes the field the config and here two is um at some points in punky two we use extension fields and so two will be the degree of the extension so here we will be using uh quadratic extensions which i i would recommend for most projects uh uh you get a hundred bits of security by using um degree two extensions okay and we have the signal then

fireproof now let's see how we can compute the signal so verifying the signal is pretty easy we just compute the public inputs of the proof so the proof will have as public input the merkle root of the access set that's that part here it's a bit complicated because we use caps merkle caps i was talking about so like the code's a bit ugly but um that would be the first part of the public input second part will be the nullifier and then the topic topic will be also a public input and then we have this function verify um which basically just verified the proof and the public input yeah and so here you can see verified data so that's

quite interesting uh we still use planck uh so that means that we have to um we have pre-processed polynomials uh the planck processors pre-process polynomials so we still need some um what is called verifier keys in some project systems to verify the proofs yeah so in stores you wouldn't need this but since we use splunk you you need to use this verifier data okay so that's the verified signal function it's pretty pretty straightforward and so how do we make a signal okay so here you can see to compute the nullifier that's what i was saying before you just hash a private key on a topic so

if i go back to my slides nullifier is the hash of the secret key on the topic that's good then then i need to define so like this is what you will do in planky 2 is you have this config which is a circuit config we have a bunch of configs ready for all kinds of applications here i will use the recursion zk config so one person was asking me about zero knowledge in punky two you can actually use zero knowledge in pakistan it will just be a bit inefficient but here i can use it because i want to hide my secret key um and uh the recursion part means that i can also do recursion with this config and then i define a circuit builder

circuit builder is how you actually build your circuits in in plunket2 uh and all the gadgets in frankie two are methods of this circuit builder so like if you want to build a circuit you just instantiate one and then call some gadgets we'll see how it works later and then partial witness is pretty cool so um so the witness in planck is basically a table um and you don't have to fill all the wires in the table um all the cells in the table manually you can use this partial witness and partially fill the table with values and then the proving system will take care of to generate the rest of the values

uh using the gadgets so here pw like the partial witness would be used to just give like the field the data that's needed uh in the circuit okay and here the first interesting part is targets so um here i want to actually define a circuit for the summer for verification so here that's the zkp i need i need the circuit if i want a zkp so let's define the circuit i have this function so first i register the public inputs i register the merkle root i register the nullifier and i registered the topic okay those are all the public inputs we saw before

uh yeah i should mention so like we have this virtual thing so like virtual targets virtual hash so when you when you want to have wires uh in your trace but you don't know where they will be in the trace um when you instantiate them you can instantiate them as virtual and then they will be wired later okay so for most things you can just use virtual targets and then they will be wired automatically so here we have the miracle proof um private key public key index okay here is our first gadget okay so we have the public key index but we actually need the bits right because in the miracle pro verification

uh when you do when you verify this merkle path you need to uh if uh your hash is on the left or the right depending on the bit of the index so we need to split this index into bits and we have a gadget for that and so you can call builder and then here you will get a list of gadgets uh and then this one for splitting bits is called split le so le for little indian and then it takes an integer and the number of bits here the integer will be the public key index so publicly index and then number of bits the number of bits in the merkle path will be just the height of the tree and so i've conveniently implemented the function

for the tree height and so that will give the number of bits it's just the height of the tree okay but here what i just did is add a gadget for bit splitting and so as you can see it's pretty easy you have this boulder builder uh the circuit builder and then you can just um call gadgets directly from the builder okay and then i want to verify this microproof so this microproof for the private the public key um and so there is of course a gadget for that so id verify microproof the the microproof takes sleeve data so the leaf data will be the the private key

and a bunch of zeros four zeroes okay and then i concatenate them that will give the leaf data and what else do i need [Music] the bits okay that's convenient i just computed the bits public index um the merkle cap and the proof okay so the miracle cap i just do uh merkel cap target and then miracle root so yeah as i said this is because of the cap thing so we don't use michael root we use merkel caps and this makes things a bit inconvenient but

basically you can think of the cap as just the root and then i need the microproof okay everything is red which is not a good sign a bunch of references okay now it should work okay and the final gadget i will use is the what i call should be nullifier so we need to check that the nullifier is computed correctly as the hash of the secret key and the topic and i'll just do that with the hashing gadgets in the circle builder we have a gadget called ash

and to hash notepad so you can hash any a vector of inputs of any size to a hash and you don't do any padding and so that will be i said the secret key so the private key and the topic and normally i can just concatenate them all right cool and then what i do is i connect so like yeah i was a as i was saying before like in planck you have copy constraints so you can connect wires and here i will connect these nullifier elements with the should be nullifier

and since the digest has size 4 i do that i loop over zero to four and then i connect these elements yeah and then i will um return all these targets um and so these targets are just wire in the trace but i've never actually filled these wires with actual values and so i need to do that at some point and i do that in the field some of our target function which is called right after this sum of four for circuit function and um it's not very interesting i just have these functions which are

pw is the partial witness and we set the targets so like we have the private key target which is the the wires representing the private key uh and then we just set them to the actual private key so here you can see private key is like um a bunch of targets and private and private the actual private key is a bunch of field elements or digest in this case so i can just set them one by one and then i have everything that i need and and here i have a small test and you can run this test let's try to see if it works it doesn't

oh well verify uh okay um [Music] so here when i verify the merkle proof i need to say which hatch function i use and normally if i specify that i use the persian hash it should work okay i need to also specify which hash function i use for this gadget all right it seems to be combining okay it works

it works and what tests did i just run um i didn't mention it so the test is pretty similar to what you've seen in in puzzle one i generate a bunch of private keys around the million private keys then i um do i derive the public keys as you can see it's the the hash of the secret key and a bunch of zeros uh i compute the access set and then here i i will do the proof for the 12th uh private key i generate a random topic and then i make the signal and then i verify the signal okay so it was probably a bit unclear but yeah as i said everything is on github you can have a

look if you want and don't hesitate to contact me if you have questions we have a discord of polygon zero if you have questions about splunky2 or like how about this example i'd be happy to help um do we have time to take questions anna i believe so let me just double check the schedule but i think so we have like 15 minutes or so right oh awesome um okay what is the difference between system zero and maidan um they're very similar uh it's stroke based vm i think maidan is more stack based so it does a lot of stack

operations um and we don't do as many stack operations but they are very similar and they both have the same goal of of of being used in a roll-up for the evm yeah do you provide a compiler assembler ecosystem for system zero uh not yet but we're working on it um we're working on a transpiler from another transfer compiler from yule okay so yule is a intermediate language from solidity so you can compile from solidity to yule and then to yule to system zero and that will be the the pipeline used in the roll-up of polygon zero what are the disadvantages of clunky 2

compared with just using turbo or multiple rank so if human turbo ultra planck as in um like aztec is doing with pairings is that um pairings are really hard to verify recursively so planky 2 is really designed for recursion it's not the fastest uh verifier it's not the the smallest proofs but it's the best printing system for recursion so if you need recursion then plunk it with the way uh otherwise yeah turbo or droplong are also good systems but i mean you could say that from k2 is just a variant of turbo planck um

can you explain publicly index and bits yeah sure so so you know like when you verify your merkle path you go up the tree and you go either right or left depending on on where you are in the tree and right or left is i represent this as a bit and so um so when you have the index of your public key in the tree then you just need to split it into bits uh and and you need a gadget for that but the gadget is pretty easy right so you you split your number into bits and then you verify the constraint is just uh you know like the first bits press the second bits times two plus the second the third bit times four and so on equals the original number yeah

when will be when will the first version of pokey to create to be released uh i don't know probably pretty soon uh we just need to publish it to create that i o and probably clean some things um does starkey already support recursion yes so when you define a stark in starkey you will have to define the constraints the stark constraints okay uh and you you also have to um define the recursive stark constraints so how to um compute the constraints in planky2 okay and and when you do that then afterwards uh automatically plankto can verify the stock

so it's actually pretty cool um how we can just define any kind of stocks and then it will be easy to to recursively verify in 2. okay no more questions