RCP-240829A: Using RGB and BP APIs with rust async

[dr-orlovsky]

authors: @dr-orlovsky
layers: informational

All libraries by LNP/BP Standards Association, including BP, LNP and RGB, are not using rust async nor Future trait. This allows them to be independent from a specific async runtime and maintain a low profile and API simplicity.

The library data objects are thread-safe, meaning they are Send and can be sent between threads. It is not advised to share objects between threads even if they are Sync (for instance using Arcs), and instead it is advised to clone objects - or to keep them in one thread only, allowing other threads to access them via thread in-memory or socket-based APIs (such as crossbeam, zmq and alike).

All file system-based operations in the libraries exist behind feature gate fs, which simplify the library use in the WASM context. In the same manner, unless a client directly uses filesystem, all library operations are not blocking, which simplifies use of the library methods in both async and non-async context.

However, once a library client needs to use filesystem operations downstream in async context, he may face a problem of most efficient API for that. Here, I propose the approach which is the best according to my knowledge.

Let's take a Wallet object from BP library as an example. In order to save it to a file (or a database) in async way, we need to do the following:

1. Develop an object which implements PersistenceProvider trait. The object is non-async, however, instead of performing I/O operations directly, it has to contain just one sender for a MPSC channel (for instance, crossbeam::channel::Sender), which is Clone and is non-blocking;
2. Create a dedicated thread which will be using async I/O for storing the data to the file system or into a database
3. Send the in-memory serialized data for the storage from the PersistenceProvider to that thread using the channel sender