Summary
Investigate why the Network Transaction (NTX) builder stops consuming notes after some Nth iteration when an account repeatedly produces network notes addressed to itself.
Context
A Finite State Machine (FSM) account was built as a network account that creates a network note addressed to itself. When the note is consumed, it produces a new copy of itself, forming a loop. The FSM account continuously outputs notes to itself which the NTX builder is expected to consume.
Observation: After some number of iterations, the NTX builder stopped consuming the account's notes. The last note created remained committed but was never consumed.
Root cause hypothesis
From initial investigation of the traces, proving appears to have failed or been canceled repeatedly. The NTX builder has a fail-safe that stops re-executing a note if it keeps failing. In this case the failures appear to have been internal (prover outage / network issues / bugs) rather than a genuine problem with the note, but the builder is currently overly conservative — it cannot distinguish between:
- An internal problem (prover outage, transient network issue, code bug)
- A genuine issue with the note (e.g. note requires a specific account state that may never materialize)
So it gives up on the note entirely.
Goals of this research
- Map out — as exhaustively as possible — the scenarios in which the NTX builder decides to stop retrying a note. For each, classify whether the cause is internal vs. external and whether the current behavior is correct.
- Identify which error classes today are misclassified or lumped together, and what additional signal would be needed to distinguish them.
- Evaluate possible mitigations:
- Smarter classification of internal vs. external failures so internal failures don't permanently disable a note.
- Automatic retry with backoff rather than never retrying.
- A "rehydrate" endpoint to let an external party signal that a note should be retried (heavily rate-limited per note to prevent DoS).
- Allowing users to submit NTX transactions directly so they can force progress (with the race conditions this implies).
- Consider the bug-in-prover/bug-in-code case: if a bug causes every attempt to crash the prover, what's the right tradeoff between aggressive retry (which exposes the bug but wastes resources) and conservative giveup (which silently stalls otherwise-valid notes)?
Proposed next steps
- Audit the NTX builder's failure paths and current retry/giveup policy.
- Document the current classification of error types and where it's wrong.
- Propose a concrete design for one or more of the mitigations above to discuss in the next sync.
References
Summary
Investigate why the Network Transaction (NTX) builder stops consuming notes after some Nth iteration when an account repeatedly produces network notes addressed to itself.
Context
A Finite State Machine (FSM) account was built as a network account that creates a network note addressed to itself. When the note is consumed, it produces a new copy of itself, forming a loop. The FSM account continuously outputs notes to itself which the NTX builder is expected to consume.
Observation: After some number of iterations, the NTX builder stopped consuming the account's notes. The last note created remained committed but was never consumed.
Root cause hypothesis
From initial investigation of the traces, proving appears to have failed or been canceled repeatedly. The NTX builder has a fail-safe that stops re-executing a note if it keeps failing. In this case the failures appear to have been internal (prover outage / network issues / bugs) rather than a genuine problem with the note, but the builder is currently overly conservative — it cannot distinguish between:
So it gives up on the note entirely.
Goals of this research
Proposed next steps
References