Oracles
DeFi (Decentralized Finance) on a blockchain hits one basic problem: everyone has to be able to verify the entire historical chain, even 20 years from now. What this means is that any decision on a transaction has to be also stored on the blockchain.
Any smart contract that decides who gets paid based on the weather, on sports events or on things like the price of gold are thus all basically imposible. In Bitcoin Cash we solved this by adding some opcodes which enable a so called 'Oracle'. From the Latin word for truth-sayer.
We can take statements from an Oracle and use select statements on-chain to unlock and move coin. A small innovation that will prove massively useful.
This is the technical solution, the business solution which makes someone actually build and run an Oracle is more difficult.
Data is a business.
I worked for several years in a company that ships a so called "Professional Terminal". It shows real time data on a very large list of financial instruments. From gold and fiat prices to stocks and bonds. Processing this data, and selling it under a subscription model, is essentially the heart of the business of such growing businesses. And that business is good.
The ideal situation is that existing companies that already have real time feeds of data would add an Oracle service. But they won't do that for free, why would they?
A medium sized Terminal gives you instant access to over 80 exchanges, 50.000 funds and ETFs and all major listed companies listed worldwide. How useful would it be if all those feeds could be used to tie any type of smart contract to?
Oracle as a business model.
When we refer to smart contracts using Oracle data it is almost implied we look at what happens at AnyHedge and the Bitcoin Cash-bull people. The teams there created a smart contract which can only close using the current price of an asset. Second the contract will only pay out correctly, at the end of its term, using another sample of the real time price of that same asset.
We already stated that data is business and that access is paid, so the question we now have to ask is how an Oracle could be designed that ties the two together. Any illusion of the data being free has to be dropped, that will never be the case. It costs money to gather that data, its only fair to pay a small fee to access it and entice the operator to maintain the service.
Data-request types
The main point of an Oracle is to provide data. In fact, we only need the data once or twice. Certainly when we settle the contract, and probably also when we create the contract.
At the same time, most people would not mind having access to the data during the contract duration in order to see what is happening and predict what value they might get out of it after contract settlement. Lots of people love looking at graphs in anticipation of the final date.
This implies we can have to types of access to the Oracle data, one that is signed and one that is just plain data.
What I propose is that we include the Oracle in the creation of the contract. It would work like this;
The two parties that come to a contract find an Oracle to be their trusted source of truth for the settlement time. The two parties create a transaction like normal for their hedge. They also include a fee in that transaction to be paid to the Oracle upon settlement.
Upon submitting this signed transaction (and p2sh script or enough metadata) to the Oracle, they get a token from the Oracle, as well as the current price of the instrument.
The Oracle at this point holds a transaction that it can broadcast in order to get paid. But it holds on to the transaction.
The two parties that enter the contract update the transaction to use the current price they got from the Oracle. This final transaction is also sent to the Oracle who will broadcast it to the network. (Though anyone can broadcast it).
Depending on which fee is being paid to the Oracle, the users may use the token as a subscription to the real time data of their instrument during the time the contract runs. That is, afterall, the core businss of such Oracle owners.
When the contract time has expired 'someone' will use the token in order to settle the transaction. What this means is that they call an API endpoint from the Oracle which returns the price at the time the contract closed, all based on the token we got at creation.
Broadcasting a transaction with this signed statement from the Oracle will cause the payout of funds according to the contract, settling the contract.
Discussion
The above suggests we only pay the Oracle at the settlement time of the contract. This ensures that the Oracle keeps its promise to provide us with data. But as long as we trust the Oracle anyway maybe this is overkill and we can just pay the Oracle at the first broadcast of the defi-contract.
The contracts from GP do not allow closing pre-maturely by one side. Which makes sense since you can't do that trustlessly. The main problem being that one side could just cherry-pick the exchange rate and pick the most optimistic for him, defrauding the other side. Afterall, if you can close it at any time, you can close it with an exchange rate from yesterday or the day before.
The less scammy way of closing it is to ensure that this is a real-time effort. Today I realize I need to settle the contract, then I need to use the current exchange rate.
A trusted Oracle could provide that by adding the token into the signature area and trusting the Oracle to only give out exactly one signed reading with that token. Meaning that only once will the Oracle produce the data that can be used to settle the contract. Ensuring the real-time state of the contract.
Conclusion
Oracles should have economies of scale going for it. Otherwise it becomes too tempting for them to cheat for friends. The more transactions they process per month, the better the security is for the individual.
The above interaction highlights a way to automate payment to Oracles while honouring their core business model, which also makes it less useful for them to cheat. They earn well from being honest, afterall.
I think it makes sense to try this setup and when we have some design specs we should try and contact specialized companies in that business to integrate with Bitcoin Cash.
I'm glad to see other people thinking about this problem in within our ecosystem and staying with low-complexity solutions. However, there are a few things in the model you describe here that I think we can do better, and which we at GP have had to take into account:
1) While paying an oracle only at the end of a contract is good in theory, locking the funds inside the contract for the duration results in the oracle getting strong expectations that they will get paid regardless of how the contract settles, meaning there is no different for the oracle if they settle with an honest of a fraudulent transaction with regards to the individual contract.
2) Informing an oracle about what contracts they ultimately have control of the outcome for, sets up an incentive for the oracle to provide fraud-as-a-service.
This issue becomes particularly important if the system ever ends up reducing volume and the prospect of future income goes down, as the incentives to do a hail-mary and take a fat bribe and then exit steadily increases with time.
At GP, we decided that one of the foundational principles is that the oracle must be blind to active contracts, such that it cannot know what contracts it can influence and are therefor unable to sell system-wide fraud-as-a-service.
They can, unfortunately, still defraud users in two different ways:
1) They can themselves enter into contracts, such that they know and control the outcome of their own contracts.
2) They can coordinate with 3rd parties who enter into contract and collect a bribe in exchange for fraudulent oracle messages that the 3rd parties settle the contracts with.
In both of these cases, they should expect to lose all future honest income, but they should also expect that the tokens the get as payment will lose value due to loss of faith by the impacted users.
For the time being, until a better oracle setup becomes available, or contracts start using multiple oracles, I would advice caution and make smaller contracts at first, and grow contract sizes with the oracle volume to stay under the line where incentives skew in the bad direction.