RVR Blockchain Consensus: A Verifiable, Weighted-Random, Byzantine-Tolerant Framework for Smart Grid Energy Trading

Abstract

Blockchain technology empowers decentralized transactions in smart grids, but existing consensus algorithms face efficiency and security bottlenecks under Byzantine attacks. This article proposes the RVR consensus algorithm, which innovatively integrates dynamic reputation evaluation, verifiable random function (VRF), and a weight-driven probability election mechanism to achieve (1) behavior-aware dynamic adjustment of reputation weights and (2) manipulation-resistant random leader election via VRF. Experimental verification shows that under a silence attack, the maximum latency is reduced by 37.88% compared to HotStuff, and under a forking attack, the maximum throughput is increased by 50.66%, providing an efficient and secure new paradigm for distributed energy trading.

1. Introduction

As a fundamental component of the emerging energy paradigm, the smart grid amalgamates communication technology, information technology, and power infrastructure [1,2,3], enabling intelligent coordination across energy production, transmission, and consumption domains. Its decentralized energy trading model effectively orchestrates distributed energy resources [4], such as electric vehicles, thereby enhancing the utilization of renewable energy sources and minimizing operational costs [5]. Nonetheless, open transaction architectures are susceptible to security vulnerabilities, including data tampering and man-in-the-middle attacks, underscoring the pressing necessity for an efficient and resilient trust management mechanism. The decentralized characteristics and tamper-resistant properties of blockchain technology [6] present promising solutions to these security challenges [7].

This research introduces the Reputation-VRF-Roulette (RVR) consensus framework, which is designed to achieve three primary objectives:

(1)

A dynamic reputation model to evaluate behavior in real time;

(2)

A VRF-driven leader election mechanism that is resistant to Byzantine manipulation;

(3)

A universal protocol to support multi-energy transactions.

The RVR framework facilitates collaborative optimization of security and efficiency, addressing the bottlenecks associated with traditional chain consensus mechanisms.

This research addresses a fundamental challenge in the design of consensus mechanisms that effectively balance efficiency and security to facilitate distributed energy trading within complex smart grid environments. It presents an innovative blockchain consensus paradigm that integrates both security and scalability for distributed energy transactions in smart grids. By employing dynamic reputation weights in conjunction with verifiable random functions (VRFs) [8], this approach mitigates the traditional performance limitations associated with chain consensus in the presence of Byzantine attacks, thereby providing methodological advancements to tackle the uncertainties related to node behavior in open systems. In comparison to existing frameworks such as PBFT [9] and PoW [10], the RVR framework achieves a collaborative optimization of malicious node suppression and random election for the first time, establishing a theoretical basis for high-concurrency energy trading scenarios. On a practical application level, the universal design of RVR accommodates coupled transactions involving various energy media, including photovoltaics, energy storage, and electric vehicles, thus broadening the applicability of blockchain technology within smart grids. Additionally, this framework offers reusable consensus design references for other distributed systems that require high-security measures, such as intelligent transportation systems and the industrial Internet of Things.

2. Literature Review

The equilibrium between security and communication efficiency remains a pivotal challenge in the domain of blockchain consensus research. The current literature can be classified into three primary categories: traditional Byzantine fault tolerance (BFT) algorithms, enhancements to chain-based consensus mechanisms, and optimizations tailored to specific applications. This section provides a systematic examination of their contributions and limitations, particularly in the context of energy trading within smart grids.

2.1. Traditional BFT Algorithms

The Bitcoin system designed by Satoshi Nakamoto uses the Proof of Work (PoW) consensus algorithm proposed by Jakobsson and Juels [10], which consumes a considerable amount of energy. The practical Byzantine fault tolerant (PBFT) algorithm [9] is a cornerstone of Byzantine fault tolerant systems, facilitating consensus among distributed nodes. Nonetheless, its communication complexity of O(n²) poses a considerable obstacle for deployment in large-scale networks. In light of this challenge, various optimization strategies have been proposed in subsequent research. For example, the Zyzzyva algorithm, developed by Kotla et al. [11], markedly improves consensus efficiency under normal operating conditions by distinguishing between fault-free and faulty scenarios. Building upon this foundation, the HoneyBadgerBFT algorithm, introduced by Miller et al. [12], incorporates a timing-based mechanism for handling Byzantine errors, effectively mitigating the timeliness issues associated with network latency. Furthermore, Zhang et al. [13] utilize sharding technology to divide the network into multiple committees for parallel transaction processing, thereby significantly enhancing system scalability. The Thunderella algorithm, proposed by Pass and Shi [14], innovatively employs state machine replication technology, substantially increasing transaction processing speed by reducing the repetitive identification tasks performed by honest nodes within the blockchain.

2.2. Innovations in Chain-Based Consensus

In response to scalability challenges, researchers have increasingly focused on chain-based designs. The SBFT algorithm [15] has successfully reduced communication overhead to O(N) while streamlining voting processes. HotStuff [16] has optimized leader rotation through a three-stage voting mechanism, augmented by threshold signature technology [17], achieving linear complexity during view switching. FastHotStuff [18] has further introduced aggregated quorum certificates (aggQCs) to minimize latency. However, these algorithms exhibit vulnerabilities in leader selection when subjected to Byzantine attacks, such as forking and silence attacks [19], which constrain their applicability in open peer-to-peer (P2P) energy trading systems.

2.3. Challenges Specific to Smart Grids

Although blockchain-based solutions for energy trading—such as token mechanisms [20] and decentralized charging [21]—have been explored, the majority of studies tend to focus on single-device scenarios or lack comprehensive frameworks. For instance, while Kumar et al. [22] proposed a hybrid EV trading model, their approach lacked dynamic reputation management mechanisms. Additionally, current consensus protocols encounter difficulties in balancing efficiency and security within multi-entity smart grids, particularly when malicious nodes disrupt leader elections.

2.4. Research Gaps

The existing literature reveals two notable gaps:

• Insufficient Byzantine-Resistant Leader Selection: The leader rotation mechanisms inherent in traditional chain consensus are vulnerable to targeted attacks.
• Scenario-Specific Limitations: A predominant focus on isolated energy types or devices restricts the applicability of findings to heterogeneous smart grid environments.

Our proposed RVR consensus framework seeks to address these gaps by integrating dynamic reputation evaluation with verifiable randomness, thereby ensuring both security and scalability in multi-energy trading contexts.

3. Methodology

3.1. Research Design

The primary aim of this research is to establish a blockchain consensus framework [23] that adeptly reconciles efficiency and security to promote decentralized energy trading within smart grids, particularly in the face of Byzantine attacks. The research methodology is organized into three distinct phases. First, a dynamic reputation model is developed to evaluate the trustworthiness of nodes in real-time, employing multi-dimensional behavioral metrics such as node activity, voting contribution, and compliance with behavioral norms. Next, a verifiable random function (VRF) is integrated to generate tamper-resistant global random numbers, which serve as the foundation for a reputation-weighted roulette wheel election mechanism [24]. Finally, simulation experiments are conducted to assess the performance advantages of the proposed framework in scenarios characterized by forking and silence attacks.

3.2. Dynamic Reputation Model

The dynamic reputation model is constructed to continuously recalibrate node trust values by formalizing multi-dimensional behavioral data. Node activity is quantified via nonlinear aggregation of the regional user base and transaction throughput, thereby reflecting real-time load conditions. Voting contribution is evaluated based on the number of valid votes cast, which quantifies participation in the consensus process. A behavioral reward-penalty mechanism is implemented to dynamically adjust reputation weight, applying exponential penalties for negative behaviors (e.g., timeout incidents) and linear rewards for positive actions (e.g., timely operations), thus effectively diminishing the impact of malicious nodes. The comprehensive reputation score integrates historical reputation data with real-time behavioral evaluations, ensuring that nodes with elevated reputations are prioritized during elections.

3.3. VRF-Driven Leader Election

The VRF-driven leader election mechanism is based on the generation of tamper-proof random numbers using the verifiable random function, which are combined with dynamic reputation weights to achieve a balance between fairness and security. The process is outlined as follows: (1) a third-party authority distributes the consensus private key; (2) nodes generate random numbers along with their corresponding verification proofs based on the current view value; (3) after independent validation of the random numbers, a roulette wheel algorithm is utilized to map reputation weights to probability intervals (for example, a node with a 30% reputation weight occupies the interval [0, 0.3)). This design ensures that election outcomes remain unpredictable while simultaneously prioritizing nodes with high reputations, thereby effectively countering Byzantine manipulation.

4. Security Model of Transaction System

4.1. System Model

The blockchain-based smart grid energy trading framework presented in this research consists of four interconnected layers: the entity layer, which enables the authentication of identities for both producers and consumers through unique identifiers (IDs) and public-private key pairs for energy transactions (Figure 1); the energy layer, which manages the injection and extraction of energy via distributed energy warehouses [25], dynamically authorized by service nodes to ensure the legitimacy of energy transmission; the service layer, which oversees transaction processing through various mechanisms, including information routing [26], Byzantine fault tolerance protocols [8], dual signature verification [27], payment amount matching [28], and block pool storage [29]; and the blockchain layer, which is collaboratively maintained by nodes to sustain an immutable distributed ledger. Within this framework, users at the entity layer (for example, Entity A and Entity B) connect to the distributed warehouses of the energy layer through designated energy interfaces. When Entity A initiates a transaction request, which includes its ID and a private key signature, the server disseminates this request throughout the network. In response, Entity B provides a signed confirmation, which the server validates to authenticate the identities involved [30]. Following this validation, the server instructs the energy layer to facilitate the transfer of energy from Entity B’s warehouse to Entity A’s through established energy links [25], with all transaction data being permanently recorded on the blockchain to ensure integrity and traceability.

4.1.1. Entity Layer

The composition unit includes transaction entities such as producers (e.g., power plants) and consumers (e.g., households and factories), which is defined as follows: $EL=\left\{E_1,E_2,\dots ,E_n\right\}$. The metadata structure of each Entity E_i is expressed as follows:

$$E_i=\left\{I{D}_i,P{K}_i,S{K}_i,balance,Energy Interface\right\}$$

(1)

where ID_i serves as a unique identifier that distinguishes various entities, such as power plants and users. PK_i refers to the public key utilized for encrypting data and verifying signatures, while SK_i denotes the private key employed for generating signatures and decrypting operations [30]. The term indicates the energy or currency balance of an account. The energy interface functions as an energy exchange interface that facilitates energy storage, extraction, and trading operations. The primary role of the entity layer is to interact with the energy warehouse via energy interfaces and to execute energy storage and transaction operations.

4.1.2. Energy Layer

An energy warehouse (EW) [25] is a distributed storage node that connects multiple entities to facilitate energy flow. It involves producer injection ($EW\leftarrow E{Q}_{\mathrm{produce}}$) and consumer extraction ($EW\leftarrow E{Q}_{\mathrm{consume}}$). The service node dynamically authorizes the interface permissions, and the verification equation is expressed as follows:

$$\mathrm{Access}\left(E_i\right)=Verify\left(S{K}_i,P{K}_{\mathrm{SN}}\right)$$

(2)

where PK_SN represents the public key of the service node, it is utilized to verify the legitimacy of the signature. This function confirms the authenticity of the entity’s identity by matching the correspondence between the private and public keys, thereby authorizing access operations.

4.1.3. Service Layer

The service layer mediates interactions between entities and the blockchain, ensuring transaction integrity and consensus execution. As depicted in Figure 2, it comprises four synchronized modules:

The information routing module (IM) forwards transaction requests from the Entity Layer to the consensus network.

The consensus control module (CM) implements the byzantine fault tolerance (BFT) protocol to ensure the integrity of the blockchain’s state.

The transaction verification module (VM) confirms the validity of the dual signature, ensuring that the energy quantity (EQ) corresponds to the payment amount (k).

The block pool storage (BP) verifies the transaction data and awaits block packaging.

4.1.4. Blockchain Layer

The blockchain layer functions as a decentralized and tamper-resistant distributed ledger [23], which is upheld by a network of nodes. It systematically documents transaction data within cryptographically interconnected blocks, employs digital signatures to verify authenticity, and incorporates an optimized architecture to ensure data integrity and secure synchronization in the context of energy trading.

4.2. Transaction Process

Transactions implement a two-phase atomic commitment protocol where Phase 1 (negotiation) establishes binding agreements via digitally signed offers/acceptances (Figure 1), and Phase 2 (execution) enforces settlement through pre-frozen funds verification, cryptographic energy escrow, and automated blockchain clearing (Figure 2), resolving the temporal asynchronicity between energy and financial transactions while guaranteeing atomicity and non-repudiation.

4.2.1. Transaction Negotiation

Energy consumers initiate transactions by broadcasting digitally signed requests containing their ID and energy demand (Figure 1). Producers respond with signed commitments that undergo service-layer signature verification, establishing binding agreements before execution.

$$TX\_Demand=\left\{I{D}_A,sig{n}_A\left(S{K}_A\right),E{Q}_{req}\right\}$$

(3)

Here, ID_A serves as the unique identifier for the transaction initiator (such as a user or power plant), and Sign_A (SK_A) represents a digital signature generated using a private key, which is used to verify identity and transaction legality. EQ_req denotes the requested amount of energy (such as electricity consumption or generation), facilitating transaction matching and settlement.

After confirming the intention to transact, Entity B sends a transaction response that includes a signed commitment.

$$TX\_Commit=\left\{I{D}_B,sig{n}_B\left(S{K}_B\right)\right\}$$

(4)

The verification module confirms participant identities by cryptographically validating attached signatures against registered public keys, ensuring that only authenticated entities proceed to transaction execution.

$$Verify\left(P{K}_A,sig{n}_A\right)\wedge Verify\left(P{K}_B,sig{n}_B\right)$$

(5)

The verification function is responsible for validating the signature [30] by employing a public key. It is essential that both parties successfully complete the verification process for the transaction to be considered valid. Additionally, the protocol for executing the transaction should only commence after the successful completion of identity verification.

4.2.2. Transaction Execution

The transaction execution phase constitutes the core operational workflow for energy settlement, ensuring atomicity and non-repudiation through cryptographic verification and distributed ledger coordination. As depicted in Figure 2, this process implements a three-stage commit protocol that synchronizes energy transfer with financial settlement while mitigating double-spending risks:

(1)

Pre-Freezing of Funds

Prior to energy release, the service layer securely locks the specified transaction amount, creating a temporary balance reserve. This financial safeguard prevents overspending during pending transactions while maintaining account transparency, with automated rollback mechanisms activating if confirmation timeouts occur.

$$balanc{e}_A^{\mathrm{locked}}=balanc{e}_A-k$$

(6)

Here, balance_A represents the original account balance of Entity A, k denotes the amount that needs to be pre-frozen during the transaction, and Balance_A^locked refers to the remaining operable balance after the funds have been locked. This mechanism ensures fund safety before transaction completion, thereby preventing overpayments or duplicate transactions. If the timeout is not confirmed, the system will automatically roll back the transaction.

(2)

Energy Mortgage

Producers physically deposit committed energy quantities into designated warehouses, triggering cryptographic receipt generation with timestamped verification data. These digitally notarized receipts then initiate automated energy transfers between warehouses while preserving transaction privacy through hashed quantity records.

$$\mathrm{EnergyReceipt}=\left\{\mathrm{t},\mathrm{H}\left(E{Q}_{\mathrm{commit}}\right),P{K}_B\right\}$$

(7)

Here, t represents the timestamp that records the time of transaction generation to ensure timeliness. H(EQ_commit) denotes the hash value of the committed energy quantity (EQ_commit), which safeguards data privacy and verifies integrity.

Subsequently, the service node transmits a command to B’s energy warehouse, facilitating the transfer of energy from B’s warehouse to A’s energy warehouse. A’s energy warehouse then receives the energy and sends the corresponding data to the server.

The service packages the credentials and energy data into information blocks, which are then authenticated and uploaded to the blockchain. Once the blockchain submission is successful, CM sends a receipt to IM, who receives the receipt to finalize the transaction.

(3)

Transaction Settlement

The settlement phase finalizes the energy exchange by atomically transferring pre-frozen funds to the producer while simultaneously releasing energy access rights to the consumer.

$$balanc{e}_B\leftarrow balanc{e}_B+k$$

(8)

$$balanc{e}_A^{\mathrm{locked}}\to balanc{e}_A$$

(9)

This coordinated asset transfer is executed through blockchain-verified balance adjustments, where the consumer receives cryptographically signed energy withdrawal credentials, enabling immediate resource retrieval and completing the transaction lifecycle with guaranteed atomicity.

$$\mathrm{EnergyPermit}=\left\{P{K}_A,E{Q}_{\mathrm{commit}}\right\}$$

(10)

4.3. Chained Leader Consensus Models and Attack Models

The chained leader consensus achieves linear communication complexity through sequential leader rotation, overcoming traditional BFT algorithms’ scalability limitations via three core mechanisms: temporary leader election, chained block confirmation (requiring three subsequent blocks for finality), and view timeout switching protocols. However, these protocol features can be legitimately exploited by Byzantine nodes through forking attacks (malicious creation of competing chains) and silence attacks (intentional block submission delays), prompting the formalization of consensus rules and attack models in this section, which directly motivate RVR’s reputation-based defense mechanism as described in Section 5.

4.3.1. Chained Leader Consensus Algorithm

This section provides a brief overview of the chain leader consensus algorithm’s fundamental process, which enables efficient Byzantine fault tolerance through decentralized coordination. The protocol achieves linear communication complexity via sequential leader rotation while maintaining transaction finality. Its three-phase workflow establishes a robust foundation for distributed ledger consistency [16,18].

(1)

Voting Stage

Replica nodes participate in leader selection by submitting votes to the randomly elected coordinator node [16,18,19]. This distributed voting mechanism ensures decentralized consensus input while preventing single-point control failures.

(2)

Block Packaging

The elected leader consolidates collected votes into a quorum certificate (QC), then packages this cryptographic proof with validated transaction requests into a new block [16,18,19]. This dual-component structure provides both consensus legitimacy and transactional payload.

(3)

Block Addition

The leader appends the newly created block to the terminal position of the existing blockchain [16,18,19]. This sequential chaining maintains chronological integrity while enabling deterministic block verification through hash-linked references.

To mitigate the influence of Byzantine nodes and network asynchrony, the final submission of block B_V must satisfy the requirement of continuously adding three new blocks thereafter (Figure 3).

In addition, the system operates under the following three fundamental assumptions [16,18].

Assumption 1.

Honest nodes strictly adhere to protocol specifications and are dedicated to maintaining consensus mechanisms, while malicious nodes may disrupt the consensus process.

Assumption 2.

The proportion of honest nodes in the system must exceed that of malicious nodes, thereby satisfying the constraint that the total number of nodes (n > 3f + 1). This condition provides a foundation for consensus security.

Assumption 3.

The encryption algorithm possesses theoretical security, and the digital signature mechanism is unforgeable, thereby ensuring the authenticity and trustworthiness of communication between nodes.

4.3.2. Byzantine Attack Model

Delays in verification processes may present opportunities for nefarious leader nodes to exploit vulnerabilities. While the system employs hash algorithms and public-private key authentication mechanisms to safeguard against tampering with published transaction data, attackers can exploit temporal discrepancies in verification to initiate attacks and disrupt consensus among replicas. The compliance of such attack behaviors at the protocol level often renders it difficult for external observers to detect and identify. Nonetheless, these attacks can substantially impair the performance of blockchain networks. There exist multiple strategies for attacking Byzantine systems, and this discussion will primarily concentrate on two specific methods.

Forking Attack

The Byzantine leader node may intentionally create a fork in the chain consensus algorithm to override the blocks proposed by honest nodes. The figure illustrates that the Byzantine leader node extends B_v+3 from block B_v. Since B_v+3 meets the voting criteria [16,18], the replica nodes will vote in favor of B_v+3, leading all subsequent leader nodes to expand based on B_v+3.

The Byzantine leader node encompasses the blocks proposed by honest nodes through a manufacturing chain fork, extending from block B_v to generate the competing block B_v+3. Since B_v+3 adheres to the voting rule [16,18], replica nodes will cast their votes in favor of it, ultimately resulting in subsequent leader nodes continuing to extend based on B_v+3, as illustrated in Figure 4.

Silence Attack

The Byzantine leader node delays block submission by issuing a negative response. When the round reaches B_v+2, the Byzantine leader halts block generation until the timeout mechanism for view v+2 is activated. Consequently, the new leader is compelled to resubmit the block after B_v, as illustrated in Figure 5.

Traditional consensus algorithms are susceptible to the duplicate selection of Byzantine nodes due to inadequate processing, which directly leads to a significant decline in the network’s overall performance. For example, under a silence attack scenario (Figure 6), the performance exhibits an upward trend as the number of Byzantine nodes increases.

To address this issue, this paper proposes the RVR consensus algorithm, which integrates a reputation evaluation system with a VRF wheel selection algorithm to effectively reduce the probability of Byzantine nodes being elected. Consequently, the algorithm achieves a significant enhancement in the performance of blockchain networks under Byzantine attacks. The specific implementation of the RVR algorithm will be discussed in the following section.

5. Chained Consensus Algorithm Based on Reputation

In response to the challenges posed by the existing leader-based consistency mechanism [9,16,18], which significantly impairs network performance during certain types of network attacks, this paper introduces a robust consistency algorithm referred to as RVR (Reputation-VRF-Roulette Consensus). This algorithm employs an evaluation model and establishes a dynamic reputation assessment system that integrates multi-dimensional node attributes and behavioral data. Furthermore, it incorporates a verifiable random function (VRF) alongside an adaptive roulette wheel selection mechanism to facilitate probabilistic leader elections based on the weighted reputation of nodes. As illustrated in Figure 7, the algorithm’s process is delineated into three fundamental stages: the construction of the reputation evaluation group, the dynamic election of leaders, and the confirmation of blockchain transactions.

The implementation process is delineated as follows. Initially, reputation modeling is executed through the observation of multi-dimensional behavioral indicators associated with nodes. During the key management phase, the system employs a consensus private key, which is issued by a third-party trust institution, serving as the encryption seed for the verifiable random function (VRF). As the blockchain view version progresses, the VRF mechanism integrates the current block height with the consensus key to produce a distinct, auditable random parameter, denoted as r. Subsequently, a matrix calculation is conducted to determine the consensus coordination node for the current view period, utilizing an enhanced roulette wheel selector alongside the dynamic reputation weights of each node. The node that is selected assumes the responsibility of packaging the transaction set into blocks and disseminating these blocks throughout the peer-to-peer (P2P) network, thereby facilitating the update of the distributed ledger.

5.1. The Relationship Among Reputation, VRF, and Roulette

The reputation mechanism serves as the foundation of trust, dynamically calculating each node’s comprehensive reputation weight T_i by monitoring nodes’ activities, voting contributions, and behavioral compliance in real time (Equations (11)–(18)). Nodes with high reputations receive greater election weights due to their historical contributions and real-time performance. In contrast, malicious nodes experience a rapid decline in their reputation weight as a result of behavioral punishment mechanisms, which reduce their probability of being selected.

VRF generates a globally consistent and unpredictable random number r (Equation (19)) using the consensus private key sk_con and the current view value view, accompanied by a verifiable encryption proof π (Equation (21)). All nodes independently generate and verify the same random number, which prevents malicious nodes from manipulating the random source and ensures the transparency of the election process.

Roulette selection balances weight and randomness, combining the dynamic reputation weight T_i of nodes with the random number r generated by VRF and determining the leader through probability mapping (Equation (20)). Specifically, the election probability pi of each node is proportional to its reputation weight, while the random number r from the VRF establishes the final selection interval. For instance, if the weight of node A accounts for 30%, its corresponding sector on the roulette wheel is [0, 0.3). Node A is selected when r falls within this interval. This design provides high-reputation nodes with a significant advantage. However, the element of randomness prevents the monopolization of fixed nodes, and the unpredictability of the VRF ensures that attackers cannot anticipate or manipulate the election results. The synergistic effect of VRF and the roulette wheel together constitutes the leader election mechanism of RVR. Specifically, VRF provides anti-manipulation random seeds to ensure the fairness of the election process. Meanwhile, the roulette wheel converts dynamic weights into probability distributions, ensuring that the election results align with node contributions while incorporating an element of randomness.

5.2. Node Reputation Mechanisms

In this section, the establishment of reputation groups is explained in detail. All nodes in the network synchronize and maintain a shared reputation ledger through a consensus protocol. To better describe the reputation mechanism, the system adopts a multi-dimensional behavior perception framework that quantifies node participation into three core observation indicators: node activity, voting activity, and behavior weight. Multi-dimensional behavior indicators (node activity, voting activity, and behavior weight) are defined using Equations (11)–(18), and a reward and punishment mechanism is introduced (Equations (15) and (16)) to dynamically adjust reputation weights. The reputation weight directly influences the probability distribution of roulette wheel selection (Equation (20)), significantly increasing the probability of high-reputation nodes being selected as leaders. This design exponentially reduces the election probability of malicious nodes (as indicated by the historical reputation decay term in Equation (18)), effectively suppressing the repeated election of Byzantine nodes.

5.2.1. Node Activity

The node activity index characterizes the real-time load status of server nodes, and its value is strongly positively correlated with the frequency of transaction processing within the regional network topology. Specifically, the growth of the user base within geographic distribution units directly leads to an increase in the volume of transaction requests. This surge results in a dynamic increase in the load of node transaction verification queues, ultimately reflected in a nonlinear rise in the activity index.

$$A\left(i\right)=min\left(\gamma {\left(\log \left(K+1\right)\right)}^a{\left(\log \left(T+1\right)\right)}^b,A_{max}\right)$$

(11)

Here, K represents the user base, T denotes the transaction throughput, and γ is the normalization coefficient. The typical parameter configurations are a = 0.5 and b = 0.3. A_max refers to the activity threshold constraint term, while the suppression index indicates the nonlinear dilation. The activity level of nodes is positively correlated with both the number of users and the transaction throughput in the region. This correlation is utilized to characterize the real-time load status of the nodes.

5.2.2. Voting Activeness

The voting activity index quantifies the strength of contributions from nodes participating in consensus by calculating the number of valid votes cast during the statistical period and applying appropriate weights to them.

$$V\left(i\right)=m-e^{-\alpha v}$$

(12)

Here, v represents the number of times a node votes to pack into QC, α is the adjustment coefficient, and m denotes the upper limit of activity. Voting activity quantifies the contribution of nodes to consensus participation by weighting the number of votes cast. During the initial stage, the number of votes has a significant impact on the reputation weights, which gradually approaches a stable value.

From this, we obtain the fundamental reputation of the node, i.e.,

$$B\left(i\right)=\alpha A\left(i\right)+\left(1-\alpha \right)V\left(i\right)$$

(13)

where α represents the weight coefficient, and the basic reputation is calculated by weighting the node’s activity (Equation (11)) and voting activity (Equation (12)), thereby reflecting the node’s overall historical performance.

5.2.3. Behavior Weight

Behavioral weight signifies that the effectiveness of node behavior, in terms of reward and punishment, is achieved through a role grading mechanism designed to create a differentiated configuration. This is specifically reflected in the higher operational authority weights assigned to leader nodes.

$$\theta ={\displaystyle \frac{1+\left(k-1\right)\xi }{k}}$$

(14)

Here, the value of ξ can be either 0 or 1, with 1 representing the lead node. The variable k denotes the reciprocal of the weight of a standard node. Leadership nodes are assigned higher weights through a role-grading mechanism, which differentiates the operational authority weights of configuration nodes.

As mentioned earlier, forking and silence attacks are challenging to detect directly. However, we can obtain the behavior penalty P(n) and the behavior reward R(t) based on the behavior weight:

$$R\left(t\right)=r_0\cdot \theta \cdot {\displaystyle \frac{1}{1+\beta \cdot \log \left(1+n\right)}}\cdot \left(1-t\right)$$

(15)

where r₀ (1 ≤ r₀ ≤ 10) is the basic reward value. It is essential to balance the intensity of incentives with the stability of the system. The parameter β (0.1 ≤ β ≤ 0.3) serves as the attenuation coefficient, which controls the decay rate of rewards in relation to the number of nodes, thereby preventing excessive dilution of rewards. The variable t denotes time, where t = 1 indicates a timeout and t = 0 signifies punctuality. Additionally, n represents the total number of timeout occurrences.

$$P\left(n\right)=p_0\cdot \theta \cdot \left(1+\alpha \cdot n^2\right)$$

(16)

Here, p₀ is the basic penalty value, and it is recommended that p₀ be set between 0.2r₀ and 0.3r₀. It is important to ensure that the penalty is sufficiently strong to deter Byzantine attacks. The variable alpha α (0.1 ≤ α ≤ 0.5) represents the punishment growth coefficient. This coefficient regulates the growth rate of the penalty based on the number of timeouts.

If a node is penalized for exhibiting abnormal behavior, such as experiencing a timeout, the penalty value increases exponentially with the number of timeouts incurred. Conversely, if a node receives a reward for completing an operation within the designated time frame, the reward value increases linearly with time stability. Specifically, we can derive an equation for the behavioral reputation, denoted as C(i).

$$\mathrm{C}\left(\mathrm{i}\right)=\mathrm{R}\left(\mathrm{t}\right)-\mathrm{P}\left(\mathrm{n}\right)$$

(17)

Comprehensive systems of punishment and reward for behavioral reputation dynamically reflect the real-time performance of nodes.

Therefore, we synthesize the basic reputation and behavioral reputation to obtain the comprehensive reputation of the node:

$$T_n^i=T_{n-1}^i+k_{1}B\left(i\right)+k_2\mathrm{C}\left(i\right)$$

(18)

where k₁ (0.5 ≤ k₁ ≤ 0.7) is the historical reputation weight, which emphasizes long-term stability and aims to minimize credit fluctuations, and k₂ (0.3 ≤ k₂ ≤ 0.5) is the weight assigned to behavioral rewards and punishments. To ensure that real-time behavior has an immediate impact on reputation, the condition k₁ + k₂ = 1 must be satisfied. The comprehensive reputation is calculated by weighting the basic reputation (Equation (13)) and the behavioral reputation (Equation (17)) and dynamically updating the global reputation weights of the node.

5.3. Leader Election Mechanism

Compared to the security vulnerabilities associated with the repeated election of malicious nodes in existing chained Byzantine fault tolerance (BFT) algorithms [16,18], the RVR scheme introduces a verifiable probabilistic roulette wheel election mechanism. This mechanism dynamically adjusts the real-time weights of candidate nodes through a reputation evaluation system. It leverages the dynamic perception capabilities of the chain topology structure to develop a leader election model that satisfies the consensus verification requirements of BFT. A key innovation of this model is the quantification of the historical behavioral reputation of nodes as dynamic parameters within the election probability distribution function. This approach ensures that the probability of malicious nodes being elected decreases exponentially in response to their abnormal behavior.

5.3.1. Generating VRF Random Numbers

Each node utilizes the consensus private key sk_con and consensus input data (consensus view) to generate random numbers and proofs:

$$\left(r_{global},{\pi }_{global}\right)={\mathrm{VRF}}_{s{k}_{con}}\left(view\right)$$

(19)

A trusted third-party institution releases the consensus private key, which facilitates the generation of random numbers through three key parameters: the current view value (view), the binary random number generated by the node, and its corresponding verifiable random function proof. A globally consistent random number, denoted as r_global, is generated using the consensus private key and the current view value (Equations (19)–(21)). This design ensures that random seeds cannot be predicted or tampered with by malicious nodes, and all nodes to verify the legitimacy of the random numbers are based on the same input, thereby preventing manipulation of election results. The random numbers generated by the verifiable random function (VRF) serve as inputs for roulette wheel selection, combined with dynamic weights (Equation (20)), to ensure the fairness of the election (randomness) while giving higher priority to nodes with a strong reputation (weight-driven selection).

5.3.2. Leader Confirmation

The standard random number r is utilized as input, combined with the node’s reputation weight $T_i(i=1,2,\dots ,n)$ through a roulette algorithm to elect the leader, namely:

$${\mathrm{Leader}}_i=min\left\{i\mid {\displaystyle \sum }_{j=1}^i{T}_j\ge r\times {\displaystyle \sum }_{j=1}^n{T}_j\right\}$$

(20)

where Leader_i represents the selected leader node, and all nodes choose leaders based on the same common random number, ensuring consistent results.

5.3.3. Verification of Leader Election

Any other node can verify the leader’s election. Since the election result is deterministically derived from the verifiable random number r, authenticating the leader election is essentially equivalent to verifying the correctness and provenance of r. The process is expressed as follows:

$$ture/false\leftarrow \mathrm{Verify}\left(p{k}_{\mathrm{shared}},\mathrm{view},r_{\mathrm{global}},{\pi }_{\mathrm{global}}\right)$$

(21)

5.4. RVR Algorithm Flow

In this section, we will present a comprehensive overview of the RVR algorithm process, detailing its node reputation mechanism and leader selection algorithm.

This algorithm employs a pipeline architecture, which transcends the execution paradigm of the traditional four-stage consensus model. As illustrated in Algorithm 1, each node in the network assumes a distinct role: consensus nodes generate and broadcast votes, while leader nodes concurrently execute block construction operations.

Algorithm 1: RVR Algorithm Process
1	As  LeaderNode
2	Wait msgs from replicas
3	if n-f η msgs are received
4	AggQC←CreatAggQC(ηset)
5	B←CreateMsg(Prepare,view,aggQC,cmd,id)
6	end
7	if n-f v msgs are received
8	QC←CreateQC(V)
9	B←CreateMsg(Prepare,view,QC,cmd,id)
10	end
11	Broadcast B
12	Update Tarry
13	nextleader←LeaderElection(view,Tarry)
14	SendVote(nextleader,V,view+1)
15	end
16	As ConsensNode
17	Wait for B from LeaderNode
18	if  B is accepted successfully
19	Update Tarry
20	nextleader←LeaderElection(view,Tarry)
21	Send Vote(nextleader,V,view+1)
22	end
23	if a timeout occurs at any stage
24	Update Tarry
25	nextleader←LeaderElection(view,Tarry)
26	Send η(nextleader,V,view+1)
27	end
28	end

In the voting collection stage (Processes 3–5), the system generates AggQCs with Byzantine fault tolerance characteristics using η-type voting (refer to FastHotStuff). Upon entering the block construction stage (Processes 8–9), the algorithm constructs a quorum certificate (QC) and encapsulates the validated transaction set within the block.

Specifically, in Processes 11–14, the selected nodes broadcast new blocks to the entire network through point-to-point communication, subsequently initiating a leader replacement protocol based on dynamic reputation. The specific implementation details will be discussed in the next section.

In standard operational scenarios (Processes 18–21), consensus nodes evaluate candidate blocks and generate standard votes. When a network anomaly or view timeout event is detected (Processes 23–26), the node activates the fault-tolerant protocol and transmits a η-type data packet containing timestamp encryption to maintain system activity. This dual-mode response mechanism significantly enhances the algorithm’s robustness in complex network environments while ensuring safety.

5.5. Theoretical Analysis

This section formally establishes RVR’s security guarantees using mathematical proofs. The safety proof (Theorem 1) demonstrates irreversible transaction consistency by leveraging quorum certificate intersections and honest node behavior constraints. The liveness proof (Theorem 2) guarantees finite-time transaction finality by analyzing reputation-driven leader election probabilities under Byzantine failures, where malicious leader selection likelihood decreases exponentially through behavioral penalties.

5.5.1. Safety Guarantees

Theorem 1 (Consistency) [16,18]. 

All honest nodes commit to the same sequence of blocks.

Proof. 

Assume there are two honest nodes, N₁ and N₂, that commit blocks B and B’ at height h. Let QC(B) and QC(B’) represent their respective quorum certificates. Based on the principle of quorum intersection, there must exist an honest node, N₃, that signed both QC(B) and QC(B’). This situation contradicts the protocol rule that states honest nodes can only vote for one block per height. Therefore, safety is ensured. □

5.5.2. Liveness Guarantees

Theorem 2 (Progress) [16,18]. 

Any valid transaction is committed within a finite time after the Global Stabilization Time (GST).

Proof. 

Let T represent the maximum epoch duration (∆ + processing time). If a leader is Byzantine, a view switching will occur within T. Due to reputation decay mechanisms, the probability of Byzantine leader election decreases exponentially. Honest leaders will ultimately propose blocks, thereby ensuring liveness. □

5.6. Comparative Analysis

This section provides a systematic comparison of the reputation-based voting and reputation (RVR) algorithm with established consensus algorithms, focusing on communication complexity, energy consumption, leader election mechanisms, latency, and support for chain consensus, as detailed in

Table 1. Comparison of consensus algorithms.

Algorithm	Complexity	Energy Consumption	Leader Election Mechanism	Latency	Is Chained Consensus?
RVR	O(n)	Low	Dynamic reputation weight random verifiable selection	Low	Yes
HotStuff [16]	O(n)	Low	Equal probability election	Low	Yes
FastHotStuff [18]	O(n)	Low	Equal probability election	Low	Yes
PBFT [9]	O(n2)	Low	Fixed sequence rotation	High (large-scale)	No
SBFT [15]	O(n)	Low	The one with the highest reputation	Low	Yes
Pow [10]	/	Very High	Computational power competition	Very low	Yes

. The aim is to elucidate the design advantages of RVR.

Communication Complexity: RVR exhibits a linear communication complexity of O(N), which is markedly more efficient than the quadratic complexity of O(N²) associated with practical Byzantine fault tolerance (PBFT). A notable innovation of RVR is its integration of dynamic reputation weights with a verifiable random function (VRF)-based roulette wheel selection mechanism. This design allows for the completion of leader election in a single round of broadcasting, thereby circumventing the multi-round interactions that are characteristic of traditional Byzantine fault tolerant (BFT) algorithms. Conversely, PBFT encounters challenges in supporting large-scale network deployments due to the frequent voting and confirmation communications required among nodes.

Energy Consumption: The reduced energy consumption of RVR can be attributed to several design features:

Linear Communication Overhead: By minimizing the number of network transmissions, RVR directly reduces energy consumption associated with communication.

Efficient Election Mechanism: The generation of random numbers using VRF necessitates only lightweight encryption calculations. Furthermore, the roulette wheel selection process is efficiently conducted based on pre-computed reputation weights, thus avoiding the substantial computational demands typical of proof of work (PoW) algorithms.

Dynamic Reputation Optimization: This feature enables the real-time isolation of malicious nodes, thereby diminishing invalid consensus participation and conserving computational resources.

Leader Election Mechanism: RVR adeptly balances attack resistance and fairness through the synergistic use of dynamic reputation weights and VRF. The probability of a node being elected is positively correlated with its historical contributions, facilitating the swift removal of malicious nodes through reputation decay. In contrast, the equal probability election mechanisms utilized by HotStuff and FastHotStuff are susceptible to interference from Byzantine nodes, while PBFT’s fixed rotation strategy lacks the requisite flexibility. Additionally, SBFT’s approach of selecting the node with the highest reputation as the leader can lead to a single point of failure.

Latency: The low latency of RVR is primarily due to its dynamic reputation mechanism, which minimizes the frequency of view switching. The deterministic random number generation provided by VRF eliminates the overhead associated with conflict retries that are common in traditional random election processes. In contrast, PBFT significantly increases latency in large-scale networks due to its heightened communication complexity.

Chain Consensus Support: Both RVR and HotStuff support chain structures to ensure transaction finality. However, PBFT’s design limitations prevent it from adapting to a chain architecture, thereby restricting its applicability in smart grid scenarios.

5.7. Experimental Setup

This research employed the Golang programming language to create a distributed simulation trading environment. Experimental results represent mean values from five independent trials. The experimental setup is characterized by the deployment of each replica node on separate virtual machine instances, each allocated with independent memory space. The inter-node communication delay is maintained at or below 1 millisecond, and client programs are executed on distinct virtual machines. During the testing phase, clients randomly select replica nodes to initiate requests, while the designated leader node is tasked with replicating and disseminating these requests to the remaining nodes. The experiment specifically simulated Byzantine fault-tolerant scenarios by incorporating faulty nodes that exhibit Byzantine behavior. To assess the performance characteristics of the RVR algorithm, the HotStuff and FastHotStuff algorithms were concurrently implemented within the same experimental framework for comparative analysis. A detailed configuration of the experimental parameters is provided in

Table 2. Parameters for the experiment.

Parameter	Description	Value
N	Total number of nodes	64
byzNo	Number of Byzantine nodes	0 to 20
strategy	Byzantine strategy	forking/silence
timeout	Maximum waiting time for the next view	1000 ms
hasher	The hash algorithm used	sha3_256
max round	The maximum number of running epochs	5000
bsize	Number of transactions included in a block	400
r0	Basic reward value	8
p0	Basic penalty value	2
α	Punishment growth coefficient	0.3
β	Reward decay rate	0.2
k1	Historical reputation weight	0.6
k2	Real-time behavior weight	0.4

.

5.8. Experimental Metrics

Latency refers to the time interval between a client initiating a request and receiving a confirmation response.

TPS (Transactions Per Second): An indicator of a system’s capacity to process transactions within a specified time frame, defined as the number of successfully processed transactions per second.

Block Interval [19] (BI): It measures the average number of view switches required for a block in a blockchain to be generated and submitted. It is mathematically defined as follows:

$$BI=\underset{v\to \infty }{lim}{\displaystyle \frac{{{\displaystyle \sum }}_{i=1}^{C\left(v\right)}{L}_i}{C\left(v\right)}}$$

(22)

where L_i represents the number of views experienced by the i-th block, measured from the start to the submission.

Chain Growth Rate [19] (CGR): It refers to the growth rate of submitted blocks during the long-term operation of the system. The equation for its calculation is as follows:

$$CGR=\underset{v\to \infty }{lim}{\displaystyle \frac{C\left(v\right)}{v}}$$

(23)

where C(v) represents the total number of successfully submitted blocks during the first v views.

6. Results and Discussion

6.1. Under Silence Attack

As illustrated in Figure 8, the RVR algorithm exhibits superior delay management in the context of silence attacks when juxtaposed with the HotStuff and FastHotStuff algorithms. In comparison to the HotStuff benchmark, RVR achieves a 37.88% reduction in request latency. Regarding throughput, as depicted in Figure 9, the decline in transactions per second (TPS) for RVR is more gradual, maintaining 53.09% of the baseline TPS (achieved with no Byzantine nodes) when HotStuff’s TPS reaches its minimum value. This improvement can be attributed to RVR’s dynamic reputation mechanism, which effectively reduces the likelihood of the re-election of malicious leaders—a notable vulnerability identified in other consensus algorithms within blockchain technology [16,18].

HotStuff and FastHotStuff utilize a fixed leader rotation mechanism, which enables Byzantine nodes to consistently impede block submissions during silence attacks. In contrast, RVR employs a verifiable random function (VRF)-based selection process that effectively excludes leaders with lower reputation weights from the electoral process, thereby alleviating performance degradation.

Figure 10 and Figure 11 demonstrate that RVR incorporates an optimized mechanism for filtering Byzantine nodes, resulting in diminished fluctuations in key performance indicators such as block inclusion (BI) and consensus gain rate (CGR). As illustrated in Figure 11, the minimum BI value for RVR is only 59.25% of that observed in HotStuff, thereby substantiating the effectiveness of its Byzantine fault-tolerant mechanism.

6.2. Under Forking Attack

As depicted in Figure 12, under a forking attacks, RVR achieves latency values as low as 47.59% of HotStuff’s value, while consistently sustaining stable transactions per second (TPS), as shown in Figure 13. This methodology surpasses the performance of FastHotStuff’s AggQC mechanism, which, although it successfully mitigates communication overhead, does not effectively prevent malicious leaders from creating conflict chains.

HotStuff requires the production of three sequential blocks to attain finality (Figure 3). Nonetheless, Byzantine leaders may take advantage of this stipulation to generate forks. The RVR protocol mitigates this concern by implementing a behavioral weight penalty, as described in Equation (16), which effectively reduces the standing of nodes that instigate forks. This mechanism significantly decreases their likelihood of being elected in an exponential fashion.

FastHotStuff partially mitigates challenges related to latency and throughput through the aggregation of quorum certificates (aggQCs) [18]. However, its absence of reputation awareness leads to instability in transactions per second (TPS) at elevated Byzantine fault ratios, as illustrated in Figure 13. In contrast, the reputation-driven architecture of RVR facilitates a more stable system throughput, as depicted in Figure 13, achieving a maximum enhancement of 50.66% relative to HotStuff. Further examination, as shown in Figure 14 and Figure 15, reveals that RVR (with a block confirmation efficiency index of BI = 3.81) exhibits a maximum increase of 24.10% compared to HotStuff (BI = 5.02). Additionally, the chain growth rate (CGR = 0.71) demonstrates a maximum improvement of 61.36%.

6.3. Discussion

The experimental validation confirmed RVR’s paradigm-shifting capabilities in Byzantine-resilient consensus. Under a silence attacks, RVR achieved a remarkable 37.88% latency reduction compared to state-of-the-art HotStuff [16], demonstrating its unique capacity to mitigate targeted leader disruption. This breakthrough originated from RVR’s innovative integration of dynamic reputation evaluation with verifiable random functions—a dual-mechanism approach that fundamentally addresses critical limitations in existing frameworks. Unlike Kumar et al.’s domain-specific model [21], which lacks adaptive reputation calibration, RVR’s exponential decay function (Equation (18)) enables real-time identification and suppression of malicious nodes through continuous behavior monitoring. Furthermore, while HotStuff family protocols [16,18] remain vulnerable to prediction-based targeting due to their deterministic leader sequences, RVR’s cryptographically secure VRF-driven election ensures truly unpredictable coordinator selection, eliminating this attack vector entirely.

For forking attacks, RVR delivers equally impressive 50.66% throughput enhancement over HotStuff [16], establishing new standards for fork-resistant consensus in decentralized energy trading. RVR proactively prevents forks through behavior weight penalties (Equation (16)) that actively demote nodes initiating forking attacks, while FastHotStuff’s AggQC mechanism [18] focuses exclusively on latency optimization and fails to address core fork vulnerabilities. Through its elegant integration of reputation-weighted quorum certificates with VRF-based view transitions, RVR maintains deterministic consistency while avoiding the prohibitive O(n²) messaging overhead that plagues classical BFT systems like PBFT [9]. This architectural innovation successfully resolves the fundamental tension between fork resistance and scalability identified in Gai et al.’s landmark analysis of chained consensus vulnerabilities [19], while simultaneously outperforming application-specific solutions such as Puthal et al.’s token-based approaches [20] through its universal design framework.

The combined security and efficiency optimization achieved by RVR represents a significant advancement for smart grid applications, where its linear communication complexity enables practical deployment in large-scale networks while providing robust protection against sophisticated Byzantine strategies that cripple conventional consensus mechanisms.

7. Conclusions

7.1. Technological Advancements and Implications

The RVR framework successfully reconciles Byzantine fault tolerance with operational efficiency within blockchain-based smart grid systems. By mitigating vulnerabilities associated with leader election in protocols such as HotStuff [16] and FastHotStuff [18], RVR establishes a scalable and secure foundation for advanced energy trading systems. Empirical findings indicate that RVR fulfills two primary objectives:

(1) Improved Byzantine Fault Tolerance: Through the incorporation of dynamic reputation assessment alongside verifiable randomness, RVR achieves a throughput enhancement of 50.66% relative to HotStuff during forking attacks, while also optimizing latency by 37.88% in the context of silence attacks.

(2) Broad Applicability: In contrast to prior research that has predominantly concentrated on single-device scenarios [9,16], RVR’s multi-dimensional reputation model is designed to accommodate diverse energy trading environments.

These advancements carry substantial implications for the practical implementation of smart grids.

(1) Security: RVR’s hybrid mechanism provides a robust safeguard for ensuring transaction authenticity within open peer-to-peer networks.

(2) Scalability: The algorithm’s linear communication complexity of O(N) and its dynamic weight-driven election mechanism render it well-suited for blockchain consensus networks characterized by fluctuating participant behavior.

7.2. Limitations and Directions for Future Research

The proposed framework is subject to several limitations that will guide future research endeavors.

(1) Assumption of Homogeneous Energy Types: The current framework presupposes uniform energy types (e.g., electricity). Future research will aim to extend the RVR model to incorporate multi-energy coupled trading scenarios, including the integration of heat and hydrogen markets [31].

(2) Centralized Reputation Initialization: The reputation ledger’s reliance on third-party key issuance partially undermines the principles of decentralization. Future work will focus on developing a fully decentralized mechanism for reputation initialization.

(3) Practical Constraints of Experimental Scale: The existing experiments are limited by the resource configurations of the simulation environment (e.g., a deployment of 64 nodes), which constrains the validation of RVR’s performance in ultra-large-scale networks (exceeding 500 nodes). Although the linear communication complexity, O(N), theoretically supports scalability, the impacts of dynamic load balancing and inter-regional communication delays necessitate further exploration. Future initiatives will include optimizing algorithmic parallelism (e.g., through sharding technology [32]), scaling the node count to over 1000 on distributed cloud platforms, and assessing its applicability within city-level smart grids.

(4) Centralized Key Distribution: The current framework relies on a third-party authority for consensus private key initialization, which contradicts the decentralized nature of blockchain systems. Future research will integrate decentralized key management protocols, such as distributed key generation (DKG) [33], to eliminate single points of trust.

Future research will concentrate on (1) integrating machine learning for real-time reputation calibration, (2) extending the framework to encompass multi-energy ecosystems, (3) investigating decentralized reputation initialization schemes to enhance system autonomy, and (4) implementing decentralized key distribution mechanisms to align with blockchain’s trustless principles.