relocate services and block syncing out of the service worker to the offscreen entry

[TalDerei]

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 #1142.

This raises some technical considerations:

• Should we move everything into the offscreen client?
• Is the offscreen client persistent and stable?
• How will error propagation be handled?
• Messaging

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

1. RPC services interacting with the block processor (move services and block processor into offscreen entry #1788)
2. The entire block processor component (move services and block processor into offscreen entry #1788)
3. The trial decryption operation, modified in wasm to use rayon threads (Implement worker scaffolding to enable parallelization  #1787)

[turbocrime]

previously #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

• separate block proccessor from queriers, and run multiple queriers
• provide a cross-document queriers messaging system
• stop using queriers

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]

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