Pluggable Consensus - Wiki OpenEthereum Documentation

OpenEthereum comes bundled with a number of consensus engines. While the most widely used is the Ethash proof of work Engine, there are others which can be used for proof of authority or stake chains. The Engine is chosen by placing an appropriate entry in the "engine" field of the spec and providing the correct "seal" under "genesis" field, as described on the Chain specification page.

Ethash

Original Ethereum PoW Engine.

"engine": {
  "ethash": {
    "params": {
      "minimumDifficulty": "0x020000",
      "difficultyBoundDivisor": "0x0800",
      "durationLimit": "0x0d",
      "blockReward": "0x4563918244F40000",
      "homesteadTransition": 0,
      "eip150Transition": 0,
      "eip160Transition": 10,
      "eip161abcTransition": 10,
      "eip161dTransition": 10,
      "maxCodeSize": 24576
    }
  }
}

The "params" object for "Ethash" may contain the following keys (YP refers to the Yellow Paper equation numbers):

"seal": {
  "ethereum": {
    "nonce": "0x0000000000000042",
    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
  }
}

Instant Seal

Engine which can be used for development, as described in Private development chain.

"engine": {
  "instantSeal": {
    "params": {}
  }
}
"seal": {
  "generic": "0x0"
}

The "params" object for "instantSeal" may contain the following keys:

Validator engines

The following Engines achieve consensus by referring to a list of “validators” (referred to as authorities, when they are linked to physical entities). Validator set is a group of accounts which are allowed to participate in the consensus, they validate the transactions and blocks to later sign messages about them.

In the simplest case they can be specified at genesis using a simple "list" (as shown in the Authority Round section):

"validators": {
  "list": [
    "0x7d577a597b2742b498cb5cf0c26cdcd726d39e6e",
    "0x82a978b3f5962a5b0957d9ee9eef472ee55b42f1"
  ]
}

More information can be found on the Validator Set page.

Aura

Simple and fast consensus algorithm, each validator gets an assigned time slot in which they can release a block. The time slots are determined by the system clock of each validator. More details.

"engine": {
    "authorityRound": {
        "params": {
            "stepDuration": "5",
            "validators" : {
                "multi": {
                        "0": { "list": ["0xc6d9d2cd449a754c494264e1809c50e34d64562b"] },
                        "10": { "list": ["0xd6d9d2cd449a754c494264e1809c50e34d64562b"] },
                        "20": { "contract": "0xc6d9d2cd449a754c494264e1809c50e34d64562b" }
                }
            }
        }
    }
}

"stepDuration" determines the lowest interval between blocks in seconds, too low might cause reorgs if the system clocks are not synchronized, or may lead to unintentional misbehavior as gasLimit increases, too high leads to slow block issuance

Optional:

"seal": {
    "authorityRound": {
        "step": "0x0",
        "signature": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    }
}

The genesis seal should not be changed unless a hard fork is conducted.

If malicious authorities are possible then --force-sealing is advised, this will ensure that the correct chain is the longest (making it BFT with finality of authorities_count * step_duration given no network partitions).

Operational tradeoffs

As blocks in Aura must be generated and broadcast within the span of stepDuration, configuring your chain specification or validator node to allow specific transactions or a maximum gasLimit that would exceed stepDuration to process can lead to persistent consensus failures. This can include repetitive forking, reorgs, and missed steps.

Some good rules-of-thumb are:

Due to how block gasLimits are “voted on” by all miners/validators on a network, settings like --gas-cap are most effective if set on all active validators - --tx-gas-limit and --tx-time-limit are useful for individual validators. These configuration options do not effect consensus, and can therefore be used to modify network capacity without requiring a hard fork, accommodating altered hardware or network conditions.