# Reputation Consensus Mechanism for Blockchain Based on Information-Centric Networking
## 4 Design
### Hybrid Consensus Mechanism
#### 4.2.1 Reputation Consensus Mechanism
It is used to assess the robustness and stability of protocols in unstable network environments. In the simulations, we reference the scale of the existing Ethereum network [54], with the default simulated network comprising 5000 nodes, 100 are designated as ICN \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Number of Nodes & 5000–15,000 [58] \\ Block Generation Time & 10 s \\ Block Size & 72 KB [55] \\ Number of Transactions per Block & 135 [55] \\ Proposer Node Network Delay Factor & 1.0, 1.5, 2.0 \\ Number of Neighbors per Node & Ethereum Go [54] \\ Global Node Distribution & Etherescan [58] \\ Network Latency & WonderNetwork [56] \\ Network Bandwidth & testmy.net [59] \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Network simulation parameter settingsnodes. Since Ethereum completed the merge of its mainnet (execution layer) and beacon chain (consensus layer) in September 2022, transitioning to a Proof-of-Stake consensus mechanism [60], both protocols used in this study are implemented based on the PoS consensus algorithm. At the current stage, Ethereum network nodes typically run both execution layer clients and consensus layer clients simultaneously. Therefore, in our simulations, we assume that all network nodes act as validators. In the experiments, the checkpoint intervals for both the RepuICN protocol and the Casper FFG protocol are set to every seven blocks. A total of 10 simulation runs are conducted, with each run generating 50 blocks. To ensure the fairness and reliability of the experimental results, RepuICN and Casper FFG protocols use the same random seed in each execution and repeat simulations with different random seeds. Additionally, all network configurations remain consistent across each experiment, ensuring the repeatability and consistency of the results. ### Analysis of Simulation Results

#### 6.2.1 Network System Performance

Figure 10 illustrates the block broadcast delay performances of the RepuICN and Casper FFG protocols under varying broadcast coverages, block heights, and proportions of ICN nodes. Figure 10a presents a boxplot comparison of broadcast delays between RepuICN and Casper FFG under different coverage conditions. The results indicate that at 50% and 90% broadcast coverage, the average block broadcast delays for RepuICN are reduced by 25.2% and 22.7%, respectively, compared to Casper FFG. Notably, the outlier values for RepuICN are closer to the overall data distribution, suggesting improved performance during instances of block congestion. Figure 10b explores the impact of varying ICN node proportions on broadcast delay at 90% coverage. The data reveal that the average broadcast delay decreases significantly as the proportion of ICN nodes increases. With an ICN node proportion of 2%, the broadcast delay under RepuICN is reduced by 22.7% compared to Casper FFG; at a 10% proportion, the reduction reaches 43.9%. Furthermore, an increase in ICN node proportion corresponds with a reduction in outlier values and a convergence towards the main data distribution, indicating reduced block congestion and enhanced network performance. Figure 10c demonstrates the effects of different block heights on broadcast delays at a 90% coverage rate. Despite fluctuations in delay due to the randomness of block proposal nodes and network conditions, RepuICN consistently outperforms Casper FFG across various block heights, particularly in checkpoint blocks where the delay reduction is markedly pronounced. In the RepuICN protocol, the broadcast delay for regular blocks is reduced by 17.4% compared to Casper FFG, while the delay for checkpoint blocks is reduced by 61.4%. This improvement is primarily attributed to the efficient block propagation by ICN nodes using a multicast mechanism, which decreases the number of hops in the peer-to-peer network. The reputation consensus mechanism also selects higher-reputation ICN nodes as checkpoint proposers, further enhancing propagation efficiency.