PulseNet chains rely on a system of POSA/POA consensus that can support short block times and lower fees. 

Consensus Engine of PulseNet


We have designed the consensus engine of PULSE to achieve the following goals:

  1. Confirmation within a few blocks 
  2. Blocking time should be 5 seconds or less.
  3. No inflation, the block reward is transaction gas fees.
  4. As compatible as Ethereum.
  5. With staking and governance as powerful as cosmos.

Geth has two kinds of consensus implementations : ethash and clique. Ethash being POW is not suitable for PULSE. Clique has a short block time and is immune to a 51% attack while doing as little to the core data structure as possible to preserve existing Ethereum client compatibility. Here we try to propose a consensus that:

  • Does the staking and governance parts for PULSE.
  • Is as simple as clique.

Having searched for some other decent implementations of the POA consensus we found that Bor follows a similar design as above. We will use a few pieces from Bor and suggest a new consensus to achieve all these goals.

Consensus Protocol

The implementation of the consensus engine is named clique. This doc will focus more on the difference and ignore the common details.

Before introducing, we would like to clarify some terms:

  1. Epoch block. The engine will update the Validator Set from the NC Validator Set contract periodically. The period is currently 200 blocks, a block is called an epoch block if the height of it is times of 200.
  2. Snapshot. Which is an object that helps to store the validators and recent signers of blocks.

Key features

Light client security

Validator Set switches take effect at (epoch+N/2) blocks. (N is the size of the validator set before the epoch block). Due to the client security, we delay the N/2 block to let the Validator Set switch take place.

The validator will check the Validator Set in the contract for each epoch block and populate the extra data field in the block header. It will be checked against the Validator Set in the contract by the full node. A light client will use it as the Validator Set for the upcoming epoch blocks, but it is unable to check it against the contract; instead, it must have faith in the epoch block’s signer. The light client could travel to the wrong chain if the signer of the epoch block sends an incorrect extra data. If we postpone the N/2 blocks to allow the Validator Set change to take place, the incorrect epoch block won’t obtain another N/2 following block that is signed by the other validators, defending the light client from such an attack.

System transaction

System transactions are those that use system contracts and are triggered by the consensus engine. Transactions on the system are signed by the validator creating the block. According to its internal logic, the witness node will construct system transactions (without signatures) and, before applying them, will compare them to the system transactions in the block.

Enforce backoff

Out-of-turn validators must wait a randomised period of time in the Clique consensus algorithm before sealing the block. The canonical version is assumed to be used by validators when it is implemented in the client-side node programme. However, it is feasible that validators will run a customised version of the node software to disregard such a delay given that they would have an economic incentive to seal blocks as quickly as possible. Each out-turn validator will be given a set window of time to seal the block, preventing validators from rushing to do so. Any block produced by an out-turn validator with an earlier blocking time will be disregarded by the other nodes.

How to Produce a new block

Step 1: Prepare

The block header of the following block is prepared by a validator node.

  • Loads the snapshot from cache or database,
  • The validators set message for each epoch block will be kept in the extraData field of the block header.
  • The coinbase is the address of the validator

Step2: Finalize And Assemble

  • If the validator is not the in turn validator, the expected validator will be slashed, resulting in the creation of a slashing transaction.
  • If there is a gas fee in the block, the system reward contract will receive 1/16 of it, and the validator contract will receive the remainder.

Step3: Seal

The last step before a validator publishes a new block

  • All block header elements should be signed and appended to extraData
  • If it is out of turn for a validator to sign the block, it will wait for an honest validator for a random reasonable amount of time.

How to Validate/Replay a block

Step1: Verify Header

Verify the block header when receiving a new block.

  • Verify the signature of the coinbase is in extraData of the blockheader
  • A blockHeader will be rejected if its block time is less than that expected when compared to the block time.
  • The signer should be the coinbase, and the expected value should be determined by the difficulty

Step2: Finalize

  • The validator node will extract Validator Set from NC Validator Set and compare it with extra data if the block is an epoch block.
  • The slash contract will be called if the block is not produced by inturn validatorvalidaror. In the event that there is a gas fee in the block, 1/16 will be given to the system reward contract and the remaining will go to the validator contract.
  • The consensus engine’s generated transaction must match the block’s transaction exactly.


The blockheader’s extraData, whose structure is the epoch block, contains the coinbase’s signature. 65 bytes of signature plus N*20 bytes of the validator address and 32 bytes of extraVanity. none epoch block. 65 bytes of the signature data plus 32 bytes of extraVanity. The block header’s Keccak256 RLP encoded content is the signed content.

Security and Finality

Due to there being more than 1/2*N+1 validators that are sincere, Proof Of Authority nets typically operate securely. There are still some circumstances, nevertheless, in which a tiny group of Byzantine validators can try to assault the network, for example through the “Clone Attack.”. To add security, PULSE users are encouraged to wait until they’ve received blocks sealed by more than 2/3*N+1 different validators. In that way, PULSE can be trusted at a similar security level to BC and can tolerate less than 1/3*N Byzantine validators.

If we were to assume 21 validators and a 5 second block time, the time required for the 2/3*N+1 validator seals would be 75 seconds. Any critical applications for PULSE may have to wait for 2/3*N+1 to ensure a relatively secure finality. However, besides such an arrangement, PULSE does introduce Slashing logic to penalize Byzantine validators for double signing or instability. This logic exposes malicious validators in a very short time and ensures that any attack would be very hard or extremely non-economic to execute. With this enhancement, 1/2*N+1 or even fewer blocks are enough as confirmation for most transactions.

Potential Issue

Extending the ruling of the current validator set via temporary censorship

If the transaction that updates the validator is sent to the PULSE right on the epoch period, then the in-turn validator may choose to censor the transaction and keep the same set of validators in place for that epoch. Despite the fact that a transaction cannot be permanently censored without the assistance of other n/2 validators, it can do so to extend the life of the existing validator set to reap some rewards. By conspiring with other validators, this scheme’s likelihood can generally be increased. Since an epoch is made up of 240 blocks, or about 20 minutes, it is a relatively minor issue that the validators could only be extended for another 20 minutes. 

Table of contents