Against Economic Abstraction

Firstly, let me apologize to everyone who is waiting for Chapter 5 of the history of Casper for producing this first. This turns out to be quite urgent because Greg Meredith is currently considering committing to economic abstraction in RChain. Chapter 5 is coming, I wasn’t able to produce it yet because I was travelling and then came down with a small cold. I’m almost feeling well enough to write it :)

What is “economic abstraction”?

“Economic abstraction”, in the context of blockchain architecture, refers to the idea that a blockchain architecture can be modified to remove the existence of a single native blockchain token (or “coin”). Rather than the protocol requiring use of a particular token, the protocol would allow the use of any one of a potentially unbounded number of tokens.

I am going to cover the case against economic abstraction for:

• security deposits (and other tokens that are “stakes” in PoS protocols)
• transaction fees
• incentives provided through token issuance

Against economic abstraction of security deposits

For clients of the consensus

In any proof-of-stake consensus protocol, the value of the coins that are “staked” or on deposit will determine the economic security of the consensus. Clients may have to make decisions as a function of the amount of economic security of the consensus. Economic abstraction of security deposits makes calculating economic security more difficult, increases the attack surface on the economic security calculation, and reduces economic security.

To calculate economic security in the context of abstraction of security deposits (or staked coins), clients must at least be aware of the effective exchange rate between the different bonded/staked coins. This means that the clients must correctly answer these questions, for each coin:

• Which exchanges/brokers have significant volume?
• What is the market depth at these exchanges/brokers?

I will call this process price discovery (though this isn’t usually how the term is generally used, in economics literature). If these coins do not trade against the same assets, then the clients must also know about the exchanges/brokers and corresponding market depths for the “intermediate” assets required to trade between them. Due to economic abstraction of security deposits, clients must engage in extra-protocol price discovery every time they interact with the protocol to safely make an economic security calculation. No matter what their choice of base unit of account.

Moreover, the attack surface on the safety calculation is higher due to this economic abstraction because economic security calculations are sensitive to the market depths available from any exchange/broker that trades any of the bonded/staked tokens. Finally, this reduces the security of the safety calculation (and therefore of the protocol) because it is easier (or not harder, strictly speaking) to push down the price of any 1 of N of the tokens, than to push down the price of any given fixed token (which could have been the one native token, without economic abstraction).

For clients wanting to place a deposit

Clients wanting to place a security deposit in a system with economic abstraction also have to do price discovery to decide in which token it is most strategic to place on deposit. They also will need/want to consider the price of hedging the volatility in the bonded token, so that they are not exposed to risk that is not correlated with their performance as bonded validators. This complicates the economic calculations that validators must make in order to be sure that they are making a rational decision.

Note that the case against economic abstraction for security deposits is better in the context of a mandatory minimum bond size policy, since the protocol itself will need to do price discovery to compare the relative prices of tokens to determine minimum bond sizes in each token in a fair manner.

Against economic abstraction of transaction fees

In this section, I will assume that the blockchain protocol in question has no mandatory fee policy, and that there is no fee distribution policy. This omission is for the sake of brevity — there is no way that economic abstraction is easier to reason about in the context of either of these policies. Instead I will assume that transaction fees are paid directly from clients to the validator who produced the block from which the transactions were executed.

For validators wanting to accept transactions

Validators must engage in price discovery (for a given token) to decide which fees offered by clients (in that token) are too cheap in price to justify their inclusion in blocks. If they want to maximize their potential to earn revenue, they must do price discovery in every protocol-compliant token that clients are trying to use to pay transaction fees. This makes the validators’ job more complicated.

For clients wanting to make transactions

Clients must query validators directly or by looking at their blocks to discover what prices in what tokens they are willing to accept in the various protocol-compliant tokens. They must then engage in price discovery to decide which tokens to purchase in order to get the best deal on transaction fees, at least if saving the money is worth the effort. This makes client transaction-making logic more complex.

Note that the case against economic abstraction for transaction fees gets better in the context of a mandatory fee policy, since then the protocol itself will need to do price discovery to compare the relative prices of tokens in order to set the required fee for each token in a fair manner.

Against economic abstraction of token issuance

Token issuance is an important part of guaranteeing the economic security of most blockchain protocols that are publicly known today. In the context of economic abstraction every protocol-compatible token must be issued for security.

Insofar as clients must reason about economic security as a function of issuance, they must (at least) do extra-protocol price discovery in order to understand the price of the protocol’s issuance. This complicates client calculations of economic security.

Important notes

This discussion omits discussion of price volatility of and correlation between the various protocol tokens, and of risk-aversion of clients. Each of these factors are important and make the economic security calculation even more difficult and complex.

The attack surface on all of the calculations described above include attacks on the order books of any exchange/broker with non-negligible volume.

Price discovery is extra-protocol reasoning, and in practice (at least in the short term) will involve queries to the Poloniex API. This changes the nature of the trust model of the safe authentication of the economic security of the blockchain protocol.

Conclusion

Economic abstraction, while at first brush seems like an elegant ideal (especially from the point of view of the aesthetics of a computer scientist), will dramatically increase the complexity of the economic calculations of clients and validators.

By increasing the attack surface and changing the trust model of economic security calculations, it reduces security for everyone.

IMHO, economic abstraction is an exceptionally bad idea.