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.

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