Nyzo is a constantly evolving democracy. New verifiers are added every two cycles, and verifiers that do not meet the expectations of the cycle are removed.
While a verifier-removal mechanism is necessary for ensuring the health of the cycle, its use should be minimized. Flaws in the consensus process have resulted in large numbers of verifiers being removed from the cycle over short periods of time. Also, there is potential that an attacker could try to gain influence in the cycle by forcing many other verifiers out of the cycle.
There are currently two situations in which a verifier will be removed from the cycle. If a verifier's block is missing, the verifier is skipped and removed after a short delay. If a verifier consistently fails to vote in the consensus process, its block will be rejected.
The second case, forced removal even when a block is available, is deactivated when any verifier has left in the last cycle. The first case, though, does not adjust due to removals.
NTTP-2: we propose increasing the time to wait for a verifier's block if other verifiers have recently left the cycle. If a single verifier has left in the last cycle, the removal delay time will increase from 80 seconds to 10 minutes. With two losses, the delay time will increase to 30 minutes. With three losses, the delay time will increase to an hour. Further losses will not increase the delay time beyond one hour. When a cycle completes with no losses, the delay time will return to 80 seconds.
This would result in hour-long stalls between verifier removals if several verifiers have recently left the cycle. This would cause the frozen edge to fall far behind the open edge, and it would delay the processing of some transactions.
This would also put a much lower limit on the number of verifiers that could be removed in any time period. It would likely allow verifier operators sufficient time to recover their verifiers from a bug or attack that might otherwise cause those verifiers to leave the cycle.
NTTP-2 was approved by the cycle in a cycle transaction from ⛵ Argo 746 (c34a6f1942cb7ec1-0d2a440b3e116041-d05df2746ebe7b41-802340a1495e7af5) to ⛵ Argo 752 (7cd4b6c2bd8316e4-40b0a6affb2c78dc-b5d7fdaa17aae8c6-a9bd45ac10017f9d). If this transaction is not successfully incorporated into the blockchain at block 6,500,001, it will be stored as on-chain metadata to document approval.