Grandpa protocols #6

MattHalpinParity · 2025-05-07T19:47:28Z

No description provided.

zdave-parity

Can't comment on the actual message contents as I'm not familiar enough with GRANDPA; will have to trust you on that for now!

zdave-parity · 2025-05-09T14:39:23Z

simple.md

+Prevote = Header Hash ++ Slot
+Precommit = Header Hash ++ Slot
+PrimaryPropose = Header Hash ++ Slot
+Message = Enum {


To be consistent with how enums are defined elsewhere, I would write this like:

0 ++ Prevote OR 1 ++ Precommit OR 2 ++ PrimaryPropose

Would also be good to use a more specific name than Message. If these are votes, perhaps Vote would be a good name?

zdave-parity · 2025-05-09T14:40:11Z

simple.md

+
+Validator -> Validator
+
+--> 0 ++ Round Number ++ Set Id ++ Signed Message


The 0 ++ seems unnecessary, similar comment on the other protocols.

zdave-parity · 2025-05-09T14:41:05Z

simple.md

+<-- FIN
+```
+
+Catchup Response. This includes all votes required to catch up state to that of the responding voter.


Assuming this is a response to a previous catchup request, we should probably just return it on the request stream?

zdave-parity

I've read the GRANDPA paper and somewhat understand how it works now. It should be possible for someone to implement this protocol given only the GP, referenced papers (this includes the GRANDPA paper), and this document. I don't think there is enough detail here at the moment for that to be the case. I've commented on particular places where I think there is not enough detail, but these comments are probably not exhaustive...

zdave-parity · 2025-08-26T17:39:11Z

simple.md

+
+GRANDPA voter sets match validator sets for each epoch.
+This is sent by each voting validator to all other voting validators.
+


A summary of the vote types here and when they are sent would be good. Ideally it should be possible to implement this using only the GRANDPA paper and this document. So in particular, I think PrimaryPropose needs clarifying here, as I don't think that wording is used in the paper. I assume it is the block broadcast by the primary in step 2 of the protocol? We also need to define here how the primary is chosen as this is not defined in the paper.

zdave-parity · 2025-08-26T17:39:49Z

simple.md

+
+```
+Message = 0 ++ Prevote OR 1 ++ Precommit OR 2 ++ PrimaryPropose
+Signed Message = Message ++ Ed25519 Signature ++ Ed25519 Public


Probably don't need the public key here given that it should match the peer ID?

zdave-parity · 2025-08-26T17:46:22Z

simple.md

+
+### CE 147: GRANDPA Commit
+
+This is sent by each voting validator to all other voting validators.


I think we need to be clearer about the sending behaviour here. The paper says that to reduce spam, we should:

Delay broadcasting a commit by a random time from 0..1 seconds.

Don't broadcast if we receive a commit from another validator.

I assume this is implemented in the Rust crate? Although it doesn't seem critical that all implementations do exactly the same thing here, we should probably still document the expected behaviour.

zdave-parity · 2025-08-26T17:49:15Z

simple.md

+
+```
+Precommits = len++[Precommit]
+Multi Auth Data = len++[Ed25519 Signature ++ Ed25519 Public]


I assume the nth signature applies to the nth precommit? This should be documented. Preferable to identify signers by their index rather than their public key here? Seems like this would cut message size by ~25%, and would be consistent with the other protocols and the GP.

Yes, the signatures are in order of precommit. I've removed this along with Compact Commit though.

zdave-parity · 2025-08-26T17:50:41Z

simple.md

+
+### CE 148: GRANDPA State
+
+This is sent by each voting validator to all other voting validators and informs them of the latest round it is participating in.


Should clarify when this is sent. Is it sent once the validator "starts the round" as defined in the paper?

zdave-parity · 2025-08-26T18:09:20Z

simple.md

+Grandpa Justification = Round Number ++ Commit ++ Votes Ancestries
+
+Justification Type = 0 OR 1
+Encoded Justification = len++[u8]


What's the reason for the double-encoding here?

This was for a generic finality justification system that would work with eg, Grandpa and Beefy. Replaced this with a simple Grandpa Justification protocol for now so the double encoding has gone.

zdave-parity · 2025-08-26T18:10:11Z

simple.md

+
+```
+Votes Ancestries = len++[Header]
+Grandpa Justification = Round Number ++ Commit ++ Votes Ancestries


I assume this does not include a Set Id because that is implied or something?

It does not strictly need Set Id as all the votes inside Commit are signed with the Set Id so the Justification will only validate with the correct Set Id.
I've decided to add Set Id to it though as I think that will make syncing and tracking set changes easier.

zdave-parity · 2025-08-26T18:11:49Z

simple.md

+Prevote = Header Hash ++ Slot
+Precommit = Header Hash ++ Slot
+PrimaryPropose = Header Hash ++ Slot
+Signed Prevote = Prevote ++ Ed25519 Signature ++ Ed25519 Public


What does the signature cover? Presumably it should cover round number and set ID to avoid weird replay attacks? In any case I think this should be documented here given that it isn't covered in the GP. Also should document the prefix used for the signature.

Yeah, I've clarified this now. The signature does cover round number and set ID.

zdave-parity · 2025-08-26T18:13:45Z

simple.md

+
+```
+Round Number = u64
+Set Id = u32


I assume Set Id refers to the validator/voter set? I think we need to be explicit here about what it actually is, eg is it an epoch index or something?

Clarified this. It starts at 0 at genesis and increments after each set change block is finalized. So it normally increments with epoch but it is not strictly the same as epoch index.

zdave-parity · 2025-08-26T18:28:33Z

simple.md

+
+### CE 149: GRANDPA CatchUp
+
+Catchup Request. This is sent by a voting validator to another validator. The response includes all votes required to catch up state to that of the responding voter.


This needs more explanation, particularly as this isn't really covered by the GRANDPA paper AFAICT. eg:

What are Base Hash and Base Header?

What do the round number and set ID in the request and response mean?

You say "the response includes all votes required to catch up state to that of the responding voter", but it seems like only the votes for one round are returned? If the requester is multiple rounds behind, are they supposed to request votes for one round at a time or something? Given the protocol defined in the paper, it does not seem possible for an honest voter to skip rounds? But perhaps this is possible based on observed commits or something?

I've clarified this a bit. Base refers to a block that all vote targets are a descendent of. There is no longer a response set ID, just for the request. The responding validator only returns the votes for the last completed round from it's view.

…pa Justification protocol

Added Warp Sync Request protocol for requesting Warp Sync Fragments and a description of how these can be used to prove finality when syncing.

Add posterior state root hash to the GRANDPA vote target as described in GP section 19.

Initial Grandpa protocols

4d33321

zdave-parity reviewed May 9, 2025

View reviewed changes

MattHalpinParity added 3 commits May 20, 2025 17:30

Small grandpa fixes

9d5ba21

Justification request

bc84a3e

Rearrange grandpa types

a756666

zdave-parity reviewed Aug 26, 2025

View reviewed changes

MattHalpinParity and others added 12 commits August 31, 2025 11:20

Remove compact commit

356bc8d

Clarify catchup

feabc80

Merge remote-tracking branch 'origin/main' into grandpa

d470644

Clarify message signing and replace Justification protocol with Grand…

68d4070

…pa Justification protocol

Add Set Id to Grandpa Justification. More notes.

2ad5f1f

Merge branch 'zdave-parity:main' into grandpa

3cf902a

Update protocol numbers

be569e3

Warp Sync

257246c

Added Warp Sync Request protocol for requesting Warp Sync Fragments and a description of how these can be used to prove finality when syncing.

Change authority set to validator set for consistency

03df0db

Update GRANDPA target

555c272

Add posterior state root hash to the GRANDPA vote target as described in GP section 19.

Calculation of primary for a round

7666d23

Genesis happens on round 0

737b8ae


		Validator -> Validator

		--> 0 ++ Round Number ++ Set Id ++ Signed Message


		GRANDPA voter sets match validator sets for each epoch.
		This is sent by each voting validator to all other voting validators.


		### CE 147: GRANDPA Commit

		This is sent by each voting validator to all other voting validators.


		### CE 148: GRANDPA State

		This is sent by each voting validator to all other voting validators and informs them of the latest round it is participating in.


		### CE 149: GRANDPA CatchUp

		Catchup Request. This is sent by a voting validator to another validator. The response includes all votes required to catch up state to that of the responding voter.

Grandpa protocols #6

Are you sure you want to change the base?

Grandpa protocols #6

Uh oh!

Conversation

MattHalpinParity commented May 7, 2025

Uh oh!

zdave-parity left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zdave-parity left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants