An escalating amount of suggested implementations on Ethereum hinges on some form of incentivized, multi-party data supply – whether for voting, random number gathering, or various scenarios where acquiring information from numerous participants to enhance decentralization is greatly advantageous, yet simultaneously presents a notable risk of collusion. A RANDAO can undoubtedly offer random numbers with significantly greater cryptoeconomic security than basic block hashes – and certainly superior to deterministic methods with publicly accessible seeds, but it is not utterly immune to collusion: if all participants in a RANDAO conspire together, they can manipulate the outcome to whatever they desire. A much more contentious instance is the prediction market Augur, in which decentralized event reporting depends on a highly sophisticated version of a Schelling scheme, where everyone casts their vote on the outcome and those in the majority receive rewards. The theory posits that if you believe everyone else will act honestly, your motivation is also to act honestly in order to be among the majority, thus honesty becomes a stable equilibrium; the issue arises, however, that if over 50% of the participants conspire, the system collapses.
The existence of an independent token for Augur serves as a partial safeguard against this issue: should voters engage in collusion, the value of Augur’s token is expected to plummet towards zero as the system starts being regarded as ineffective and untrustworthy, resulting in substantial losses for the colluders. Nevertheless, this is by no means a comprehensive protection. Paul Sztorc’s Truthcoin (as well as Augur) incorporates an additional safeguard that is quite economically astute. The fundamental mechanism is straightforward: rather than granting a fixed sum to everyone in the majority, the rewarded amount is contingent on the degree of dissent among the final votes. The greater the dissent, the more majority voters receive, while minority voters face an equally substantial decrease in their security deposit.
The objective is clear: if you receive a message from an individual saying “hey, I’m initiating a collusion; even though the true answer is A, let’s all vote B”, in a simpler system, you might feel compelled to follow suit. However, in Sztorc’s layout, you may deduce that this person is actually voting A, attempting to persuade just a small percentage of participants to vote B, in order to siphon off some of their funds. This establishes a distrust, complicating collusions. However, a challenge remains: due to the exceptional nature of blockchains as tools for cryptographically secure agreements and coordination, it’s incredibly difficult to make collusions absolutely impossible provably.
To illustrate, consider the most basic scheme for reporting votes in Augur: there is a timeframe during which all can submit a transaction with their vote, and at the conclusion, the algorithm determines the result. However, this method is fundamentally flawed: it incentivizes participants to delay as long as feasible to observe the responses of others before casting their own vote. Taking this to its logical conclusion, we would witness everyone voting in the final block, effectively allowing the miner of that block to control everything. A method where the conclusion arrives randomly (e.g., the first block that surpasses 100 times the usual difficulty threshold) somewhat alleviates this issue, yet still allocates significant power to individual miners.
The conventional response from cryptographers to this dilemma is the hash-commit-reveal scheme: each participant P[i] establishes their response R[i], and there is a duration where all must submit h(R[i]), wherein h can be any designated hash function (e.g., SHA3). Afterward, all must submit R[i], and the values are validated against the previously submitted hashes. For two-player rock-paper-scissors, or any other zero-sum game, this functions excellently. For Augur, however, it still allows for the potential of credible collusion: participants can voluntarily reveal R[i] beforehand, and others can verify that this indeed corresponds to the hash values they submitted to the blockchain. Allowing participants to alter their hashes before the hash submission period concludes does little; users can always lock a significant amount of funds in a specially crafted contract that only releases it if no one provides a Merkle tree proof to the contract, culminating with a previous blockhash, demonstrating that the vote was altered, thereby committing not to change their vote.
A New Solution?
Nonetheless, there exists another approach to addressing this challenge, one that has not yet been sufficiently investigated. The proposition is this: rather than making pre-revelation for collusion purposes burdensome within the primary game itself, we introduce a parallel game (albeit a mandatory one, backed by the security deposits of oracle participants) wherein anyone who pre-reveals any information regarding their vote to other parties exposes themselves to the risk of being (probabilistically) betrayed, without any means to prove that it was that specific individual who betrayed them.
The game, in its fundamental form, operates as follows. Imagine there is a decentralized random number generation process where participants must all flip a coin and provide either 0 or 1 as inputs. Now, suppose we aim to discourage collusion. Our solution is straightforward: we permit anyone to place a bet against any participant in the system (note the use of “anyone” and “any participant”; non-players can join as long as they provide the security deposit), essentially asserting “I am confident that this participant will vote X with over 1/2 probability”, where X can be 0 or 1. The conditions of the bet are simply that if the target provides X as their input, then N coins are transferred from them to the bettor, and if the target submits the alternative value, then N coins are transferred from the bettor to the target. Bets can be made during an intermediate phase between commitment and revelation.
From a probabilistic standpoint, any sharing of information with another party is now potentially extremely costly; even if you persuade someone else that you will vote 1 with 51% likelihood, they can still probabilistically claim coins from you, and they will prevail in the long run as this kind of scheme is replicated. It is significant to note that the other party can bet anonymously, allowing them to always feign that they were just an onlooker.
gambler placing the wagers, not them. To improve the strategy even more, we can specify that you need to wager against N different competitors simultaneously, and these players must be pseudo-randomly chosen from a base; if you aim to target a specific participant, you can achieve this by experimenting with various seeds until you pinpoint your intended target along with a few others, ensuring there will always be some degree of plausible deniability. Another potential enhancement, albeit one that incurs costs, is to mandate that participants only record their bets during the phase between commitment and disclosure, revealing and executing the wagers long after multiple rounds of the game have transpired (we assume that a significant time frame before security deposits can be withdrawn is necessary for this to function).
Now, how can we translate this into the oracle scenario? Reconsider the straightforward binary situation: users indicate either A or B, and some proportion P, undetermined prior to the conclusion of the process, will report A while the remaining 1-P will report B. Here, we adjust the scheme somewhat: the wagers now state “I am certain that this individual will vote X with a higher probability than P”. Note that the phrasing of the wager should not imply knowledge of P; rather, it suggests an opinion that, regardless of the probability that a random user will vote X being, the specific user that the bettor is aiming at will vote X with a greater likelihood than that. The conditions of the bet, processed post-voting phase, stipulate that if the target votes X, then N * (1 – P) coins are transferred from the target to the bettor; otherwise, N * P coins are transferred from the bettor to the target.
It is important to note, in the typical scenario, that profit here is even more assured than in the binary RANDAO example mentioned earlier: most of the time, if A holds true, everyone votes A, making the wagers low-risk profit opportunities, even when complex zero-knowledge-proof protocols are utilized to provide only probabilistic assurance that they will vote for a specific value.
A brief technical note: if there are merely two options, then why can’t you deduce R[i] from h(R[i]) just by testing both alternatives? The explanation is that users are indeed publishing h(R[i], n) and (R[i], n) for a substantial random nonce n that will be discarded; thus, there is insufficient space to enumerate.
Additionally, note that this scheme can be viewed as an expansion of Paul Sztorc’s counter-coordination scheme described earlier: if someone persuades another to incorrectly vote B while the true answer is A, they can secretly bet against them with this knowledge. Specifically, profiting from others’ moral shortcomings would now transform from a public good to a private good: an attacker who dupes another into a false collusion could reap 100% of the profits, heightening the suspicion surrounding joining a collusion that cannot be cryptographically demonstrated.
Now, how does this operate in the linear case? Assume users are voting on the BTC/USD price, meaning they must provide not a choice between A and B, but rather a scalar figure. The simplest approach is to apply the binary method in parallel to every binary digit of the price; however, an alternative method is range betting. Users can place bets of the form “I am convinced this individual will vote between X and Y with a higher probability than the average individual”; this way, disclosing even an approximate value you intend to vote for to anyone else is likely to come with costs.
Issues
What are the vulnerabilities of the scheme? Perhaps the most significant one is that it creates an opportunity to “second-order grief” other players: while one cannot, on average, force others to lose money to this scheme, one can undoubtedly expose them to risk by wagering against them. Consequently, this may present opportunities for blackmail: “comply with my demands, or I will compel you to gamble with me.” That said, this attack involves the risk of the attacker themselves being exposed to loss.
The most straightforward method to mitigate this is by capping the amount that can be gambled, and possibly even limiting it in relation to how much is wagered. For instance, if P = 0.1, allow bets up to $1 stating “I am certain this person will vote X with more than 0.11 probability,” bets up to $2 stating “I am certain this person will vote X with more than 0.12 probability,” etc. (mathematically savvy users may recognize that mechanisms like logarithmic market scoring rules are effective methods for efficiently implementing this functionality); in this case, the amount of money you can extract from someone will be quadratically related to the amount of private information you possess, and conducting large-scale griefing is bound to cost the attacker money over time, rather than just risk.
The second point is that if users are known to utilize several specific sources of information, especially on more subjective inquiries like “vote on the price of token A / token B” rather than solely binary events, those users may become vulnerable; for example, if it is known that some users tend to rely on Bitstamp while others look to Bitfinex for their voting information, then as soon as one obtains the latest feeds from both exchanges, they can probabilistically extract some amount of money from a participant based on the estimate of which exchange they are following. Thus, it remains an area for research to determine precisely how users would react in such a scenario.
It is important to note that such occurrences are a complex issue in any situation; failure modes where all participants converge on one specific exchange are very likely to happen, even within straightforward Sztorcian schemes devoid of this kind of probabilistic griefing. Perhaps a multi-layered scheme possessing a second-layer “appeals court” of voting at the top that is invoked so rarely that centralization effects do not materialize may alleviate the problem, but this remains a highly dependent empirical inquiry.
