EthCC 2: Sergey Nazarov

in my I'm good to go I think I'm just gonna start for the sake of time yeah so hi everyone thanks thanks for joining us to think about Oracle's and polka-dot I'm a little bit jet-lagged so hopefully this will all make sense and add up in being English so the problem we're going to be examining is something called a smart contract connectivity problem or the Oracle problem this is the fundamental issue that the smart contracts people built today can't access data so if they can't access data they can't know what's going on if they can't know what's going on they're severely limited and what they can do this essentially means that without access to data all that smart contracts can do for the most part is move tokens around now moving tokens around is great and tokens are great and that's all very exciting and I'm a fan of tokens but it would be really great if we could get smart contracts doing things other than tokenization if we could get them talking to data feeds to trigger relevant contract changes about the delivery of something about a market event about an IOT event for insurance and the fundamental issue kind of the common ground that we need to have to have this discussion is that there there isn't right now any built-in functionality for that and there likely won't be and so what you essentially need is an Oracle now to put this in context I think that the space has gone through through a number of shifts where the functionality of smart contracts are networks like aetherium soon to be are networks like polka dot that because the features of smart contracts have increased they've evolved into doing more I mean that's essentially what we're talking about is increasing what a smart contract is capable of doing so to put that in context I think it's just useful to look at you know how the evolution has developed so far so I think the initial leap forward for smart contracts happened in you know obviously in 2009 there was a lot of progress at Bitcoin 10 11 12 and then in 13 you had the appearance of the protocol opcode based smart contracts that's where you had to code into a protocol that you would have a decentralized exchange or insurance contract or something else so you couldn't you couldn't write your own contract you had to go to the protocol developers and they had to put whatever smart contract you wanted into their protocol so that was one very large shift that's actually the shift that God got mean a lot of people that have been in the space for five six years very interested in in what smart contracts can do the next shift was basically put forward by etherium and it was a very large addition in features it was a very large step forward in that instead of having to go to protocol developers you could break your own contract so contract it became scriptable and you could script up whatever contract you felt you needed decentralized exchange of 50 flavors insurance contracts delivery for payment whatever papers are payment for delivery whatever whatever contracts you wanted so this was the next large shift that I think we as a community observed the the shift you know just to kind of put into perspective what we're we're discussing that the next large shift in in our opinion is a shift from scriptable contracts that can move tokens to scriptable contracts that can do everything else so scriptable contracts that can send payments they can well bank payments they can know about off chain events like IOT data for insurance they can know about market events they can you know release data to people based on the fact that somebody performs some contractual obligation they can you know just identity data from off chain systems so that's somebody with the right identity can do something relative to the contract so all of these multitude of basically off chain resources inputs and outputs being made accessible to a contract will essentially exponentially expand what they're able to do so we would literally go from moving tokens to everything else that a digital agreement can do which encompasses all the financial services industries trade finance insurance basically everywhere where you have a financial contract have any value so this is the kind of body of work that we achieve link are focused on and that we're hoping to bring to many communities like polkadot to enable those communities to build high quality contracts essentially our body of work is the creation of a middleware essentially the creation of a a secure reliable Oracle that can trigger contracts in various networks etherion based networks polka-dot by various various other networks to both allow those contracts to react to relevant off chain events and allow those contracts to generate off chain events so for example that smart contract can trigger a shipment a smart car a smart contract can start doing meaningful things the way that digital agreements do today so like we I go to a lot of a lot of meetings like today this is what I these days that's where I seem to spend a lot of my time on with people that are building these contracts and the reality is that the people who have already been building a form of smart contracts essentially digital agreements the people that have been building digital agreements the centralized form banks insurance companies fintax various startups the digital agreement they have has all these capabilities their digital agreement run against some server and they're in in their bank it can talk to data and it can send payments wherever they needed to be sent and it can affect whatever change they wanted to affect and this makes smart contracts not as attractive in my experience opinion an opinion once that feature exists the reliability of smart contracts makes them superior as long as they can also react to all the relevant inputs and generate all the relevant outputs we'll get to the part about polka dot and how we're integrating into the net into that network and so on but I think before we do that it's important to understand kind of the usefulness of of an Oracle what it could enable and that fundamentally what we're doing with with the polka dot network and other networks is is we're generating a collection of inputs that developers and that ecosystem can use in combination with their contract so they can write a piece of contract code and they could have react to data where they could have it send the bank payment or they could have it you know ship something or they could have it deliver a pizza to your house so they can have it do whatever whatever they wanted that code to do other than move a token in order for us to actually deliver on this on this idea it's very important that we're able to do it reliably because fundamentally the value of a smart contract the unique property as far as I can tell is that it's reliable it's extremely reliable it's so reliable that nothing can stop it it's it's it's it's super reliable it's it's it's just it's the most reliable form of digital agreement you could hope to have for for a small amount of money large amount of money whatever whatever contract value you have that's a unique property that's the unique property of our entire space right bitcoins unique property is that it's reliable you have a private key you reliably have a Bitcoin you've tied to that private key right that means that all the relevant like essentially mission critical systems or the systems that are gonna affect what a smart contract does also need to meet a high level of reliability because in my experience actually implementing this for for real use cases people aren't as interested in a piece of a system they're interested in a solution they're interested in something that works and to end right if you talk to to a CSO or CIO or lead architect and you tell them I have a great system it works in the middle but on the right before then and right after that is completely vulnerable how would you like to use my system it's not it's not it's not as valuable assuming that that CIO or the architect wants to build something that reacts the data and generates of chain events so the the real project of making a reliable Oracle is the project of making a secure Oracle an Oracle that can provide the same types of guarantees that a smart contract provides one way not to do something like this in our opinion is to have a single centralized Oracle that's maybe running closed source code and you know which is run by some some group of people that can just decide to basically you know either have that Oracle go down or it can easily be taken down essentially that that model is is an example of a model that's incompatible with the logic of our space the logic of our space is why is a smart smart contracts are fantastic because they're reliable they're reliable because there's the centralized computation there's multiple redundant nodes computing what a contract does and that that isn't the model of a single entity a single note that's easily easily manipulated easily shut down easily DDoS easily you know easily manipulated essentially there's two sides to the solution to generating such a such a reliable Oracle that that we're pursuing then that we found to be the most the most likely to succeed in the near term essentially the first solution is you apply the logic of our space which is the centralized computation to this same problem so just like the smart contract is reliable because it's computed in a decentralized environment the Oracle mechanism is also computed in a decentralized environment you have multiple nodes securing the contract state you have multiple nodes computing the input of data and then that also allows you to decentralize with data sources you use so if you want to improve on multiple data sources instead of one once you decentralize the middleware layer then then you have that option yeah essentially I mean I have a very simple example that I'll just put this into perspective if you were paying somebody for delivery you could have two sources of data proving that the delivery happened one is a primary and one is a backup and then when you wanted to calculate the payment amount let's say you wanted to pay them in cryptocurrency you would need a market price and you would need a highly reliable market price because of that was manipulated then the payout to them could be excessively high or if you manipulated it could be excessively low so in this example you have multiple independent nodes querying multiple independent data sources providing that decentralization of both secure middleware and data to allow a contract to be reliably triggered and allowed to gain reliable data that it needs to to basically pay somebody accurately and then there's a multitude of of chain links that exist that can allow a contract to pay to exist in various existing data sources various existing payment sources essentially yeah the the project that we're engaged in is the creation of this large collection of inputs so the first property the first thing we need is that they need to be highly secure ideally as secure as the contracts themselves if that that can be possible and then ideally we want a large multitude of inputs that are pre-made so just like web developers have api's which are essentially pre-made inputs and outputs chain links or Oracle contracts on whichever chain the Oracle contract is on is a premade input right an Oracle is essentially a contract on chain that an that a user's contract can speak to and it can request something or it can request that the Oracle do something for the users contract so essentially essentially the goal is the creation of a large collection of pre-made inputs and outputs that can be easily combined with all the code that people are writing in their smart contracts today so we have been closely working with web 3 and thinking about how to best provide the various web 3 pair of chains with the relevant market data and other data they would need and essentially the way that looks is that there's there's essentially two stages in in the case of poccadot the first stages every pair of chain let's say you have like a derivatives pair of chain and you have a trade finance pair of chain and you have an insurance pair of chain and you know five other pair of chains for specific use cases where you get the scalability properties of these pair of chains or you know these are these linked chains chain link can essentially broadcast the contract on to each of those chains that's how the the initial implementation will look it will be you know a contract that's broadcast every chain that wants that data you want market data let's say there's 50 chains all 50 want market data about price market prices because they need that because they're you know chains that have Unchained financial products 50 chain-link contracts get broadcast one one on each chain and although all the contracts on each on each relevant para chain can then use its respective contract I mean this is an immediate solution it gets people off the ground it gets them building essentially our company exists to do that our company exists our body of work exists to enable people to build genuinely valuable smart contracts that go beyond to organization that react and generate react to and generate useful events the the second later implementation would essentially be the creation of a once enough usage starts happening on the relevant chains and you possibly have scalability concerns then you can generate pair of chain essentially an Oracle chain the chain where there's reliably a way to acquire data both reference data and specific data that the other chains can query so if if a large number of pair of chains begin using the same data at some point the scalability approach of poccadot might be useful as far as generating the chain specifically for the input of data into the other chains in a more scalable way I mean those are essentially the first two phases the first phase is essentially you know able able to work pretty much right away and something that we can you know we're looking forward to people using and people getting the benefit of being able to build something truly useful so yeah I mean that's the overview of the problem our solution one actually one part of our solution that's the decentralized part there's another part to our solution where we use trusted execution environments like Intel SGX and for that we acquired a project called Town Crier which was made by some some of academics and has been as far as I know the only Intel SGX kind of tea production system that hasn't been breached for delivering data to contracts on main net will be specifically using Intel SGX but well I don't think we have enough time to go into the trusted execution environment piece essentially I think the the important property for more publicly focused platforms or networks like polka dot is the ability to to get data in at all and then the ability to get data in in a decentralized form which matches up with the security model and the thesis of the of the network itself yeah so so I I'm kind of a little jet lag so sorry if my voice is a little kind of monotone I've just been kind of recently flew in and I tend to go on so I guess I can I can do questions now because if that makes sense if there if there are questions seems like there's a few questions yes right right here so that's a input side that you kept there can you tell us more about the outputs like Lupton just they have sort of an example of a small contract ordering a courier shipment or something like that is there yeah like a silly example is imagine a smart contract could use some kind of delivery API to order a pizza to your house like you know because now you can pay for the pizza using Bitcoin or something that's that's a silly example a more useful example is let's say you make a smart contract in the insurance industry and you want to pay our premiums and the people that would receive your premiums without the premiums but you know the payout from the from the actual the actual insured event and they want to receive it in dollars or yen or some fiat currency the smart contract needs a bridge to send those payments and in a traditional format yes is there any work on that yet or any examples of hobbits how that can be solved yeah yeah there's a we we have something called a core adapter model so we have core code which is the code rely that reliably secures the main operations of a chain link node and then we have adapters and adapters our integration level code that are written around the AP is so I think we have yeah we have a few adapters built around existing payments networks they require people's credentials and they require people to basically permission the chain link node to use their account but essentially what what we have in terms of chain link is a very flexible system for adding adding various payment sources you basically just write adaptor level code to that payment sources API or in the case of banks with messages or in the case of you know somebody else some other standard and that that means that the contract can generate a payment in that system and that code runs where are you talking about solidity code the runs a small contractor you talking about something runs on the outside in the outside so this is essentially middleware middleware sits in both worlds so it sits on the Unchained world in the form of a contract and then it sits off chained in an off train piece of software that essentially monitors that contract and execute the commands sent to it so that the Unchained contract is like an interface that other contracts can talk to for a specific resource okay and then presumably that's a bit more of a challenge to decentralize then say the inputs which is more sort of data yeah that's more centralized it's like quite difficult imagine decentralized a traditional that's a different challenge the challenge there is being able to do it at all yeah going from zero to one yeah oh maybe having some sort of competitions that's decentralized through it through through a competitive structure yeah traditional payments have a lot of regulation and a lot of things that you need to jump through so getting from zero to one is already a fix yeah I'm not thinking actually about payments I'm thinking about could be anything like hey ordering a courier or dispatching something or yeah you can but I guess there's systems where you can generate a payment then you can have other chain links confirm that a payment was generated even if they don't generate the payment so things like that can happen but I think there's other questions wrong - yes there's a fellow here right behind you hey thanks for the talk I was just wondering if you have like a decentralized oracle meaning distributed sources of truth looking at the same source or like multiple versions of the source a price feed of a single item picked up on different markets what kind of use strategy - uniform nation - like a single value and how does that not get biased by for example an attacker that puts in like a huge bias - this yeah so that really depends on the use oh sorry I should do this I've been told I should do this I should repeat the question essentially the question is how do we decentralize the origin how do we make sure that the origin of the data the data provider whether that's a data company and IOT device or whatever how do we reliably eliminate the risk that that's tampered with is that right right so then then what that comes down to is what people are willing to pay for decentralization on the level of the origin and if they can even have a decentralized origin so in certain cases with IOT devices like let's say I'm looking at temperature and I'm looking at temperature in some geographic area or I'm looking at some kind of weather event in a geographic area and I have multiple sensors or I'm looking at a field of solar panels that I'm ensuring and I want my contract to know how many solar panels are failing I have a multitude of sensors right so then I can I can take a subset of that distribution I can randomly query you know 50 solar panels and if you know all 50 work then there's no problem right then the contract doesn't pay out an insurance insurance amount but then for the it it's it's all--it's chain-link is part of an architecture so essentially there are different design patterns for different contracts and those design patterns depend on how much people want the centralization whether they can even get it based on the data source there's just a number of factors essentially what we're seeing in practice is that there's four different use cases like derivatives there's many sources of market prices so the design pattern is let's let's get multiple data sources for IOT based insurance where there's only one source of data there's only one source of data the design pattern is you're stuck with that right there's no like clear-cut answer it's it's just I think the key idea is that the important thing is that we provide people a flexible secure system to cruise the design pattern that secures their contract that's I mean that's essentially the body of work that in another way I like six ways to describe what we do but that's another way to describe it any other questions for Sergey hi how does chain link technology aims to be blockchain agnostic yes you specifying the polka dot network in this talk but it also works in the others blockchains examples what is that a core code which is sorry could you speak louder what makes the chain link technology blockchain agnostic Oh issue yeah sure makes sense I think everybody heard the question I've been told I have to do this essentially how do how does Cheerilee become blockchain agnostic it's the same answer as I gave earlier sort of there's this core adapter model so the core features are these security reviewed audited open source security sure that every reliable Oracle will need and then the adapter level code so you there's adapters for hyper ledger there's adapters for Z cash Bitcoin and and people in the relevant communities can also write their own adapters right so the the whole goal for us is that there's an easy way for you to to gain access to a large collection of inputs all you have to do is either have ask us or maybe somebody on your team usually through some kind of collaboration like the type we're having with the polka dot network and web 3u we arrive at an adapter that enables ya enables your chain and right now I mean we're able to turn those around and like something like a day a day and a half so an hour so our our goal is to make a flexible system where well it also depends on the chain it really depends on the chain as well but the other yeah essentially that's the answer the answer is a flexible system where literally you know every chain out there if you if you if you wanted your chain to have all these all these inputs all these data sources and all these payment sources all you had to do was to write an adapter and that might take you know day or two or week max something like that there's another apparently another one okay no worries that's cool so the people that get questions ask questions get a t-shirt now I'm wondering why they're asking the question I'm just yeah so something I was wondering while you were explaining how you make decentralized do you guys make any assumptions on the integrity of the data that passes through chain link or do you just assume that it's genuine and correct yeah so there's a number of approaches to this I didn't have time to get into trusted execution environment approach but essentially well actually sure I understand your question your question is if the data source tells for example three chain links that the value is one then those three chain links will all accept the value as one is that your question my question is more along the lines of what if you don't have enough sources to actually verify that I don't know the price of Bitcoin is $8,000 if you just have like two or three values do you just pass them on as correct or do you modify the values in some way to determine which is the correct value yeah well imputation system I think I think the question is what if I don't have enough data sources what if I don't have enough origins to create a reliable degree of decentralization does that sound yeah so that's if you don't have enough data sources to create the level of decentralization at the origin that you'd like that's a problem so in the case of market prices that's not a problem there's a multitude of market price data feeds and indexes so in that example it's not a problem in other examples it may be a problem there may be a situation where you have a single IOT device and you're stuck with that one IOT device but then you can get into all kinds of other other dimensions of security such as maybe the IOT device has trusted X has a secure environment chip right maybe it's signed something and then that signature is verified in the chain links trusted execution environment so there's there's a there's a there's a few approaches that you can dial up and down depending on your situation the in the single in the single source it's likely that the trusted execution environment is going to be more useful and seems like there's another version of the question yes yeah I hear you maybe maybe Sergei will be around after this yeah we all go to the next time yeah I'm glad I think about this a lot so I'm glad to talk about it thank you thank you very much thanks a lot so yeah thanks for having ok so next we're gonna hear from Sean