mirror of
https://github.com/serai-dex/serai.git
synced 2025-01-03 09:29:46 +00:00
Document the signals pallet in the user-facing docs
This commit is contained in:
parent
233164cefd
commit
9662d94bf9
3 changed files with 42 additions and 6 deletions
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
title: Evolutions
|
||||
layout: default
|
||||
nav_order: 5
|
||||
has_children: true
|
||||
---
|
42
docs/protocol_changes/index.md
Normal file
42
docs/protocol_changes/index.md
Normal file
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
title: Protocol Changes
|
||||
layout: default
|
||||
nav_order: 5
|
||||
---
|
||||
|
||||
The protocol has no central authority nor organization nor actors (such as
|
||||
liquidity providers/validators) who can compel new protocol rules. The Serai
|
||||
protocol is as-written with all granted functionality and declared rules
|
||||
present.
|
||||
|
||||
Validators are explicitly granted the ability to signal for two things to occur:
|
||||
|
||||
1) Halt another validator set.
|
||||
|
||||
This will presumably occur if another validator set turns malicious and is the
|
||||
expected incident response in order to apply an economic penalty of ideally
|
||||
greater value than damage wrecked. Halting a validator set prevents further
|
||||
publication of `Batch`s, preventing improper actions on the Serai blockchain,
|
||||
and preventing validators from unstaking (as unstaking only occurs once future
|
||||
validator sets have accepted responsibility, and accepting responsibility
|
||||
requires `Batch` publication). This effectively burns the malicious validators'
|
||||
stake.
|
||||
|
||||
2) Retire the protocol.
|
||||
|
||||
A supermajority of validators may favor a signal (an opaque 32-byte ID). A
|
||||
common signal gaining sufficient favor will cause the protocol to stop producing
|
||||
blocks in two weeks.
|
||||
|
||||
Nodes will presumably, as individual entities, hard fork to new consensus rules.
|
||||
These rules presumably will remove the rule to stop producing blocks in two
|
||||
weeks, they may declare new validators, and they may declare new functionality
|
||||
entirely.
|
||||
|
||||
While nodes individually hard fork, across every hard fork the state of the
|
||||
various `sriXYZ` coins (such as `sriBTC`, `sriETH`, `sriDAI`, and `sriXMR`)
|
||||
remains intact (unless the new rules modify such state). These coins can still
|
||||
be burned with instructions (unless the new rules prevent that) and if a
|
||||
validator set doesn't send `XYZ` as expected, they can be halted (effectively
|
||||
burning their `SRI` stake). Accordingly, every node decides if and how to future
|
||||
participate, with the abilities and powers they declare themselves to have.
|
0
docs/protocol_changes/signals.md
Normal file
0
docs/protocol_changes/signals.md
Normal file
Loading…
Reference in a new issue