Reputation Consensus Mechanism for Blockchain Based on Information-Centric Networking

Abstract

The integration of blockchain with Information-Centric Networking (ICN) enhances content distribution efficiency in areas such as the Internet of Things (IoT) and 5G/6G communications. This integration implies that the network state information of ICN can significantly impact consensus efficiency. However, the Ethereum Casper FFG consensus algorithm overlooks the network heterogeneity among consensus nodes, leading to a potential bottleneck in consensus efficiency, especially when nodes with inferior network quality participate. To address this issue, this paper proposes a multidimensional reputation model based on an ICN-enabled blockchain architecture. The model combines on-chain stake and network contributions to evaluate the reputation of ICN consensus nodes. Furthermore, a reputation-based hybrid consensus mechanism, RepuICN, is introduced, which enhances the network layer of the Casper FFG algorithm. This mechanism selects higher-reputation ICN consensus nodes as proposers for checkpoint blocks, mitigating the impact of network latency fluctuations on block propagation. Additionally, RepuICN improves block propagation efficiency through ICN multicast and caching techniques. Simulation results show that, under identical conditions with a network of 5000 nodes and 2% ICN nodes, RepuICN reduces broadcast latency by 17% for regular blocks and 61.4% for checkpoint blocks and achieves 3.4 times higher transaction throughput than Casper FFG.

1. Introduction

Since its inception by Nakamoto in 2009, blockchain technology has demonstrated significant potential across various sectors, including finance, the Internet of Things, and healthcare, due to its decentralized nature, anonymity, and immutability [1,2,3]. Despite these advantages, traditional blockchain systems like Bitcoin face considerable scalability challenges due to their inefficiencies and high energy consumption [4]. For instance, Bitcoin’s average transaction throughput of only seven transactions per second is inadequate for high-performance transactional services [5].

Transaction throughput (TPS) is a critical performance metric for blockchains, primarily influenced by block latency, which includes the time to generate and broadcast blocks. The block generation time is affected by the consensus layer of the blockchain, where researchers have proposed various novel consensus mechanisms to reduce computational complexity and energy consumption, such as Proof of Stake (PoS) [6] and Proof of Authority (PoA) [7], enhancing system scalability. On the other hand, block broadcast time has been optimized through improvements in the peer-to-peer (P2P) network’s topology and routing strategies, adopting structured network models like Kademlia [8] and Kadcast [9], to minimize transmission redundancy and optimize bandwidth utilization. These application-layer improvements are constrained by the end-to-end transmission design principles of the TCP/IP network, and thus, issues such as network congestion and bandwidth wastage persist during large-scale blockchain content distribution.

ICN [10,11] is an emerging network architecture that emphasizes information as the central element. It decouples content identifiers from locators and offers efficient content distribution mechanisms through features such as content-name-based addressing and routing, in-network caching, and multicast. These capabilities enhance the performance of blockchain systems.

As a result, ICN-based blockchain technologies [12,13,14,15] have garnered significant attention. When ICN nodes serve as blockchain nodes, they not only function as transmission “pipelines” for transactions and blocks but also directly participate in the consensus process. This implies that the network state of ICN nodes becomes a critical factor to be considered within the consensus mechanism.

However, existing consensus mechanisms do not sufficiently account for the network state of consensus nodes. Due to network heterogeneity, nodes with suboptimal network service quality and performance typically exhibit reduced block distribution capabilities, resulting in increased block broadcast delays. This, in turn, becomes a bottleneck in the consensus process.

To address this issue, we proposes a reputation-based hybrid consensus mechanism, RepuICN, built upon the ICN blockchain architecture. The mechanism aims to enhance the consensus efficiency of Ethereum’s Casper FFG by incorporating high-reputation ICN consensus nodes as proposers for checkpoint blocks. Specifically, this paper first introduces a multi-dimensional reputation model designed to evaluate the reputation of ICN consensus nodes. This model considers both on-chain stake (including node stake and block generation rate) and network contribution (encompassing network service quality and performance metrics). The model assesses the reputation of ICN consensus nodes from the perspectives of objective trust and historical trust, thereby providing the prior conditions for the RepuICN consensus mechanism.

Next, we improve the checkpoint block proposal process in Casper FFG by utilizing the reputation consensus mechanism to select ICN consensus nodes with superior network performance as proposers for checkpoint blocks. This approach reduces the impact of proposer network latency fluctuations on block propagation and leverages the capabilities of ICN to accelerate the distribution of checkpoint blocks. For conventional blocks, the traditional PoW/PoS proposal scheme is maintained to preserve network fairness while simultaneously improving consensus efficiency.

Simulation experiments demonstrate that the RepuICN consensus mechanism significantly enhances the consensus efficiency of blockchain systems. The main contributions of this paper include:

• The construction of a multidimensional reputation model within an ICN-based blockchain architecture, effectively reducing the likelihood of deceptive and malicious activities.
• The introduction of the RepuICN hybrid consensus mechanism, which not only considers system fairness but also enhances the stability and efficiency of Ethereum’s Casper FFG at the network layer.
• The conducted simulation experiments on the Jabs and SimBlock platforms demonstrate that, under identical conditions, the RepuICN system surpasses the Casper FFG protocol in several critical metrics: block broadcast latency, transaction throughput, network traffic bandwidth consumption, and network latency variability.

The structure of this paper is organized as follows: Section 2 reviews existing blockchain consensus mechanisms and the ICN network; Section 3 elaborates on the related system model and preliminary work; Section 4 details the reputation model and hybrid consensus mechanism; Section 5 analyzes the security and incentives; Section 6 presents the simulation experiment results; and Section 7 concludes the paper and looks forward to future research directions.

2. Related Works

2.1. Blockchain Consensus Mechanism

One of the core components of blockchain technology is the consensus mechanism, which ensures consistency among nodes in a distributed network. Since the emergence of Bitcoin [1], various consensus mechanisms have been proposed, including Proof of Work (PoW), PoS, and PoA. PoW is the consensus mechanism adopted by Bitcoin, wherein miners generate new blocks by solving complex mathematical problems [1]. However, block generation in PoW requires substantial computational power and introduces block confirmation delays, leading to inefficiency and low transaction throughput. The Bitcoin network’s transaction rate is only seven transactions per second [5], rendering PoW inadequate for real-world scenarios that demand high transaction rates and network scalability.

The PoS mechanism [6] alleviates the high energy consumption associated with PoW. For instance, Algorand [16] employs a pure PoS approach, where nodes are randomly selected to propose and validate blocks based on their stake, achieving high throughput and low latency with minimal energy use. The core idea of PoS is that the higher a user’s stake in the system, the more likely they are to obtain the right to record new blocks. Buterin and Griffith proposed the Casper [17] mechanism, which combines PoS with Byzantine fault-tolerant consensus theory in a partial consensus mechanism. A prominent example of BFT-based consensus is Tendermint [18], which uses PBFT to achieve deterministic finality in permissioned or small-scale networks, ensuring agreement despite faulty nodes. In Casper, new blocks are proposed through a cyclic block signing scheme under PoS, and mining is accomplished through voting. Cryptocurrency holders can become miners by staking their holdings in the system. Miners receive rewards when they generate or validate blocks on the main chain; if they violate the protocol, they are penalized [17]. Another extension of PoS is Delegated Proof of Stake (DPoS) [19], where miners are elected by other nodes, and voting is weighted according to each voter’s stake in the network. In DPoS, the number of block producers is fixed, and each round allows one participant to produce a block. If a miner does not act appropriately, they can be removed through community voting. While the DPoS mechanism enhances consensus efficiency, it also amplifies the influence of nodes with large stakes, promoting centralization. This exemplifies the well-known blockchain trilemma, which posits that a blockchain system cannot simultaneously achieve decentralization, security, and scalability [20,21].

To balance the decentralized nature of blockchain with consensus efficiency, several reputation-based consensus mechanisms have been proposed. PoA [7,22] combines elements of PoW and PoS by selecting a small number of authoritative nodes to participate in block generation based on their off-chain reputation. This mechanism is typically employed in private or permissioned blockchain environments. PoR [23] is another reputation-based consensus mechanism used in permissioned blockchains. It extends PoA by allowing only authorized nodes to participate in the consensus process. Moreover, PoR substitutes miner and cryptocurrency rewards with reputation-based incentives, encouraging nodes to engage in consensus activities. ReCon [24] selects a limited number of validator nodes based on external reputation rankings and improves the BFT consensus protocol. The mechanism updates node reputation scores based on the outcomes of the on-chain consensus process, thereby reducing the impact of Sybil attacks. BRBC [25] is a reputation-based consensus mechanism designed for private blockchain environments. It introduces node maturity as the standard for initial reputation, whereby nodes with longer network uptime have a higher chance of being selected as miners. Only consensus nodes with reputation scores exceeding a predefined threshold are permitted to participate in consensus. Randomly selected arbitrators monitor the behavior of participating nodes and update their reputation scores accordingly. For RPoC applied in permissioned blockchains,  ref. [26] proposes a two-layer consensus mechanism. The first layer consists of high-reputation and identity-verified nodes, while the second layer consists of randomly selected secondary nodes. This structure aims to balance consensus efficiency and fairness. Finally, FPoR [27] is a reputation-based consensus mechanism suitable for both permissioned and permissionless blockchains. It combines token staking to establish initial reputation and employs the PBFT protocol for consensus. It is evident that existing reputation-based consensus mechanisms are predominantly used in permissioned blockchain environments and largely rely on on-chain factors (such as consensus validation behavior, token staking, etc.) and off-chain authority (e.g., community or institutional identity verification). However, these mechanisms often overlook the network service quality and performance of consensus nodes, which limits the consensus efficiency due to the heterogeneity of the network. In contrast, RepuICN not only incorporates token staking and identity verification but also takes into account the network service quality and performance of consensus nodes. Additionally, RepuICN improves the Casper FFG protocol by adopting a hybrid consensus model that integrates reputation mechanisms with PoW/PoS, making it suitable for both public and permissioned blockchains.

Table 1. Comparison of reputation-based consensus mechanisms and RepuICN.

Protocol	Improvement	Blockchain Scenario
PoA [7,22]	PoW, PoS	Private/Permissioned
PoR [23]	PoA	Permissioned
ReCon [24]	BFT	Permissioned
BRBC [25]	PoW, PoS	Private
RPoC [26]	BFT, PoW	Permissioned
FPoR [27]	PBFT	Public/Permissioned
RepuICN	Casper FFG	Public/Permissioned

provides an overview of these consensus protocols and highlights the differences between RepuICN and existing mechanisms.

2.2. ICN

Traditional Internet Protocol (IP) addresses face semantic overload challenges, particularly in scalability, mobility, and security, rendering existing network architectures inadequate to meet the escalating demands of emerging application services. To address these issues, ICN architectures [10,11,28] have been proposed. By leveraging content naming and caching mechanisms, ICN enhances data transmission efficiency, aiming to overcome the inefficiencies inherent in traditional IP networks.

Furthermore, as hardware capabilities advance, network devices not only support routing and forwarding functions but are increasingly endowed with computing and storage capabilities. These resources, distributed across forwarding devices, can provide on-site computation and storage for autonomous networks, satisfying time-sensitive service requirements.

Equipped with these capabilities, ICN nodes leverage SDN technologies in the control plane, on-site forwarding capabilities in the data plane, and autonomous resolution services to support the deployment of various applications, including network-layer multicast, computing power, storage, and resolution services. This facilitates the provision of richer and more flexible network services [29]. Integrated systems of blockchain and ICN have been applied in fields such as the Internet of Things and 5G/6G, addressing issues of large-scale content distribution, data privacy protection, and identity authentication. Research indicates that blockchain systems can enhance the security of ICN by improving data authentication and identity management mechanisms [30,31,32,33]. Additionally, ICN can offer more efficient content distribution mechanisms, helping to alleviate the performance bottlenecks of blockchain networks [12,13,14].

3. Preliminaries and System Model

To elaborate on our research scheme, this section outlines the system model explored in this paper, along with its preliminary work. The proposed model is applicable to ICN that is compatible with IP. For ICN that does not support IP, connectivity is achieved through ICN gateway nodes that facilitate IP protocol conversion [34]. As illustrated in Figure 1, the system model incorporates three key components: ICN Blockchain Nodes (IBNs), IP Routers (Rs), and Blockchain Nodes (BNs) within the IP network. The IBNs, deployed within ICN, connect and exchange messages with BNs via P2P networks. These IBNs broadcast blocks and transaction messages using ICN multicast and caching technologies, thereby enhancing the propagation speed of blocks and messages across the network. This model supports public blockchains such as Bitcoin and Ethereum, as well as private and consortium blockchains for block storage and message distribution.

The system model primarily includes two core components: a reputation model and a hybrid consensus mechanism. The reputation model aims to assess the service quality and network performance of IBNs, whereas the hybrid consensus mechanism is utilized for electing proposer nodes to enhance consensus efficiency. As depicted in Figure 2, the reputation model is divided into two parts: reputation management and reputation verification. Reputation management involves the collection, validation, computation, and updating of reputation parameters for IBNs, facilitated by third-party trust entities and edge computing within the network. Reputation verification, on the other hand, entails the validation of IBN consensus nodes’ reputation values by blockchain nodes through third-party trust entities, thereby strengthening the system’s trustworthiness.

The hybrid consensus module enhances the Ethereum Casper FFG at the network layer. We have introduced a reputation-based hybrid consensus mechanism, PoR, which can serve as a reputation overlay for existing PoS/PoW consensus mechanisms, providing a tool for finality, as illustrated in the blockchain reference model shown in Figure 3. The yellow highlighted sections, ICN and PoR, represent modules added to the traditional blockchain network layer and consensus layer based on this paper. Under the Casper FFG architecture, our system adopts different consensus strategies for regular blocks and finality blocks. For regular blocks, IBNs and BNs reach consensus based on existing mechanisms (PoW/PoS), whereas for finality blocks, IBNs select ledger nodes with higher reputations from within the reputation model. Blockchain nodes authenticate the identities of IBN ledger nodes through third-party trust organizations and verify the legitimacy of blocks. By selecting ICN consensus nodes with superior network service quality and performance to handle the generation and delivery of finality blocks, the system balances fairness while enhancing the scalability and consensus efficiency of the blockchain network.

It is essential to highlight that the core of the system model revolves around the development of a multidimensional reputation assessment model. This model facilitates the design of a reputation-based hybrid consensus algorithm, aimed at selecting ICN consensus nodes with superior network service quality and performance as proposer nodes for checkpoint blocks, thereby enhancing consensus efficiency. Related techniques, such as the specific methods for verifying trust data within the reputation model, can be integrated with existing relevant works. These include verification through trusted hardware, SDN technologies, blockchain smart contracts, and third-party trust entities.

The subsequent sections will provide a detailed discussion on the design of the reputation model and the reputation-based hybrid consensus mechanism.

4. Design

4.1. Reputation Model

Existing research frequently introduces behavior-based reputation models to enhance the efficiency of blockchain consensus mechanisms [7,22,24]. However, these models primarily focus on nodes’ performance in blockchain transactions and community contributions, often relying on on-chain and off-chain activities or subjective evaluations by other nodes while neglecting specific performance metrics at the network layer. This approach fails to fully consider the heterogeneity of nodes within the network, particularly those with lower network service quality and performance, which may become bottlenecks in the blockchain consensus process.

Figure 4 illustrates our proposed multidimensional reputation model for a blockchain architecture based on ICN. This model comprises three main components: reputation evaluation dimensions and parameter selection, reputation processing, and reputation output.

• Reputation Evaluation Dimensions and Parameters: We assess the reputation of ICN consensus nodes by integrating blockchain stakes, network service contributions, and historical performance from the perspectives of objective trust and historical trust.
• Reputation Processing: This phase involves correcting reputation value increments in each update cycle using a logistic growth model and applying a reputation decay mechanism based on the Ebbinghaus forgetting curve to historical reputation. These measures help prevent Sybil attacks and whitewashing attacks.
• Reputation Output: The reputation output includes the initial reputation and cumulative reputation. The initial reputation assigned when a node joins the network depends on its stake in the blockchain. The cumulative reputation is the long-term accumulation of the node’s performance in the network, comprising corrected objective trust and decayed historical trust.

This hierarchical reputation model systematically evaluates and updates nodes’ reputation values in a distributed network, providing a dynamically adaptive and robust framework for enhancing the security and efficiency of ICN.

Based on the above structure, the formula for a node’s reputation value is expressed as:

$$R\left(t\right)=\left\{\begin{array}{cc}{R}_0,\hfill & \mathrm{if}t=0\hfill \\ \sigma ·R(t-T_R)+f\left(t\right)·\Delta R\left(⌊{\displaystyle \frac{t}{T_R}}⌋\right),\hfill & \mathrm{if}t>0\hfill \end{array}\right.$$

(1)

To simulate actual update cycles, we define $n=⌊{\displaystyle \frac{t}{T_R}}⌋$. The discrete form becomes:

$$R\left(n\right)=\sigma ·R(n-1)+f\left(n\right)·\Delta R\left(n\right)$$

(2)

where:

• $R\left(t\right)$: Reputation value at time t.
• $R_0$: Initial reputation value when the node joins, defined as $R_0=R_c\left(0\right)$, determined by the node’s initial on-chain stake.
• $\sigma$: Exponential decay factor for historical reputation.
• $T_R$: Reputation update cycle (a fixed interval).
• $n=⌊{\displaystyle \frac{t}{T_R}}⌋$: Number of completed reputation update cycles by time t.
• $\Delta R\left(n\right)$: Reputation increment during interval n, comprising the blockchain stake increment $\Delta R_c\left(n\right)$ and the ICN network contribution increment $\Delta R_i\left(n\right)$.
• $f\left(n\right)$: Logistic growth function evaluated at the n-th interval.

We now provide a detailed introduction to the hierarchical structure of the reputation model.

4.1.1. Reputation Evaluation Dimensions and Parameter Selection

We evaluate the reputation of ICN consensus nodes along two dimensions: objective trust and historical trust. For objective trust, we use quantitative standards to reduce the risk of collusion attacks arising from subjective evaluations, thereby resisting conspiracies by fraudulent nodes. For historical trust, based on nodes’ accumulated contributions and behaviors, nodes must continuously participate in the blockchain and ICN network to ensure the continuity of their reputation, preventing Sybil attacks and whitewashing attacks. The specific parameter selection and calculations are as follows:

Blockchain Stake: The node’s blockchain contribution is quantified by its staking ratio and block generation rate. The blockchain reputation increment is expressed as:

$$\begin{array}{c}\hfill \Delta R_c\left(n\right)={\alpha }_P·P\left(n\right)+{\alpha }_B·B\left(n\right),\end{array}$$

(3)

where $\Delta R_c\left(n\right)$ is the reputation increment from blockchain stake during the n-th interval. $P\left(n\right)$ and $B\left(n\right)$ represent the proportions of the staked amount and the block generation rate within a reputation cycle $T_R$, respectively, and ${\alpha }_P$ and ${\alpha }_B$ are the weights for these factors. By using the staking amount ratio and block generation rate as evaluation indicators, we enhance the node’s commitment to the network and reduce the possibility of malicious attacks.

For new blockchain nodes joining the ICN network, the trust management system assigns an initial reputation based on blockchain contributions:

$$\begin{array}{c}\hfill R_0=R_c\left(0\right)={\alpha }_P·P_0+{\alpha }_B·B_0,\end{array}$$

(4)

where $P_0$ and $B_0$ are the staked amount and initial block generation rate upon joining.

ICN Network Contribution: The node’s comprehensive performance in the ICN network encompasses service quality and network performance. From the aspects of network Quality of Service (QoS) and network performance, we select parameters that affect the node’s performance when forwarding blocks. Within a reputation cycle $T_R$, the reputation increment from ICN contributions is calculated as:

$$\begin{array}{c}\hfill \Delta R_i\left(n\right)={\beta }_T·T\left(n\right)+{\beta }_F·F\left(n\right)+{\beta }_E·E\left(n\right)+{\beta }_C·C\left(n\right)\end{array}$$

(5)

where $\Delta R_i\left(n\right)$ is the reputation increment from ICN network contributions during the n-th interval. $T\left(n\right)$, $F\left(n\right)$, $E\left(n\right)$, and $C\left(n\right)$ represent the node’s average online rate, failure rate, traffic forwarding rate, and cache hit rate, respectively; ${\beta }_T$, ${\beta }_F$, ${\beta }_E$, and ${\beta }_C$ are the corresponding weights.

In terms of network QoS, parameters like average online rate and failure rate evaluate the node’s reliability and stability. For network performance, parameters like traffic forwarding efficiency and cache hit rate evaluate the node’s efficiency. Quantifying these indicators allows us to effectively assess service quality and performance, ensuring that nodes with excellent network performance participate in blockchain consensus, thereby enhancing consensus efficiency and block transmission reliability.

Combining the calculations for the node’s blockchain stake and ICN network contribution, the reputation value growth of the multidimensional objective reputation model within one cycle is:

$$\begin{array}{c}\hfill \Delta R\left(n\right)=\Delta R_c\left(n\right)+\Delta R_i\left(n\right).\end{array}$$

This formula reflects the comprehensive performance of nodes in on-chain activity and network service quality. The incremental reputation values $\Delta R\left(n\right)$ for different periods can be represented by the following matrix:

$$\left[\begin{array}{c}\Delta R\left(1\right)\\ \Delta R\left(2\right)\\ ⋮\\ \Delta R\left(n\right)\end{array}\right]=\left[\begin{array}{cccccc}P\left(1\right)& B\left(1\right)& T\left(1\right)& F\left(1\right)& E\left(1\right)& C\left(1\right)\\ P\left(2\right)& B\left(2\right)& T\left(2\right)& F\left(2\right)& E\left(2\right)& C\left(2\right)\\ ⋮& ⋮& ⋮& ⋮& ⋮& ⋮\\ P\left(n\right)& B\left(n\right)& T\left(n\right)& F\left(n\right)& E\left(n\right)& C\left(n\right)\end{array}\right]\left[\begin{array}{c}{\alpha }_P\\ {\alpha }_B\\ {\beta }_T\\ {\beta }_F\\ {\beta }_E\\ {\beta }_C\end{array}\right].$$

The parameter weights must be normalized to balance the influence of each factor in the reputation calculation, satisfying:

$${\alpha }_P+{\alpha }_B+{\beta }_T+{\beta }_E+{\beta }_C+{\beta }_F=1.$$

Note that this paper presents a design framework for the reputation model; specific parameter settings are adjustable based on application needs and are therefore not discussed.

Reputation parameters such as the staked amount and block generation rate can be directly verified through public blockchain data, ensuring transparency and traceability. For ICN network QoS and performance indicators such as average online duration, failure rate, traffic forwarding efficiency, and cache hit rate, existing research [35,36,37] provides a foundation for QoS measurement techniques in ICN. These indicators can be monitored and evaluated using network monitoring and performance testing tools, with edge computing resources handling data processing and verification. A third-party trusted institution oversees the final data audit to ensure objectivity and reduce risks of collusion attacks stemming from subjective evaluations.

Regarding historical reputation, nodes exhibiting improper behavior will lose all reputation values upon detection, and their identities will be blacklisted, prohibiting participation in subsequent consensus processes. This punitive mechanism helps prevent malicious behavior, ensuring network security and stability. Specific methods for detecting malicious nodes can be found in the existing literature [38,39]; they are not detailed here.

4.1.2. Reputation Processing

Reputation Value Correction

To effectively manage new nodes and the dynamic changes in their reputation values, we introduce a correction mechanism based on the Logistic Growth Model [40]. This mechanism ensures that new nodes experience slower reputation growth initially, preventing them or potential malicious nodes from quickly gaining disproportionately high reputation through minimal normal behavior, thereby increasing the cost of Sybil attacks. Over time, nodes with consistent good performance will see accelerated reputation growth, encouraging sustained high-quality behavior. Once a node’s reputation reaches a high level, the growth rate stabilizes, ensuring only consistently high-performing nodes maintain elevated reputation, contributing to network stability and trustworthiness.

The reputation correction uses the logistic growth function:

$$f\left(t\right)={\displaystyle \frac{L}{1+e^{-k(t-t_0)}}},$$

And its discrete form becomes:

$$f\left(n\right)={\displaystyle \frac{L}{1+e^{-k(n-n_0)}}},$$

where:

• $L:$ The theoretical upper limit of the reputation value, set to 1.
• $e:$ The base of the natural logarithm.
• $k:$ Parameter determining the growth rate.
• $t:$ Time or another cumulative behavior-related metric; n is the number of completed reputation update cycles by time t.
• $t_0:$ The inflection point where the reputation value reaches half of its maximum; $n_0$ is the number of completed reputation update cycles by time $t_0$.

This correction ensures that reputation growth aligns with actual performance, promoting a fair and stable network environment.

Reputation Value Update

To better reflect recent behaviors’ impact on reputation, we introduce a decay mechanism based on the Ebbinghaus forgetting curve [41].

This mechanism adjusts the influence of historical behavior on reputation, emphasizing recent performance. The forgetting curve is expressed as:

$$\sigma =e^{-\lambda T_R},$$

where:

• $\sigma$ is the memory retention rate.
• $\lambda$ is the forgetting rate controlling decay speed; the larger $\lambda$, the faster the decay.
• $T_R$ is the reputation update period.

This ensures that reputation dynamically reflects behavioral changes over time. The update mechanism is:

$$\begin{array}{cc}\hfill R\left(n\right)& =\sigma ·R(n-1)+f\left(n\right)·\Delta R\left(n\right)\hfill \\ \hfill & =e^{-\lambda T_R}·R(n-1)+{\displaystyle \frac{L}{1+e^{-k(n-n_0)}}}·\Delta R\left(n\right).\hfill \end{array}$$

(6)

Equation (6) represents the complete reputation update formula for a node. It is formulated by summing the decayed historical reputation $R(n-1)$ and the reputation increment $\Delta R\left(n\right)$ accrued during the update period, where the increment is adjusted by a logistic correction. If we assume constant increments $\Delta R\left(n\right)=\Delta R$ and no behavioral deterioration, as $n\to \infty$, the reputation correction function $f\left(n\right)\to L=1$, and the reputation $R\left(n\right)$ converges to:

$$\begin{array}{cc}\hfill R_{\infty }& =\underset{n\to \infty }{lim}R\left(n\right)=e^{-\lambda T_R}·R_{\infty }+\Delta R\hfill \\ \hfill & ={\displaystyle \frac{\Delta R}{1-e^{-\lambda T_R}}}.\hfill \end{array}$$

(7)

This formula provides the steady-state convergence value, where $\Delta R$ controls the increment per cycle, and $\lambda$ and $T_R$ control the decay speed. Adjusting these parameters affects the equilibrium point and convergence speed, influencing the final reputation score.

This decay mechanism ensures the system considers both recent and historical behaviors, encouraging continuous good conduct and improving fairness and timeliness.

4.1.3. Reputation Output

After implementing the correction and decay mechanisms, substituting into Equations (4) and (6), the node’s reputation update formula is:

$$R\left(n\right)=\left\{\begin{array}{cc}{R}_0\hfill & \mathrm{if}n=0,\hfill \\ e^{-\lambda T_R}·R(n-1)+{\displaystyle \frac{L}{1+e^{-k(n-n_0)}}}·\Delta R\left(n\right)\hfill & \mathrm{if}n>0.\hfill \end{array}\right.$$

(8)

Based on the above reputation model, we designed a simplified simulation to analyze the convergence behavior of a single node under different conditions. The node’s reputation value is set between 0 and 1. The simulation parameters used in the modeling process are shown in

Table 2. Simulation parameters.

Simulation Parameters	Value
Simulation tool	Python
$\Delta R$	0.1
L	1
k	0.5
$n_0$	50
$R_0$	0.01–0.1
Number of periods	200
$\lambda$	0.106

.

In Figure 5, we detail the evolution of the reputation model under different parameter settings. The observations are as follows:

• Logistic Model: Without using the logistic correction model, the reputation value grows approximately linearly in the early stages, as shown in the figure. Assuming a reputation consensus threshold of $2/3$, a system without the logistic correction model reaches the threshold in just 10 periods, whereas using the logistic model requires 62 periods. This design reduces the likelihood of nodes rapidly increasing their reputation through high initial values or early accumulation, thereby lowering the risk of Sybil attacks.
• Midpoint $n_0$ of the Logistic Function: The parameter $n_0$ determines the time at which the reputation value begins to grow rapidly. A larger $n_0$ delays the onset of rapid reputation growth.
• Initial Reputation Value $R_0$: $R_0$ has a significant impact on the reputation value in the early stages of the model but has less influence in the later stages.
• Slope k of the Logistic Function: The value of k primarily affects the growth rate of the function. A smaller k results in slower reputation growth and a gentler curve. As k increases, the reputation value increases more rapidly in the mid-term, and the function curve becomes steeper.

The above modeling and analysis reveal the impact of different parameters on the reputation model. Through graphical curves, we emphasize the importance of the logistic correction model and the reputation decay strategy in preventing Sybil attacks and reputation manipulation. Overall, the design of our reputation model effectively enhances the fairness and security of the system.

In the next section, we will introduce the hybrid consensus mechanism design based on this reputation model.

4.2. Hybrid Consensus Mechanism

To address the inefficiency of existing consensus mechanisms in handling network heterogeneity, we introduce a hybrid consensus mechanism based on a reputation model. The hierarchical design of the hybrid consensus module is illustrated in Figure 6. This mechanism builds upon the Casper FFG and the the Latest Message Driven Greedy Heaviest Observed Subtree (LMD GHOST) fork-choice rule. By incorporating a reputation-based consensus mechanism for checkpoint blocks, we enhance the checkpoint block proposal process in Casper FFG. Simultaneously, traditional proposal mechanisms (PoW/PoS) are employed for regular blocks. This design overlays an additional layer of reputation-based consensus on existing proposal mechanisms, effectively improving consensus efficiency while ensuring the fairness of the blockchain system.

The block structure of the specific consensus mechanism is depicted in Figure 7. In Ethereum’s Casper FFG, time is divided into multiple epochs based on the number of blocks, with each epoch containing multiple blocks. In each epoch, the block created in the first slot serves as a checkpoint. If a checkpoint receives votes from more than two-thirds of validators by the end of the epoch, it is finalized. In this mechanism, Proof of Work (PoW) is used for producing regular blocks, while PoS is employed for producing checkpoint blocks to achieve network finality. Validators vote to confirm checkpoint blocks, aiming to leverage the efficiency and environmental friendliness of PoS while maintaining the high security and decentralization provided by PoW. However, this consensus mechanism does not resolve the inefficiency caused by network heterogeneity; nodes with lower network capabilities become bottlenecks in block production and propagation, thereby reducing consensus efficiency.

In the block structure of the hybrid consensus mechanism proposed in this study, PoW/PoS is used for producing regular blocks, while Proof of Reputation (PoR) is utilized for producing checkpoint blocks to achieve network finality. The reputation-based consensus mechanism selects ICN consensus nodes with superior network service quality and performance as block proposers responsible for creating checkpoint blocks. Unlike Casper FFG, which selects proposers through a random algorithm, our method employs the PoR consensus mechanism to reduce the likelihood of proposer nodes experiencing network latency fluctuations. By utilizing ICN consensus nodes as proposers, we can leverage ICN’s multicast and caching technologies to accelerate block dissemination, thereby expediting network finality and enhancing consensus efficiency.

4.2.1. Reputation Consensus Mechanism

This section details the reputation consensus mechanism, which aims to select nodes with high service quality and network performance from ICN consensus nodes as checkpoint proposers in the blockchain network. Unlike traditional PoS mechanisms that rely solely on random selection based on staked amounts, the reputation consensus mechanism elects block proposers based on nodes’ reputation values; nodes with higher reputation values have a greater probability of being selected. Additionally, by limiting the number of nodes that can become checkpoint proposers in each cycle, we mitigate attacks from malicious nodes. Restricting the number of consensus nodes also reduces the network load during the broadcast of consensus messages, improving node reliability and broadcast efficiency.

The reputation consensus mechanism employs BFT [42] and Boneh–Lynn–Shacham (BLS) aggregate signature techniques [43,44], similar to those utilized in Ethereum’s PoS system. These methods ensure voting consistency and reduce computational costs; detailed discussions of these techniques are beyond the scope of this paper.

Ethereum measures time using slots and epochs: each slot lasts 12 s, and 32 slots constitute an epoch $T_E$, totaling approximately 6.4 min [45]. In the first slot of each epoch, a checkpoint block is created by high-reputation ICN consensus nodes. The reputation update cycle $T_R$ spans $N_s$ epochs, i.e., $T_R=N_s\times T_E$, where $N_s$ also denotes the number of checkpoint proposers selected in each cycle. To prevent manipulation attacks, the selection of checkpoint proposers is made one cycle in advance.

As illustrated in Figure 8, the reputation consensus mechanism operates as detailed in Algorithm 1, proceeding through the following steps:

• Initialization: Each ICN consensus node i is required to stake at least 32 ETH and possesses a reputation score $R_i$ recorded in a smart contract. These reputation scores are used to weight the probability of nodes being selected as proposers. The set of all reputation nodes is initialized as $\mathcal{R}=\{i\mid R_i\}$, with a cardinality of $N_R=\left|\mathcal{R}\right|$. The duration of each epoch is set to $T_E$, and the reputation update period is defined as $T_R=N_s\times T_E$, with $N_s$ signifying the number of epochs between reputation updates.
• Proposer Selection: Utilizing the pseudorandom algorithm RANDAO weighted by reputation scores $R_i$, $N_s$ checkpoint proposers are selected from the set $\mathcal{R}$. Each proposer $p_j$ is randomly assigned to an epoch $E_j$, and all selected proposers form the set $\mathcal{P}$ with cardinality $N_s=\left|\mathcal{P}\right|$.
• Checkpoint Block Creation: In the first slot of their assigned epoch $E_j$, each proposer $p_j$ is responsible for creating and publishing a checkpoint block $b_j$. Proposers who fail to create a block within the specified time or create more than one block are penalized to maintain protocol integrity.
• Block Validation: For each checkpoint block $b_j$, a validator committee ${\mathcal{V}}_j$ is selected using RANDAO from all validators in the network. The validators in ${\mathcal{V}}_j$ validate $b_j$, and if agreement among them is less than ${\displaystyle \frac{2}{3}}$, the block is marked as invalid in accordance with BFT principles. Otherwise, the block is accepted as valid.
• Reputation Update: At every reputation update cycle $T_R$, when the current time t satisfies $tmod{T}_R=0$, the reputation scores $R_i$ for all nodes in $\mathcal{R}$ are updated. This ensures that the reputation data remains accurate and reflects the latest state of node participation and behavior.

Algorithm 1 Reputation Consensus Mechanism

Require: Each ICN consensus node i stakes at least 32 ETH and has a reputation score Ri Ensure: Secure and fair creation and validation of checkpoint blocks   1: Initialize the set of reputation nodes $\mathcal{R}=\left\{i\right|R_i\}$, with cardinality $N_R=\left|\mathcal{R}\right|$   2: Define the set of checkpoint proposers $\mathcal{P}$, with cardinality $N_s=\left|\mathcal{P}\right|$   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 bj 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 ${\displaystyle \frac{2}{3}}$ then 26:       Mark $b_j$ as invalid 27:      else 28:       Mark $b_j$ as valid 29:      end if 30: end for 31:     ​ 32: Reputation Update: 33: if Current time t satisfies $tmod{T}_R=0$ then 34:      Update reputation scores $R_i$ for all nodes in $\mathcal{R}$ 35: end if

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),$$

(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.

To balance these trade-offs and enhance system security and stability, we employ a reputation threshold based on principles from BFT consensus mechanisms [24]. Specifically, we set a threshold $\theta$ (commonly $\theta ={\displaystyle \frac{2}{3}}$) to ensure that the cumulative reputation of the selected nodes represents a supermajority of the total reputation, thereby maintaining robustness even if up to one-third of the nodes are faulty or malicious.

The threshold condition is expressed as:

$${\displaystyle \frac{R_s}{R_{\mathrm{total}}}}={\displaystyle \frac{{\sum }_{i=1}^{N_s}{R}_i}{{\sum }_{j=1}^{N_R}{R}_j}}\ge \theta ,$$

(10)

where:

• $R_s$ is the total reputation of the $N_s$ selected nodes;
• $R_{\mathrm{total}}$ is the total reputation of all $N_R$ candidate nodes;
• $N_R$ is the total number of candidate reputation nodes competing for selection as checkpoint proposers;
• $R_i$ and $R_j$ are the reputation scores of the selected nodes and candidate nodes, respectively.

Equation  (10) specifies that, to ensure network fairness, the cumulative reputation of the nodes selected during each reputation consensus period $T_R$ must constitute at least a fraction $\theta$ of the total reputation. Assuming the average reputation of the selected nodes is ${\overline{R}}_s={\displaystyle \frac{R_s}{N_s}}$, we can rearrange Equation (10) to solve for the minimum number of selected nodes $N_s$:

$$\begin{array}{cc}\hfill {\displaystyle \frac{N_s\times {\overline{R}}_s}{R_{\mathrm{total}}}}& \ge \theta ,\hfill \\ \hfill N_s& \ge {\displaystyle \frac{\theta \times R_{\mathrm{total}}}{{\overline{R}}_s}}.\hfill \end{array}$$

(11)

Since $T_R=N_s\times T_E$ from Equation (9), we can express the minimum reputation update period $T_{R_{\min }}$ as:

$$T_{R_{\min }}=N_s\times T_E\ge {\displaystyle \frac{\theta \times R_{\mathrm{total}}}{{\overline{R}}_s}}\times T_E.$$

(12)

Substituting $T_E=N_C\times T_B$:

$$T_{R_{\min }}\ge {\displaystyle \frac{\theta \times R_{\mathrm{total}}}{{\overline{R}}_s}}\times N_C\times T_B.$$

(13)

For $\theta ={\displaystyle \frac{2}{3}}$, $N_C=32$, and $T_B=12$ s, the minimum reputation update period becomes:

$$T_{R_{\min }}\ge {\displaystyle \frac{2}{3}}\times {\displaystyle \frac{R_{\mathrm{total}}}{{\overline{R}}_s}}\times 32\times 12\mathrm{s}.$$

(14)

By ensuring that $T_R$ meets or exceeds $T_{R_{\min }}$, we maintain a high level of trust and security in the system, even in the presence of faulty or malicious nodes. This approach balances the trade-offs between network efficiency, fairness, and security, aligning with the principles of BFT consensus mechanisms.

4.2.3. Fork Choice and Finality

This study adopts the LMD GHOST protocol for fork choice. Ordinary validators verify the legitimacy of checkpoint proposers’ reputation values by combining on-chain staking data and verification from trusted third-party institutions and subsequently validate checkpoint blocks. When a checkpoint block receives support and approval from more than two-thirds of validators, the checkpoint is considered justified. According to the Casper FFG protocol, if a justified checkpoint A is followed by another justified checkpoint B in subsequent epochs, then checkpoint A is finalized.

5. Security and Incentive Analysis

5.1. Security Analysis

In this study, we propose a multidimensional reputation evaluation model that integrates both on-chain stake and network contribution, aiming to mitigate potential malicious behaviors by reputation nodes. When a reputation node exhibits dishonest behavior, its reputation score is reset to zero, the node is blacklisted, and all funds staked by the node in the blockchain are confiscated. This rigorous punitive mechanism effectively deters malicious activities and safeguards the security and stability of the network.

5.1.1. Collusion Attacks

Collusion attacks refer to scenarios in which multiple nodes conspire to manipulate the system for mutual benefit. In RepuICN, high-reputation ICN nodes are selected as proposers for checkpoint blocks. Should multiple high-reputation nodes collude, they may attempt to propose invalid checkpoint blocks or manipulate reputation scores.

• Invalid Checkpoint Blocks: The validation of checkpoint blocks in RepuICN is conducted independently by nodes randomly selected from the peer-to-peer network based on the RANDAO protocol. The transparency of on-chain data ensures that reputation nodes cannot artificially enhance their blockchain contribution through data fabrication.
• Network Contribution Assessment: The evaluation of network contribution relies on objective measurements of network performance and quality of service, with the corresponding data provided by certified third-party institutions. This approach hinders colluding nodes from elevating their reputation scores via data falsification without detection.

5.1.2. Sybil Attacks

A Sybil attack involves an adversary creating multiple fraudulent identities to gain undue influence within the network. In the proposed reputation computation model, a time-decay model and a correction mechanism are incorporated, requiring nodes to accumulate and maintain high reputation scores through sustained honest participation. Consequently, attackers are impeded from rapidly establishing numerous fake identities to acquire high reputation scores, as each identity must demonstrate continuous positive contributions. Moreover, the integration of on-chain staking (e.g., the staked amount) imposes significant economic costs on Sybil attacks, necessitating substantial resource investment for each fraudulent node and further elevating the attack’s difficulty.

5.1.3. Malicious Behavior by Reputation Nodes

Although ICN reputation nodes undergo identity verification by third-party authoritative institutions to ensure a degree of security, high-reputation nodes may still engage in malicious activities, such as proposing invalid checkpoint blocks or attempting to disrupt the consensus process. Such behaviors could adversely affect the system’s performance and security. RepuICN employs the following countermeasures:

• Punishment for Dishonest Behavior: Upon detection of malicious actions, the offending node’s reputation score is reset to zero, it is added to a blacklist, and its staked funds are confiscated. This stringent punitive mechanism effectively discourages malicious behavior.
• Casper FFG Voting Mechanism: In the Casper FFG protocol, checkpoint blocks must be approved by validator votes, and only blocks that obtain a sufficient quorum are ultimately confirmed. Thus, even if a malicious reputation node proposes an invalid block, it will not be accepted unless the majority of network validators are compromised.
• Redundancy and Timeout Mechanisms: To mitigate proposal delays or interruptions caused by malicious nodes, the system incorporates a timeout mechanism and selects alternative proposers from the pool of high-reputation nodes, ensuring the continuity and stability of the consensus process.

5.2. Incentive Analysis

Incentive mechanisms are central to the design of blockchain networks, driving node participation and ensuring long-term stability and fairness. RepuICN, as a reputation-based hybrid consensus mechanism, allows high-reputation ICN nodes to propose checkpoint blocks and receive additional rewards. This section analyzes, from a game-theoretic perspective, how RepuICN ensures long-term participation, maintains fairness, and incentivizes good behavior while deterring malicious actions through economic rewards.

According to the implementation standards of Ethereum’s Beacon Chain [46], proposers receive 12.5% of the total block reward [47]. In contrast to Ethereum’s use of RANDAO [48] to randomly select proposers, RepuICN prioritizes the selection of ICN nodes with superior network service quality and performance to propose checkpoint blocks, focusing more on efficiency and contribution incentives.

5.2.1. Incentives for Long-Term Participation

• Reputation and Rewards: Nodes accumulate reputation through sustained honest participation and high service quality, earning proposal rewards to incentivize long-term involvement.
• Penalty Mechanism: Malicious actions (e.g., invalid proposals) result in reputation loss and staked assets being forfeited, thus ensuring honest behavior.
• Dynamic Balance: Regular blocks select proposers randomly, preventing monopolization by high-reputation nodes and encouraging broad participation.

5.2.2. Fairness and Decentralization

• Hybrid Consensus: Proposal rights for regular blocks are open to all nodes in the network, preventing resource centralization.
• Objective Evaluation: The reputation of nodes is determined by on-chain assets and the network contributions measured by third parties, ensuring fairness.
• Flexible Adjustment: The reward ratio and checkpoint interval parameters are adjustable based on specific network applications, further optimizing reward distribution for network proposers while balancing efficiency and decentralization.

5.3. Fairness Analysis

In traditional PoS mechanisms, block proposers are selected from validators through the RANDAO random selection algorithm, with the probability of selection being proportional to the amount of staked tokens. However, in real-world networks, entities with greater stakes can increase their chances of proposal selection by deploying additional validators, leading to fairness concerns associated with the concentration of wealth.

In contrast, the RepuICN mechanism selects proposers for checkpoint blocks based on the network performance of ICN consensus nodes, with higher-performing nodes having a greater likelihood of being chosen. While this mechanism may result in better-performing nodes receiving more rewards, it also introduces the risk of centralization. However, RepuICN addresses this concern in two ways. First, the proposal mechanism for regular blocks remains the same as that of Casper FFG, with reputation-based consensus applied only to checkpoint blocks, which account for a small fraction (1/32) of the total blocks. Additionally, the interval between checkpoint blocks can be adjusted to strike a balance between efficiency and fairness. Second, higher-performing nodes contribute more significantly to the consistency of network messages, and the rewards they receive can be viewed as a form of contribution-based fairness.

6. Evaluation

This section presents a simulation-based evaluation of RepuICN’s performance. We first describe the experimental setup and assumptions, including platform configuration, implementation, and evaluation metrics. Then, we compare the RepuICN protocol with the Casper FFG consensus protocol and provide a comprehensive analysis of the simulation results.

6.1. Experimental Setup

6.1.1. Implementation

Conducting experiments on actual public blockchain networks is challenging; therefore, we utilize simulation experiments based on JABS [49] and SimBlock [50,51] to validate our theoretical analysis. JABS is an open-source platform that supports multiple new consensus algorithms, while SimBlock is an event-driven blockchain network simulator that allows all nodes in the network to generate messages and block times. We implemented the RepuICN protocol on JABS to evaluate its performance in terms of block propagation delay, transaction throughput, and bandwidth consumption within an Ethereum network scenario. Additionally, we simulated the impact of proposer node network latency fluctuations on block propagation delay using SimBlock.

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. Specifications of experimental software and hardware.

Software and Hardware	Version/Model
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 IntelliJ 2024.3.4
Programming Languages	Python 3.10 and Java 17.0.1

.

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. Network simulation parameter settings.

Parameter	Value
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	Etherscan [58]
Network Latency	WonderNetwork [56]
Network Bandwidth	testmy.net [59]

.

Evaluation Metrics

To assess the performance optimization of RepuICN 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. 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 nodes. 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.

6.2. 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.

Figure 10d illustrates the impact of varying the proportion of ICN nodes and network size on the broadcast delay optimization rate under 90% broadcast coverage. The network size ranges from 5000 to 15,000 nodes. As changes in network size induce topological variations, which in turn affect broadcast delay, the vertical axis represents the broadcast delay optimization rate of RepuICN relative to Casper FFG. This normalization helps mitigate the influence of topological changes. From the figure, it is evident that for a given network size, a higher proportion of ICN nodes leads to a greater optimization rate in broadcast delay for RepuICN. Although increasing network size introduces fluctuations in the optimization rate due to topological changes, the overall trend indicates that the broadcast delay optimization rate of RepuICN, compared to Casper FFG, increases with larger network sizes.

6.2.2. Transaction Throughput

In the CasperFFG protocol, block generation time is set at 12 s, and assuming a uniform transaction count per block, the transaction throughput remains consistent. For comparative purposes, we compute the throughput of RepuICN by analyzing the proportion of time taken for final confirmation of checkpoint blocks. In Ethereum, checkpoint blocks require validation by over two-thirds of validators to be considered valid. Figure 11 illustrates the variations in transaction throughput across different ICN node ratios and their associated errors. The gray dashed line in the figure represents the reference throughput line for Casper FFG. As the proportion of ICN nodes increases, the average transaction throughput of RepuICN also shows a progressive increase, and the standard deviation of throughput decreases, indicating enhanced stability in TPS. Notably, when the ICN node ratio reaches 2%, the TPS of RepuICN is 3.4 times that of Casper FFG. However, it is crucial to acknowledge that while an increase in ICN nodes can enhance throughput, it may also pose a risk of network centralization. When ICN nodes serve as relay nodes in the network, a higher proportion of ICN nodes reduces the impact of P2P node configurations on overall network performance. As a result, the network’s operation becomes increasingly dependent on the stability of ICN nodes rather than the collaborative participation of P2P nodes. Should ICN nodes fail or be subject to malicious control, the stability and security of the network could be severely compromised, leading to potential centralization risks. Therefore, a careful balance between efficiency gains and the preservation of decentralization is essential.

6.2.3. Bandwidth Consumption

In this study, we maintain the P2P network structure while comparing network traffic consumption under various protocols. Figure 12 illustrates the bandwidth consumption of the entire network over a fixed period as the proportion of ICN nodes increases. At an ICN node ratio of 0%, the bandwidth consumption corresponds to that observed under the Casper FFG protocol. The histogram in the figure distinguishes between the bandwidth consumed by P2P networks, represented in grey, and that by ICN networks, shown in orange. The results indicate that an increase in the ICN node ratio leads to a progressive reduction in the total network bandwidth consumption, while the bandwidth consumption of the ICN network exhibits a slow linear increase. Specifically, a 10% ICN node ratio results in a 3.2% reduction in overall network bandwidth consumption; at a 30% ratio, this reduction reaches 17.7%. This decreasing trend becomes more pronounced with higher ICN node ratios, primarily due to the caching mechanism within the ICN layer of RepuICN, which significantly lowers the total network traffic. However, when the ICN node ratio is below 10%, the difference in network bandwidth consumption between RepuICN and Casper FFG is negligible, with P2P network traffic constituting the majority of the total network bandwidth. This minimal impact is attributed to the consistent P2P network topology between ICN nodes and external IP nodes. Although optimizing the P2P network topology between ICN nodes and IP nodes could reduce bandwidth consumption further, such enhancements are beyond the scope of this study and may be explored in future research.

6.2.4. Impact of Network Latency Fluctuations on Propagation Time

We evaluated the performance of RepuICN relative to the Casper FFG protocol under conditions of network latency variability in proposer nodes. Employing the SimBlock simulation platform, we executed blockchain network simulations maintaining consistent P2P network conditions. To isolate the influence of external network factors, ICN functionality within RepuICN was disabled, and the simulation comprised 15,000 blockchain nodes.

Figure 13 illustrates the correlation between the coverage rate of nodes that received the broadcast block and the average propagation time across varying rates of network latency in proposer nodes. The horizontal axis indicates the node coverage rate, while the vertical axis denotes the average propagation time. The data indicate that an increase in the network latency of proposer nodes leads to a proportionate increase in block propagation delays within the Casper FFG protocol compared to RepuICN. Specifically, a latency increase to 1.5 times the baseline results in a $5.54\%$ longer propagation time for the Casper FFG protocol to reach $90\%$ of the network nodes. At a latency increase to twice the baseline, this delay escalates to $22.12\%$. Additionally, simulations were conducted to evaluate the impact of network latency variations among non-proposer nodes; however, these fluctuations had a minimal effect on the block propagation time to $90\%$ of nodes.

In conclusion, while the network latency fluctuations of individual non-proposer nodes exert a negligible influence on the propagation time required to reach the majority of nodes, latency variations in proposer nodes substantially impede the efficiency of block propagation. Notably, a latency increase to 1.5 times the baseline prolongs the time required to broadcast blocks to $90\%$ of network nodes by $5.54\%$, and this delay amplifies with further increases in latency. These findings underscore the superior resilience of RepuICN to network latency fluctuations compared to the Casper FFG protocol.

Overall, the RepuICN protocol outperforms the Casper FFG protocol in finalized block propagation delay, transaction throughput, network bandwidth consumption, and block propagation time under network latency fluctuations, showcasing RepuICN’s comprehensive performance advantages.

7. Conclusions

This paper presents a multi-dimensional reputation model based on network state information and a reputation-based hybrid consensus mechanism, RepuICN, built upon an ICN blockchain architecture. This approach introduces high-reputation ICN consensus nodes as proposers for checkpoint blocks, thereby mitigating the impact of proposer network latency fluctuations on block propagation. Additionally, leveraging the inherent characteristics of ICN accelerates the distribution of checkpoint blocks, significantly enhancing the consensus efficiency of Ethereum’s Casper FFG protocol. For regular blocks, the traditional PoW/PoS proposal mechanism is maintained, ensuring network fairness while improving consensus efficiency. RepuICN is particularly applicable to public or consortium blockchains based on the Casper FFG protocol.

Experimental results demonstrate that, under identical conditions, RepuICN outperforms the Casper FFG protocol in terms of block broadcast delay, transaction throughput, network traffic bandwidth consumption, and block broadcast time under network latency fluctuations.

Although the RepuICN protocol has exhibited strong performance in simulations, several challenges remain to be addressed in future research. These include the security and centralization issues introduced by the incorporation of ICN consensus nodes, as well as the integration and deployment challenges associated with ICN in blockchain infrastructure.

Future work could further optimize RepuICN to support additional consensus protocols and address broader application needs. Furthermore, the deployment and implementation of RepuICN in practical environments, such as IoT and 5G/6G networks, should be explored to facilitate its adoption across a wider range of application scenarios.