Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions CIPs/cip-173.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
---
CIP No.: 173
Title: Fix PoS Dispute Evidence and Stake Locking
Author: Peilun Li (@peilun-conflux)
Status: Draft
Type: Spec Breaking
Created: 2026-07-06
Required CIPs (*optional): 156
---

## Simple Summary

A PoS dispute penalizes a validator that signed two conflicting messages in the same round by locking its stake for six months (CIP-156). Currently the evidence check accepts pairs that prove no conflict — for example, two copies of a single vote — and the lock is skipped entirely for a validator whose stake is already fully unlocking. From a PoS activation view, this CIP accepts a dispute only if both pieces of evidence are signed by the accused validator and are genuinely distinct, and extends the lock to a validator whose stake is entirely unlocking.

## Abstract

A dispute transaction carries two votes or two proposal blocks from the same epoch and round as evidence that a PoS validator equivocated; once accepted, the validator's entire stake is locked for six months (CIP-156). Two bugs weaken this mechanism: the verifier accepts evidence pairs that prove no conflict, and the lock is not applied when the accused validator's stake is entirely unlocking. From a PoS transition view, this CIP requires vote evidence to be two valid vote signatures over `LedgerInfo`s with distinct hashes, proposal evidence to be two `Proposal` blocks signed by the accused validator with distinct block ids, and the dispute lock to cover a validator whose entire stake is unlocking.

## Motivation

The dispute verifier checks each piece of evidence individually but never that the pair conflicts, so two copies of the same vote or proposal qualify as a dispute and an honest validator can lose access to its stake for six months. For proposal evidence, NIL blocks pass with no signature from the accused validator at all, while genuine equivocation evidence is rejected because its committee-signed quorum certificates cannot be verified with the accused validator's key alone.

On the penalty side, the CIP-156 lock is skipped for a validator with no locking or locked votes, so a validator that retires all its votes after equivocating recovers its stake on the normal unlocking schedule instead of six months later.

Dispute handling mutates the PoS state on every node, so the fixes require a coordinated activation.

## Specification

### Parameters

`POS_DISPUTE_FIX_TRANSITION_VIEW`: the PoS view at which this CIP activates. This is a view of the PoS chain, not a PoW block height: the rules apply when the view of the PoS state processing the dispute is at least this value.

### Dispute evidence

From the activation view, a dispute transaction is valid only if the accused address matches the payload's public keys and:

- **Vote evidence**: both votes decode, vote for a block of the same epoch and round, and pass signature verification against the accused validator's key; and the two signed `LedgerInfo`s have distinct hashes.
- **Proposal evidence**: both blocks decode and carry the same epoch and round in their block data; both are `Proposal` blocks authored by the accused validator, each with a valid proposer signature over its block data; and the two block ids (the hash of the block data) are distinct. The embedded quorum certificates are not verified.

A dispute transaction failing these checks is rejected at execution; one validated at a view below the transition view follows the previous rule.

### Stake locking

A dispute-triggered relock covers all of the accused validator's locking, locked, and unlocking votes. From the activation view, the relock triggers whenever any such votes exist; below it, only locking or locked votes trigger it, so a validator whose votes are all unlocking is not relocked.

## Rationale

Distinctness is judged on the message the validator signed — the `LedgerInfo` hash for votes, the block id for proposals — rather than on the submitted evidence bytes, so a single vote re-encoded (for example, with its optional timeout signature attached) does not count as equivocation.

## Backwards Compatibility

This is spec breaking for PoS nodes.

## Test Cases

Test cases for the evidence rules are provided in conflux-rust PR [#3534](https://github.com/Conflux-Chain/conflux-rust/pull/3534).

## Implementation

Reference implementations: conflux-rust PRs [#3524](https://github.com/Conflux-Chain/conflux-rust/pull/3524) (stake locking) and [#3534](https://github.com/Conflux-Chain/conflux-rust/pull/3534) (evidence rules).

## Security Considerations

The evidence rules close a path by which an honest validator's stake could be locked without misbehavior — an accepted dispute now proves the accused validator signed two distinct messages in the same round — and make genuine proposal equivocation disputable, since evidence no longer fails on its committee-signed quorum certificate. The stake-locking rule closes the escape where a validator retires its votes after equivocating and exits on the normal unlocking schedule, restoring the six-month deterrent of CIP-156.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).