 Hi, so my name is Jacob Eberhardt and I work at the information systems engineering group at TU Berlin in Germany And I'm here today to talk about Socrates, which is a toolbox for CK snarks on ethereum So let's first look at how Transaction processing works in traditional blockchain networks as you can see on the left the transaction is sent to the network It that then gets validated at the first node and is then broadcast to the other nodes And at some point it gets included into some block after someone solved the proof-of-work problem Now imagine if we had a system like on the right side where a transaction is sent to the nodes in the network But instead of directly being validated on chain they get forwarded to a third party the yellow box here and That's where the transaction processing happens after the processing of chain is done The result is written back to the blockchain and on chain. It is verified to be correct Only that verification would then happen redundantly and not the transaction processing itself So what would be gained through that one thing would be scalability if the Verification is cheaper than redoing or Executing the transaction in the first place if you only have to do the verification on chain then you can increase throughput Also, there is no such thing as the block gas limit that comes into play here because there's no need to circumvent the halting problem a Second aspect is that private information that gets used on that external node Can if we use the right tools be kept private and they do not have to be published to the blockchain at work Which is also what we not have at the moment So what are approaches for that? We've heard an excellent talk by Jason earlier about true bit and true bit is one such approach where you Gain scalability by off-chain and computations and then there's that verification game played on chain and with that you gain scalability Another approach is a non interactive zero knowledge proofs In that case you additionally have zero knowledge That means the private information you use during your processing on that external load. They are not revealed to the network Okay, so what could those non interactive certain knowledge proofs be one Yeah, proven mechanism is CK snarks I think many of you are aware of that technology and it stands for zero knowledge succinct non interactive arguments of knowledge and here are Several key properties of CK snarks So the proofs are short and non interactive that essentially means you can simply take a proof Generated by a prover send it over the network to a verifier and without further communication. It can then be verified Also, we have a certain knowledge property that means some information that goes into the processing Is not revealed to the network later on? Verification cost and that's a big one is independent of the computational complexity of the initial computation So no matter how complex your computation is the cost of verifying a proof is always the same Okay, so that's a key aspect now a little inconvenience is that to specify Computations in a way that you can do certain other proofs on you have to Think in an abstraction. That's not very convenient to most developers So for example, you can specify computations as arithmetic circuits or rank one constraint systems Of course, you can do it, but it's just not convenient to do and that's what yeah impacts usability negatively Let's take a brief look at the process of using CK snarks before we move on to the tool itself because it's necessary background so Here on the left we have a circuit or rank one constraint system that encodes a computation in that case we just multiply two numbers and Demand that that equals another number and for example RSA encryption uses a different a similar construction From that circuit or rank one constraint system the first step is the so-called setup phase which is needed to arrive at the proving key and a verification key that are then later on needed in the proving process So this setup has to be performed once for a circuit or rank one constraint system And then it can be reused over and over again On the right side here, you see the verification process based on the proving key a prover code for example First find the solution for the problem at hand and then generate a proof that it correctly Executed that computation and found a solution and the cool thing is it could Optionally supply all the information that went into the processing But it could also keep some of the information to itself in that example here the prover only supplies set Which is the result of the multiplication and not the factors themselves that went into it and the verifier can then check the Correctness of the computation without redoing it and that is much cheaper that Verification process then the the proving process and with that the execution of the computation itself in the first place Um Socrates so with Byzantium Ethereum added three new pre-compiles that enable CK snark verification on chain So we have elliptic curve addition scalar multiplication and a so-called pairing check But the big question is how do we use that and that's where socrates comes in So the vision of this toolbox is to provide a usable abstraction And tooling to support CK snark's only theorem to actually make them usable The goal is to support the complete process from program code specification to On-chain verification of the execution of that program code It's supposed to seamlessly integrate with the theorem and how it does that we'll see in a minute Socrates comprises several things one is a domain specific High-level language that allows you to specify your computation in a more abstract way than Arithmetic circuits or rank one constraint systems which are inconvenient then we have a compiler which transforms these programs into provable constraint systems and Then there's support for the different phases We need to go through with a CK snark So the setup phase finding a solution to our constraint system Which is the witness computation the proof generation itself and then we can also using the tool Export a solidity smart contract that can then be used to verify the computation on chain Let's briefly look at the language So the language at this point is pretty close to the constraint system But provide some more convenient abstractions to specify circuits So the data type we have is prime field elements You can just think of these as positive numbers Smaller than a huge prime number. So essentially think of it as positive numbers Then we have imperative statements, which is the abstraction most of you should be used to when programming We have assertions. We have loops We have conditionals and we have functions which allow you to Structure your code and keep it a bit less redundant So let's look at an example here for n choose K or binomial coefficient The upper function here computes the factorial We'll not look at that in detail because it's just not important What's more interesting here is the lower part is the main function as you can see the main function here takes two arguments N and K and then there's a return statement now in socrates The arguments of the main function and the value of the return statement are public That means when you prove that computation you use that code to prove the correct execution execution of that code and K and the return value become public if you do not want that to happen if you want to keep that private that Information you can simply not list that as arguments But still use the variables in the processing as we do here and then when you supply the proof and the inputs And on K do not appear in there and all the person verifying that thing would know is that you Computed the binomial coefficient and what the result was but N and K would not be known Let's look at the user perspective and the command line interface or criticism provides you So you start with high-level code you write that high-level code and it gets Compiled to a set of conditions or also called flattened code Based on that you can then find a verifiable Available assignment for that code which is basically a solution to your program and that's called a witness So you can use a tool to find solutions for your programs and it also supports you with a setup phase So you can use a tool to Compute a verification key and a proving key which you will need later on Based on the verification key you can derive a solidity smart contract Deployed to the network and then verify proofs that were generated with the proving key that came out of the same setup phase And to generate a proof there is that generate proof Yeah Command which takes a given witness that you computed previously and the proving key and together you generate a proof that can then be Verified by the smart contract you created beforehand The internal architecture of the tool looks like this. So we start with code in that domain specific language and that goes into a part of Puzzle is then flattened and then you have an interpreter which Compute solution to the program Here you can decide which part of the solution will become publicly available and which part will remain private So here you have the control and then after that we do just some format conversions to Yeah to Interface with the lip snark library, which we use for the CK snark operations themselves Then there's the contract exporter which can be used to Export solidity smart contracts to verify proofs Okay the on-chain proof Verification looks like this. So on the left side here, we have what the socrates to generated is a proof it consists of eight elliptic curve points and inputs on the other side we have a Verification contract which we also generated and that contains a verification key Seven elliptic curve points is what that is made up of and then there's verify function Which uses the new pre-compiles that came with Byzantium to? Yeah, check the validity of the proof and also make sure that the inputs were correct At the moment a verification like that costs around about 1.6 million gas. So actually a lot That means on a Robston testnet we can do four in one block on the main ad It's currently six in one block the gas cost varies a bit with the amount of input parameters we We give with the proof, but the main cost is constant and and rather high a Couple of challenges an outlook of how we want to proceed with socrates What would be cool in the future? So I think for the language to be more usable more convenient We would want additional types. So for example boolean types everything You can do with boolean types can be done now but it's just not as convenient to do it on prime field elements and then some Integers that have a binary representation internally What's very important and that's basically implementation work ahead of us is Domain specific library with important functions. So next thing we need in my opinion is hash function so we can do commitments in circuits and then Signature encryption that would be nice to have also we want to look at integration of other front ends That can also be used to arrive at rank one constraint systems. For example Buffett a generic ck snark challenge that is not specific to socrates, but rather Yeah, always comes up when speaking about ck snark is the trusted setup phase So if you supply a verification smart contract and you want to verify Something someone else proves to you and you're the only one to be convinced You don't have any problem you run the setup and you know that you did it correctly And thus you can trust the proofs and you know that the person proving to you cannot fake proofs because you were in control Of the setup, but if you want to use these proofs to also convinced third parties other parties Observing these proofs on on the blockchain Then they would have to trust you with the setup phase So what would be great if we could eliminate some of that trust by integrating a distributed setup phase? it just would have to become a bit more efficient than it was in the Ccash multi-party computation protocol for example, which they employed to do their trusted setup So I think we'll hear more about that on Friday in the Ck snark breakout session. Hopefully Okay, so the code is open source. It's available on github. You're all welcome to try it out I'm happy to receive your feedback Keep in mind. It's proof of concept and a research prototype at this place. We're actively developing it and We're always happy for people who want to contribute to the further development you can also contact me by email and I want to give Credits to Christianreidwiesner who always Provided very valuable feedback and input in discussions and also to Dennis Kuhnert who contributed a lot to the existing implementation Thank you very much