ZK-EVM

Transcript

hello hello well first of all let me thank you to the organization of uh fscc paris i think they did a great job especially with the circumstances that we are so i just want to ask you for applause for the for that well let's start i'm jorda beilina i'm the technical lead at hermes for the people that don't know yet what's hermes remix is a layer 2 roll up a zk roll up it's launched it's actually running in mainnet the people

of you that's having playing to the truss community game they were using the hermes roll up in mainnet so you can do any if you have an erc20 token and you want to do transfers in a cheap way uh hermes is already running in there it's a roll up that's decentralized the protocol is fully decentralized we are doing a transaction of batch transaction every 10 minutes or so is the roll up that's the most efficient in terms of cost the proof cost of the roll-up is very very very cheap and it's the one that the i would say the the the cost per

transaction is the cheapest one we also have been working in the inter interoperable with other role apps it's still something that's working in progress uh the roll-up already from the security perspective uh at some point it had uh 30 million dollars which is a but it's a good quantity just for to start you know smart contracts never are safe but you know that's at least if they have had 30 million dollars and have not been hacked it's better that if they don't have it so that's something that's interesting there from the more technical things the prover of 2048 transactions the just generating a proof we are around one minute which is quite cool of course we can run many proverbs in parallel and we can achieve this scalability of 2000 transactions per

second but this is already maint okay and the next challenge is going to be the ziki vm that's actually what i'm going to talk in this presentation before going to the zqbm just a couple of things that we're also doing and then i want just to share with you is that we are also working with token swaps we have a service for token swapping on hermes same way that you are doing with the game here because it will be will be done a service a permanent service just to do token swaps and then we also will work in the instant payments but let's go to the zika vm okay so we want to run smart contracts on a roll-up so we want to scale ethereum mainly that's what we want to do okay but what's why it's so difficult you know just

ethereum virtual machine was not designed to run in a roll-up to run in a zika circuit it was designed at six seven eight years ago long time ago and you know zero knowledge at that time and very few people knew what what it was the cash people probably are amazing people you know they did a great work for that so for the zero knowledge so um so when we want to build circuits to run the z kbm roll up what strategies can we follow because no it's not designed for so we need to do some kind of engineering here well there is one first i would say

naive approach so okay let's throw away ethereum let's build a new ethereum or a new vm that's as zika optimal to build on top of that okay but what happened with all the knowledge that we have taken uh during these years from security perspective from writing a smart contract for applications etc okay so another approach is okay we have this evm okay let's try to do it like solidity compatible or you know just we have a solidity we recompile the program instead of going to this vm we go to this other evm this has some problems but something

that's doable and actually some projects are doing this approach okay but i want to explain like a third approach that's true that's actually the approach that we are following and is we are trying to just do it directly so try to implement all the zk so all the op codes of ethereum directly in the directly in the in the in this in the sdk circuit how we do that well first of all why up code based approach why do we want this compatibility between opcodes one to one well first of all from the engineering perspective

we have a perfect definition of the problem we know the op codes of ethereum they are in the consensus layer so everybody knows what are those codes so we know what's the goal we know what we want to implement we want to implement all the up codes so we want to a person that has a smart smart contract circuit uh running in layer one should take this compiled circuit put it in layer two and work exactly the same that's that's the goal and we do that if we implement all the opcodes we want full compatibility with the ecosystem if we do that if we go at the opcode level

then we guarantee this compatibility with all the tooling and all the tooling that we have right now in the space [Music] in the evm there is a lot of knowledge about about security so here another advantage of doing up code bio code is that we maintain all the security model of evm if we have a new security model for example the gas the gas there is a lot of security uh in the calls uh when you are doing a call you are limiting the number of gas and a lot of the security for smart

contracts is based on that fact because if not you have re-entrancy okay so okay if you create a new evm with a different gas model what will happen well we'll have to start over again on this so if we keep this you you maintain the security alt that has been a work for many years on on now the other thing is that here if you go to the compiled version at the end deficiency when we analyze the problem it should not be that different because solidity is very much evm uh focus it's uh you know in solitude you have 256 integers uh it's very linked solidity and the ibm so at the end you can if you

are doing in a solidity way you can end up that the the compiler uh adds a lot of instructions of this specific zero knowledge there and if you compare with the instructions that you are we are running in the way we are reading at the end it's not going to be that different so we don't see that a huge advantage but something that we need to see in some way okay and the last uh motivation that i want to to add is because we believe in this solution i think this is the right way to go maybe we are wrong but we are i think this is uh we think this is the right way so that's we go for it okay so let me start to enter a little bit of the detail so the idea is okay we cannot run we can

it's very difficult to create a zkb a an evm optimal zkvm directly running opcodes so what we are doing mainly the trick and this is the important trick is we are creating like uh let's call it a micro up codes so we are creating like a kind of a evm that's decay compatible compatible that interprets that reads the op codes and executes those op codes on that but the trick here is that the this micro evm that we are designing it is very tailor-made for executing these evm of codes and this is the way that we

can optimize a lot okay just to see to set up the problem at the end is we have a micro evm assembly code this could be like the rom it's a fixed program that we already have the input of this program would be like the alt state all the transactions that we want to execute and the output would be the new state okay so that's like the problem so we have a program brighten in micro assembly micro uvm assembly that reads the state the world process all these transactions and compute the new state just to set up a little bit the problem that we want to

to build okay so well here i'm gonna jump okay uh this so well i'm gonna start going a little bit deep now okay so before going a little bit deep i just want to do like a three minutes parenthesis to talk about to explain a little bit about what's polynomial commitments because this is very important to understand what's coming next okay so this is do not get scared it's easy so i think that most of you knows what's a polynomial you know polynomial is something like that okay so polynomial oh sorry polynomial can be let me see it fits this yeah so

polynomial can be you know just here it's a typical polynomial a line one plus two x that's a polynomial okay so and in general to represent the polynomial we have the coefficients so let's say one a two a three this is a normal way most of the people understand what's a polynomial okay but a polynomial can also be represented but we will say the evaluation polynomial for example if we have a line we have two points we also define a line okay so if we have a three point we can have a two degree polynomial so at the end you just need evaluations to some specific points okay so here is the coefficients representation evaluation representation and the cool thing here is that we have some interesting tools like fft that you can convert from one

from one number to the other so i can convert if i have a polynomial in the coefficient way i can convert to a uh evaluation way and just switch okay so well polynomials well in general you see it in the real space in the real space is very easy you just see a polynomial here we are in a finite field so we don't have all the numbers we just have a specific set if we are for example working for example in a in a with a field of set prime 17 here we just have only 17 so in the x axis we only have 17 values and in the y axis we only can have 17 values and this polynomial if we evaluate this polynomial with the finite field finite field is just doing modulus you know if

you want to add you add the numbers and and do the modulus 17 you multiply multiply them and do modulus 17. so if you get this polynomial into the numbers you can see here for example at point zero two plus three plus zero plus zero plus zero this is two okay so a two and zero is two so you can have just a normal polynomial nothing fancy here okay and yeah this polynomial for example we can represent it with coefficients way just 2 plus 3 x plus 6 1 1. so this is the coefficient of way but we can represent it also this is exactly the same polynomial this is in the evaluation polynomial and we can convert from one to another just using this uh fancy function here okay so we have polynomials and then what's a polynomial commitment

polynomial commitment is okay we have a proven verifier so here we have an interactive protocol the prover just commits to a polynomial committing to a polynomial is a little bit like committing to an array so we can commit to all the evaluations to the polynomial for example a way of doing a polynomial commitment is just doing in the last polynomial is getting the 17 points hashing them together maybe with a miracle tree and sending this mercury and this is hashing the polynomial okay and then the verifier just chooses a random search just chooses chooses a random number send it to the approver and then the prover just okay at point r what's the valuation okay this is what we call an opening and they say the evaluation at this point

is whatever is that 0 is 2 okay this will but how do you know that actually this evaluation at this point is matches the commitment matches the polynomial that you commit before well here is you need to add the proof and here there are some primitive a lot of primitive cryptography primitive to do all these uh all these uh stuff okay so this is what we call the opening a polynomial and this is this is very cool because well this is an interactive protocol but this can be converted very easily in a non-interactive protocol so instead of waiting for the verifier to send a random number because we don't have very fire it's not interactive what we do is we just hash the

commitments that we made before and because hash is on reversible function you cannot control this r and you cannot control the charge you cannot cheat and so you can build you can have all the transcript you can have all the polynomial commitments for all these proofs and these evolutions on this proof and this just generates a zero knowledge proof in this case for this polynomial okay so here is the math that i want to see it's just not it's not hard the cool thing here with this mechanism is that we can prove so if i commit to three polynomials for example i can prove that for example that there is some relationship between these three polynomials for example i can prove here that you know i commit to a b and c i can recommit that for example the polynomial a times b is 44 times c x square so i can't have i

can write any relationship between polynomials because you know if i i to polynomials or it adds to all the values so i can do this i can i can do these verifications of the polynomials i can also do other kind of more interesting proof for example i can prove that an evolution of one point matches the evaluation of the next point for example if i have an evaluation this polynomial i can check that the next value is the square of the last one so i can do this kind of things and there are some some tricks to do this mainly you are doing is just opening two in two points but that's you can do that easily from the in the polynomial combinations we have all the tooling for doing this okay you can for example prove that the polynomial at the beginning of

at some specific point has a value okay but in here and this is something new from the last years and here thank you very much to the aztec people for the block up there is one thing that's very interesting is that you can prove that the valuations of one polynomial are the same that the other polynomial but maybe with a different permutation they're different or even better you can check that the points of one polynomial are included in another polynomial maybe they they there are some points that are missing there are some points that are repeated but you can prove that all the points all the valuations of one polynomial are the same as to one polynomial this is what's block up and again is

here zach and ariel make a great work on that and this primitive is essential for doing what we are going to do next okay so okay well let's go back to the to the evm you know the abm we have a lot of things to implement in dbm we have uh arimatic storage binary we have a lot of things so as engineers what we're trying to do is just trying to divide the problem in the different in different things okay so well let's start for the for the main program you know let's start for the cpu okay so let's start a cpu in general if using a machine mainly it's a state transition machine so it's just you start from maybe the some registers program counter you just execute one function you get a new

new states of the registers and this would be a normal state machine that's executing a program okay so a program brightening assembly would be something like that this is an example program of course this would be the what the program the real program will be the program that actually reads interprets all the uh transaction of the transactions executes all the op codes and everything okay but this is just a single program of assembly how it would work this is a program that actually do is uh it computes the fourth power of a number in the first in the first function you just load like the input parameter you just put one one parameter in the a register and here well you just create you see here it's a loop

okay so you have a jump and you decrement you do these things four times and then you are just multiplying a times a and put it in a and then you have uh four times and when the end is just a stop that's just a example program of abn how it would work okay so well this is an assembly we can convert these to we can convert these to uh some numbers okay imagine that each instruction is one field number we're working a polynomial that's 256 bits it's a huge polynomial so we can have like a compilation here okay so each instruction have like a codification some of these instructions maybe they have some constant value in there for example jumping i need to say where i want to jump or something like that so here you just

compile okay so this is just a field element it's just a way of compiling this this program okay so what i have if i put here okay let's run this program let's uh do a trace what happened when i execute this program well first i execute the next first function registers are in specific status it's good to move and then this is puts the register v2 and this is status and this is like a normal state machine that's going that's executing one of the other as you can see this is state machine we can define some relationships between the line a and the previous and the previous line okay so this is just an execution trace okay so and how this links to a polynomial

well i can take just all the values for example register a okay imagine that i say okay register a is a polynomial and these are the evaluations of that polynomial so this represents a polynomial there is a polynomial register of a of x where at a point w one is zero a point w two is forty four four is going to be a very high degree uh polynomial degree as high as the number of lines we have it's a huge polynomial but it's a polynomial okay so here i can convert all these trays in a in polynomials okay so here is what you see in in red here that i convert everything in

polynomial okay and what i'm building here is i'm building like a i'm compacting i'm actually i'm just taking like two polynomials and adding and composing them together so i'm doing the program counter register okay and it's the first part of this is that's why i do to do the 16 the problem counter plus the instruction that i'm executing in the polynomial okay and in the main program i'm doing a little bit the same i'm just taking the position of the program and this position and you can see that this so this polynomial here must be included here so the all the values here must be here

if we are executing that program okay so this is the the inclusion using block up the inclusion this is what we are checking so we are creating these polynomials we are committing to these polynomials and we are checking that the relationship between these polynomials are one the other and with this we guarantee that the instructions that are we executing are not some random instructions are actually the instructions of the main program and the main program is fix it's known by the verifier you don't need to commit to the main program the program is fixed it's define it so we can prove that this trace belongs exactly to this to this program okay so we just do it with just a couple

of polynomials commit we said okay so this is the main thread how it works but you know there are more complex things okay let's talk a little bit about the storage how we do the storage well instead of having like one single state machine here we can have like different state machines we have uh for example we have one the state machines that computers hashes just one after the other just put whatever input you want here and you just compute the hash and maybe each hash has different steps for example position is like 60 steps so okay you have a polynomial it's just like a state machine that's computing the hash 60 times when you finish just computes the next hash and so on we can have another state machine that computes a

merkle tree of the state so in order to write a miracle tree you need to like to go twice you know to go down just to verify the old value and then the new value and so you need to go up and forth to the mercury so for each step you need to compute two hashes what i do is okay i have a set machine that actually follows this but the the instead of computing the hash in this state what i mean is i'm assuming that this is okay so i'm just i'm putting the hash that's the valid hash but i'm just creating this polynomial and at the end so when i once i have i checked that the hashes that i am assuming here as as valid that maybe are wrong so i'm just putting the result so i'm just i'm

tricking here i'm tricking but instead of putting the so i'm just putting here but then here is a polynomial and then i'm checking that this polynomial is actually included included in the in the polynomial that's in this other state so i'm assuring that the hashes that i'm putting here are actually calculated in this other state machine okay and again let's go to the main thread the main thread we have some instructions that's going to be stored okay just maybe some of them store reads or write sources some stores okay so it's very easy to build a polynomial that's zero everywhere except for when you have a write when you have a bright storage okay and then i can just check that the

rights the result the rights under the inputs and outputs of the writes here matches exactly the same that the inputs and outputs that that are in this polynomial and again i'm using just block up just to match that this polynomial here is exactly the same than here okay and with this technique i can implement all most of the op codes because all the objects you know they have a state machine that have a super state machine a super state machine and i just have all these polynomial commitments and i'll link them one to each other [Music] okay let's go to memory how i why implement memory well very much i'm doing the same i have the main i have the main thread maybe i

have a polynomial zero everywhere except when i have memory reads and memory rights okay very easy and then i have a second state machine where is memory the cool thing here is that instead of just following the same order what i'm doing is this state machine i'm sorting the i'm sorting the the i'm sorting the the state so i'm sorting the the the reads and writes first by address and then by uh by by step so okay what reads and writes are in the position zero i have to read some three brides and i put that those in the in the in the in the step order

so it's address step this is sorted by this so in this state machine of course i first i need to check that they're following this order so that this number is greater than the other one and here's why this is included in the same machine here and the cool thing is that then the relationship of this is very easy because you just have you just have one value and you just if you're reading you're reading the value and if you're writing you're writing that value so you can have a very easy state machine here and again how do i join those tables and this is the cool thing i can use block up because if you just pack together the inputs and the outputs here that you are executing in the memory and you pack the inputs and the outputs that you have in the in the in the main thread this

must match one so this must be included in one in the other so i can check verify that the reads and writes that i'm really verifying really doing here in this state machine are exactly the same that i'm exaggerating in the my thread and so fo so and so go so forth you know just just uh any code no no i don't know uh doing pairings you know paintings you maybe you have uh you have uh uh the you have the the final exponentiation uh you have the miller loop the miller loop that has different steps this meets a step may have some instructions you have a super machine that have instructions the miller's test may have like field

two the field two have yelled one condition so we can have a set a lot a lot of sets of uh state machines each one very specialized uh thing and then joining them together okay and this microphone for example is very useful also to uh to do something in in in abm you have a lot of variable codes for example you have create code great code you need to write at the end you need to write something in the state but well at the end it's going to be a program that's going to take the the maybe from the data input will be somewhere in the memory and we'll hash them together and write the state in the whatever it is and it's a program okay and you can implement anything

maybe an exponentiation a modal exponentiation is a set of multiplications you can have okay so you have a lot of state machines going for many different things and what you are doing is mainly this first you do the verification of each state machine holds by itself you know if i'm doing memory rates and memory rights there's no reason that memory writes okay and second i just verify this relationship between these different uh state machines by mainly using block up so that this this polynomial is the same or permutation or included in this other

polynomial this is the main tree easy okay okay we have a bunch of polynomials a bunch a lot okay a lot of relationships okay what happened with the very fire very fire is going to be expensive it will have a lot of things so one of the concerns we have is okay we can do it in on maybe on chain maybe it's not that hard maybe it's not that maybe it's not that cheap we don't know yet but probably you know if the evm is complex so probably going to be a lot of gas here so here we are considering two ways to pack these uh polynomials polynomial commitments and polynomial verifications

one of those is just using these skate k commitments and using plonk and especially block up uh just for doing like in block up you can verify uh you know just you can have like a lookup table in some way so you can do like multiplications in the same field and uh well you can you can have some way to aggregate and just put everything in with a single painting in the very fire and then trying to aggregate but this is you know uh you this is one way to do it it's a little bit i think it's more or less how uh the athletic people is doing okay there is another way that we are we are uh analyzing and looks very promising right now

that's all these polynomials imagine that are starks okay so we can use because starks no stocks are great the problem of storks is that uh you know the proof of the stock proof is is huge it's a lot and you cannot put that in the evm it's it's very very very expensive but imagine that we have a growth 16 you know a normal ck like hermes uh circuit you know uh or like any other normal 16 that's verifying starks so we can have a circuit as a growth 16 circuit that actually verifies using a starks all these polynomial commitments all these openings all this

relationship between polynomials and using stars as the opening of itself this has the advantage because the start has one important advantage is that in order to write a verifier you can use a single field element so it works so it's very easy to implement so it fits very well implementing a verified star verifier inside the growth 16 or inside the plonk if you don't want the trusted set up but the cool thing of this is that we can pack all these polling also all this polynomial relationship that we saw before in maybe it's a huge stark proof but all this proof is verified in another snark so at the end in the evm only we have a single gross

16 or plonk verification which is 200 300k gas so we can prove a full evm set of transactions of code by your code in dbm with just a single verifiable system and this is mainly what we are start building in terms and we are very excited to do it in the upcoming in the upcoming months roadmap you know when mainnet you know that's i know that's gonna be the next question uh i don't of course i'm not to commit to anything this is just the internal this is just the internal roadmap that more or less we we have right now but you know maybe it's sooner maybe it's later we're working on that we we are committed we are going to work hard on

that that's at least at least in my site so this is uh but just to to have some some fear so i hope that in probably less but you know i hope that in the next year here we can present uh the the zika vm in in maine and well that's it i hope glad to bring the smart contracts so i think we i went quite fast so we can i think we have some time for for for for questions hey uh so you said you're uh opcode

based so in l1 ethereum when there's a hard you know you need to add new op codes uh there's a hard fork what's the equivalent in the ckvm when you need to add the new upcodes okay hard fork okay um if you have a hard fork in the layer one you will have two roll ups running in there so actually you will fork also what's inside the roll-up that's the thing uh if you don't have a so uh roll-ups are not consensus roll-ups are not consensus they are using the consensus of layer one so i would say there is no equivalent uh to a hard fork in layer two because you

know it's uh there is no consensus layer there so i think does not apply uh no what i meant is uh how hard there is uh for pacific ibm for you to add you know new up codes to it oh uh yeah uh we probably yeah that's that's uh this is gonna be a stick to one of code and then you will have to do some we'll have to think about some some mechanisms to upgrade the but you will have to upgrade the full uh the full the full you know the full smart contract some some way evm so the abm have some interesting uh up codes just to detect hard forks you know

you have the chain and and you can have things so maybe we can do something on that we have nothing very much on that thank you that's interesting it's interesting thing so uh so i understand that um that in zika roll ups that execution is a lot cheaper so how do you actually price the up codes in the zk rollover we are uh we are going to try to maintain the same

model that in layer one we want to keep is going to be some state variable here is going to be the gas so we are going to try at least at the beginning to use the same gas cost that's uh that's in layer one what can happen is that maybe there is because you know layer two is not exactly the same layer one and maybe there are some uh smart contracts that are more expensive to execute in zqbm that in layer one and the other way around but what can happen here is maybe there are some transactions that do not fit in the circuit that are too big for the circuit and maybe would fit in the l1 we will see but the idea is to maintain the so from the gas perspective just try to maintain and

this is we need to maybe just think better but the idea is to maintain the same gas model that we have in in layer one so that developers uh it should not make a difference between one and the other okay thank you hi uh thanks for the talk it was really nice um [Music] so you mentioned it when you're first talking about the the big polynomials in the blue cups i'm assuming that the the polynomial for execution the is going to be the largest one if you have like one execution with thousands of up codes for example um

i'm wondering even of course on chain sets can be very expensive but if you doing the verification or the the check that the polynomials one contains the other off-chain um how long does that take i'm just wondering to verify to build to verify to verify polynomial commitments in general uh well in general are constant so you commit to something is quite constant or constant logarithm so it's just uh under verification do not so an opening do not depend on the b or how big is the polynomial don't do not depend too much you know just a start for example is lock n so it's just but log n is just almost constant so okay

uh should not be so for for the verification should not be uh an issue at all and for the prover uh yes we will have more polynomials it's going to be more expensive so people is uh wondering for the proverb yeah the problem the quest the important question is how will cost to generate the proof of this okay the cool thing here is that uh in in in polynomial commitments but in any snark in any zero knowledge technology the prover is in general is very very very parallel so it's like you pay more you know if you have a big proof just put more machine it's going to be more expensive

and it will work that's doable you know it's just a matter of how much how much will uh will cost thank you hello uh how does the mev fit in the context of the evm zk roll up who fits on in like what the mev the minor extractable value does like is there like any possible mvv that can be done in a zk roll up uh you mean so while the mine does that approver can [Music] like arrange transaction in a way that it can extract value from those uh no no it's it's a well no in general well depending here depending on the

um coordinator selector protocol that you are doing for example in the one that we are using hermes we are using a kind of a an auction do to buy a time to write a 10 minutes a slot uh during this time you can the and anyone can uh prove anyone can uh send as many can verify so can can send as many batches as they as they can miners could try to delay that but they will not they will not earn anything on that sense uh no it's not our it's another it's not just it's not a it's another story but depends a lot here depends a lot in the mechanism that

you are using so the equivalent of miners if you want in vail too it's the operators who you select from the approval point of view than the miner because i do understand that after that when it's on the l1 it will be like pretty much hard to change but they cannot chat so the only thing that can do a minor the only decision can take a miner is to mine a batch or or not you know if you didn't batch a batch maybe the next miner will will mine it here if there is some collision between miners and coordinators to do some stuff well there could be something interesting to analyze there but the ana miner will have to do something else we lose money just to do that because it's not going

to mind a transaction that's profitable to mine it so at least there is a cost that will not uh it's a it's an opportunity cost if you want that's going to lose um over blockchain like zcash and cello are doing ceremonies to set up a trusted setup is that the same case with rms in hermes we are using growth 16 growth 16 requires a thruster setup actually plonk also requires addresses but it's a universal process setup it's something that's run once it's already run so you don't have to worry about and and and for each circuit it's it's it's different

uh here is if we are doing this packing packing things of course if we are doing a growth 16 prover uh progressive sting proof we will have to run a trusses setup the same way we did in hermes if we are doing that in a plonk which is then you will not have to do this uh trusted setup ceremony here is probably the best idea right now is to do it in plonk at least at the beginning of the versions and maybe when something is stable and you just want to keep it as is and so on maybe you just do gross system you optimize run the ceremony once forever and let's see that would be maybe one approach but something that both things can be done uh a little bit related to the previous

question here okay so if i'm a user of i want to submit the transaction do i submit the proof for that transaction as well or is that the job of somebody else that is then putting transactions together it's somebody else that's gonna it's the coordinator that's do all this job and you will pay the fee for uh that will go to the coordinator for that job so i can still not do it myself like i want this transaction with this proof do it not in this so not not not in this not in this approach these approaches send the transaction to the coordinators problem because you you have many coordinators you have a decentralized system you will send the transaction to all of them and when they build the when they build

the the the batch with all the transactions collected from you and from other people will just do all these computations validators uh and we are we are thinking so validators is not somebody running a raspberry p in their home validators especially in our in in any roll up in general that are doing uh thousands of transactions per second we are thinking more in uh investments of uh thousands of hundreds dollars uh altogether you know just uh collecting i don't know two thousand three thousand transactions per second sorting ordering creating these proofs and so on this is not going to be cheap so the mindset for coordinators is another you know it's just uh we need

to think change a little bit the chip of a coordinator and uh maybe a staker or something like that and and the proof is for the batch not for each transaction the proof is for the batch all together exactly so this the program is taking as an input all the transactions that security and one of the things that we'll do is just check the signature for example that you have to do it inside the inside the inside the circuit but it's going to be a specific state machine that will do the signature verification actually this thing that we need it because for example we have this uh pre-compiled smart contract to check signatures okay so we have to we have to implement it anyway so this superstate machine for signatures verification is going to be

another state machine and some polynomials maybe with different steps because you know seeing that verifying signatures you have to do some uh maybe analytical multiplication usually one multiplication maybe have different uh field specific field multiplications and and you have like a two three levels of uh state machines that are linked together to verify a signature in this case a set of signatures hey what's about data availability did you find the solution to incentivize data storage we are not focusing on data availability

so we are assuming that you have some sort of data availability if a roll up just put the data availability on chain which is expensive okay but here we have some uh promising solutions about that availability one of those of course is ethereum to the zero sharding and so on this is one of the things but there are now there is uh there are other people you can that's working on that you know just well you can have of course a federated federated set of servers a kind of a validium on that set or we can have even i don't know i think polygon people were doing something about that availability that's cool and you know there are different approaches there

what we are thinking here as a roll up we are relapse so what we are here thinking here is to put all this data on chain at least in the first in the first version but we hope that some other projects solve the data availability because something that we need not for overlaps but for many for many other things now maybe filecoin i don't know that's that availability solution too is it possible for the coordinator which is creating the proof as i understand it to select the order of the transactions it's receiving

and and like the use case or potential malicious use case might be that let's say there's a dex it sees a bunch of large transactions come in it inserts its own order ahead of them and then inserts a sell order in front of them to front run that value exactly the same thing that a miner coordinator is like god for a while so he can select he's free to select transactions he wants to sort them and to include it in the batch the same way that the miner is free to select the transactions he won't of course have an incentive economic incentive to include it there and in the right way but a coordinator and a minor they share a lot of a lot of things so

from running from running attacks are well we know a lot about that in in layer one in layer two it's gonna be the same that done okay thank you you