A credit-based hierarchical PBFT consensus method for a V2G scenario

Abstract

This invention proposes a reputation-based hierarchical PBFT consensus method for V2G scenarios, aiming to solve the problem of high communication complexity in traditional PBFT as the node scale increases. This invention constructs a two-layer consensus structure: bottom-layer nodes perform initial intra-group confirmation of consensus requests, while top-layer nodes participate in cross-group consensus. Regarding node selection, top-layer nodes are selected within a group based on their reputation values ​​to participate in cross-group consensus, while other nodes only participate in intra-group consensus. Simultaneously, among top-layer nodes, both node reputation values ​​and the average reputation value of the group are comprehensively considered, combined with a verifiable random function to select a global master node, improving the fairness and randomness of master node election. Furthermore, this invention introduces a reputation evaluation mechanism, constraining malicious or low-performance nodes by comprehensively considering factors such as node performance, historical transaction processing power, and user evaluations. Through the synergistic effect of the hierarchical structure and the reputation mechanism, the number of inter-node communications is reduced, improving consensus efficiency.

Description

Technical Field

[0001] This invention relates to the field of blockchain consensus technology, and more specifically, to a reputation-based hierarchical PBFT consensus method for V2G scenarios. Background Technology

[0002] In Vehicle-to-Grid (V2G) scenarios, electric vehicles serve as distributed energy storage units to alleviate peak load pressure and improve grid stability. V2G allows for bidirectional energy exchange between electric vehicles and the grid, thereby enhancing the flexibility of the energy system and achieving load balancing and peak shaving. With the large-scale integration of electric vehicles, blockchain applications in V2G scenarios are gaining increasing attention. Blockchain technology, due to its decentralized, traceable, and tamper-proof characteristics, provides new technical support for electric vehicle identity authentication and the reliable storage of transaction data.

[0003] Regarding the choice of consensus method, compared to mechanisms based on computational power competition, such as Proof of Work (PoW), Byzantine Fault Tolerance (PBFT) consensus algorithms are more suitable for V2G scenarios. Firstly, PoW relies on high-intensity computation, resulting in high energy consumption and high confirmation latency, which is incompatible with the "high-frequency, small-amount, real-time" electricity trading characteristics of V2G scenarios. Secondly, V2G networks typically consist of aggregators, grid operators, and electric vehicles, belonging to a permissioned consortium blockchain environment where node identities can be pre-authenticated, eliminating the need for computational power competition for the right to record transactions. Practical Byzantine Fault Tolerance (PBFT) consensus methods are widely used in distributed systems due to their low latency, high efficiency, and resistance to Byzantine attacks. This mechanism does not rely on computational power competition and is more suitable for consortium blockchain structures where node identities can be managed. Therefore, in V2G scenarios, using PBFT as the underlying consensus framework better meets the system's comprehensive requirements for real-time performance, security, and energy efficiency.

[0004] However, directly applying traditional PBFT to V2G scenarios presents several problems: First, the sheer number of nodes in V2G scenarios, coupled with the fact that all nodes participate in consensus, significantly increases the O(N²) communication complexity of PBFT, leading to a sharp rise in network overhead and making it difficult to meet the real-time requirements of high-frequency energy trading. Second, the traditional PBFT master node election method is relatively fixed, making it susceptible to prediction and even targeted attacks, which is detrimental to maintaining long-term security in the open and dynamic V2G network environment. Therefore, it is necessary to optimize the structure of the PBFT consensus method and improve the master node selection mechanism, taking into account the characteristics of large node scale and high transaction concurrency in V2G scenarios, in order to enhance the system's scalability and security. Summary of the Invention

[0005] To address the above problems, this invention provides a reputation-based hierarchical PBFT consensus method for V2G scenarios, comprising the following steps:

[0006] S1. Both Local Energy Aggregators (LEAGs) and Electric Vehicles (EVs) must register and authenticate their identities with a Trust Authority (TA) to obtain corresponding digital certificates. Upon successful authentication, the TA assigns a unique and legitimate identity identifier to each LEAG and EV, and generates a public-private key pair and a digital certificate bound to that identity.

[0007] S2. Configure LEAGs with valid identities as consensus nodes in the blockchain network, and initialize the reputation value of each node according to the preset reputation evaluation mechanism;

[0008] S3. Based on the geographical location of each consensus node, the nodes participating in the consensus are divided into regional clusters to form several groups, each group containing multiple nodes with similar geographical locations;

[0009] S4. In each group, select the node with the highest reputation based on its reputation value, set it as the top-level node and the master node within the group, and enable it to participate in the consensus within and across groups; the remaining nodes are set as bottom-level nodes and only participate in the consensus process within the group.

[0010] S5. Among the top-level nodes selected in each group, a global master node is selected by comprehensively considering the node's own reputation value and the average reputation value of its group, and using a verifiable random function. The global master node is responsible for the final coordination and confirmation of cross-group consensus.

[0011] S6. Each consensus node is responsible for receiving and collecting energy transaction requests submitted by electric vehicles within the region, and caching the transaction requests;

[0012] S7. When a transaction is completed, the consensus node collects the transaction records and confirms the consistency of the transactions in the current round based on the hierarchical PBFT consensus method;

[0013] S8. Update the reputation values ​​of all nodes based on the consensus results of this round, and repeat steps S4 to S8 to complete subsequent consensus rounds.

[0014] Furthermore, in step S1, the V2G scenario includes three types of entities: trusted certification authorities (TAs), local energy aggregators (LEAGs), and electric vehicles (EVs).

[0015] The Trusted Authentication Authority (TA) is responsible for system initialization and identity management. During the system initialization phase, it generates common system parameters, completes identity registration and authentication for entities participating in the system, and issues digital certificates.

[0016] The unified format for digital certificates is as follows:

[0017]

[0018] in, These are the entity roles in the system, including electric vehicles (EVs) and local energy aggregators like LEAG; For the entity number under the corresponding role, For entities A unique identifier; For trusted certification authorities (TAs) as entities The issued public key; For entities The validity period of a digital certificate; Use their private key right , and hash digest Perform the digital signature generation process;

[0019] The local energy aggregator LEAG provides power access and communication services for electric vehicles, and is responsible for aggregating and managing energy trading requests from electric vehicles within its jurisdiction. Furthermore, LEAG participates in the consensus process as a consensus node in the blockchain network, verifying, packaging, and recording energy trading data into the blockchain ledger; LEAG also maintains the electric vehicle... The mapping relationship between identity information and transaction address is used for subsequent identity verification and energy transaction management. The mapping relationship is as follows:

[0020]

[0021] in, For electric vehicles A unique identifier; TA is a trusted certification authority The issued public key; for The hash digest of a digital certificate; for The validity period of a digital certificate; For trusted certification authorities (TAs) Signature of digital certificate information; for The transaction wallet address;

[0022] The electric vehicles (EVs) are equipped with bidirectional charging and discharging devices and can participate in V2G energy trading as distributed energy storage units. In the V2G scenario, based on their own power status and user preferences, electric vehicles can be categorized as discharging vehicles, charging vehicles, and idle vehicles.

[0023] Furthermore, in step S2, when calculating the reputation value of LEAG, multiple factors are comprehensively considered, including node performance score, node transaction score, and user rating. The specific calculation process includes:

[0024] The computational resources and network bandwidth of nodes are standardized using a minimum-maximum normalization formula, and the consensus is as follows:

[0025]

[0026] in, This represents the numerical value in the original data. and These represent the minimum and maximum values ​​in the dataset, respectively. The value is the normalized value;

[0027] For the Local aggregator nodes Its performance score It can be represented as:

[0028]

[0029] in, for The normalized value of the computational resource index, for The normalized value of the network bandwidth, where and These are the weighting coefficients, and ;

[0030] Secondly, historical transaction processing volume reflects the activity and stability of nodes participating in system operation. Specifically, In the The amount of electricity processed in round consensus can be denoted as: Its calculation method is as follows The total transaction volume successfully processed in this round, regardless of Whether the company trades directly with EVs or acts as an intermediary in transactions between EVs, the electricity volume of the transactions is counted. The historical transaction volume. The calculation formula is:

[0031]

[0032] in, for In the The number of successful transactions participated in during consensus rounds. For the first The electricity consumption of this transaction, in its initial state. ;

[0033] The historical transaction processing power of a node represents its cumulative transaction processing power across multiple rounds. To enhance sensitivity to recent transaction behavior, a round decay factor is introduced to weight the transaction processing power of each round, giving higher weight to more recent transactions, thus obtaining an indicator that better reflects the node's current activity level. Historical Transaction Processing Power The calculation formula is:

[0034]

[0035] in, This is the round decay factor, with a value range of (0,1). This represents the consensus round that has been completed. Representing the Consensus rounds. The iterative update formula for historical transaction processing power is:

[0036]

[0037] Among them, the initial state When the first round of consensus is not completed, the historical transaction processing volume is 0.

[0038] No. The verified historical transaction volume after the consensus round ends will be used to calculate the [number]th [round]. Round consensus transaction score The formula for transaction score is:

[0039]

[0040] Among them, the initial state That is, if the first round of consensus is not completed, the transaction score is 0;

[0041] Furthermore, electric vehicles can evaluate the service quality of LEAG, thereby reflecting the reliability and fairness of nodes in providing services. For electric vehicles... ,in ,according to Historical transaction volume Calculate its user weight using the following formula:

[0042]

[0043] in, For electric vehicles based on forward Historical trading volume The calculated user weight will be applied to the first... Wheel service evaluation; Let be a natural constant, such that =0, that is The initial weight is 1; For electric vehicles The historical trading volume with phase decay has a calculation formula that is similar to... However, unlike it, Only calculate The reason for the electricity traded by the electric vehicle is that the electric vehicle is only the terminal entity in the energy trading and does not act as an energy intermediary.

[0044] For the Local aggregator nodes Its new score in the nth round of consensus is The calculation process incorporates user weights, which reflect a user's credibility. Therefore, weighting allows the rating results to more accurately reflect the importance of different users. New rating system. The calculation formula is:

[0045]

[0046] in, Representing the Round of consensus, The number representing the score. represent In the The sequence number received in the round is The rating is an integer in the range [0, 5]. represent In the The total number of ratings received in the round; for In the The consensus in the first round gives the first One user rating, To Provide the user weight corresponding to this rating;

[0047] To ensure the continuity and stability of the rating system, new ratings are only used as one of the inputs for this round of updates, and are adjusted using a decay mechanism and historical ratings. After comprehensive calculation, the final result is In the Wheel of user ratings The specific update relationships are as follows:

[0048]

[0049] in, This is the round decay factor, with a value range of [value range missing]. ; for In the Wheel's historical rating, for In the The new rating of the wheel;

[0050] Therefore, The reputation value is represented as ,in Both are weighting coefficients, and ; The integrity coefficient ranges from (0,1], with an initial value of 1. Attenuation occurs in the following manner:

[0051]

[0052] in, represent recent The number of times malicious acts or malfunctions occur during consensus-building. The range of values ​​is As the number of wrongdoings or malfunctions increases, the integrity coefficient gradually decreases.

[0053] Furthermore, in step S4, the roles of nodes within a group are assigned based on their reputation values. For any group, the node with the highest reputation value within the group is selected and set as the top-level node of that group, based on the current reputation values ​​of each node in the group. This top-level node has the authority to participate in both intra-group consensus and cross-group consensus, and is responsible for summarizing intra-group consensus results and interacting with cross-group consensus.

[0054] Furthermore, in the process of selecting the global master node described in step S5, the security, fairness, and unpredictability of the system can be improved in the following ways:

[0055] First, the overall reputation score of a node is calculated. This score is composed of the node's own reputation score and the average reputation score of its group. The probability of selecting each top-level node is positively correlated with its overall reputation score. The specific formula for the overall reputation score is as follows:

[0056]

[0057] in, For the first In the consensus round, the top-level node Overall reputation score This is the weighting adjustment coefficient, with a value range of (0,1), used to balance the proportion of a node's own reputation to the average reputation of its group. for The group you belong to; Grouping The total number of nodes within; For the first Consensus Group Average reputation score within;

[0058] The process of selecting a global master node using a verifiable random function (VRF) is as follows:

[0059] Top-level nodes of each group Call your own private key The current consensus round number and the hash of the latest block in the entire network are used as public inputs. Generate unique random values ​​using the VRF algorithm. At the same time, generate the corresponding verification proof. ; the random value Normalized to the [0,1] interval, the normalization formula is:

[0060]

[0061] in, The length of the fixed-length bit string output by the VRF;

[0062] To make nodes with higher overall reputation scores more likely to be selected, a reputation-weighted average is applied to the normalized values. The weighting formula is as follows:

[0063]

[0064] in, for Overall reputation score;

[0065] When malicious behavior or a malfunction is detected in the global master node, select The node with the smallest value is selected as the new global master node.

[0066] Furthermore, the transaction request described in step S6 is processed as follows:

[0067] First, when Towards When initiating a charge / discharge request, Their identity needs to be verified. Will to Submit its digital certificate ;

[0068] According to Public key computation wallet address Check if a corresponding account exists in the system. If no relevant record is found in the system, then... verify The system retrieves the certificate and attempts to establish an account mapping. If the corresponding account information already exists, it proceeds to the identity verification stage and updates the fields appropriately.

[0069] During the verification process, First, obtain the local system time. and the validity period in the mapping table Compare the current time to confirm that it has not exceeded the certificate's expiration date. If the expiration date in the mapping table has expired, then check... The validity period of the uploaded certificate If the request has expired, it will be rejected outright.

[0070] For certificates that are still valid, Calculate its hash value and compare it with the certificate digest stored in the mapping table. A comparison is performed to determine if the certificate has been changed. If the hash values ​​do not match or this is the first time the connection has been established, a full certificate signature verification must be performed. If the verification passes, the mapping table is updated. If they match and the cache is not expired, the repeated signature verification steps can be skipped, and only the signatures on the certificates need to be compared. and signatures in the mapping table If they match, there is no need to repeat the signature verification.

[0071] After the certificate's validity has been verified, Use the public key in the mapping table verify Signature in transaction request This verifies that the request was generated by the corresponding private key holder. If all the above verifications pass, the request is cached.

[0072] Furthermore, the process of recording transactions on the blockchain using the layered PBFT consensus algorithm in step S7 is as follows:

[0073] Once a transaction corresponding to a charging / discharging request is completed, the aggregator node that processes the transaction will first collect the complete transaction record and report it to the top-level node in the region.

[0074] After the top-level node aggregates the transaction records reported by each aggregator node in its region, it broadcasts the batch of transaction records to all bottom-level nodes in the group within the region. After receiving the transaction records broadcast by the top-level node in the group, the bottom-level nodes in the group will first verify their legality and then execute the first PBFT consensus process within the group.

[0075] Once the PBFT consensus process of this group is agreed upon, the top-level node will submit the transaction record to the global master node.

[0076] After receiving the transaction records, the global master node sorts the set of transaction records submitted by all top-level nodes according to the timestamp. Then, the global master node performs a legality check on each transaction in the set. After the check passes, it organizes them into a pre-prepared message and then starts the RF-PBFT (Reputation-Based Fast PBFT) consensus process.

[0077] The consensus process of RF-PBFT is as follows:

[0078] The global master node will broadcast a pre-preparation message to the other top-level nodes, which includes the proposed block and related metadata;

[0079] Top-level node ( After receiving the readiness message, the non-master node broadcasts the readiness message to the remaining top-level nodes. Collect preparation messages from no less than 2 / 3 of the top-level nodes within the timeout threshold T. Then it enters the completed state and sends a commit message to the global master node;

[0080] If the top-level node If preparation messages from at least two-thirds of the top-level nodes are not collected within the timeout threshold T, the process enters the commit phase, broadcasting a commit message to other top-level nodes. Top-level nodes already in the completed state, upon receiving this commit message, will then... Return a commit message. When the node When at least 2 / 3 of the commit messages from the top-level nodes have been collected, the system enters the completion state and sends a commit confirmation message to the global master node.

[0081] Once the global master node has collected commit confirmation messages from no less than 2 / 3 of the top-level nodes, it determines that the block has reached consensus in the network and broadcasts the consensus message to all nodes in the system to achieve network-wide state synchronization.

[0082] Furthermore, the reputation mentioned in step S8 will be dynamically updated based on the consensus result after each round of consensus; the node reputation value will be updated accordingly. middle, It will change with each round; after the reputation value is calculated, steps S4 to S8 are re-executed on this basis to continuously drive the consensus process of subsequent transaction rounds.

[0083] The beneficial effects of this invention are as follows:

[0084] This invention effectively reduces the communication complexity of PBFT, improves the security of master node election, and enhances the scalability and operational efficiency of the system in large-scale V2G networks by constructing a hierarchical consensus structure and introducing reputation and random mechanisms. Simultaneously, in the reputation assessment process, it incorporates V2G scenario characteristics, comprehensively considers the node's historical transaction volume and the service evaluation of electric vehicles to aggregators, and introduces a round-decay factor to dynamically adjust historical reputation. Furthermore, it includes the average reputation value of nodes within the group in the overall reputation calculation, thereby improving the objectivity and stability of node reputation assessment. Attached Figure Description

[0085] Figure 1 This invention presents a blockchain-based V2G energy trading model.

[0086] Figure 2 This is a flowchart of a hierarchical PBFT consensus method according to the present invention. Detailed Implementation

[0087] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0088] like Figure 1 The diagram shows a V2G energy trading model, which constructs a decentralized energy trading network based on blockchain. The system mainly consists of electric vehicles (EVs), aggregators, and trusted entities (TAs). EVs, as distributed energy storage units, connect to the system through aggregators and participate in electricity trading. Aggregators are responsible for the unified management of the connected EVs and energy interaction with the power grid. The blockchain is used to record transaction information, and the TA is responsible for the identity registration and authentication management of each participating node in the system.

[0089] Furthermore, in step S1, the V2G scenario includes three types of entities: trusted certification authorities (TAs), local energy aggregators (LEAGs), and electric vehicles (EVs).

[0090] The Trusted Authentication Authority (TA) is responsible for system initialization and identity management. During system initialization, it generates common system parameters and completes identity registration and authentication for entities participating in the system. The TA assigns a unique legal identity identifier to EV and LEAG and generates a public-private key pair and digital certificate bound to their identities for subsequent identity authentication and data signing. During normal transactions, the TA does not participate in energy transaction execution or blockchain consensus; it only performs identity verification during entity registration or dispute tracing.

[0091] The unified format of the digital certificate is as follows:

[0092]

[0093] in, , For the corresponding role, take electric vehicles as an example, assuming there are a total of The first legal electric vehicle, recorded as the first One electric vehicle , for Unique identifier For TA for The issued public key; for Certificate validity period; For a digital signature, the user first checks the identity information contained in the certificate. Public key The data is hashed to obtain a hash digest. Then use your own private key Digital signatures are applied to hash digests to achieve both the verifiability and non-forgeability of certificates.

[0094] The local energy aggregator LEAG acts as a consensus node in the blockchain network and maintains the electric vehicles. The mapping relationship between identity information and transaction address is used for subsequent identity verification and energy transaction management. The mapping relationship is as follows:

[0095]

[0096] in, For electric vehicles A unique identifier; TA is a trusted certification authority The issued public key; for The hash digest of a digital certificate; for The validity period of a digital certificate; For trusted certification authorities (TAs) Signature of digital certificate information; for The transaction wallet address;

[0097] The electric vehicle (EV) is equipped with a bidirectional charging and discharging device and can participate in V2G energy trading as a distributed energy storage unit. The EV's computing and storage capabilities are relatively limited. The EV does not participate in the consensus process of the consortium blockchain and only retains the index of the corresponding transaction information.

[0098] Furthermore, in step S2, when calculating the reputation value of LEAG, multiple factors are comprehensively considered, including node performance score, node transaction score, and user rating. The specific calculation process includes:

[0099] First, a node's computational and communication performance directly impacts its efficiency in executing transaction verification, block generation, and message broadcasting during the consensus process. Therefore, node computing resources (e.g., the number of CPU cores) and network bandwidth are considered crucial components of reputation assessment. Due to inconsistent dimensions of performance metrics, a min-max normalization formula is used to standardize the metrics for unified measurement.

[0100]

[0101] in, Min represents a value in the original data. ) and max( The numbers ) represent the minimum and maximum values ​​in the dataset, respectively. After normalization, the result will be... It is mapped to the interval [0,1].

[0102] After normalization, for the first... Local aggregator nodes Its performance score It can be represented as:

[0103]

[0104] in, for The normalized value of the number of CPU cores. for The normalized value of the network bandwidth, where and Both are weighting coefficients, and ;

[0105] For the Local aggregator nodes In its first The amount of electricity processed in round consensus can be denoted as: for:

[0106]

[0107] in, for In the The number of successful transactions participated in during consensus rounds. For the first The electricity consumption of this transaction, in its initial state. ;

[0108] The Historical transaction processing volume Calculated using an iterative update formula:

[0109]

[0110] in, The round decay factor has a value range of (0,1), and the initial state is... ;

[0111] No. The verified historical transaction volume after the consensus round ends will be used to calculate the [number]th [round]. +1 round consensus transaction score Transaction score The formula is:

[0112]

[0113] Among them, the initial state .

[0114] For electric vehicles ,in The formula for calculating user weight is:

[0115]

[0116] in, For electric vehicles based on forward Historical trading volume The calculated user weight will be applied to the first... +1 round of service evaluation; It is a natural constant; for The historical trading volume with phase decay has a calculation formula that is similar to... ,but Only calculate Electricity traded by itself;

[0117] For the Local aggregator nodes Its new score in the nth round of consensus The calculation is as follows:

[0118]

[0119] in, Representing the Round of consensus, The score number is the number assigned to each person. represent In the The sequence number received in the round is The rating is an integer in the range [0, 5]. represent In the The total number of ratings received in the round; for The user who gives the kth rating in the nth round of consensus, To Provide the user weight corresponding to this rating;

[0120] User ratings Calculated using an iterative update formula:

[0121]

[0122] in, This is the round decay factor, with a value range of [value range missing]. ; for In the Wheel's historical rating, for In the The new rating of the wheel;

[0123] For the Local aggregator nodes Its reputation value is expressed as:

[0124]

[0125] in, yes Performance score; yes The transaction score; yes User ratings; These are the weighting coefficients, and ; The integrity coefficient ranges from (0,1] and has an initial value of 1. The calculation formula is as follows:

[0126]

[0127] in, for recent The number of times malicious acts or malfunctions occur during consensus-building. The range of values ​​is ;

[0128] for ,That = In other words, initial reputation depends on its performance score.

[0129] Furthermore, in step S3, the nodes participating in the consensus are divided into regions based on their geographical location. The region division can be achieved by any clustering algorithm based on distance metrics, such as the K-means clustering algorithm.

[0130] Furthermore, in step S4, the roles of nodes within a group are assigned based on their reputation values. For any group, the node with the highest reputation value within the group is selected and set as the top-level node of that group, based on the current reputation values ​​of each node in the group. This top-level node has the authority to participate in both intra-group consensus and cross-group consensus, and is responsible for summarizing intra-group consensus results and interacting with cross-group consensus. The sorting can be implemented using any sorting algorithm, including but not limited to quicksort, mergesort, etc.

[0131] Furthermore, the process of selecting the global master node described in step S5:

[0132] First, the overall reputation score of a node is calculated. This score is composed of the node's own reputation score and the average reputation score of its group. The probability of selecting each top-level node is positively correlated with its overall reputation score. The specific formula for the overall reputation score is as follows:

[0133]

[0134] in, For the first In the consensus round, the top-level node Overall reputation score This is the weighting adjustment coefficient, with a value range of (0,1), used to balance the proportion of a node's own reputation to the average reputation of its group. for The group you belong to; Grouping The total number of nodes within; For the first Consensus Group Average reputation score within;

[0135] The process of selecting a global master node using a verifiable random function (VRF) is as follows:

[0136] Top-level nodes of each group Call your own private key The current consensus round number and the hash of the latest block in the entire network are used as public inputs. Generate unique random values ​​using the VRF algorithm. At the same time, generate the corresponding verification proof. ; the random value Normalized to the [0,1] interval, the normalization formula is:

[0137]

[0138] in, The length of the fixed-length bit string output by the VRF;

[0139] To make nodes with higher overall reputation scores more likely to be selected, a reputation-weighted average is applied to the normalized values. The weighting formula is as follows:

[0140]

[0141] in, for Overall reputation score;

[0142] When malicious behavior or a malfunction is detected in the global master node, select The node with the smallest value is selected as the new global master node.

[0143] Furthermore, the transaction request described in step S6 is processed as follows:

[0144] First, when Towards When initiating a charge / discharge request, Their identity needs to be verified. Will to Submit its digital certificate ;

[0145] According to Public key computation wallet address Check if a corresponding account exists in the system. If no relevant record is found in the system, then... verify The system retrieves the certificate and attempts to establish an account mapping. If the corresponding account information already exists, it proceeds to the identity verification stage and updates the fields appropriately.

[0146] During the verification process, First, obtain the local system time. and the validity period in the mapping table Compare the current time to confirm that it has not exceeded the certificate's expiration date. If the expiration date in the mapping table has expired, then check... The validity period of the uploaded certificate If the request has expired, it will be rejected outright.

[0147] For certificates that are still valid, Calculate its hash value and compare it with the certificate digest stored in the mapping table. A comparison is performed to determine if the certificate has been changed. If the hash values ​​do not match or this is the first time the connection has been established, a full certificate signature verification must be performed. If the verification passes, the mapping table is updated. If they match and the cache is not expired, the repeated signature verification steps can be skipped, and only the signatures on the certificates need to be compared. and signatures in the mapping table If they match, there is no need to repeat the signature verification.

[0148] After the certificate's validity has been verified, Use the public key in the mapping table verify Signature in transaction request This verifies that the request was generated by the corresponding private key holder. If all the above verifications pass, the request is cached.

[0149] The format of a transaction request is as follows:

[0150]

[0151] in, For the first electric vehicles The first The next charge / discharge request includes vehicle identification. Power demand (Unit: kWh), Transaction Demand Type (0 represents charging demand, 1 represents discharging demand), expected transaction price range (Unit: Yuan / kWh) Timestamp used to defend against replay attacks The unique identifier of the request =H( ), Digital signature = The original request information is not stored directly on the blockchain; it is only after the transaction is successful that a unique identifier corresponding to the request is generated. It is recorded on the chain as an index record.

[0152] Furthermore, upon completion of the transaction in step S7, the corresponding transaction record will be written to the blockchain. Electric vehicles can autonomously choose their trading partners based on their own electricity / supply needs, transaction cost preferences, and other practical factors. They can interact with the power grid or engage in point-to-point electricity trading with other electric vehicles. Depending on the trading partner, the data format of the transaction record is divided into two categories: electric vehicles... - Electric vehicles Transaction records between Defined as:

[0153]

[0154] Among them, subscript Indicates the buyer's electric vehicle serial number, subscript Indicates the seller's electric vehicle serial number, superscript express No. This request, superscript express No. This request; assuming No. The demand and No. This is the second time that the needs are matched. express and The requested transaction record; ={ This refers to transaction information, including the amount of electricity traded. (Unit: kWh), Transaction Price The timestamp corresponding to the transaction Consensus rounds corresponding to transactions ; and These are unique identifiers representing charge / discharge requests; in addition... Also includes transaction summaries ,buyer right Digital signature Seller ; Assumption As the intermediary in this transaction, Verify signature , After it is valid, use your own private key to pair Signature, get This forms the final transaction record;

[0155] As for electric vehicles -Power grid Its transaction records Defined as:

[0156]

[0157] Among them, subscript Indicates the electric vehicle's serial number, subscript Indicates the local aggregator's ID; transaction information. Including the unique identifier of local aggregators Transaction volume (Unit: kWh), Transaction Price The timestamp corresponding to the transaction Consensus rounds corresponding to transactions ; represent The request; For transaction summary; for right Digital signature; for Verify signature After effective Digital signature.

[0158] Furthermore, the process of recording transactions on the blockchain using the layered PBFT consensus algorithm in step S7 is as follows:

[0159] Once a transaction corresponding to a charging / discharging request is completed, the aggregator node that processes the transaction will first collect the complete transaction record and report it to the top-level node in the region.

[0160] After the top-level node aggregates the transaction records reported by each aggregator node in its region, it broadcasts the batch of transaction records to all bottom-level nodes in the group within the region. After receiving the transaction records broadcast by the top-level node in the group, the bottom-level nodes in the group will first verify their legality and then execute the first PBFT consensus process within the group.

[0161] Once the PBFT consensus process of this group is agreed upon, the top-level node will submit the transaction record to the global master node.

[0162] After receiving the transaction records, the global master node sorts the set of transaction records submitted by all top-level nodes according to the timestamp. Then, the global master node performs a legality check on each transaction in the set. After the check passes, it organizes them into a pre-prepared message and then starts the RF-PBFT (Reputation-Based Fast PBFT) consensus process.

[0163] The consensus process of RF-PBFT is as follows:

[0164] The global master node will broadcast a pre-preparation message to the other top-level nodes, which includes the proposed block and related metadata;

[0165] Top-level node ( After receiving the readiness message, the non-master node broadcasts the readiness message to the remaining top-level nodes. Collect preparation messages from no less than 2 / 3 of the top-level nodes within the timeout threshold T. Then it enters the completed state and sends a commit message to the global master node;

[0166] If the top-level node If preparation messages from at least two-thirds of the top-level nodes are not collected within the timeout threshold T, the process enters the commit phase, broadcasting a commit message to other top-level nodes. Top-level nodes already in the completed state, upon receiving this commit message, will then... Return a commit message. When the node When at least 2 / 3 of the commit messages from the top-level nodes have been collected, the system enters the completion state and sends a commit confirmation message to the global master node.

[0167] Once the global master node has collected commit confirmation messages from no less than 2 / 3 of the top-level nodes, it determines that the block has reached consensus in the network and broadcasts the consensus message to all nodes in the system to achieve network-wide state synchronization.

[0168] Furthermore, the reputation mentioned in step S8 will be dynamically updated based on the consensus result after each round of consensus; the node reputation value will be updated accordingly. middle, It will change with each round; after the reputation value is calculated, steps S4 to S8 are re-executed on this basis to continuously drive the consensus process of subsequent transaction rounds.

[0169] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be within the scope of protection of the present invention.

Claims

1. A reputation-based hierarchical PBFT consensus method for V2G scenarios, characterized in that, Includes the following steps: S1. Trusted Certification Authority (TA) assigns unique and legitimate identity identifiers to local energy aggregator LEAG and electric vehicle EV, and generates public-private key pairs and digital certificates bound to their identities; S2. Configure LEAGs with valid identities as consensus nodes in the blockchain network, and initialize the reputation value of each node according to the preset reputation evaluation mechanism; S3. Based on the geographical location of each consensus node, the nodes participating in the consensus are divided into regional clusters to form several groups, each group containing multiple nodes with similar geographical locations; S4. In each group, select the node with the highest reputation based on its reputation value, set it as the top-level node and the master node within the group, and enable it to participate in the consensus within and across groups; the remaining nodes are set as bottom-level nodes and only participate in the consensus process within the group. S5. Among the top-level nodes selected in each group, a global master node is selected by comprehensively considering the node's own reputation value and the average reputation value of its group, and using a verifiable random function. The global master node is responsible for the final coordination and confirmation of cross-group consensus. S6. Each consensus node is responsible for receiving and collecting energy transaction requests submitted by electric vehicles within the region, and caching the transaction requests; S7. When a transaction is completed, the consensus node collects the transaction records and confirms the consistency of the transactions in the current round based on the hierarchical PBFT consensus method; S8. Update the reputation values ​​of all nodes based on the consensus results of this round, and repeat steps S4 to S8 to complete subsequent consensus rounds.

2. The reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S1, the unified format of the digital certificate is: ； in, These are the entity roles in the system, including electric vehicles (EVs) and local energy aggregators like LEAG; For the entity number under the corresponding role, For entities A unique identifier; For trusted certification authorities (TAs) as entities The issued public key; For entities The validity period of a digital certificate; Use their private key right , and hash digest A digital signature is generated through the signature process.

3. The reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S1, LEAG, a local energy aggregator, acts as a consensus node in the blockchain network, verifying and packaging energy transaction data; LEAG also maintains electric vehicles. The mapping relationship between identity information and transaction address is as follows: ； in, For electric vehicles A unique identifier; TA is a trusted certification authority The issued public key; for The hash digest of a digital certificate; for The validity period of a digital certificate; For trusted certification authorities (TAs) Signature of digital certificate information; for The transaction wallet address.

4. The reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S2, the reputation assessment mechanism comprehensively considers multiple factors such as node performance score, node transaction score, and user rating. The node performance score is calculated using a minimum-maximum normalization formula to standardize the node's computing resources and network bandwidth, with the consensus being: ； in, This represents the numerical value in the original data. and These represent the minimum and maximum values ​​in the dataset, respectively. The value is the normalized value; For the Local aggregator nodes Its performance score It can be represented as: ； in, for The normalized value of the computational resource index, for The normalized value of the network bandwidth, where and These are the weighting coefficients, and ; The calculation of node transaction scores, for the 1st node... Local aggregator nodes In its first The amount of electricity processed in round consensus can be denoted as: for: ； in, for In the The number of successful transactions participated in during consensus rounds. For the first The electricity consumption of this transaction, in its initial state. ; The Historical transaction processing volume Calculated using an iterative update formula: ； in, The round decay factor has a value range of (0,1), and the initial state is... ; No. The verified historical transaction volume after the consensus round ends will be used to calculate the [number]th [round]. Round consensus transaction score Transaction score The formula is: ； Among them, the initial state ; User rating calculation for electric vehicles ,in The formula for calculating user weight is: ; in, For electric vehicles based on forward Historical trading volume The calculated user weight will be applied to the first... Wheel service evaluation; It is a natural constant; for The historical trading volume with phase decay has a calculation formula that is similar to... ,but Only calculate Electricity traded by itself; For the Local aggregator nodes In its first New scoring in consensus rounds The calculation is as follows: ； in, Representing the Round of consensus, The score number is the number assigned to each person. represent In the The sequence number received in the round is The rating is an integer in the range [0, 5]. represent In the The total number of ratings received in the round; for In the The consensus in the first round gives the first One user rating, To Provide the user weight corresponding to this rating; User ratings Calculated using an iterative update formula: ； in, This is the round decay factor, with a value range of [value range missing]. ; for In the Wheel's historical rating, for In the The new rating of the wheel; For the Local aggregator nodes Its reputation value is expressed as: ； in, yes Performance score; yes The transaction score; yes User ratings; These are the weighting coefficients, and ; The integrity coefficient ranges from (0,1] and has an initial value of 1. The calculation formula is as follows: ； in, for recent The number of times malicious acts or malfunctions occur during consensus-building. The range of values ​​is .

5. A reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S5, the overall reputation value of the top-level node Based on the node's own reputation value It is composed of the average reputation score of its group, and the formula is: ； in, For the first In the consensus round, the top-level node Overall reputation score This is the weighting adjustment coefficient, with a value range of (0,1), used to balance the proportion of a node's own reputation to the average reputation of its group. for The group you belong to; Grouping The total number of nodes within; For the first Consensus Group The average reputation score within the country.

6. A reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S5, the process of selecting the global master node using a verifiable random function (VRF) is as follows: Top-level nodes of each group Call your own private key The current consensus round number and the hash of the latest block in the entire network are used as public inputs. Generate unique random values ​​using the VRF algorithm. At the same time, generate the corresponding verification proof. ; the random value Normalized to the [0,1] interval, the normalization formula is: ； in, The length of the fixed-length bit string output by the VRF; To make nodes with higher overall reputation scores more likely to be selected, a reputation-weighted average is applied to the normalized values. The weighting formula is as follows: ； in, for Overall reputation score; When malicious behavior or a malfunction is detected in the global master node, select The node with the smallest value is selected as the new global master node.

7. A reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S6, transaction request processing includes an authentication process, specifically: electric vehicles To local energy aggregators When initiating a charge / discharge request, submit its digital certificate. ; according to public key Calculate its wallet address And check if there is a corresponding account mapping relationship in the system; If it does not exist, then verify. And establish account mapping; if it exists, proceed to the identity verification stage; During the verification process, Perform the following steps: Get local system time The certificate validity period stored in the mapping table The comparison confirms that the current time has not exceeded the certificate's validity period; If the validity period in the mapping table has expired, then check. The validity period of the uploaded certificate If the request has expired, it will be rejected outright. For certificates that are still valid, Calculate its hash value and compare it with the certificate digest stored in the mapping table. Compare and determine if the certificate has been changed; If the hash values ​​do not match or this is the first time the connection has been established, a full certificate signature verification must be performed, and the mapping table will be updated after the verification is successful. If the hash values ​​match and the cache is not expired, the repeated signature verification steps are skipped, and only the certificate signatures are compared. and historical signatures in the mapping table If the signatures match, there is no need to repeat the signature verification; otherwise, the request is rejected. After the certificate's validity has been verified, Use the public key in the mapping table verify Signature in transaction request This verifies that the request was generated by the corresponding private key holder; if all the above verifications pass, the request is cached.

8. A reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 1, characterized in that, In S7, the layered PBFT consensus algorithm handles the on-chain transaction process as follows: Once a transaction corresponding to a charging / discharging request is completed, the aggregator node that processes the transaction will first collect the complete transaction record and report it to the top-level node in the region. After the top-level node aggregates the transaction records reported by each aggregator node in its region, it broadcasts the batch of transaction records to all bottom-level nodes in the group within the region. After receiving the transaction records broadcast by the top-level node in the group, the bottom-level nodes in the group will first verify their legality and then execute the first PBFT consensus process within the group. Once the PBFT consensus process of this group is agreed upon, the top-level node will submit the transaction record to the global master node. After receiving the transaction records, the global master node sorts the set of transaction records submitted by all top-level nodes according to the timestamp. Then, the global master node performs a legality check on each transaction in the set. After the check passes, it organizes them into a pre-prepared message and then starts the RF-PBFT (Reputation-Based Fast PBFT) consensus process.

9. A reputation-based hierarchical PBFT consensus method for V2G scenarios according to claim 8, characterized in that, In S7, the RF-PBFT consensus process is as follows: The global master node will broadcast a pre-preparation message to the other top-level nodes, which includes the proposed block and related metadata; Top-level node ( After receiving the readiness message, the non-master node broadcasts the readiness message to the remaining top-level nodes; when Collect preparation messages from no less than 2 / 3 of the top-level nodes within the timeout threshold T. Then it enters the completed state and sends a commit message to the global master node; If the top-level node If no less than 2 / 3 of the top-level nodes' preparation messages are collected within the timeout threshold T, the commit phase begins, and a commit message is broadcast to other top-level nodes. When a top-level node that has already entered the completed state receives this commit message, it sends a message to... Return a commit message; when the node When at least 2 / 3 of the commit messages from the top-level nodes have been collected, the system enters the completion state and sends a commit confirmation message to the global master node. Once the global master node has collected commit confirmation messages from no less than 2 / 3 of the top-level nodes, it determines that the block has reached consensus in the network and broadcasts the consensus message to all nodes in the system to achieve network-wide state synchronization.

Images