*4.4. Voting-Based Chain Finality Mechanism*

Since fork issues are caused by network latency or deliberate attacks, the block proposal mechanism will inevitably produce multiple conflicting blocks, which are children blocks with the same parent block. Therefore, those proposed blocks are in fact form an ever-growing *block tree* structure, as the upper part of Figure 3 shows. At the end of an epoch, the *head* with epoch height becomes a checkpoint that is used to resolve forks and to finalize chain history. Inspired by Casper [24] and Microchain [40], our EconLedger finality process adopts a voting-based finality mechanism overlaying the PoENF block generation to commit checkpoint block and finalize the already committed blocks on the main chain.

The chain finality protocol is mainly for identifying a unique chain path on block tree by choosing a single child block from multiple children blocks with a common parent block. For efficiency purposes, the chain finality protocol is only executed on *checkpoint* blocks rather than the entire block tree, and committee members vote for hashes of blocks instead of entire block contents. The chain finality ensures that only one path, including finalized blocks, becomes the main chain. Therefore, blocks generated in the new epoch are only extended on such a unique main chain.
