ADR 018: ABCI Validator Improvements

Changelog

016-08-2018: Follow up from review:

  1. - Revert changes to commit round
  2. - Remind about justification for removing pubkey
  3. - Update pros/cons

05-08-2018: Initial draft

Context

ADR 009 introduced major improvements to the ABCI around validators and the use of Amino. Here we follow up with some additional changes to improve the naming and expected use of Validator messages.

Decision

Validator

Currently a Validator contains address and pub_key, and one or the other is optional/not-sent depending on the use case. Instead, we should have a Validator (with just the address, used for RequestBeginBlock) and a ValidatorUpdate (with the pubkey, used for ResponseEndBlock):

  1. message Validator {
  2.     bytes address
  3.     int64 power
  4. }
  6. message ValidatorUpdate {
  7.     PubKey pub_key
  8.     int64 power
  9. }

As noted in ADR-009[https://github.com/tendermint/tendermint/blob/develop/docs/architecture/adr-009-ABCI-design.md], the Validator does not contain a pubkey because quantum public keys are quite large and it would be wasteful to send them all over ABCI with every block. Thus, applications that want to take advantage of the information in BeginBlock are required to store pubkeys in state (or use much less efficient lazy means of verifying BeginBlock data).

RequestBeginBlock

LastCommitInfo currently has an array of SigningValidator that contains information for each validator in the entire validator set. Instead, this should be called VoteInfo, since it is information about the validator votes.

Note that all votes in a commit must be from the same round.

  1. message LastCommitInfo {
  2.   int64 round
  3.   repeated VoteInfo commit_votes
  4. }
  6. message VoteInfo {
  7.     Validator validator
  8.     bool signed_last_block
  9. }

ResponseEndBlock

Use ValidatorUpdates instead of Validators. Then it’s clear we don’t need an address, and we do need a pubkey.

We could require the address here as well as a sanity check, but it doesn’t seem necessary.

InitChain

Use ValidatorUpdates for both Request and Response. InitChain is about setting/updating the initial validator set, unlike BeginBlock which is just informational.

Status

Proposal.

Consequences

Positive

  • Clarifies the distinction between the different uses of validator information

Negative

  • Apps must still store the public keys in state to utilize the RequestBeginBlock info

Neutral

  • ResponseEndBlock does not require an address

References