Offscreen API

[TalDerei]

References #146

This PR supports building transactions in the web in parallel using web-workers! Additionally, the serial build method has been deprecated.

The output console logs can be monitored by navigating to chrome://extensions, clicking details, and then inspect view.

[TalDerei]

Tackling some internal complications with spawning workers in a service-worker context, but should be ready for review soon. We'll need to additionally consider fallback scenarios and the proper error handling / propagation (reference #295?) for serial builds.

[TalDerei]

@grod220 building the actions in parallel in the offscreen document and passing the prebuilt vector of actions back to the extension is working, but calls to the build_parallel method is failing. It's throwing "Error: invalid type: byte array, expected a base64 string". Think it's a protobuf change related error?

[grod220]

Ah, you've run into our classic wasm serialization issue. We've each run into this independently 😅 . Think we should document this somewhere.

When crossing the javascript->wasm boundary, you can pass javascript objects. However, it's not a guarantee that serde can deserialize it into structs. For that to be successful, it has to be in json format (protobuf rules though). Bufbuild provides the helper .toJson() on our proto-classes to get in this specific format. So try doing this for each argument like so:

const transaction = build_parallel(
    batchActions.map(action => action.toJson()), 
    req.transactionPlan.toJson(), 
    witnessData.toJson(), 
    req.authorizationData.toJson()
  )

[TalDerei]

Benchmarks on my machine (2020 M1 Mac, 8-core CPU and GPU) for a typical transaction (2 spend and 2 output actions):
- Parallel transaction: 12s build + 6s broadcast = ~18s total
- Serial transaction: 30s build + 6s broadcast = ~36s total

The broadcasting operation viewClient.broadcastTransaction is currently taking around 1/3 of the time for constructing a transaction in parallel. @grod220 @hdevalence Can the perceived time of the broadcasting be somehow reduced?

In terms of outstanding work before this PR can be merged, @turbocrime we should implement a fallback mechanism for serial builds in cases where web workers are not supported. One idea is to introduce a global variable like webWorkersSupported and check against that. Where should this ideally be included considering the changes in #255?

We can further consider load-balancing the workload distributed to the web-workers using a queue when the number of ActionPlan exceeds the number of logical CPU cores on the device. Alternatively, spawning more web-workers than the available cores leads to excessive context switching and resource contention, which degrades the performance.

[hdevalence]

The "broadcast" step in the web code is currently a hardcoded 6s timeout. Two points:

1. The hardcoded timeout is a stand-in for the logic we have in the Rust view server, where we await detection of the transaction during sync, closing the loop on the broadcast (not just waiting for "did the server say it was accepted" but "did it end up in a block we scanned"). This means the time will be between ~0 and ~5s, depending on when the transaction was broadcast relative to the block interval.
2. For this reason, I think it makes sense to expose this to users as a different phase ("Building Transaction..." vs "Broadcasting Transaction...") in the UI.

@grod220 is currently working on replacing the hardcoded timeout with detection logic.

[hdevalence]

Going from 30s build time to 12s build time is amazing!

If we can also cut down some of the wasm overhead, we're stacking improvements that get us pretty close to the ideal scenario of being able to build the transaction in the time it takes the user to review the transaction in the approval dialog.

[TalDerei]

The "broadcast" step in the web code is currently a hardcoded 6s timeout. Two points:

1. The hardcoded timeout is a stand-in for the logic we have in the Rust view server, where we await detection of the transaction during sync, closing the loop on the broadcast (not just waiting for "did the server say it was accepted" but "did it end up in a block we scanned"). This means the time will be between ~0 and ~5s, depending on when the transaction was broadcast relative to the block interval.
2. For this reason, I think it makes sense to expose this to users as a different phase ("Building Transaction..." vs "Broadcasting Transaction...") in the UI.

@grod220 is currently working on replacing the hardcoded timeout with detection logic.

ah I was wondering why it was hard-coded specifically to 6s!

[TalDerei]

If we can also cut down some of the wasm overhead, we're stacking improvements that get us pretty close to the ideal scenario of being able to build the transaction in the time it takes the user to review the transaction in the approval dialog.

Agreed #113 shouldn't be blocked for much longer.

[hdevalence]

In terms of outstanding work before this PR can be merged, @turbocrime we should implement a fallback mechanism for serial builds in cases where web workers are not supported. One idea is to introduce a global variable like webWorkersSupported and check against that.

In what case would web workers not be supported?

[TalDerei]

In what case would web workers not be supported?

It's generally a good idea to check for web worker support (https://www.w3schools.com/html/html5_webworkers.asp). I referenced this chart (https://caniuse.com/webworkers), yet it suggests that 98% of devices wouldn't have an issue.

[TalDerei]

@hdevalence If we don't implement the check, there's no reason to keep the serial build method in the web code, which means we can further reduce the WASM binary size from 8.5 MB to 6.2 MB.

[hdevalence]

From the caniuse.com page, we can unconditionally use web workers, since we're only targeting Chrome

[turbocrime]

hey, i think have quite a lot of feedback on the event and message flow, so i'm just going to add some commits to this pr. we should pair when possible

[TalDerei]

hey, i think have quite a lot of feedback on the event and message flow, so i'm just going to add some commits to this pr. we should pair when possible

I paired with Gabe yesterday, and am currently refactoring the underlying serialization formats as JsonValue. Let's pair later about the event and message flow.

[TalDerei]

I think we're close to be able to merge once the last few comments are addressed.

[TalDerei]

The offscreen lifecycle management is sufficient for now. In a separate issue, we'll make it more complete and enable servicing multiple simultaneous requests.

[grod220]

Great job! Have some remaining points from me. Really excited to get this in though. After this (and Christmas), we should do a release and get users on the new fast builds.