Until cryptocurrency has gained significant traction, prices will be volatile and unpredictable. This hurts the ability for normal consumers to use crypto-assets as actual currencies. Plenty of speculators hold Bitcoin and Ether; very few use them to buy anything. A handful of projects aim to solve this problem by using smart contracts to automatically stabilize the price of a currency by buying or selling assets as demand ebbs and flows. A necessary component of any such system is a price feed that provides real-time trading data to smart contracts.
Some projects report that they will use a “schelling network” to relay price information from exchanges to their smart contracts. While these projects’ white papers generally don’t go into the specifics, the “schelling network” approach refers to an idea described by Vitalik Buterin in his 2014 post, Schellingcoin.
During an even-numbered block, all users can submit a hash of the ETH/USD price together with their Ethereum address
During the block after, users can submit the value whose hash they provided in the previous block.
Every user who submitted a correctly submitted value between the 25th and 75th percentile gains a reward of N tokens (which we’ll call “schells”)
The protocol does not include a specific mechanism for preventing sybil attacks; it is assumed that proof of work, proof of stake or some other similar solution will be used.
The economics of [the protocol] are not perfect, and if large collisions are possible then it may break down, but it is likely close to the best that we can do.
Vitalik’s last claim is likely incorrect. For security-critical oracle systems, a schelling network is not the best we can do, and if it is, then we have a real problem. While the protocol has the benefit of complete decentralization, it does not provide the security guarantees that an oracle system would realistically need. In any application where an attacker could make a substantial profit from corrupting the oracle data, a schelling oracle will fail.
The whole point of an oracle system is to provide reliable data to smart contracts. If such a system relies on the good behavior of anonymous participants, we can expect it to fail. As stated, the schelling protocol does not protect against Sybil attacks, where an attacker submits a large number of votes, from different addresses, to overwhelm the votes of honest voters. Vitalik suggests Sybil resistance could be added via a proof of work or proof of stake system. Unfortunately, Sybil resistance is not an easy piece to add to such a system. Since Vitalik’s post in 2014, no promising Sybil-resistant schelling network designs have been put forward.
Vitalik doesn’t say in his post how such an oracle system would fund reporters. Some have proposed requiring reporters to all stake some amount, and then taking the staked tokens from the reporters outside the middle 50% of the distribution to give it to the reporters inside that central distribution. This does provide some “skin in the game” for reporters, but alone will not incentivize reporters to participate. Additional money must paid out to reporters. Otherwise, the average utility reporters make is 0, and reporters are gambling in a zero-sum game.
Let’s run through a thought experiment. Let’s say we had a schelling oracle system that paid out $1,000 per day, in total, to schelling reporters that answered the question, “What was the average ETH/USD price on Binance on [today’s date]?” The payout would be split among reporters in the 25th — 75th percentile of the distribution, or split among all reporters who submitted the same answer if they made up more than 50% of total reporters.
If there were 10 reporters and they all submitted the same answers as each other, then they would each receive $100 per day. If there were 100, each would receive $10 per day.
How many reporters do we expect to participate if the system pays out $1,000 per day? Well, let’s say the cost of running a server which calls the exchange API & submits a price to the smart contract is approximately $5 / day. This would mean that the profit to be made from participating in the Oracle system would be (1000 / N) — 5, where N is the number of reporters. If N was 200, then an Oracle reporter would have a net profit of 0. Thus, there must be fewer than 200 reporters for a new schelling reporter to have an incentive to join the system.
An attacker can game this system at any time by simply creating more oracle reporters. Remember that these reporters do not have to be unique people — an attacker can make an arbitrary number of Ethereum addresses. This is a Sybil attack. The more reporters an attacker adds, the more honest schelling reporters will leave, as their profits decrease due to the payout being split among more actors. The attacker loses a slight amount of money with each additional schelling reporter they create, but less than it might seem, given the incentive for other reporters to leave the market as their profit margins fall. Thin or slightly negative margins are acceptable to the attacker, given they are profiting from altering the oracle data rather than profiting from the small reporter payout.
Even in schemes where staking is required, successful attackers do not lose their stake. An attacker can report oracle prices correctly until they have a majority of reporters, then all at once report an incorrect price. Because their price will be treated by the system as the “correct” one, honest participants will lose their stake because their submitted prices will not match.
Reputation systems have been proposed as ways to protect schelling oracles from Sybil attacks. Such systems do increase both the capital and time costs of attacks, but these protections are unlikely to be effective in the long run. An attacker can still make an arbitrary number of fake reporters and run them honestly until their reputation accrues enough to control the majority of votes.
The problems with schelling oracle systems generalize to larger problems with token voting. Pseudo-anonymous voting systems are extremely vulnerable to vote buying attacks. For tokens with high liquidity, it becomes easy for an attacker to buy up a large percentage of a token, swing a vote in their favor, then quickly sell off their tokens. Voting-based governance systems are unlikely to be effective unless token holders have a long term incentive to hold on to their tokens.
Schelling oracles should be abandoned in favor of better systems. It’s better to have a small group of verified & trusted reporters than a trivially gamable schelling system. This should be obvious, but blockchain projects are vulnerable to fetishizing decentralized solutions even when they are less secure. For many applications, decentralized oracles don’t actually provide greater decentralization, because the oracle reporters source data from the same centralized entities. In cases where smart contracts rely on crypto exchange trading data, exchanges are the trusted third parties, regardless of the oracle architecture. It makes far more sense to ask exchanges to sign their data so that smart contracts can cryptographically verify the data’s authenticity. If this can be implemented, the security of the oracle system is no longer important, because the intermediaries relaying data cannot submit false data without being detected. The blockchain community would benefit from dropping the pretense of designing completely decentralized systems and focus on securing the weak points in the semi-centralized systems that are currently in place.