An Introduction to Zkopru

Transcript

my name is chance hudson and i'm a scalability engineer at the ethereum foundation and today i'm going to talk to you about zkopro and zikru is an acronym for zero knowledge optimistic privacy roll up so this is a fairly short talk and i'm just gonna kind of dive right in so the major feature of zk approve is of course private transactions and this hides both the center the receiver as well as the amount being set uh z care proof supports ether erc20 and erc21 tokens and it does so with a single privacy pool also because it's a rollup it offers an order of magnitude transaction fee reduction and

an order of magnitude transaction throughput because each layer two block is a layer is just a layer one transaction so additionally we have this concept of viewing keys and spending keys very similar to zcash so say for instance that you're a business using zko approve for the private transactions and you have different departments with different budgets and they all have uh different secure approve wallets but you also have an accounting department that wants to sort of keep track of these other departments you can give the viewing key to the accounting department and they will be able to see what is being spent but not actually do any spending and so this is valuable not just for businesses but also for taxation purposes regulation things like this

and finally uh the most valuable feature in my opinion is all the data is stored on chain and the only thing that you need to fully re-synchronize is your ethereum private key everything else will be reconstructed from the blockchain so let's talk about the key derivation for zkopro we use the baby jump jump key pair or the curve to generate key pairs and we do so using 254 bits uh keys and sort of the best case would be just using the ethereum private key as the the key for zke approve but most browser extensions and connectors don't allow access to the private key and for good reason so we have to solve this problem

um but and we chose to do so by generating a signed string using eip712 and then hashing it and using that as the key for zika crew and so one of the big concerns we had when doing this was how do we prevent phishing attacks how do we prevent other websites from tricking users into just citing a random stream and giving away their private key and so as you can see right here there's very nice standardized interfaces for eip712 and where this message uh you know this signature is a private key only signed on official websites will always be shown and is the only way to actually gain access to the key um and so this is how we generate the keys for zq approve

so going on to deposits deposits are relatively cheap to include in layer 2 and this is because we use a merged hash strategy for generating deposit commits on layer two so each deposit sort of builds on the previous spending deposits and hashes the previous hash along with the hash of the deposit and creates the spinal merge deposit hash and only that is included in layer two and then off chain you're able to verify that deposits have in fact been included because you can take the list of deposits hash them all together and get the final merge deposit so because of this um emerging and arbitrary number of deposits actually costs a constant value which is a nice feature

so how does the optimistic roll-up work we use a commitment nullifier scheme to actually spend utxo nodes and verify the validity of utxo notes so deposits create utxos transaction creates transactions create utex outputs etc so what you need in order to spend a utxo so first you have to generate a merkle proof showing that the utxo exists within the utxo tree to prove that it has in fact been created and included in layer two the second thing you need is a nullifier and the nullifier corresponds to the utxo and proves that you own the ubtxo and that the utxo has not been spent so you have to prove that the nullifier does not exist in the nullifier tree in order

to spend the funds and the last thing you need is an ownership proof which is typically a signature from the private key so the the the trees are one part of the system and the second part is are actually the zk starts so this is sort of a complicated graphic but the main thing that i want to show is this yellow cylinder in the middle and so the utexo trees uh or the trees in general validate the inclusion of utxo notes and the zk start validates that the the transaction itself is valid that the funds being spent are valid more specifically uh it it proves that the inflow amount is equal to the amount the outflow amount plus the fee and it does

so without revealing the amounts that have actually been spent which is why it's a zero knowledge proof so the first part the utxo or the trees validate that the nodes exist in ownership of the nodes and the second part the the zk snarks validate that the amounts being spent are valid and high the amounts being spent so this is an optimistic roll-up so withdrawals are always kind of an issue because you have to wait typically about seven days to allow fraud proofs to be submitted by people that are watching the chain um zika proves no different we have the same seven day waiting period but we also have an instant withdrawal feature that allows people to offer funds in exchange for prepayment so for instance

if i was making a 10 ether withdrawal i could offer one ether uh to someone that is uh willing to pay me early and this would work by uh the the prepayer sending nine ether to ezekiel crew and then that nine ether gets forwarded to me and the prepayer assumes ownership of the withdrawal and then receives 10 ether seven days later so you can think of this as short-term loans against the validity of the layer two state and this isn't specific to zq approve other optimistic roll-ups like optimism and i think arbitrary use similar strategies and so um i i personally think this could create a very a very nice short-term loan market and hopefully people can aggregate funds to put the lease

another thing that seeker has is network upgrade ability we have this concept of mass migration transactions and they use a similar strategy to deposits except instead of depositing from layer one to layer two you're depositing from one instance of zko crew to another instance of ziki approve so we use the same merge strategy to create a single mass deposit and then we send that mass deposit to the new version of zko pro so users can move their funds into another instance of zko pro without having to withdraw until later one and redeposit to another layer one contract so finally i want to talk about the

limitations of the system um overall it works pretty well but by far the largest limitation is the fact that only four ut utxo nodes can be spent at once so if you have a hundred if you receive a hundred transactions from a hundred different people you're gonna have to spend you're gonna have to send at least 25 withdrawals to withdraw all the funds alternatively you could send 33 layer 2 transactions to consolidate the notes so first you would send 25 transactions to turn you 100 notes into 25 notes and then you'd send seven transactions to turn uh seven notes or 25 notes into seven notes etc until you have one withdrawal transaction so this uh sort of breaks cpr proof for like for

instance a storefront because they would have to be sending dozens or hundreds of layer 2 transactions if they ever want to spend the funds this is something that we're actively researching for the next version of zko group but nevertheless it's the limitation of the current version another issue with zk approve and with sort of most layer 2 applications and even crypto in general is complexity um one of the things that we have trouble with is how do we design the user interface for zk approve in such a way that people understand and this is something that you know we've done our best to solve but this is a more general problem in the community that people

and developers and designers all sort of need to pay attention to and try to collectively solve and learn from each other um that's about it though that's sort of the lightning overview of zko proof um wanted to touch on most of the major features and give a basic overview of how it works but that's about it