ZK10: Statelessness and zkp ~new type of zkp application~ - Erik Rybakken

Transcript

[Musikk] My name is Eric I work for inmax and I'm here to give this talk called Pushing the limits of CK rollups So what is the goal of blockchain scaling so you might say that the goal is to maximize the number of transactions per second But if this was the only thing that Cared about the best solution be central Database not what we want so instead the goal of blockchain scaling is to maximize tps given some conditions so Which kind Which conditions Do you want to satisfy Well

that depends on the use case so in our case We are building a payment system so and this is a system where people can transact money and since people care a lot about their money We will need to satisfy pretty strict conditions the first condition is want to maximum liveness want to minimize the chance that your funds Can Be Frozen this excludes valids And Also do not want to any online requirements and exudes plasmas in a plasma a user can prove that certain

balance money me plas user need to online Once in prevent other users from stealing money This is not very user friendly så class of blockchain solution blockchain scaling Solutions satisfies conditions rolls Roll Avid on re of plasma Mak Dat There are two kinds of rolls

optimistic rolls and rolls and it turns out want to Maxim the number of transaction per second you need to use C roll and theon for is that C you need to publish all transaction data on but By using ckp you can prove that you know some data without having To Give That data over to the verifier in the case of C Roll Up The verifier is the Roll contract on layer one this means that you can send less data on what are limits of rolls rolls are limited by data availability means that

in order to Maxim tps we need to minim data Us transaction So what does the transactions look like in our case So we are building a payment system Which means that eh the transactions are simple transfers from a sender to a recipient transferring a certain amount of money and transactions are collected in Blocks and over time we get a sequence of Blocks så How much of this data do we need to publish on chain so for en optimistic rollup you would have to publish all of this information on chain som CK

rollups publish less data by only Publishing State SS on eh But The answer the question is Can we publish Even less data on ch and the answer to this is Yes and in order to see how we will start by only Publishing mots on ch like in this example so for Each Roll Up Block we have a Merle tree where the leaves of this Merle tree corresponds to the Roll users and the content of the Leaf corresponding to user contains the transactions sent by that user in the block in this case Alice sends a

transaction of 5 to Bob while Carol sends 7 E to Alice and e to David root of meres are published on And Also assume that the sender senders in block knows The Miracle proof of the transaction in that Block now to construct a balance proof proving your balance you would Take The Miracle proofs of all transactions you have sent and all transactions you have received as well as for Each transaction you received you would need a balance proof proving that the cender of the

transaction had sufficient balance for a transaction so for instance here when Alice sends five e to Bob Alice would need to send off chain to Bob the data consisting of the the merkle proof of this transaction together with a balance proof Which proves that Alice has at least five e and then Bob will use this information to build his eh balance proof ok and if Bob does not receive This data from Alice den Bob consider the transaction to be valid OK så the balance of user is computed by taking the total amount

received minus the ToT amount sent the problem The problem balance transactions sent and since the verifier only has access to the Merle rot they do not know how many transactions you have sent so to fix this We will Also publish the set of senders in each block on ch like this so in this example the set of senders in this Block is Alice and Carol so we also publish set on ch And then the verifier can check that you actually Included all of your s

transactions in your balance proof So This actually works and it's eh so notice that even though Carol sent two transactions in this Block She is only Included Once in the cender set So This Means that ehm This is very data efficient it's more data efficient than existing rollups and since each sender is only Included Once in the sender set a sender can send an unlimited number of transfers in a single Block with no Extra cost so even though This is more data efficient than existing

rollups the balance Pro themselves are not very efficient so they are very large and are expensive to verify So how do we improve this so we replace the Merle proes with recursive cps so now every user will have one ckp proving balance and this ckp can be updated each time the balance of the user Changes now we are using plk 2 for this but we will replace it with Nova later So let's have a look at how The rollup Contract works so The rollup Contract stores in Storage the list of all previous Block hashes Where A Block

hash is computed by taking the hash of the Block with the previous Block so to add a new Block to the rollup anyone can call this function with the New Block and bls signature of the Merle rot by all the senders in the Block The function will check the signature and if it is valid it will Add the New Block to the roll up by storing by computing this hash and storing it in Storage and then when user wants to from the r will send request to this contract function where they include a CP Which proves That they sufficient balance for

With The Contract function checks this ckp and if it is valid it Withs the amount så can we improve this even further so in the description I just gave of the Roll of contract you need to verify a bls signature for Each new Roll Block but we can improve this by cont Ver bls on for Each inad that computation to the function Block not

verify instead users bls verification of comp bls verification correctly så in conclusion we achieve the highest possible transactions per second for Roll we achieve minimal finalization time because you do not actually need to construct CP in order to add a new Block The CP proving Happens syn maximum sensor resistance since anyone is allowed to add Blocks to this rollup it's totally

permissionless and we get minimal layer one cost both in Ter of data and computation and it is private because transaction details are only shared between the sender and the recipient of the transaction so not even the aggregator needs to know the transaction details and here is our White paper Thank you [Applaus] we have time for one question may be to quick on so just one question for AS far as I understand There is no

data availability That is poed on chin Right like the full transaction and that is necessary to inherit security from l1 right the set of senders on and and Bl signature of byers Bl [Musikk] of Security

actually I was Wonder You said that you are planning to move from PL to Nova for recursion wondering why and what are like the trade there eh ye I think Nova Seems to be more efficient than plk 2 you can like the each recursive step is like optimized Eh ja I think I think it fits our use case better Ja I think If there's any other questions please take it up with eric afterwards and we move Along Thank you very much Thank

[Musikk] you