Consensus recommended: an approach to complex consensus on the blockchain that works in practice
The distributed computing solutions used by academia and mainstream tech companies maintain consensus about enormously complex systems. But blockchains operate in a more adversarial environment where fewer assumptions can be made about the behavior of nodes. Blockchains also typically use the peer to peer model where full nodes have equal functions and privileges, in contrast to mainstream distributed systems where different nodes often provide different services to the network.
Applications built on blockchains like Bitcoin are able to ignore some of the complexities of maintaining distributed consensus because Bitcoin handles this complexity by automatically resolving forks via proof of work. But many blockchain applications would like to have distributed consensus about more than just transaction data. Systems like Ethereum provide advanced functionality for decentralized apps with Turing complete smart contracts which allow base layer coins, second layer tokens and other crypto assets like non-fungible tokens to be transferred, and also allow arbitrary data to be stored on the blockchain for use by decentralized apps. Consensus about these contracts, assets and data is guaranteed by the Ethereum network.
But even Turing complete smart contracts are limited because they can only use data which is on chain. Maintaining distributed consensus about data external to the blockchain is a highly sought-after feature for dApps but remains a fundamentally hard problem. Many dApps that rely on external information approach this problem by writing data onto the blockchain after coming to consensus about the external information. This approach uses the term “oracle” to describe the source of truth which will eventually provide the authoritative data to be written to the blockchain. In prediction markets, oracles typically determine the outcome for markets with voting by stakeholders who are collectively incentivized to select the correct outcome by game theory.
PolyCash takes a unique approach to distributed consensus based on the assumption that consensus cannot be solved at the technical level alone and instead should be solved at the political level. The PolyCash software is technically built with a “consensus not required” paradigm. Nevertheless, consensus is achieved in practice.
Each PolyCash crypto asset runs on top of a blockchain such as Bitcoin or Litecoin and therefore nodes remain fully in consensus about transaction data from the underlying blockchain. But these crypto assets are “second layer tokens” aka “colored coins.” Each transaction from the underlying blockchain is interpreted in the context of the associated “game” or crypto asset. Therefore, the UTXO set for each crypto asset is determined by data stored in the “game definition” in addition to data from the blockchain.
The game definition contains all information not contained in the blockchain which is needed to determine the UTXO set. Nodes can easily check if they are in consensus by comparing hashes of their game definitions. If they are not in consensus, differences in their game definitions allow them to quickly see and resolve their points of difference.
For simple crypto assets built with the PolyCash protocol, the game definition may never change. In these assets, the game definition only contains the genesis tx hash, the initial coin supply and a few other parameters supported by the PolyCash protocol. But for more sophisticated assets like the sports betting games and virtual stock market that we’ve launched, the game definition frequently changes when new betting events are added or when sporting event outcomes or synthetic stock payout prices are determined.
Game definition changes are handled carefully to preserve the history of the UTXO set for a game at every point in time. And changes to the game definition should be adopted by all nodes running a crypto asset to avoid a fork of the asset. Whenever a node changes its game definition, it saves a copy of its current game definition and then runs a migration routine to switch to the new game definition. When a node migrates from one game definition to another, game reloading takes place. When a base parameter for a game is changed, the entire game must be reloaded. But when something like a prediction market event outcome is set, the game only needs to be reloaded from the affected block. Game reloads can be time consuming and wallet features are restricted during them to prevent users from creating transactions.
Game definitions allow nodes to easily check if they are in consensus while also giving them the flexibility to incorporate information external to the blockchain and resolve differences between nodes. This provides all the functionality needed to enable distributed consensus for complex crypto assets for binary options (prediction markets) and synthetic assets.
Bitcoin uses proof of work to drive up the cost of being out of consensus, providing a game theoretic solution to reaching consensus. But Bitcoin needs to achieve distributed consensus in a relatively simpler context where the main constraints are maintaining the fixed emission schedule for 21 million bitcoins while also ensuring that transactions are balanced and have valid cryptographic signatures.
Distributed prediction markets have the harder task of maintaining consensus about real world outcomes plus additional information like the exact time during which bets can be placed and should only allow prediction markets with well-formed questions with determinable outcomes. PolyCash makes it possible to achieve consensus for decentralized prediction markets, but one of the tradeoffs for this design is the higher risk of forks. PolyCash does not attempt to make it impossible to fork crypto assets at the technical level. But PolyCash makes it possible to achieve consensus and relies on game theory to achieve consensus in practice.
PolyCash crypto assets may have value which fluctuates based on supply and demand like most cryptocurrencies. But PolyCash is also designed to support stablecoins where crypto assets are backed by tangible sources of value such as dollars or bitcoins held in escrow. Because stablecoins are backed by assets held in escrow somewhere, they are less decentralized than coins with free-floating value. But the game theory for avoiding forks is more straightforward in this situation. In these stablecoins, the peg between the crypto assets and the value in escrow is kept via mechanisms which allow coin-holders to retrieve dollars or bitcoins from the escrow by destroying their coins. In this context, the node or nodes which control withdrawals from escrow effectively have authority over setting the game definition. Since the value of coins is ultimately determined by the assets in escrow, other nodes are incentivized to use the same game definition as the nodes which control the escrow. Nodes using non-consensus game definitions are only deceiving themselves.
The game theory is similar for crypto assets with free-floating value. When most nodes are in consensus about the current game definition, nodes which are not in consensus are only deceiving themselves about the state of the current UTXO set. Not being consensus is very costly to Bitcoin miners and in theory breaks the currency but in PolyCash games being out of consensus does not break the currency. Nodes which disagree about the outcome of a single betting event will have different values for any affected UTXOs but will still have consensus about the majority of UTXOs.
If every end user operates their own node, temporarily being out of consensus only means that some users were temporarily deceiving themselves and once all nodes get back into consensus, affected users will now see accurate transactions in their wallets. But some users may not be willing to set up a node and PolyCash also allows users to set up web wallets on public nodes. PolyCash crypto assets should also be tradeable on exchanges who would need to install nodes. In these contexts, there are possibilities for end users to lose money to node operators/exchanges and for node operators/exchanges to lose money to end users even when consensus is only temporarily broken.
To mitigate this problem, PolyCash nodes maintain a list of peers and constantly check if they are in consensus with all of their peers. If they are not in consensus with any peer, the node automatically switches into a “lockdown mode” for that crypto asset which disables key features like exchanging and withdrawing coins. Once the consensus problem is resolved, lockdown mode is switched off and exchange/withdraw features are switched back on.
This solution makes it possible to maintain consensus for prediction markets in decentralized adversarial environments. This software can also be used in less decentralized environments such as a betting business who sets up an escrow backed stablecoin and uses this software to efficiently accept and payout bets.
In PolyCash prediction markets, bets are placed by destroying coins to one of your own addresses. And payouts work by each node re-creating that money by updating the value of winning UTXOs. No payout transaction is created. This is much different than traditional betting solutions where a bookmaker holds onto funds and then pays out bets. It is also different from decentralized solutions where smart contracts provide the escrow and payout functions. Rather than bets being tied up in escrow, players still hold onto the private keys for their bets in this model. This creates a kind of “conditional money” where you can hold onto and even spend UTXOs which have a value dependent on future events.
This approach to distributed consensus relies on game theory and can only be proven by being tried in the real world. If distributed consensus cannot be achieved in practice using the approach described above, the protocol may need to be extended. Possible solutions like creating a custom blockchain where blocks are mined by hashing the current game definition alongside the transaction Merkle root may provide the way forward. If you would like to help us prove or disprove this concept, please consider setting up a node, providing feedback, or checking out our code on GitHub or signing up for one of our games.
