ETHParis: Scalability and privacy with zero knowledge proofs
ETHGlobal·Wed, Oct 9, 2019, 12:00 AM
ETHParis workshop: Scalability and privacy with Zero Knowledge Proofs. In this workshop Alex Gluchowski explains scalability and privacy with zero knowledge proofs for developers and hackers attending ETHParis. ETHParis took place in Paris, France, as part of the ETHGlobal series of ethereum focused hackathons. For more information go to ethglobal.co March 9, 2019 at the coding school 42, in Paris, France.
Transcript
okay so I think we will start hi everybody my name is Alex I'm also from other labs just as another Alex and I'm gonna talk about scaling about with zero knowledge proof in general it's going to be a little more high-level hopefully you will have a better idea how what we can do now and answer the question which was as before what are the killer features so I want to restart with the question whether scaling actually matters who why it matters many people say that we just need to focus on usability and user adoption I'd argue it's not the case you have to think about scaling because if you run into if you if you become successful you're gonna face the scaling challenge and you only want to plan for the success case because if if you're not planning for success then what's the point of making the app in the first place an app or our service or whatever you're building so any successful project will have to to scale and it might be too late but of course it's important to have usability and it's important to be able to develop applications fast and it's also important since we're in crypto to also take into account scalability and security in decent ization which is known as the infamous blockchain trilemma it's really difficult to fix one of the problems without harming the others so we have multiple scaling approaches existing today we can go for centralization with just a few validators which is may be useful for some applications but it defeats the very purpose of crypto we have similar one approaches POS + charting which will state will still take down some time to develop into a full feature a full feature approaches which are secure but they also they are difficult because they make this the compromises in security then we have some layer 2 approaches like payment stage channels plasma which can be used today but we'll come back to them and gonna talk about zero knowledge proof as scaling so how many of you know what your knowledge proofs are and how you can use them okay not so many people so I'm gonna go into a little more details zero knowledge proof allow you to prove that you know some secret input to a publicly known function such that the function evaluates to public output which is known to everybody for us we want to scale and there are only two techniques which we can actually use for scaling because of some synchronous part is the snarks and Starks which are pretty much the same from the outer perspective if we look at them as a black box but they differ in in the implementation most important difference is that Starks are transparent and snarks are not transparent they require trust a setup we'll talk about this now but these are the scaling characteristics of both approaches as you can see snarks are better sympathetically in all three dimensions they are faster to prove they have much much much faster to verify and they have way smaller proof size so they actually better in any dimension and it's especially important for public block chains because they we always have some limitation of in in blocks be it block size or the guest limit and with Starks with close to hundred kilobytes proof size it's really difficult to fit them in in the blockchain and to make the it efficient in contrast to snarks so the reason why snacks were not as widely used in the past was they trust a setup it's a one-time operation which is required before you start using the the proofs in production where whoever provides the trust setup promises to delete some initial entropy some some information they used to generate it setup which we refer to as toxic waste because if he retains toxic-waste he will be able to fake all the proofs now of course if we only have one person who provides the setup it's a little difficult to believe that this person has had deleted a toxic-waste because the results are no way to prove that you deleted it it's you you just promised it and there is no no theoretical way to prove it that's why what is being done in practice is a multi-party ceremony where we have n participants each of them contributes some randomness and all of them say we deleted the randomness and if at least one of them is honest then the the entire ceremony is correct if all of them could loot together and put together a toxic waste then they together can produce fake proofs which if you have a lot of participants which are wide known in the community would not be a big problem because it's really hard to collude it's it's have a hard to cooperate even on normal matters not on dark matters like this however the biggest problem was with with snark specifically with with the constructs we should we had before sai should cross 16 is that we need to do the trusted set up for each circuit and by circuit we mean the actual program the function which we evaluate it means every time we have a new application we need a new trust set up and every time we do a Noblet of this application we also need a new trust to set up and it's really difficult and it's also difficult to attract people from broader community to participate just for your application because the trusted setup is hard you have to organise security measures you have to do a lot of computations it's expensive it's time-consuming and so on and this is the reason snarks are only used for now in production in Z cash with to trans to setup ceremonies haven't taken place but this year we have a new hope which Alexander was talking just before me about it's called Sonics it has the same asymptotic characteristics of scaling it's also constant size proof and constant verification time however it's one and for all Universal trusted setups for for all circuits and all applications so this and we also have implementation on the development which were going to publish soon hopefully in benchmarks in Berlin so this practically solves the problem so now we can have really incredible organizations and individuals participating which everybody knows and this is going to be a solution so we how exactly can we use zero knowledge proof I'm gonna talk about roll-up which is a construct of a side chain secured with your knowledge proof security with snarks roll-up is a difficult name we used to call it like plasma and snarks but plasma people who are not happy about this so we were brainstorming recently and tried to come up with with a better naming I proposed Aaron T which is like our MP is not plasma but it was declined so III don't know what we're gonna use but for now we'll use roll-up so how are ela Forks let's recap how plasma works in the first place the plasma is a sidechain how many of you are familiar with plasma okay so well plasma is a sidechain where we have a main chain with blocks going in in sequence in time and then we want to scale so we create a off of main chain another in block chain with each block being committed on the main chain in the main chain we store just a short cryptographic commitment Merkle hash of the block of the sidechain and on the sidechain let's say we have a Merkle tree representing the state so we have leaves of this Merkle tree are the accounts with our ballasts and we have the the root hash is the one we commit on a on the sidechain so how how plausible works the sidechain is the blocks are being generated by an operator they include transactions in this box the updated state was the state on the main chain and you as a user have to monitor these blocks and see whether your transactions were correctly included and more importantly that no transactions have been included that modify the state in an non-permitted way somebody just just took your money and assigned to their account so you have to be online and you have to monitor and if you see the fraud you have to object and put the transaction on the main chain saying hey this translator this book is not correct and here is the proof because I did not send this transaction and it this transaction takes it to to my account so it requires all users to be online which we call live in this assumption and it requires a lot of communication [Music] okay one second I'm sorry for this okay now it's gonna be faster so so yes we have this box we have monitoring gladness assumption everybody has to check for profile frauds so with zero knowledge proof which is replace this entire monitoring part with each block must be verified on the main chain so the operator when they produce a new block they also obligated to produce a zero knowledge proof that this new block is corrected every state like this state transition was made by a sequel by applying a sequence of transactions each of which is correct they they have very valid signature they have very from balance to balance the amount was transferred is less than the original balance and so on so this this the state transition is then this function here the state transition is the function which we prove with with zero knowledge so that means we don't need to wander the chain anymore we completely rely on the main chain for for securing this because the smart contract is going to check and we have roughly the same security guarantees as a main chain which is pretty awesome now we have a few challenges with this approach one challenge is this journals regeneration snark proof generation it's still relatively small as slow at the moment it takes somewhere between 1 to 20 minutes so we need to come up with like instant block instant confirmation for transactions is something we have to do workarounds for and but how do we choose throughput if we have this blocks and we have to wait 20 minutes to the next block we won't be able even if we fit thousand transactions in the block and it's still going to be some limit because they the higher the larger the block the longer the proven time how do we choose throughput we do it with roll-up by cascading transactions so we make commitments in one timeline and then once we made the commitment we start generating the proof and we keep making new commitments on the main chain then it proves fall after these commitments so this way we can cascade and we can just like just a like a conveyor we can fit much more transactions because block is just follow the second big challenge which we have with this approach is data availability because we solve the correctness part through application of zero knowledge proof however if an operator submits a new state which is valid which has been correctly transitioned but they don't publish the data for this state then nobody can reconstruct the state nobody knows we know we know the miracle hash but nobody knows what account data is there and they cannot prove that they own some some money and then if operator stops cooperating nobody can withdraw money so we want to avoid well this this is a hard problem it's all scaling approaches like sharing faces the same thing plasma faces the same problem in roll-up we solve it with putting the data on chain it's a very simple approach we for each transaction we put the public data we don't put the entire transaction data we don't need to put signature on chain and we don't need to use storage which is very important because it's much cheaper to just put some data on like call data transaction input and we only need 9 bytes which is 500 gasp as opposed to 21,000 yes minimum transaction fee in the theorem however this unfortunately limits us for now to up to 500 transactions per second just because of this if we didn't have data availability issues we could go thousands of transactions per second and this is the current limitation so let's come back to the scaling approaches and then let's see how they compare to each other so we have payment channels and state channels and Plasma both require liveness you have to be online you have to watch every transaction as long as your fonts are in the side chain you cannot sleep calmly you have to give to be on the watch the roll-up doesn't need this this laminas assumption is closely tied to security because if you fail to monitor the fraud you're going to be screw and if you discover the fraud but you cannot put your transaction through on the main chain because the chain is congested or because you're being specifically censored by minors then you're gonna lose your money plasma is slightly better but but it's comparable in this regard for zero for four for all up the security is roughly the same as the main chain except for the Atrocitus aramony which which again is solvable if we have a lot of participants now a very important thing is capital efficiency state payment channels approach is used in lightning and Radin and and similar technologies require that you open a this payment channel for every participant and you can only receive as much money as the size of the currently open state Channel which means you have to park a lot of money in there you have to make a lot of capital bound just to be able to operate the system so this is pretty inefficient in terms of capital plasma is way better however unfortunately current constraints of plasma require that all tokens are non-functional and if you want fungible value transfers then you have something like coins which you have to exchange there is some slight capital inefficiency with roll-up it's completely absent you can have accounts with arbitrary amounts of value in them so capital efficiency is again here and as far as throughput is concerned payment channels are supposed to be theoretically indefinitely scalable because it's completely off chain however because of the capital bound requirement they are practically bound to the amount of capital so if you if you have one either or like hundred dollars payment channel open and you receive hundred transactions then then it's it right you have to reopen it again so it's difficult to quantify but it's very very inefficient this plasma is much better you have bandwidth requirement but it still can handle up to thousands transactions per second which is really cool but the use abilities is difficult well they're all up as we seen before because of data available can only do 500 transactions per second is it bad well we have to compare it to something right you either PayPal handles on average hundred 60 transactions so until we reach these levels of throughput it's gonna be a good problem to have but by that but for now for if we even have millions of users is going to be more than sufficient for token transfers for payments and things like this yes so let's recap scaling is important you want to plan for skating and you want to understand which approaches are there all of them have merits you want to see what's best for your application your knowledge proofs are really interesting you you you I encourage you to watch closely development in snark Starks Sonic's especially we're gonna see a lot of cool stuff coming out this year and roll up can be used today and I actually if we have time let me see yeah we have some more time so I can show you a live demo of how it works on matter network matter test net can just log in with my madam asked it creates a new account it creates in you key pair for me we use a different signature type for with different curve for this and now I have my main chain account where I have a balance of 1.5 ether on the ring pin test net and I have my test net account which is empty we or rather non-existent I don't have yet anything here so let's deposit some money so how it works you have you have to send money to some to smart contract I'm gonna do this let's insert one either I sign a transaction so it goes to this contract confirm let's wait transaction to be mind and then the the account then what happens the operator will notice that there is a transaction on the smart contract and they will start generating proof for this transaction in practice on in production we will have to wait until we have a lot of transactions to batch them all together but the in the in the test net we just wait for so let's see what's the state of a transaction still pending okay it's confirmed and we immediately have balance which is verified because we already computed the proof and drove in and submitted it to learing B test net and I have this money here so now I can transact I can send this money inside the test net to anybody's we have this nice test account which is eager to receive my cash and I'm gonna send this amount and I make a submit transaction and it's immediately submitted an AC pending balance has decreased and non-citizens has increased because we have the state is live it's is monitor constantly I can make more of these transactions I'm just gonna make eight which is the number of transactions in the block and once I have eight the survey will start generating the proof for the block so we assume that we're gonna have much more transactions in real life or if we don't have too much we can always accelerate them so the user experience for end users is gonna be you submit you make a transaction you get a confirmation you can either trust operator and you or you you have some confirmation the transaction is going to be included or you just wait a few minutes till the block is verified on the main chain and then it's final I mean of course s final is the main chain itself because we don't have finality in the theorem but assuming there is gonna be no reorge its final and you can just forget go offline it's safe and then you can any time you can come back and return so yeah and then you any time even without operator you can just go and make a withdrawal make a partial with row or make a full exit and just close it completely which is going to be unchanged transaction and I'm just gonna throw all my money from from the side chain yeah we all wait for while we're waiting I think I'm done so I'm happy to answer any questions [Applause] so that people can hear us who are watching life you just have to do to be close with it yeah yes to reconstruct initial transaction in the main three bytes from three bytes - it's from two amount and feet we just have an assumption of two to the power of 24 accounts which is 16 million accounts gonna be sufficient yes so when you're register you're getting you slot and it's getting reserved for you you put your public key in this slot and we have a maximum amount of users of 16 million who can register and once you register you have this free by the identifier for your account yes you will have well as you can see when I submitted the transaction I used but it's because we have a map in this maps to your they are actually verified in snark it's not hard to verify them and Stark you just need the curve which is embeddable so we have chop-chop curve and baby jab jump in pre-compiled contracts we have a curve for the snarks themselves and inside snarks we use a different curve which is embeddable in you could get the signature and say that somebody has signed the transactions but you cannot prove that they are all correct that each signature for each transaction was was from the sender and that Center had correct the center had amount of remember on their balance more than what they're trying to send at this very moment and so on so Starks is easier knowledgeable in general prove the entire function the entire state transition by applying all these transactions BLS would just prove that somebody signed the data nothing more just just not horizon data so their approaches to data availability with data notaries but they are still being researched so for now we use the simplest one because 500 transactions per second is I mean until we get there we will figure out how to solve it better I can just repeat the question it's we're planning to release documentation & SDKs soon - for developers to be easier we just weird we have very high requirements to quality and we don't want to release you can use it now if you if you can talk to me and you can immediately use it on hackathon but we want to release something which is very high quality and easy to use which is gonna be soon yes what would it mean to 500 years dps would not be accessible for scaling solution or full scale insertion sidechain so you have you can have multiple side chains yes so well well I mean you cannot have many side chains with your knowledge proves because they are all gonna compete for a guess on the main chain and they're gonna drive the increase gas price insane and you also have other transactions but we can have the the this is not for the limitation is only because of data availability there are ways to solve data availability without data on chain which will make us through plasma because there's going to be sub linear to the number of transactions it's just a not a priority right now because it's much easier to do it this way once we hit this limit we can always switch to something which is slightly less usable but allows more transactions yes we can however we have a requirement of hundred percent availability so we need to guarantee that every single byte of this data is gonna be retrievable in the worst case this is the challenge no existing solution offers that the approach is like air we've which are promising but we always need something like we need to guarantee that every single bit is gonna be retrievable so we can do it with proofs of proximity with [Music] arrays recording things like this where we can probabilistic we check that we have at least so like at least some percentage of the data blocks and then if we have let's say half of the blocks you can always reconstruct the entire data set but no solution currently offers this so it would be great if somebody can work on this and and fulfill it until now we just taken the lazy approach and put in data on chain because it's just not not as critical yes there are there is work in this direction erasure coding is the key word you want to check if you are interested okay I think well done thank you very much [Applause] hey guys so I know there's a lot of questions about its kind of stuff so if you guys are interested in having an informal workshop it's going to happen just kind of outside so I'm just follow a Lex and him and Lewis Lewis will give you an informal workshop on this
Automatic transcript — names and jargon may be misspelled.