How do we incentivise good VN behaviour? Currently, byzantine behaviour has no down side. For example a node operator may simply shut their node down, causing a disruption to consensus by missing proposals without any consequence.
Staking
A VN registers and deposits an amount to stake in their initial registration. This stake is a finite resource (XTM) that provides sybil resistance and value that can be reduced for punishments or, in severe cases, completely slashed.
The minimum required amount to be queued for the active validator set is VN_MIN_ACTIVATION_BALANCE.
Optional: This may be deposited in the registration transaction or later in the form of top-ups. This allows validators to make multiple deposits to reach the required balance and to top up their balance after being punished should they fall below VN_MIN_ACTIVATION_BALANCE.
The stake is locked and not spendable. Using the minimum_value_promise machinery, the registration's value is clear. The actual commitment value may be more however there is no reason to do this as that puts more if the staker's value at risk for no benefit.
Validators will scan for these UTXOs (as before) and take note of the balance (minimum_value_promise). We'll call this the "effective balance" of the validator. This determines the validator's relative voting power for L2 consensus. We cap the effective balance to VN_EFFECTIVE_BALANCE_CAP. This may be equal to VN_MIN_ACTIVATION_BALANCE.
Once the VN_MIN_ACTIVATION_BALANCE is deposited, the validator enters an "activation queue". This queue limits the number of new validators that join the network per epoch to avoid disruptions while nodes sync and catch up to the current committee state.
Changes to L2 consensus: We currently consider each vote from a registered validator as equal to any other. To reach quorum, at least $n - f$ / $2f + 1$ votes are required where $n$ is the total number of nodes in a committee. With this change, we'll redefine $n$ as the total effective balance of the committee, requiring > 2/3rds of the total committee effective balance to vote for blocks. For functioning nodes, this is very similar to the previous quorum rule. We assume there is some mechanism for punishing nodes (reducing the effective balance) that do not participate or perform their duty to propose blocks, thereby reducing their relative voting power.
Withdrawing Stake / Exiting
We propose a new output type called ValidatorExit which registers the intent to exit from performing validator duties.
Once this UTXO is added to the blockchain, the validator enters an "exit queue". This exit queue limits the number of validators that can exit per epoch in order to avoid large changes to the active validator set, leading to disruptions. The exact epoch that the validator is removed from the active validator set can be determined from the current exit queue and the number of exits per epoch - we may want to also account for the number of VN's entering the active set too.
ValidatorExit UTXOs:
MAY have no minimum value,
MUST correspond to/reference an unspent VN registration UTXO.
MUST have a lock height >= VN_EXIT_UTXO_LOCK_HEIGHT
Once a VN has exited as per the queue, the validator node registration UTXO is unlocked/becomes spendable.
Each base node must maintain a list of the active validators and keep track of requested entries and exits. Amongst other things, this is used to prevent premature spending of validator node registrations. Once and entry/exit comes into effect the validator Merkle tree must be updated accordingly.
Problem
How do we incentivise good VN behaviour? Currently, byzantine behaviour has no down side. For example a node operator may simply shut their node down, causing a disruption to consensus by missing proposals without any consequence.
Staking
A VN registers and deposits an amount to stake in their initial registration. This stake is a finite resource (XTM) that provides sybil resistance and value that can be reduced for punishments or, in severe cases, completely slashed.
The minimum required amount to be queued for the active validator set is
VN_MIN_ACTIVATION_BALANCE.Optional: This may be deposited in the registration transaction or later in the form of top-ups. This allows validators to make multiple deposits to reach the required balance and to top up their balance after being punished should they fall below
VN_MIN_ACTIVATION_BALANCE.The stake is locked and not spendable. Using the
minimum_value_promisemachinery, the registration's value is clear. The actual commitment value may be more however there is no reason to do this as that puts more if the staker's value at risk for no benefit.Validators will scan for these UTXOs (as before) and take note of the balance (
minimum_value_promise). We'll call this the "effective balance" of the validator. This determines the validator's relative voting power for L2 consensus. We cap the effective balance toVN_EFFECTIVE_BALANCE_CAP. This may be equal toVN_MIN_ACTIVATION_BALANCE.Once the
VN_MIN_ACTIVATION_BALANCEis deposited, the validator enters an "activation queue". This queue limits the number of new validators that join the network per epoch to avoid disruptions while nodes sync and catch up to the current committee state.Changes to L2 consensus: We currently consider each vote from a registered validator as equal to any other. To reach quorum, at least $n - f$ / $2f + 1$ votes are required where $n$ is the total number of nodes in a committee. With this change, we'll redefine $n$ as the total effective balance of the committee, requiring > 2/3rds of the total committee effective balance to vote for blocks. For functioning nodes, this is very similar to the previous quorum rule. We assume there is some mechanism for punishing nodes (reducing the effective balance) that do not participate or perform their duty to propose blocks, thereby reducing their relative voting power.
Withdrawing Stake / Exiting
We propose a new output type called
ValidatorExitwhich registers the intent to exit from performing validator duties. Once this UTXO is added to the blockchain, the validator enters an "exit queue". This exit queue limits the number of validators that can exit per epoch in order to avoid large changes to the active validator set, leading to disruptions. The exact epoch that the validator is removed from the active validator set can be determined from the current exit queue and the number of exits per epoch - we may want to also account for the number of VN's entering the active set too.ValidatorExitUTXOs:VN_EXIT_UTXO_LOCK_HEIGHTOnce a VN has exited as per the queue, the validator node registration UTXO is unlocked/becomes spendable. Each base node must maintain a list of the active validators and keep track of requested entries and exits. Amongst other things, this is used to prevent premature spending of validator node registrations. Once and entry/exit comes into effect the validator Merkle tree must be updated accordingly.
Punishment
Proof of Committee Liveness
Fees