L17 - zk Circuit Architecture | by Jose | BlocSoc Lecture Series

Transcript

um okay uh welcome everybody to this uh session in which we're going to provide an introduction to the polygon ZK TBM uh first we're going to see what is uh what is a ZK rollup because the zkm is is a project that builds a rollup and then we will see which are the the main parts of the ZM um as well as um all other tooling that we have in well first let me introduce myself I am Jose I am an associate professor at the University po Technic of this is University marcelona and I am collaborating with a project with

polygon since three years now so and I am in charge of creating all the specification documents May research and some trainings so yeah let's go yeah so we want to scale ethereum ethereum is a layer one a layer one uh is a layer in which we have an State and the state is is the state of uh list of accounts these accounts have balances they have NS they have bu if they contracts and so okay so we have the state of ethereum is is a is a bunch of of data okay and the idea is that uh then we send uh in the network we have a

block uh we have to arve to a consensus of which is the next block to apply and and when we execute the transactions of the block we get a new state which means that we have new data I mean data of the of the accounts may change because we are executing the transactions and so on and so forth so we are just executing transactions and these the execution of these transactions is making the state change or progress so this is the layer one and all the information all the transactions in a block are available in the network and they are executed and this is one of the I mean this this provides a security a

high degree of security because everybody needs to see the transactions and everybody needs to execute these transactions however is also has some it it uh it shows a here because uh everybody needs to do these these operations and and this does not allow to have you know Big Blocks or or blocks uh very very frequently I mean if we have a high uh transactions rate then maybe there is a problem here because everybody needs to process and and then if we make here a lot of transaction per second then um the networks in the the not in the network

only the most power po network will will be able to do so so we have centralizing so yeah here we have some problems regarding capability because we want security we want we would like security we would like uh decentralization and also we want a high performance so uh which is uh the approach that when that we're going to do and E theum in particular vitalic already said which was which is going to be the approach to scale the which is build uh layers okay well before the state uh the state is just uh a summary of all the information all the current state of the network

what we call the state in fact is a hash all the state data and in form of a tree a Mer tree so virally I would say that most of the blockchain systems just uh represent the current state of the system with a hash which is many times is is just a hash three of all the information so this is what we this is our state so yeah as I was saying uh there is the scaling approach of ethereum is okay let or let third parties build uh some layer two six steps okay and a layer two is essentially like a new blockchain system

or or is it's a new chain of States H that and these states they are going to change also because we have transactions that are applied to this state so these are L2 transactions and and here we want to have a list of transactions that we also apply to the state and we compute them in your state the thing is that uh one way of scaling is that in this approaches of of Layer Two not only a few entities they are going to compute this state okay and we need to see how to make this secure also so this is the idea just to build a layer on top of layer one which has its own State its own transactions

and is secured by L1 by the layer by by the bottom layer so here I have a bunch of questions to answer which is okay if I'm a user uh how do I send transactions and who is going to receive this transaction okay the second one is uh how we are going to make these transactions publicly available if so I mean there are different systems we're going to discuss the different approaches that we have here but uh yeah if transactions have to be available how do I make them available uh another question is uh okay uh who is going to process these transactions and how how is going to I mean how is going to be the processing of these transactions if

everybody in the networks in the network needs to do this in in a high frequency I mean then uh it is going to be hard to scale so we are going to see some strategies so that only a few people have to process the transactions H and then what type of applications our Layer Two is going to support I mean it is going to be a simple layer or for example we can build some uh I mean we can just for example build an Layer Two for managing tokens alc2 tokens for example or are we going to provide the full capability of of ethereum I mean how we going to build a

evbm the the layer two is going to be able to process transactions regular ethereum transactions that the ethereum buildor machine will process okay well this is the approach I mean at the beginning most of of the layer two were like simple layers and now virtually all the layer tools they are able to process regular transactions of ethereum so now let's go to see how we can answer these questions um which are the options and then we will see which is the approach of the polygon ZM so uh for uh how users they are going to send the transactions uh they can they

can send transaction unicast I mean we can have some note here which is going to receive the the L2 transactions of all the nodes in the network okay this is the unicast approach in some way is well it's centralized because there is an entity here receiving all the transaction okay so um so we are going to send the transaction to this node and then this node will process them we can also build a peer-to-peer Network to do so is more decentralized but is probably more difficult to manage and then we can also relay on layer one and we can also send the transactions to a Smart contract

okay and this smart contract is going to uh process all these transactions in some way okay so this is this is the approach the three approaches that we may we have later I'm going to answer this question I mean which is the approach of polygon uh and then uh okay how Layer Two trans are made available well we have several options here we can make all the information of the transactions available in the network in the L1 Network um if if this if this is the approach then we call that this is a rup okay because there will be a transaction in layer one that will contain all the

information of the L2 transactions so we are rolling all the transactions inside an uh L1 transaction so this is one approach and when data is available in layer one we say that this is a roll um another option is just uh to uh not to put the data on on layer one but just put a hash a summary of the data in layer one and then we we talk about validum or optim optim optimism um so one option to put the data is is

is put it on layer one on the field of the transaction okay uh that is able to carry data which is the the call data the call data field is able to uh put put data on the network so if this is the approach that uh with this is the apprach with which most of the layer to now well this is in the future but this I would say is already already here and we are most of the layer tools are starting to do some tests with this or some of them are even more less in production uh well is to use etherum build a system of data shards which are

chains in which we can post data uh there is no execution there it's just po the data and well most of the of the layer two systems they are just uh see seeing how to uh put the data of the the layer two transactions inside these data charts or what inside the data chart what we have is is a block and the block inside has some transactions which inside have what we call what is a block binary large object which is the transaction okay so and the idea here of data shs or this EIP that is currently uh being explored by most of the layer

TOS is um to but the idea here the main idea behind this data shs is that the data is delet deleted after some time uh in ethereum we talk about three weeks so and this is uh what makes uh this transaction much much cheaper than sending uh regular transactions in in in the C data which is supposed to be more expensive so well talking about rollups is uh what we what I said is just that the layer two transactions they are included in a L1

transaction uh so and and data is available in in Mayer one right this is one option this is what we call a run and then we have a aium well aium just doesn't post all the data in the L1 transaction but just a hash okay so hash of the data summary so and if you want to know uh if you want to get the uh the L2 transactions then you have to ask someone okay typically here we have some committees in in polygon we are also building validium we are

building both uh mums which have which do not provide data availability in ethereum and also rups which do provide the that availability in our case we have like uh what we call data availability committees which are several uh here we have like several entities that uh they are to post to be trusted and when you ask for the data they will provide you the data okay but obviously this approach is less is less decentralized that the data availability committee is more centralized but it's much more cheaper I mean because you know I mean just

recording the hash of the transactions in layer one is much cheaper than what rollup does which is record all the data okay so this is this is this is the tradeoff here um so now talking about uh uh who is going to process the transaction and how here we have like several options uh I mean to save resources we can do the execution in a centralized way I mean there is a there is an entity which is going to receive the transactions it's going to process these transactions is going to compute the the state so this is the centralized execution so in this case users they're

going to send the transactions to L2 operator which is a centralized uh operator and and and then this is going to compute the new state it is going to create uh lists of transactions there it is going to apply this transactions to the to the state and then it's going to compute the new state and in a smart contract it will record all the sequence of States um however this is uh an approach which is very centralized because this it is I mean we cannot dispute the uh State computation to the operator because the operator here is I mean is

God is is is powerful in the system and you there is no way to to uh to to dispute or say okay this state is is wrongly computed okay so this is an approach that is virally followed by nobody because there is no way for a there's no way to say okay I there's no way to say this state is not corly computed the centralized execution here has I mean the operator has too much power and most of the solutions which are based on this idea use what we call optimistic execution in optimistic execution the operator is going to compute the new state but we will have a period of time in which anybody can uh

provide a proof uh we call it proud proof um about the fact that the state is not correctly computed okay um well this is and the main problem of these systems is that this amount of time may be quite long like one week for example okay so we left time for users to just provide this froud proof If there is no froud proof we assume that well the state is currently computed okay so this is this is what we call optimistic Solutions and there are many of them in production and they are managing quite a lot of Fs in the in the in the

ecosystem um and then we have the this type here which is uh in which we have a ver verifier uh here the idea is that uh I mean the we replace the L2 operator either the centralized or the optimistic and and here what we have is aover okay and uh the approver what is's going to do is to generate a proof that uh the I mean that uh taking one state as the initial State and then applying all the transactions to this state the resulting state is exactly this one and I'm going to provide a

proof that is sound I mean you cannot cheat so provs are going to prove the validity of the execution and and and these systems are cryptog cryptographically sound which means that you can and then we're going to talk a little bit about how we build these systems uh but uh essentially you cannot cheat you cannot produce a valid proof If the state if the change of state is not correctly and the idea here is that is this K who does the hard work here and so the the heavy work here is by the Prov I mean the proving the

proving uh process is quite resource consuming it is going to consume quite a lot of you know CPU RAM memory RAM and also CPU so um but then the the verification uh the appr produces a proof okay produces a proof and we also this is the proof and we also send the transactions that L2 transactions and then the thing is that a smart contract can verify that the proof is is correct and and essentially that the state change is correct so the verification uh process is really light

uh is so light that a smart contract in a in layer one I mean a smart contract in AUM can verify that the proof is correct so and this is and here there is no way I mean we we don't need any any dispute system or any fra proof because I mean if you are trying to cheat you will I mean you cannot cheat here because you cannot produce a valid proof uh I mean you cannot provide a proof for uh I mean uh you canot provide a proof that is proving a a bad state or incorrect State and uh the cryptographic techniques that we use here are the zer

knowled technology uh despite we don't really need uh zero knowledge in in meaning that here the application is not privacy there is nothing private here I mean the transactions are public the current state is public and the new state that AR going to compute it is also public okay but we are using zero knowledge technology because because it allows us to prove that the computation was well done and sound you cannot cheat um um so if we make a summary and and put all the names here that we are talking about so if uh if that if we are pro providing

a validity proof I mean zled proof then then and we are also Pro putting all the L2 transactions in in etherum in layer one so we are providing providing data avilability in layer one so we're providing we put all the all the L2 transactions there on one hand and we are using we are using a proof then we are talking about a ZK R okay um if uh we are using zero knowledge proofs validity proofs but we are not putting the data on chain for data avability then we are talking about um and polygon in fact is I mean

the ZK evbm is a ZK roll up okay but we are also building Ms so we are building these both these two types of L2 Solutions on the other hand we have uh optimistic rollups in this case it's a rollup so all the information is available in layer one but the how we check that the execution is correct is doing an optimistic system which means that we send the new state to the smart contract and then we uh left some time around a week to uh so that anybody can dispute this state computation and

provide the proof if that I that we did not compute this this correctly for example okay and but the all all the data is available and finally we will have this uh Opti optim systems in this case they are using optim the optimistic approach with the F proof but they are uh not putting the data available in layer one or in ethereum so and this is what we call Optimum if you want to check this link here you you will see a list of projects that are currently running networks of these four types okay uh in polygon we

are uh uh we are building this this two um and then another question that we had to answer is okay um which type of system we are building okay as I said at the beginning there were layer twos that only I mean for a limited applications okay they were for example just managing balances of 1 tokens or something like that okay they it was like a simple processing that I mean the knowledge proof systems were not they mature enough or tools were not mature enough to build like complex systems and the first the the first approach for layer

layers two were to build this simple system simple applications but then we have a new generation uh of uh of systems with validity proofs uh using zero zero knowledge technology that they are able to just have a complex State the same state as layer one ethereum so we can have account with balances with B code we can execute transactions of smart contracts and so on and and the proof is able I mean the Z knowled proof or validity proof that we generate is able to prove that the change is correct uh the ZM is is is of this type is a is an evm

so um so answering the questions for the polygon ZM uh so how I mean how we manage L2 transactions well we we use a unicast approach I mean we have an note a centralized note okay that is going to receive all the transactions okay so but but then you may you may say okay but this is very very centralized because I mean what happens if if this this node is not going to include my transaction in the computation of the new state um well we also provide uh an I mean this node finally is going to write these

transactions into layer one okay but if this note does not include your transaction then you have the possibility of directly writing into the layer one over I mean and bypassing this node if this noes tries to do some some type of censorship then we also uh provide the possibility of directly uh storing the data yourself into layer one it's going to be a little bit more expensive but uh then it is going to be an anti- censorship measure okay we we call this I mean when we we can send a batch of a list of transactions of our transaction to the smart contract and we call this

for batches this is a batch of or a list of transactions that we can directly send to the smart contract if the centralized note is not doing the work of uh processing on our L2 transaction um then how are uh transactions made publicly available in our case we are at rollup I mean we are we are building both bidum and rollups but the DM in particular is a r so data is available in layer one yeah answering the question who is going to process the L2 transaction well we have a right now we have a centralized aggregator node which means we have a

centralized we have a system that is going to able to generate uh in our plans we are we are planning to decentralize this layer and enable everybody to to participate as as a in the system um by the way this GRS uh can also be aggregated and this is why I call aggregator but essentially a um so we are using this proof system however remember that it cannot cheat I mean we cannot cheat we cannot produce a proof Computing an incorrect state so it's calized but the only thing that the pro can do there is not

generated uh in the future we will decentralize this and it one aggregator is not gener approv then another one but right now in the in in the architecture our aggregator is is just uh the uh is a centralized piece here that is quite easy to this but we will do it at some point uh and then yeah what type of application do we support we support everything we support an machine so we support essentially uh anything that the layer one ofum supports so yeah going to the

architecture I mean how we are going to build this uh system this is uh this is a diagram of our architecture which has as you see different pieces here so this is our no let say this is the note that is receiving the data okay and well inside and this is the and then this note is also sending information to layer so in the center we have layer one um I go to this uh diagram in in a minute but let's see it in a you UNF friendly way let's say let's see which is the flow uh of processing an L2 transaction and so here we have the user

and the user essentially to send the conr to our okay so this is our okay well if we are not processing the position he is going to be able to directly send the transaction to the smart contract in a foret way this is just if needed okay so we we provide some an sensorship here uh but we send all the to the no and the first piece that we have here is a Jon RPC which is a block just uh answering I mean is receiving the transaction and answer this say okay I re contion it's okay or it's not okay or whatever uh essentially we support the same API we support essentially the same

API uh methods that the ethereum J RPC supports plus some extra methods uh that are specific of the C uh if the transaction is okay is well form and so on we just put the transaction for the pool D and it's a pool of L2 transactions so we store it here and then we have a new another piece which is called the sequencer and the sequencer just is going to take some of the ending transactions transactions that are not yet included in the in the state and uh yeah it is going to create what we call this a batch of transaction

a list of transactions it's going to decide a a list of transactions and and it's going to send this transactions to the Prov okay and the Prov is going to uh take the current state the current state essentially we have a database which we call Hash DB is this database the hash DB is stores the current state all the information of the current state so the pro takes the current state takes the bunch of L2 transaction and comput a generates a proof and then sends this proof to the layer one in which we have

a smart contract that is called the polygon ckm is a sorry is a smart contract that receives the the proof the previous state is I and the new state is I plus one and the smart contract verifies that the proof is correct I mean and also sorry also reive the L2 transaction okay so as you see here we are receiving the L in an L1 transaction we are including the Prov puts there the L2 the list of L2 transactions the previous state the new state and then sends this to the smart contract and in the smart contract we have a function here that is verify much which is the apply which applies the cryptography

here to verify that the state change is correct and there is no way in which the pro can cheat this proof will uh in a in an irreputable way will uh uh will say that the state change is correct and this is in a high level what happens uh in a more detailed way if you want this is what happens in the architecture so the US sends the L2 transactions to the RPC J PPC store the transaction in the pool then the sequencer reads the pool getting transactions decides an order and then

uh store this information into the stateb node the stateb is stores the state of the node okay so and so we are storing here that we are we are going to process we created a batch a batch the sequencer what it does is close a the side which is the next list of L2 transactions that are going to be part of the state [Music] and and and then the prover essentially the pro just uh reads this database and Sayes okay what I have to prove generates a proof and for generating the pro it may

need to know the current state so maybe it's going to Al uh Comm with this Pro with the hdb which contains the data of the state generates a pro changes the state so it is going to is going to be it is going to also write this hdb because the state is going to change finally leaves the RO here in the stateb and and then we have a what we call the sequence Center which essentially goes to the DAT to the database and sees if there is some uh something that needs to be sent to L1 in this case the list of transactions and the proof

and takes this uh information and then sends this to the this manager which essentially take takes a look at the network and see when see when is a good moment to sell the transaction do check the price and so on and finally write the information in the smart contract and when the information is uh right into the smart contract we have we have also a synchronizer which is uh monitoring the L1 Network and says okay the proof is already registered and then we write out this information into the state database and we just put the check that okay this bunch of transactions has been proved and included in the system this is a

simplified flow because I mean it's not exactly like this I mean uh but I wanted to simplify little but most of the systems in most of the systems the sequencer also send the transaction to the n i mean we first decide the order s transaction to the network just defining the order and the proof comes later okay most of the system to do like this in two steps I just wanted to show you a simplified version but the actual version is first it has a sequence step that is recorded in layer one and then the pro is made later I explained here like together to

simplify and then here you have the explanation that what I already stud so this is in a high level what the zkm uh does and now I want to talk a little bit more about how we proof how how we build the proof okay so I'm going to just talk about how is our Pro which is the technology that we have developed which are we we develop some languages some compilance so I'm going to talk about this stuff so okay as we were saying we have the pro and the pro the the goal of the proval is just take one state a bnch of transactions and then

produce a new state and then produce a proof that this state is correctly computed so how we do this well to do this I mean to prove executions you need to build a matrix H what is what we call the execution Trace I mean to build a proof you need to create an execution Trace with is which is nothing else than a matrix and then you need to uh you need to Pro the pro will need to prove that this Matrix is correct okay let's do some examples so for example let's consider

that I have uh a vector of three inputs okay let's call it x0 X1 and X2 I mean this these are three values seven 11 and 12 okay and then I want to implement an execution trace for doing this computation I want to take uh input x07 and and the second input 11 and then multiply by four and then multiply by the third okay this is my computation and I want to prove you uh that I made these computations um how want to do this okay um to do this what we need to have is

what we call Operations okay our system is based on building operations over this Matrix and and let's assume that I have these four operations available uh I I have an operation that allows me to copy the input into a cell in the execution Trace then I can sum two cells of the execution Trace in the same row okay I can Su this this cell and this cell and then leave the result in a Cell in the next in the next row for example here so I want to add the this this value leave the result here okay this this is the add operation then I have another operation I mean these operations are arbitrary okay so

I'm just putting an example so then I have this operation times four which takes the value of a cell multiplies this value by four and then leaves the result in the next in the next in a Cell in the next row and then this is times four so it's multiplying by four and then um I can have a mole operation which takes two cell in the two cells in the same row and then leaves the result in a uh cell in in the next row okay so let's see it's just an example of building an execution trace for uh doing this computation in which we have this four operations avable okay

this is the the idea um so one thing that we have to decide when implemen this is uh I mean how is going to be this execution execution tra I mean how many how many columns do I do I do we will have how many rows okay so rows and columns are important sometimes we call register I mean instead of column we are going to use the word register okay so in the zkm we are also using some regist in our EX in the execution Trace that allows us to prove the the execution of L2

transactions we're going to use some resistance in this example we have three resistors a b and c or C columns or three columns as you prefer but I'm going to name them inter change for um and then let's see which are the operations that we are going to have here so let's let's let's consider that we have this input one to five okay this is the input of our computation and this is like our program this is what we are going to have okay well but the program is given in this in this in this form of an equation but I need to transform this

program into a sequence of instructions so yeah so let's see which is the the problem to to do this okay this is the program so first I need to copy the first input I need to copy to the first cell in the first row so I copy the first input here I copy the second input here so I will have operation I have the copy operation here and then I I just call the add operation which adds these two value and and leaves the result into the next row and then I call the times four operation which multiplies by four and leaves the result into the next cell and then I call the multi M operation

which multiplies sorry which multiplies these two values and leaves the result here okay and this is the result of my operation and this is my program so I I if I execute this program with this inputs I'm going to obtain this R the thing is that I need to somehow I need to uh very I need to convince you that I created the correct execution Matrix if I convince you I use the correct execution Matrix then you will convince that the computation is correct and the idea here is that I I'm going to be able to convince you that the execution was correct providing you some information

and obviously you are going to need much less uh comp computer computation effort to to verify okay the thing is that the Prov has to do a lot of work has to generate this execution Matrix and has to do a lot of stuff but the verifier does my less work um so let's put some names here uh you you may observe that we have I mean I just put the col the column C is in another color and uh and this is because uh I mean yeah this is the execution Trace I

mean this is the execution Trace for the inputs one two five okay but if I change the inputs obviously the execution tra is going to change okay because well I have now five my my input three is is my other input then I'm going to allation I'm going to run the same parag but over different inputs and columns A and B they going to change because we have different input values but column C is not changing because column C is just part of the computation I mean every time I use times four this four value is fixed okay and this is uh what we call I mean we the

The Columns with fixed values are called fixed columns okay while the columns that change when we change the inputs we're call we're going to call them witness columns okay so providing a different input all the witness columns or well I mean the window columns may change while the fixed columns they stay the same because they are part of the computation okay okay so the first thing here I mean I need to do two steps here the first one is to create the execution Matrix okay so I need to create the execution

matx in some way and in our architecture the the uh the piece that creates the execution Matrix is what we call the executor the executor is given the inputs and it generates an execution matx okay um and and here we have like two options to implement this executor I mean what we want to do is to build an Executor for the processing of the E okay so we we can how we build this executor well we can do it in two ways first we can just program the executor to I mean we can code this executor in C

rest or whatever and generate a program and generate a program that just does the computation that we I mean that we set okay so it's like yeah it's like building yeah is building a piece of software just for uh Ju Just for proving the uh exact computation okay we call this the native executor okay um we are just in fact we are just building this native executor okay the the other approach is just to create like a generic executor I mean

it is an Executor that is going to generate the execution Matrix but that uh it is going to read a program and a program is a set of instructions remember so we are going to build an Executor that is able to prove this program or another program I mean uh this is area buil something that I I I'm going to provide the program to the executor and the executor is going to I'm going to provide the program the inputs and then the executor will generate the execution mat so in some way the native executor is a hardcoded executor while

the um while the general purpose executor is just reachs the program bre the inputs and generate generates the execution MX and and this is this was our first approach because uh we develop our language an assembly language to Define the operations that we need to do to implement all the up codes all the codes of the ethereum virtual machine um so the executor is going to just read the assembly take the inputs and then do the computation okay and the idea is

that the executor is going I mean if you you Define the Operation I mean for this executor needs some language that defines the possible operations to build the execution Matrix okay we call this language with this operations is what we call ZK ASM in our architecture so we describe the processing of the the v machine in ZK ASM okay and the ZK ASM well this is a this is this is a toy example okay but for example in in this example I have like three I'm using this program add

times four and move but then I can I can just build another program with the same set of instructions I can just generate another a different program which the ex this generic executor is going to reassembly the ZK the inputs and it will generate the ex the corresponding uh the corresponding execution pH for example if if we want to prove this computation here which only receives two inputs by the way then I'm going to say okay copy copy the input to to the to the cell a z and then do a times four and and then do another times four and then then do a multiplication so I have here the result

okay so and we just built an Executor and and if you want to change the program but with the same set of instructions well if you have the a set we are going to uh create an assembly language with a set of instructions with this set of instructions you can just build different programs to and these different programs they're going to generate different execution traces okay um this is the idea and in our case well you will find all all this all this information here um but this is a table comparing uh this

uh I mean comparing the the general purpose executor or the this this more General executor that read assembly okay um I think that many other projects just created executors uh Native executors which is I mean they go faster they are probably more efficient in this sense but they are probably also more difficult to audit and to check that they are correct in some way and to change okay if you want to take a look at how the assembly looks like it's like uh for example looks like this okay in our this is the assembly

that we just uh developed to uh to create execution tra step it means step to a it means that in the execution tra we want to copy the value in uh in in column A to column step okay we going to we're copying this value okay or we can also we can do a lot of stuff okay this is the I mean this is the big part of the ckm project was to develop the correct set of instructions and so this is one of the main main uh main issues here okay so

yeah we develop a language and yeah providing the language we have a compiler that just generates a an instruction file that the executor is going to uh the nice thing of this approach is that uh I mean the v machine the the evm is always changing I mean the specifications of the evm they are changing they are changing all the time so uh with this general purpose executor the idea here is that if we have to change some behavior in the processing of the transactions we don't need to rewrite the executor we just need to change the uh

assembly uh program that we built to prove the transactions and this is much easier and uh quick to change and quick to audit than uh mod defying the program the this native program okay so this is this is why we uh did in this way um each time we change the behavior of our processing which is made to be closer and closer to the theal machine uh we generate a new version in our case the versions are for the fork ID okay the fork ID in the ZM this is the version of the program that process

the L2 transactions and we are changing we are generating new Fork IDs to introduce I mean to to go closer to the evbm and maybe to introduce some uh I mean or or to make our processing more optimal or so um okay but uh we have this execution Trace okay but how do we prove that the trace is correct well uh how we ensure that the execution the execution correctness well remember that we have this computation we have this execution Trace we ensure that the execution is correct with constraints we

have to uh make sure that the table that execution tra that the Matrix is fulfilling these constraints in this case uh we're going to copy some inputs and then we are calling the ad oper operation okay the operation also is using or is enforcing this constraint here okay that A1 should be a z plus b0 okay so this value should be the sum of these two and then if I use a times four here I mean each each operation enforces certain constraints okay and um we just just generated a

language for describing these constraints and this is what we call uh pill okay why because I mean in the execution tra I mean I I I have a large I may have a large execution trace a large Matrix and the idea here is I want to prove you that the if I want to prove you that the execution was correct well what I do is just uh take each of the columns and then them I mean the cryptographic systems what they do the zero knowledge systems what they do is to take these columns generate pols and then do enforce all the uh

constraints uh with these pols and there is an efficient way of proving relationships between pols and each polom is interpolating a lot of data because I mean the polinomial will presentent a whole column here okay and uh so we just created a language to describe the constraints in this execution Matrix that is called P which which comes from polinomial Identity language an identity is just an equation so we just created a language to describe which equations the execution Matrix should fulfill

so that it is correct okay and we also created a compiler and so on okay so um so this is a this is one other uh software that we just created is available in the polygon repositories and is open source so you can use it if you want um yeah finally I just want to mentioned that uh uh some of the values using Z know technology some of the cells they can be primate also I mean they are values that uh they are not shown I mean they are

only known by the pro but uh it is not going to reveal these values okay so uh typically this is what we call private and then uh so I'm saying here that I have a private value here okay I'm not going to disclose this value but I'm I'm able to generate a proof okay I'm going to generate a proof in which I will I will tell you okay uh using this to uh I mean using these inputs okay as input zero I'm using as input zero I'm using one as input

two X1 which is the second input I'm using a value that I'm not going to disclose and as input three I'm going to use five okay and one and five are public the output of the computation typically is also public so is 60 so the publics here are one five and 60 I'm saying I'm doing a I'm doing the computation that we just Define okay just uh you know adding and multiplying by four and so on okay if and uh one of the inputs I'm going to keep it private but I know it okay but I will I'm not going to show it to you but if I do the computation I mean I know

uh if I I created the execution tra and the output is 60 so I know I essentially I'm saying I'm saying to you that I know this value but I'm not going to show you I know the value here that when you compute when you do the computation the output is exit Okay um so we can do proofs with some privacy too using zero knowledge okay so now then we say that we have the public uh we have public inputs in this case public inputs are just one on five we have also private inputs which is two so not all the inputs are public in this case I'm putting one uh input as private the output typically is public so we

have 60 so if I say the public are one five and six okay and essentially here is uh I'm going to just give you the high level but uh essentially to the cryptographic back end that is going to generate the proof you just give the constraints you just give the the witness columns and the fixed columns so you provide all the constraints that the execution Matrix should fulfill you provide the witness columns and the fixed columns I mean you provide execution Matrix which in our case it will come from the executor the executor will provide these things here okay we provide the constraints and the kog

graphic back is going to generate a proof H and the public and the pro and the verifier in a very suain way in a very with I mean this information is going to be small and also the processing that the verifier needs to do is also small the verifier can say okay this is correct or this is not correct okay uh uh just to give you some numbers in our case the well the the Pro system is rather complex but the last part of the Prov is what we call a we are using this protocol the F PL and the smart contract is just uh consuming around 200k of gas to of execution to

verify uh to verify uh a batch of transactions even uh several batches of actions which is which a very very small computation effort we are verifying a very big uh amount of resources I mean we are verifying a really complex computation um so as I more mentioned our approach is to prove the machine up course I mean in the machine there are there a set of instructions or up codes and what we are doing is to implement all of the all of these evbm

up codes with our up or our smaller up let's say okay which is which are our zkm up so we have a in some way I have a set of micro instructions that are able to implement all the instructions of the the machine and finally we are ex we are generating this execution places uh and then the proam with the execution trains and the constraints we are able to generate a proof that is sound that there is no way to cheat there um so for every transaction we just Pro all of the operations that this uh transactions involv

uh well uh vitalic made a post about zkm in general or layer layers well yeah zkm in general and yeah I you can build a CM type one which means that you are using exactly the same I mean you are exactly like AUM which means uh for example that the state is built with the same hash tree as AUM in the case of a for example they are using a Patricia medical tree um if you are a type one then you should represent the state with a patri medical tree the problem is that this tree for example is not very I mean you need really a huge execution you you are

going to consume a lot of the execution trays for proving this three it's not efficient to prove this three in zero knowledge because of the hash function for example that he's using which is sha 256 is not uh friendly with the zero knowledge technology so there are hash functions that are more friendly for example POS so then you are type two I mean type two systems are they just process transactions the same as ethereum but they do some internal changes how they represent data for example how they store the state this is our case we are we are targeting a type two so essentially we are type two maybe

some small things are missing but essentially we are type two um which means that we change some internal structures to make these structures more friendly to proof which means consuming less less space into into the execution Trace um then you have type 2.5 which are zms that they change for example how they I mean certain operations maybe certain operations maybe they are not so costly in ethereum but if you want to to prove the execution of of of this operation it maybe very costly I mean the cost is

maybe is not the same as in ethereum that in our system because maybe an operation is is easy to do easy to Pro easy to process and it's cheap in ethereum but in our case maybe it's expensive so type dot uh 2.5 they are also changing the the cost scheme of etherum I mean they are changing how how much operation costs I mean in ethereum you measure the cost of operation in gas so they are changing the gas that certain operations consume because proving proving this operations is expensive so they are making changes in how they account the

gas well this not exactly because I mean the if you change the gas schema this has some impact a transaction may be processed differently if the gas is work if we are using one for another so in case we prefer to stay with just type two and we are not changing the gas uh type three where is when you just change little bit change the uh I mean there are changes okay but you do these ches to be more efficient okay but the processing is not exactly as the machine so there are some

changes and and then type four is when you are compatible in a higher level in in ethereum you typically write the smart contracts in a high level language like this solidity and then you compile this to this to the instructions of the of the zkm in our case the polygon zkm is compatible at the up level but there solutions that are compatible only at the Sol level okay behind the scenes they they do whatever I mean they can do whatever they can they can perform differently so this is like the most the approach of this more fun from the evm okay so if you take a look um I mean and you you

usually sacrifice compatibility because of performance okay the type four is the most performance but this the far is more part regarding compatibility and well type one type two they are I mean they are the tyes that are really equivalent in our case in the zkm we are completely equivalent to the point that you can obviously we are compatible at the up Cod level so you can write your SM contracts in so in Viper in whatever you want uh and then you can use regular tools you can just build your smart contract and compile it with a regular compiler and deploy it with your wallet

like metam I mean all the tooling is exactly the same as in so from the point of view of a developer you will not see differences I mean there is a proving system a complex system behind the scenes that is just you know proving the execution of dat section but for you for as a developer to just create a smart SM contract and that's it yeah uh yeah I just wanted to if you want you can go to our repos to see the pill the pill is probably the most complex part because I mean uh if you put or if you don't put a constraint is it may have a great impact into the

security so you must you must be sure that the constraints that you are that you put the constraints that find the correct execution TR uh yeah we have aits here also of this part and yeah the last thing is that uh in fact um the last thing that I want to to highlight here is that building a huge I mean the uh the computation of a transaction I mean the computation of the state change that transaction involves this is a quite complex task I mean execution Matrix I mean it is impossible to fit this into a single

execution one so essentially what we have is we have multiple execution matrices and then we are able to connect them okay so we do a computation here and well we are doing some computations here and maybe I need to do a hatch for example here I just put the data here and there is another what we call them State machines because this is like a if you see the execution Matrix is like a state machine that is changing the State according the processing of the transactions well we call them State machines you can also call them sub execution mates whatever you you like so and then they are

specialized in proving certain operations okay and then what we do is just check that rows in the in these two matrices match and and then it means that okay this is correct okay um so well and right now our system uh I mean you need to you need to Define which are the columns okay and you need to Define which is the number of rows okay currently we are working with two to so we are executing we have a bunch of matrices and a bunch of colums which are

Pol and a bunch of rows okay but the thing is that this is like this is like fix each way because I mean when we receive a list of instuction we need to make sure that they fit into this fix structure I mean so and this is why do some pre executions me we check that when we if if this list of contion is going to fit in in the structure of matrices and sub matrices of execution places that we have and so for for doing this we need to do some execution here to to make sure that they fit uh currently we are just developing A system that can

generate as many that is able to generate different the the matrices that we need to to do the pro okay this is is called backs variable degree composable proofs and and we are also adapting our P language okay we we are developing P2 so we are developing here some tools to be able to uh generate the execution matrices necessary to uh prove anything okay but right now we have like a piix set space and we need to check that the transactions fit there and yeah this is a summary I mean in this presentation I just did a general overview of of the of what is a

layer two which different types are there then we talk about the approach of polygon and then we spend more some of the time Des describing in a high level how the appr works and in a high level the pro works as as we said we we just in in the Pro we just provide the private inputs the public inputs the assembly program and the pill specification and essentially we have this this the executor which takes the inputs private and public the assembly program and then generates The Columns of the Matrix that are uh viable which we call them with colums

this need these columns have to be generated per proof so anytime we generate a proof we need to generate this uh these columns then have fixed columns well this is just a setup phas I mean if you have a times for operation we know that in this fixed column here we have a four and this four is going to be for all the all the computations all the inputs that we do so different different proofs for different inputs uh that the the this column will stay the same so it's a fixed column so what we do is we the executor runs in a set of in a setup phase just reading the assembly and then generates the fix set columns and this is only done once I

mean and then each time uh as as inputs here we are providing L2 transactions so each time we provide a different set of L2 transaction then we are generating different witness columns that they change because we change the input um and then we need to prove that the execution T is correct so that here we have the cryptography backend okay we just uh well in this small session we just see it as a black box but we provide the P specification which is the constraint but weile this and put it in a correct format for this box but essentially we just provide the constraints the constraints are going to

be always the same so we generate this Con stength in a setup phe uh and then in the cryptographic backend we just put the uh weakness columns the fixed column the constraints and the back produces approve and the and a set of public which are inputs and outputs that are public and then the verifi just operates with the proof and the Publix and says okay or not okay yeah and in our case this verifi is a smart contract in layer one uh this is the general overview of the ZM and we talk a little bit about

how the proving system works okay the project has still more pieces for example we have a brege to send if or tokens to our to our layer and then you can also uh send these assets back again to layer one so there is communication here between layers but this is another topic so but we also have an implementation of of a bridge and and now we are just building like um a layer that allows to create different layers ler to and then connect them and we call this technology the aggregation layer and and this is what we are actively working right now and uh well that's all

uh regarding this introduction to the ZM and mainly to uh the proving system used in in this in the polygon zavia yeah so okay can you yeah I can I can hear you yeah so you said like polygon created ZK ASM language for like building zkm so is it specific for polygon or like any zkm can be made it uh yeah this is a specific I would say this is a specific for building a

evbm an a machine it's it's a it's a language which a set of the instructions that allows us to prove the up codes of the so this ZK up codes maybe you need maybe it's one one sometimes it's one one sometimes we need two or three 3K outputs to implement one of these okay uh but right now what another project that is being developed inside polygon is to build just a BM not not a f just a virtual machine with a set of instructions that proves any computation that you can describe in

a in a regular language for example like R you you can or C or whatever you can write your program and then create a proof for this program and this is a BM and this is like a new research area which is quite active and people is creating DK BMS some projects here for examp we have risk zero which which which is using the risk P set of instructions F1 and PO is building one that is called cisk so this is like the the new well a new area is building uh systems to prove a

computation described as a rust or a c program in our case the the K assembly that we generated is able to prove the up codes of the of an of an evm but anybody can use it and the langu and the idea is and the base of the language is being used to to build to build the system so it's just introduce more operations and that's it I mean the tooling is the same and everybody can use this tooling so how are you how are you making like these GK opto op codes as like evm compatible of codes for execution I mean uh we are I mean we

develop a set of instructions that implement the output so for example I mean we need to create for example binary for all the binary operations or for example let me talk about the arithmetic operation so for example doing AR operations we have a machine that is able to compute for example this a plus B A + B * c [Music]

equal well let me let me show you some example let me let me think in in some example or the memory for example we have a we have an execution trace a small execution I mean we have a state machine which is one of these sub execution matrices just to prove for example reads and rights in the memory so the execution Trace will contain memory and we just uh we just constra the table so the each time you do a read or write operation I mean we are following the order and so on so essentially we need we we needed to create uh execution matrices for every

and each operation that the evm does and uh here we have like super operations because yeah we have to uh I mean yeah I don't know how to explain it in a high level without going into the details but um for example our our memory is able to read and write 32 bytes okay but the let me put an I mean our memory tra is able to read and write uh 32

bytes I mean it's eum is works like this I mean you can read and write 32 bytes in the memory but we we we R we uh we WR and write them Al line which means the basic memory that we have is just a r i this is the word zero which start at the position zero and then this is 38 and then have the B 32 so here is the second of what and so on so we built an execution Trace that is able to prove rich and rights align okay but in ethereum in ethereum from time to time you May read here at a position that is not align okay so then then I need to

read these B here which are half of one word and half of another so yeah one I mean our instructions of the this is what we call the M execution traes we have our the execution tra of our memory uh machine is reading and writing in a in an alignment in it's aign is a alignment okay but but then ethereum may read the memory in a not an aligned way so then then we have another execution then I have another execution trade with another operations that make sure that we are reading this piece and this piece so this is an example of how in ethereum

you have the up code read from memory from this point and it will you will get 32 bytes okay but in our case it implies different operations first we WR and write we are able to WR and write this uh we are able to write only you know in an alignment way and then o over this we have another operation that constraints and say okay you if you want to read this piece then you have to read this word you have to read to read also this word and then you need to cut here and take this part and cut here and and have this part so I have to to do I have to read two

words and then I have to cut the F some bite from the first word and then I have to cut other B from the second word and so so these are our micro instructions that finally they are going to produce the same as the output okay but in the output it's just read from memory from this position but since we implemented this in a different way we need to use okay in our case we will need the micro instruction read this word read this words take this B from the this word and take this other B from this only so we have like four or five mro instructions to implement the um the instruction that theum does with just one instruction okay with one up code okay which is uh

the m m load it was clear yeah it is clear thank you okay if there are more questions if not it was a pleasure