# EconLedger: A Proof-of-ENF Consensus Based Lightweight Distributed Ledger for IoVT Networks
## 4 PoENF: A Proof-of-ENF Consensus Protocol
### PoENF-Based Block Proposal Mechanism
#### 4.3.2 PoENF Consensus Algorithm  
Given current transactions pool \(TX\), the validator \(v_{i}\in D\) chooses all ENF-proof transactions generated by committee members to construct an ENF-proof transactions list \(TX_{ENF}=\{tx_{1},tx_{2},...,tx_{K}\}\), where \(K\) is the committee size. An ENF proof is a vector \(E=\{e_{1},e_{2},...,e_{d}\}\), where \(e_{i}\in\mathbb{R}\) is the ENF sample value, and \(d\) is the samples' size. By using \(swarm\_hash\) that is stored in the \(data\) parameter of \(tx_{k}\), the \(E_{k}\) sent by \(v_{k}\) can be fetched from off-chain storage. Thus, each \(v_{i}\) can locally maintain a set of collected ENF proof vectors \(G_{i}=\{E_{1},E_{2},...,E_{k}\}\), where \(k\leq K\). In order to become a slot leader and propose a new block in the current block proposal round, \(v_{i}\) must show that its ENF proof \(E_{i}\) can solve a PoENF puzzle problem. Intuitively, the goal of PoENF puzzle problem is to choose the \(E_{k}\) that deviates the least from all ENF proofs in \(G_{i}\) based on their relative distances, which are computed with the Euclidean norm. However, a single Byzantine validator can force the PoENF algorithm to choose any arbitrary ENF proof by sending a poisoned \(E_{b}\) that is too far away from other ENF proofs. Therefore, our PoENF algorithm adopts the Krum aggregation rule to provide the \((\alpha,f)\)-Byzantine resilience property [39]. For each \(v_{i}\in D\), let \(G_{i}=\{E_{1},E_{2},...,E_{n}\}\) include \(n\geq 2f+3\) collected ENF proofs from PoENF committee members, and at most only \(f\) is sent by Byzantine nodes. For any \(i\
eq j\), let \(i\to j\) denote the fact that \(E_{j}\) belongs to the \(n-f-2\) closest ENF proofs to \(E_{i}\). Then, we define the ENF score for \(v_{i}\). \[s(i)=\sum_{i\to j}\|E_{i}-E_{j}\|^{2}. \tag{1}\]  
Equation (1) calculates ENF scores \((s(1),...,s(n))\) associated with validators \(v_{1}\) to \(v_{n}\), respectively, and applies the Krum rule to select the minimum ENF score as follows. \[s^{*}=\operatorname*{argmin}_{i\in\{1,...,n\}}(s(i)). \tag{2}\]  
Finally, the PoENF puzzle problem is formally defined as the following. **Definition 4**. : _Proof-of-ENF: Given \(G_{i}=\{E_{1},E_{2},...,E_{n}\}\) collected by validator \(v_{i}\in D\), the process of PoENF verifies whether a valid ENF proof \(E_{j}\) can meet the condition \(s(j)\leq s^{*}\). If it does, \(v_{j}\) wins the leader election and is qualified to propose a block; otherwise, the blocks generated by any \(v_{j}\) are rejected._  
Given the above definitions, the PoENF-enabled block generation procedures are presented in Algorithm 1. During the current block generation round slot \(sl_{t}\), each validator \(v_{i}\in D\) executes the \(generate\_block()\) function to propose a candidate block according to its collected ENF proofs in the transactions pool. If the ENF score \(s_{i}\) is not greater than the target value \(s^{*}\), then \(v_{i}\) can create a new block and broadcast it to the network. Otherwise, they are only allowed to verify blocks from other validators until the current round finished. The closer \(s_{i}\) is to \(s^{*}\), the higher probability that \(v_{i}\) can propose a new block.