perf(l1): decrypt L1 deposits in parallel off the engine task - #1389
Closed
mattsse wants to merge 1 commit into
Closed
perf(l1): decrypt L1 deposits in parallel off the engine task#1389mattsse wants to merge 1 commit into
mattsse wants to merge 1 commit into
Conversation
`L1BlockDeposits::prepare` was an async fn without an await that ran the full ECIES pipeline — ECDH, Chaum-Pedersen proof and AES-GCM — for every encrypted deposit inline. The leader awaits it from `ZoneEngine::advance` before block production starts, so a block near the portal's cap of 230 deposits stalled the tokio worker driving the engine for the entire time. Each deposit's result only depends on its decryption key, its own payload and the portal address, so the secrets are now resolved once per distinct key index up front and the per-deposit work runs on rayon inside `spawn_blocking`, collected in order so the queued deposits and their decryption data keep their exact positions. A missing key index still fails with the same error, now before any crypto runs. Blocks without encrypted deposits skip the thread hop and only ABI-encode inline. Timed with a throwaway harness over 230 encrypted deposits on a loaded 12-core M-series machine, with the crypto crates built at opt-level 3: median wall time per call drops from ~200-225 ms to ~32-37 ms, minimum from ~117 ms to ~21 ms.
mattsse
requested review from
0xKitsune,
0xrusowsky,
adityapk00 and
klkvr
as code owners
September 3, 2026 20:56
mattsse
commented
Sep 3, 2026
mattsse
left a comment
mattsse
left a comment
Contributor
Author
There was a problem hiding this comment.
not worth doing since we dont see a lot of deposits in the same block
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
1 participant
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.
L1BlockDeposits::prepareran the full ECIES pipeline (ECDH, Chaum-Pedersen proof, AES-GCM) inline for every encrypted deposit, and the leader awaits it fromZoneEngine::advancebefore block production starts. A block near the portal's cap of 230 deposits stalled the engine's tokio worker for the whole duration, and the key ring lock was taken and aSecretKeycloned per deposit.Each deposit's result depends only on its key, its payload and the portal address, so keys are now resolved once per distinct index and the per-deposit work runs on rayon inside
spawn_blocking, collected through an indexed pipeline so order and contents are unchanged. A missing key index fails with the same error, now before any crypto runs, and blocks without encrypted deposits stay inline. Per-deposit log lines may now interleave.Timed with a throwaway harness over 230 encrypted deposits on a loaded 12-core machine, dev build with the crypto crates at opt-level 3: median wall time per call drops from roughly 200-225 ms to 32-37 ms, the minimum from 117 ms to 21 ms. For a single deposit the thread hop adds about 50 µs against roughly 260 µs of crypto it moves off the engine.