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.

74 lines
3.1 KiB

  1. # ADR 025 Commit
  2. ## Context
  3. Currently the `Commit` structure contains a lot of potentially redundant or unnecessary data.
  4. In particular it contains an array of every precommit from the validators, which includes many copies of the same data. Such as `Height`, `Round`, `Type`, and `BlockID`. Also the `ValidatorIndex` could be derived from the vote's position in the array, and the `ValidatorAddress` could potentially be derived from runtime context. The only truely necessary data is the `Signature` and `Timestamp` associated with each `Vote`.
  5. ```
  6. type Commit struct {
  7. BlockID BlockID `json:"block_id"`
  8. Precommits []*Vote `json:"precommits"`
  9. }
  10. type Vote struct {
  11. ValidatorAddress Address `json:"validator_address"`
  12. ValidatorIndex int `json:"validator_index"`
  13. Height int64 `json:"height"`
  14. Round int `json:"round"`
  15. Timestamp time.Time `json:"timestamp"`
  16. Type byte `json:"type"`
  17. BlockID BlockID `json:"block_id"`
  18. Signature []byte `json:"signature"`
  19. }
  20. ```
  21. References:
  22. [#1648](https://github.com/tendermint/tendermint/issues/1648)
  23. [#2179](https://github.com/tendermint/tendermint/issues/2179)
  24. [#2226](https://github.com/tendermint/tendermint/issues/2226)
  25. ## Proposed Solution
  26. We can improve efficiency by replacing the usage of the `Vote` struct with a subset of each vote, and by storing the constant values (`Height`, `Round`, `BlockID`) in the Commit itself.
  27. ```
  28. type Commit struct {
  29. Height int64
  30. Round int
  31. BlockID BlockID `json:"block_id"`
  32. Precommits []*CommitSig `json:"precommits"`
  33. }
  34. type CommitSig struct {
  35. ValidatorAddress Address
  36. Signature []byte
  37. Timestamp time.Time
  38. }
  39. ```
  40. Continuing to store the `ValidatorAddress` in the `CommitSig` takes up extra space, but simplifies the process and allows for easier debugging.
  41. ## Status
  42. Proposed
  43. ## Consequences
  44. ### Positive
  45. The size of a `Commit` transmitted over the network goes from:
  46. |BlockID| + n * (|Address| + |ValidatorIndex| + |Height| + |Round| + |Timestamp| + |Type| + |BlockID| + |Signature|)
  47. to:
  48. |BlockID|+|Height|+|Round| + n*(|Address| + |Signature| + |Timestamp|)
  49. This saves:
  50. n * (|BlockID| + |ValidatorIndex| + |Type|) + (n-1) * (Height + Round)
  51. In the current context, this would concretely be:
  52. (assuming all ints are int64, and hashes are 32 bytes)
  53. n *(72 + 8 + 1 + 8 + 8) - 16 = n * 97 - 16
  54. With 100 validators this is a savings of almost 10KB on every block.
  55. ### Negative
  56. This would add some complexity to the processing and verification of blocks and commits, as votes would have to be reconstructed to be verified and gossiped. The reconstruction could be relatively straightforward, only requiring the copying of data from the `Commit` itself into the newly created `Vote`.
  57. ### Neutral
  58. This design leaves the `ValidatorAddress` in the `CommitSig` and in the `Vote`. These could be removed at some point for additional savings, but that would introduce more complexity, and make printing of `Commit` and `VoteSet` objects less informative, which could harm debugging efficiency and UI/UX.