EthCC 2: Adan Sanchez De Pedro

so good morning vomit on something like that I will be speaking on the future of blotting Oracle's and what this centralization means in an Oracle Network you you may probably have heard of the Oracle problem but the first thing you need to know about these problem is that it's not formalized at all so when someone is claiming that they are solving the Oracle problem what that does really mean what's what's even an Oracle at all so an Oracle is some entity that gives you knowledge that gives you access to your information that is that you cannot have access directly so it's a kind of a middleware relay for information that you cannot avoid you simply need it Oracle's are a thing in etherion and in the smart contract world because smart contracts are completely isolated from the rest of the internet from the rest of the world and that's for a good reason because at the end of the day a smart contract needs to be executed in a totally deterministic way because it's a program that will be executed across multiple instances of the AVN so it needs to have always the same result as long as it operates on the same data so if you connect a deterministic program to non-deterministic sources you are contaminating it with non determinism and you will not be able to resolve to ferret to find consensus on the other result of the of the contract so in some way we can say that Oracle is is some kind of middle word that abstracts away the non determinism from from this contract that it says how those uncertainties need to be resolved so the very moment that you take your smart contract and you connect it to an a data source from outside you're breaking the very most important property of smart contracts which is tamper resistance the centralization and trustless nests are only the way to achieve tamper resistance but at the end of the day what we expect from smart contracts is tamper resistant we want them not to be manipulating not to be censored by anyone either and for any system its security equals that of the most non secure element in it so we need Oracle's we need those entities bringing data into contracts to be as secure as decentralized as trustless as the smart contract consuming them are so what I will be talking about is the research on and all the development and know the design goals that we had when that foundation have taken into account when creating a truly decentralized oracle contract or sorry oracle network which is win it the first the first design goal is data integrity because the tamper resistance when we are looking at Oracle's boils down to data integrity so preserving ensuring that the data that is sent to the smart contracts is exactly the same that is presented by the data sources by api's for example so the first way that we achieve that is by doing some kind of crowd witnessing so taking multiple and notes from a network work and making them go to a certain API or to a certain website and a lot of the content and report that to the network that's the way to achieve that is by having a big pool of nodes in the in the network and randomly selecting a subset at small amount of nodes from that pool that will have no conflict of interest and that will report the value coming from the API from any data source and and this is chosen using a cryptographic sortition algorithm that guarantees that it's not predictable so this creates incentives in a similar way to shell in point schemes or to Vitalik batarians shelling coin because those nodes will be all only rewarded if the data they bring into the smart contracts is in consensus with that with the data that they're that the other nodes is reporting so we for that to happen we need a commitment and reveal scheme which means that the nodes creates secret commitments to the data points so that they cannot deny them afterwards they cannot change afterwards and then they've revealed the actual values they got from there from the data sources that prevents freeloading that prevents one else copying each other the other thing that we need is aggregation or multi-source fact-checking which means that at the end of the day if what we are saying is that we cannot rely on a single entity to provide information into our contract we cannot either rely on a single data source because it's it's pretty evident that in some high value fearing contracts the data sources that we are querying could have hag incentives to manipulate the data so that they tamper with the result of the contract so we need to query multiple data sources and aggregate all that all the data in a deterministic way on chain and one other thing that we need is not indistinguishably which means that the data sources should not be able to distinguish nodes in this Oracle network from their regular consumers from their regular users because otherwise it would be really really easy for them to target them with with fake data and in order to tamper with the contract without any negative impact on their public image or on their reputation let's say so the second design goal out of three is furnace furnace means that there's a very very low barrier to entry so you as a developer or a suteki should be able to create your own node to put a computer to resolve these data requests for bringing data into into a smart contracts without without big barriers to entry this is not something deliberately decided this is very very important because they lower the barriers to entry the more the the bigger the variety of operators and notes that will there will be in the network which means that it's much less likely that they will collude to tamper with with a contract okay so the low barriers to entry can come from having no requirement of minimum reputation because there's a repetition system there needs to be a repetition system in the in the network to ensure that we assign these very request tasks to the notes that have behaved and abided by the protocol more over time and the ones that have been reliable over time but it's important that even if you don't have any repetition you still have a chance to you to participate in the protocol also that no stake is demanded to participate and that the requirements regarding hardware are are very low and then the repetition system means that the power of its node in the network its influence and its potential income from resolving these tasks is proportional to their past performance the reputation score the repetition points flows from the outliers from the cheaters from the notes that are not behaving to the nodes that are reporting data in consensus with the other nodes that are selected for that mission and there's there needs to be some kind of progressive demarest which means that only because you have reputation points you lose reputation points and the more reputation points you have the more quickly you you need to lose them in order to make you to make the most important nodes in the network accountable to make them liable in case they corrupt okay so it's a kind of this phrase with very power power comes great responsibility and the third a very very important design goal is parametrization so for example we can parameterize what's the size of the committee how many nodes will be retrieving the data the quality requirement if we want at the the data request to be retried if we don't achieve consensus what are their words the fees may be optional collaterals what's the retrieval the aggregation and consensus function so how data will be retrieved from the data source is how it will be aggregated held will be transformed normalized and so that from multiple data sources we end up having a single data point and this is in our case we do this through Rayden which is a DSL at the minute specific language that we are defined for deterministic transformation of an aggregation of data it's a kind of functional language that resolves all the in determinations in a in a very expressive way and and at the end of the day how it works it's it's something like that you have used your own contract and from your own contract you make a call to contract in in in etherion that is the winded bridge interface that translate that call into a Wynette data request we need the request is a written file that describes how data will be retrieved aggregated and delivered so this the request gets run it gets assigned to a randomly sampled and notes committee from all the nodes in the network how many nodes will be used is chosen is decided by the data requester so by the creator of the different contracts as soon as those nodes have discovered their eligibility for resolving that particular data request they go to the api's that are the data sources that are specified in the de request so for example in this case two different weather api's they aggregate the result coming from the from the APS and they secretly send these anonymized commitment which are which are published along a proof of their eligibility that is constructed using a verifiable random function and after there are enough commitments they they can reveal which is the value that they they got from the API sand and constructed and and came with through applying the radon functions that word if were specified in the Dare request itself so they reveal their values and at the point any node in the network can apply the consensus function defined in the data requests itself to tell which are the outliers which ones will not be rewarded and which ones voted with a consensus and this consensus don't need to be a mode or an average it can be filtering out those outliers that simply are twice away from the average as the standard deviation and then get me the average mean and and then convert that into an integer or a flood or whatever you want and then simply we get back the final data point into the sharing contract this is something that is already working on our test net that we released last January at our con what we presented what it was exactly this this use case of retrieving data from the weather data from two different a BIS and it's it works thanks to when addressed which is our first implementation of the protocol using the rest programming language and we also have this desktop client sheikha which is in one hand is the wallet for the token that is native to the to the Wynette blockchain and in the other hand is also an integrated development environment for the data requests for creating these radon scripts and our next steps is publishing the Wynette if your IAM bridge contracts that will allow a few in contracts to interact with the Wynette decentralized oracle network because nowadays you can only create this data request inside when it and have their results delivered inside Winnett but this is our next step to connect add to etherium and also the the library the solidity library that will abstract away radon from from aphelion contracts so that so that etherion contract developers can request information through and that without having to learn radon even if it's super cool but that's something that we we don't want them we don't want to force them to to learn one more language and we will be releasing maintenance for our network by the end of the of the year we're currently hiring solidity developers react developers res developers and any contribution on github is welcome and I I hope you enjoyed my presentation and if you have any questions you will need to request the microphone thank you [Applause] hello okay Thomas from Oracle is here so thank you for the presentation very interesting and I think you have explained quite a bit what kind of guarantees are given within DeWitt net Network can you maybe say something about the ways like the atrium context can understand the chittim a sea of data that it gets from the witness context like once the data makes it on the blockchain how could like any theorem smart contract verify that it's really coming from witness and the guarantees promised by witness are like preserved over time yeah thank you so had these words in our first implementation is that the Turing contracts make calls to deed wbi the Wynette bridge interface which is a very kind of dummy contract that held the rewards they is the payment that the etherion contracts make in ease or any year seat when a token and holds the rewards inside and then they win adults observe the the state of that contract so they see the calls that are going into the contract they replicate that calls in we're not they translate that into data requests until Radin and then when they do request is resolved what happens is that some of the nodes are randomly selected to report that data back to that wvi to the Wynette bridge interface to the contract inside aetherium and these what happens in in in there is that they present a proof that proofs that the final data belongs to the witness blockchain so they prove that that's the result that we saw the result for that particular data request and that that was anchored into the Wynette blockchain and the way that the assyrian contract verifies that is because it has all the block headers from there from the way net blockchain inside its state so it's it's a scheme kind of similar to BTC relay in which you can verify Bitcoin transactions from etherion so it's it kind of works you know in a similar way and finally what happens is that you as a if you're in contract developer will have a method in your contract that only can be called by the wbi so that's like your callback for further for the result and that's where the where the final data will will go to please please do sorry very quickly so I guess what this implies is that there will be a subsidized cost by someone on for maintaining this state on the blockchain and that's very interesting since your subtitle is like what the centralization really means which to me is an open question mark for the entire community and we don't know yet and the second question that I wanted to ask you and I didn't find addressed here is like what do you think is the cost of decentralization in the context of an Oracle yeah the the entire point of the third design goal which is parameterisation is exactly that we we envision an Oracle network as something that works in a very low level it's a very low level piece of infrastructure inside the stack so what that means is that we cannot we cannot foresee what are the use cases that will be built on contract and on smart contracts once they get connected to the Internet and to the outside world so the those whose cases will have multiple trade-offs regarding security redundancy latency a lot of criteria that we cannot we cannot predict so our point is that we need to make our design generic enough and parameter stable enough for each user to decide what are their trade-offs and what they need so that's why you you should be able to choose every particular parameter and by yourself the degree of decentralization of trust lessness and tamper resistant that you need for your counter for example if a contract is is to is supposed to ET secure a very big value it's it's desirable that the notes the Wynette nodes resolving that the request will need to put some kind of collateral for them to be more liable in case they try to tamper with the with the result but that's only a parameter maybe what you want to do is requesting the data through more more nodes or using more sources it's it's totally up to the their requesters to find what are the sensible thing to do for for their use case but that could be a nightmare at the end of the day so what we expect is for the community to find what are the sweet points and come with templates for things that kind of work for the 99% of the cases okay thank you very much [Applause]