Decentralized trustless oracles (DTO) by piggybacking on timestamp consensus rules
Trustless oracles are quite a difficult problem, at least it was until I came up with a simple method that implements them.
Some people have the position that its ok to trust the oracle: https://medium.com/@antsankov/the-oracle-problem-isnt-a-problem-and-why-smart-contracts-makes-insurance-better-for-everyone-8c979f09851c
But is is clear that left without some decentralized trustless mechanism, oracles will need to be based on votes, weighted votes, aggregated data, or some complex system involving rewards/punishments/reputation to provide incentives for proper behavior.
there are many other articles about oracles and either it is just assumed that trusting the oracle is ok, or that trusting the voters to vote properly is ok.
I used to believe this too, as it seems there is no real alternative. Then I had an educational few days of intense discussion with https://twitter.com/zack_bitcoin
I realized that whatever incentive system you setup onchain, there is no way to stop offchain sidebets. And with offchain sidebets able to dwarf the economic value of all onchain value… Well, all rational game theory actions change dramatically when the onchain incentives are small compared to the offchain sidebets. Is this really a realistic thing we have to worry about? Probably not, until it is too late.
And that is the problem. While it seems preposterous at first that offchain bets would be made that dwarf onchain value, the fact remains that it can and if it can and there is no way to prevent it, it just seems a matter of time before an attacker will do this. Certainly not until things mature more and there is sufficient value to make it worth doing. By then it would be too late, especially if the industry has adopted vulnerable aggregated oracles.
Dont get me wrong, I also implemented the normal data aggregation oracles as that is the common sense things to do, but it does require having trusted data providers, so it is antithetical to the blockchain. To build systems on oracles that dont have to worry about the offchain betting attack appearing as it scales up in value dependent on it, we need a DTO.
OK, but how to make such a thing? By definition the oracle is putting offchain data onchain, so there is no way to verify the data directly. dont we have to trust some data provider, or some processed result that originates with the raw data being provided by semi-trusted data sources?
That was was I thought until my encounter with zack spurred me onto find a solution. Not being so deep into oracle tech, maybe it gave me an advantage over those who have spent years deep in all the research. I couldnt help but have a different approach as I only knew what I had done with the basic oracles CC, which created a data market and relied on a positive reinforcement of datafees to make the data at least semi-decent. It certainly wasnt any DTO. Layers of data aggregation could certainly be done, even stake weighted voting, but ultimately it would be building on a weak foundation. Still there is nothing wrong with aggregated data oracles for many use cases and if it is sufficient, then use it!
Now I have been writing a fair amount of blockchain code in the last 5 and a half years, including my own bitcoin protocol node written in scratch in C called iguana. The legacy devs made me abandon it as I wasnt about to add support for the abomination that is segwit into my iguana code, and if iguana wasnt going to work with bitcoin, then its main usecase of fast syncing the BTC chain (as fast as 10 minutes in 2016) was not really needed.
However, I sure learned a lot about the nitty gritty of blockchain protocols. Add to that the years of being the lead core dev of komodo and you cant help but learn a thing or two. One of these things I learned was how timestamps in a block is based on the local clock of the miner and combined with the variable time to find a block, it can be quite a bit different than what the “correct” time is. In bitcoin there is a +2 to ~-4 hour leeway on the timestamp, with komodo is is +1 minute to ~-8 minutes leeway.
What this means is that if a block comes in that is not reasonable (within the allowed tolerance) it is simply rejected as invalid. Even though if it was submitted at a different time it might be valid. This metastable behavior could end up with a node going on a fork, but with the clocks reasonably in sync, only the nodes whose system clock is out of sync would have problems with syncing the blockchain. If your system was right on the borderline, maybe you reject a block, but when you fix your system clock it allows your node to stay in sync.
In a very real sense, all blockchains are a DTO for timestamps!
Once I had this flash of insight, it wasnt long before I had a proof of concept using various price feeds. you can see a primitive set of charts for the prices at http://159.69.45.70:8050
I guess I should describe a bit more details.
The timestamp is a value that can be locally validated as all nodes need to have a system clock. There is no need to trust any other node that the timestamp in the block is reasonable, as each node can validate it directly. Just like each node can validate all transactions are valid. If there is no trust needed, then it is trustless and with all nodes doing it becomes a fully decentralized and trustless process.
Notice there is nothing magical about the timestamp. It just happens to be a value that all computers can come to reasonably close approximation to. I totally ignore timezones, daylight savings times, leap days, seconds, etc. as the timestamp we are talking about in blockchains are the UTC timestamp.
But why not change “timestamp” to “data accessible to all nodes”? in this case it is immediately apparent that if indeed there is data accessible to all nodes, that it can be treated just like the timestamp. There happen to be many online sources with api for prices, which is accessible to all nodes, ie. “data accessible to all nodes”!
And that is how the first decentralized trustless oracles for pricefeeds that I know of was created. Maybe there are others, but I am not aware of them. I made a CC (custom consensus) blockchain where similar to requiring reasonable timestamps, reasonable prices are needed. If not, it is simply rejected by all nodes. Since that is the case there is no need for any complex rewards/punishment/reputation system and since all nodes are validating against local data, it achieves the DTO status.
As with anything there are edge cases, like nodes that are eclipse attacked into seeing a false chain, but as long as nodes make sure they are in sync with the main chain before making monetary bets and keep their node running, then there is little danger to worry about. Regardless of the size of the offchain bets, the DTO will continue posting reasonable prices, block after block
