Steem recently announced the upcoming launch of Smart Media Tokens that will enable anyone to create their own version of Steem currency with built-in economics and integration with the Steem blockchain. Last week 
Oracles are generally considered to be entities that provide real-world data to a blockchain so that a smart contract can make decisions based on that data. There are various considerations to be made depending on the type of data one wants. Some data depends on a single centralized api, some is hard to access, some isn’t precise. This makes it hard for decentralized nodes to reach consensus about the data. But there is another type of oracle — the computational, or Smart Oracle. These oracles take blockchain data as the input, perform some computation, and update the state of the blockchain. Since the oracle’s computations can be deterministically derived from the parent chain, they are easy to verify and have fewer trust issues.
Oracles that only use blockchain data as inputs are very similar to smart contracts. The big difference is that instead of requiring the whole network to perform complex computations on-chain, the work is done by a small set of oracle nodes. This post by Vitalik Buterin is a great overview of this concept.
Generally, the main drawback of oracles is the low level of decentralisation. In the case of Smart oracles this issue is mitigated by the fact that all inputs are well-determined and anyone can verify whether their computations are done correctly. There are several mechanisms for determining consensus among oracles and challenging and verifying computations. One can force oracles to make a deposit and penalise those that don’t conform to the majority — SchellingCoin. Another approach is to utilize a mechanism that challenges oracle’s computation and verifies them on the main chain — TrueBit.
With Steem we already have a method for letting a small set of elected individuals to secure a trustless decentralized network — DPOS. We can extend this idea to Oracles and elect a certain set of public individuals to run and secure a set of oracles for any given SMT.
When we add the DPOS consensus to smart oracles what we get is decentralized smart contracts. The SMT creator can publish the source-code for a full-node DPOS ‘oracle miner’ that anyone can campaign to compete for a witness position. The smart contract can take the form of a plugin to the main node code (Potentially one could even allow for the smart contracts to be written in different languages as long as the code can be executed by the oracle node). These SMT oracles can be thought of as mini-steem nodes. At each block (or a set time interval), they read the state of the main chain, and update the SMT-specific state. Each state update is then hashed into a Merkle Tree so that anyone can easily check the root hash against their own version in order to verify the computation.
DPOS smart oracles will thus facilitate secure trustless smart-contracts for any given SMT, just like DPOS witness facilitate the security of the main Steem blockchain. In fact you could even extract all of Steemit’s app business logic into a Steemit SMT. This would allow one to keep a separate code base for the main chain, and all the apps built on top of it.
The main difference between the oracle witness and blockchain witness is that oracles don’t need to determine the order of transactions — that work is left to the main chain. All the main trust assumptions about DPOS still apply to oracles.
Suppose we want to implement an SMT token to support a social network that uses a complex algorithm that computes a reputation score for each user (like Relevant). For example, Eigen Trust++ can give us very reliable reputation scores resistant to fraud and Sybil attacks, but it is too costly to compute on the main chain. We want a decentralized way to compute this reputation score and use it to rank content and determine reward distributions.
We specify one smart oracle contract that will periodically compute the reputation score for each user on our platform based on the blockchain history up to a given block. We specify a second smart oracle contract that will compute the reward distribution for each new block based on the combination of user’s SP and Reputation. We can then use SMT (or SP) vests (and potentially even users reputations!) to elect witnesses to run these Oracles.
Once the oracles are running, they will continually compute and publish user reputation scores. Anyone can easily audit them by running the computations themselves and checking the results. At each block the oracles will also compute the reward distribution for that block and these can also be audited. The main chain will deposit all total rewards for that block into an account controlled by the oracles. Once M out of N oracles agree on the outcome of the reward distribution, the funds get distributed to the users.
If any of the oracles are found to perform fraudulent or inaccurate computations, they can be easily exposed and voted out of their position.
Additionally, deposit requirements and on-chain verification can also be considered, although it might be technically challenging to implement on-chain verification for a general case. These additional security measures could be implemented using a smart oracles themselves. Eventually we can see a hierarchy of protocols forming, each enforced by their own set of oracles and providing infrastructure for higher-level apps.
Smart contracts on Steem! Need I say more? Not only that, these smart contracts can be computationally complex and will cost practically nothing to execute! This opens up a myriad of use cases that are either impossible or impractical to accomplish using other blockchains, creating opportunities to experiment with a wide array of economic incentives and currency distribution dynamics. Smart oracles will also provide the necessary foundation to build an ecosystem of protocols that will facilitate a rich ecosystem of apps.
