Since that conference there has been a lot of more development in the space of smart contracts, especially if you look at Ethereum. However, one of the biggest obstacles limiting what a smart contract can do has always been the information it can use. To put it simply, smart contacts running on blockchains could only access data from within that blockchain, not from the Internet as a whole. This is to make sure those contracts are executed in a consistent manner at every machine - you couldn't for example have a contract checking the current Foreign Exchange rates online, since two different machines asking for the same information could get different data. Moreover, there is a question of security and preventing DDOS attacks - a script asking for a web page 1000 times executed at 1000 locations would result in a million page requests.
To address these issues, the concept of "smart oracles" came about. A smart oracle is a piece of software running on a machine that has access to both the blockchain data, as well as the real world data, and can interact freely between the two. You might have, for example, SatoshiDice checking the blockchain for transaction bets and evaluating them, or some bot that checks the current Bitcoin exchange rate and embeds it into the Bitcoin blockchain.
One of the projects offering a distributed platform for running smart oracles that inspired today's blog post is Codius. It's a project that grew out of the initial idea for smart contracts on the Ripple platform into what it is today. I would like to present to you some ideas of what could be built using that platform. But first, some assumptions.
Smart oracle assumptions
A useful smart oracle platform needs to offer the following functions:
- Make the code to be run verifiable and open - anyone interacting with the code needs to be able to make sure the proper code is running and it hasn't been tampered with
- Interact with both the Internet and the blockchains - this is needed to leverage the power of smart oracles over smart contracts
- The oracle needs to be able to keep some private data - whether it's private keys for signing transactions or other proprietary data, the oracles are more useful when they can store some data privately. Of course, the private data can be made public through proper function handlers
- In many cases, it is beneficial for multiple smart oracles to be run by different parties to ensure there is no collusion. Because of this, the platform running the oracles needs to be open source and not have proprietary code
Given those features, we can build some interesting projects...
Factom in a script
Since Factom is essentially just embedding information to be stored in the blockchain, it would be easy to setup some smart oracles where you can pay some money and have certain pieces of information embedded into the blockchain - whether it's hashes of proof of existence, or actual data like the current exchange rates, it doesn't matter much. Having more than one oracle communicating on what data to embed can also be useful to make sure no single party is manipulating the data.
Coin to Crypto 2.0 gateways
In the Crypto 2.0 space, there is a need for efficient, cheap and secure gateways between the various coins and the 2.0 system. Most of those gateways are currently run by centralized parties, but with smart oracles you could easily reinvent that model and run it on a few smart oracles.
Smart oracles could serve as an interesting platform for betting and gambling. Users would be able to register and gamble with the oracles against one another, real-world events, or against the house, which can also be run by the oracles in a fashion similar to JustDice.
Since the oracles would be able to store private data, anyone would be able to send messages to be stored on multiple oracles that can later be retrieved by the intended recipient. This communication could be end-to-end encrypted, and since it wouldn't reside on a single server, it could be more robust than a lot of networks.
A lot of exchanges (centralized or distributed) benefit from initial market liquidity bootstrapping that can be achieved through the use of bots. Those bots are usually tasked on copying the market from an existing exchange onto the new one and locking in any trades that might take place. Moreover, there is even more benefit if there is competition in this space - having multiple parties competing with one another to provide the best rates stimulate activity, as well as make the market more competitive. If an exchange that needed liquidity would provide smart oracle code for anyone to easily deploy and run on Codius with tweakable parameters, they could quickly see a lot of amateur market makers provide them with a competitive market on their platform. Similarly, the same could be done on a 2.0 platform with a decentralized exchange like Ripple.
In this example, the smart oracles are mainly used as cheap, 24/7 hosting platforms.
Timed releases of secret information
Through the use of encryption and Shamir's Secret Sharing, smart oracles could be programmed to release the decryption keys for various files or documents at a given point in the future. Even if some of them went down or did not release the keys, the secrets could still be revealed if the minimum threshold was reached. This could be used for example by provably fair gambling platforms releasing their secret seeds at a predictable time in the future.
There is a lot of need for various economic contracts out there, and a lot of them rely on some external data, such as the current exchange rate, being fed in. Smart oracles could not only facilitate the proper data being verifiably embedded into the blockchain, but also execute the smart contracts as desired in an objective fashion.
And many more...
There are many other ways one can use smart oracles, ranging from simple servers running scripts on one end, through embedding data into the blockchain, down to leveraging both the cryptocurrencies and data from the real world. The main advantage of using oracles over traditional servers is that a lot more of them can be deployed at the same time, and the same script can be easily executed by multiple parties, therefore minimizing the risk of malicious behavior.