LLMSkillHub
mirroredCopied from PlamenTSV/plamen under MIT. PlamenTSV has not claimed this page, and is not affiliated with LLM SkillHub.

plamentsv / consensus-tx-identity-invariants

L1 trigger - audits replay protection, transaction identity binding, and cross-layer uniqueness.

0
SKILL.md
3.1 KB

Injectable Skill: Consensus Tx Identity Invariants

L1 trigger: CONSENSUS flag AND (txid, tx_hash, nonce, sequence, signature, message_id detected across modules)
Inject Into: depth-consensus-invariant, depth-state-trace
Language: Go and Rust
Finding prefix: [TXI-N]

1. Identity Definition

Determine what uniquely identifies a transaction in each layer:

  • explicit nonce / sequence
  • hash of body
  • hash of signed payload
  • envelope ID distinct from execution payload ID

Tag: [TX-ID:DEFINITION]

2. Replay Protection

For every submission path, ask what value changes to prevent replay and whether
it is monotonic, chain-bound, and sender-bound. Flag replay surfaces on the
same chain, across forks, or across layers.

Write the answer as a table:

Tx TypeReplay-unique fieldSender-bound?Chain-bound?Expiry / bound

Tag: [TX-ID:REPLAY]

Mandatory enumeration:

  1. List every signed transaction/message type, not only system
    transactions: user transactions, system transactions, commitments,
    block-level commitments, gossip messages, admin/config messages, and any
    wrapper/envelope format.

  2. For each type, identify the replay guard: nonce, sequence, anchor,
    recent-block hash, expiry, chain ID, domain separator, or explicit consumed
    marker.

  3. If no per-sender or per-message replay guard exists, emit a finding. Do not
    accept "outer EVM signature has chain_id" as sufficient unless the inner
    payload identity and all consensus effects are also covered by that exact
    signature domain.

  4. Check same-chain replay, cross-fork replay, cross-layer replay, and
    re-inclusion after reorg separately.

3. ID / Signature Binding

Verify that the provided ID equals the hash of the signed content and that the
signature covers the exact bytes later used for execution or persistence.

Questions:

  1. Is the ID recomputed by the verifier, or trusted from peer input?
  2. Does the signature sign the same bytes the ID is derived from?
  3. If the ID and signature are derived from different byte domains, can the
    content change while one of them stays stable?

Mandatory binding table:

ObjectClaimed ID fieldRecomputed fromSignature coversPersistence keyMismatch possible?

Apply it to blocks, transactions, commitments, and any included commitment
list. If a block/tx/commitment ID is accepted from peer input without
recomputing it from the signed bytes, emit a finding.

Tag: [TX-ID:BINDING]

4. Cross-Layer Consistency

Trace the transaction through admission, mempool, consensus inclusion,
execution, and indexing. All layers must agree on nonce / chain identifier /
sender identity / canonical ID.

If a wrapper transaction carries an inner transaction or message, verify the
wrapper ID is tied to the inner payload identity instead of being an unrelated
field.

Tag: [TX-ID:CROSS-LAYER]