Ecosystem/serai
Ecosystem/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2025-01-09 12:29:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Rewrite the Validators spec

Browse source 
Moves Oraclization/Report to Consensus for now.
This commit is contained in:
Luke Parker 2022-07-19 23:10:12 -04:00
parent 1b461ca5be
commit d320af06a7
2 changed files with 46 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/protocol/Consensus.md
View file

@ -1,3 +1,11 @@
# Oraclization (message)
`Oraclization` messages are published by the current block producer and communicate an external event being communicated to the native chain. This is presumably some other cryptocurrency, such as BTC, being sent to the multisig wallet, triggering a privileged call enabling relevant actions.
# Report (message)
`Report` reports a validator for malicious or invalid behavior. This may be publishing a false `Oraclization` or failing to participate as expected. These apply a penalty to the validator's assigned rewards, which is distinct from the bond which must be kept as a multiple of 1m. If the amount deducted exceeds their assigned rewards, they are scheduled for removal with an appropriately reduced bond.
# Consensus # Consensus
Consensus is a modified Aura implementation with the following notes: Consensus is a modified Aura implementation with the following notes:

53
docs/protocol/Validators.md
View file

@ -1,23 +1,46 @@
# Register (message) # Register (message)
`Register` messages mark the signer as a valid target to become a validator. They include another public key, who must also sign, of who is the manager for the validator in question. - `validator` (signer): Address which will be the validator on Substrate.
- `manager` (signer): Address which will manage this validator.
- `set` (u8): Validator set being joined.
# Stake (message) Marks `validator` as a validator candidate for the given validator set, enabling
delegation.
`Stake` specifies a validator, or validator candidate, and delegates the specified amount to them. Initially, only the manager of a validator may stake to them. The stake amount must be a non-zero multiple of 1m $SRI. This is due to multisig key shares being without weights, requiring validators to be equal accordingly to ensure security. Each 1m $SRI causes a new share of the group key to be assigned. # Delegate (message)
- `delegator` (signer): Address delegating funds to `validator`.
- `validator` (address): Registered validator being delegated to.
- `amount` (u64): Amount of funds being delegated to `validator`.
Delegated funds will be removed from `delegator`'s wallet and moved to
`validator`'s bond. If `validator`'s bond is not a multiple of the validator
set's bond, it is queued, and will become actively delegated when another
delegator reduces their bond.
Note: At launch, only `validator`'s manager will be able to delegate to
`validator`, and only in multiples of the validator set's bond.
# Undelegate (message)
- `delegator` (signer): Address removing delegated funds from `validator`.
- `validator` (address): Registered validator no longer being delegated to.
- `amount` (u64): Amount of funds no longer being delegated to
`validator`.
If a sufficient amount of funds are queued, the `validator`'s operation
continues normally, shifting in queued funds. If the `validator` falls below a
multiple of the validator set's bond, they will lose a key share at the next
churn. Only then will this undelegation process, unless another party delegates,
forming a sufficient queue.
Note: At launch, only multiples of the validator set's bond will be valid.
# Resign (message) # Resign (message)
`Resign` specifies a validator, or validator candidate, and initiates their removal. For an active validator, they will be removed at the next churn, returning their bond to the validator's manager. For a non-active validator, their bond is immediately returned. - `validator` (address): Validator being removed from the pool/candidacy.
- `manager` (signer): Manage of `validator`.
## Rationale for the separation of Register and Stake If `validator` is active, they will be removed at the next churn. If they are
solely a candidate, they will no longer be eligible for delegations. All bond is
Ideally, a DPoS system will eventually be possible where stake takes a variadic amount. Once the stake value hits 1m, the validator is considered for active inclusion. If the stake value hits a new multiple of 1m, a new key share would be assigned. Any excess stake amount would be added to a queue and when someone else unstakes, this queue will shift in. If there is insufficient excess stake, the node would lose a key share/inclusion in validation entirely. This is not being considered for the initial release, leaving out an `Unstake` message and instead routing handling though `Resign`. refunded after their removal.
# Oraclization (message)
`Oraclization` messages are published by the current block producer and communicate an external event being communicated to the native chain. This is presumably some other cryptocurrency, such as BTC, being sent to the multisig wallet, triggering a privileged call enabling relevant actions.
# Report (message)
`Report` reports a validator for malicious or invalid behavior. This may be publishing a false `Oraclization` or failing to participate as expected. These apply a penalty to the validator's assigned rewards, which is distinct from the bond which must be kept as a multiple of 1m. If the amount deducted exceeds their assigned rewards, they are scheduled for removal with an appropriately reduced bond.