# Reputation Consensus Mechanism for Blockchain Based on Information-Centric Networking
## 4 Design
### Hybrid Consensus Mechanism
#### 4.2.1 Reputation Consensus Mechanism
It is important to note that both JABS and SimBlock are network simulators developed based on the P2P network layer and do not simulate routing units and network layer protocols (e.g., multicast routing protocols) in IP and ICN. Although existing simulation platforms such as NS2 and NS3 can simulate routing devices and their network protocols, they are complex and time-consuming for large-scale network simulations. Moreover, simulating ICN multicast protocols is not the focus of this study. Therefore, we incorporated existing comparative data of Ethereum networks based on IP and ICN [12, 52] as parameters into JABS to evaluate the performance of RepuICN under a hybrid network topology of IP and ICN. #### 6.1.2 Platform Configuration

We conducted our experiments on a desktop computer equipped with an Intel Core i5-10505 CPU @ 3.20 GHz processor, 32 GB of RAM, and a 1 TB hard drive. In addition to simulations using SimBlock and JABS, we performed experimental data analysis and plotting using Python. Detailed specifications of the experimental software and hardware are presented in Table 3. \begin{table}
\begin{tabular}{c c} \hline \hline
**Software and Hardware** & **Version/Model** \\ \hline Operating System & 64-bit Windows 11 \\ Processor & Intel Core i5-10505 (Intel Corporation, \\  & Santa Clara, CA, USA) \\ CPU & 3.20 GHz \\ RAM & 32 GB DDR4 \\ Hard Drive & 1 TB SSD \\ Platforms & SimBlock [50, 51] and JABS [49] \\ IDE & PyCharm and Intellji 2024.3.4 \\ Programming Languages & Python 3.10 and Java 17.0.1 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Specifications of experimental software and hardware Simulation Parameters

In the network simulation process, probabilities and statistical data are derived from real data sources, extracted from existing studies or datasets. For blockchain data statistics, parameters such as inv-message size and the number of node neighbors are obtained from the source code and default configurations of Bitcoin Core [53] and Ethereum Go [54]. The size of Ethereum blocks, average number of transactions per block, and transaction throughput are acquired from Etherscan [55]. Network statistical data include parameters such as node distribution, network latency, and bandwidth. Node latency data are sourced from WonderNetwork [56], while bandwidth speeds are obtained from SpeedTest.net [57]. Parameters for comparing Ethereum network performance over IP and ICN networks are derived from existing studies [12; 52]. The sources of specific blockchain data and network parameters are summarized in Table 4.

Evaluation Metrics

To assess the performance optimization of RepulCN compared to the Casper FFG protocol, our experimental design considers the following key variables: block message broadcast coverage across all network nodes, block generation interval, checkpoint interval, proposer node network latency fluctuation parameter \(J\), and the proportion of ICN nodes. By controlling these variables, we selected the following metrics to evaluate performance improvements:

* Network System Performance: This includes block propagation delay and transaction throughput. Block propagation delay is defined as the average time from when a block is first proposed to when it is received and verified by the majority of nodes in the network. Transaction throughput, a fundamental metric for measuring blockchain performance, represents the number of transactions the system can process per second. These two indicators collectively reflect the efficiency of the blockchain network in reaching consensus. * Network Bandwidth Consumption: This metric refers to the amount of network traffic consumed by different protocols during the consensus process. It is used to evaluate the network efficiency of protocols and their applicability under different network environments. * Network Stability: This metric focuses on the block propagation time under conditions of proposer node network latency fluctuations, reflecting the extent to which proposer node network volatility affects block propagation efficiency.