The goal of this post is to give an overview of the potential oracle solutions to deal with the limitation @guy raised. We are going to use time as an example for our discussion.
We can’t reliably tell time (and balances) inside the enclave during contract execution as detailed in Issue #201. This creates problems for applications where time is required as a trigger for contract execution, such as voting, mixing(Salad) and dead-man’s switch. The short term solution to this problem is Oracles. There are two potential design patterns to leverage time oracles for secret contracts:
- Trusted off-chain oracles
- Multi-sig on-chain oracles
Note: the naming is slightly confusing because all oracles deal with off-chain data - bear with me pls
Trusted off-chain oracles
This is a simple concept - there’s one registered address that’s allowed to send block-height input to the secret contract. While auditing oracle behavior is easy, this creates a significant level of trust on the oracle and opens a possibility of misbehaving oracle at the expense of the system. There are no checks and balances for the trusted oracle, no on-chain aggregation or consensus of off-chain input. In addition a trusted oracle is not censorship resistant, which is an important design principle in Web3.
Multi-sig on-chain oracles
The idea of a multi-sig oracle is to create an oracle model that doesn’t require a central point of failure, is censorship resistant and can aggregate off-chain data on-chain (multi-sig consensus). This replaces a trusted operator with a network of N participants. Here are some properties for the multi-sig operator model:
- Open participation (anyone can choose to participate in the multi-sig oracle)
- Predetermined set of participants
- Crypto-economic incentives to honest behavior
Let take secret voting as an example. Voting contract that requires votes to be tallied after X blocks. The on-chain multi-sig oracle can provide time input to a voting contract, as well as any other contract like Salad, which has a time and quorum based trigger for the mix.
Multi-sig time oracle contract will accept deposits from network participants during time t. For sake of example, let’s assume minimum deposit amount is 100 SCRT and each vote costs 1 SCRT per multi-sig oracle participant. This process is open to any holder of SCRT who wants to serve the network. However at some point t+1, the multi-sig participant list must be finalized. The participant list can and should be updated periodically.
Secret voting contract will be able to query multi-sig time oracle contract during execution, which means that multi-sig time oracle can provide block height to determine whether the votes can be tallied or not.
From a crypto-economic perspective:
- participants with time input on which the multi-sig contracts forms consensus on gets rewarded
- participants with conflicting inputs get slashed.
One improvement area is to allow secret contracts to pay each other for running queries. This is a feedback we have given to CosmWasm team through the latest CosmWasm core contributor and our one and only @reuven !!!
For the sake for argument let’s assume we have a 2-3 multisig:
Alice, Bob and Charlie each deposit 100 SCRT to the multi-sig time oracle. The participants run a bot to provide block height. In exchange for providing time information, Alice, Bob and Charlie expect to receive a payment either generated by TX fees or set aside as a bounty by the contract owner (secret voting, salad etc.)
When the time input is required (secret voting contract tally function is called), participants provide the block-height to the multisig oracle contract. At this point there are number of possible outcomes:
- 3/3 agree on the same result, time is passed to the voting contract. Reward denominated in the contract is shared among Alice, Bob and Charlie. Note that this may not be the right time, but there would at least be consensus on-chain on the block height
- Bob agrees with Alice and Charlie doesn’t vote. ⅔ passes, reward is shared between Alice and Bob
- Bob agrees with Alice and Charlie disagrees. ⅔ passes, reward + Charlie’s deposit (1 SCRT) is shared among Alice and Bob
- Bob and Charlie doesn’t vote. We can’t provide time input to the voting contract and the contract halts. I don’t think this is very likely because either the contract owner or the participants in the voting have the incentive to see the contract run properly. However this is still a risk and threshold participation vs. incentives must be researched further.
Multi-sig operator model is significantly more complex than a trusted operator model. It’s a network within a network. However, it’s also censorship resistant and less vulnerable to manipulations. The mutli-sig oracle approach is also similar to how Maker and Compound use off-chain price information in determining their rates and prices. In Maker there are whitelisted oracles and an aggregation smart contract (instead of the multisig contract) that takes the average of the prices fed by whitelisted oracles.
Compound also uses a similar approach. (For more information on oracles). These two DeFi applications do not offer open participation. Maker and Compound alone account for approximately $600mn, which is a testament that oracles with some trust level are already playing a big role in the blockchain ecosystem.
I personally would like to see a multi-sig oracle contract and the tooling that makes participation easy as a building block in the Secret Network ecosystem!