zkSummit6: Account based privacy in ZeroPool - Igor Gulamov - ZeroPool

Transcript

[Music] uh hi zeke assignment i'm igor gulam from xerapool and we are building privacy engine for blockchain supporting smart contracts like ethereum near polk dot and waves one of problem are going to solve when we build in our solution is that if we use utics so basic uh private transactions we need to publish for each input you take so annually fire in case if

nullifiers are not collision resistant we need to spend 10 bytes per each nullifier and this data is expensive in term of gas and storage else if we are going to use collision resistant nullifiers we need to spend twice more space and collision resistance is important if we don't want to check our nullifiers on collisions because collisions are losing money so if our modifier is already present we

cannot spend this assets this is how account based privacy works we have one account in the input and one account in output and we need to publish notifier only for input account we merge all date all amounts from input you pixels into this account and we create some new utic source in output our input utic source will be considered to spend because we

have spent interval field in our account structure and we increment this interval and all eutex cells belong to account owner considered to be spent if digital source are inside this interval so how it works we just publish our commitments in into our miracle tree and when we spend some you take so we update our account and increase the right border of

interval and all you take source inside the interval considered to be spent it's important that it's enough to publish on chain only uh output commitments not separate account hash and utex or hashes because if receiver knows on the hashes of his data he can build miracle proofs and perform new transactions so decree encrypted you take cells and accounts could be moved to not so expensive storage like historic

nodes and similar solutions this is the scheme of our circuit so we have mutex structure with three files and account structure we have interval here uh in the most simplest case this is interval from 0 to the value in more complex case we have can work with a set of these primitive intervals this approach allow to make our user

experience better delta amount is a parameter used for withdrawals and deposits and gas fees and this is out put your text source and you take some fascists and account hashes this isn't uh public fields of the housing key snark but we can compute hash of all output structure this is our commitment of our transaction it is public so this is how it's working um so this is root

of all utic source and accounts this is output commitment also this is nullifier we have only one nullifier because we have only one account on the input also we perform some check that sum of input equals to some of outputs so with this approach we are going to use much lesser storage and data per our transaction than in our deployed to attain you better version thank you for your attention you can check more about our project

uh or on these links so that's all cool all right i still don't see any questions in the in the chat so i am going to encourage anyone who's watching to add some if you could i think would be great but i do have a question as well for igor um why did you choose to do optimistic roll-up why did you choose our solution was deployed on ethereum in march 2020 uh it is a very early experiment in private transactions for ethereum so that's why we choose

existing technology optimistic roll-up and use it in our prototype cool and you mentioned that you're building on near and polka dot as well why are you working with those projects uh because we love rust and most of our source code is built with trust we built smart contracts client was models and ziki snarks in rust including our self-developed library to build circuits pop script the snacks cool