zkSummit - Scaling settlements with zkSNARKs - Alex Vlasov (Matter Labs)

27 Mar 2019 · 21:30

Filmed at zkSummit3 in Berlin, Alex Vlasov of Matter Labs presents on scaling settlements with zkSNARKs. Vlasov breaks down a scaling implementation with its cost tradeoffs, compares design options for adding privacy, from a trust minimized operator to confidential accounts and recursive proofs, and examines the newly introduced SONIC proof system against Groth16.

Speakers

Topics

Transcript

[Applause] you send it in a schedule it was a little bit else about information of metal apps itself I will keep this bar short luckily for me a view from Star Wars already explained a lot about also solutions which are possible to make for level 2 networks for transaction aggregation for watching in some other forms I will just say what we do exactly so our right now we're working on the level 2 solution or just sizing how people call it which is using Zeki snarks for transaction creation and scaling of the public chains and public is important here we need existing primitives so we use what we have an Assyrian right now our goal is universal

solution in some sense and I will speak a little bit about it later initially we finalized our set of features for a first version prophet like two weeks ago would be transfers would be decks atomos which in a form of atomic dependencies with advisory chains and state channel opening fronting and closing without escalation so for best case scenario we want to move in the field of privacy it's ok at least the transaction amounts but for now we optimize for efficiency so this is not in the first version also this centralization is important for such a level to network it will be required for someone to aggregate such transactions and we want the party who would have to

aggregate these transactions which can be called in different settings like in plasma those entities are called operators we call them validators and doesn't measure they just make the proofs we want those parties to be more than one or more than one finite set of entities which are known upfront so we want to have wider participation for this network but in principle work in a both practical part and just some fundamental part to have phaser progress and direction for advancements and my personal goal or more or less what I want to do is to have some form of arbitrary kind of as a smart contracts in level to layer but for this we need recursion and I will not stop with this

today so universality is important is that's why I actually presenting it here today first time we call for initiative for more or less universal the key snarks for now standards for all the public chains in a sense of tooling for users to design circuits back-end for proving so those can be interoperable like reference verification contracts reference by purification contacts and contracts and all this part may be some reference functionality for some kind of networks and if you want to know something please use this email there is no website so just email and we will answer your question directly so what Universal Universal these

important begins will work in a public chains and even well you can do compression of transactions efficiently so you can just prove a lot of transactions upon state transition from an asset a tree to another you need still to care about the worst case scenarios when someone needs to reconstruct the whole state from some part and to be able to have the procedure of movement funds back to the main chain when there is no cooperation from the operator this can be more or less eliminated Eve service is there is some form of the centralization but will it's not final so for this part I will just gives actually the concrete numbers every transaction which is aggregated by

a say using star starts will consist of two parts one is if how much you paper verification how much you pay for public data which is required for now to solve the date availability role for our case if you go for scale fully filled blocks payment will take a hundred and fifty gas per transaction just purification exchange will take well actually twice me twice more but let's put some margin for now and now for date availability now even without the privacy which will require additional costs it will cost one hundred and fifty gas per public data to be able for every participant of the network to reconstruct a state for worst-case scenarios which we should

always care about in a public and decentralized networks on some party just to refuses to cooperate and yeah it's already a lot if you want to put thousand transactions multiplied by thousands already quite a lot more and more more it ik also network capacity and if you use six million proof for starts you take more network capacity and then we have another critic it is well or whatever and actually if you just go into the there is resurgence is how much data is transferred between the serum nodes how much more you can push and actually just much more difficult and just say let's just reduce it ten times fortunately it also depends on the network level and if

you want to have the decent rise network and keep as a soon decentralized you cannot estimate that every node which are actively participates has a gigabit of network capacity so we cannot estimate this so just chain saying that let's put the price for data 10 it's less it's not going to work so that's why something you versatile is more or less ideal so you can have a wide functionality for as many users of the network as possible whether it's Texas payment solutions state channels what's horrible is working on so you always pay for any proof of any transaction aggregation you pay the fixed price no matter how many transactions you actually have the block and how many transaction actually just damage transaction we choose for padding so

this price is fixed and you still put always the same price whether it's padding transaction or not for public data so if your blocks are under field it's actually hurt the network in post levels so if you don't have the network because she can operate at the maximum efficiency and simultaneously be properly filled so that's why there is a need for some universality you can just scale efficiency there will be just koop tickety's again but best part is actually much more interesting especially for me and I think for people who actually drink join us here today so for Sonic's I'm not repeat the Sonics is another proof system as it has a

common reference drink yes it has a common reference Twinkie requires trust to set up this trust to set up is first of all Universal you run it once you can use it for any circuit up to the given depth and it's updatable if you don't trust the previous trusted setup you can tribute on top of it and let's say you trust yourself and please I don't like any credit different implementation I make I make improvements I make new primitives but sir all credit should go to the original people who made this idea so please their names Elster if just to show how Sonics and standards not like girls 16 are

different I see you want to play a game a card game for growth 16 you take a deck of cards you shuffle it under the table to give it to another participant of the game you shuffle the under the table and you get the deck on the table and you play the game with this stack and for every game you did and you deck so you need to go over all this procedure again and again for sonics you shuffle the deck you give it to another entity and at the end of the day you gets a shuffle deck in the table and then you magically clone it and use it for a game and if you want to play another game another kind of game for example just another round you clone it and you play it and you only need to do a shopping once well up to sum up two

games which require only 52 cards for example to play so both of these pro systems can potentially start from Rank 1 constraint system also sonics use the multiplication gates and linear constraints in their paper and in the description but they can all start answers can be reduced main parameters for grass 16 is just number of constraints as many people familiar with for Sonic's any paper describes that like the most important parameter is the number of multiplication gates actually a number of linear constraints is also important so here you have to care for more numbers and well implementations so on so since phone implementation was not

there yet but repetition of the growth 16 in terms of prover and very fire and patch in which every fire is there so we can hope for some like 200 gasper proof in the batch mode of 5 transaction f5 proofs checked at once if there is one public input for example you know now about the efficient implementation everyone knows what that for verse sixteen or oppressed in principle you want to run somewhere fifty so you want a scalar field with a number a large number of roots of unity your program will work and both small and large groups and you wanted you to usually called the pollen petition is available a lot of people well operations are highly parallelizable up

to the very large degree so can be done efficiently you can scale it to more CPUs if you want in your large buffet server if you want to prove the large circuit over a small time with Sonic's operations are parallelizable at least a large share of them maybe Utley maybe except of one but it doesn't take a lot of time as I test it the proper implementation requires only multi expansions into one which are usually like four or five times less expensive which is potentially also good as a problem is it for F of T for some polynomial multiplication which you need for sonics well the number of multiplication gates I will show how it's related to the number of

constraints but potentially Sonic's limit your circuit size for for a given scalar field unless well because you need efficient palermo multiplication for which you just need to diffusion 250 so it just can create example of the conversion if you could choose a min see circuit standard one just open the pulmonary depository for you find one if you convert it originally it has 644 constraints if you convert it you get [Music] 968 multiplication case it didn't put some linear constraints here actually forget about it and roughly the conversion is trivial you take one rank one constraint system constraint you

convert it into three linear constraint plus multiplication gate and also to allocate a new variable private to public you need like one half of the multiplication gate so this formula is more or less universal so you see it's actually just grows with a small factor but still then there was part of the paper which much more difficult to understand which was about help procedure and help procedure where whether there is a proof assistant or not so I will go into this details just one step after another the same way as smaller structure than paper for just understanding of the audience so let's say there is no bunching is there is no requirement for seasoned pro see just one probe which Tommo needs to prove so prover does three polynomial

commitments plus a signature of correct computation fortunately the signature of credit competition its verification in this naive form requires the number of steps which is equal to the number of multiplication gates which so the proof is every fire in the setting is not so sinned so we need to go further what was called a help procedure you can make some entity and untrusted help a helper so can be anyone this entity can aggregate M proofs and M signatures of correct computation and produce one signature of computation so basically

you reduce the verification work from M by n to just and still not so send there's a SIL procedure called and helped yes you can make the signature of correct computation to send also for some trade offs so I just increase the number of multiplication gates after the three times we will go into it later and yes every fire is now as a center what you can do it can mix and match you can take both so this most likely is going to be an optimal procedure so you make an M independent proofs over one circuit Jerry gates a signature of

credit competitions so and then you transform the signature of computation with sauce in form and you get a very fire if his work is actually well still linear in an hour of proofs which you need to verify but now the signature of computation it's at least the same so this one is more or less like a batch of reification of the snarks the standard graph 16 okay now benchmarks which were not in Paris because some people could have seen this presentation kind of in Paris this is a concrete example a test circuit was few sha-256 rounds which just leads to this number of multiplication gates and linear constraints I mean one rank one

constraint system constraint will transform with one multiplication gate plus three linear constraints which is quite obvious and my machine just a laptop modern MacBook 12 virtual cores so it's physical worse ones but virtual cores actually do help when you run the procedure for graph 16 is point 6 seconds per proof so it's four or five proofs let's say three seconds sonics single proof was just production of the proof itself plus what's called advise a commitment to the signal signature of computation as unfortunately in nine

seconds the part which is called a helper as an trusted part which can anyone which anyone can run as sounds like 12 seconds to aggregate 5 to 5 signatures correct computations and this work has a linear in number of computations you want to aggregate so it's not amortized so it's a reduction just plain implementation was a reduction procedure if I even also we made a good progress on how to actually implement it it's not in the code yet so let's say is the worst assumption from the paper which will increase the number of multiplication gates three times so we just kill all the results previously by three which is a good assumption

actually and so we go we go to the synthetic part of the benchmark part of this is synthetics only for proof computer calculation part for the since signature of correct computation which requires permutation arguments through actually three permutation arguments when product arguments and while for madness our arguments everything this form as a paper if you want to go there just assay names for those not the most efficient double amputation yet because it just has a procedure which can aggregate internal parts it's around 60 seconds which let's say 30 percent can be shaved easily just by aggregation so in total of 226 seconds it's almost 80 times more quite

unpleasant for now but now let's focus but we optimized not for time but for a price per proof and for optimization for a price for proof because you can always scale all those proven techniques with well up to of course I'm given degree but quite far I would say you can just spend more computing power in it and just babies basically will be more per one proof if you want to fit it at the same time for this well we work on the parts which should help us with this as like before it there was a whiteboard session about implementation of GPU perverse with some benchmarks and like very early stepped on so my estimate

from what already we have already without any professional GPU design experience we could already achieve up to twice the performance in multi exponentiations and multi exponentiation sysm procedure which is present in most cross 16 and sonic probe systems so it takes in Sonic's 70 to 80 percent of the proper time so those can be efficiently sped up by GPU and speed up here in either you spend less time or you need less resources in terms of price defintely there's at the same time window so here everything we just call the speed there's actually optimization

for a price so if you say so to achieve what we have as well 35 seconds still quite a large multiplier but first of all one should remember why we want to have so next to the first place this is the part where you don't need to have a trusted set up for any user application as I mentioned I want to have some kind of smart contract logic and in layer 2 chainz for this some crater primitives are needed which are not yet available in the cerium and I work well we work for cerium as a level 2 chain and that's why I say that there are limitations if the primitives I

available if recursion cycles are available by this set of courses curves is available well we can brief I the sonic proof inside of the circuit with with the circuit itself being either sonic R or 16 or something else so we can efficiently mix and match and just provides a functionality which would be interested for them users as a real sonic so to top levels GPU so we just have users who provide who prove some their private smart contracts you since the CPUs just implementation should be done tested and what I actually think is over this year maybe next year there will be another step further and common

reference string Sassoon Pro systems so expect the next implementation will be even more efficient and we already see that well yes 25 times more still manageable and the worst case because we still even well what working for public will change we will need to go for work in areas even if Sonic's are not that efficient we have the plan I just for what we do yeah thank you I try to leave more time for questions if someone has talked is quite involved but I hope that it's a zero noise I made people know what we will be talking about so please anyone any questions nothing can you detail a bit more what's the

difference between the multiplication gates with presentation that you use and how once yes and how complicated would be to translate well first of all the translation procedure is not difficult in everyone CS you basically have the multiplication of two vectors of variables plus addition I mean you transfer of Lin multiplication of linear combinations element wise this parts each like usually represented a multiplied by B minus C is equal to 0 where a B and C in your accommodations we just make one linear constraint in sonics which is for a and you make a new variable which will

represent all this a combination you take the same for B you take the same for C and now you have basically a B equal to C which is your multiplication gate so the transformation procedure from our 1zs to what sonics using the paper for multiplication gates and for linear constraints is trivial linear constraint is just well it's linear constraint multiplication gates is just three variables a B and C which are a multiplied by B is equal to C but not now not in terms of linear combinations but in terms of individual variables in your constraint system any other questions then let's thank our speaker

again and we'll have a small announcement from Anna [Applause]