You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

100 lines
2.8 KiB

6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
  1. # ADR 018: ABCI Validator Improvements
  2. ## Changelog
  3. 016-08-2018: Follow up from review: - Revert changes to commit round - Remind about justification for removing pubkey - Update pros/cons
  4. 05-08-2018: Initial draft
  5. ## Context
  6. ADR 009 introduced major improvements to the ABCI around validators and the use
  7. of Amino. Here we follow up with some additional changes to improve the naming
  8. and expected use of Validator messages.
  9. ## Decision
  10. ### Validator
  11. Currently a Validator contains `address` and `pub_key`, and one or the other is
  12. optional/not-sent depending on the use case. Instead, we should have a
  13. `Validator` (with just the address, used for RequestBeginBlock)
  14. and a `ValidatorUpdate` (with the pubkey, used for ResponseEndBlock):
  15. ```
  16. message Validator {
  17. bytes address
  18. int64 power
  19. }
  20. message ValidatorUpdate {
  21. PubKey pub_key
  22. int64 power
  23. }
  24. ```
  25. As noted in ADR-009[https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-009-ABCI-design.md],
  26. the `Validator` does not contain a pubkey because quantum public keys are
  27. quite large and it would be wasteful to send them all over ABCI with every block.
  28. Thus, applications that want to take advantage of the information in BeginBlock
  29. are _required_ to store pubkeys in state (or use much less efficient lazy means
  30. of verifying BeginBlock data).
  31. ### RequestBeginBlock
  32. LastCommitInfo currently has an array of `SigningValidator` that contains
  33. information for each validator in the entire validator set.
  34. Instead, this should be called `VoteInfo`, since it is information about the
  35. validator votes.
  36. Note that all votes in a commit must be from the same round.
  37. ```
  38. message LastCommitInfo {
  39. int64 round
  40. repeated VoteInfo commit_votes
  41. }
  42. message VoteInfo {
  43. Validator validator
  44. bool signed_last_block
  45. }
  46. ```
  47. ### ResponseEndBlock
  48. Use ValidatorUpdates instead of Validators. Then it's clear we don't need an
  49. address, and we do need a pubkey.
  50. We could require the address here as well as a sanity check, but it doesn't seem
  51. necessary.
  52. ### InitChain
  53. Use ValidatorUpdates for both Request and Response. InitChain
  54. is about setting/updating the initial validator set, unlike BeginBlock
  55. which is just informational.
  56. ## Status
  57. Proposal.
  58. ## Consequences
  59. ### Positive
  60. - Clarifies the distinction between the different uses of validator information
  61. ### Negative
  62. - Apps must still store the public keys in state to utilize the RequestBeginBlock info
  63. ### Neutral
  64. - ResponseEndBlock does not require an address
  65. ## References
  66. - [Latest ABCI Spec](https://github.com/tendermint/tendermint/blob/v0.22.8/docs/app-dev/abci-spec.md)
  67. - [ADR-009](https://github.com/tendermint/tendermint/blob/v0.22.8/docs/architecture/adr-009-ABCI-design.md)
  68. - [Issue #1712 - Don't send PubKey in
  69. RequestBeginBlock](https://github.com/tendermint/tendermint/issues/1712)