Hi again :)

Round one maybe wasn’t quite enough — I hope round 2 will be a knockout!

A quick foreword

Proof-of-stake systems that do not use security deposits cannot have almost any in-protocol disincentives for “stakers” not to be Byzantine, and therefore clients must simply assume that the stakers are not Byzantine (usually at least a weighted-by-stake majority of them). This assumption is ridiculous in the context of any kind of economic analysis that doesn’t permit convenient reliance on extra-protocol incentives (i.e. “their coins will fall in value!1!”).

Without security deposits there really can’t be that much at stake.

So I’m not going to talk about naive proof-of-stake and instead talk only about security-deposit-based proof-of-stake. Note anyways that all of the arguments given here have direct analogies in naive proof-of-stake land.

I really hope that some day soon the cryptocurrency space will collectively abandon proof-of-stake protocols that don’t use security deposits. It would make for shorter, cleaner blog posts!

The nature of authentication in proof-of-stake

To safely authenticate a proof-of-stake protocol, a client must know about a set of nodes (lets call them validators) who currently have security deposits.

Clients rely on knowledge of the current state of security deposits to distinguish between digital signatures from nodes with something at stake and signatures from nodes with nothing at stake.

This knowledge allows clients to assign weights to the validators they know about. They may have to use these weights to choose between alternative “forks” of the consensus. If two clients disagree about the weights of validators, they may choose two different forks.

Fork choice under economic abstraction

Economic abstraction might put clients in a position where they know about validators that have deposits in tokenA and validators that have deposits in tokenB. In this case, clients must decide the relative price of tokenA to tokenB before assigning weights to validators. And they must assign weights to validators before they authenticate the consensus.

They need to compare apples to oranges as step 1. They need to decide precisely how many apples are worth exactly as much as a single orange before they can begin to authenticate the consensus.

These clients need to learn the relative price of apples to oranges. But price discovery is complicated and has an attack surface (this was covered in round 1). Clients might disagree about the relative price of tokenA to tokenB, and therefore may choose two different forks even given the exact same view of the state of the protocol.

Economic abstraction of deposit tokens is a consensus critical problem.

Assuming clients already agree on the relative prices of tokens

However, we can cleverly assume that at T=1, clients do agree on the relative prices of apples and oranges. Then they will be able to reliably authenticate the state of the consensus. They will then be able to agree on a relative price for T=2, using the consensus protocol itself! Induction ftfw!

Rather than authenticating the state with just knowledge of validators who have deposits in tokenA and of validators who have deposits in tokenB, in this model we will authenticate the consensus using an additional piece of information; the relative price of tokenA to tokenB.

This change in the model allows us to circumvent the consensus critical problem described in the previous section. And it requires that we update this relative price using the consensus protocol itself.

This consensus relative price information is only accurate if it is a reliable forecast of future exchange rates. However, predicting prices is notoriously difficult. If the consensus relative price is incorrect in a predictable way, the protocol creates opportunities for an adversary to buy consensus weight at a discount. In this case, the attacker will buy tokenA when the consensus overestimates the relative price of tokenA to tokenB, and will buy tokenB otherwise. This is an economic security problem.

For economic abstraction to work securely, the consensus protocol itself must engage in economic forecasting in a way that consistently does not underperform relative to an adversary’s forecast.

However, the consensus on relative prices necessarily lags behind inputs to the consensus protocol, and an adversary can themselves be the cause of price moves.

So an adversary will be able to get discounted weight in the consensus.

Conclusion

A client’s price forecasts will always influence the client’s understanding of their economic security.

However, with economic abstraction this reality becomes part of a client’s strategy for authenticating the state of the consensus. A client’s price conclusions thereby feed into determining what is true.

This can be avoided, but only by introducing a new security requirement; that the consensus can make better price forecasts than an adversary.

At very best, economic abstraction is complicated and introduces a new vulnerability that must be dealt with by effective in-consensus price forecasting.

So it’s my opinion that economic abstraction of deposit tokens is an exceptionally bad idea.