Skip to content

Final Atomic Commit + No-DoS Staging Semantics v1 (TKT-P3-56)

Status: later-research planning freeze (no implementation in this ticket)
Issue: #85
Depends on: spec/proof-work-staging-chunk-accumulator-v1.md (#86)

1. Purpose

Freeze the final atomic commit rule and no-DoS semantics for multi-transaction proof-work staging.

This note defines staging safety semantics only. It does not implement the staging lane.

2. Model C + Scope Discipline

This note is explicitly Model C aligned:

  • direct self-sovereign spend remains the base path
  • staged/aggregation-style paths are optional and later
  • no mandatory aggregator dependence is introduced
  • no shared global bottleneck is assumed

This note does not widen current frozen execution scope.

3. Boundary Constraints (Applied Here)

  • no ABI widening in this ticket
  • no lane widening in this ticket
  • no protocol redesign beyond staging-semantics clarification
  • no confidential state mutation during proof-work staging

4. Final Atomic Commit Rule (Authoritative)

4.1 Rule

Only the final commit transition MAY mutate confidential state.

Any preparatory staging transaction MUST be non-mutating with respect to confidential state cells.

4.2 Preconditions for final commit eligibility

A final commit is eligible only if all are true:

  1. a staging session is open and non-expired,
  2. staged chunks satisfy canonical ordering and accumulator rules from #86,
  3. the provided final accumulator equals the deterministic terminal accumulator for the session,
  4. no session-invalidating conflict marker (expiry/reclaim/restart) has been applied.

If any precondition fails, final commit MUST fail closed.

5. Session Lifecycle Semantics

5.1 Session model

A staging session is identified by (artifact_id32, session_nonce32) and has states:

  • OPEN: chunks may be staged
  • COMMITTABLE: all required chunks staged with valid final accumulator
  • EXPIRED: deadline passed without valid final commit
  • RECLAIMED: owner/authorized path reclaimed staging resources after expiry
  • FINALIZED: final atomic commit succeeded

Transitions outside this state machine MUST fail closed.

5.2 Expiry

Each session MUST carry an explicit expiry condition (height- or time-window policy defined by implementation lane).

After expiry:

  • staging append operations MUST reject,
  • final commit MUST reject,
  • reclaim path MAY execute.

5.3 Reclaim

Reclaim semantics MUST:

  • be available after expiry,
  • release staging resources without mutating confidential state,
  • mark the session as terminal (RECLAIMED).

5.4 Restart

Restart requires a new session_nonce32 and MUST NOT reuse a terminal session state as active.

A restarted session MUST re-establish accumulator progression from its own acc_0 seed.

6. No-DoS / Anti-Griefing Semantics

6.1 Non-blocking principle

Incomplete or abandoned staging work MUST NOT block honest progress on direct-spend baseline paths.

6.2 Required anti-grief properties

  1. incomplete staging cannot force perpetual lockup of confidential state mutation rights,
  2. stale sessions cannot be revived after terminal transitions,
  3. reclaim/restart paths are deterministic and bounded,
  4. staging resource growth must be bounded by explicit policy limits,
  5. honest actors can resume with fresh session nonce without global coordination.

6.3 Shared-pool prohibition in this note

This semantics freeze does not require a shared advancing pool and does not assume a mandatory shared coordination market.

7. Adversarial Mutation Cases (Must Reject)

caseId Adversarial attempt Required result
AC-01 staging tx attempts confidential state mutation reject
AC-02 final commit references non-terminal/incorrect accumulator reject
AC-03 final commit attempted after expiry reject
AC-04 duplicate final commit for same terminal session reject
AC-05 append chunk after FINALIZED / RECLAIMED / EXPIRED terminalization reject
AC-06 restart attempt reuses terminal session nonce reject
AC-07 reclaim attempted before expiry reject

8. Implementation-Cut Guidance (Do Not Implement Here)

Future implementation tickets should separate into:

  1. state-machine enforcement and terminal-transition tests,
  2. expiry/reclaim wiring and bounded-liveness tests,
  3. duplicate/stale session rejection corpus.

9. Explicit Non-Goals

This ticket does not:

  • define chunk/accumulator byte formats (already #86)
  • implement staged execution transactions
  • replace direct-spend baseline with staged workflow
  • define aggregation market economics
  • introduce public launch claims

10. Acceptance Mapping (#85)

  • Final atomic commit rule: section 4.
  • Expiry/reclaim/restart semantics: section 5.
  • Incomplete-work safety / no-DoS: section 6.
  • Adversarial mutation cases: section 7.
  • No protocol-boundary widening: sections 2 and 3.