github.com/hyperion-hyn/go-ethereum@v2.4.0+incompatible/docs/Consensus/ibft/ibft-parameters.md (about)

     1  # IBFT parameters
     2  
     3  ## CLI options
     4  
     5  ### Block period
     6  
     7  `--istanbul.blockperiod 1`
     8  
     9  Setting the block period is used for how long blocks should be minted by the validators. It is also used for validation
    10  of block times by all nodes, so should not be changed after deciding a value for the network.
    11  The setting is a positive integer, and measures the minimum numbers of seconds before the next block is considered 
    12  valid.
    13  
    14  The default value is `1`.
    15  
    16  ### Request timeout
    17  
    18  `--istanbul.requesttimeout 10000`
    19  
    20  The request timeout is the timeout at which IBFT will seek to trigger a new round if the previous one did not complete.
    21  This period increases are the timeout is hit more often. This parameter sets the minimum timeout in the case of normal 
    22  operation and is measured in milliseconds.
    23  
    24  The default value is `10000`.
    25  
    26  ## Genesis file options
    27  
    28  Within the `genesis.json` file, there is an area for IBFT specific configuration, much like a Clique network 
    29  configuration. 
    30  
    31  The options are as follows: 
    32  ```
    33  {
    34      "config": {
    35          "istanbul": {
    36              "epoch": 30000,
    37              "policy": 0,
    38              "ceil2Nby3Block": 0
    39          },
    40          ...
    41      },
    42      ...
    43  }
    44  ```
    45  
    46  ### Epoch
    47  
    48  The epoch specifies the number of blocks that should pass before pending validator votes are reset. When the
    49  `blocknumber%EPOCH == 0`, the votes are reset in order to prevent a single vote from becoming stale. If the existing 
    50  vote was still due to take place, then it must be resubmitted, along with all its votes.
    51  
    52  ### Policy
    53  
    54  The policy refers to the proposer selection policy, which is either `ROUND_ROBIN` or `STICKY`.
    55  
    56  A value of `0` denotes a `ROUND_ROBIN` policy, where the next expected proposer is the next in queue. Once a proposer 
    57  has submitted a valid block, they join the back of the queue and must wait their turn again.
    58  
    59  A value of `1` denotes a `STICKY` proposer policy, where a single proposer is selected to mint blocks and does so until
    60  such a time as they go offline or are otherwise unreachable.
    61  
    62  ### ceil2Nby3Block
    63  
    64  The `ceil2Nby3Block` sets the block number from which to use an updated formula for calculating the number of faulty 
    65  nodes. This was introduced to enable existing network the ability to upgrade at a point in the future of the network, as
    66  it is incompatible with the existing formula. For new networks, it is recommended to set this value to `0` to use the 
    67  updated formula immediately.
    68  
    69  To update this value, the same process can be followed as other hard-forks.