Consensus
Consensus Engine of OJX Chain
Abstract
We target to design the consensus engine of OJA Coin Smart Chain to achieve the following goals:
Wait a few blocks to confirm (should be less than Ethereum 1.0), better no fork in most cases.
Blocking time should be shorter than Ethereum 1.0, i.e. 5 seconds or less.
No inflation, the block reward is transaction gas fees.
As much as compatible as Ethereum.
With staking and governance as powerful as cosmos.
Geth implements two kinds of consensus engine: ethash (based on PoW) and clique (base on PoA). Ethash is not a fit option for OJX because OJX gives up PoW. Clique has smaller blocking time and is invulnerable to 51% attack while doing as little to the core data structure as possible to preserve existing Ethereum client compatibility. The shortcoming of PoA is centralization, and the lack of meaningful staking and governance capability on-chain. On the other hand, the OJA Coin Smart Chain is built on Cosmos which does have a deployed staking and governance mechanism. Thus here we try to propose a consensus engine that:
OJA Coin Smart Chain does the staking and governance parts for TC.
Consensus engine of OJX keeps as simple as clique.
We investigated some popular implementations of PoA consensus and find out that Bor follows a similar design as above. We will borrow a few parts from Bor and propose a new consensus engine to achieve all these goals.
Infrastructure Components
OJA Coin Smart Chain. It is responsible for holding the staking function to determine validators of OJX through independent election, and the election workflow are performed via staking procedure.
Consensus Protocol
The implement of the consensus engine is named as clique. This doc will focus more on the difference and ignore the common details.
Before introducing, we would like to clarify some terms:
Epoch block. Consensus engine will update validatorSet from NCValidatorSet contract periodly. For now the period is 200 blocks, a block is called epoch block if the height of it is times of 200.
Snapshot. Snapshot is an assistant object that help to store the validators and recent signers of blocks.
Key features
Light client security
Validators set changes take place at the (epoch+N/2) blocks. (N is the size of validatorset before epoch block). Considering the security of light client, we delay N/2 block to let validatorSet change take place.
Every epoch block, validator will query the validatorset from contract and fill it in the extra_data field of block header. Full node will verify it against the validatorset in contract. A light client will use it as the validatorSet for next epoch blocks, however, it can not verify it against contract, it has to believe the signer of the epoch block. If the signer of the epoch block write a wrong extra_data, the light client may just go to a wrong chain. If we delay N/2 block to let validatorSet change take place, the wrong epoch block won’t get another N/2 subsequent blocks that signed by other validators, so that the light client is free of such attack.
System transaction
The consensus engine may invoke system contracts, such transactions are called system transactions. System transactions is signed by the validator who is producing the block. For the witness node, will generate the system transactions (without signature) according to its intrinsic logic and compare them with the system transactions in the block before applying them.
Enforce backoff
In Clique consensus protocol, out-of-turn validators have to wait a randomized amount of time before sealing the block. It is implemented in the client-side node software and works with the assumption that validators would run the canonical version. However, given that validators would be economically incentivized to seal blocks as soon as possible, it would be possible that the validators would run a modified version of the node software to ignore such a delay. To prevent validator rushing to seal a block, every out-turn validator will get a specified time slot to seal the block. Any block with an earlier blocking time produced by an out-turn validator will be discarded by other witness node.
Last updated