Proof-of-stake system background reading & discussion about anoma-archive HOT 7 CLOSED

In general, we should avoid introducing too much complexity in the proof-of-stake system, since it makes security more difficult to analyse and since we aren't trying to innovate in this particular area so much (at least initially). That said, there are some neat things we can do with validity predicates and the trade system without much extra effort which might be worthwhile:

• We can certainly use the trade system to handle reward distribution: each validator will have a special account with a validity predicate they control to which inflation and fees from validating is sent, then they can implement whatever fee distribution algorithm they prefer for their delegators (with defaults available).
• Possibly, we could even use the trade system to allocate delegations to validators, by all stakeholders periodically broadcasting orders describing which validators they're willing to delegate to and/or algorithmic selection (lowest fees), which would interplay nicely with e.g. power-quadratic fee distribution (this is a bit similar to NPoS), and also with quadratic slashing if slashing risk can be included as an algorithmic parameter somehow (if the goal is partially to provide better Sybil-resistant identity, it probably cannot be, but off-chain tooling could incorporate it). This would replace manual delegation and redelegation.

Miscellaneous notes:

• We should have epochs for changes, it makes things much simpler and doesn't come with significant downsides. A particular bond must be assigned to a particular validator for a particular epoch. This should make it possible to allow redelegation once per epoch and avoid tracking "redelegations" separately.
• Staking reward calculation should start from the discussions in cosmos/cosmos-sdk#3529, subject to changes for the DKG, exchange fees, etc. and a better formalisation.
• We should definitely do quadratic/proportional slashing, approximately as per this document.

from anoma-archive.

Possibly, we could even use the trade system to allocate delegations to validators, by all stakeholders periodically broadcasting orders describing which validators they're willing to delegate to and/or algorithmic selection.

We should do this, but clearly separate out the interface so the non-Anoma-specific parts of the bond implementation, epochs, Tendermint validator set delta calculation, etc. can be written as a separate module.

from anoma-archive.

Basic model of proof-of-stake:

The primary state tracked by the proof-of-stake system is a set of "bonds", or bonded units of stake:

type Bond {
  delegator: Address
  validator: Address
  amount: Tokens
  epochStart: Nat
  epochEnd: Nat
}

Bond objects are created when a delegator locks up stake to a particular validator. Each epoch, voting power in Tendermint is allocated proportionally to the sum of tokens for all bonds to a particular validator. When a delegator unbonds, their bond is marked as ending in the appropriate epoch.

Points of consideration:

• Desiderata of slashing: accurately punish delegators according to their contribution to the validator's power at the time of the misbehaviour.
• It would be nice if we could avoid tracking redelegations separately. We could even consider giving up redelegation, although it would be nice - but we also need to think about how it would interact with automatic delegator-valdiator matchmaking.
• Need to consider epoch length w.r.t. unbonding period, whether there is any relation between the two.
• We could allow a bond to be assigned to a particular validator for each epoch, this is OK but it does mean that the bond's validator list may grow indefinitely long over time, so we have to store it in a subkey or something instead - however, we can prune old epochs safely.
• "unbonding" is almost like a special validator, the bond object remains until the end of the unbonding period.
• Logically, the funds should be "in" the (each particular) bond object.
• For slashing, we can then lookup the exact power distribution at a past block (for which we haven't yet pruned data)

from anoma-archive.

Should the proof-of-stake module be a validity predicate? It's possible, but I think probably not, we need to e.g. do a lot of periodic queue iteration and cleanup on BeginBlock / EndBlock, and I think it's fine for upgrades of the proof-of-stake system to require the full upgrade process.

from anoma-archive.

Operations exposed by the proof-of-stake module:

type delegate = (delegator: address, validator: address, amount: uint) => (bond: int)

type redelegate = (bond: int, validator: address) => ()

type undelegate = (bond: int) => ()

type slash = (validator: address, fraction: Fraction, block: uint) => ()

Misc notes:

• Should bonds be automatically unbonded? Can simply require another transaction, which can then claim the funds.
• The proof-of-stake module needs to interact with the XAN token itself in some native fashion.

Distribution:

• Rewards should be distributed to validator accounts, which can then pay them out as they choose, delegate again, etc.
• We should implement something like F1 fee distribution as a default.

from anoma-archive.

from anoma-archive.

Closing in favour of https://github.com/heliaxdev/spec/issues/43.

from anoma-archive.