 Hi, everyone. My name is Guy Ziskind. I'm the CEO and co-founder of Enigma, and I want to tell you today how you can build scalable privacy-preserving smart contracts on Ethereum. So the problem with blockchain is that it's completely public. Everything you put on the blockchain is there for everyone to see and also forever. That means that you cannot use sensitive data on the blockchain today, and that's a big issue. I'm sure you would all agree that any application today, whether centralized or decentralized, is going to need to use sensitive data in some form or another. And obviously this greatly limits the potential applications that we can use with the technology. So if you want to be a bit more technical, smart contracts, which is the unit of execution that we have in blockchains gives us correctness, but it does not give us privacy. Correctness means that if you're running a computation, then you can be guaranteed that you're going to get the right result, and no one can tamper with it. And that's great. That's why we're really excited about blockchain technology. But we need something stronger, and a stronger definition is what we call secret contracts that provide both correctness of the execution, but also privacy of the data. So Enigma is the first available platform for you to build secret contracts and execute them. It is the first time that you can actually add and use sensitive information on the blockchain without compromising decentralization. Enigma works by using privacy-enhancing technologies that allow you to basically compute over encrypted data. That's the main secret sauce. The second part, for scalability, we take the position that execution should be separated from consensus. Blockchains are really good at reaching consensus on small amounts of public data, but they're not good at keeping privacy, and they're not good at scalable execution. So we have a long history of actually doing this. A few years ago, we came up with these two ideas, and we published these in two papers, Decentralizing Privacy and the original White Paper for Enigma. And these papers currently stand on more than 500 citations combined, so they really become a cornerstone in the space. And really, they were the first to crystallize the ideas that if you want to have privacy in the blockchain, you've got to use some additional cryptography. You've got to use something that allows it to compute over encrypted data. And on top of that, if you really want to have scale, you've got to separate execution from consensus. And you know, I was here this week, and it was really inspiring to see that so many other projects are actually taking that approach right now. So maybe it's taken a few years, but it seems that the industry is finally coalescing into the idea that execution and consensus should be separated, and that privacy for smart contracts is really important, and we should not settle just for transactional privacy. So I'm mostly going to talk today about the Enigma Discovery Network. This is the first network that we're pushing out right now. The network has all the great features I told you. It allows you to execute these secret contracts and its scale, but it also has other important properties. It's permissionless, completely. It's economically incentivized, which means that we use some form of proof of stake model. And I think what's mostly important for developers here and for this talk is that it's compatible with Ethereum. We don't want to make you choose between Ethereum and Enigma. There's enough of, you know, copycat blockchains in the space. What we want to do is make sure you can build the best decentralized applications that you can. So we build a very seamless bridge, and I will talk about it later on, about how you can actually combine public execution on Ethereum with private execution on Enigma. So the best way to... The best way to explain the protocol is for it to discuss the stakeholders. So as usual, we have developers that write code. We have users that then interact with these secret contracts with that code, and we... Where things kind of change is that we have workers. Workers are basically the nodes in our network that are running and executing secret contracts. We use these definitions to kind of separate them and not to confuse them with Ethereum nodes and miners that reach consensus. The basic architecture is as follows. As I said, developers deploy secret contracts to the network. There's... Users can then submit tasks, tasks with the equivalent of Ethereum transactions, and that basically then gets executed on the Enigma network, and final consensus is reached on Ethereum. For developers, we support two modes of execution, two modes of, I'm sorry, of writing contracts. You can use Solidity, which many of you know, or you can use WebAssembly-enabled language, primarily Rust. We're keeping Solidity for backwards compatibility, but actually, Rust and WebAssembly have a lot more benefits. We're seeing the industry go in that direction, and so if you really want to enjoy all of the benefits and scale that the system can provide, you should probably use the WebAssembly route. From a user perspective, once a secret contract is deployed, the user can interact with that secret contract by submitting tasks, which are again the equivalent of Ethereum transactions. The main difference is that a task can include encrypted inputs that the user supplies. Under the hood, what really happens is that the user commits a proof of the transaction of the task on the Ethereum blockchain that actually helps us reach consensus on the ordering of the task so that the Enigma network does not need to do this, and we reuse that trick all over the place. Whenever there's something small that we need agreement on, and it's not a heavy computation, we do that on Ethereum, but the actual execution then happens on Enigma, which is a separate network. The way that works is we start with it, the user starts with a task, right? He sends the task to the Enigma network, but which node is a task propagated to? We're not using the naive approach that current blockchain use, where everyone computes everything that is counter productive to scalability. Instead, we have a proof of stake model where we sample a group, a group of workers, a constant size group of workers, to actually execute that task. Those group of workers are always weighted by stake, which means that if you stake more tokens, you are more likely to get selected to more computations. That really increases scale that gives us a form of sharding that is fairly simple to implement and that we're going to have up and running in about two months. Then that quorum, these committees of workers, they actually run these computations at the end of an epoch. For performance reasons, it's not just one computation that this group is assigned to, it's actually a group of computations that are bounded by time in an epoch. At the end of the epoch, the workers submit the results back to Ethereum. Ethereum only does very small verification, making sure all of the state changes are correct. If that's the case, the workers get incentivized. If not, they get penalized and slashed. I'm going to go a bit deeper about what a secret contract execution looks like internally. What's important to understand here is that each secret contract has an encrypted state. That's like an Ethereum state for contracts, but the difference is that this is end-to-end encrypted. When a computation comes in, then the current encrypted state goes in, basically lives in the network, and the workers that are running the execution, they can update the state, however they see fit based on the computation, of course, and then they can spit out a new modified updated encrypted state. In addition, users can supply encrypted inputs, users can supply encrypted inputs, and then get encrypted outputs that are only selectively revealed to them. Now, what's really important in this slide is how we bridge to Ethereum. We have a third type of output, which is the Ethereum callback. Basically, if you're a secret contract developer, you can add a special return statement. That return statement can take the output of the secret contract that just executed on Enigma, call another smart contract on Ethereum with the output from Enigma as an input to that smart contract. That completes the full cycle. To give you a concrete example, if you have a voting smart contract, we do know how private voting, how hard it is to achieve that in a good way on Ethereum. What you can do, you can have the private voting happen on Enigma. On Enigma, users can supply their encrypted votes. The actual telefunction runs on Enigma workers, and then at the end of that, you can commit that result back as input to another smart contract in Ethereum that can do whatever business logic with those results that it wants. All right, let's switch gears a bit. So far, I told you a lot about how Enigma architecture works and that we have encrypted computation, but I was kind of hand wavy. Let me explain to you how we actually protect privacy in the network. For discovery right now, we're using trusted execution environments, or T's, to actually achieve these privacy guarantees. T's are basically a secure region in the processor that can hide any data and anything that goes inside of a computation from even the host. So a malicious host cannot see what they're computing over. It gives us great scalability guarantees. It gives us strong privacy guarantees. But we're actually thinking about how we can do better. There are other privacy preserving technologies that are available today that are purely cryptographic. This is actually a good time to say that when Enigma started, and I was a student at MIT, my thesis was on how we can achieve privacy preserving smart contracts using secure multi-party computation, or MPC, which is one of these techniques. MPC is a distant cousin to fully homomorphic encryption. They both try to achieve the goal of computing over encrypted data. But because MPC is still orders of magnitude more scalable, we are focusing on developing that. One final note on ZK Snarks and Starks. There's a big misconception about these technologies. They're an amazing technology, but at the same time, ZK Snarks and Starks don't actually allow us to compute over encrypted data. What they allow us is that if we trust someone with the data, that someone can then prove a computation over that data without actually revealing the data to anyone else. But you still got to trust someone with the data. And in the context of smart contract, this doesn't work. Because when you execute smart contracts on the blockchain, the nodes are untrusted. You can't trust them to actually see the data. So ZK Snarks and Starks are with the exception of very specific use cases like transactional privacy that are usually explored for scalability and not for privacy. Long story short, we need something like MPC. And I'm going to give you a quick background about how that works. I can't go into too many details, but I'll try to give you the main idea. So MPC works in this paradigm. Let's assume first that we have an ideal world. In this ideal scenario, we have one trusted machine, a God-like machine, that we can send any computation to, and any sensitive data, and we can trust that machine to always produce the right results and never to leak the data to anyone. This is obviously not possible in the real world. T's, trust us, execution environments really get us to the limit of what's possible with that, but it's still not perfect. If we want the perfect solution, we need cryptography. So MPC comes and says, you know, maybe you can trust one machine, but if you can trust a network of computers where all of the nodes in the networks don't have to be trusted, but as long as there is at least one honest node in that network, then you can actually run secure computation. You can actually run any computation and achieve both privacy of the data, everything remains encrypted, and you can get the right result. It's an amazing, it seems almost impossible and counter-intuitive, but we actually know that from the 80s. So let me walk you through a simple example of how that works. Let's imagine we have a very small network of three computers, and they're going to do MPC to solve the problem of computing over encrypted data. So first of all, we need to find out how can we store data in this network. Storing works by a process called secret sharing. It's actually not that complicated, but I'm not going to explain it here. But the main idea is that you take a piece of data, let's say that data is called X, and then you split it into different encrypted shares and only send one encrypted share to each computer. So the first node gets X1, the second X2, the third X3. All of these are independently encrypted. You can do the same with any amount of data that you want, let's say Y. And now let's run a simple computation. So let's say we want to run addition. Well, it turns out that addition comes for free. Because of the properties of secret sharing, all you have to do to compute the addition of X plus Y is ask each one of these computers to just combine the numbers together locally, and that's it. And then when you want to decrypt the result, what you have to do, you have to send all of the shares of the data back to someone, that someone having all of the shares in one place can decrypt the information. But an amazing thing happened here. These computers have run a computation. They don't know the X's, they don't know the Y's, and they don't know the Z's. All they saw, if you're probing to, if you zoom into one of these computers, all you see is encrypted data. And yet, this guy got the decrypted result. So that's the basic of MPC when it comes to addition. Multiplication is more complicated, but I do want to go at this on a high level of how it works. So for multiplication, it turns out that we need something else. We need something called multiplication triplets. Multiplication triplets, that's the A, B, C. They are correlated randomness. So A and B are just random numbers that are randomly generated independently. But C is correlated because it's the product of A times B. Okay. And now every node has these triplets. These triplets are independent of the data, so they can actually be computed a priori. Like you can put a supercomputer or these computers can work overnight and just generate many, many, many, many of these A, B, and Cs. The reason is that these A, B, and Cs are then used as a one-time pad and they cannot be reused. So you really need many of these pre-processed for computation. So now let's do the actual computation. We want to compute x times y. What happens here is that each node takes a one-time pad of their share of x and y. The reason they do this is because then they need to share these with each other, which is what happens here. And then when they share it with each other, they can, because each one of them has all the shares, they can decrypt a number called D and a number called E. D and E are basically a one-time pad of x and y. Why is this important? Because if we had not done this step, then all the nodes would have shared their x and y's together and by the property of secret sharing, if you get all the x and y's in one place, you can decrypt the actual information. So this is a master. We cannot avoid this. But because C equals A times B, and if you then plug that into this equation just by a very simple algebra and you're going to have to trust maybe, everything is going to cancel out and you're going to end up with z equals x times y. Or actually each of these z's is an encrypted share of x times y. And so at this point you can just send those z's back with the addition and hold and behold we computed multiplication over encrypted data. Now that might not sound that exciting. I mean addition multiplication, fine. How do we get general purpose computing? Well it's a very known result that with addition and multiplication you can actually compute any function. And that's what we use and that's technically what I believe other techniques like FHE and Snarks use. That's really all you need. So how does that tie back to enigma and what are we working right now to develop next beyond trusted execution environments? So the idea is, and there's only a small amount of difference we need to make. The idea is that when a user now submits a task instead of encrypting those with AES or something and just sending these to the enclaves what they can do, they can do the secret sharing. They can split these into shares and share one and send one share of the input to each node in the in the worker group that is randomly assigned. And everything else kind of happens as the same way. The worker groups having the secret shared version of the data of the inputs, they can get, they can take the WebAssembly code and then just go one by line, line by line in the WebAssembly code and interpret that as an MPC protocol. So for example, if you have an instruction, if you have an instruction that says, if you have an instruction that says let's multiply two numbers where it's actually being interpreted as what I showed you two minutes ago. Now I'm running out of time a bit so I what I do want to focus on is first of all that this is live today. We have very serious projects building on us and there's a whole host of applications where this is relevant. We're talking governance, auction, secret ICOs and privacy preserving DEXs and many many other use case. And at this point I want to invite Isan from our team to actually show you a live demo for privacy preserving voting. Thank you. Hi, excited to be here. Nice to meet you all. My name is Isan Rifkin. I'm a software developer at Enigma and part of the protocol team. Today I will demonstrate a demo that is built on top of our application but before I want to make a claim and kind of walk you through this. So, unchain governance, what is this? So it's kind of at risk if you think about it. We're trying to build this decentralized world, this decentralized applications, but the more we grow, the more decisions we need to make in the decentralized environment and this means voting. So if we look today, the common use cases for voting are TCRs which is token curated registries and DAOs. By the way, raise your hand if you know what the TCR is. All right, TCR are basically a list, a list of some vendors and reviews. You can think of a decentralized Yelp with tokens. So we have TCRs and we have DAOs that maybe we want to vote on a change of leadership or maybe we want to fork the network. So all of those require voting. Now usually this scheme is done with something that is called commit and reveal. It has two steps. The first step would be you hash some vote, you commit this on chain and then you have this period of time where you have to reveal the real value on chain and validate this. Now there's two, well it kind of sucks from a user perspective because it requires you to remember to reveal your vote in a very limited period of time. So if you know Civil Project for example, they send Google calendar reminders to tell you, hey, don't forget to vote, otherwise it's lost. And also it doesn't prevent vote bribing because you can always see who voted for what. So with the demo I'm demonstrating now it's kind of solved, right? So basically the schemes today are on chain voting is subject to automated bribery attacks. You can have different attacks and this is a problem. So now I'll show you a demo and if you want to build something like this all you need to know is Solidity and JavaScript to interact with our network. So this is a voting application based on top of the Enigma protocol and this is just in the browser. So maybe the internet would work. Oh okay, so basically we have here accounts, Ethereum accounts at our disposal. They're connected to a test net and we'll access them programmatically. We have tokens we're using for vote and you buy those tokens and you use them to vote at some exchange rate. Then we have stake tokens. I know it's blurred. Those stake tokens is for you to do weighted voting. So you can stake five tokens and vote with a weight of five. After we do this we need to buy tokens. So we will buy 10 tokens and we will stake five of them into the contract and now we need to create a poll. So we need to insert some bits of information. First of all we have quorum. So we will choose a quorum of yes votes divided by the number of total votes should be bigger than 50 percent and it's a simple majority. So if we have more than 50 the poll has passed. Then we need to ask a question so is privacy important in voting and very topical and then we need to add some period we will say 60 seconds. So we have 60 seconds to vote. Go ahead create the poll and then users can start voting. So the first user will go in and say stake five and say yes privacy is important. The timer keeps growing and most importantly is the result you can see in the console. It's saved encrypted in Ethereum. So just to reiterate no one no third party sees this information and who voted for what. So this is an important aspect and then we need to vote again right. So after this happens we'll switch in account. This is all testnet of course. This is why it kind of happens behind the scene. So we'll stake three tokens and we say no privacy is not important. Again you can see the result is completely encrypted and this is how it's stored on chain. So again you don't know who voted what. At the end of this timer a very important function will happen on our side. This will trigger a computation. The nodes on our network will fetch the state from Ethereum, compute over the encrypted data, tally the results, commit them back on chain and modify the contract state on Ethereum. And yeah we can see that the success for those of you who keep count we had five votes saying yes, three votes saying no. So privacy is important. And then on the front end we have this event listener just simply listens to an event on the Ethereum account, on the Ethereum network and you know once the poll is ended it can update the UI. That's all. All right so I know we run a lot of time but I just want to finalize and tell you some exciting things. Secret voting the demo just saw is not just a demo. It's actually being produced by very reputable companies in the space. We have Aragon and Ocean Protocols actually building privacy preserving voting on Ethereum right now. You can actually look at the code if you want it's live. Another amazing example is machine learning over encrypted data. So Eximchain who's working with us has implemented a scheme where they can classify or creditworthiness that's what the plane here represents in the diagram and they can keep the actual weights of the model completely encrypted. So they can hide the model from the network and still continue to train it and get better predictions on whether people's credits is worthiness or not. Enigma is live today. You can work on it. You can build on it. Just go to enigma.co slash protocol and start building. We have documentation. We're open to feedback. The code is open source. Everything you need is there. But what's even more exciting that I want to announce today is eggs. Enigma growth grants. Enigma growth grants is really the best way for you to become involved is the new emerging ecosystem. We're going to work together with the people who apply to grants. We're going to fund this. We're going to help this evolve. And this includes a lot of the core things that we need to make the enigma platform an independent thriving ecosystem. Now enigma is exploding right now. It's growing very fast and there are many ways for you to get involved beyond eggs. Whether you're a developer or a user or you want to just run node and stake and earn rewards all of the information that you need is packed on this slide. Thank you very much.