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