 Okay, hi everyone. Thanks for coming week 12 Friday to hear this talk so This talk is about succinct proofs first scaling blockchains And we're going to make more sense of this title as we go along. So let's just get right into it so The first thing I want to ask to get a sense is how many people know what a blockchain is a show of hands Yes confidence. Yes. Okay. There's about about half their room So who's confident enough to kind of take a step at defining it? Anyone want to throw out some suggestions? Okay, if not then I'll just give a technical definition of it. So a blockchain is a peer-to-peer replicated state machine and What so you guys are aware of what a state machine is? Yes, okay, so it's a it has a set of instructions It takes in some input and it has some state and based on the input and instruction it changes the state So that's why it's called a state machine So this state machine in a blockchain is basically keeping track of a ledger So it can be a ledger of unspent transaction outputs like in Bitcoin or it can be a ledger of Accounts and account balances like in Ethereum for example So that's called the state of the blockchain and it's replicated across all the nodes of the blockchain So everyone who's running a Bitcoin note for example has to agree on the current state of the whole network And it's peer-to-peer because anyone can run a note So it's not the case that we are all looking to a central note and querying it for the current state But we maintain a local copy of the state so the thing is About such a peer-to-peer replicated structure is that it's very hard to scale and that's because every phone Now is required to do a lot of computation. So they firstly need to maintain full state they need to Maintain a full set of transactions and They need to validate all the transactions by executing them So this is a lot of memory. It's a lot of computation and This also means that the network is basically limited to what the weakest node can do so The rate at which the weakest node can process and execute these transactions and how many transactions the weakest node can store So if we want to naively increase the transaction throughput We can just say oh we'll decide to put more transactions in each block But that will lead to fewer and fewer nodes being able to keep up with this block size And so that will lead to your blockchain becoming Effectively more centralized to those with enough computing power So that's a naive solution to scaling the blockchain and this talk will be about looking at other Ways of scaling the blockchain that still allow it to be decentralized So I'm not sure if you guys have heard of starting So starting is a very common thing in distributed systems. It's basically I'm splitting the state of the system into several different parts and We no longer require every node to know about the full state But instead we only require each node to know about the part that it's responsible for so Instead of maintaining full state and maintains partial state it maintains only a partial list of transactions and it only needs to process process a partial list of transactions as well So for extra reading you can oh these links might be a bit dated But you can basically just Google blockchain sharding. I saw that Zilliqa for example had come to NUS hackers before So they they're very they have a great sharding solution Yeah, so that's that's what's known as layer one scaling because it splits the actual blockchain But the talk today is not about layer one scaling. It's gonna be about layer two scaling So who here has heard of this concept of layer two scaling? Right, so layer two scaling is a different approach than layer one because what it tries to do is Take computation off the blockchain. So onto a second layer a higher layer and Naively you can think of it like a side chain. So this is your main save Bitcoin blockchain and You with one transaction you transfer an asset to a side chain. So for example, you trust some moderator to run their own Private blockchain and you trust them to basically recognize this transfer onto their chain and And What's good about doing your transactions on this private chain is that? basically for example, only one person is in charge of maintaining the state Executing the transactions and they can do it as fast as you want for as cheap as you want and there's no burden on See thousands of peers to replicate this state and to agree on the same state So it's gonna be fast and cheap on this side chain and When you've done all the business that you need to do you can simply with one more transaction Push the state back on chain So if you count the number of on-chain transactions, it's only one and two Yeah, so this is a nice solution because as I mentioned the person running this side chain has to be trusted Yeah, that's a problem with this solution and and So we need to trust that all these transactions here were basically performed in A valid way meaning that this person did not do anything malicious did not insert any double-span Did not drain the balance of some unsuspecting party like and transfer it all to their own account, you know all this We have to have faith and basically and whoever's running this side chain So that's not very nice when we outsource our computation. We want to be fairly confident that it was carried out according to our wishes and in other words that the state transitions are valid but The point is that we do not want to redo the whole computation ourselves So we can check the state transition is valid simply by replaying all the transactions that happen on this side chain But that would defeat the purpose We would still be doing the same amount of work that we would have done on the main chain So we want to be lazy, but we also want to Be able to have confidence that our instructions were carried out So a few so there are two classes of solutions to this basically Two ways of putting constraints on the operator of the side chain To make sure that they behave the first which we will not discuss today. It's called fraud proofs. So there's this whole group of people in the blockchain world who work on plasma It's a cool sounding name But all it means is that Basically when the operator of the side chain submits the state back to the main chain We open a challenge period and anyone can submit a proof that something wrong has been done And and that some some part of the state is not as expected so this this still stays on computation because we um Basically, it's innocent until proven guilty So only when we have some cause to suspect the operator do we need to do any work and Submit the challenge and even when we submit this challenge. It's only one Transaction on the blockchain. So it still does save computation But complexity can arise with fraud proofs when for example, you consider all the situations all the challenge games that can happen and Actually, it's very game theoretic and People have also started using predicate logic for example to better define these games Yeah So that's one that's one way to keep the side chain operator honest the other The other approach is validity proofs and this is what we will discuss today So validity proofs basically Make it such that the operator cannot commit a mistake So fraud proofs are such that the operator can commit a mistake but can be caught Validity proofs are such that the operator cannot even commit a mistake So that it is not possible for the operator to make an invalid state transition yet Yeah, so for fraud proofs You can think of it as Kind of the question was for fraud proofs to detect the mistake Wouldn't you have to do the computation yourself and the answer is yes But you would only have to keep track of your own assets basically so whereas if everyone was on the main chain everyone would need to Keep track of everyone else's assets as well rest for fraud proofs you only need to for example observe your own coins history and basically Listen for any anything that's going wrong Anything unexpected. Yeah, so it still does save Yeah, any other questions before we move on Okay, so yeah today we're gonna talk about validity proofs And we're gonna talk about them By exploring this construction called roll up So as I said Roll up is it takes the approach of validity proofs meaning that at each state transition at the time of each state transition The operator has to prove the validity of their actions So this is roughly how it's gonna work. So we have state one this on the blockchain and then Off chain we have This is the side chain basically so on the side chain people are submitting transactions very cheaply to some central coordinator or operator and What happens here is basically that the operator has to take all these transactions Process them and at the end of this process Produce a succinct proof that he actually executed these transactions according to some predefined rule so This succinct proof is actually a mathematical object that we will explore in the next few slides but Let it be said that this succinct proof is desirable because it is very cheap to verify so after After the succinct proof is produced the operator has to submit it to the main chain and the main chain will verify it cheaply and Only if this verification passes will the main chain allow state one to transition to state two So this is basically what we're trying to do Let's see Yes, so basically it's called succinct because as I said verification is efficient. So Verification is actually constant. Yeah, so it doesn't depend on how many transactions you have. So it's a constant verification time and Yeah, if you recall this fulfills our objective of not wanting to recompute anything Everything so instead we only need to compute this tiny verification, right? So, let's see Yeah, does anyone watch Silicon Valley? Yeah, so Basically, what have I told you that For any program of arbitrary length with an arbitrary number of inputs We can produce a proof that is Constant size the proof itself is constant size and its verification is also constant time That that would be amazing, right? Yeah, that's what we can do So how we do it how we create a succinct proof is using this Mathematical construct so ZK snarks have people heard about zero-knowledge proofs Yeah, so this is the one type of zero-knowledge proof. Yeah, zero-knowledge Substinct non-interactive argument of knowledge ZK snark And there are a lot of ZK snark constructions So the most efficient one known today is graph 16 by Jansk Roth in 2016. So as I said This is a constant size proof that can be verified in constant time So given a circuit That defines the set of computations you want to follow Given a set of public inputs, which are your transactions and A set of expected public outputs a Prover can convince a verifier that they know a set of intermediate gates Which satisfy the circuit So we're gonna we're gonna explain this in the next few slides What's important for us here is that this is succinct And it actually also has some other nice qualities. So for example zero-knowledge meaning that the prover can actually conceal however many inputs they want and still convince the verifier that their computation was valid And this should also be sound meaning that No incorrect proof should pass the verification Of course complete meaning that a correct proof should always pass the verification So I will mention here that soundness is probabilistic in graph 16 and in most zero-knowledge constructions and this is because of some Information theoretic magic. We'll go into it later Meaning that there is a chance an arbitrarily small chance that an incorrect witness can still pass the verification Yeah, any questions before I move on No, no, it's not I think this actually Actually good question. I'm not sure if we can define it in our Implementation, but I don't think it's dependent on the size of the input Yeah, but if you guys want to look up the graph 16 paper Well written So let's go more in-depth into what this proof is actually doing So as I mentioned before our circuit defines a set of rules that we want to follow and Over here. You see that they're quite reasonable rules So for example, if we want if Alice is sending an amount of money to Bob We need to check that for example Alice signed the transaction check that Alice is a real account Check that she has enough money And all these basically sanity checks But if we don't perform these then the operator can get up to all kinds of mischief For example, if Alice is colluding with the operator She has zero balance, but she still sends some money to Bob and the operator credits this out of dinner, for example so So this is This actually is very close to the state transition function that is defined in Bitcoin Yeah, but the point being we're stuffing it all into this circuit. We're not going to perform all these on chain Instead, we are with we're compressing it into a succinct proof so You you also see that We have a set of inputs that go into this circuit So with every new batch of transactions, these inputs will change depending on who's sending how much to home And as I mentioned just now you can choose to keep some inputs private and some public So for our case it doesn't really matter We were not really concerned about privacy, but there are other projects who focus on privacy and for example, they want to keep the They want to keep the identity Private or they want to keep the amount sent private That's an option in zero-knowledge proofs. I have a couple of slides that actually walk through 16 and it's very mathematical and I don't think I will go through them today Because I gave this talk a few months ago and I think this is the part where I lost everyone I Recommend you guys to read this on your own but on the big picture level basically we start with an arithmetic circuit and Express it as a rank one constraint system. So it's almost like a Pictorally you can think of a set of wires of inputs and outputs and then We express the rank one constraint system as a quadratic arithmetic program and all this is to massage it into a Form that's amenable to a succinct proof So and then from quadratic arithmetic program into a non-interactive linear proof and finally to a snark so Yeah, like I mentioned, please read this on your own if you're interested and just quickly Yeah, well we covered just now from the arithmetic circuit to the snark it's actually all the prover's job Before the prover can start doing this This snark this particular construction requires a common setup And the point of the setup and approving is that this is where all the computationally intensive work happens So all this work is done basically the comp compile a huge program into a tiny proof and it's all this stuff is known as pre-processing and We do it so that by the time we reach verification. There's very little left for the verifier to do Yeah, so verification requires Very very few not a lot of information and not a lot of computation. Yeah In standard zero knowledge proof, right, the verifier has a choice to ask whether you want to Perhaps be the a or b. That's the only how it works But so if given the negation won't the prover have to re-prove every single instance Verifier asks a or b Okay, I think I know what you're referring to so For example, probabilistically checkable proofs are when the verifier Gives a challenge to the prover and the prover needs to Basically compute the correct answer. Is it right? Yeah, so what was your question? It's a typical zero knowledge proof setup. You will have your verifier or this challenge in some sense issued So in some sense, but Usually it requires a new proof every time the verifier issues a challenge So this wouldn't that be computationally demanding? Uh, okay This That's how in theory a zero knowledge proof works. So what we are doing here is An uh, so this caught us that same non interactive argument of knowledge, right? So what you describe just now is An interactive oracle proof Yeah, so basically, uh, the the verifier asked a question The prover answers it and instead of doing that here We pre compute all the questions that the verifier can ask so and this is random randomly computed and so the prover Notes all the questions and and has to answer all of them correctly But the prover doesn't need to engage in this song and dance with the verifier If that makes sense Yeah, so that's why it's a non interactive Um Okay, so That was basically the math behind Compiling a program a large program into a small proof And now we're going to show you how we use it in this particular construction on the blockchain so Yeah, we call it roll up um So we've seen this diagram before Yeah, basically what we described just now is from this Uh circuit to this small proof And we also describe this verification So how we're going to use this So, oh, this is how we're going to use it on the blockchain So is everyone familiar with a merkle tree? A merkle tree is a binary tree um Where all your leaves, um represent Basically the state you're interested in and as you go up the tree you hash together The children and you you repeat this until when you reach the top You get a a hash that represents the state of the whole tree, right? So And this is a very nice sort of accumulator because if one If the state changes in one of the leaves, um, this state will change, right? So We can use a merkle tree to represent our state in each leaf is an account with some balance And nonce so the nonce is just an index counting the number of transactions you've made This is a simplified version of the ethereum state um So we've defined our state and on this state we would like to perform some valid Transactions some valid state transitions so These uh a valid transition transaction is basically what we defined earlier in our circuit And after a valid transaction is executed We get we basically go from an old state to a new state We in a valid state transition So we'll go through one example of how this is done. So bob is sending one dollar to ellis You can see bob's leaf over here and ellis's leaf at the extreme left so We received this transaction from bob, right the first thing we do where the operator first thing we do is we check that Bob signed it So this is a easy dsa algorithm And we check that bob actually exists in this state tree So to check that bob exists What we do is we require a merkle proof from bob. So a merkle proof is basically all the Notes and inner notes necessary to hash from bob up to the state route Yeah, so bob needs to along with his transaction give us these three notes And we hash it ourselves And we I mean we better get the state route that we accept So any questions by the way? Okay, so once we're satisfied bob exists We check that his balance is enough we check and After this check We're happy to actually update bob's account So how we update bob's account is We Deb uh, we debit one dollar from his balance We increase his nonce by one and then we use the old merkle proof that he gave us to do that same hashing And get this time a new state route right so And then we need to Basically do the same thing for ellis And I will not bore you with that. It's exactly the same thing We check ellis exists We check we update ellis's account And then once again, we use ellis's merkle proof to update the state route one more time So we've done two updates of the state route Yeah, that's one transaction from bob to ellis and the operator can perform An arbitrary number of transactions like this Yeah And still get a constant size proof Yes, so Basically what you've seen is one transaction from bob to ellis And then let's say c and d also want to perform a transaction. So they have to um How did we do this? Sorry Right, so it actually has to happen on the operator side. So the operator needs to keep track of basically which Basically the state route and which inner nodes have changed. Yeah So as you can see we do rely on the operator to be honest and to Keep good track of the state But the caveat here is that if the operator is not honest or is very disorganized And cannot produce the right proofs, then there is no way that he can pass the verification So yeah So these are the Once again the constraints that our circuit has So this is what we're going to we'll represent as an arithmetic circuit component as night These are the inputs and outputs Um, and as I mentioned If you're very privacy conscious you can choose to Reveal only the minimum of information Yeah So that is the minimum information Yes, it's the minimum information because Yeah, so the we want to keep The state route public because the verifier actually needs To check that the the proof is transitioning from the current state route to the newer clean state route Yeah, and this is useful for Basically anyone who's keeping track of the public blockchain To perform their own sanity check But you're welcome to think of other constructions that Save on the number of inputs. I mean something interesting about public inputs is the more you have the more expensive It'll be because you actually need to publish this information on chain Whereas if your inputs are private, no one needs to know about them. And so You don't push that information onto the chain and that saves you Some cost any other questions goes into detail about how Yeah about how the circuit Yeah, basically this is graph 16 again You can see why it's constant size Each proof basically consists of three group elements And then Yeah, so it's always three group elements. Yeah, you can see here that we're using the fact that the state route is public to allow the smart contract to basically Transition from one valid state to another Yeah, so that was all describing transactions In roll up But the question one question you might have is How do we enter this system? Like How do we go from the chain? How do we deposit assets into the chain and see them appear? on the operator site So how we do it is we actually want These assets to be on chain. So they're real assets for example bitcoin or ether And so we actually deposit them on chain into a smart into a smart contract and We keep track of the people who've entered the system on the smart contract. So Within a smart contract. We are actually hashing together deposits as they come in So each time someone deposits we add a leaf to this deposit tree and With this The state route of the deposit tree keeps track of the number of people who have entered your roll-up system And to withdraw We basically define withdraw as a normal transaction except that it's going to a zero address and When this when the sender publishes This withdrawal transaction the smart contract can check that its recipient is the zero address And then credit the real assets on chain back to the person. So they basically exit your system right, um If you guys want to see a demo of this I can send these slides around later Um Basically Oh You can play it. Have you guys used Ethereum applications before? Okay, so Hold on. Let me just read one. Oh no. So what we see here is, um Someone depositing Oh, we don't someone depositing money into the system and then Uh performing a transfer and then withdrawing their money back out into their account so You can see that deposit and withdraw are actually on chain So you need to unlock your Ethereum account to actually do these transactions And you can see that the transaction went through on the blockchain So that's basically roll-up and that's how we outsource computation In a succinct way to reduce our computation cost on the blockchain Some considerations because this is not the only construction out there So this construction is useful in particular if you want to prove the same constraints multiple times and that's because if you recall we have a very intense Setup pre-processing phase. So set up improving and if each time you plan to change Your circuit and change the rules of your state transition Then you need to perform A costly pre-processing For each circuit basically So this is only suitable if you plan to stick to the same set of constraints Um And another consideration is the prover needs to do a lot of work So this is not the most democratic solution So you You most likely want to outsource it to someone with a big server basically Um Another consideration is that the setup phase is actually trusted. What this means is that it contains some Information that the prover can use to make invalid proofs. So This is known as toxic waste. So projects who actually carry use zk snarks in production What they do is they do the trusted setup and then they destroy all the information from it And some There's this project called zcash. They have a public burning ceremony. They take the laptop and they smash it and burn it To show that they got rid of toxic waste So, yeah, but if you don't trust that, um, then that's a consideration to have in mind Um, there are other constructions. There are not growth 16 Which do not have trusted setup. So the prover can never make an invalid proof And the last consideration here is that it's not quantum safe Yeah, so it assumes that the discrete log problem is hard and um The answer to this consideration is another construction known as start sub-sync transparent um arguments of knowledge So you can check that out yeah, basically Um, I would say cryptocurrencies have revived interest in zero knowledge proofs and so in the past Few months and years a lot of new constructions Have come up that do not have trusted setups that are quantum safe So it's a very exciting time to be working on zero knowledge proofs so there's some future directions that, um Oh, this slide is a little bit outdated. Um, but basically this construction can be applied to more than just layer two So for example, it can be applied to communications between blockchains it can be applied to light clients or stateless client models um And there's also a sort of There's also a class of snarks called recursive snarks Where basically within a snark you can prove a snark Yeah, so You get even more savings If each time each time your proof gets way smaller so There's a project called coda that actually has implemented recursive snarks. That's all. Um, I want to say that I'm interested in Anything to do with p2p privacy cryptography So if anyone else is interested in this and wants to work on a project together, please talk to me. Um Yeah, I do work with the ethereum foundation But I'm a physicist by training. Um, yeah, I'm interested in exploring this p2p cryptography space not just blockchains either Yeah, so yeah, that's all for me. Thank you Any question? Yeah, so when you say the proofs are three other three elements of the proof Are they three like numbers or? Yes, what are they specific way? Uh, they're group elements. So So You're familiar with group theory. Yes Right. So they're just elements in a certain group. Uh, it has to be Yeah, it has to be a group of Unknown order if I'm not wrong over a pine field You can you can look up the specific group in the paper. Yeah, sorry Yeah Yeah True Oh, um, yes, uh, I think the drawback so basically Graft 16 is a pairing based zk snark. So basically they use an A pairing operation on elliptic curves So if you want a recursive snark, you need to find a curve that can Basically support pairing operations of another elliptic curve and these are Few and far between these elliptic curves. I think they're called mnt curves Yeah, so the kinds of computations that you can define are also more limited Um, recently zcash came up with a construction called halo Uh, so halo is supposed to be Yeah recursive zk snarks. Um But their paper doesn't have any proofs yet. So the construction is there but the proofs have not been done yet Yeah, but definitely a lot of people are looking into this at the moment I can say very high I'm trying to get back to those mathematical Yeah, you can see here So Very high that amount. Okay. Yeah, the idea is Sorry So the exponentiation here, let me talk about I'm not sure No, I don't it shouldn't be impossible To prove Yeah Yeah, I mean it definitely the complexity of the perver goes up with the number of transactions. Yeah But the size of the proof So if What does that mean is that most efficient in terms of computation or the size of the proof or So, yeah the size of the proof Most efficient meaning most efficient verification. Okay. Yeah so Yeah, because these sorts of constructions are concerned with outsourcing computation and Letting more limited clients basically verify Exactly that, yes Yeah Because Um, right. Yeah, so this is definitely bias to the bear fire. Okay. Thank you