4.3.3. Chain Extension Policies

In a PoENF block generation round, validators extend the local chain based on a "*largest height of confirmed block*" rule, which requires that new blocks *Bi*+<sup>1</sup> are only appended to *head*(C) by letting *Bi*+<sup>1</sup>[*pre*\_*hash*] = H(*head*(C)). The PoENF process allows that the probability of a block generated by validator *vi* is related to the rank of its ENF proof *Ei* among the global ENF proof vectors *G*. However, *Gi* observed by validator *vi* may vary

due to network latency or misbehavior of Byzantine nodes. Thus, it is hard to guarantee that only one block is proposed during each slot round, and the amount of candidate blocks could be between zero and the committee size *K*. Given the candidate blocks number *b* ∈ [0, *<sup>K</sup>*], the chain extension rules are described as follows:

	- (a) Chain head points to a block that records most ENF proof transactions among other blocks;
	- (b) For the candidate blocks having ENF proof transactions of the same size, the block generated by validator that has the largest credit value becomes the chain head.

Rule (i) covers a basic scenario to ensure that a new blocks is extended on the chain head. Rule (ii) handles the conflicting chain head update scenario when multiple validators propose valid blocks when they have different global ENF proof vectors *G*. It also discourages dishonest behaviors by using a smaller *G* to win the right to block proposal. Rule (iii) guarantees liveness in PoENF consensus process such that at least one uniform block is generated to ensure chain extension even if a leader cannot propose a new block due to crash failures or attacks.
