Skip to content

feat(web): expose stateless transaction sync - #500

Merged
WiktorStarczewski merged 5 commits into
0xMiden:mainfrom
0xrouss-miden:pablo/rpc-sync-transactions
Oct 23, 2026
Merged

WiktorStarczewski merged 5 commits into
0xMiden:mainfrom
0xrouss-miden:pablo/rpc-sync-transactions

Conversation

@0xrouss-miden

@0xrouss-miden 0xrouss-miden commented Oct 21, 2026 •

Copy link
Copy Markdown
Contributor

Expose RpcClient.syncTransactions(blockFrom, blockTo, accountIds) so Node.js relayers and browser clients can find included transactions without creating a MidenClient or local store.

The shared Rust binding reuses the existing RPC pagination and account chunking, scans duplicate account IDs once, and rejects returned records outside the requested inclusive range. RpcTransactionRecord exposes the transaction ID, executing account ID, and inclusion block. All entry points and consumer documentation cover the API, cursor ownership, browser wrapper consumption, chain-tip bound, and RPC trust assumption.

Validation:

  • make lint, make test (2,499 tests), and all coverage gates passed.
  • Native RPC suite: 4 passed; Chromium/WebKit RPC suite: 16 passed, using local protocol fixtures.
  • ST and MT WASM builds passed with MIDEN_FAST_BUILD=true; public binding/type checks and packaged agent docs passed.
  • Both range-validation and duplicate-account regressions failed before their fixes; mutation checks confirmed that removing each semantic guard reproduces its expected failure and restoring it passes.
  • Read-only testnet validation confirmed the API can find an exact known transaction ID in its inclusion block.

Closes #498.

@github-actions

github-actions Bot commented Oct 21, 2026 •

Copy link
Copy Markdown

➖ WASM proving — No significant change (largest prove / consume / ecdsa-k256-keccak +0.74%, floor ±1.90%)

Head 3bb775c
Base 42254ee (main)
Method mean of per-rep fastest, 6 reps × 3 warm proves, release / mt, 8 threads on warp-ubuntu-latest-x64-8x — lower is better
Workload 1 benchmark (ms) — prove / consume / ecdsa-k256-keccak
Benchmark Base (ms) Head (ms) Δ Δ %
➖ prove / consume / ecdsa-k256-keccak 2,502.3 2,520.8 +18.5 +0.74%
Methodology and raw samples
  • The timed interval is the proveTransaction call on a client constructed without a web worker. Prover construction, transaction execution, the faucet draw and the production worker round-trip are outside it, so a change confined to any of those does not move this number.
  • The run configuration below — runner, profile, variant, thread count, repetition and prove counts — is reported by the benchmark job, which runs from this pull request's own code. It describes what that job says it did. Every figure and every verdict above is recomputed here from the raw samples.
  • Each benchmark keeps 6 reps × 3 warm proves on warp-ubuntu-latest-x64-8x (8 threads, release / mt). One extra repetition and the first prove of every page run first and are discarded.
  • The reported figure is the mean of each repetition's fastest prove. Within one repetition every prove is bit-identical work, so interference — which only ever adds time — is all that varies, and the repetition's fastest prove is its best observed warm prove — a lower-tail statistic, not a measured "clean" cost, and so blind to a regression that leaves the best case alone (see the mean cross-check). Across repetitions the faucet differs, which shifts the proof-of-work grind, so averaging the per-repetition minima shrinks that lottery — it averages the grind down rather than cancelling it, because each side draws its own.
  • Measured over six calibration runs of identical binaries, this estimator holds a standard deviation of 1.79%, against 2.96% for a global minimum and 5.39% for a plain median.
  • A movement is only called significant when it clears the noise floor and no repetition's paired difference contradicts the direction, with a majority of repetitions positively agreeing. Base and head run interleaved within a repetition, so the pairs saw the same machine; a movement whose repetitions disagree is reported as unresolved rather than as a result. Runs shorter than 6 repetitions are never called significant — the floor is calibrated at that count and does not transfer below it.
  • Base and head are driven one prove at a time, alternating, with the order flipped every prove. Running each side's batch back to back let the second side pay a consistent penalty — measured at +1.19% before this was fixed, which is a bias no number of repetitions removes.
  • A wide gap between the reported figure and the max has two causes and the samples below do not separate them: interference within a repetition, and the proof-of-work grind differing between repetitions. Neither invalidates the comparison — both sides ran interleaved on the same machine — but a gap much wider than usual is worth a second look.
  • Base and head are measured in the same job on the same runner, so runner-to-runner drift cancels out. The base dist may have been built by an earlier run of this workflow and restored from cache — the cache key covers the toolchain and the build commands, so the bytes match what this run would have produced.
  • Δ % = (head − base) / base on that figure. Lower is better for every benchmark in this suite.
  • Every figure above is recomputed here from the per-rep samples in the artifact; the summary statistics the bench script reported alongside them are not used.
  • The ±1.90% threshold is calibrated on warp-ubuntu-latest-x64-8x (2026-08-27): 30 runs of one build against a copy of itself, at 6 repetitions, gave a standard deviation of 0.62% and a largest movement of 1.17%. It is 3σ (1.85%) rounded up, which here is the procedure rather than a deviation from it: the largest movement across those 30 no-change runs stayed below 3σ, so nothing observed argues the tail is heavier than normal. How this is measured.
  • Full machine-readable results are attached to the run as results.json.

Per-rep samples

  prove / consume / ecdsa-k256-keccak
  base rep  1: 2,578.1, 2,584.7, 2,526.9
  base rep  2: 2,584.1, 2,488.5, 2,527.1
  base rep  3: 2,479.9, 2,463.1, 2,493.6
  base rep  4: 2,588.2, 2,618.9, 2,492.3
  base rep  5: 2,513.7, 2,698.2, 2,636.2
  base rep  6: 2,570.4, 2,529.0, 2,664.1
  base median 2,549.7 ms  min 2,463.1  max 2,698.2
  head rep  1: 2,621.1, 2,539.1, 2,514.1
  head rep  2: 2,608.5, 2,775.1, 2,620.6
  head rep  3: 2,538.7, 2,465.3, 2,459.8
  head rep  4: 2,580.7, 2,497.5, 2,479.7
  head rep  5: 2,591.4, 2,510.6, 2,546.2
  head rep  6: 2,631.0, 2,555.2, 2,552.1
  head median 2,549.2 ms  min 2,459.8  max 2,775.1

🔺 slower beyond the noise floor · 🔻 faster beyond the noise floor · ❔ no verdict — see the heading and notes above · ➖ within the noise floor


Generated by bench run 39878228814 for 3bb775c. This comment is informational only and never blocks merge.

@0xrouss-miden 0xrouss-miden left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed by review-council

Review summary

Tip

No code-review blockers remain; both P2 findings are fixed. All 12 required CI checks and local gates passed; additional CI jobs were still pending at the final check.

5 panels · 2 findings: 2 fixed, 0 for you, 0 rejected · gates 12/12 required CI checks passed; 2,499 unit tests and 20 RPC binding tests passed; all four coverage gates passed; additional CI jobs pending
Panel: GPT-6.1 Sol · GPT-6 Luna · GPT-6.1 Sol (repeated CLI seat), each at maximum effort

Decisions for you

  • None.
Decisions in detail

No decisions remain.

Fixes (2 commits)
Severity Fix Commit
P2 F1: Reject transaction records outside the requested inclusive block range instead of returning malformed node results. fdff1f20
P2 F2: Deduplicate account filters before pagination so repeated IDs do not repeat RPC scans or returned records. c2de5c4a
Verified sound
  • The shared Rust binding retains the pinned RPC client pagination, account-list chunking and account-ID verification, while exposing transaction IDs, account IDs and inclusion blocks without local storage.
  • Both semantic fixes have owner-boundary regressions that failed before the fix, passed afterward, failed when the corresponding guard was removed, and passed again after restoration.
  • Native and browser bindings, eager/lazy ST/MT exports, TypeScript declarations and consumer documentation agree on the API, inclusive range, cursor ownership, RPC trust assumption and browser wrapper consumption.
  • Final verification found no further defects in correctness, security/state/API, concurrency/resources/performance or regression coverage.
Coverage
  • Five completed panels: simplicity, risk discovery, full adversarial review, fix-plan review and a fresh four-bundle verification panel after both fixes.
  • Actual roster is OpenAI-only at xhigh effort, with two independent GPT-6.1 Sol seats and one GPT-6 Luna seat; Claude was unavailable and Gemini failed its preflight probe, reducing provider diversity.
  • An incomplete simplicity assignment and an incomplete plan assignment were each replaced once with a valid completed review; 13 reviewer calls completed across 15 attempts.
  • Local gates on the final code: make lint; make test (121 files, 2499 tests); all coverage thresholds; 4 native RPC tests; 16 Chromium/WebKit RPC tests; ST/MT fast WASM builds; four binding/type checks; packaged agent-doc verification.
  • Mutation checks pinned the two semantic production hunks while keeping regressions, prose and behavior-preserving refactors fixed. An initial native mutation run was inconclusive because Cargo reused a stale artifact; refreshing source mtimes made the repeated measurement pass.
  • Required GitHub checks are 12/12 green on c2de5c4. Additional automatic CI jobs were pending at the final check and are not represented as passed.

Reviewed by review-council, an independent multi-model review panel. Every finding was checked against the source before it was fixed or reported. 2026-10-21

@WiktorStarczewski WiktorStarczewski left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed by review-council

Review summary

Tip

No code findings; all required current-head CI checks passed. No author decisions remain. The 45 reported checks include 39 successful, 5 skipped, and 1 neutral result.

3 panels · 0 findings: 0 fixed, 0 for you, 0 rejected · gates Current PR head: 39 successful, 5 skipped, 1 neutral checks; 918 unit tests, 238 Node.js Playwright tests, 2 native RPC contract tests, and 44 sync/state integration tests passed.
Panel: GPT-6 Luna · GPT-6 Luna · GPT-6 Luna · GPT-6 Luna, each at maximum effort

Decisions for you

  • None.
Decisions in detail

No decisions remain.

Fixes (0 commits)
Severity Fix Commit
- No fixes required -
Verified sound
  • The shared RPC binding checks returned records against the requested inclusive block range.
  • CI passed coverage for empty-page advancement and duplicate account chunks, along with the browser RPC integration shard.
Coverage
  • Panels: simplicity, risk discovery, final verification; four GPT-6 Luna seats per panel at xhigh.
  • Only the OpenAI lab was available, so panel diversity was reduced.
  • Current-head checks: 39 successful, 5 skipped, 1 neutral; measured test suites passed.

Reviewed by review-council, an independent multi-model review panel. Every finding was checked against the source before it was fixed or reported. 2026-10-23

@WiktorStarczewski
WiktorStarczewski merged commit 417fffc into 0xMiden:main Oct 23, 2026
45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose SyncTransactions in the TS/Node RpcClient

2 participants