zkSummit6: L2 Interoperability and implementation of Hermez zk-Rollup

Transcript

[Music] okay um what's a roll up rope is very is it's very simple thing so at the end is we are maintaining a state mainly at the state is a database of balances uh of people we have uh balance these people has this amount these people has this amount okay and this database of balances it's a current state it's a snapshot of a moment okay we store that and the idea is we we mercalize all that we put that in the merkle tree so we get like a hash of all together we have a root okay and then uh what we do we are what we're doing is we're forging match we are changing this state so this batch is a set of transactions that were actually

what it does is modify these states very much like a normal blockchain works but the here things is that the the blocks or what we have we call it the batch just to distinguish between the blocks in layer one and the batches in layer two just to distinguish this but we are creating these batches just is a normal ethereum transaction but we when we want to create a transaction mainly what we do is we we put a new state okay this is a new estate uh that actually mines actually forges uh a set of transactions so this revolution from state a to a state b with all these transactions and we put the new we publish this new state in the ethereum ethereum with a normal in a normal transaction we call it this fortuna patch okay and

the the properties of uh zke roll up is mainly that besides the besides the new state we also give a proof that this state is uh this is valid it's correct okay so it means it's a proof of validity proof we call it it's at the end it's a snark it's a it's a proof that's verified in the same smart contract and it guarantees that this new state is is correct so that means that all the transactions that are included in these bytes are signed in that all that there is no double spending that there is no phones no funds to send from one to the other so that the state is currently in the state it makes sense okay so that's mainly what we are doing in uh what we're doing

there is an important property that other labs needs uh to fulfill and is that that what they call the data availability if we are selling if if somebody imagine an operator that puts a new estate but this state uh it's calculated from some hidden transactions from the from the operator then the roll up would stop nobody would know exactly what's this new state so in some way we need a way to get uh those uh to reproduce these these states so this is and this is the data availability problem we need to in some way in this in this smart contract we need to prove that this data is uh available in the case of the or zika roll-up mainly what we do is just put all this data

in the in the same uh in the same transaction in the in the same blockchain but we put it in a very very very very compressed way we will see this data structure so this way what we can do mainly is we can compress this is a roll-up effect we can compress a lot of transactions in a single in a single in a single transaction there are other options validiums maybe they put it off chain or in federated systems and so on and there is a optimistic roll-ups that they don't put they don't include this zk indicate proof proving that and they are more based on gaming somebody can challenge that this proof is not valid and then they need to write a little bit more in order to find the lights but zika roll ups mainly what it works works that that way

okay so and well let's start going deep and whole what's what's the state ho ho ho what we have in this estate well this state is mainly so as i told you it's a mercury in this case in our case it's a sparse mercury we could use a normal mercury but we choose the sparse mercury because have some good properties uh for this uh but here what's in this in each leaf what do we have in each leaf well mainly what we have in each leaf is just a token it's a token id it's an idea of uh of which token are token zero is going to be ethereum token one but we don't know uh people can register tokens in the in the main net and this is everyone every token will be

assigned internationally so we have a token id we have announced of this account we have a baby jab jab public key here with uh here with the sign and the public see you see here the two the two the third and the the last one is this this is a public key we have an ethereum address of this account so we have uh this this address that means that can be handled by an ethereum address or by baby and of course we have the balance which okay this this account holds this balance so that's finally what we have and in each leaf we have one state and this is a structure we are we are we are generating here so mainly what we do is we get this we get

this structure we put them we hatch them we are using post signal in all the you know the roll up so this is the main uh hash function we are put putting the hash function and then all these we mark the lights all all together so this is what the internal structure of this very simple structure what we have okay uh well just a brief introduction of what sparse mercury sparse mercury is a tree that is it has if you want the uh as many levels as as as you want we are limited here for the circuit just to 32 levels but here uh sports market treaty can grow as much as as as you want and then it has to kind of uh well two kind

of of blocks this would be like a normal tree when you have here is just the hash of the left of the right and you go down to the tree until there is a point where there is only one on where there is only one uh one uh key value one there is only one one one place in this case what we do is we hash different we put a different hash and then we just put the kia value directly here so we can have a structure that can that can that can grow but just for the presentation you can imagine that's just a normal mercury and it works the same way okay so okay and the other important structure another important data structure of the roll-up is the

the transaction what are layer two transactions looks like well here is you see here a lot of a lot of uh a lot of uh information but let's go just one by one so we have a signature constant so because we are assigning something that we need we cannot reuse these signatures here here is this probably a hash of uh this is a roll up transaction and i have to release to move whatever okay so this is a constant on the uh there is a chain led because you know the theorem can have work so here are the transactions we already uh well we are we're just putting the chain id here the from index so who is the who is sending who's from uh uh the leaf that's sending the the funds the two index okay and the

amount here you see that the amount is 16 bits we'll see here that's uh that's very if you want we put the token this would not be necessary because we have the we have the uh we already have in the index the from index we already know that on on there but we decided to put here just for security reasons just for be sure that the the the user is signing to send this specific token and there is no conclusion there announce a user fee you see here a user fee of eight bits and uh yeah that's mainly that's really it okay there is the others i will go uh the other here well here is the destination can be a two index but can also be a

uh ethereum address or it can also be a daily jab jab and and it can be even a combination of these it must be it must fulfill this and this so we have uh these three things okay and at the end if you see at the end oh yeah at the end uh you see the signature okay so the signatory is a baby job it's uh edsa uh ddsa signature with poseidon as a as the hash function so we hash all these all these parameters together and we put it all together here let me go a little yeah yeah here is the the 16 the the flood 16 that we are using here

you see it's a five uh mantissa of ten bits uh an exponent of five bits and then one half week it's like uh this is because you can see the formula here but this allows to put any number with a precision of three and a half numbers three numbers and the last number can be a zero and a five this is the the half bit here so this is very natural way of talking about the money you know if you see here for example this is a kind of uh so we cannot put any amount there but we can set a lot of the normal amounts that a normal person would use on that the other is the other thing is that the feed the fee is just uh the fee is just eight bits and here mainly it's a table it's a it's a lookup table

of eight bits and uh we we go from uh zero 0.000 from zero the next one is zero though zero zero zero zero one percent we go logarithmically we have a lot of uh density in the what would be a normal normal fees you know something between 0.001 maybe five percent so everything is here it's more compressed and then we can go just uh ten percent one thousand percent uh ten thousand percent and we can go high so we have all the spectrum of all the possibles with uh more with more density in the what we understand that's the more uh normal ways there's a small

percentage of uh normal value for for for the for what you are sending i want to sell that here in hermes the the fee is paid with the same token that you are transferring so if you are transferring uh hermes tokens for example you will pay with hermes tokens if you are if you are transferring dives you will pay with dice so every every transaction goes to the we will talk a little bit later about the fee about the fees okay so and then here in the transaction you see all these fields that start with air view this is for the this is for the for the atomic transactions most of them are going to be zero here but we will explain later on about the atomic when we talk about the atomic transactions but

mainly this is the conditions that the other transactions into fulfill that's why more or less all the fields are repeated here okay so we have already what a lot uh i2 transactions looks like okay and how what the circuit does well the circuit mainly what it does it it's well we start with a node with a root okay we process a transaction we get a new route we process another transaction with a root and we process two thousand three sections and then we have the last the last route okay so this is mainly what we are doing yes there is a question or something yeah there's two questions jordan uh yeah so uh so the first is how is hermes network using dram based random

numbers how is it better than the starkware vdf and chainlink vrf that's first question and then there's a second i'll let you ask the first one first we uh well for the let's for random numbers uh you mean for the for the for the random beacon of the trusted setup you can check out if you read the chat yeah yeah well this is uh uh we are well we are using divrent we are not using starware because in the start where you don't have the the

the code for generating the proof uh open source so we decided to go to the run and it should be it's just for the random beacon uh it's uh it should be safe uh it should be safe enough we'll do exactly the same with the phase two we have the verification there and that's what what we have and then igor has a question too yeah that availability proofs are uh working at hermes for uh plonk based roll ups uh kcat 256 could be used to pass all data in the revolve home this problem with glow 16 bass uh roll up yeah we will we will explain we'll go on that we'll go on that later

i will i will answer you i will answer uh igor on that uh if if i don't answer during the presentation uh ask me again okay but you will see well let me let me let me just move well here what we do here is uh well we i i started to do this so we have this transaction so mainly what we do is we need to process we need to verify that this uh from going from uh not root to a new route uh it's fine by these transactions and well one of the things that we need to do is also uh what we what we do is we get all this uh data availability here you see that this data availability is very short it's the from index the

two index which is 32 bits 32 bits plus the mode which is 16 bits and the use fees so we get all these that availability of all the keys and we hash them all together so in the circuit there is only one input actually we'll see that in the in the circuit there is not only the hash of these but the hash of all the other also all the other inputs all the other parameters so at the end the circuit has a single single a single public input which is very cheap and what we do is we do an sha 256 of the data availability process plus a lot of things so i have another presentation for that so we'll see we'll see later okay so let's see a little bit more let's go

let's zoom in a little bit uh hold the uh roll up uh however circuits are organized well we have the main roll up here i have when i will share the presentation so here there is a link here so here's a main role up which is uh uh this is the the main project so the main circuit in in done in in the circum one maybe you can go you can push here so i don't know if you can see it so this is the main vola okay so here is all the inputs and here you see the parameters here is the number of transactions in this case it's going to be 2000 number of levels it's going to be 32 then the max l1 transactions and max fee

that we will see we'll see later okay so and this main role up mainly it's a placeholder for uh what well we have the transaction the transaction we divide the transactions in two parts actually it's at the code transaction and then we have uh what's specifically a roll up uh the roll up transaction the the transaction that we process okay we have some i will explain later on why we do that okay here of course with all these transactions we hatch them all together so we have here a huge hatch sha-250 that's cash inputs that takes all the inputs the data availability and many other things that we will see later okay and then at the end

it's important to see a fee transaction mainly what we do for the transactions is we collect we collect uh so in each transaction we uh zoom up we accumulate the transactions and at the end we get all the transactions of the different tokens we have up to in a thick in a block can be up to 64 different tokens so and then at the end we we just modify the state so we change the root we modify the state uh we add these fees to the sum okay operator defined by the defined it by the cause by the by the coordinator so some account that uh it's owned by the coordinator and this is added at the end of the at the end of the roll

okay so if go a little bit more on that later okay uh if we go in the here if we zoom in again in a single transaction what there is in the transaction what we see in the transaction well mainly what we see in the transaction are these two pieces the processor one and processor two actually what is this two pieces what it does it modifies the state so it goes to a leaf and it updates this leaf maybe or that dates or inserts as well we are processing so this is and why we have to well because we need to in the normal transactions we need to we need to update uh two leaves uh the the from we probably need to subtract some value from the from and the two so we need to

add into the two so that's why we need two times and this is we are having these two processors that are the biggest part when we are talking about constraints okay what we do in the middle well we have this uh state hash so this is uh the state that we saw before we it's a state and and put it as the input of the processor and uh it's good uh and i ha and we have here a balance of data the balance of data mainly what it does it takes uh well it do all the the math it do all the calculus it subtracts from one side it does from one side it's also when we do the deposit also the deposits it calculates the fees

uh it tends to feed so we do what what would we do what we can say the the math of the of the transaction okay and this is in this in this circuit okay we have a fee accumulator okay that we will see later on and two important things we have a signature verifier for layer two we need to verify that the signal is valid so if if the scenario is not valid then the the the the proof will not be valid so we need in order to process this transaction we need to have a valid signature that's important and of course we have the request for the atomic transactions the verification of the other one we'll see a little bit more on that okay okay with with this we have very much um a transactions so a roll up that

works very good if we are only in layer two okay but what happened how we how do i deposit to the layer one how do i deposit to the layer two from the layer one and how do i exit so well let's start with uh with the deposits okay for the deposit what for deposits or what we have here is a special kind of transactions that we call l1 transactions so it's a letter one transaction is a transaction that somebody doing the smart contract you do a smart uh maybe a deposit in the smart contract and then the operator needs to process this to process these l1 transactions we have different kind of transactions this can be a deposit can be a transfer but let's let's think about the deposit which is

uh the typical uh l1 transactions well what we do here is um well we have a uh i mean what we have is a queue of queries okay so when somebody puts a transaction we have we put it here in queue in qa1 okay when somebody else put another deposit it put it in queue in in the second in the second slot of the q1 okay and this queue is limited to 128 slots if there is 129 then it's gonna be put in the in the next one of the qe2 and so on so people is adding transactions on that okay and uh what uh the the from the smart contract what we do is we force

the operators to uh forge all these l1 transactions uh um every uh every five minutes so so uh when an operator forges uh fortunes these l1 transactions then it can forge as many other from as many other uh batches for during five minutes but after five minutes the next operator the one that at after five minutes will be forced to forge the next kiwi so we are in some way we are processing all the cuis every five minutes we process one uh one queue and we force that buying smart contract so this way there is no way that the the the balance

uh the deposit is gonna stay in the in the middle in the in the limbo of the of the smart contract we know that everything is going to be deposited okay um here we have the data structure so mainly what we are doing here we are we are we are constructing that in the same transactions in the little one transactions we were putting here we have what we have in these transactions we have the from ether account so when you are depositing is the from of who's sending this deposit uh the baby jab the baby jab jab anybody can choose which baby jet jab in this case are compressed it's 156 bits um from index um you can do a deposit on top if you're suffering this but if from index is zero then that means that

you are creating an account actually okay how much this is set it up by the smart contract so when you are so you need to of course you need to if you are if i'm depositing dice of course the smart controller needs to to check in some way that you will send the dice to the to the wallet smart contract okay um the token id and uh the token and also in this transaction in the same l1 transaction we can do a transfer so i can do a deposit on top of something and maybe sending this to somebody else exactly in the same transaction why it's possible that because for the deposit we're using just the first processor of intersections and then we can use the other one just for for for the

for the destination so in the first processor we are adding the lot amount we are subtracting the amount and in the other one we are adding the amount this is very useful because this allows for example to do a single payment in the layer one transaction but uh the second one received in the in this uh automatically in the layer two and you are doing with the central with the same transaction you are doing one single deposit okay so this is and uh this is interesting because with this we can do uh layer one can do a transfer for sure i can do a force transfer okay or i can do a force exit we will see it later at the end is uh we are what we are doing is is this okay um a cool thing of these l1 transactions

this would be like what we call it the user transaction it's a transaction that the user do in layer one but um in um there is another so there is another kind of layer one is an operator before just before where in the same transaction that's forcing the batch just before forting the batch they can add l1 transactions there okay and these l1 transactions mainly is for creating accounts so an operator can create uh can create uh [Music] can create an account there okay so this is very interesting because this allows for example uh to send from layer one send ether or any token to a user

that have no account yet so have no leave in the rollout it doesn't exist in the rollout but it exists in the account maybe half an ethereum address or has a baby jab jab address already so i'm able to send that so i will process i will i will generate this transaction i will send to the to the to the to the coordinator and the coordinator what we'll do is well in the same in the same transaction of forcing the batch it will create the it will create the the account and after greeting the call will process the transaction of course the transaction probably will have to have a little bit more of gas because operator needs to pay for these other layer 1 transactions but this can be very transparent

uh for for for the user okay and what include what we include in this um uh layer one coordinator transaction well we include um a signature here a signature mainly is a signature that's generated by the the the by the receiver especially uh just to in some ways to link the ethereum address and the baby jab jab address it's a kind of uh alpha rights uh this baby jab jacket for hermes roll up creation you are signing so you are proving in some way that you have this uh uh ethereum this ethereum account so this ethereum account that this may be job address it's uh uh it's a it's linked together so this is created

here of course we put the baby jab jab uh the token for this and the serial mother so that's mainly what what it does it creates this account but with this property then in the role in the roll up in hermes rob we are guaranteeing that the owner of the baby jab jab and the owner of the ethereum address in the leaf is is always the is is null or is the same it's it's it's controlled so that's why we are signing um with one key to the other okay uh free processor we explained a little bit before but here we go a little bit more in in detail um yeah let's see if accumulator step so so

here what what what we do here well let me let me just start start here so mainly what we are doing here we are accumulating we have in this case we have uh 64 accumulators okay and each transaction generates a fee to charge okay and it's added to one of those it's added to one of those accumulators okay and this this one goes so and this uh this goes accumulating and at the end of the accumulator there is this fee transaction but mainly what it does it uh it actually uh the the the root of there so we are the fees the coordinator get the fees in the layer two that's interesting because we're using the same layer too to collect the fees in here okay um let's talk about the axis okay how

we having okay we know how to transfer things in layer tools we know how to deposit things but how can the users exit well what we are doing here mainly is um once when the user is sending to the address one which is the div one which is a special address then that means it's uh an exit and when we detect that's an exit mainly what we are doing is we are maintaining another mercury so it's like another state it has exactly the same format that the roll-up state but it's a state that in each rock starts from zero so it starts empty and we are adding there all the deposits that are exiting so here what we do is

in the process to instead of modifying the old root state instead of modifying the old root state what we are doing is modifying the uh the exit route so we are creating another tree that includes all the uh the tokens all the all the money that's exited in that in that in that block so uh at the end we have like at the end of the of the of the so after that all the transactions we have a new exit route that includes all the exits that happen in that in that in that in that block this exit 3 is maintained in the smart contract and then we can do a withdrawal so mainly the withdrawal what we need to

prove is that we we have some we have some key that belongs to the to this exit route and so we have some tree that belongs to these exit routes and of course that we didn't have a kind of nullifier that we didn't withdraw it uh before and all this we can do it we can proof it with a normal miracle proof which is a little bit expensive to do it in in in ethereum because poseidon in ethereum means expensive but we can also use a zero knowledge we can also use a small circuit just to prove all this the signature and the on the merkle tree of uh of the exit and uh i must roll up our allows more things maybe with an exit that there is just a single exit in the in the in the in

the batch it's going to be cheaper to do it with just with a normal mercury maybe one level two but if there is more levels then you can you can go to the to the zero knowledge to zero knowledge sequence okay so here is how we do the exit reconstruction we start with an empty tree and if it's an exit then what we are doing is we are adding that into the exit but it looks like it's the same it's the same processor we are recycling this processor because we are actually watching a tree that's exactly has exactly the same format that the normal that the the standard r3 and at the end we have the x3 okay uh yeah and this is what i mentioned you before

okay so all these because when we're processing for example these these uh these layer one transactions well we're modifying the state we are modified uh here the layer one transactions we are modifying the state okay so we are creating new accounts and so on so here what we do is well we collect what would be all the public inputs if you want our public input outputs and we are packing all them and doing just a single sha-256 what we include in this public in this public in this public inputs outputs we have the well we have here let's start with the third one the old state route the new state board the new exit tree so we have these these these

dates we have all the layer one transaction for data you know all these uh uh well all these oh sorry all that all so here of course the layer one transactions yeah we we have it in the smart contract but we need to guarantee that this is current but what we are processing in the in the input so actually what we do is we get all the we put all these input we include in this hash so it's like if we put all these everything that we have in the smart contract and we we put it in the circuit and then we in the circuit we we check that everything is exactly what you have in the smart contract so we are processing exactly these layer one

transactions and we have um so all these layers we have all these one transactions we have all this layer one layer two this is what's that availability the ones that we talked before you know these four fields uh from to uh amount and user fee here we have these 64 well this is our the deposit address of so where the fees goes on the operator so the um the the what the mechanism is the operator just uh sensing the transactions put this this fees uh so this free those fee indexes we put it in the in the in the operator and then we hatch them together so we see that actually the the

these fees so these these uh fee indexes so where the transaction fees goes it's also valuable it belongs to that availability we know what but that needs to be included in the in the in the data availability in the so in the call the call data of the forge block uh transaction we have of course the chain id here too just to to not for for for relaying relaying attacks um here we have also the current badge this is what we see we'll see that uh more a little bit more later and here we also have what's the odd last so the all last index and the new last index so when we are inserting transactions here we the smart contract needs to keep control

on what's the last um the last index relaxed leaf that's inserted if you have four leaves when you create uh when you create three new accounts then you will have three more three more three more leaves so so we need to keep control on that so we need to be sure also that the the indexes goes the smart construct keeps uh covering with uh with with the state and we hatch them all together and we have this single public input and this is the single input that goes to the public circuit okay yeah i'm sure there is a lot of questions i don't know if we are yeah yeah we're good sometimes doing great on time

and uh i'll let you read it maybe i'll let you read the question right off the chat window i just wanted to flag that there was a question yeah let me just read there because i have i have a ball here okay yeah uh which one is the i don't know yeah how many yep how many how many what okay sorry go on go low below the question is how many transactions have yeah okay how many transactions can be packed in one block uh and whether dynamic block sites can be uh super parts no it's uh well i here we need to see because we need to distinguish between what we call it a block and what we call it a batch

okay a block is for layer one we reserve this word for layer one and we talk about the batch i i understand that we are talking about the badge in a batch there is a fixed number of 2000 transactions there is one kind of transaction there is a knob transaction so it should be less than 2000 so 2000 transactions at most okay for layer one transactions um [Music] okay for layer one transfer for layer one transactions uh we accept only uh well the user layer once is 128 okay and um operators layer 1 transactions are up to 256 so if you just used two

users you can do active actually 254 um operator transactions you can end up until 256 with uh layer 1 transactions and the remaining transactions or even less or so until 2000 are just layer two layer two transactions here uh let me just go back a little bit but uh here in the right transactions here you see states and several transaction states actually is all this logic here is internet of this logic it's a layer one it's a layer two it's a uh it's an exit it's not uh it's not an exit so

all these um states or all these uh state variables are computing this uh specific uh in this specific circuit here and then there's another question about uh or just a clarification on uh hashing to a single public input and is this a technique to save on gas fees uh or some gasoline verification this deficit really saves a lot of uh of gas fees okay and but it's also uh it's also very convenient uh well we already have uh we pack them all together so it's also

safe constraints inside inside the circuit but yes mainly it's for saving saving fees doing a hash in the in the ethereum is very cheap and then we just get a single input and this input then you see the prover is much cheaper it has one single just one it's one it's just one field multiplication it's one just one group multiplication uh for the for the for the for the verifier so that's much better okay that's uh i think that's all the questions that we have for now okay let's so let's move forward okay see how we go a little deeper in one of the specific circuits this is a fiat correlator step so this is for example so well if we start

from here okay uh yeah um now we started from here okay so this is accumulator step so we know i'm zooming here the fee accumulator how the accumulator would look like so the fee accumulator will look like you may be so this like there is 64 fee accumulator steps okay and each accumulator steps mainly what it does is this is like okay you you start from an accumulator this is the input of the accumulator and here in the multiplex we select uh if we if we here we select if we add it or not so if if if it's not if it's not added then the accumulator just copied to the

output if it's added just we select the one that's added okay and what what here we have an internal signal here that this is this is it's already selected or not if it was already selected then we don't do anything else okay so and when we select it here when the fee plan matches the token so this is okay this is this is the right one if this is the right one and it's not selected yet then is when we added them if not then it goes and it's like already was selected the next one is going to be selected so here is just uh

the example of a very small circuit okay that's a accumulator step and then when we put them all them together we we just put them this is a field emulator of a single transaction and when we go here and the calculator we we accumulate all of them here and at the end we of course we have the transaction fees so this is for example how we who we have on this okay here's the last another example you know just as another just to have a detail of things how it works you know the last index id here is if it's new account that mainly what we do is we increment so we have this kind of uh circuitry

for for uh computing the new last uh the new last uh id okay yeah one of the things that i announced in the main stage and maybe i want to go a little bit deeper here is uh the mass integrations we are prepared for massive migrations and how it how we will it work well mainly here we have this uh the hash of the we have the hash that includes all the the data availability we have all these from and too so how would it work let's see the how it would work in hermes massive migration okay so imagine that there is a new version you know it's hermes too or do it's a

i don't know um layer two or something like that you know there is another layer two uh thing let's let's take for example that's like uh hermes two okay and we want people just to move from layer one is our decentralized and we want people to move to layer two in a massive way so here what we do is we will create this uh destination in this case would be the hermes uh tool we call it the destination smart contract okay but this dsc for for for for abbreviation uh this uh contract what we do is we'll register a new account in the roll-up maybe we do a deposit of you on the zero deposit so we create a leaf there okay and then the people can start send

tokens to that destination to that destination uh uh to that index id to that destination leaf okay in breakers those uh to the destination to the destination index the the index is means the destination so is that the index of this follow-up okay um then we have okay in the roll-up we already have funds received from many accounts in a single in the single roll-up account so the smart contract can again do a a

force force exit a force exit is a layer one transaction that's sending okay just do a force it's like force and exit it's only from the layer one of course because the operator is forced to mine this to forge these these transactions then the the exit will be created okay and because it's created then uh it can withdraw uh uh so one once when sexy that this smart contract can can withdraw it but the cool thing is that we can use the data availability hash to process all these transactions we know what the transactions that this account received and we can

have this data availability hash to process those transactions in the in the in the layer so in the layer two of the destination prolapse we have this hash so we can process this new rollup that they will insert these addresses we can use the state and we can use the transaction so we can use all the information probably creating a circuit to process these uh these massive migrations and update the state of the new of the new broad but as you see in the later one there is only one single withdrawal there is one single transfer of uh there is one single transfer of the aggregated transactions uh until now

of the of the uh of the uh of that of that token of that of that contract okay so this is a little bit how it works so it's possible and of course requires some work it will require some work in the destination address but uh but this is actually this is actually possible there okay i see some questions here let me read let me see how many um i might let's see i might have massive i have missed your explanation but this is a 256 hashing

all these um into a single public input a technique to save gas oh yeah we answer that yes okay um contracts are great well first of all we want to disable that as soon as possible that's the thing but in the beginning we have some uh security mechanisms that we it's going to be enabled at the beginning we hope we can disable that very soon and one of those is the contract upgrade so in case there is something wrong with the contract uh we have this the the thing is that we cannot upgrade so that the upgrade has a one it's gonna be one week delay uh for that but as i told you i hope that we can just uh fully centralize that means that

this smart contract at some point will not be able to to upgrade maybe we can use massive migrations to create another wall up but but it's gonna be always knocked out it's not gonna be forced uh on that there's a question in the chat jordy about the previous slide yep um so one additional circuit is used for dsc for uh bucket token yes exactly in the in the in the recipient it will it will process it will process uh yeah an exit when you do an exit you will process but you will have

because you have all the information there you have the hashes of the all this information discussions can be like the input of this uh of this new circuit and then the circuit will process uh in the domain specific of the destination code yeah that's mainly how how it will it will work so one additional circuit is used for dsc for uh budget token transfer exactly yeah yeah the destination will have to have their own circuit to process all these massive migrations that comes from the rule but we have all this information we have it packed and high so it should not be difficult to process uh to convert this uh this data and that's already hashed

there to uh domain to the specific of these two of the of the needs of this new block we don't know how this roll up will be maybe using different corp and maybe there is some conversion there but definitely it's it's it's possible to uh it's possible to you have all the information in the smart contracts and all this hashing can be inserted in this destination circuit this is how it would work i don't know if starli stands for that did you see that you saw the follow-up question i think so one circuit for dsc smart contract yeah there's one

battery and one for smart contract yeah at least one yeah maybe there is others but yeah at least one cool okay so another thing that's the sexy mechanism i don't want to go deep in here but that's well the first the first again this is a safety mechanism that we will start in the in the beginning but we want to disable that very fast uh this is just it's a kind of escape hatch for uh just for the beginning so how it will work well first of all if uh if this is disabled people just you have immediate withdrawal the system should work and we hope we can enable this mode uh very soon okay but what would be in

the beginning well at the beginning it's going to be two kind of uh withdrawals it's gonna be a direct withdrawal and uh delayed withdrawal direct withdrawal and the idea is that the direct withdrawal is going to be some uh red limit so it's not going to be possible to directly maybe decrease i don't know one one um you know just uh million tokens of each token per second actually it's uh it's more complex than that it's uh there is like five um ranges of transactions and there is a limit you know for limit for uh high value transactions a limited for less value transactions and so on there is like five limits and we can and this can be controlled by uh uh uh

governance okay but this is but then if this if this system is so if the rate is full then the users can always do what we call it the delayed withdrawal delayed withdrawal just goes to another smart contract that's not going to be upgradable we call it withdraw the layer and actually this will uh so you will be able to get the phones uh later on you know maybe in just uh one hour in two hours in one day or in some market in any case this by smart contract this uh this this can never be more than two weeks so this is the maximum the maximum delay uh that that that can happen okay and during this during this delay

so the governance can can switch for example if there is a if there is that for example if there is a problem and we detect some some problem in the roll-up we can um just uh put the very very uh so we can stop direct withdrawals just by putting a very low uh limit okay so we just stop without so everything needs to be go to the withdrawal delay and we can delay that to maximum to two weeks we can never get the funds but we can delay on that so we here we can analyze things we can analyze thing maybe we cannot update the smart contract but see that if we cannot take the the rollup smart controller but we cannot update this so everything that's in there it's going to be there and the only

thing that we can do then is this withdraw the layer we have a trigger we have a trigger button you know escape hatchbuton that in case that we see that's something that's mentioned for example uh a poseidon break you know something breaks a position or something really crazy uh happens on just a huge back it's we phone then what we could we do is we just we have an escape hatch and then uh this the phones and these with driver without the layer will go to the to some uh it's a multi-scene with trusted members uh of the trusted members of the community some white hats and people that's trusted but it's not it's not us as i told you we want to

disable all these mechanisms like this the direct withdrawal for everybody and that's it and we hope we can reach this uh state of maturity um very soon but we will see and this is uh we need to be comfortable and this is just some safety mechanisms that we want to be sure that everything works in the right way especially especially okay uh another thing that have we already talked about the atomic transactions how the atomic transactions work well mainly what's here is and here is what we have the gold transaction and the rollout transactions then the code transactions mainly what it does it just gets part of the it's part of the transactions and it's um

so that imagine that they send these centric transactions you see this one that's black arrows goes here okay so here what we send is we send it to the last four transactions and the next three transactions okay the information of these transactions and then we multiplexed this to a single transaction and this is a selector so the operator can select which is the the the pair the other the transaction that's related that's related okay and the request verifier mainly is checking that this that what signet what we saw at the beginning matches us with that transaction this allows us to for example do an exchange so i you i will send you this die but with the condition that you send me this ether

behind so there is this other transaction that's minded in the other direction and the other way around so we have these two things so we have this uh kind of linking transactions and we can do these atomic transactions another thing that we added recently is a time a time limit so we can in the transactions we have uh the timing if we go to the first slide uh here you see here all these requests transactions are from and here the other thing is the maximum batch you see here uh i don't know if you see my cursor some somewhere but that's you see here uh the second block and someone is a maximum batch and so this allows uh to create a transactions with a timeout

you know it's like if this transaction is not uh forged by this batch then this transaction is invalid and that's the motivation where we are adding uh putting as an input hashed but as a public input the the the the hash id here is see here see the last the last the last thing that we have is the current batch okay so we have these uh things that i think can be very convenient for for exchanges or for for uh payment channels for different applications that can run on top of of the of the of the of the of the roll-up okay um yeah and the last detail is that

uh it's a more technical thing is that you see here so instead of uh in the transactions instead of computing the route in a serial way here is we have a transaction we compute the root the transaction computer this is very slow to process because there is this dependency especially within in in in circum so mainly what we do is we do a trick here is that what we do is okay so instead of calculating all these hashes in sequence in order actually is uh what we do is uh okay we just as an input we put all the inputs of all the transactions so we can process these transactions in parallel and then we add a single constraint that the output of these transactions is

equal to this actually we are not really solving the problem we are just translating the problem outside the circuit but outside the circuit the things are much cheaper to compute and we can do much uh faster we can do it in parallel we can use other techniques and here in the circuit we use it this way so at the end what we have is a parallel way of processing the transaction so if you analyze the circuit you will see that there is these intermediate signals you will see so just it's just for optimization optimization things okay so this is my talk here this is a brief introduction of how hermes network works how the especially how the circuits work

we are looking for people to take a look at the reviewers we love if anybody is interested to to review the the the code please please let us let let's know we will we are probably going to create a group of people that wants to review that as you can imagine um it's quite more or less it's quite easy to find people that reviews for example smart contracts but it's not easy to to find people to review uh circuits because it's more new technology and especially circuits in silicon and so on so anybody that's interesting it will be very helpful there is some some budget for that so just uh anybody that uh wants to join please contact us with great

personal discord account or something like that but just uh join us and that's the the main goal if somebody likes this and wants to know more about silcom about hermes and that it's please contact contact us and yeah that's that's my presentation let's go for more questions great so we have uh we actually have someone who's raised their hand up live um so i'll bring them up now it's garrett mcdonald and then we have another question from the chat so let me let me actually see if this works here hopefully we can get garrett in a second and and then take that question then i'll i'll go to the chat okay there's a little bit of a lag just so

you know it's already between the chat and the and the actual um okay let me see what's the last get the loss yeah um uh okay we'll just take leo's question and i'll all dm i'll dm garrett see if he if he meant to ask a question i'm going from dance i'm going up um can you talk a bit about performance how long uh does it takes to compute uh proof uh of the circuit for 2000 transactions oh yeah uh approve the circuit right now uh where we are just uh just uh checking what's better in just in a cpu or gpu but it takes about two minutes uh to compute these

these this it takes about two minutes to copy this proof depending on how many transactions if they are zero or not but the maximum the limit that we are managing is about uh it's about two minutes next one uh thanks a lot for explanation jordy yeah you are welcome yeah i think you answered those you answered those uh kind of in the course of uh of the talk so uh we'll ask here so does anyone have any uh any other questions for jordy and i just paint garrett to see if he uh if he wanted to ask his question live oh there we go where there is any tool to help uh transfer smart contract uh smart contracts to circuits uh no no it

doesn't work that way so uh you need to build the circuits actually uh we build silicon you can go to silcom let me just write it down here this is uh but go to github find silicon it's simply compiler which is very easy name and uh with that you can build uh there are other languages but this is well this is the one that we are using here and it's uh it's very it's very easy there is some tutorials and there is also another for example there is another zk um i guess you'll need uh talk that i give like one year ago talking about silicon you can go through there and it's very easy but you need to comp to create the circuits in there and

and it's not just which is the it's a tool and there are other tools but the tool that in some way it converts this circuit in uh well you need to do that setup and all these uh you know all the all the sequences but at the end you end up with a validation key annotation keys but actually you can you can you have a smart contract where you can validate this proof okay but in order to build circuits you need to go to a specific language for building uh circuits there are circum is the one that we are using here but there are

others in the space you can check which one it has these different properties circum is like very straightforward uh how it works you know it's just uh you just connect it's very like for electronics right it's very it's like a circuit you need to connect blocks and just join things and it's like a puzzle and then you build the things and this is how uh hermes circuit is on cool and then there's uh we got i think so it's running out of time for the session we have two more questions i think we can probably get to both uh leo in the chat has a follow-up question and then uh and then we have another one just below that so okay why don't we take those two let me see leo

uh thanks for the two minute number uh how many constraints does your circuit have 2 to the 27. so one 128 millions [Music] yeah we can talk a bit more about how long yeah i i think it's i'm done right it's it's i'm forgetting anything i don't know if in the past i forget anything yeah so there's one more uh there's one more question below uh will all circuit code be open sourced it's it's already it's already open source it's already there i think i see somebody already uh uh oh it's stunning okay uh tony already put the

oh no it's not let me just put the let me just let me just go to the link well you can you can you can see my screen here so uh it's already open source here is the here is the contracts here is the circuits let me just put and paste this in the okay oh okay okay somebody really put there this is the sequence but here lms network you can see here in their ms network we will publish everything it's here right now we have the contracts on the circuit which is mainly the protocol and but here we will publish also the the contract circuits have also the well here is it's private already but we will publish all this we will publish here we have the hermes js with for the api

the hermes note we have the dogs contracts this is private you see most of them are private but we will release when we clean up and we put something that it's easy to read on that synchronizer testing opportunity but here is a little bit internals okay uh but here is all the work that we are doing right now in the in the in the in the hermes and we were polish uh in the upcoming in the upcoming weeks as i mentioned in mainly stage uh the idea is to have a running test net for christmas more or less and once we feel comfortable running this test net then we will we'll go made it hope this v very soon but you know it's like uh

we'll see how the things go but uh uh what i can tell you is that uh we have the full team very committed to publish this uh as soon as possible but at the same time as safe as as possible and we will not stop till we do it so that's that's uh that's our commitment and that's what we that's why we are working for i think it's important having a roll up of these properties with the scalability you know just having this real number of transactions with scaling all that and having uh um this in the space and understanding how the relapse will work this is very important for for uh for ethereum in particular but for the

space in general you know roll ups uh i really i really believe that are the the future for blockchain scalability and this is the best thing that we know right now so uh it's really an important uh step uh for the for the for the scaling space just together together with oh yeah i think we're out of time so that's that's good just let me say that uh i'm very happy for example that the theory right now it's also they it was funded you know so it will launch like next week the ethereum two and this is very important also for the scalability especially for the data availability in there so that availability uh together with the roll-ups this actually is what i really believe

that i will bring these two mainstream that's at the end people use crypto everywhere yeah well thank you very that's a great call out jordy because yeah big big accomplishment for for the ecosystem today um and thank you very much for your presentation i know we all i think we all learned a lot and uh i would encourage everybody in the session here to go check out our next session right after this i think leo from al grand is going to be presenting um a technique for aggregating vector commitments called point proofs so i really encourage you to check that out after this and i hope to see you around the rest of the event today thank you jordy thank you everyone see you you