New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

EthCC 2: Sergey Nazarov

Ethereum ParisWed, Oct 9, 2019, 12:00 AM

Speaker

Sergey Nazarov

EthCC 2 EthCC, the Ethereum Community Conference is created by the community, for the community. It brings together great minds and forethinkers, and allows the community to grow. Follow us : @AssethFR https://ethcc.io

Transcript

thank you hello yep okay okay hello yes wonderful okay we're good to go after a lot of stuff but we're in Paris it's beautiful so it's that's fine like even a fire drill here is great right I wasn't here for the fire drill but you go outside and it's so beautiful you're like i-it's okay it's a fine show it's fine I'm a guy can be fine with this okay so I guess I'll just jump jump right in so or I won't because nothing works and we need to make it work yes sorry makes sense okay now it's gonna work Oh fantastic it moves it a little bit to the left and to the right but not it doesn't cycle it so I can move it literally a pixel left and a pixel right where I can that's a cool feature the one pixel left or right feature my USB yes okay apparently apparently there's a protocol for this there's a whole set of sorry I'm not sure why this is it's probably me so it's because it's a PDF I see yes everybody's deep in thought anyway you know just a second so it is everybody else's PDF also can I move the laptop over there can I just move it along from the laptop can't bring the laptop over there yes yeah sorry again about the delay not sure why why that happened but we we seem to be good now so thank you for your for your patience yes so the fundamental problem we're gonna be talking about is the the Oracle problem or essentially the problem of how do we reliably trigger a contract now just just in case you know just so we have all we have the same kind of ground to stand on the same ideas to to work with it's important to understand that the contracts on aetherium or you know the vast majority of other chains they essentially cannot reach out to data so smart contracts running any theorem if you've gotten farther along in a process where you're building a contract that needs to know about market events or a contract that needs to know about IOT data for insurance or a contract that needs to do anything other than tokenization by being able to consume data or you need your contract to reliably generate off chain events it can't do that so this is this is a very large limiting factor in what what contracts can do without the ability for a smart contract to talk to an API and get data you can't you can't you can't have it compete with existing digital agreements that already do that you can't you can't make a lot of things you can't make high quality derivatives you can't make insurance products we can't make trade finance products you you can't build much more than token at tokenized assets of some kind which is a huge limiting factor it's this limiting factor that we seek to that we seek to basically get rid of now if we're able to get rid of this limiting factor it's very possible we go to the next stage of the spaces development to put that into context what I mean by going to the next stage of the space is development it might just be useful to do a quick overview of how the space has evolved I mean the smart contract space so initially we had mold signature functionality in Bitcoin that was considered a smart contract that's all you had for smart contract functionality then you had protocol opcode based protocols those were started around 2013 and they they allowed you to make a smart contract like a decentralized exchange or something else and in order to have with that smart contract type you needed to go to a protocol developer and you needed to get them to change their protocol which took months of development tasks and deployment so you couldn't write your own contract you had to talk to a protocol developer and they had to be baked the contract right into their protocol then assyria made a very substantial leap forward of allowing people to go from i need to talk to a protocol developer when i make a concert one i want a new contract to i can write my own contract so now people can sit down and they can write out they can script out their own contracts and that means people can script up really cool stuff right so the features massively expanded the types of contracts massively expanded and the space grew right like a lot of the companies out there you know outside of this presentation room and out there in the world they can exist because people can script up a type of contract that they weren't able to before so that that's a great thing I think that aetherium did for for the largest lot larger space the next stage of development that that we think is very likely and and very useful is the stage where we go from scriptable smart contracts to externally connected smart contracts so what that means is now I can script up a contract but what I can script it to do is much greater right right now all I can do is I can write make a scriptable smart contract for token movement what what the world is going to be like very soon and I think is gonna be a very large improvement is the ability that you could make a scriptable smart contract that can talk to various data feeds that can actually ship things on its own affect various events in the real world react to events in the real world and do that securely and reliably right that's another huge leap and features that's another huge leap in what people can build and in our opinion it's another very large expansion of what the smart contract space in general will be will be capable of doing so in order to get to that we need to solve this problem so we need to look at how do we get reliable connectivity between a smart contract a scriptable smart contract in a network like aetherium and the various data inputs payment outputs there that although all the events that a smart contract might want to consume and all the events that a smart contract might want to generate and how do we do that reliably now I'm going to go through kind of our approach to this we have a two-sided approach one side is the application of decentralization and the other side is trusted execution environments the the first you know kind of basic idea that we need to look at is how do we solve this problem is the fact that you know basically blockchain middleware also often called Oracle's is what solves this problem you have a piece of software that provides circle security guarantees about its reliability and has the capability of getting data to the contract and getting the contract to talk to other systems the the key point in our experience and in experience building Oracle's and smart contracts so smart contracts we've been building for over five years Oracle's you know for over three years and combining them for for a lot of different use cases excuse me the the key idea I think to keep in mind is that intend reliability is what every system that touches a smart contract needs so the unique property of a smart contract as compared to its alternatives as compared to digital agreements running an essential server the unique property of a smart contract is that it's highly reliable right if you have a private key that has a Bitcoin attached to it you have that Bitcoin no matter what happens you have it right if you were in a smart contract in aetherium you know assuming you coded it up correctly and you don't introduce a whole bunch of problems then it's gonna run right that's a unique property no other smart no other system of digital agreement has right in there in our opinion that is the unique property of this technology and if we want if we want a smart contract to be externally connected that unique property then needs to extend to the the middleware eventually the data sources so what you need is you need end-to-end reliability is basically what it is if people are gonna use externally connected contracts for any substantial amounts of value they need end-to-end reliability because practically speaking nobody cares if a part of your system is secure all people care about is if your system is secure which means the whole system which means the thing that triggers what happens in the system so this end-to-end reliability is is essentially the focus of our body of work a chain link it's on creating this block chain middleware that's both feature-rich open source peer-reviewed and you know we work with the academic secure the research community to get that as far as we can and also that it's extremely secure so one way you know just to put things into perspective one way not to solve this problem in our opinion is to use a single centralized Oracle that's you know provided by some kind of close source piece of software so if you use a single centralized Oracle then your point of failure is probably that Oracle the data source you're going to be using is probably a larger company with good security that has been around for some amount of years and then you're gonna have the decentralized computation network which is relatively new but supposedly very secure due to high redundancy and then you're gonna have one Oracle run by you know a small team of people using close source code this is the model we're trying to get away from it's it's a model where there's a failure mode and this failure mode eliminates the possibility of higher value contracts in our opinion so this this is essentially the model that we think we we have this model on a site called smart contract comm we we've been doing this model for years before and we just don't don't think it provides the it doesn't provide what the space is about so the the way to move away from this model is essentially to decentralize this mechanism so that you know that's the kind of foundation that chain-link is built on it's built on the idea that why don't I have an Oracle mechanism where if I want five Oracle's or ten Oracle's or 15 Oracle's I can choose how many Oracle's I want to guarantee the validity of an input and the accuracy of an input and unlike you know traditional blockchain networks where I'm forced to buy twenty one thousand or however many thousands of nodes in in our variation you can say I want five or ten or 50 or however might have a much decentralization I want to consume is the amount of decentralization I can consume for the security I want to pay for so the first the first point is the centralizing this Oracle mechanism which once that's decentralized then you can decentralize the data origin level right so that the point is that we have a decentralized contracts they change layer then we have an Oracle mechanism that's decentralized and then once those two are decentralized then we could also decentralize things at the level of the the origin now just to put this in slightly clearer perspective because I know there's you know a number of kind of different ideas going together here and I'm still a little jet-lagged so yeah who knows what what's actually going on and there just just to make it slightly clearer a simple example would be delivery payment for delivery so let's say you had a high-value good arriving somewhere and you had it being triggered and you had that recorded and managed by a irreversible highly reliable smart contract right so because you have this highly reliable contract you don't have a lot of fallback scenarios you want to make sure the smart contracts execute correctly in in our scenario you can get the data from two different sources about yes my good has been delivered yes my good has clearly been delivered then you want to generate some kind of payment let's say you want to pay this person out in Z cash right for whatever reason you want to pay for this good in Z cash at that point your smart contract needs to know the market price of Z cash and then you also need to pay for which you also need a chain link so on the payment side with with the different providers of data if somebody were to manipulate the data input about the market price they could get a much higher payment from your highly reliable contract that's not a problem you want the way to possibly solve this problem is why don't I pay slightly more for a greater degree of redundancy a greater degree of decentralization my market price is now reliable I know that my contract will reliably pay the correct amount I now have a reliable contract that can know something about an important event and one that can reliably pay the correct amount so initially this is this is the beginning of our our approach it's the foundation on which which were built is the the fact that you should be able to purchase however much decentralization you want to create a reliable Oracle mechanism the other the other side of our thesis is also that we essentially are generating many pre-made inputs and outputs what that means is we have hundreds of chain links that represent discrete individual api's so what a chain link actually is is it's a contract on chain that represents a specific resource or API off chained so the one one of the other key ideas that is less focused on security is more focused on giving people useful building blocks is the is the fact that you know the way you build a web app today is you combine api's into some core code right you combine a GPS API and SMS API and a payments API and that's how you can build a new Varenne VP in a week right because you can write your core code and combine these ap is what chain link does and what we what we basically have is a large collection of these pre-made contracts that represent individually represent each resource that you would want to connect to your contract so that means if you wanted to build some kind of decentralized application and you at an interest rate and you needed a bank payment and you needed to send an SMS all you would need to do is to get your contract to talk to 3 chain-link contracts on chain and you would have your decentralized app doing those 3 valuable off chain events in a day or two so that's that's another kind of very important part of not as much the security but the features that we think will take the space to the next level so essentially this collection of of building blocks now the the next part of our thesis is something called trust at execution environments one of the reasons we've decided to begin adopting this approach is because we practice something called the defense in depth strategy defense in depth means that you're not my apically focused on a single approach defense in depth means that you adopt all the approaches that work and that's essentially the the philosophy we have a chain-link is that as better approaches like zero knowledge proof sand eventually homomorphic encryption eventually other approaches we seek to build the best Oracle middleware for all the high quality changes you would ever want to use as a developer on the basis of good security practices not on the basis of like falling in love with one approach so that the second approach on top of the centralization that we think has has merits worth worth exploring this trusted execution environments essentially trusted execution environments create a smaller attack surface area for each node operator what that means is that you have specialized hardware like Intel SGX being run by chain link node operators this means that you they can't inject vulnerabilities adversaries can't inject vulnerabilities because the the hardware talks directly to the application with its own segregated resources it doesn't go through the hypervisor it doesn't go through the OS that this is essentially the value of trusted Hardware the yeah so basically the the main idea is that you can't inject vulnerabilities in into an a chain link node as a node operator or as an adversary because supposedly trusted execution environments are reliable once again this is an additional level of security on top of decentralization the approach we use for this is something called Town Crier it's been on production for I think close to or maybe even over two years now using Intel SGX to provide data to a theory of contracts it's made by really really smart people from Cornell and ic3 and we're very lucky to work with them and we've been very lucky to to acquire Town Crier and bring it into into chain link as chain links approach to trusted execution environments essentially what it is is that the same thing as an Oracle just using a trusted execution environment that means that the Oracle software that runs on off chain is run in this segregated highly secure environment to query data sources verify that some data came from a data source and then sign that that data came from that data source putting both the data and the verifiable signature that the data came from the from the data source back on to back onto the chain back on back into the contract so what trusted executions provide is a number of very very good properties one of them is confidential off chain data delivery this means that you can send an encrypted data to a chain link node operator the chain link node operator can never know what the data is they can even do computations on the data and then send the results or the data back to the contract so this means that you could have multiple independent chain link notes coming to consensus you can have individual chain link nodes processing data and and that node operator themselves will never know what they're processing the the other piece of this that's very useful is the ability to do confidential credential management so confidential credential management is particularly useful if you want to chain them to do something like a bank payment this means that you can have you could have somebody that's not as good as security running the chain link that has SGX and the credential management is baked in this means that the reliability of doing off chain payments greatly increases without putting a burden on the people that want to offer that service so credential management generally speaking is a huge problem for any API your data data providers or payments providers that well a lot of them use credentials especially for premium data so credential management is a key piece and then the other really interesting piece that I think you know the folks in this room will probably appreciate to a degree more more than other folks is the control of private keys so the control of a private key for use by a smart contract is actually a really really powerful thing so if you want your etherium contract to control the private key of you know a hyper ledger contract or you want to control the private key of a Bitcoin address that that can sign multi six the the trusted execution environment can house the private keys that only a specific contract can use so you can basically put a collection of other or other across chain capabilities into a chain link house the private keys in that chain link and then say that you will only allow these private keys to be used from these commands by a smart contract and now the smart contract has control over a bunch of other private key based resources so the other thing that we've seen with trusted execution environments is the splitting of smart contracts into an on chain and an off chain piece so what this means is that there's either code you want to keep private or there's code that you don't want to run on chain for scalability or cost reasons this code can be run in a trusted execution environment confidentially and that at a larger degree of scale so this means that in trusted execution environment you can basically run the part of your contract you want to keep private or the part that's too costly to compute on chain it creates a lot of positive scalability dynamics and in fact the people that we've seen using trusted execution environments successfully have have moved parts of their contracts functionality into this environment because it can scale ibly and privately compute certain things that they wouldn't be able to do on chain this again expands what what a smart contract is able to do the other thing that is particularly attractive to us is the fact that you can do computations in the trust and execution environment of well-tested libraries so well-tested libraries mean that you can take a piece of code that has been around for 5 10 15 20 years that does some specific tasks like creating randomness or you know generating some kind of output that you need you can put that code into a trusted execution environment knowing that it's the highly audited highly reliable code you're used to using in traditional you know web 2 or web 3 web 2 world and and now you can run it as part of your contract in this environment so you can make highly valuable highly audited reliable code part of your contract and you know that it'll run correctly because it's running in this environment so one example of this that's particularly relevant to our space is the generation of randomness for lottery contracts so let's say there's somebody developing a lottery contract and they want to guarantee to their users that nobody is gonna collude so they want to guarantee that their lottery code that their contract is fair but it doesn't really matter that it's a lottery contract they they have an input of randomness that decides who wins and they want to provide a guarantee to their end user that that input that guarantees who wins is reliable is not gamed so in the scope of our thesis of the centralization and execution environments trust execution environments let's just kind of look at how that plays out initially what you could do is you could get a random number generation library run it and Intel SGX you know that code is reliable and widely used you run it in the say in trusted execution environment that's highly secure and difficult to breach it generates the randomness that you need which then gets sent back to the lottery contract so now now I've generated some kind of randomness in a unique environment using a well tested highly audited piece of code and the the trusted execution environment can even tell me hey I have I have generated this randomness from this code here's a signature proving that now let's say you like this additional level of security but you don't want to rely on SGX completely because it has its flaws or it has its worries or it's not finished or whatever whatever thesis you might have at this point the the flexibility of the protein-linked has is that you can say I want multiple notes I want a quorum of three five ten fifteen twenty however many nodes I feel I need to pay for however much decentralized computation I want to purchase and then you you you basically purchase that computation from a large collection of nodes the amount of nodes you want to pay for not the amount of nodes that we tell you not the amount of nodes that kind of like some magical system decides is the right number but the the amount of nodes that essentially a good design pattern says is probably the right amount of nodes and then once you have the randomness generated you usually want usually want to pay so and usually you paying people is usually what happens at the hands of most at the end of most contracts and then people usually want to be paid in the form that they want to be paid in they don't care what form you want to pay them in nobody cares that somebody wants to pay them in some format that they don't want to be paid in so essentially the the next piece of value is that once you've securely generated this randomness you've securely been able to trigger a reliable contract now you want to pay people in the form they want to be paid in I mean this this I guess is just an example of what a good highly reliably triggered contract looks like it's reliable on the edges it's reliable in the middle and it can pay people it can settle the contract the way people want this is in our opinion how the future of a good contract looks now just to recap essentially the focus we have is on end-to-end reliability that means decentralization and a multitude of inputs and outputs so people can build a large combination of truly usable contracts and on top of this decentralization a multitude of inputs the application of many other approaches starting out with trusted execution environments as being the one that might have the most immediate value and going on to others like zero knowledge proof eventually homomorphic encryption and and others so yeah I mean you guys are welcome to to look at what we've built we have a booth we have some technical folks there we have a workshop on Thursday where one some of the folks from our company are gonna dive into some more detail on how to work through building something essentially our company exists to enable people in this room to build great great contracts that's what our company seeks to do like our company succeeds if we help you guys build really cool contracts that's that's that's what we're that's that's what we're doing with like up our time and our lives and we're just we're recently building all this because we think that once you have all the all the necessary building blocks in place you can build great things and and that's what would make us really really proud and happy and I think it would really help you know expand the space to a new stage of development so you're you're very welcome to check it out and we were very open to feedback if there's anything we're missing anything you'd like to see anything you'd find to be particularly useful we definitely want to hear about it and yeah I appreciate you know your attention and I know if I have time for questions if I do I don't because of some time thing yeah sorry I don't know what happened with time that was drilling I got I got a cut okay we're good yeah sorry no time for questions sorry about that okay thank you [Applause]

Automatic transcript — names and jargon may be misspelled.