# Reputation Consensus Mechanism for Blockchain Based on Information-Centric Networking
## 4 Design
### Hybrid Consensus Mechanism
#### 4.2.1 Reputation Consensus Mechanism
```
0: Each ICN consensus node \(i\) stakes at least 32 ETH and has a reputation score \(R_{i}\)
0: Secure Secure and fair creation and validation of checkpoint blocks
1: Initialize the set of reputation nodes \(\mathcal{R}=\{i\,|\,R_{i}\}\), with cardinality \(N_{R}=|\mathcal{R}|\)
2: Define the set of checkpoint proposes \(\mathcal{P}\), with cardinality \(N_{s}=|\mathcal{P}|\)
3: Set the duration of each epoch \(T_{E}\)
4: Set the reputation update period \(T_{R}=N_{s}\times T_{E}\)
5:
6: **Proposer Selection:**
7: **for\(j=1\) to \(N_{s}\)do**
8: Select proposer \(p_{j}\) from \(\mathcal{R}\) using RANDAO weighted by \(R_{i}\)
9: Assign \(p_{j}\) to epoch \(E_{j}\)
10: Add \(p_{j}\) to \(\mathcal{P}\)
11: **end for**
12:
13: **Checkpoint Block Creation:**
14: **for all** proposers \(p_{j}\in\mathcal{P}\)do**
15: At the first slot of epoch \(E_{j}\), proposer \(p_{j}\) creates and publishes checkpoint block \(b_{j}\)
16: **if**\(p_{j}\) creates more than one block **or** fails to create \(b_{j}\)**then**
17: Penalize \(p_{j}\)
18: **end if**
19: **end for**
20:
21: **Block Validation:**
22: **for all** checkpoint blocks \(b_{j}\)do**
23: Select validator committee \(\mathcal{V}_{j}\) using RANDAO from all validators
24: Validators in \(\mathcal{V}_{j}\) validate \(b_{j}\)
25: **if** Agreement among \(\mathcal{V}_{j}\) is less than \(\frac{2}{3}\)**then**
26: Mark \(b_{j}\) as invalid
27: **else**
28: Mark \(b_{j}\) as valid
29: **endif**
30: **end for**
31: **Reputation Update:**
32: **if** Current time \(t\) satisfies \(t\) mod \(T_{R}=0\)**then**
33: **Update reputation scores \(R_{i}\) for all nodes in \(\mathcal{R}\)**
34: **endif**

Figure 8: Flowchart of the reputation consensus mechanism. #### 4.2.2 Determining the Reputation Update Period

The system operates with three types of periods: the block generation period \(T_{B}\), the checkpoint interval \(T_{E}\), and the reputation update period \(T_{R}\). These periods are illustrated in Figure 9 and are mathematically related as follows:

\[T_{R}=N_{s}\times T_{E}=N_{s}\times(N_{C}\times T_{B}), \tag{9}\]

where:

* \(T_{R}\) is the reputation update period,
* \(N_{s}\) is the number of selected reputation nodes serving as checkpoint proposers within a reputation update period,
* \(T_{E}\) is the duration of a checkpoint interval,
* \(N_{C}\) is the number of blocks in a checkpoint interval,
* \(T_{B}\) is the block generation period. Equation (9) indicates that the reputation update period \(T_{R}\) is defined as the product of the duration of a checkpoint interval \(N_{s}\) and the number of reputation nodes \(N_{s}\) selected as checkpoint proposers during that period. In Ethereum, the block generation period \(T_{B}\) is 12 s, and each checkpoint interval consists of \(N_{C}=32\) blocks [45]. Therefore, the checkpoint interval duration is \(T_{E}=N_{C}\times T_{B}=32\times 12\) s, and the reputation update period \(T_{R}\) directly influences the number of ICN nodes selected \(N_{s}\) within each period. A longer reputation update period \(T_{R}\) (i.e., a larger \(N_{s}\)) means more nodes are selected per period. This approach reduces bandwidth consumption for reputation updates and node elections and lowers the probability of nodes being repeatedly selected within the same timeframe, enhancing randomness and fairness. However, selecting too many nodes may include those with lower reputation scores, potentially decreasing the average network quality of the selected nodes. Conversely, a shorter \(T_{R}\) (smaller \(N_{s}\)) results in fewer nodes being selected per period. In the extreme case where \(T_{R}=T_{E}\) and only one node is selected (\(N_{s}=1\)), the selected node is likely to have a higher reputation score, improving the average network quality. The drawbacks include increased bandwidth overhead due to more frequent reputation updates and elections, and a higher risk of certain nodes being repeatedly selected, which can lead to centralization and increased vulnerability to attacks.