Skip to content
Draft
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions simple.md
Original file line number Diff line number Diff line change
Expand Up @@ -703,3 +703,85 @@ Auditor -> Validator
--> FIN
<-- FIN
```

### CE 146: GRANDPA Vote

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

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

```
Ed25519 Public = [u8; 32]
Round Number = u64
Set Id = u32
Prevote = Header Hash ++ Slot
Precommit = Header Hash ++ Slot
PrimaryPropose = Header Hash ++ Slot
Message = Enum {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

0 = Prevote,
1 = Precommit,
2 = PrimaryPropose
}
Signed Message = Message ++ Ed25519 Signature ++ Ed25519 Public
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Validator -> Validator

--> 0 ++ Round Number ++ Set Id ++ Signed Message
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

--> FIN
<-- FIN
```

### CE 147: GRANDPA Commit

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. Delay broadcasting a commit by a random time from 0..1 seconds.
  2. 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.


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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Compact Commit = Header Hash ++ Slot ++ Precommits ++ Multi Auth Data
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's going on with Commit vs Compact Commit? What makes a Compact Commit compact? Why not just use Commit here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is left over from a potential optimization in the grandpa crate that never happened. I've removed Compact Commit.


Validator -> Validator

--> 1 ++ Round Number ++ Set Id ++ Compact Commit
--> FIN
<-- FIN
```

### 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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


```
Validator -> Validator

--> 2 ++ Round Number ++ Set Id ++ Slot
--> FIN
<-- FIN
```

### CE 149: GRANDPA CatchUp

Catchup Request. This is sent by a voting validator to another validator.

```
Validator -> Validator

--> 3 ++ Round Number ++ Set Id
--> FIN
<-- FIN
```

Catchup Response. This includes all votes required to catch up state to that of the responding voter.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


```
Signed Prevote = Prevote ++ Ed25519 Signature ++ Ed25519 Public
Signed Precommit = Precommit ++ Ed25519 Signature ++ Ed25519 Public
Base Hash = Header Hash
Base Number = Slot
Catchup = Round Number ++ len++[Signed Prevote] ++ len++[Signed Precommit] ++ Base Hash ++ Base Number

Validator -> Validator

--> 4 ++ Set Id ++ Catchup
--> FIN
<-- FIN
```