# Penumbra Web Client-Sync V2

Our block processor does the job of querying blocks and assembling a filtered portion of the state-commitment-tree. This is then used for the user's transactions, on the client forming zk proofs that their commitment is included in this tree. The block processor / sync implementation in the web exhibits a substantial [performance regression](https://docs.google.com/spreadsheets/d/1DtOj8cAibJbQ1JrYzPZefobvH6I8jjczUpZeaapkuqA/edit#gid=0) compared to the rust implementation present in the core monorepo.

## <u>Design Considerations</u>

[DagSync](https://hackmd.io/@str4d/dagsync-graph-aware-zcash-wallets), an efficient graph traversal algorithm, is expected to improve web client-sync performance, and the implementation will involve:

**1.** enumerate the current V1 design of the client-sync algorithm,
**2.** write-up a V2 design and codesign with other cryptography (eg. FMD).

For context, "Fuzzy Message Detection" (FMD) is a detection capability built into addresses, enabling oursourcing message detection to an external third party (ie. detector). A hybrid codesign could involve using an FMD system to detect the first note, from which point DagSync would take over and traverse a local subgraph. There are interesting design considerations here like: **(1)** where do you start scanning the chain, **(2)** how should the TCT be modified to support "partial" state updates, **(3)** how to integrate a linear scan for background detection for filling in the rest of the partial state, **(4)** could webgpu hardware acceleration be used, etc.

Additionally, since **~90%** of compact block contents will probably be produced by high-frequency trading bots, reducing the supply production of these notes is ideal. To make the view server more efficient on sync, we're introducing a ["sync_exclude"](https://github.com/penumbra-zone/penumbra/issues/4405) flag where market-makers can opt-in to not include their spends / outputs in compact blocks. Importantly, since the web maintains dedicated implementations of the view server and block processor, any modification in the core monorepo will need to be downstreamed to the web-side accordingly.