search

penumbra-zone / web

Apache License 2.0
12 stars 15 forks source link

relocate block syncing out of the service worker and into the offscreen client #1573

Open TalDerei opened 1 month ago

TalDerei commented 1 month ago

proposal:

The service worker has inherent performance limitations due to its single-threaded and blocking nature. Consequently, note payloads inside blocks are trial decrypted serially. To address this, we propose moving block syncing out of the service worker and into the offscreen client, thereby allowing this CPU bound operation to be parallelized using dedicated web workers. This approach is supported by benchmarks recorded in https://github.com/penumbra-zone/web/issues/1142.

This raises some technical considerations:

The specific components being considered for moving into the offscreen client are:

  1. RPC services interacting with the block processor
  2. The entire block processor component
  3. The trial decryption operation, modified in wasm to use rayon threads
turbocrime commented 1 month ago

previously https://github.com/penumbra-zone/web/pull/710

services

a major benefit of moving services to offscreen is the entire package could then target standard dom api and drop chrome dependency.

targeting standard dom is important. the current offscreen mechanism implicitly depends on undocumented messaging and implementation details, and no consumer is going to achieve that.

targeting standard dom api, development of penumbra providers for ffx and other browsers would be as simple as writing a transport session manager for those browsers.

this could also be done piecemeal, right now, using the proxying tools and a context client. offscreen could, on-demand, run a limited service of only the endpoints that require wasm, and with the proxy tool, the existing router adapter can seamlessly merge these.

this could be done most quickly by splitting the view service def, but that's a bad shortcut.

if we want the existing services implementation to be adaptable for this, it would be necessary to stop doing direct cross-method calls in services, and to rewrite use of queriers to use of context clients.

block processor

offscreen block processor currently shares queriers with services. if these begin to run separately, we either have to

i prefer the third option. most queriers are very thin wrappers to single api functions on promise clients.

eliminating queriers and switching to client use is simple in the block processor, and would provide versatility.

in services, it's more complex as switching to clients means that we now have local same-document clients and fullnode clients. i still think this is beneficial.

moving block processor out of the main worker also allows the extension to respond to messages during heavy operations inside the block processor. genesis sync freeze (which prevents injection init, shows user the 'connect' button when already connected) would not happen

TalDerei commented 6 days ago

hackmd: https://hackmd.io/0Clj7ej1RQqmBfNdLfY4uw#

TalDerei commented 7 hours ago

update

https://github.com/penumbra-zone/web/pull/1769 and prax-wallet/web#190 are the first steps toward this goal. It relocates the offscreen client outside the services package, and enables services to execute within the offscreen document. However, migrating the entire block processor component has yet to be implemented and requires further consideration.