paritytech
Custom RPC strategy
I need a RPC to get storage diff for a particular block, and another RPC to dry run transaction and return the storage diff.
I can try to have them implemented in Substrate and then request to support those RPC here. However I would like to discuss the proper way of requesting new RPC methods. Should I make an issue to https://github.com/paritytech/json-rpc-interface-spec first?
On the other hand, I don't necessary require those RPC to be included the official smoldot repo. Another way to achieve my goal is use smoldot as a library and I can do whatever I want without it without require changes within smoldot. I certainly don't need those RPC in Substrate/Acala full node as we plan to migrate all of our services and dApp to use substrate connect so the RPC implementation in Substrate won't be used.
So I would like to open this issue to discuss what's the pathway forward.
I totally understand if make smoldot extensible could be out of the scope as that's the purpose of Substrate. So maybe the best way is to propose a generic of RPC to execute blocks and get output back?
I think it makes sense to add to chainHead_unstable_call the list of storage items that have been modified.
Once that is implemented, you can call TaggedTransactionQueue_validate_transaction to dry-run a transaction, or Core_execute_block to execute a block.
I think the way forward is to have a clear division between the client and runtime. The client exposes generic RPC methods that let you query anything you want to know from the runtime, and the runtime decides on chain-specific things. I think it's not a good idea for the client to expose things such as fees, nonces, etc.
There are some RPC methods that smoldot is missing that could make sense to add, such as querying Babe or Grandpa information, but I would add them on a case by case scenario if they're justified.
archive_unstable_call can fit my first requirement and chainHead_unstable_call can fit my second requirements if they both able to return changed storages.