feat: merge-train/fairies-v5#24530
Merged
Merged
Conversation
SQLite3MultipleCiphers 2.3.5 (#24293) stopped shipping the bundler-friendly build variant, so the package entry re-exports the plain sqlite3.mjs. That loader always resolves sqlite3.wasm through its Module['locateFile'] hook, which computes new URL(path, import.meta.url) with a dynamic path — invisible to bundlers. Bundled consumers (e.g. Vite apps using @aztec/kv-store/sqlite-opfs) request an unhashed sqlite3.wasm relative to the emitted chunk and 404 at runtime; dev servers are unaffected, so only production builds break. Wrap the init and inject emscriptenLocateFile (the vendored loader's supported escape hatch= resolving the wasm via a static `new URL('../vendor/jswasm/sqlite3.wasm', import.meta.url)` that bundlers detect, emit, and rewrite. Unbundled usage is unaffected: the static URL resolves to the real vendored path. Verified by building a Vite consumer against the patched dest/: the emitted worker chunk resolves the hashed wasm asset through the hook. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…24511) ## Summary - Renames the HandshakeRegistry's `get_handshakes` utility to `get_non_interactive_handshakes`: it only returns handshakes discovered from non-interactive announcement logs, so interactive handshakes (#24473) never appear in it, and the name should say which kind it returns. - Sweeps the rename through the aztec-nr selector constant, the registry's internal reader, the PXE default-authorization allowlist, and tests, and documents the getter's privacy properties (any contract can read a scope's discovered handshakes; ephemeral keys don't reveal the shared secret). - Re-pins the standard contracts, since the registry's artifact changes. Stacked on #24483. Fixes F-769 --------- Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>
…E_LOGS_PER_TX + headroom, not exactly MAX_PRIVATE_LOGS_PER_TX (#24437) ## Summary Follow-up to #24429. That PR widened `UNFINALIZED_TAGGING_INDEXES_WINDOW_LEN` from `20` to exactly `MAX_PRIVATE_LOGS_PER_TX` (64). This PR argues that's still not the right value for the scenario #24429 was trying to fix, and proposes `MAX_PRIVATE_LOGS_PER_TX + 20`. **Scope note (see "Known limitation" below):** this fixes a real, CI-confirmed problem; multiple ordinary pending txs to the same counterparty stacking up before the first is mined. There is a separate, harder problem captured in [F-783](https://linear.app/aztec-labs/issue/F-783/pxe-unfinalized-tagging-indexes-window-len-cannot-bound-a-squash-heavy). Additional separate breakage follow-up on the sender-side when pending logs exceed the window [F-784](https://linear.app/aztec-labs/issue/F-784/pxe-typed-error-and-resync-recheck-when-pending-tagging-indexes-exceed). ## Investigation `MAX_PRIVATE_LOGS_PER_TX` is a genuine, protocol-enforced bound for ordinary transaction patterns: `noir-protocol-circuits` `constants.nr` defines `MAX_PRIVATE_LOGS_PER_TX` directly as `MAX_NOTE_HASHES_PER_TX`. A fresh secret's very first ordinary tx can legitimately consume that many indexes before anything is finalized. But exactly `MAX_PRIVATE_LOGS_PER_TX` leaves zero headroom for a second unconfirmed tx to the same counterparty once the first one is already near the max. `finalized` only advances once the sender's own node observes a tx as mined (see `syncSenderTaggingIndexes`), so any burst of sends to one counterparty before the first is mined can exhaust the window. This is exactly what happened in #24429's `bench_build_block` failure: `#24387`'s handshake default added extra per-cold-chain overhead, and the bench builds up a backlog of unmined txs by design, so `used` ran past `finalized` (which stayed at `0`) before window `20` could absorb it. ## Confirmed live: reproduced on this branch at bare `20` To settle whether #24429's bump was actually necessary, we reset this branch's constant back to bare `20` and let `bench_build_block` run to completion in CI rather than relying on the reasoning above alone. It failed the same way (see http://ci.aztec-labs.com/4ed074af4b8ab633 from [a4feea1](a4feea1), on the current `merge-train/fairies-v5` tip: ``` ERROR: kv-store:lmdb-v2 pxe-0 Failed to commit transaction: Error: Highest used index 21 is further than window length from the highest finalized index 0. Tagging window length 20 is configured too low. Contact the Aztec team to increase it! ``` So this isn't a synthetic worst case: it's a real failure on real CI infrastructure, at index `21`, i.e. just one past the window. Not even a large burst of txs. ## Red/green evidence Added `sender_tagging_store.test.ts`: "allows an ordinary pending tx to stack on a fresh secret already at the `MAX_PRIVATE_LOGS_PER_TX` floor" — one tx uses the full worst-case 64-log burst from a fresh secret, then a second, ordinary-sized pending tx to the same secret must still be storable before either is mined. - **Red at bare `20`:** the *first* call in that test already throws, with zero other txs involved: ``` Highest used index 63 is further than window length from the highest finalized index 0. Tagging window length 20 is configured too low. ``` - **Green at `MAX_PRIVATE_LOGS_PER_TX + 20`:** same scenario passes. This is the key point for review: the `bench_build_block` failure isn't just "risky under bursty load".`20` is mathematically incapable of tolerating even one legitimate worst-case single ordinary tx, independent of what CI on this branch shows either way. CI passing at `20` only means our current test/bench suite doesn't happen to construct a single tx tagging more than 20 logs to one recipient; it was never testing the general safety of the constant, just this specific workload's exposure to it. The live CI failure above is the same underlying gap, just surfaced through a different, real workload instead of a targeted unit test. We also added tests to pin the window's stacking semantics: a run of window+1 one-log pending txs to one secret fits, while the next tx throws. ## Why `+ 20`, not `* 2` or another additive constant - The floor (`MAX_PRIVATE_LOGS_PER_TX`) covers one worst-case *ordinary* tx. The failure mode above is about *additional, ordinary-sized* pending txs to the same counterparty stacking up, not another maxed-out 64-log tx. - It's the value the team had already judged sufficient for realistic pending-tx headroom before #24429 (it was just misapplied as the *entire* budget instead of a margin on top of the floor). --------- Co-authored-by: Martin Verzilli <martin@aztec-labs.com>
Closes F-771 --------- Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>
Closes #5837 This PR makes it so we no longer derive signing keys from the master privacy key. If there's no user-supplied privacy key seed, we instead derive it _from_ the signing key, which is a safe derivation: PXE never sees the signing key nor any value it is derived from. This has a large knock-on effect on wallets, CLI, tutorials, etc., but there's ultimately no large decisions being made there, it is mostly mechanical changes. In some cases I reworked some internals of wallets to make this distinction clearer.
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
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
7 participants
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.
BEGIN_COMMIT_OVERRIDE
fix(sqlite3mc-wasm): restore bundler-visible wasm resolution (#24529)
refactor(aztec-nr): rename get_handshakes to non_interactive variant (#24511)
fix(pxe): UNFINALIZED_TAGGING_INDEXES_WINDOW_LEN should be MAX_PRIVATE_LOGS_PER_TX + headroom, not exactly MAX_PRIVATE_LOGS_PER_TX (#24437)
refactor(aztec-nr): keep handshake secrets internal to TagSecretSource (#24508)
test(txe): extend oracle roundtrip coverage to more scalar oracles (#24550)
refactor!: reimplement partial notes on FactStore (#24369)
feat!: stop deriving signing key from privacy keys (#24439)
END_COMMIT_OVERRIDE