Skip to content

FROST anchor: retain the handshake attestation as a rollback witness (detection material already exists) #4230

Description

@mswilkison

Summary

Every node already computes and signs a complete anchor rollback witness, under an external challenger's nonce, in its activation-handshake attestation — and nothing retains it across restarts. An external monitor that stores the maximum ever seen per operator would detect a class of rollback that is otherwise structurally undetectable, with no protocol change and no code change on the node.

This came out of the #4222 analysis. Recording it because the detection material is fully built and only the consumer is missing.

What is already exported

The signed attestation carries currentAnchorRevision, stateGeneration, certifiedFloorRevision, certifiedFloorGeneration, trustCertificateSequence, anchorServiceEpoch, both restartable headrooms, anchorRotationWarning, and stateAnchorPoisoned.

Why it matters

The certified floor bounds the anchor service and the signer process. It does not bound the operator — every artifact naming the floor is a local file the operator owns (see the "What the floor does not bound" section added to docs/development/frost-anchor-rotation.adoc in #4226). A colluding anchor service plus a rolled-back operator is undetected by design today, because the node's own durable witness sits in the same store directory as the state it is meant to protect and is rolled back in the same act.

A monitor outside both trust domains, retaining per-operator maxima, is the cheapest thing that notices.

Three monitors, none needing a protocol change

  1. Max-ever-seen per operator on trustCertificateSequence, anchorServiceEpoch and the certified floor pair. A decrease is a downgrade.
  2. Revision-budget reconciliation — compare attested revision growth against what the admission arithmetic predicts. Excess revisions imply a writer other than this node on the stream.
  3. Fleet correlation of stateAnchorPoisoned and anchor errors — simultaneous multi-operator failure is the shared-anchor-instance tell.

A fourth, out of band: compare OnlineKeyHash across operators. Equality reveals a single shared response key, and therefore a single point of acknowledgement forgery.

Scope

No node change required. This is monitoring infrastructure plus a decision about who runs it — which overlaps the open anchor-service tenancy questions in #4222.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions