mirror of https://github.com/poanetwork/quorum.git
Add documentation on IBFT parameters (#835)
* Include documentation on IBFT parameters * Update links from other pages
This commit is contained in:
Peter Fox
fixanoid
parent
99f7fd6733
commit
7d773ae432
|
|
@ -44,7 +44,7 @@ The official docker containers can be found under https://hub.docker.com/u/quoru
|
|||
* [Tessera](https://github.com/jpmorganchase/tessera): Java implementation of peer-to-peer encrypted message exchange for transaction privacy
|
||||
* Quorum supported consensuses
|
||||
* [Raft Consensus Documentation](https://docs.goquorum.com/en/latest/Consensus/raft/)
|
||||
* [Istanbul BFT Consensus Documentation](https://github.com/ethereum/EIPs/issues/650): [RPC API](https://docs.goquorum.com/en/latest/Consensus/istanbul-rpc-api/) and [technical article](https://medium.com/getamis/istanbul-bft-ibft-c2758b7fe6ff). __Please note__ that updated istanbul-tools is now hosted in [this](https://github.com/jpmorganchase/istanbul-tools/) repository
|
||||
* [Istanbul BFT Consensus Documentation](https://github.com/ethereum/EIPs/issues/650): [RPC API](https://docs.goquorum.com/en/latest/Consensus/ibft/istanbul-rpc-api.md) and [technical article](https://medium.com/getamis/istanbul-bft-ibft-c2758b7fe6ff). __Please note__ that updated istanbul-tools is now hosted in [this](https://github.com/jpmorganchase/istanbul-tools/) repository
|
||||
* [Clique POA Consensus Documentation](https://github.com/ethereum/EIPs/issues/225) and a [guide to setup clique json](https://modalduality.org/posts/puppeth/) with [puppeth](https://blog.ethereum.org/2017/04/14/geth-1-6-puppeth-master/)
|
||||
* Zero Knowledge on Quorum
|
||||
* [ZSL](https://github.com/jpmorganchase/quorum/wiki/ZSL) wiki page and [documentation](https://github.com/jpmorganchase/zsl-q/blob/master/README.md)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ With no need for POW/POS in a permissioned network, Quorum instead offers multip
|
|||
* __Raft-based Consensus__: A consensus model for faster blocktimes, transaction finality, and on-demand block creation. See [Raft-based consensus for Ethereum/Quorum](../raft) for more information
|
||||
|
||||
|
||||
* __Istanbul BFT (Byzantine Fault Tolerance) Consensus__: A PBFT-inspired consensus algorithm with transaction finality, by AMIS. See [Istanbul BFT Consensus documentation](https://github.com/ethereum/EIPs/issues/650), the [RPC API](../istanbul-rpc-api), and this [technical web article](https://medium.com/getamis/istanbul-bft-ibft-c2758b7fe6ff) for more information
|
||||
* __Istanbul BFT (Byzantine Fault Tolerance) Consensus__: A PBFT-inspired consensus algorithm with transaction finality, by AMIS. See [Istanbul BFT Consensus documentation](https://github.com/ethereum/EIPs/issues/650), the [RPC API](../ibft/istanbul-rpc-api.md), and this [technical web article](https://medium.com/getamis/istanbul-bft-ibft-c2758b7fe6ff) for more information
|
||||
|
||||
|
||||
* __Clique POA Consensus__: a default POA consensus algorithm bundled with Go Ethereum. See [Clique POA Consensus Documentation](https://github.com/ethereum/EIPs/issues/225) and a [guide to setup clique json](https://hackernoon.com/hands-on-creating-your-own-local-private-geth-node-beginner-friendly-3d45902cc612) with [puppeth](https://blog.ethereum.org/2017/04/14/geth-1-6-puppeth-master/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
# IBFT parameters
|
||||
|
||||
## CLI options
|
||||
|
||||
### Block period
|
||||
|
||||
`--istanbul.blockperiod 1`
|
||||
|
||||
Setting the block period is used for how long blocks should be minted by the validators. It is also used for validation
|
||||
of block times by all nodes, so should not be changed after deciding a value for the network.
|
||||
The setting is a positive integer, and measures the minimum numbers of seconds before the next block is considered
|
||||
valid.
|
||||
|
||||
The default value is `1`.
|
||||
|
||||
### Request timeout
|
||||
|
||||
`--istanbul.requesttimeout 10000`
|
||||
|
||||
The request timeout is the timeout at which IBFT will seek to trigger a new round if the previous one did not complete.
|
||||
This period increases are the timeout is hit more often. This parameter sets the minimum timeout in the case of normal
|
||||
operation and is measured in milliseconds.
|
||||
|
||||
The default value is `10000`.
|
||||
|
||||
## Genesis file options
|
||||
|
||||
Within the `genesis.json` file, there is an area for IBFT specific configuration, much like a Clique network
|
||||
configuration.
|
||||
|
||||
The options are as follows:
|
||||
```
|
||||
{
|
||||
"config": {
|
||||
"istanbul": {
|
||||
"epoch": 30000,
|
||||
"policy": 0,
|
||||
"ceil2Nby3Block": 0
|
||||
},
|
||||
...
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Epoch
|
||||
|
||||
The epoch specifies the number of blocks that should pass before pending validator votes are reset. When the
|
||||
`blocknumber%EPOCH == 0`, the votes are reset in order to prevent a single vote from becoming stale. If the existing
|
||||
vote was still due to take place, then it must be resubmitted, along with all its votes.
|
||||
|
||||
### Policy
|
||||
|
||||
The policy refers to the proposer selection policy, which is either `ROUND_ROBIN` or `STICKY`.
|
||||
|
||||
A value of `0` denotes a `ROUND_ROBIN` policy, where the next expected proposer is the next in queue. Once a proposer
|
||||
has submitted a valid block, they join the back of the queue and must wait their turn again.
|
||||
|
||||
A value of `1` denotes a `STICKY` proposer policy, where a single proposer is selected to mint blocks and does so until
|
||||
such a time as they go offline or are otherwise unreachable.
|
||||
|
||||
### ceil2Nby3Block
|
||||
|
||||
The `ceil2Nby3Block` sets the block number from which to use an updated formula for calculating the number of faulty
|
||||
nodes. This was introduced to enable existing network the ability to upgrade at a point in the future of the network, as
|
||||
it is incompatible with the existing formula. For new networks, it is recommended to set this value to `0` to use the
|
||||
updated formula immediately.
|
||||
|
||||
To update this value, the same process can be followed as other hard-forks.
|
||||
|
|
@ -21,7 +21,9 @@ nav:
|
|||
- Consensus:
|
||||
- Consensus: Consensus/Consensus.md
|
||||
- Raft: Consensus/raft.md
|
||||
- Istanbul: Consensus/istanbul-rpc-api.md
|
||||
- Istanbul BFT:
|
||||
- Consensus/ibft/istanbul-rpc-api.md
|
||||
- Consensus/ibft/ibft-parameters.md
|
||||
- Transaction Processing: Transaction Processing/Transaction Processing.md
|
||||
- Security Framework:
|
||||
- Overview: Security/Framework/Overview.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue