A blockchain-based energy security transaction method for internet of vehicles

Abstract

The present application relates to a kind of blockchain-based vehicle networking energy security transaction method, belong to vehicle networking and distributed energy transaction field.The method aims at solving the problem of fair pricing under asymmetric information, user privacy protection and transaction efficiency.The gist is that: authority issues certificate for vehicle and roadside unit;Vehicle node signs broadcast transaction request;Roadside unit verifies and broadcasts demand and collects response, then triggers smart contract;The contract is based on bayesian Nash equilibrium model, and the optimal equilibrium transaction volume and price are obtained by solving the first-order condition of maximum expected utility, to realize automatic matching;Identity and data privacy are protected by combining ring signature and zero-knowledge proof;Hybrid consensus mechanism is used to improve efficiency;Finally, deposit escrow, settlement and default handling are automatically completed by contract.The method is used to build decentralized, safe and reliable vehicle networking energy transaction market.

Description

Technical Field

[0001] This invention relates to the field of vehicle-to-everything (V2X) communication and distributed data processing technology, and in particular to a blockchain-based V2X energy security trading method, specifically involving an inter-node energy trading collaboration mechanism, an anonymous identity verification method, a trading qualification verification method, a balanced pricing strategy, and a network load adaptive control method. Background Technology

[0002] With the continuous development of electric vehicle technology and vehicle-to-everything (V2X) communication technology, vehicles are gradually acquiring energy storage and exchange capabilities. A collaborative model based on energy sharing among vehicles can help alleviate local energy supply and demand imbalances and improve overall energy efficiency.

[0003] In existing technologies, vehicle energy trading largely relies on centralized coordination mechanisms. These mechanisms have several limitations in dynamic network environments. The presence of a central node makes the system's stability susceptible to single-point failures, and the reliability and consistency of transaction data depend on the reliable operation of the central node. When the central node malfunctions, the overall system functionality is easily affected.

[0004] On the other hand, vehicle energy trading involves node identity information, transaction behavior information, and account status information. In traditional interaction models, node identity and transaction behavior are easily correlated and analyzed, making it difficult to meet privacy protection requirements. Furthermore, transaction qualification verification typically requires disclosing account resource information, posing a risk of sensitive data leakage.

[0005] In transaction matching and pricing, traditional methods often employ fixed rules or simple bidding strategies. These methods struggle to achieve stable equilibrium outcomes under conditions of incomplete information, easily leading to increased transaction failure rates or decreased resource allocation efficiency.

[0006] Meanwhile, in a blockchain environment, the choice of consensus mechanism directly affects system throughput and latency. Fixed consensus strategies are ill-suited to the dynamic changes in transaction request volume and network load in a connected vehicle environment.

[0007] Therefore, it is necessary to propose an energy trading method that can balance transaction security, privacy protection, pricing rationality, and system adaptability. Summary of the Invention

[0008] This invention proposes a blockchain-based method for secure energy trading in the Internet of Vehicles (IoV), aiming to achieve secure, efficient, and fair energy trading through technologies such as game theory pricing, dynamic consensus, anonymous authentication, and automatic execution of smart contracts.

[0009] In the method of this invention, firstly, an authoritative institution issues digital certificates to the vehicles and roadside units participating in the transaction, and creates an account for each registered user containing a public-private key pair, digital certificate, account balance, and energy balance; this is the S1 system initialization and account registration step. When a vehicle needs to trade, the S2 energy transaction request and broadcast step is initiated. The vehicle generates transaction request information containing a transaction type identifier, transaction quantity, acceptable price range, and timestamp based on its own energy status, signs it with its own private key, and sends it to the connected roadside unit. In the S3 request verification and demand broadcast step, after receiving the request, the roadside unit verifies the vehicle's identity and certificate validity. If successful, it broadcasts the demand information in the local network. The broadcast content includes a timestamp, demand waiting time limit, transaction quantity, and price range. In the S4 transaction response collection step, other interested vehicles verify the broadcast source and send response information to the roadside unit containing transaction intention, available energy quantity or demand information, and a timestamp. In the S5 transaction matching and smart contract execution step, the roadside unit collects the response information within the demand waiting time limit and then triggers the smart contract. The smart contract matches buyers and sellers based on a preset pricing mechanism, calculates the optimal transaction price and volume, and generates a matching result. In the S6 transaction execution and settlement steps, the successfully matched buyers and sellers pay a deposit to the escrow account according to the smart contract instructions. After the transaction is completed, the smart contract automatically updates the balance and energy quantity in both parties' accounts. If one party defaults, the deposit is automatically transferred to the non-defaulting party through the smart contract.

[0010] The aforementioned pricing mechanism is based on a Bayesian Nash equilibrium model. Firstly, in the S211 step of establishing the incomplete information game model and public belief, the private type of the buyer node is set as the true valuation per unit of energy. The seller node's private type represents the true cost per unit of energy. Both follow the intervals and The uniform distribution of costs on the surface leads to a common belief, namely, the buyer's expectation of the seller's average cost. Seller's expectation of the buyer's average valuation In S212, these prior distribution parameters are set by an authoritative body and stored in the blockchain as public belief parameters for use by smart contracts. In S213, buyer nodes submit their energy demand range. and acceptable unit price range The seller node submits its available energy quantity. and acceptable unit price range .

[0011] In the steps of defining the strategy space, market clearing, and expected utility function in S221, the smart contract assumes that both buyers and sellers follow a linear pricing strategy, and the buyer's pricing function is: The seller's quotation function is ,in, For trading volume, The policy parameters to be determined are specifically as follows: The highest unit price the buyer is willing to pay. This refers to the diminishing marginal rate of return, which is the rate at which the buyer's bid decreases as trading volume increases. The lowest unit price the seller is willing to accept. This refers to the marginal rate of increase in asking price, which is the rate at which the seller's asking price rises as transaction volume increases. The transmission loss factor is... This refers to the publicly visible distance between the two parties. , All are greater than 0.

[0012] In S222, the market clearing condition is that the bids from both buyers and sellers are equal. This leads to the solution of the equilibrium trading volume. Based on the Bayesian property of incomplete information games, S223 defines the buyer's expected utility. and seller's expected utility .

[0013] In step S23, which solves for the Bayesian Nash equilibrium strategy parameters, the smart contract solves for the strategy that maximizes expected utility by setting the first-order partial derivatives of the expected utility function with respect to the respective strategy parameters to zero. This is derived from the first-order condition for maximizing the buyer's expected utility in step S231. and The first-order condition for maximizing the seller's expected utility, derived in S232, is... and .

[0014] In step S24, deriving the equilibrium trading solution and pre-setting it as an executable function, the aforementioned strategy parameters are substituted into the market clearing formula to obtain the Bayesian Nash equilibrium trading volume and equilibrium price expressed in terms of private type, public parameters, and public beliefs. In S242, to transform the theoretical equilibrium into an executable function for the smart contract, a correspondence is established between the private type and the midpoint of the public price range; that is, assuming... and incorporate public beliefs Finally, the explicit equilibrium solution function, which is entirely represented by the publicly submitted parameters and the system's common belief parameters, is derived:

[0015] First, calculate the intermediate parameters:

[0016]

[0017] This leads to the formulas for calculating the equilibrium trading volume Q and the equilibrium price P:

[0018]

[0019] In the S25 equilibrium matching step triggered and executed by the RSU, after collecting and verifying the transaction requests and responses from both buyers and sellers, the roadside unit sends the publicly submitted parameters and system public information parameters to the smart contract to trigger execution. Upon receiving the parameters, the smart contract calls its internally configured explicit equilibrium solution function to calculate the matching result and verify whether it meets the publicly submitted constraints. and ,at the same time If the verification passes, a final matching command is generated; otherwise, a failure is returned.

[0020] To adapt to different transaction loads, this invention also introduces an adaptive hierarchical hybrid consensus mechanism based on energy transaction load awareness. In the S31 energy transaction load intensity calculation step, the number of energy transaction requests that have passed legality verification is counted within a preset statistical time window before the start of each new block generation cycle. And according to the formula Calculate the load intensity of energy trading, where The system presets a maximum transaction processing capacity. In the S32 consensus mode determination step, the system pre-sets a load determination threshold. ,when When the system enters low-load consensus mode, it uses proof-of-stake consensus. When the system enters a high-load consensus mode, it uses an improved practical Byzantine fault-tolerant consensus.

[0021] In the step of calculating the overall consensus weight of node S33, the overall consensus weight is calculated for the i-th roadside unit node participating in the consensus.

[0022]

[0023] in, As the overall consensus weight of the nodes, Contributing indicators to node energy trading As an indicator of node operational stability, As a node reputation indicator, This refers to the node's ability to adapt to resource load. The weighting coefficients are and satisfy the following conditions: .

[0024] S331 Energy Trading Contribution Indicator

[0025]

[0026] in, For energy trading statistics time window, The number of energy transactions completed by the node within the window. For the k-th energy transaction completed by node, For the current time, The moment the transaction occurs. This is the time decay factor.

[0027] S332 operational stability indicators

[0028]

[0029] in, This represents the number of consensus rounds successfully completed by the node. The number of consensus rounds in which the node participates. This represents the percentage of nodes that are online.

[0030] S333 Node Reputation Indicators

[0031]

[0032] in, The number of times a node violates regulations or exhibits abnormal behavior. Set the maximum number of anomalies that the system can tolerate.

[0033] Resource load adaptability index in S334

[0034]

[0035] in, This represents the current overall resource utilization ratio of the node. Set the maximum resource capacity for the system.

[0036] In the S34 weight coefficient dynamic adjustment mechanism step, the system presets the initial value of the weight coefficient and dynamically updates and normalizes it according to the energy trading load intensity. In the S35 leader node election mechanism step, the node with the largest weight value is selected as the leader node according to the comprehensive consensus weight. If the leader fails to complete the block proposal within the preset block generation time, a decay factor is applied to its contribution index and stability index, and node election is re-executed.

[0037] In the S36 low-load consensus mode execution process, a proof-of-stake consensus process is adopted. The leader node generates a new block, and the authorized nodes perform legality verification on the new block. After obtaining a simple majority confirmation from no less than the total number of authorized nodes, the block is submitted to the blockchain ledger. If no confirmation is obtained within a preset time, the leader election is re-executed.

[0038] In the S37 high-load consensus mode execution process, an improved practical Byzantine fault-tolerant consensus process is adopted. In S371 consensus sub-region division, the roadside unit nodes are divided into multiple consensus sub-regions according to the physical deployment topology. In S372 intra-regional consensus confirmation, the leader node broadcasts a new block proposal to its region, and nodes within the region perform block verification and broadcast confirmation messages. When the number of confirmation messages reaches at least two-thirds of the total number of nodes in that region, consensus is considered reached within the region. In S373 inter-regional consensus confirmation, each region elects a regional representative node. The regional representative node broadcasts the regional consensus result and verifies and confirms it. When the confirmation result reaches at least two-thirds of the total number of regional representative nodes, consensus is considered reached across the entire network. In S374 block submission, after consensus is reached across the entire network, each node writes the new block into the blockchain ledger. In the S38 improved Byzantine fault-tolerant consensus structure features, the improved practical Byzantine fault-tolerant consensus reduces inter-node communication overhead through a regional hierarchical structure.

[0039] Furthermore, this invention integrates multiple privacy protection and security mechanisms. In the S4 ring signature anonymization mechanism, during the S41 ring key generation, it is assumed that the system has... The main signature vehicles. Each vehicle Each has a public-private key pair; the public key is... The private key is All these public keys are put together to form a public key set R. .

[0040] In S42 ring signature generation, when a certain vehicle Need to give a message During the signing process, it performs the following steps. S421 selects a random number. S422 is calculated as an initial commitment value. S423 is for all other vehicles in the ring road. , Select random numbers in sequence Then calculate S424 addresses the actual signatory. You need to choose one Close the entire loop. To meet By solving this equation, we obtain... The final generated ring signature Put this signature and message Send them out together.

[0041] During the S43 ring signature verification, the roadside unit receives the message. and signature Then, use the public key set To verify. S431 recalculated. , S432 calculates iteratively. S433 checks the final calculated result. Is it equal to the first value in the signature? If they are equal, the verification passes, indicating that the message originated from the ring. It is a legitimate member of the organization, but it is unknown which one.

[0042] In the S5 zero-knowledge proof verification mechanism, the content to be proven in the establishment of the S51 zero-knowledge proof system is: the prover has a valid digital certificate. The private key corresponding to this certificate is Energy balance in the witness's account Sufficient, that is ; The required trading volume, and its declared trading parameters. For example, the price range and quantity range satisfy the internal consistency constraint. .

[0043] In the S52 zero-knowledge proof generation, a zero-knowledge proof is constructed. This proves that he knew a set of secret witnesses. Meeting the requirements of public statements :

[0044]

[0045] in, From and Derived public key, These are private parameters, such as the lower limit of the truly acceptable price. To publicly declare parameters, For certificate verification algorithms, This is the constraint verification function.

[0046] In S53 zero-knowledge proof verification, the roadside cell node acts as the verifier and receives the proof. and publicly available parameters Then, run the verification algorithm. If the output is true, it confirms that the proving party is legally qualified and the claim is valid, but no information regarding... Precise value and Specific information.

[0047] In the S6 information security and verification mechanism, in step S2, the vehicle node uses its private key to digitally sign the transaction request information to ensure the integrity and non-repudiation of the information. In step S3, the roadside unit node uses the public key in the requesting vehicle's certificate to verify its signature and the validity of its digital certificate to confirm the legitimate identity of the requesting node. In the S7 transaction constraint and filtering mechanism, in step S3, the broadcast information includes a waiting time limit. In step S4, the roadside unit node only processes the response information received within this time limit; expired information is discarded. In step S72, during the matching process, the smart contract prioritizes matching buyer and seller nodes that are geographically closer. The S8 smart contract also includes transaction security and default handling mechanisms. In step S5, the updates to the account balance and energy balance are automatically executed by the smart contract. If one party defaults, the smart contract automatically transfers the deposit paid by the defaulting party to the non-defaulting party's account. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating the overall process of the energy security trading method described in this embodiment of the invention.

[0049] Figure 2 This is a flowchart of the Bayesian Nash equilibrium matching process described in an embodiment of the present invention.

[0050] Figure 3 This is a schematic diagram illustrating the workflow of the hybrid consensus mechanism described in an embodiment of the present invention. Detailed Implementation

[0051] like Figure 1As shown, the energy security trading method of this invention includes system initialization, transaction request and broadcasting, request verification and demand broadcasting, transaction response collection, transaction matching and smart contract execution, and transaction execution and settlement. In the initialization phase, S1 System Initialization and Account Registration: An authoritative institution issues digital certificates to all vehicles and roadside units and creates accounts. Account content includes public / private key pairs, digital certificates, account balances, and energy balances. Taking a typical transaction as an example, buyer vehicle A generates a transaction request based on its energy shortage. S2 Energy Transaction Request and Broadcasting: The request information includes the required electricity, acceptable unit price range, timestamp, etc., and is sent to the currently connected roadside unit RSU1 after being signed with its private key. S3 Request Verification and Demand Broadcasting: After verifying the validity of vehicle A's certificate and signature, RSU1 broadcasts the demand in the local network with a waiting time limit. S4 Transaction Response Collection: After receiving the broadcast, seller vehicle B, if willing to sell energy, sends a response to RSU1. S5 Transaction Matching and Smart Contract Execution: After collecting multiple responses within the waiting time limit, RSU1 triggers a smart contract for matching. 6. Transaction Execution and Settlement: After successful matching, both the buyer and seller pay a deposit to the escrow account according to the smart contract instructions; upon final completion of the transaction, the smart contract automatically updates the balance and energy quantity in both parties' accounts. If one party defaults, the deposit is automatically transferred to the non-defaulting party via the smart contract.

[0052] The Bayesian Nash equilibrium matching process is as follows: Figure 2 As shown. The smart contract incorporates a pricing model based on Bayesian Nash equilibrium. Both the buyer and seller submit public parameters in their requests and responses, such as the buyer's demand quantity range and acceptable unit price range, and the seller's available energy quantity and acceptable unit price range. System public belief parameters include the buyer's valuation range and the seller's cost range, which are pre-stored on the blockchain. S25 is triggered by the RSU and executes equilibrium matching: the smart contract substitutes these parameters into the explicit equilibrium solution function, calculates the equilibrium transaction quantity and equilibrium price, and verifies whether the calculation results satisfy the public constraints of both parties. If the verification passes, a matching success instruction is generated; otherwise, a failure is returned. In this embodiment, vehicle A's demand is 5 to 10 kWh, with an acceptable unit price range of 0.3 to 0.5 yuan per kWh; vehicle B has 8 kWh available for sale, with an acceptable unit price range of 0.25 to 0.45 yuan per kWh; the system public belief parameters are set as follows: the buyer's valuation is evenly distributed between 0.2 and 0.6 yuan per kWh, and the seller's cost is evenly distributed between 0.15 and 0.55 yuan per kWh. Considering that the product of the transmission loss coefficient and the distance is 0.01, the smart contract calculates an equilibrium transaction volume of 7.33 kWh and an equilibrium price of 0.39 yuan per kWh, both of which are within the acceptable range for both parties, satisfying all constraints, and the match is successful.

[0053] S6 Transaction Execution and Settlement: Upon successful matching, the smart contract requires both parties to pay a deposit equivalent to 10% of the transaction amount, which is then transferred to an escrow account. Once the transaction is actually completed—that is, vehicle B supplies electricity to vehicle A via a roadside unit and this is confirmed by both parties—the smart contract automatically transfers the corresponding funds from the escrow account to the seller, while simultaneously updating the fund and energy balances in both parties' accounts. If either party fails to fulfill the transaction, for example, vehicle A fails to pay or vehicle B fails to supply electricity, the smart contract automatically transfers the deposit paid by the defaulting party to the non-defaulting party.

[0054] The implementation of consensus mechanisms, such as Figure 3 As shown. S31 Energy Transaction Load Intensity Calculation: At the beginning of each block generation cycle, the system counts the number of valid transactions over a past period and calculates the load intensity. Assuming that the number of valid transactions in the current cycle is high and the load intensity is higher than the threshold, S32 Consensus Mode Determination: The system determines that it is in high load mode and starts the improved PBFT consensus. S371 Consensus Sub-region Division: All roadside unit nodes are divided into several sub-regions according to their geographical location. S372 Intra-region Consistency Confirmation: Each sub-region first undergoes a pre-preparation, preparation, and confirmation phase to achieve intra-region consistency. This process requires confirmation from at least two-thirds of the nodes. S373 Inter-region Consistency Confirmation: Subsequently, the representative nodes elected by each region conduct a second round of consensus between regions, which also requires confirmation from at least two-thirds of the representatives. S374 Block Commit: Finally, all network nodes write the new block into the ledger. If the load intensity is lower than the threshold, PoA consensus is adopted. S36 Low Load Consensus Mode Execution Flow: The node with the highest comprehensive weight directly generates the block, and other authorized nodes submit it after simple majority confirmation. In both modes, the overall weight of a node is dynamically calculated based on its energy trading contribution, operational stability, reputation, and resource load adaptability. The S35 leader node election mechanism selects a leader based on these factors.

[0055] Regarding privacy protection, Vehicle A can use ring signature technology when sending transaction requests. S42 Ring Signature Generation: It generates a ring signature from a set of public keys containing its own public key using a specific algorithm. This allows the verifier to confirm that the signature comes from a member of that set, but not which one. S43 Ring Signature Verification: After the roadside unit verifies the ring signature, it can be assured that the message comes from a legitimate ring member. Simultaneously, Vehicle A can also generate zero-knowledge proofs. S52 Zero-Knowledge Proof Generation: This proves that it holds a valid digital certificate, has sufficient account balance, and that the quoted price range conforms to internal logic, without revealing the specific content of the certificate, the exact balance, or the true estimated base price. S53 Zero-Knowledge Proof Verification: After the roadside unit verifies the proof, the legitimacy of Vehicle A and the authenticity of the request are confirmed, and subsequent processes can continue.

[0056] The smart contract also incorporates built-in transaction constraints and filtering mechanisms. S71 Transaction Constraints and Filtering Mechanisms: For example, a waiting time limit attached to broadcast requests prevents stale responses from interfering with matching; during matching, priority is given to buyers and sellers with closer geographical distances, helping to reduce transmission losses and costs. S8 Transaction Security and Default Handling Mechanisms: In the event of a default, the smart contract automatically executes a deposit transfer to ensure transaction fairness.

Claims

1. A blockchain-based method for energy security trading in the Internet of Vehicles, characterized in that, Includes the following steps: S1. System Initialization and Account Registration: The authoritative body issues digital certificates to vehicles and roadside units participating in energy trading; An account is created for each registered vehicle user, and the account content includes at least: public and private key pair, digital certificate, account balance, and energy balance. S2. Energy Transaction Request and Broadcast: Vehicle nodes generate transaction request information based on their own energy status. The request information includes at least: transaction type identifier, transaction quantity, acceptable price range, and timestamp. Vehicle nodes sign the request information using their own private key and send it to the connected roadside unit nodes. S3. Request Verification and Demand Broadcast: Upon receiving a request, the roadside unit node verifies the identity and certificate validity of the sending vehicle node. After successful verification, it broadcasts the transaction demand information within the local network. The broadcast information includes a timestamp, demand waiting time limit, transaction quantity, and price range. S4. Transaction Response Collection: Other vehicle nodes that receive the broadcast information verify the broadcast source. If they intend to participate in the transaction, they send response information to the roadside unit node. The response information includes the transaction intention, the available energy quantity or demand information, and a timestamp. S5. Transaction Matching and Smart Contract Execution: The roadside unit node collects response information within the demand waiting time limit and triggers a smart contract; the smart contract matches buyers and sellers based on a preset pricing mechanism, calculates the optimal transaction price and transaction volume, and generates a matching result; S6. Transaction Execution and Settlement: The matched buyer and seller pay a deposit to the escrow account designated by the smart contract according to the instructions of the smart contract; after the transaction is completed, the account balance and energy balance in the buyer and seller's accounts are automatically updated through the smart contract; if one party defaults, the deposit is automatically transferred to the other party through the smart contract.

2. The method as described in claim 1, characterized in that, The pricing mechanism in step S5 is based on the Bayesian Nash equilibrium model, specifically including: S21. Establishing an incomplete information game model and public beliefs: S211. Buyer node B, whose private type is a true valuation of unit energy. This information is known only to buyer B; seller node S, whose private type is the true cost of providing a unit of energy. This information is known only to seller S; and it assumes the true valuation of all buyers in the system. Independent and following a public prior probability distribution, and within the interval [missing information]. Uniform distribution on the surface; assuming the true cost of all sellers in the system. Independent and following a public prior probability distribution, and within the interval [missing information]. The system exhibits a uniform distribution over time; based on this prior distribution, the common beliefs formed in the system include: the buyer's expected estimate of the seller's average cost. Seller's expected estimate of buyer's average cost . S212. The prior distribution parameters The parameters are set by an authoritative institution and stored on the blockchain as public belief parameters of the system, which are then used by smart contracts. S213. The game strategy of buyer node B and seller node S is to submit their publicly disclosed trading parameters to the roadside unit (RSU): the buyer submits its energy demand range. and acceptable unit price range The seller submits its available energy quantity. and acceptable unit price range . S22. Define the strategy space, market clearing, and expected utility function: S221. The smart contract is based on a game theory model, assuming that both buyers and sellers will follow a linear pricing strategy in equilibrium, and constructs its internal derivation logic accordingly. The linear strategy space is defined as: Buyer's linear quote function: Seller's linear quotation function: in, For trading volume, The policy parameters to be determined are specifically as follows: The highest unit price the buyer is willing to pay. This refers to the diminishing marginal rate of return, which is the rate at which the buyer's bid decreases as trading volume increases. The lowest unit price the seller is willing to accept. This refers to the marginal rate of increase in asking price, which is the rate at which the seller's asking price rises as transaction volume increases. The transmission loss factor is... This refers to the publicly visible distance between the two parties. , All are greater than 0. S222. The market clearing condition is that the bids from both buyers and sellers are equal, i.e. Therefore, the equilibrium trading volume can be determined. Functions used as policy parameters: . S223. Based on the Bayesian property of incomplete information games, a participant's objective is defined as maximizing their expected utility. This expectation is the expectation of the private type probability distributions of other participants: Buyer B's expected utility: ,in Follow the interval Uniform distribution on; Seller S's expected utility: ,in Follow the interval A uniform distribution on the surface. S23. Solve for the Bayesian Nash equilibrium policy parameters: The pre-defined solution logic within the smart contract solves for the strategy that maximizes the expected utility by setting the first-order partial derivatives of the aforementioned expected utility function with respect to their respective policy parameters to zero, i.e., solving for the equilibrium. S231. First-order condition for maximizing the buyer's expected utility: Market clearing conditions and substitute the buyer's quotation function and utilize public beliefs The relationship between the buyer's equilibrium strategy parameters and their private type, public information, and public beliefs can be derived: S232. First-order condition for maximizing the seller's expected utility: Similarly, by substituting market clearing conditions and seller quotation functions, and utilizing public beliefs... The relationship between the seller's equilibrium strategy parameters and their private type, public information, and public beliefs can be derived: in, . S24. Derive the equilibrium trading solution and pre-set it as an executable function: S241. The equilibrium strategy parameters obtained in S23 Substitute into the market clearing formula , obtained in private type Bayesian Nash equilibrium transaction volume represented by public parameters and public beliefs With equilibrium price . S242. To transform the theoretical equilibrium into an executable function for a smart contract, a relationship needs to be established between the private type and the public price range. Based on the linear equilibrium structure, the private type can be set to correspond to the midpoint of the public price range, i.e.: The specific expressions of the above relationships and public beliefs Substituting the equilibrium solution, we can finally derive the explicit equilibrium solution function, which is entirely represented by the publicly submitted parameters and the system's common belief parameters. and Its specific form is pre-defined in the smart contract: make: but: The final formula for calculating equilibrium trading volume and price is: S25. Balance matching is triggered by RSU and performed. After collecting and verifying the transaction requests and responses from both the buyer and seller, the Roadside Unit (RSU) will store the publicly available parameters submitted by both parties, including... and system common belief parameters Send to the smart contract to trigger execution. After receiving the parameters, the smart contract calls its internally pre-built explicit equilibrium solution function. and The calculation is performed to obtain the matching results. The smart contract verifies whether the computation result meets the publicly submitted constraints by both parties: , and If the verification passes, a final matching success command will be generated. If any of the above conditions are not met, the smart contract determines that the matching has failed and returns a failure instruction to the roadside unit node. If all conditions are met, the smart contract generates a final successful matching instruction.

3. The vehicle-to-everything (V2X) energy security trading method as described in claim 1, characterized in that, The blockchain system employs an adaptive hierarchical hybrid consensus mechanism based on energy trading load awareness, which includes the following steps: S31. Calculation of Energy Trading Load Intensity: Before the start of each new block generation cycle, within a preset statistical time window... Internal statistics show the number of energy transaction requests that have passed the validity verification. And calculate the energy trading load intensity according to the following formula. : in, For energy trading load intensity, For statistical time windows The number of effective energy transactions within the country, Set the maximum transaction processing capacity for the system. S32. Consensus Mode Determination: The system pre-sets a load determination threshold. The Preset parameters for the system or threshold parameters that are adaptively updated based on historical transaction status; When the following conditions are met: When the system enters a low-load consensus mode, Proof-of-Stake (PoA) consensus is used. When the system enters a high-load consensus mode, the improved PBFT consensus is used. S33. Calculation of Node Consensus Weight: After determining the current consensus mode, calculate the comprehensive consensus weight for the i-th roadside unit node participating in the consensus. : in, As the overall consensus weight of the nodes, Contributing indicators to node energy trading As an indicator of node operational stability, For node reputation metrics, Metrics for node resource load adaptability. The weighting coefficients are satisfied. . S331. Energy Trading Contribution Indicators calculate: in, For energy trading statistics time window, The number of energy transactions completed by the node within the window. For the k-th energy transaction completed by node, For the current time, The moment the transaction occurs. This is the time decay factor. S332. Operational stability indicators calculate: in, This represents the number of consensus rounds successfully completed by the node. The number of consensus rounds in which the node participates. This represents the percentage of nodes that are online. S333. Node Reputation Metrics calculate: in, The number of times a node violates regulations or exhibits abnormal behavior. Set the maximum number of anomalies that the system can tolerate. S334. Resource load adaptability indicators calculate: in, This represents the current overall resource utilization ratio of the node. Set the maximum resource capacity for the system. S34. Dynamic adjustment mechanism for weighting coefficients: The system presets the initial values ​​of the weighting coefficients as follows: According to energy trading load intensity Dynamic updates: in To adjust the parameters and perform normalization on the updated weight coefficients: S35. Leader Node Election Mechanism: Based on the comprehensive consensus weight The node with the highest weight value is selected as the leader node. If the leader node is not generated at the preset block generation time... If the block proposal is completed within the specified time, then: in, The preset decay factor is then used to re-execute the node election process. S36. When the system is in low-load consensus mode, a proof-of-stake consensus process is adopted, including: S361. The leader node generates a new block; S362. Authorized nodes perform legality verification on the new block; S363. The new block is submitted to the blockchain ledger after receiving a simple majority confirmation from at least the total number of authorized nodes; S364. If confirmation is not received within a preset time, a new leader election is performed. S37. Execution flow of high-load consensus mode: When the system is in high-load consensus mode, an improved practical Byzantine fault-tolerant consensus process is adopted, including: S371. Consensus Sub-region Division The roadside unit nodes are divided into multiple consensus sub-regions according to the physical deployment topology. S372. Confirmation of Consistency within the Region S3721. The leader node broadcasts a new block proposal to its region; S3722. Nodes within the region perform block verification; S3723. Nodes within the region broadcast confirmation messages; S3724. When the number of confirmation messages reaches at least two-thirds of the total number of nodes in the region, consensus is considered reached within the region. S373. Inter-regional consistency confirmation S3731. Each region elects a regional representative node; S3732. The regional representative node broadcasts the regional consensus result; S3733. The regional representative node verifies and confirms the result; S3734. When the confirmation result reaches no less than two-thirds of the total number of regional representative nodes, the entire network is considered to have reached a consensus. S374. Block Commit After the entire network reaches a consensus, each node writes the new block into the blockchain ledger. S38. Features of the Improved Byzantine Fault-Tolerant Consensus Structure The improved practical Byzantine fault-tolerant consensus reduces inter-node communication overhead through a regional hierarchical structure.

4. The method as described in claim 1, characterized in that, The method also includes an identity anonymization mechanism based on ring signatures, specifically: S41. Ring Key Generation: Assume the system... There are 10 potential signature vehicle nodes, each node Have a public-private key pair ,in For public ring keys, For the node's private key; All ring public keys constitute a public key set. ; S42. Ring Signature Generation: When the vehicle node... That is, the actual signer wants to modify the message in step S2 or S4. When signing a transaction request or response message, the following steps are performed: S421. Select a random number ; S422. Calculate the initial commitment value of a ring signature. ,in For cryptographic hash functions, It is the base point of the elliptic curve; S423. For all other nodes in the ring. Select random numbers in sequence And calculate ; S424. For the actual signatory ,choose Make the equation closed Establishment requires ,in The order of the elliptic curve; S425. The generated ring signature is With the news Send together; S43. Ring Signature Verification: The roadside unit node receives a message with a ring signature. Then, verify using the following steps: S431. Using a public key set and signature Recalculate S432. Iterative calculation ; S433. Verify the final calculation Is it equal to the signature? ; If they are equal, the verification passes, confirming the message originated from the ring. The member is a legitimate member, but the specific signature node cannot be determined. .

5. The method as described in claim 1 or 4, characterized in that, The method also includes a transaction qualification verification mechanism based on zero-knowledge proofs, specifically: S51. Establishment of a zero-knowledge proof system: Define the statement to be proved as the prover possessing a valid digital certificate. The corresponding key is And its account energy balance satisfy , The required trading volume, and its declared trading parameters. For example, the price range and quantity range satisfy the internal consistency constraint. . S52. Zero-knowledge proof generation: The vehicle node, acting as the prover, constructs a zero-knowledge proof before sending a transaction request or response. This proves that he knew a set of secret witnesses. Meeting the requirements of public statements : in, From and Derived public key, These are private parameters, such as the lower limit of the truly acceptable price. To publicly declare parameters, For certificate verification algorithms, This is the constraint verification function. S53. Zero-knowledge proof verification: The roadside unit node acts as the verifier and receives the proof. and publicly available parameters Then, run the verification algorithm. If the output is true, it confirms that the proving party is legally qualified and the claim is valid, but no information regarding... Precision value and Specific information.

6. The method as described in claim 1, characterized in that, The method also includes an information security and verification mechanism, specifically: S61. In step S2, the vehicle node uses its own private key to digitally sign the transaction request information to ensure the integrity and non-repudiation of the information; S62. In step S3, the roadside unit node uses the public key in the requesting vehicle certificate to verify its signature and the validity of its digital certificate to confirm the legitimate identity of the requesting node.

7. The method as described in claim 1, characterized in that, The method also includes a transaction constraint and filtering mechanism, specifically: S71. In step S3, the broadcast information includes a "demand waiting time limit", and the roadside unit node in step S4 only processes the response information received within the "demand waiting time limit", and the response information that has expired will be discarded; S72. In the matching process of step S4, the smart contract prioritizes matching the buyer and seller nodes that are geographically close.

8. The method as described in claim 1, characterized in that, The smart contract also includes transaction security and default handling mechanisms. Specifically, in step S5, the updates to the account balance and energy balance are automatically executed by the smart contract. If one party defaults, the smart contract automatically transfers the deposit paid by the defaulting party to the account of the non-defaulting party.

Images