Zen’s Oracle Solution

Our solution lets oracles commit to a practically unlimited amount of data in advance, then reveal only those parts they are paid for.

Oracle commitment process

Create a commitment:

The oracle takes each piece of data, combines it with a nonce (some randomly generated bytes, different for each piece), then creates a Merkle tree from the result. Each leaf of the tree comprises a record containing the nonce and a commercially valuable datum. The hashes of leafs are repeatedly concatenated and hashed again until a single hash is created, the Merkle root of the tree. Commit to Merkle root on Zen:

After generating the root, the oracle creates a transaction which puts the Merkle root in the blockchain. Repeat

The oracle creates new commitments as often as required, recording new Merkle roots in the Zen blockchain. A simple contract can save space here, combining prior commitments with new ones and taking the hash of the result.

Since the price to commit to one piece of data is the same as that to commit to a million pieces of data, the oracle does not have to know how much data will actually be purchased. In fact, the scheme works better when the amount committed is considerably greater than the amount purchased.

How users use Oracles:

Step A: Agreement on a set of oracles.

Prior to entering a contract, users agree on a set of oracles which are trusted to provide the contract with an input. Our website lists some example oracles. The contract is configured to accept a quorum of these oracles as an arbiter.

Step B: User gets price proof from oracle

If a dispute arises, one party pays the oracles for a proof of what data they committed to. Each proof has the form of a merkle audit proof.

Step C: Submit proof to contract

The aggrieved party invokes the contract, providing the proofs. The contract checks the blockchain for the associated Merkle roots, validates the proofs and acts accordingly.

Oracle Profit

When a user wants to exercise a contract using some oracle data, the contract must validate a Merkle audit proof for that data. Creating this proof is not possible without the cooperation of the oracle, who is the only one to know all the nonces in the Merkle tree. The user can send a conditional payment, which can only be spent by revealing the desired proof. This gives two-sided protection: the user only spends money if the proof is revealed, and the oracle only puts data on the blockchain when paid.

Benefits

Simplicity & low barrier to entry: This mechanism allows anyone to be an oracle. Fetching the data, committing, receiving payment, and sending the proof can all be handled via wallet software, and does not require complex technology or game theory to work.

This mechanism allows anyone to be an oracle. Fetching the data, committing, receiving payment, and sending the proof can all be handled via wallet software, and does not require complex technology or game theory to work. Privacy: Oracles are not aware that contracts depend on them. Users only request proofs after the contract has been signed and a dispute has arisen.

Oracles are not aware that contracts depend on them. Users only request proofs after the contract has been signed and a dispute has arisen. Scalability: The oracle provides commitments to a lot of data, while only a small amount is revealed. This results in high scalability, in which each piece of data added to the blockchain has a definite financial function and is adequately paid for.

The oracle provides commitments to a lot of data, while only a small amount is revealed. This results in high scalability, in which each piece of data added to the blockchain has a definite financial function and is adequately paid for. Profitability: In the case that each datum is only used a small number of times, oracle operators can turn a profit, as the existence of “parasite contracts” is not an issue. Oracles may charge at least once per piece of data, as each piece has its own secret proof. Even if several oracles commit to the same data, they will use different nonces and so create different proofs.

Furthermore, from a simple cash-flow perspective, oracles pay a small fee to make a commitment, while users pay both for the computation and for the data to be recorded on-chain.

Security

Oracles have a motive for lying when this gives them more expected profit than the expected future profit they can earn while remaining honest. This can be countered either by making oracles more profitable, or by making dishonesty less profitable.

Trusted oracles carry a reputation premium: their credibility makes their judgments more valuable. The essence of the problem with “parasite contracts” is that this prevents trusted oracles from realizing the value of their “reputation premium”. That is to say, honest oracles can’t reliably turn a profit — which gives them a big incentive to make money from lying. Our model allows oracles to realize their “reputation premium”.

The second thing we should do is reduce the expected profit of stealing.

An oracle steals by reporting an incorrect result. The primary theft strategy is to observe those contracts which rely on one’s data, take the “contrarian position”, and lie about the result. By enhancing contract privacy, we reduce the expected profit of theft, as the oracle does not know what to lie about.

Nevertheless, an oracle operator could secretly take a position depending on its data, and then lie. For example, the operator could buy cheap, out-of-the-money call options on a stock, then falsely report its price to have risen.

Therefore, we envision routine use of multiple oracles, whereby a set of oracles are chosen to provide data. Normally one oracle is enough to resolve the contract, but if the oracle’s result is disputed then a quorum of oracles are required. In this case, the bad oracle would lose all reputation without influencing the final result.

To surmount this barrier would require a coalition of oracles to exit scam simultaneously. With a wide enough selection of oracles, the risk of this is quite low. Besides, this requires coordination on a risky enterprise in which the proceeds have to be split.

Conclusion

We have a working solution to the oracle problem. Oracles are compensated for creating data and for being honest, the blockchain is kept uncluttered, and the system scales well with increased usage. The mechanism is simple to understand and can used by contract participants and oracle operators of average technical skill. Real oracles make it possible to go beyond the monetary function and use decentralized platforms for financial technology in general.