-
Notifications
You must be signed in to change notification settings - Fork 162
Description
Proposed Change or Idea
The purpose of the useRcBlock parameter is to allow applications to continue following the Polkadot blockchain by traversing the Relay Chain, and look up information about parachains via the RC block.
This is the pattern we want to be following since as an exchange we care greatly about finality, and finality is still determined by the relay chain.
However, the current implementation is not as user friendly as it could be.
The block/ endpoints will only return information about the RC block if there is a corresponding parachain block. If there is no block then the response is []. I'd like to propose that when a caller is looking up details relative to the RC chain (by using useRcBlock=true), they should always receive at least the relevant information of the RC block.
Right now the API is:
// Request for RC block with no parachain block
[]
// Request for RC block with parachain block
[{"rcBlockNumber": 100, "rcBlockHash": "foo"}]
It would be very useful for us if the API was instead:
// Request for RC block with no parachain block
{
"rcBlockHash": "foo",
"rcBlockParentHash": "bar",
"rcBlockNumber": "100"
"parachains": []
}
This would allow our wallet to traverse the parachain via relay chain blocks without needing to send requests to two separate instances of the sidecar.
The existing implementation forces us to deploy a sidecar for the relay chain and use that for block headers, and deploy a separate sidecar for the parachain and use that to look up transactions.
The key improvement here is that by returning the relay chain block header, wallets get one API which exposes the full picture of the chain that is being traversed without making separate calls to the relay chain node. This simplifies the interaction model since we do not need to maintain two different sidecars and direct traffic between the two.