Add BatchDomain::batch_ka_agree_dec, a per-viewing-key batched agreement hook - #13
Merged
Merged
Conversation
…ent hook Trial decryption computes ka_agree_dec for many ephemeral keys against the same incoming viewing key. For domains where same-scalar multiplications can share work (for example, lockstep ladders over a shared batched field inversion), this dominates the cost of batched trial decryption, but the per-item Domain::ka_agree_dec interface gives implementations no opportunity to exploit it. This adds a provided BatchDomain method that computes the agreements for a whole batch against one viewing key, defaulting to the per-item computation, and routes the batch module's shared-secret derivation through it (one call per viewing key, preserving the output-major order the downstream batch KDF expects). Existing BatchDomain implementations are unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
@LukasKorba yes, please prepare those backport PRs for orchard and sapling-crypto. |
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
2 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.
Trial decryption computes
ka_agree_decfor many ephemeral keys against the same incoming viewing key, and those scalar multiplications dominate the cost of batched trial decryption. The per-itemDomain::ka_agree_decinterface gives implementations no opportunity to exploit the shared scalar — thebatchmodule even notes "The scalar multiplications cannot benefit from batching", which is true for the current interface but not for the underlying math: same-scalar multiplications can share work (e.g. lockstep affine ladders amortizing one field inversion per ladder step across the whole batch, on curves like Pallas).This PR adds
BatchDomain::batch_ka_agree_dec: a provided method computing the agreements for a whole batch of prepared ephemeral keys against one viewing key. The default implementation is exactly the per-item computation, so existingBatchDomainimplementations are unaffected. Thebatchmodule's shared-secret derivation now routes through it — one call per viewing key — reassembling results in the output-major order the downstream batch KDF expects.Context: this interface comes from a production wallet sync engine, where an Orchard implementation of the hook (a batched same-scalar kernel) measured a +15% wall-clock improvement on full-history restores on some hardware; we're preparing the corresponding
orchardPR that implements the override. The pair has been running in production behind a runtime toggle with the output KAT-gated byte-identical to the per-item path.One question for the maintainers:
orchard(both main and the released 0.15) andsapling-cryptocurrently targetzcash_note_encryption 0.4, while this repo's main is the unreleased breaking 0.5 line. The method is additive and applies cleanly to the 0.4 code as well — if you'd take a0.4.2patch release, I'm happy to open the corresponding backport PR so implementations on the 0.4 line can adopt it without waiting for the 0.5 migration.