Skip to content

chore(port): forward-port v5-next pxe/client/txe backlog to next#24932

Draft
PhilWindle wants to merge 7 commits into
nextfrom
port-v5-pxe
Draft

chore(port): forward-port v5-next pxe/client/txe backlog to next#24932
PhilWindle wants to merge 7 commits into
nextfrom
port-v5-pxe

Conversation

@PhilWindle

@PhilWindle PhilWindle commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

Forward-ports the pxe / client / txe slice of the v5-next → next backlog (work merged to v5-next after the ~2026-07-08 cut that reshaped next).

Applied (clean cherry-picks, chronological)

⚠️ Needs owner conflict-resolution (conflict against reshaped next; not included here)

Cherry-pick onto this branch and resolve:

Part of the manual v5-next → next backlog sweep. Draft until conflicts are resolved and CI is green.

Added after review

mverzilli and others added 6 commits July 23, 2026 11:02
While trying to deploy the latest nightly standard contracts to testnet
I experienced gas estimation issues.

According to Claude these issues are due to variability in Merkle tree
insertions: there's around 40% of gas cost spread between the happiest
case (no tree "climbing" needed) and the worst case (10 level climb).

If eth_estimateGas occurs during the happiest case, and actual TX
execution during the worst case, the default 20% buffer we use in
Aztec.js turns out not to be sufficient.

Closes F-794

(cherry picked from commit 2734da1)
First part of integrating the enhancements explored at
aztec-labs-eng/oxide#257

Closes F-808

(cherry picked from commit 8a3f7e6)
Some stores were being accessed without checking if the associated
accounts were in scope or not. For logs I added this to the service, but
we're not yet consistent in how we use services (call-lived, tx-lived?)
so in other cases it is just inlined in the oracle.

(cherry picked from commit ce12e29)
Additions to the README on gas and fees

(cherry picked from commit 4d53a9f)
…evidence (#24655)

Fixes the sender tag sync conflict from
https://gist.github.com/nventuro/0aa690736b1d2865e27197723a814e9d,
including the "Window straddle" residual edge.

Discovery could re-derive a different index range for an already tracked
(secret, txHash) pair and hit the `Conflicting range` throw in
`storePendingIndexes`, permanently wedging the secret. Two triggers:

- A same-PXE tx partially reverts: the chain only shows the surviving
non-revertible sub-range of the prove-time entry, and the throw fired
before the finalized receipt step could resolve it.
- A tx straddles a sync window boundary: the window loop assembles its
range piecewise, so window 2 stores a different range than window 1
(latent regardless of reverts).

Fix: discovery passes `mergeExisting` to `storePendingIndexes`, which
widens the stored entry to the union of both ranges (grow-only, driven
by onchain evidence). The finalized receipt step still resolves partial
reverts. The only other writer of pending ranges,
`persistSenderTaggingIndexRangesForTx` (records the indexes a tx sent
from this PXE used, at prove time), does not pass the flag and still
throws on a mismatch: there it indicates a bug, not partial onchain
evidence.

Red-green (all fail on the base with the `Conflicting range` throw):
- partial revert repro: finalizes the surviving index, frees the
squashed ones, repeat sync is a no-op
- cross-sync widen: an entry tracked from an earlier sync grows when
discovery evidences further indexes
- window straddle: drives the actual window advance loop, asserts per
window queried tags and that the widened entry later finalizes cleanly

Store-level tests pin the union semantics: a sub-range keeps the entry,
a range beyond it widens it, an untracked tx still stores.

(cherry picked from commit fd7515d)
This fixes a scoping bug where an account's ivsk would be used to
produce an ECDH shared secret even if that account was not in scope. The
base wallet class was adjusted to put these in scope when an explicit
sender is selected for tagged messages.

(cherry picked from commit 4994006)
@PhilWindle PhilWindle added ci-draft Run CI on draft PRs. ci-no-squash labels Jul 23, 2026
waitForNode called retryUntil without a timeout, and retryUntil treats a
zero timeout as the never-time-out sentinel, so an unreachable node caused
the call to poll getNodeInfo forever with no way for the caller to bound it.

Add an optional { timeout, interval } argument and default it to
DefaultWaitOpts (300s / 1s), matching the sibling waitForTx. An unreachable
node now rejects with a TimeoutError; pass timeout: 0 to opt into the
previous infinite-wait behavior.

(cherry picked from commit 482a6b8)
@nchamo nchamo self-assigned this Jul 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci-draft Run CI on draft PRs. ci-no-squash

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants