You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Noticed one strange thing when testing our relay with Kusama/Polkadot - within the same session, GRANDPA justifications received from the node contain different number of signatures. E.g. given session with 1000 validators in Kusama, on justification has 672 precommits, other has 674 and the next one has 676. Since on-chain signature verification is expensive, it'd be better for relayers to "optimize" justifications before submitting them. Iiuc in this (1000 validators) case we only need 667 signatures, so extra ~10 signatures may be removed before sending it to the pallet.
The text was updated successfully, but these errors were encountered:
Noticed one strange thing when testing our relay with Kusama/Polkadot - within the same session, GRANDPA justifications received from the node contain different number of signatures.
This is normal, GRANDPA justification is built using all the available/gossiped signatures, the condition being >= 2/3+1, so they can be more than 667 for 1000 validators.
so extra ~10 signatures may be removed before sending it to the pallet
Sounds good, if it's a low-hanging fruit let's do it.
Noticed one strange thing when testing our relay with Kusama/Polkadot - within the same session, GRANDPA justifications received from the node contain different number of signatures. E.g. given session with
1000
validators in Kusama, on justification has672
precommits, other has674
and the next one has676
. Since on-chain signature verification is expensive, it'd be better for relayers to "optimize" justifications before submitting them. Iiuc in this (1000
validators) case we only need667
signatures, so extra ~10 signatures may be removed before sending it to the pallet.The text was updated successfully, but these errors were encountered: