EthCC 2: Alex Gluchowski

good evening everyone yeah so let me start it's been a long day so I'm gonna keep it short and try to make it this productive for you as possible my name is Alex Bukowski I work with ethereal foundation and matter labs on aetherium scaling with your knowledge pros so I want to start with a motivation for this or with a question why it matters or does it matter actually how many of you work with with solutions which require scaling today Oh interesting quite a few so there are a lot of opinions that scaling actually doesn't matter now they need to focus on usability and user adoption so like do we really need to think about it now maybe we can do it later as the adoption grows my answer to this is well the moment you hit the adoption that you hit the the scalability wall it's gonna be too late because you're gonna lose the momentum and your competitors who were thinking about scalability in the beginning are gonna take over so and you may be you will just break the entire network so it matters and you want to plan for the successful case if things remain like this today that scaling is not really required it's probably not gonna make anybody happy so if you believe that your project will succeed then you have to scale and you have to plan ahead of time yeah but other things also important it's important to be able to develop this stuff quickly it's important to have good UX and scalability security and decentralization which is the famous blockchain trilemma also matter a lot so you want your scaling solution to embrace them from the beginning and there are multiple scaling approaches available for box chains today well the the most real one is centralization or just limiting the number of nodes to the minimum which is of course a joke you have sharding you have payment state channels you have plasma all of them have marrieds and they have up size downsides but most of the mostly these solutions have problems with one of the edges of the blockchain trilemma so they they reduce either scalability or I mean sorry they either reduce the security of the network or they reduce the decentralization so I'm gonna talk about the method which keeps all three parameters at high level if this is your knowledge proofs how many of you are familiar with your knowledge proof wow that's impressive like almost everybody so I don't need to dive much deep into this zero knowledge proof allow us to prove that some computation is correct without revealing the all the input data for this computation but what what's interesting for us in for scaling is the succinctness some sure knowledge approaches have succinctness which means that the amount of computation I can do and I can prove is much larger than the the proof size and the amount of computations I need to do in order to verify them but today currently only two methods support this these are Starks and snarks I'm gonna talk about them a bit further so how can we apply zero knowledge proof to scaling in the only project I'm working on now we have a zero knowledge proof space sidechain where we have some blocks on the main chain so the notion of sidechain is clear at we have main chain going on and then we have a side chain and each block gets committed on the main chain we have some cryptographic commitments normally it's marklar root we just have an authorized version of this block so that it matches the security of the main chain however we also need to secure the sidechain somehow and for this we use your knowledge proofs so in in our approach we have a account-based model where the the entire state of the sidechain is represented as a Merkle tree with some accounts at the leaves of the tree we have the Merkel root representing the entire state and we commit the state now on each step when we progress to a new block we provide the proof that the transition was correct it means that every transaction which was included in the new block and which affects the state has followed the rules of the side chain so we verify the signature of the transaction we verify that the center had bellydance that receiver had was also valid and so on and then that we were in the state the balance was updated correctly we subtracted the right amount and added the same amount to the recipient and we submit a proof on the main chain which is verified by a by smart contract in our case it's etherium so this approach has a few challenges one challenge is that your knowledge generation snark so stark doesn't matter is relatively slow at the moment so depending on the hardware we use it takes somewhere between 1 and 20 minutes so instant confirmations or instant find final confirmation since that finality is not possible out of box we need to go some workarounds for this but how do we achieve throughput if every block has some some limited capacity and if we would have to wait 20 minutes to the next block we would not be able to fit too many transactions in this so what we do with with roll-up is we introduce a pipeline so we make commitments and verifications in parallel we commit every new block on the main chain and then we just go on and in commit new in your new blocks and the verification falls after some delay call latency this allows us to to increase the throughput to actually practically boundless we are only limited by the hardware we require to around 80 proof the second big problem is data availability so the zero knowledge proof approach is solving completely the fraud problem the operators can have a cheat unlike plasma and state channels there is no way for the operator to commit any incorrect and consistent data because it always has to be followed by the proof however the data itself must be made publicly available to the users of this blockchain otherwise an operator can commit a correct proof but never disclose the data and then the funds become undone recoverable because nobody else can can go and prove that in the new block they had some stake in in specific account so we solve this so this is actually what we roll up stands for we put the data on chain as a transaction call so we do not use a theorem storage we simply use a theorem for making the data publicly available and we rely on the mining mechanism and on the game theoretical properties of the theorem that this data will be just distributed broadly and people will be able to collect it and and thus every new state will be reflected so you can reconstruct it and currently takes for the simple token transfer only nine bytes so nine bytes is like 500 gasp which is very small much is more compared to normal transfers and especially to token transfers however this limits us on the throughput so with with this approach we can post maximum 500 transactions per second and aetherium with the current characteristics there are there is work on the way there may be some things we change in the theorem protocol maybe some pricing will change there are other approaches to solve data a bit differently but this is state-of-the-art what we can achieve right now now let's compare the scaling the pros the different scaling between each other so we have state payment channels like lightning and Raiden we have plasma we have your knowledge roll up in well lightning and plasma are actually not limited by throughput essentially anything but the capital requirements or or the aliveness assumption so liveness means that in order for you to use payment channels or or plasma stage channels users have to be online if you submit a transaction you have to wait for you have to constantly monitor the chain as as long as your funds are in the side chain and see whether there are fraud attempts and you have to counter them so you have to send submit a counter transaction in order to prevent front and this is called liveness and this is a big problem because it it reduces UX trade-offs and it also introduces security risks since if you're if you were not on time to prevent fraud or if you were not successful to submit this transaction on chain then you're gonna be you're gonna lose the funds right sis your knowledge proves completely eliminate this with your knowledge where liveness free as soon as you submitted the transaction at that mind and it got confirmed by by your knowledge proves you're safe you have the same security guarantees as I maintain so you're on on the throughput for lightning for for payment channels because it's happening off chain you could do any throughput whatever however they in reality you are bounded by you're limited by the capital which is put in the channel saying if you reach if you open a channel of one ether and then you get ten transactions and you reach the limit you have to reopen the channel and increase it so it's difficult to to measure or to quantify it here but it's it's it's going to be practically there limited with plasma we don't have this problem with plasma and plasma constructs are pretty efficient and they are like very high transaction triples under the liveness assumption and also they would require users to download very large amount of data to monitor for frauds so but we can say that it's very high at slightly worse capital efficiency than than the zero knowledge grows the capital efficiency is the amount of capital you need to park which is gonna remain idle in order for you to operate the chain so with lightning of course its norm it's it's gonna be very very very large with plasma we only have some difficulties with certain models like plasma cash because plasma will support plasma cash and similar constructs support non functional tokens if you want to represent fungible assets you have to make changes and this introduces some small capital requirement with your knowledge proofs on the other hand you don't have any extra capital requirement at all it's a complete transparent chain where you all all the money you put in are gonna remain there you don't need this one cent extra so these are the approaches you can compare depending on the application on the use case different things are gonna be better suited we believe that your knowledge are going to be the future for secure chains if you if you need high security it's going to be the best mix of UX cost and throughput and throughput actually it looks small however if we compared to let's say PayPal I mean till we reach this limit it's it's gonna be a good problem to solve by that so so I mentioned before we have two different kinds of zero knowledge proof techniques which can be used for scaling the Starks and Starks both because of the S of 16 part in it so we have 16 on interactive proofs sixteen transparent proofs arguments of knowledge they are mostly this from the user perspective they are the same you don't really like the from user perspective what matters is the cost and proving time and yeah the verification cost but you can deal with them as a black box under the hood they differ significantly in characteristics so snarks are Starks are poly logarithmic and the prover is an poly logarithmic which is the prover complexity is comparable it's taken approximately the same amount of time - or amount of resources to compute snarks and Starks proof however the verification because of the proof size favours snarks way more for the public block chains because in public block chains we have the guessed limit or other otherwise limiting the bandwidth of the network it's really very hard to beat 300 bytes which starts we're gonna have hundred kilobytes if the price of inputs is gonna go down and theorem maybe it will be more or less efficient but snart's will always remain better so why don't we use snarks right now why why is nobody well has nobody done yet any solution which is in production for scaling I mean of course we have snarks in in Z cache but not for scaling yet the reason for this is the trusted set up so this is the ugly part of snarks or has been so far we need to create to profit to create some predefined data which we call common reference string which the participants or the people who create this this data have to use some external entropy and then they have to delete this entropy and forget it and there is no way to prove that they have actually forgotten it that's why if one person creates the trust a set up is going to be very difficult to trust it right the trust assumption is gonna defeat the very purpose of the public dog chains that's why we have something like MPC multi-party computation ceremony similar to what Z cash did with first sprout and then sampling where n participants compute the trust is set up and if at least one of them is honest and deleted this initial entropy which we refer to as a toxic waste then the entire ceremony is safe it's enough to have just one honest participant in other words in order to compromise this ceremony all of them together have to collude and join the data and then use it to generate fake proofs which for if we have a lot of high profile respected credible participants it's gonna be I think it's gonna be very convincing that they cannot do this but we can't at the moment these snark techniques which we which we have the most efficient one being growth 16 requires the trusted setup to be done for every application for every specific circuit and for every update of this application so whenever we do just one small change we have to read around the entire truss to set up and we have to go in this multi-party ceremony and every participant has to secure their data and it's getting very complicated and very costly so this is why snarks have not reached wide adoption yet however we have a new promise a new new hope on the horizon it's called sonic it's a construct by John Ball from Z cash he announced that the beginning of this month and there is already implementation on the way by Z cash and by matter labs a matter that is going to be faster probably and the special thing about Sonic is that it's still requires the trusses set up but the stress is set up is universal we do it once and we can use it for all applications and for every update which is to reuse the data which was produced by this initial to set up and it's also updatable so if you have your application and you want to use sonic trusses setup produced by by a group of highly trusted participants but you still don't trust them you can always take it and add your entropy on top and then you're going to be 100% sure that there was no back door and on compromise so from practical standpoint this actually this completely solves the problem I mean there's going to be people who never trust trust Isetta because they're trusted but for if we have significantly trusted or significantly credible respected participants it's probably not going to be a problem yeah so that's it for now you can follow the developments on Twitter on my account we're gonna have some interesting news probably this year there there gonna be some some more protocols coming out which are even more efficient and we're gonna see some implementations for this on etherium so yeah thank you for your attention [Applause] turn us can you can you go back to the slide with logarithmic and the constant this one so my understanding is that snarks are considered to have a constant verifier complexity because they initialization because of the initialization parameters essentially they pound you in some way so couldn't you also consider this with Starks that if you say that the N is like up to a certain size theoretically you're still like oh one with just a huge constant well you still not gonna be all funny it's still gonna grow logarithmically it's gonna be pick your initialization parameters such that you never exceed this number which makes your complexity constant you put an upper bound like which is constant based on your other limitations you put because since night you're the computational complexity that you can prove it's bound by the ceremony what you do is that correct this is correct so we go to the to some maximum amount of circuit if we if we have the same with Starks we will have or also well it's yes you can say it's like it will be practically off one but with very very large see yes the constant is gonna be extremely large and what matters here is the practical implementation the the practical cost on the blockchain so for now the verification of snarks costs about six hundred thousand gasp if it's just one snark if you base multiple snacks together it's gonna be much cheaper each additional marginal cost of each additional snark is around 150 KS with Starks it's gonna be in the order of magnitude of several million gasp for for the very for the very low like if we go for the same circuit size which is not strictly comparable with in Starks and Starks but if we like to let's say we go for the same amount of computations it's gonna be much much more even with poly logarithmic asymptotic radius okay no more questions Peter the next step is vault Sonic so the as I mentioned there are two implementations to the best of my knowledge which are going on right now for Sonic's 1 by Z cash another one by metal apps I think metal apps is going to be faster because the cash focuses on different things but I mean it's up to them and we all you're right you're absolutely right we we need some things to change in aetherium in order for us to be used to be to be able to use Sonics we need different pretty compiles for different elliptic curves and we expect this to happen hopefully by the next hard fork which is scheduled for August we'll see we were working closely with food guys who are responsible for the hard fork from then on once the implementation of the prover and the pre compiles are done we can immediately use sonic for production etherium then the only thing missing will be the actual process setup ceremony with large number of credible participants well I guess you have started the project B before the attack on on snacks well the attack that was released on the spout protocol to be knock you basically so you had to update your trusted set up as well and to make it compatible with with the core 16 because otherwise anyone can fake fake posts so what happened in sprout the it was not strictly it was not an attack and it was not even an exploit it was a problem in the price was a a mistake in in this software implementation that made it possible for people who knew about who would know about this mistake to use the public transcript and to produce fake proofs now we don't know whether this happened or not probably not but it was it was just a mistake in the implementation because basically the security was was the one of Pinocchio but then because they changed this the change typically the pairings yeah they moved to a different proof system they moved from Pinocchio to growth 16 and after that and they deleted the entire transcript so that nobody can reuse it and then they made some honest undercover story about this and so on and they pissed Peter thought but why this happened let's take a systematic approach why this actually happened in the beginning I believe that the fundamental problem was that the trusted set up of sprout was not I did not get as much public attention because it was specific to just this one project which would only benefit the easy cash stay collars so it was not enough incentive from for people in the broader cryptographic community to go and oh did it strictly and check the code and the specification and make sure that all the parameters were correct simply because they the incentives were missing now with Sonic this is gonna be different because sonic will be everybody will be able to reuse it if Tyrion will be able to do so other blockchains enterprise applications and so on and so on it's much more interesting we expect the participants in the sonic trusted set up to be much more high-profile and to be much much more much more diverse broadly represented by different communities and correspondingly also the the attention to detail and peer review and hold it is going to be much higher level and by the way there was a paper pushed by God which has the cabin area festering updatable as well so Universal before the sonic so why there is much more attention to sonic people oh all other constructs which were before sonic we are not efficient ok I actually have mentioned that sonic shares the asymptotic characteristics of snarks that is the the breakthrough of sonic all the other things before were were not usable just because they are too expensive so it was a mistake not not in the protocol itself but in the in the paper yes and they just implemented they the record with a mistake well the code was implemented according to the specification which was incorrect yes complexity is quasi linear and not only the guys mix I'm just wondering if that changed is that no it is quasi linear it's an poly log n so it grows with with an e with the number of operations you have to perform almost linearly slightly more than linearly just like with snarks socks are slightly more efficient but it doesn't matter because the the proofs are they are a little slow now so you it will take between 1 and 20 minutes on average maybe five minutes with good hardware but we expect also new hardware to appear and we expect also to use GPUs and other optimizations and eventually Asics for this so they're gonna go to negligibly low levels so it won't matter it will be very close to the native computation of really of whatever you're trying to prove okay okay I think it's done thank you very much [Applause]