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

**URL:** <https://forum.anoma.net/t/sketch-of-possible-anoma-proof-of-stake-system-heterogeneous-proof-of-stake/492>\
**Category:** Protocol Design\
**Created:** [March 1, 2024, 10:48am UTC](https://forum.anoma.net/t/sketch-of-possible-anoma-proof-of-stake-system-heterogeneous-proof-of-stake/492 "2024-03-01T10:48:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\
**Post date:** [March 1, 2024, 10:48am UTC](https://forum.anoma.net/t/sketch-of-possible-anoma-proof-of-stake-system-heterogeneous-proof-of-stake/492/1 "2024-03-01T10:48:42Z")

</div>

**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](https://forum.anoma.net/t/generalized-proof-of-stake/389), 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](https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm) 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](https://github.com/cosmos/v1.cosmos.network/blob/develop/content/pdf/cosmos-whitepaper.pdf). 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.

---

<div class="post-metadata">

**Author:** ![quintus](https://avatars.discourse-cdn.com/v4/letter/q/49beb7/32.png) [@quintus](https://forum.anoma.net/u/quintus)\
**Post date:** [March 1, 2024, 10:04pm UTC](https://forum.anoma.net/t/sketch-of-possible-anoma-proof-of-stake-system-heterogeneous-proof-of-stake/492/2 "2024-03-01T22:04:35Z")

</div>

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

> [@cwgoes](#):
>
> **1.1: What should proof-of-stake provide?**

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.

---

<div class="post-metadata">

**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\
**Post date:** [April 24, 2024, 10:33am UTC](https://forum.anoma.net/t/sketch-of-possible-anoma-proof-of-stake-system-heterogeneous-proof-of-stake/492/3 "2024-04-24T10:33:03Z")

</div>

> [@quintus](#):
>
> 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?

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.

> [@quintus](#):
>
> 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.

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!
