Light client for Polkadot and Substrate-based chains

This JavaScript library provides a light client for
the Polkadot blockchain and for chains built
using the Substrate blockchain framework.

It is an "actual" light client, in the sense that it is byzantine-resilient.
It does not rely on the presence of an RPC server, but directly connects to
the full nodes of the network.

Example

``
import * as smoldot from 'smoldot';

// Load a string chain specification.
const chainSpec = fs.readFileSync('./westend.json', 'utf8');

// A single client can be used to initialize multiple chains.
const client = smoldot.start();

const chain = await client.addChain({ chainSpec });

chain.sendJsonRpc('{"jsonrpc":"2.0","id":1,"method":"system_name","params":[]}');

// Wait for a JSON-RPC response to come back. This is typically done in a loop in the background.
const jsonRpcResponse = await chain.nextJsonRpcResponse();
console.log(jsonRpcResponse)

// Later:
// chain.remove();
`

Usage

The first thing to do is to initialize the client with the start function.

Once initialized, the client can be used to connect to one or more chains. Use addChain to add
a new chain that the client must be connected to. addChain must be passed the specification of
the chain (commonly known as "chain spec").

The addChain function returns a Promise that yields a chain once the chain specification has
been successfully parsed and basic initialization is finished, but before Internet connections
are opened towards the chains.

In order to de-initialize a chain, call chain.remove(). Any function called afterwards on this
chain will throw an exception.
In order to de-initialize a client, call client.terminate(). Any function called afterwards on
any of the chains of the client will throw an exception.

After having obtained a chain, use sendJsonRpc to send a JSON-RPC request towards the node.
The function accepts as parameter a string request. See
the specification of the JSON-RPC protocol,
and the list of requests that smoldot is capable of serving.
Smoldot also has experimental support for an extra (still experimental at the time of writing of
this comment) set of JSON-RPC functions found here.

If the request is well formatted, the client will generate a response. This response can be pulled
using the nextJsonRpcResponse asynchronous function. Calling this function waits until a response
is available and returns it.

If the request is a subscription, the notifications will also be sent back using the same mechanism
and can be pulled using nextJsonRpcResponse.

If the chain specification passed to addChain is a parachain, then the list of potential relay
chains must be passed as parameter to addChain as well. In situations where the chain
specifications passed to addChain are not trusted, it is important for security reasons to not
establish a parachain-relay-chain link between two chains that aren't part of the same "trust
sandbox".

Usage with a worker

By default, calling start() will run smoldot entirely in the current thread. This can cause
performance issues if other CPU-heavy operations are done in that thread.

In order to help with this, it is possible to use smoldot in conjunction with a worker.
To do so, you must first create a worker. Since creating a worker has some subtle differences
depending on the platform, this is outside of the responsibility of smoldot.

Once the worker is created, create two MessagePorts using new MessageChannel, and send one
of them to the worker. Then, pass one port to the ClientOptions.portToWorker field and the
other port to the run() function of smoldot, which can be imported with
import { run } from 'smoldot/worker'; (on Deno, it is found in worker-deno.ts).

Another optimization that is orthogonal to but is related to running smoldot in a worker consists
in also loading the smoldot bytecode in that worker. The smoldot bytecode weights several
megabytes, and loading it in a worker rather than the main thread makes it possible to load the
UI while smoldot is still initializing. This is especially important when smoldot is included in
an application served over the web.

In order to load the smoldot bytecode in a worker, import compileBytecode with
import { compileBytecode } from 'smoldot/bytecode'; (on Deno: bytecode-deno.ts), then call the
function and send the result to the main thread. From the main thread, rather than using the
start function imported from smoldot, use the startWithBytecode function that can be imported
using import { startWithBytecode } from 'smoldot/no-auto-bytecode'; (on Deno:
no-auto-bytecode-deno.ts). The options provided to startWithBytecode are the same as the ones
passed to start, except for an additional bytecode field that must be set to the bytecode
created in the worker.

Here is an example of all this, assuming a browser environment:

`ts
import * as smoldot from 'smoldot/no-auto-bytecode';

const worker = new Worker(new URL('./worker.js', import.meta.url));

const bytecode = new Promise((resolve) => {
worker.onmessage = (event) => resolve(event.data);
});

const { port1, port2 } = new MessageChannel();
worker.postMessage(port1, [port1]);

const client = smoldot.startWithBytecode({
bytecode,
portToWorker: port2,
});


// worker.ts

import * as smoldot from 'smoldot/worker';
import { compileBytecode } from 'smoldot/bytecode';

compileBytecode().then((bytecode) => postMessage(bytecode))
onmessage = (msg) => smoldot.run(msg.data);
`

Note that importing sub-paths (for example importing smoldot/worker) relies on a relatively
modern JavaScript feature. If you import a smoldot sub-path from a TypeScript file, you might have
to configure TypeScript to use "moduleResolution": "node16". The official TypeScript
documentation itself recommends setting this configuration option to
node,
and it is likely that node16` becomes the go-to module resolution scheme in the future.