Sketch of possible Anoma proof-of-stake system: "heterogeneous proof-of-stake"

Protocol Design
1

Abstract

The aim of this post is to sketch a possible Anoma proof-of-stake system, which for this post I will call “heterogeneous proof-of-stake”, although this name should be considered provisional.

This design is a continuation of previous thoughts here, and has also been inspired by discussions with Barnabe Monnot from the Ethereum Foundation.

To start, I think it is necessary to describe the design context and goals.

1.1: What should proof-of-stake provide?

Proof-of-stake was originally understood as an alternative to proof-of-work to be used with Nakamoto consensus. It also enabled BFT consensus algorithms to be operated in a more open manner, particularly influenced by the launch of Cosmos. At this time, proof-of-stake was primarily considered a voting power allocation mechanism for consensus, and was concerned only with the service of consensus (often referred to as “validation”, although this is a bit of a misnomer).

I understand here the goals of proof-of-stake in a broader sense - in particular, two, which are typically coupled but fundamentally quite distinct:

  • Credible long-term alignment with an asset (and the associated network), which can be achieved by locking the asset for some duration, with a longer duration providing longer-term alignment. This mechanism considered alone is not dissimilar to a “bond” issued by corporations or governments - it is, in effect, debt sold by the protocol (although it also does not feature many specific legal features present in that market, and we should probably find a different term).
  • Credible service commitments which can be entered into by various parties to provide various services such as attestation (validators), storage provisioning, compute provisioning, bandwidth provisioning, etc. These commitments typically require:
    • The ability to punish safety violations (e.g. double-signing), which often requires association of the commitment with a “safety deposit” that cannot be withdrawn at will. This is why these commitments (particularly to attestation) are often associated with the locked bonds of native tokens.
    • The ability to reward correct behaviour (e.g. signing votes), which often requires the ability to mint native tokens and distribute them to correctly-behaving parties.

1.2: What do users want?

  • Network operator diversity (decentralization, preference entropy).
  • The ability to prove long-term alignment and to make service commitments.
  • Returns for committing to long-term alignment.
  • As much liquidity as is compatible with the protocol’s security requirements.

2.1: Abstract Proposal

Abstractly, the proposed proof-of-stake mechanism would consist of:

  • A bond mechanism, with which the protocol can buy and sell (from and to users), and users can buy and sell (from and to each other and the protocol), transferable bond objects, each with a duration, interest rate, and other such parameters. Details such as variable/fixed interest, auto-rollover, etc. are yet to be determined.
  • A target debt profile, describing the protocol’s preferred debt distribution across time and bond types, which is used to set prices at which the protocol will buy and sell (AMM-style), and to set interest rates for variable-interest bonds.
  • A general language for service commitments, each of which consists of:
    • A safety property, typically what the operator will not do (e.g. double-sign), logic to detect and attribute faults when this property is violated, and logic to punish (slash) faulty operators.
    • A liveness property, typically what the operator will do (e.g. sign), and logic to detect correct behavour.
  • A service bonding mechanism to associate service commitments with bonds. In general, services must be deactivated before bonds can be resold to the protocol. Most service deactivations are immediate, but some (e.g. attestation) will require cooldown periods (in order to allow for faults to be detected).
  • A service payout function (mutable) which calculates what the protocol will pay out for different service commitments, on the basis of the type, the liveness, the operator’s identity, and the other service commitments made.

2.2: Concrete Proposal

  • Most of the mechanisms and functions can be implemented on the Anoma Resource Machine.
  • The service commitment language should be in the form of predicates over incoming and outgoing messages. This must be legible to the whole system. These commitments can then be registered with particular controllers.

3: Alternative Options

  • These two goals can be completely decoupled by making the choice about service commitment payments collective (via governance) rather than individual. This means that losses are socialized, though - need to think about incentives here. Perhaps a hybrid approach (~ delegator DAOs) is possible.
3 Likes
2

As with almost everything Anoma, I always enjoy the clean abstraction.

The standard explanation for why proof-of-X is required is usually that it acts as an anti-sybil mechanism. Of course, it doesn’t really, it just means that its expensive in some sense (perhaps in alignment abstractly) to increase one’s representation in the network. My reading of this post is that you would classify this kind of goal “anti-sybilish” explanation that is usually given as a contained within the credible long-term alignment goal. Is that correct?

How are you thinking about the challenges of measuring long-term commitment? For instance, some node operators on Ethereum have 32 Eth staked and stand to lose a big chunk of it if they misbehave, rocket pool node operators have some eth delegated to them so stand to lose less etc.

2 Likes
3

Good question. I think “anti-Sybil” is often underdefined - defining an objective way to distinguish “really different” identities is very difficult, at some point it even simply becomes the proof-of-humanity problem. In the simple sense of preventing arbitrary P2P network participants from taking over the network without expending some cost (in purchasing tokens) - which I think is usually how proof-of-stake systems might understand this term - that is an important sub-goal which I diid not mention. I do think it can be contained within the long-term alignment goal, but maybe should then be rephrased as long-term alignment of distinct / anticorrelated actors, which I didn’t explicate at all - this model needs to be refined a lot! That distinction might be useful, though, since it should also capture e.g. wanting the reward system to preserve anticorrelation, which “instantaneous” anti-Sybil does not imply.

It’s a double-sided market (users with intents/assets/transactions seeking secure ordering, storage, and compute, and validators/operators providing ordering/storage/compute with different bonds, security levels, etc.), so I think it will depend on what users want, and different choices will make sense for different applications and transactions. As you mention, one valuable measure is simply how much would be lost if a commitment is violated, since this can be used by the user to perform a quick analysis - if the operator would lose less than they might gain, probably not secure enough!

1 Like