import { type AddChainOptions } from "https://deno.land/x/smoldot@light-js-deno-v0.7.9/client.d.ts";
Configuration of a blockchain.
Properties
JSON-encoded specification of the chain.
The specification of the chain can be generated from a Substrate node by calling
<client> build-spec --raw > spec.json. Only "raw" chain specifications are supported by
smoldot at the moment.
If the chain specification contains a relay_chain field, then smoldot will try to match
the value in relay_chain with the value in id of the chains in potentialRelayChains.
Content of the database of this chain. Can be obtained by using the
chainHead_unstable_finalizedDatabase JSON-RPC function.
Smoldot reserves the right to change its database format, making previous databases incompatible. For this reason, no error is generated if the content of the database is invalid and/or can't be decoded.
Important: please note that using a malicious database content can lead to a security vulnerability. This database content is considered by smoldot as trusted input. It is the responsibility of the API user to make sure that the value passed in this field comes from the same source of trust as the chain specification that was used when retrieving this database content.
If chainSpec concerns a parachain, contains the list of chains whose id smoldot will try
to match with the parachain's relay_chain.
Defaults to [].
Must contain exactly the objects that were returned by previous calls to addChain. The
library uses a WeakMap in its implementation in order to identify chains.
The primary way smoldot determines which relay chain is associated to a parachain is by
inspecting the chain specification of that parachain (i.e. the chainSpec field).
This poses a problem in situations where the same client is shared between multiple different
applications: multiple applications could add mutiple different chains with the same id,
creating an ambiguity, or an application could register malicious chains with small variations
of a popular chain's id and try to benefit from a typo in a legitimate application's
relay_chain.
These problems can be solved by using this parameter to segregate multiple different uses of
the same client. To use it, pass the list of all chains that the same application has
previously added to the client. By doing so, you are guaranteed that the chains of multiple
different applications can't interact in any way (good or bad), while still benefiting from
the de-duplication of resources that smoldot performs in addChain.
When multiple different parachains use the same relay chain, it is important to be sure that
they are indeed using the same relay chain, and not accidentally using different ones. For
this reason, this parameter is a list of potential relay chains in which only one chain
should match, rather than a single Chain corresponding to the relay chain.