github.com/pokt-network/tendermint@v0.32.11-0.20230426215212-59310158d3e9/docs/architecture/adr-005-consensus-params.md (about)

     1  # ADR 005: Consensus Params
     2  
     3  ## Context
     4  
     5  Consensus critical parameters controlling blockchain capacity have until now been hard coded, loaded from a local config, or neglected.
     6  Since they may be need to be different in different networks, and potentially to evolve over time within
     7  networks, we seek to initialize them in a genesis file, and expose them through the ABCI.
     8  
     9  While we have some specific parameters now, like maximum block and transaction size, we expect to have more in the future,
    10  such as a period over which evidence is valid, or the frequency of checkpoints.
    11  
    12  ## Decision
    13  
    14  ### ConsensusParams
    15  
    16  No consensus critical parameters should ever be found in the `config.toml`.
    17  
    18  A new `ConsensusParams` is optionally included in the `genesis.json` file,
    19  and loaded into the `State`. Any items not included are set to their default value.
    20  A value of 0 is undefined (see ABCI, below). A value of -1 is used to indicate the parameter does not apply.
    21  The parameters are used to determine the validity of a block (and tx) via the union of all relevant parameters.
    22  
    23  ```
    24  type ConsensusParams struct {
    25      BlockSize
    26      TxSize
    27      BlockGossip
    28  }
    29  
    30  type BlockSize struct {
    31      MaxBytes int
    32      MaxTxs int
    33      MaxGas int
    34  }
    35  
    36  type TxSize struct {
    37      MaxBytes int
    38      MaxGas int
    39  }
    40  
    41  type BlockGossip struct {
    42      BlockPartSizeBytes int
    43  }
    44  ```
    45  
    46  The `ConsensusParams` can evolve over time by adding new structs that cover different aspects of the consensus rules.
    47  
    48  The `BlockPartSizeBytes` and the `BlockSize.MaxBytes` are enforced to be greater than 0.
    49  The former because we need a part size, the latter so that we always have at least some sanity check over the size of blocks.
    50  
    51  ### ABCI
    52  
    53  #### InitChain
    54  
    55  InitChain currently takes the initial validator set. It should be extended to also take parts of the ConsensusParams.
    56  There is some case to be made for it to take the entire Genesis, except there may be things in the genesis,
    57  like the BlockPartSize, that the app shouldn't really know about.
    58  
    59  #### EndBlock
    60  
    61  The EndBlock response includes a `ConsensusParams`, which includes BlockSize and TxSize, but not BlockGossip.
    62  Other param struct can be added to `ConsensusParams` in the future.
    63  The `0` value is used to denote no change.
    64  Any other value will update that parameter in the `State.ConsensusParams`, to be applied for the next block.
    65  Tendermint should have hard-coded upper limits as sanity checks.
    66  
    67  ## Status
    68  
    69  Proposed.
    70  
    71  ## Consequences
    72  
    73  ### Positive
    74  
    75  - Alternative capacity limits and consensus parameters can be specified without re-compiling the software.
    76  - They can also change over time under the control of the application
    77  
    78  ### Negative
    79  
    80  - More exposed parameters is more complexity
    81  - Different rules at different heights in the blockchain complicates fast sync
    82  
    83  ### Neutral
    84  
    85  - The TxSize, which checks validity, may be in conflict with the config's `max_block_size_tx`, which determines proposal sizes