Consider removing GrandPa commit messages gossiping

[tomaka]

Right now, nodes "sometimes" (as an implementation detail) gossip GrandPa commit messages to each other.

Light clients rely on these commit messages in order to know which block has been finalized. In practice, however, since the gossip messages aren't always gossiped, there is sometimes a delay between the chain's finalized block and the light client's finalized block. Since UIs on top of light clients are supposed to rely only on finalized blocks and that anything non-finalized can't 100% be trusted, this is not great. See https://github.com/smol-dot/smoldot/issues/1754

It seems to me that it would be a better idea to make light clients explicitly download the justification of a block once it has learned (through a neighbor packet) that it has been finalized.

As far as I understand (correct me if I'm wrong), at the time when GrandPa was created, we would only store justifications of epoch change blocks. Since we've implemented warp syncing, however, we also store the latest finalized block justification.

Since, if I'm not mistaken, we only store the latest finalized block's justification, that gives 6 seconds for the full node to send a neighbor packet to light clients and for light clients to ask for the justification in return. This should be more than enough. If the block time was to be reduced, however, we would have to store the justifications of a few recent blocks rather than just the one most recent block.

Let me know if that all makes sense.

cc @andresilva

[andresilva]

I wonder why the light client doesn't get the commit messages gossiped to it regularly. Is it connected to a low number of peers?

Either way, your suggestion for requesting the justification explicitly should work since we always have the latest justification available. IIRC we are currently only sending neighbor packets to light clients when the authority set changes, so we'll need to change this to everytime a new block is finalized (or basically when the round finishes, same as full nodes).

[burdges]

Yes, we could switch light clients from gandpa to beefy, not sure the current beefy lag, but..

We could do beefy BLS signatures every block, even ETH relayers do not create the web3sum proof of the beefy aggregate public key every block.

A polkadot light client who knows the validators BLS public keys could simply read the bitfield identifying the signers, add up those public keys, and do the pairing check of the aggregate BLS public key. We ingnore the web3sum proof entirely, because that's just an optimization for ETH's fucked up cost model.

At least on kusama, this should already be faster than checking over 600 signatures, assuming we're building ed25519 verification into wasm now. If otoh the light client uses the webcrypto APIs for native verification code, then maybe sticking with unaggregated ed25519 remains faster.

[tomaka]

I wonder why the light client doesn't get the commit messages gossiped to it regularly. Is it connected to a low number of peers?

It's normally connected to 3 full nodes, but it can be fewer than that because smoldot can only ever connect to nodes through WebSocket, which significantly limits the possible selection.

[tomaka]

Having to explicitly query justifications (as opposed to passively receiving commit messages) has a few advantages:

• There's no random chance of not receiving any commit message.
• Less bandwidth usage, as you're downloading the justification/commit only once per block, instead of possibly once per block and per peer.
• Assuming that catch-up messages become a request-response protocol too, this would allow significantly reducing the maximum size of a GrandPa gossip packet. More granularity is always better.
• From a simplicity point of view, removing the concept of GrandPa commit (which is basically a subset of a justification but with some minor differences such as fields being in a different order) isn't a bad idea IMO.