perf(pxe): derive sender tagging finalization from log blocks - #25033
Merged
Merged
Conversation
The sender tagging sync fetched a receipt for every pending tx in a window. The block a log sits in already says whether its tx is finalized, so a window now usually resolves from its logs query alone. Receipts are fetched only for the txs the logs cannot settle: those absent from the window, and those whose highest tracked index is missing onchain.
…/optimize-sync-rpc-calls
nchamo
marked this pull request as ready for review
July 28, 2026 19:14
…/optimize-sync-rpc-calls
nchamo
enabled auto-merge (squash)
July 29, 2026 03:04
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
nchamo
pushed a commit
that referenced
this pull request
Jul 29, 2026
… — backport to merge-train/fairies-v5 (#25045)
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
We are trying to reduce the RPC calls PXE makes to nodes. We are starting with one of the most common workflows, which runs every time a user sends a message.
How it works now
Before sending a message for a secret, PXE has to pick the next tagging index to use. It queries the node for the logs of a window of tags, starting just above the highest finalized index. It then calls the node again once per pending tx in that window to read its receipt, which includes txs that no log surfaced, such as the ones this PXE sent earlier. A receipt reporting the tx as finalized is what lets us advance the highest finalized index.
The change
A log already carries the block it was mined in, so we no longer need to ask the node about its tx. We compare that block against our locally synced finalized tip instead, and a window whose logs settle every pending tx now costs a single query.
We still fetch receipts for the txs the logs cannot settle. A tx absent from the window needs one to say whether it is still in the mempool or was dropped. A tx whose highest tracked index is missing onchain partially reverted, and only its tx effect tells us which of its tags survived.
One behavior changes. Logs are queried per secret, so finalizing from them advances only the secret being synced, while a receipt covers the whole tx. A tx that also carried logs for another secret keeps its entry there until that secret syncs on its own.
Metrics
Ran the client flow benchmarks on the base commit and on this branch. Every call we save is a receipt fetch.
getTxReceiptdrops from 35 to 23, which takes the total from 226 to 214, and no other RPC method moves.Per flow, the savings land on the transfers, which are the flows that emit private logs. The
private_fpcvariants gain the most because paying through a private FPC means a second private transfer.getTxReceipttransfer_1_recursions+private_fpctransfer_0_recursions+private_fpctransfer_1_recursions+sponsored_fpcamm_add_liquidity_1_recursionstoken_bridge_claim_privatestorage_proof_7_layersThe unchanged flows are the control: they show the change does nothing to workflows that do not send private logs.