Open lexnv opened 9 months ago
this information might be useful for some developers
could you please enumerate some of the use cases? 🙏
I'm not entirely familiar with the justifications, to be honest. Bridges are using justifications heavily in their code. It might enable some developers to check the integrity of those blocks by inspecting the justification. Anything related to consensus engines I think might benefit from fetching the justifications. Pierre mentioned them in this issue: https://github.com/smol-dot/smoldot/issues/1638#issuecomment-1917407636, however, I think light-clients will use the p2p protocol instead of the RPC method.
Have opened this issue to gather some feedback and ideas. Since we plan to stabilize the chainHead API soon, I wanted to bring this up before we bump the version 🙏
The topic of having a function that allows querying a block's justification has come surprisingly often.
If there's no practical reason why it should be possible to download a block's justification, then I'm against adding a function that lets you do that. This also concern things like the block number, list of GrandPa votes, list of authorities, etc.
Justifications in particular are especially problematic because:
I want to highlight the fact that "justifications" are a poorly-defined concept, and just because Substrate has a function that allows reading the justifications of a block and that this function is easy to call is not an argument why we should expose this concept from the JSON-RPC API.
We don't expose a justification method on the
chainHead
class and this information might be useful for some developers.I wondered if we should add this method before stabilizing the
chainHead
to version 1 to have a more complete API.From the Substrate perspective, this is quite trivial to implement. I'm not sure what the implementation would look like for the light clients.
Would love to get your thoughts on this 🙏
// cc @paritytech/subxt-team @tomaka @josepot