chore: re-add execution of network transactions and add expiration#2148
chore: re-add execution of network transactions and add expiration#2148SantiagoPittella wants to merge 1 commit into
Conversation
SantiagoPittella
force-pushed
the
santiagopittella-ntx-builder-block-sub-phase-3
branch
from
8b4366b to
b446bbd
Compare
| long = "tx-expiration-delta", | ||
| env = ENV_TX_EXPIRATION_DELTA, | ||
| default_value_t = DEFAULT_TX_EXPIRATION_DELTA, | ||
| value_parser = clap::value_parser!(u16).range(1..), |
There was a problem hiding this comment.
You could make this a NonZeroU16
| /// Returns `true` if every one of `nullifiers` for `account_id` has been marked consumed | ||
| /// (`committed_at IS NOT NULL`), i.e. the actor's submitted transaction has landed in a committed | ||
| /// block. An empty `nullifiers` slice trivially returns `true`. |
There was a problem hiding this comment.
Interesting approach. iiuc this works by virtue of the actor being the only possible consumer of these notes.
This is technically not true though; because I think they can be recalled for example.
This may be good enough for a first cut at this.
We could also revisit how we perform notifications. One option could be to store the latest N blocks as shared data that actors can access. So an actor waiting on a transaction could count the blocks going by but also inspect their transactions directly.
There was a problem hiding this comment.
Or alternatively, a quicker solution would be to have the coordinator also store the last transaction ID of each account in the account's table. The actor can then pull that. That way we stick with the pure database approach for now, and we can revisit that decision holistically later.
2 participants
Third and final PR of the ntx-builder block-subscription refactor (follows #2120 and #2144). This PR reconnects the execution path so the ntx-builder actually builds and submits network transactions again.
After catch-up, an account actor with pending notes selects a candidate, executes/proves/submits it, then enters a
WaitForBlockstate and detects landing purely from local state. If the transaction doesn't land withintx_expiration_deltablocks, the actor resubmits.Submitted transactions also carry an on-chain expiration: a pre-compiled transaction script (
update_expiration_block_delta) is injected viaTransactionArgs, so a stale tx is rejected by the chain rather than landing late.