A better oracle design?
I've come up with what I think is a novel oracle design. It may give better game-theoretic guarantees than existing designs. I'm going to explain it in the context of a binary oracle where there are two options, such as 'who won the US presidential election in 2024.' Generalizing it to non-binary oracles, such as price fees, is left as an exercise to the reader :)
The main problem with blockchain oracles is that oracle providers may maliciously provide incorrect data. This is concerning because billions of dollars of capital could be lost if an oracle does provide incorrect data.
A naive solution to this problem is to simply slash oracle nodes that provide incorrect data. The problem with this approach is defining which data is correct and which is incorrect. You can really only slash nodes for not giving the consensus result.
For example, imagine that an oracle is supposed to return the answer to "Who won the US presidential election in 2020, Joe Biden or Donald Trump?" Now suppose that there are 9 oracle nodes, 7 of them responded 'Joe Biden,' and 2 of them responded 'Donald Trump.' In this case, we can slash the two nodes which gave an incorrect response. The problem arises when the majority of nodes give a spurious response. In this case, we would slash the nodes who provided a correct response. For example, This is a major problem because it incentivizes oracles to provide what they believe the consensus response will be. If I'm an oracle node and I see that a majority of nodes have already voted that Donald won, I will probably go along with them even if it is false. Malicious individuals or groups can game this system by submitting an incorrect response early. That way, the other nodes will be incentivized to follow-on with more incorrect responses.
This oracle may be useful for constructing prediction markets
If we want to adopt a slashing-based approach, we must it very hard for nodes to reveal who will they vote for before all nodes have voted. If nodes don't know what other nodes vote for, the Schelling point is the truth.
My solution to this is a hash-based commit-reveal scheme. During the commit phase, oracle nodes determine what the correct response is and select a random nonce. They then hash these together, and submit this hash to the chain. In pseudo-code, this looks like the following:
let nonce = random_number()
let who_won = get_who_won()
let commit = hash([nonce, who_won])
submit_to_chain(commit)
During the commit phase, any node can be slashed if their nonce is revealed. Slashed stake is redistributed to the other nodes. Once all nodes have submitted commits, the oracle enters a reveal phase. During the reveal phase, nodes have time t to reveal the nonces they used to compute the commits, which in turn reveals their vote (Joe Biden in this case).
It is very hard for nodes to reveal what they will vote for before all nodes have committed to a response. If a committed node proves to an uncommitted node that they have committed to a certain response by revealing their nonce, the uncommitted node can submit this nonce to the chain to receive their share of slashing the committed node. On the other hand, if the committed node uses a 'just trust me bro' style of proof, the uncommitted node runs the risk that the committed node is trying to trick them into submitting a non-consensus vote so that the committed node can collect their share of slashing the uncommitted node. So either way, nodes can't collude easily.
Further, nodes can't use tit-for-tat because a node must 'bet the farm' in a collusion-attempt. This makes it a finite game, where tit-for-tat is not the equillibirium.
So yeah, I think this is a pretty cool design. I'm not sure what kind of feeds this would be good or bad for. I'm pretty sure that the commits and reveals would need to be in separate blocks, which wouldn't allow one-update-per-slot oracles like Pyth provides on Solana. I'm not even sure how this would exactly work for prices. Maybe you slash nodes that are more than 5% away from the consensus median? But this does seem like it would work well for binary oracles that aren't super-real-time, like presidential election results.
We may not need this if Switchboard's TEE-centric approach works.