§1Model and assumptions#
| Assumption | If it breaks |
|---|---|
| Less than one third of voting power is Byzantine | Conflicting blocks could finalize |
| One validator set per height; keys are authenticated | Certificates become ambiguous |
| Signing storage is durable, unshared, and never rolled back | A validator can equivocate after a restart |
| Messages are eventually delivered and an honest proposer eventually wins | Progress stalls; safety is unaffected |
| Validator clocks are NTP-disciplined | Slot timing drifts. Skew is detected and alerted, not corrected |
The slot scheduler runs at a fixed interval; it is not an adaptive partial-synchrony pacemaker. Liveness under partitions and high latency is therefore measured rather than assumed. See load qualification.
§2Parameters#
| Parameter | Value | At the 2 s target |
|---|---|---|
| Slot duration | 2 s | |
| Slots per epoch | 192 | 384 s |
| Rounds per slot, maximum | 3 | |
| Active validators, maximum | 128 | |
| Minimum validator stake | 10,000 RSC | |
| Unbonding period | 14 epochs (2,688 slots) | about 89.6 min |
| Downtime participation window | 300 committed blocks | about 10 min |
| Double-sign slash | 5% (500 basis points) | |
| Downtime slash | 0.1% (10 basis points) | |
| Forced evidence-inclusion deadline | 32 slots | about 64 s |
| Evidence lifetime | 2,688 slots | about 89.6 min |
| Evidence per block / pending queue | 128 / 512 |
The Kubernetes template uses 1 s slots with 64-slot epochs, and the test harness 1 s with 32. These are different consensus profiles. A network qualifies one exact profile, and none of these values may change on an initialized database.
§3Views, locks and certificates#
At a fixed height, views are ordered by (slot, round). A validator precommits a block only after fully validating it and seeing more than two thirds of active voting power prevote that exact block in the current view. It writes the lock and the certificate to disk before releasing the precommit signature. A failed write or a corrupt record stops voting rather than clearing the lock.
- A locked validator prevotes its locked block, or a conflicting block only if it carries such a certificate.
- A locked proposer re-proposes the original block unchanged: same hash, author signature, timestamp and state commitments. It signs a fresh envelope for the new view.
- Finality signatures carry their slot and round. Verifiers reject mixed views, views earlier than the block's proposal, duplicate signers, and insufficient power. Quorum counts voting power, not signatures.
- Sync import accepts a block finalized in a later view than the one it was created in.
§4Secret leader election#
Each validator privately evaluates the RFC 9381 ECVRF with its own key over the view input
alpha = head.Randomness ‖ slot (8 bytes, big-endian) ‖ round (4 bytes, big-endian)It may propose only if BE64(output[:8]) mod totalVotingPower falls inside its own stake window. The winner publishes the 80-byte proof and 32-byte output in the block header, so one evaluation is both the lottery ticket and the next randomness beacon.
- Secret. Outcomes depend on secret keys, so no observer can derive the schedule from the public head. This removes advance targeting of the next proposer by denial of service or bribery.
- Probabilistic. A round may have no winner, and every validator times out and advances. It may have several, and the first valid proposal wins while the BFT rounds absorb the race. Empty rounds depend on secret keys, so they leak no lookahead.
- Re-proposals carry a leader claim (winner, proof, output) that is bound into the envelope signature.
- Suite. ECVRF-EDWARDS25519-SHA512-TAI. Try-and-increment is safe here because the VRF input is public, so its input-dependent running time leaks nothing.
A winner sees its output before publishing and can withhold its block, which turns a fair coin into a 3/4 coin. That is why contracts cannot read the beacon. A threshold beacon is proposed.
§5Signing domains#
| Message | Construction |
|---|---|
| Block header, by its author | Ed25519 over ASCII RESILIENCE_BLOCK_HEADER_V1 followed by the 32-byte header hash; 58 bytes, no terminator or length prefix |
| Prevote and precommit | Keccak-256 of RESILIENCE_CONSENSUS_VOTE_V2 ‖ type ‖ slot ‖ height ‖ round ‖ block hash |
| Proposal envelope | 32-byte digest of the genesis-bound view, block hash, certificate and leader claim |
| VRF proof | The RFC 9381 construction, separate from all of the above |
The signer interface exposes only header and vote signing, each over a 32-byte input, with no general message-signing method. Local, encrypted-keystore and remote signers produce identical signatures, and the remote signer enforces its own watermarks. The remote-signer custody path has an open internal finding; see Assurance.
§6Evidence and slashing#
Correct builders include every provable, unexpired pending evidence item, oldest offense first, up to 128 per block, and blocks must carry evidence in that canonical order. Validators enforce timely inclusion by withholding votes from fresh proposals that omit evidence they have held for more than 32 slots.
Omission is punished at vote time instead of at validity: validators withhold their votes from a fresh proposal that omits evidence they have held past the deadline. Censorship therefore fails whenever more than one third of voting power holds the evidence, because the censoring block cannot reach quorum.
Omission is deliberately not a validity rule, because honest nodes can hold different pending sets and rejecting their blocks would fork them. Locked re-proposals are exempt, since their body cannot change. If a node cannot evaluate the rule, it votes normally: withholding is a preference, never a safety mechanism.
§7Epochs and the validator set#
The validator set changes only at epoch boundaries, so a successful stake action does not mean immediate participation. Rewards depend on participation and on time-weighted delegation. A restarting node must rebuild exactly the same set. Jailing for downtime follows the signed ratio within a participation window of 300 committed blocks, not a count of consecutive misses.
§8Open limits#
- Slot time is a target, not a bound on finality.
- Light clients trust the validator set on first contact until out-of-band anchor pinning is implemented.
- If more than one third of voting power is eclipsed from the evidence, inclusion can be delayed until the evidence expires.
- Measured liveness under sustained load is the binding constraint today. See Assurance.
Sources: internal/consensus/engine.go, locking.go, leader.go, importer.go, evidence_force.go; crypto/ecvrf.go, crypto/validator_signing.go; configs/config.toml; consensus/BFT threat model 0.3.0.
Cite this page
@misc{resilience-protocol-consensus,
title = {{Consensus and finality}},
author = {{Resilience Network}},
year = {2026},
note = {Reference implementation c3acec4, protocol manifest r28},
url = {https://resiliencenetwork.xyz/protocol/consensus/}
}