Create subxt backend from a substrate backend

[nmammeri]

Hi, thanks for the valuable work you're doing with subxt.

I would like to create an OnlineClient for signing and submitting extrinsics. However I don't want to go through the network and websockets. Is there a way to create a subxt Backend from a substrate ChainHead backend?

My scenario is that we would like to offer some custom RPCs for our users and expose those as part of our substrate based node. As part of those RPC's we would like to use subxt to sign and submit some extrinsics. It doesn't sound optimal to go through the netrwork layer while we already have got access to the full substrate backends including ChainHead. I'm wondering is there a way to create subxt backend from a substrate backend.

Many thanks

[niklasad1]

Hey hey,

Is there a way to create a subxt Backend from a substrate ChainHead backend?

There is no way to connect to a substrate node besides the HTTP/WebSocket RPC interface.
I guess you want to connect to a substrate node but without the WebSocket overhead such as IPC?

Or what do you want to accomplish?

[nmammeri]

Instead of asking our end users to use subxt to interact with our blockchain, we want to make easier for them by providing custom RPCs on the substrate node itself that perform parameter validation, signing and submitting extrinsics, waiting until tx is in block, decoding events using metadata then replying with meaningful error messages. This is roughly what I envisage:

               substrate node 
   -----------------------------------
   |   chainHead_backend  <-- subxt   |  <---- createDepositRpcEndpoint 
    -----------------------------------

Currently, I found a way to interact directly to the sc-transaction-pool, but it is requires writing a lot of boiler plate code. In subxt an OnlineClient can be created from a Backend. My question is, can this be created from an sc_client_api::backend::Backend? I guess the answer is no, would it make sense to add such functionality?

[niklasad1]

My question is, can this be created from an sc_client_api::backend::Backend? I guess the answer is no, would it make sense to add such functionality?

Ok, I see what you mean.

The subxt::Backend trait/abstraction is designed/implemented to fetch such data via RPC from a substrate-based-node and it is currently not possible to create from a sc_client_api::backend::Backend.

Technically, it should be possible to implement the subxt::Backend for the sc_client_api::backend::Backend but that trait is sealed and can't be externally implemented.

I don't think sc_client_api::backend::Backend impl is something that we would want to have in subxt directly because we have made efforts to not depend directly on polkadot-sdk libraries directly because it's so difficult with different crate versions with traits bounds etc.. but we could open the Backend trait so you could implement it yourself.

@jsdw

What do you think about making Backend trait non-sealed/externally implementable (I don't remember why)?

[nmammeri]

Thanks for your quick answer. I see what you mean, if I understood correctly the design principle of subxt is to operate via RPC to a substrate node.
Making the subxt Backend trait non-sealed might be a step in the right direction.

[jsdw]

I'm not against unsealing it. The reason for it being sealed originally was because we were unsure of the design and wanted room to be ablke to tweak it without impacting users so much, but it has been pretty stable lately anyways!

if I understood correctly the design principle of subxt is to operate via RPC to a substrate node.

Exactly; it's basically an API client to give a nice interface over interacting with the node RPCs at its core, which means we want it to be fairly independant from substrate code for the reasons Niklas mentioned!