3. Three examples of cryptoeconomics

There are at least three different kinds of systems being designed today that could be called “cryptoeconomic”.

Example 1: Consensus protocols

Blockchains are able to reach reliable consensus without having to rely on a central trusted party — a product of cryptoeconomic design. Bitcoin’s solution, which we surveyed above, is called “proof-of-work” consensus because miners must commit work — in the form of hardware and electricity — in order to participate in the network and receive mining rewards.

Improving proof-of-work systems and designing alternatives to them is one active area of cryptoeconomic research and design. Ethereum’s current proof-of-work consensus mechanism includes many variations and improvements on the original design, enabling faster block times and being more resistant to the mining centralization that can result from ASICs

In the near future, ethereum plans to migrate to a “proof-of-stake” consensus protocol called Casper. This is an alternative to proof-of-work that does not require “mining” in the usual sense: there is no need for specialized mining hardware or huge expenditures of electricity.

Remember that the whole point of requiring miners to buy hardware and spend electricity is to impose a cost on miners, as a way of raising the cumulative cost of attempting a 51 percent attack sufficiently high that it becomes too expensive. The idea behind proof-of-stake systems is to use deposits of cryptocurrency to create the same disincentive, rather than real-world investments like hardware and electricity.

In order to mine in a proof-of-stake system, you must commit a certain amount of ether into a smart contract “bond.” Just like in proof-of-work, this raises the cost of a 51 percent attack — an attacker would have to commit a very large amount of ether to successfully attack the network, which they would then lose forever.

Casper is being designed by Vlad Zamfir, Vitalik Buterin, and others at the Ethereum Foundation. You can read more about the history of Casper’s designin this series of posts by Zamfir or hear him talk about it on a recent podcast. Buterin wrote a long post about Casper’s design philosophy here, and there is a useful FAQ on the ethereum GitHub wiki here.

Example 2: Cryptoeconomic application design

Once we have solved the fundamental problem of blockchain consensus, we are able to build applications that sit “on top” of a blockchain like ethereum. The underlying blockchain gives us (1) a unit of value that can be used to create incentives and penalties, and (2) a toolkit with which we can design conditional logic in the form of “smart contract code.” The applications we build with these tools can also be a product of cryptoeconomic design.

For instance, the prediction market Augur requires cryptoeconomic mechanisms in order to function. Using its native token REP, Augur creates asystem of incentives that rewards users for reporting the “truth” to the application, which is then used to settle bets in the prediction market. This is the innovation that makes a decentralized prediction market possible. Another prediction market, Gnosis, uses a similar method, though also lets users specify other mechanisms for determining true outcomes (commonly called “oracles”).

Cryptoeconomics is also applied to design token sales or ICOs. Gnosis, for instance, used a “Dutch auction” as a model for its token auction, on the theory that this would result in a more fair distribution (an experiment that had mixed results). We mentioned earlier that one area where mechanism design has been applied is in the design of auctions, and token sales gives us a new opportunity to apply some of that theory.

These are a different kind of problem than building the underlying consensus protocols, but they share enough similarities that both can be fairly seen as cryptoeconomic. Building these applications requires an understanding of how incentives shape users’ behaviour and careful design of economicmechanisms that can reliably produce a certain result. They also require an understanding of the capabilities and limitations of the underlying blockchain on which the application is built.

Many blockchain applications are not necessarily products of cryptoeconomics; for instance, applications like Status and MetaMask — wallets or platforms that let users interact with the ethereum blockchain. These do not involve any additional cryptoeconomic mechanisms beyond those that are already part of the underlying blockchain.

Example 3: State channels

Cryptoeconomics also includes the practice of designing much smaller sets of interactions between individuals. The most notable of these are state channels. State channels are not an application but a valuable technique that can be used by most blockchain applications to become more efficient.

A fundamental limitation of blockchain applications is that blockchains are expensive. Sending transactions requires fees, and using ethereum to run smart-contract code is comparatively costly to other kinds of computation. The idea behind state channels is that we can make blockchains more efficient by moving many processes off-chain, while still retaining a blockchain’s characteristic trustworthiness, through the use of cryptoeconomic design.

Imagine Alice and Bob want to exchange a large number of small payments of cryptocurrency. The normal way for them to do this would be to send transactions to the blockchain. This is inefficient — it requires paying transaction fees and waiting for the confirmation of new blocks.

Instead, imagine that Alice and Bob sign transactions that could be submitted to the blockchain, but are not. They pass these back and forth between one another, as fast as they want — there are no fees at this point, because nothing is actually hitting the blockchain yet. Each update “trumps” the last one, updating the balance between the parties.

When Alice and Bob have finished exchanging small payments, they “close out” the channel by submitting the final state (i.e. the most recent signed transaction) to the blockchain, paying only a single transaction fee for an unlimited number of transactions between themselves. They can trust this process because both Alice and Bob know that each update passed between them could be sent to the blockchain. If the channel is properly designed, there is no way to cheat — say, by trying to submit a previous update as though it were the most recent — since recourse to the blockchain is always available.

For illustrative purposes, you can think of this as similar to how we interact with other trusted sources, like a legal system. When two parties sign a contract, most of the time they never need to take that contract to court and ask a judge to interpret and enforce it. If the contract is properly designed, both parties simply do what they promised to do, and never interact with the courts at all. The fact that either party could go to the court and have the contract enforced is enough to make the contract useful.

This technique is not just useful for payments, but for any update to the state of an ethereum program — hence the more general term “state channel” rather than the narrow “payment channel.” Instead of sending payments back and forth, we can send updates to a smart contract back and forth. We can even send entire ethereum smart contracts that, if needed, will be sent to the blockchain and executed. These programs never have to be executed to be useful. All that is needed is a sufficiently high guarantee that they could be executed if necessary.

In the future, most blockchain applications will use state channels in some form. It is almost always a strict improvement to require less on-chain operation, and many things done on-chain today can be moved into state channels while still preserving a sufficiently high guarantee to be useful.

The description above skips over many important details and nuances of how state channels work. For a more detailed description, Ledger Labs built a toy implementation last summer that demonstrates the basic concept.