# Reputation Consensus Mechanism for Blockchain Based on Information-Centric Networking
## 4 Design
### Hybrid Consensus Mechanism
#### 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}=|\mathcal{R}|\). 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}=|\mathcal{P}|\). * 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 \(\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 \(t\bmod 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.