Data sharing method based on block chain double-chain architecture

Abstract

The invention discloses a data sharing method based on a block chain double-chain architecture, and the method comprises the steps: building a double-chain block chain network architecture containing an emergency transaction chain and a common transaction chain based on a vehicle OBU and a road side unit RSU, and dividing a corresponding account book; the vehicle collects Internet of Vehicles service data through the OBU and distributes the data to corresponding transaction pools according to types; calculating an emergency degree index for each transaction entering the emergency transaction chain; calculating a global reputation value of the node by adopting a multi-source multi-right subjective logic reputation model; a high-reputation consensus committee is established, emergency data optimization PBFT consensus is executed, common data standard PBFT consensus is synchronously executed by legal nodes, and data classification efficient sharing is achieved through parallel collaboration of an emergency transaction chain and a common transaction chain. According to the data sharing method based on the block chain double-chain architecture, the problems of high emergency data transmission delay and lack of effective prevention of malicious interference of internal nodes in an existing Internet of Vehicles data sharing technology are solved.

Description

Technical Field

[0001] This invention belongs to the field of vehicle networking and blockchain data sharing technology, specifically involving a data sharing method based on a blockchain dual-chain architecture. Background Technology

[0002] In the Internet of Vehicles (IoV), vehicles generate massive amounts of driving and traffic status data in real time. Sharing this data helps improve traffic efficiency and driving safety. However, traditional centralized IoV data management models suffer from problems such as data tampering, user privacy leaks, and a lack of trust. Blockchain technology, as a decentralized, tamper-proof, and traceable distributed ledger, offers a new solution for IoV data sharing. However, due to the massive amount of data and the highly dynamic nature of nodes in IoV, recording all data indiscriminately on a single blockchain could lead to excessive on-chain storage and consensus loads, making it difficult to meet the low-latency processing requirements of urgent data.

[0003] In existing technologies, some research attempts to improve the efficiency and reliability of vehicle-to-everything (V2X) data sharing by refining blockchain consensus algorithms. For example, some solutions employ PBFT-based committee consensus to reduce the number of participating nodes, thereby reducing communication complexity and increasing confirmation speed; others introduce reputation evaluation mechanisms to remove nodes with malicious behavior from the consensus process, enhancing the system's ability to resist internal attacks. However, existing solutions still have shortcomings: First, when faced with emergency data such as traffic accident alerts, existing blockchain consensus mechanisms struggle to prioritize and process it promptly, as emergency information may be overwhelmed by the processing of large amounts of ordinary information, resulting in excessive latency; second, traditional solutions lack fine-grained and effective constraints on malicious nodes within the V2X network, allowing attackers to disrupt normal system operation by frequently broadcasting false emergency messages or impersonating others to participate in consensus. To address these shortcomings, a new method for V2X data sharing is urgently needed that can ensure the rapid and reliable uploading of emergency data to the blockchain while preventing abuse by malicious nodes. Summary of the Invention

[0004] The purpose of this invention is to provide a data sharing method based on a blockchain dual-chain architecture, which solves the problems of high latency in emergency data transmission and lack of effective prevention against malicious interference from internal nodes in existing vehicle network data sharing technologies.

[0005] The technical solution adopted in this invention is a data sharing method based on a blockchain dual-chain architecture, comprising the following steps:

[0006] Step 1: Based on the vehicle onboard unit (OBU) and roadside unit (RSU), build a dual-chain blockchain network architecture including an emergency transaction chain and a normal transaction chain, and divide the corresponding ledgers; Step 2: Vehicles collect vehicle-to-everything (V2X) service data via OBU and distribute it to the corresponding transaction pool according to type; Step 3: Calculate the urgency index for each transaction entering the emergency transaction chain; Step 4: Calculate the global reputation value of the node using a multi-source, multi-weight subjective logical reputation model; Step 5: Establish a high-reputation consensus committee and execute the emergency data optimization PBFT consensus, while legitimate nodes execute the ordinary data standard PBFT consensus simultaneously. Through the parallel collaboration of the emergency transaction chain and the ordinary transaction chain, efficient data classification and sharing are achieved.

[0007] The invention is further characterized by: The urgency index in step 3 is calculated using the following formula: (1) In the formula, This indicates an urgency index, measuring the ultimate urgency of a transaction; This indicates the cumulative number of emergency transaction requests made by the vehicle during this consensus period. Indicates the impact weight of the number of emergency transactions that have been requested; The vehicle's expected urgency for the transaction is calculated using formula (2) and reflects its sensitivity to transaction delays. (2) In the formula, This indicates the average latency for the emergency transaction chain to confirm a block; This indicates the expected latency of a transaction, which is the maximum tolerable latency for the transaction to reach consensus. It is preset by the transaction type. This indicates the time when the transaction occurred, specifically the timestamp when the vehicle generated the transaction. The timestamp indicates the time from which a transaction is sent from the vehicle to the time it is received by the roadside unit, reflecting the transaction transmission delay.

[0008] Step 4 specifically includes the following steps: Step 4.1: Set different priority coefficients for different transaction types and calculate basic parameters including familiarity, timeliness of direct opinions, and trajectory similarity to provide input for credit assessment; Step 4.2: Generate and combine direct opinions based on direct interaction behavior between nodes; Step 4.3: Based on the indirect interaction paths between nodes, deduce and combine indirect opinions; Step 4.4: Integrate direct and indirect opinions to output a global reputation value.

[0009] Step 4.1 specifically includes: First, different priority coefficients are assigned to different transaction types for weighted processing in subsequent reputation score calculations, calculated according to the following formula: (3) In the formula, Indicates different transaction types, Indicates an emergency transaction. Indicates a non-urgent transaction. This indicates the priority coefficient related to the transaction type; Secondly, familiarity, timeliness of direct opinions, and trajectory similarity are calculated separately, as follows: Familiarity is recorded as It can be calculated using the following formula (4): (4) In the formula, This indicates that within the set time window, the vehicle and vehicles The total number of actual interactions between vehicles As data users, vehicles As a data provider; Indicates vehicle Average number of interactions with other vehicle nodes; Indicates with vehicles The set of all vehicles that interact with each other; Represents a set Number of vehicles in China; The timeliness of direct opinions is recorded as It can be calculated using the following formula (5): (5) In the formula, Representative vehicle Time to complete the transaction; Representative vehicle The time point at which the data to be evaluated was uploaded. Indicates the timeliness amplification factor; Indicates the decay index; and These are the timeliness amplification factor and attenuation index for emergency data. and These are the timeliness amplification factor and attenuation index for ordinary data, satisfying... , ; Trajectory similarity is denoted as It can be calculated using the following formula (6): (6) In the formula, Weights representing the similarity between velocity and direction; Indicates speed similarity; The directional similarity is expressed and calculated using the following formula (7): (7) In the formula, This indicates the number of trajectory points participating in the comparison. , Representing vehicles and vehicles The feature value at the k-th trajectory point.

[0010] Step 4.2 specifically involves: First, the factors of familiarity, timeliness of direct opinions, and trajectory similarity are weighted and summed, combined with the proportion of urgent interactions. And emergency transaction weighting coefficient, to obtain the vehicle and vehicles Direct opinion weight , means as follows: (8) (9) In the formula, , , Indicates familiarity Timeliness of direct opinions Similarity to trajectory The corresponding weights satisfy ; The weight of direct opinions indicating whether something is urgent or not. Indicates vehicle and vehicles The percentage of emergency interactions between them This represents the weighting factor for emergency transactions. This indicates the weighted parameter for the proportion of emergency situations; Secondly, the validity of outlier data is calculated by combining the growth curve function of the Pearl model. Normal data validity is represented as Calculate according to the following formula: (10) In the formula, This indicates a adjustment factor, which differs between urgent and non-urgent data. X Indicates following the vehicle j The collection of all vehicles that have interacted. Represents any vehicle in the set For vehicles The direct weights; Indicates vehicle x In and vehicles j The number of anomalous data observed during interactions; This represents the weighted average of the outlier data; Using the number of normal data points and the number of abnormal data points as inputs, and combining the positive / negative evidence amplification factor, the validity weighting of normal and abnormal data is completed, as shown below: (11) In the formula, Indicates vehicle and vehicles The number of times normal data occurs between them. These represent the number of emergency and non-emergency data points between vehicles, respectively. Indicates vehicle and vehicles The number of times abnormal data occurred between them. Similarly; This represents the positive evidence amplification factor, usually applicable in emergency situations. , This represents the negative evidence amplification factor, usually used in emergency situations. ; Subsequently, based on the evidence mapping operator in the subjective logic SL trust model, the vehicle is calculated using the following formula (12). i For vehicles j Direct opinion: (12) In the formula, Indicates vehicle i For vehicles j Trust level; Indicates vehicle i For vehicles j Distrust level; Indicates vehicle i For vehicles j Uncertainty; Strengthen the decisiveness of emergency transaction recommendations; This indicates the percentage of urgent evidence counted within the window. Finally, for all vehicles within the period j The collection of all vehicles that have interacted X The opinions are weighted and integrated to obtain the direct opinion combination, as shown below: (13) In the formula, , , This indicates that the system comprehensively considers the vehicle j The level of trust, distrust, and uncertainty of direct opinions.

[0011] Step 4.3 specifically involves: First, a depth-first search algorithm is used to find all indirect paths from source node A to target node C in the vehicle interaction graph; then, the indirect opinion of a single indirect path is calculated using the discount operator based on the subjective logic SL trust model, as shown below: (14) In the formula, B represents an intermediate node, which is obtained by the depth-first search algorithm; , , This represents the degree of trust, distrust, and uncertainty of node A's direct opinion on intermediate node B. , , This represents the degree of trust, distrust, and uncertainty of intermediate node B's direct opinion on node C. , , This represents the degree of trust, distrust, and uncertainty of the indirect opinions of node A and intermediate node B regarding node C. Secondly, for paths with urgent transactions, their weight is increased based on the path priority coefficient, as shown below: (15) (16) In the formula, Let represent the path priority coefficient, and m represent the intermediate nodes that satisfy the sequence relation. This represents the weighting factor for emergency data. Indicates whether there are any urgent transactions along the path; The path weights are calculated as follows: (17) In the formula, This indicates that when node A evaluates target node C through intermediate node m, the weight of this indirect path decreases as the number of path passes increases. This represents the set of vehicle nodes that satisfy the sequence relationship obtained by the indirect opinion path search algorithm. Represents a node m The direct opinion weights to node C.

[0012] Finally, the weighted average method is used to integrate the indirect opinions from multiple indirect paths, resulting in the system's combined indirect opinions on the target node C, as shown below: (18) In the formula, , , These represent the system's overall trust, distrust, and uncertainty regarding the indirect opinions of the target vehicle node C, respectively.

[0013] Step 4.4 specifically involves: First, by combining direct and indirect opinions, the final system opinion is obtained, as follows: (19) In the formula, Indicates the final level of trust. Indicates the final level of distrust. ， Indicates the final uncertainty; K Represents the normalization coefficient; The global reputation score is calculated based on the final trust level and final distrust level after fusion. , means as follows: (20) In the formula, The factor representing the uncertainty.

[0014] Step 5 involves establishing a high-reputation consensus committee, specifically as follows: Sort all nodes in descending order of global reputation value, select the top p nodes to form a high-reputation consensus committee, and replace all nodes in the optimization of PBFT consensus; Step 5 involves performing emergency data optimization PBFT consensus, which specifically includes the following sub-steps: Step 5.2.1, Master Node Election and Block Packaging: The node with the highest reputation value in the high-reputation consensus committee serves as the master node. The master node selects the emergency block with the highest urgency based on the urgency index ranking of the emergency transaction blocks after packaging, and broadcasts the block to other validator nodes in the high-reputation consensus committee. Step 5.2.2, Local Node Verification and Voting Feedback: After receiving the candidate emergency block, each verification node performs local verification on the block structure integrity and transaction legality. After the verification is passed, it sends the voting information of signature agreement to the master node. Step 5.2.3, Consensus Result Determination: When the master node receives no less than f+1 identical votes of agreement, where f is the Byzantine fault tolerance parameter and f < p / 3, the consensus is determined to be successful, and the block is recorded in the emergency data blockchain ledger; if not enough votes of agreement are collected within the preset time window, the current consensus is terminated, and a new consensus is initiated. Step 5.2.4, Broadcasting and Uploading Consensus Results: The master node broadcasts the successful consensus result to the entire network, completing the emergency data uploading process.

[0015] The high-reputation consensus committee will be dynamically optimized as follows: Master node round limit: The number of consecutive rounds in which the same node serves as master node shall not exceed a preset value of H. After completing the duties of master node in one round, it shall no longer serve as master node in the subsequent H rounds of emergency consensus. Committee member update: After processing T emergency blocks, the committee is reassessed based on the latest global reputation value of the nodes, and new nodes with high reputation are selected to replace members whose global reputation value has decreased, so as to maintain the reliability of the high-reputation consensus committee.

[0016] In step 5, the legitimate nodes execute the PBFT consensus standard for ordinary data, specifically as follows: Nodes whose global reputation value reaches a basic threshold are selected as legitimate nodes and participate in the general data consensus. All legitimate nodes participate in the standard PBFT consensus, verifying, voting on, and recording general data transactions according to the regular block size and block generation speed. After reaching a network-wide consensus, the general data blocks are recorded in the general data blockchain ledger to ensure the consistency and reliability of general data sharing.

[0017] The beneficial effects of this invention are: This invention presents a data sharing method based on a dual-chain blockchain architecture. Compared to existing technologies, this dual-chain architecture enables the categorized processing of vehicle network data. Emergency data receives priority and rapid consensus in a dedicated emergency chain, significantly reducing on-chain latency. Regular data is processed in parallel on the regular chain, preventing a large number of routine transactions from crowding out emergency service bandwidth, thus ensuring real-time and reliable sharing of emergency information. The reputation-driven consensus mechanism introduced in this invention effectively filters out untrusted nodes, ensuring that only high-reputation nodes execute emergency data consensus. This significantly reduces consensus communication overhead and improves the credibility of consensus results, enhancing the system's resistance to and punishment of malicious internal nodes, achieving higher security and reliability. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the overall system architecture of the data sharing method based on a dual-chain blockchain architecture of the present invention; Figure 2 This is a flowchart of the emergency data consensus process in the data sharing method based on a blockchain dual-chain architecture of the present invention; Figure 3 This is a comparison chart of reputation value changes in Embodiment 7 of the present invention; Figure 4(a) is a comparison of block confirmation latency in Embodiment 7 of the present invention when the number of transactions is 500; Figure 4(b) is a comparison chart of block confirmation latency in Embodiment 7 of the present invention when the number of transactions is 1000; Figure 4(c) is a comparison chart of block confirmation latency in Embodiment 7 of the present invention when the number of transactions is 1500; Figure 4(d) is a comparison chart of block confirmation latency in Embodiment 7 of the present invention when the number of transactions is 2000; Figure 5(a) is a comparison chart of throughput in Embodiment 7 of the present invention when the number of transactions is 500; Figure 5(b) is a comparison chart of throughput in Embodiment 7 of the present invention when the number of transactions is 1000; Figure 5(c) is a comparison chart of throughput in Embodiment 7 of the present invention when the number of transactions is 1500; Figure 5(d) is a comparison chart of throughput in Embodiment 7 of the present invention when the number of transactions is 2000. Detailed Implementation

[0019] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0020] Example 1 This embodiment provides a data sharing method based on a blockchain dual-chain architecture, such as... Figure 1 As shown, it includes the following steps: Step 1: Based on the vehicle's On-Board Unit (OBU) and Roadside Unit (RSU), establish a dual-chain blockchain network architecture including an emergency transaction chain and a regular transaction chain, and divide the corresponding ledgers. The emergency transaction chain is used to process emergency data, and the regular transaction chain is used to process routine data.

[0021] Step 2: Vehicles collect vehicle-to-everything (V2X) service data via the OBU and distribute it to the corresponding transaction pool according to type. Emergency data is generated when a vehicle experiences an emergency, such as a collision or accident warning, while regular information such as the vehicle's status and location is generated as normal data according to a preset cycle. Emergency data is broadcast to the emergency transaction chain, while normal data is sent to the normal transaction chain, thus achieving data separation at the source.

[0022] Step 3: Calculate the urgency index for each transaction entering the emergency transaction chain. The urgency index is used to quantitatively assess the urgency of the transaction. The higher the value, the higher the priority the transaction needs to be processed, ensuring that truly urgent transactions are prioritized for consensus packaging in the emergency transaction chain.

[0023] Step 4: A multi-source, multi-weighted subjective logical reputation model is used to calculate the global reputation value of each node, which is then used to assess trust in the nodes within the vehicle-to-everything (V2X) network. This reliable reputation evaluation mechanism ensures the reliability of the consensus-participating nodes and provides a basis for the subsequent reputation-based consensus process.

[0024] Step 5: Establish a high-reputation consensus committee and execute the emergency data optimized PBFT (Practical Byzantine Fault Tolerance) consensus. The high-reputation consensus committee uses an optimized Practical Byzantine Fault Tolerance algorithm to verify and confirm emergency transactions. By reducing the number of nodes participating in the consensus and optimizing the consensus process, fast block generation is achieved. Simultaneously, legitimate nodes execute the standard PBFT consensus for ordinary data. Through the parallel collaboration between the emergency transaction chain and the ordinary transaction chain, efficient data classification and sharing are achieved.

[0025] Example 2 In step 3, to ensure that emergency chain resources prioritize truly urgent transactions while preventing malicious nodes from abusing emergency channels to seize consensus and bandwidth, this invention constructs an urgency index for quantitative evaluation and priority ranking of urgent transactions. The specific calculation is as follows: (1) In the formula, This represents the urgency index, which measures the final urgency of a transaction and is used to determine the priority of a transaction in the emergency transaction chain. The higher the value, the higher the priority for being packaged and consensus-reached. This indicates the cumulative number of emergency transaction requests made by the vehicle during this consensus period. Indicates the impact weight of the number of emergency transactions that have been requested; The vehicle's expected urgency for the transaction is calculated using formula (2) and reflects its sensitivity to transaction delays. (2) In the formula, This indicates the average latency for the emergency transaction chain to confirm a block; This indicates the expected latency of a transaction, which is the maximum tolerable latency for the transaction to reach consensus. It is preset by the transaction type. This indicates the time when the transaction occurred, specifically the timestamp when the vehicle generated the transaction. The timestamp indicates the time from which a transaction is sent from the vehicle to the time it is received by the roadside unit, reflecting the transaction transmission delay.

[0026] Example 3 Step 4: Calculate the global reputation value of nodes using a multi-source, multi-weight subjective logical reputation model, which is used to assess trust in nodes within the vehicle-to-everything (V2X) network. This includes the following sub-steps: Step 4.1: Set different priority coefficients for different transaction types and calculate basic parameters including familiarity, timeliness of direct opinions, and trajectory similarity to provide input for credit assessment. Specifically: First, different priority coefficients are assigned to different transaction types for weighted processing in subsequent reputation score calculations, calculated according to the following formula: (3) In the formula, Indicates different transaction types, Indicates an emergency transaction. Indicates a non-urgent transaction. This indicates the priority coefficient related to the transaction type; Secondly, familiarity, timeliness of direct opinions, and trajectory similarity are calculated separately, as follows: Familiarity is recorded as This is an indicator of the familiarity between vehicles. The higher the familiarity, the higher the interaction frequency, the more prior information, and the more reliable the feedback. It is calculated using the following formula (4), which measures the ratio of the total number of interactions between vehicles / points to the average number of interactions between other vehicle nodes within a certain period: (4) In the formula, This indicates that within the set time window, the vehicle and vehicles The total number of actual interactions that occurred between them. (Vehicles) As data users, we are the vehicle nodes that provide evaluations based on this data. As the data provider, this is the vehicle node whose reputation will be evaluated in this assessment. Indicates vehicle Average number of interactions with other vehicle nodes; Indicates with vehicles The set of all vehicles that interact with each other; Represents a set The number of vehicles, i.e., the number of vehicles j The total number of vehicles interacting.

[0027] The timeliness of direct opinions is recorded as Newer data has higher weight. It is calculated using the following formula (5): (5) In the formula, Representative vehicle Time to complete the transaction; Representative vehicle The time point at which the data to be evaluated was uploaded. Indicates the timeliness amplification factor; Indicates the decay index; and These are the timeliness amplification factor and attenuation index for emergency data. and These are the timeliness amplification factor and attenuation index for ordinary data, satisfying... , This indicates that newer emergencies have greater impact.

[0028] Trajectory similarity is denoted as , representing vehicles i With vehicles j The overall trajectory similarity in this data sharing is obtained by aggregating the velocity and direction cosine similarity. Specifically, it is calculated using the following formula (6): (6) In the formula, Weights representing the similarity between velocity and direction; Indicates speed similarity; The directional similarity is expressed and calculated using the following formula (7): (7) In the formula, This indicates the number of trajectory points participating in the comparison. , Representing vehicles and vehicles The feature value at the k-th trajectory point.

[0029] Step 4.2: Generate and combine direct opinions based on direct interactions between nodes. Specifically: First, the factors of familiarity, timeliness of direct opinions, and trajectory similarity are weighted and summed, combined with the proportion of urgent interactions. And emergency transaction weighting coefficient, to obtain the vehicle and vehicles Direct opinion weight , means as follows: (8) (9) In the formula, , , Indicates familiarity Timeliness of direct opinions Similarity to trajectory The corresponding weights satisfy ; The weight of direct opinions indicating whether something is urgent or not. Indicates vehicle and vehicles The percentage of emergency interactions between them This represents the weighting factor for emergency transactions. This indicates the weighted parameter for the proportion of emergency situations; Secondly, the validity of outlier data is calculated by combining the growth curve function of the Pearl model. Normal data validity is represented as Calculate according to the following formula: (10) In the formula, This indicates a adjustment factor; urgent and non-urgent data differ, and it determines... The upper limit of the possible values; X Indicates following the vehicle j The collection of all vehicles that have interacted. Represents any vehicle in the set For vehicles The direct weights; Indicates vehicle x In and vehicles j The number of anomalous data observed during interactions; This represents the weighted average of outlier data, such as data errors, malicious data, or invalid data. Using the number of normal data points and the number of abnormal data points as inputs, and combining the positive / negative evidence amplification factor, the validity weighting of normal and abnormal data is completed, as shown below: (11) In the formula, Indicates vehicle and vehicles The number of times normal data occurs between them. These represent the number of emergency and non-emergency data points between vehicles, respectively. Indicates vehicle and vehicles The number of times abnormal data occurred between them. Similarly; This indicates the positive evidence amplification factor, usually applicable in emergency situations. , This represents the negative evidence amplification factor, usually used in emergency situations. ; Subsequently, based on the evidence mapping operator in the Subjective Logic (SL) trust model, the vehicle is calculated using the following formula (12). i For vehicles j Direct opinion: (12) In the formula, Indicates vehicle i For vehicles j Trust level; Indicates vehicle i For vehicles j Distrust level; Indicates vehicle i For vehicles j Uncertainty; Strengthening the decisiveness of emergency transaction opinions makes it easier to concentrate trust; This indicates the percentage of urgent evidence counted within the window. Finally, for all vehicles within the period j The collection of all vehicles that have interacted X The opinions are weighted and integrated to obtain the direct opinion combination, as shown below: (13) In the formula, , , This indicates that the system comprehensively considers the vehicle j The level of trust, distrust, and uncertainty of direct opinions.

[0030] Step 4.3: Based on the indirect interaction paths between nodes, deduce and combine indirect opinions.

[0031] By combining key parameters such as the correlation strength and transmission frequency of different indirect paths, the opinions on each path are weighted and integrated to ultimately obtain a comprehensive and objective combined indirect opinion. This process combines direct interaction information with indirect opinion analysis, providing more robust data support for decision optimization in vehicle interaction systems. Specifically: First, a depth-first search (DFS) algorithm is used to find all indirect paths from source node A to target node C (i.e., the vehicle node whose reputation is ultimately evaluated) in the vehicle interaction graph. Then, the indirect opinion for each indirect path is calculated using the discount operator based on the Subjective Logic (SL) trust model, as shown below: (14) In the formula, B represents an intermediate node, which is obtained by the depth-first search algorithm DFS; , , This represents the degree of trust, distrust, and uncertainty of node A's direct opinion on intermediate node B. , , This represents the degree of trust, distrust, and uncertainty of intermediate node B's direct opinion on node C. , , This represents the degree of trust, distrust, and uncertainty of the indirect opinions of node A and intermediate node B regarding node C. Secondly, for paths with urgent transactions, their weight is increased based on the path priority coefficient, as shown below: (15) (16) In the formula, Let represent the path priority coefficient, and m represent the intermediate nodes that satisfy the sequence relation. This represents the weighting factor for emergency data. Indicates whether there are any urgent transactions along the path; The path weights are calculated as follows: (17) In the formula, This indicates that when node A evaluates target node C through intermediate node m, the weight of this indirect path decreases as the number of path passes increases. This represents the set of vehicle nodes that satisfy the sequence relationship obtained by the indirect opinion path search algorithm. Represents a node m The direct opinion weights to node C.

[0032] Finally, the weighted average method is used to integrate the indirect opinions from multiple indirect paths, resulting in the system's combined indirect opinions on the target node C, as shown below: (18) In the formula, , , These represent the system's overall trust, distrust, and uncertainty regarding the indirect opinions of the target vehicle node C, respectively.

[0033] Step 4.4: Integrate direct and indirect opinions to output a global reputation score. Specifically: First, by combining direct and indirect opinions, the final system opinion is obtained, as follows: (19) In the formula, Indicates the final level of trust. Indicates the final level of distrust. ， Indicates the final uncertainty; K Represents the normalization coefficient; The global reputation score is calculated based on the final trust level and final distrust level after fusion. , means as follows: (20) In the formula, The factor representing the uncertainty.

[0034] Example 4 In step 5, a high-reputation consensus committee is established and emergency data optimization PBFT consensus is implemented, such as... Figure 2 As shown, specifically: Sort all nodes in descending order of global reputation value, select the top p nodes to form a high-reputation consensus committee, and replace all nodes in the optimization of PBFT consensus; Performing emergency data optimization PBFT consensus includes the following sub-steps: Step 5.2.1, Master Node Election and Block Packaging: The node with the highest reputation value in the high-reputation consensus committee serves as the master node. The master node selects the emergency block with the highest urgency based on the urgency index ranking of the emergency transaction blocks after packaging, and broadcasts the block to other validator nodes in the high-reputation consensus committee. Step 5.2.2, Local Node Verification and Voting Feedback: After receiving the candidate emergency block, each verification node performs local verification on the block structure integrity and transaction legality. After the verification is passed, it sends the voting information of signature agreement to the master node. Step 5.2.3, Consensus Result Determination: When the master node receives no less than f+1 identical votes of agreement, where f is the Byzantine fault tolerance parameter and f < p / 3, the consensus is determined to be successful, and the block is recorded in the emergency data blockchain ledger; if not enough votes of agreement are collected within the preset time window, the current consensus is terminated, and a new consensus is initiated. Step 5.2.4, Broadcasting and Uploading Consensus Results: The master node broadcasts the successful consensus result to the entire network, completing the emergency data uploading process.

[0035] To prevent a single high-reputation node from dominating the consensus for an extended period, this invention dynamically optimizes the high-reputation consensus committee, specifically including: Master node round limit: The number of consecutive rounds in which the same node serves as master node shall not exceed a preset value of H. After completing the duties of master node in one round, it shall no longer serve as master node in the subsequent H rounds of emergency consensus, in order to avoid "consensus monopoly".

[0036] Committee member update: After processing T emergency blocks, the committee is reassessed based on the latest global reputation value of the nodes, and new nodes with high reputation are selected to replace members whose global reputation value has decreased, so as to maintain the reliability of the high-reputation consensus committee.

[0037] Example 5 In step 5, the standard PBFT consensus for ordinary data is executed synchronously by legitimate nodes. Specifically, nodes with a global reputation value reaching the basic threshold are selected as legitimate nodes to participate in the ordinary data consensus (i.e., most nodes in the entire network can participate in the accounting consensus for ordinary data). All legitimate nodes participate in the standard PBFT consensus, verifying, voting on, and recording ordinary data transactions according to the regular block size and block production speed. After reaching a network-wide consensus, the ordinary data blocks are recorded in the ordinary data blockchain ledger to ensure the consistency and reliability of ordinary data sharing.

[0038] The emergency transaction chain and the regular transaction chain work together: the emergency transaction chain prioritizes processing a small amount of data on sudden emergency events, while the regular transaction chain continuously records large-scale routine data. Each chain adopts different optimization strategies to build a dual-chain data sharing system that balances real-time performance with throughput and security.

[0039] Example 6 Based on the data sharing method using a dual-chain blockchain architecture as described in the above embodiments, and combining the vehicle on-board unit (OBU) and roadside unit (RSU), a dual-chain blockchain network architecture containing an emergency transaction chain and a regular transaction chain is constructed, such as... Figure 1 As shown, it is divided into a vehicle-to-everything (V2X) node layer, a dual-chain processing layer, and a reputation support layer. The collaborative relationship between these three layers, and the functions and data interaction logic of each module, are as follows: The vehicle-to-everything (V2X) node layer includes two core node types: vehicles and roadside units (RSUs). Vehicle Nodes: Two types of data are collected in real time via OBU: emergency data is triggered by sudden risks detected by vehicle sensors, such as sudden acceleration changes or collision signals; regular data, such as location, speed, vehicle condition, and road network congestion information, is generated at fixed intervals. These two types of data are respectively connected to the transaction pools of the emergency transaction chain and the regular transaction chain.

[0040] RSU nodes are deployed at intersections, highway service areas, and other locations as data forwarding and auxiliary sensing nodes. On the one hand, they receive broadcast data from vehicles and forward it to the dual-chain, improving the stability of data transmission in weak communication environments. On the other hand, they collect traffic conditions of road sections (such as traffic flow and traffic light phases) to provide auxiliary information for determining the urgency of the data.

[0041] The dual-chain processing layer is the core processing unit for data sharing, divided into an emergency transaction chain and a normal transaction chain subsystem. The high-reputation consensus committee consists of H high-reputation nodes selected by the reputation system, replacing all nodes in optimizing the PBFT consensus. The overall node consensus involves all legitimate nodes in the vehicle network participating in the standard PBFT consensus.

[0042] The reputation support layer is the guarantee for the efficient operation of the two chains. The global reputation value of the computing nodes is stored in the global reputation database, and the high reputation consensus committee of the emergency chain needs to select nodes from this database. The permissions of the consensus nodes of the ordinary chain are also bound to the reputation value, realizing reputation-driven resource scheduling.

[0043] Example 7 A blockchain simulation platform based on Golang was built to compare the subjective logic SL reputation model used in this invention with two existing reputation models: TWSL (Time-Weighted Subjective Logic) and MSMWSL (Multi-Source Multi-Weight Time-Weighted Subjective Logic) reputation models. The performance of the method in this invention was also tested under different transaction loads, node sizes, and block time configurations, and compared with traditional single-chain network consensus schemes. The parameter settings are shown in Table 1. Table 1 System Parameters

[0044] All nodes are initially set to a reputation value of 0.5. The changes in reputation values ​​between honest and malicious nodes are compared over 10 rounds of voting. Figure 3 As shown, when using the Subjective Logic (SL) reputation model, the reputation value of honest nodes only increases slowly, and the reputation of malicious nodes decreases only slightly. This means that the model's punishment for malicious behavior is insufficient, and malicious nodes may maintain a moderate reputation for a considerable period, thus having the opportunity to continue participating in consensus. The TWSL model increases the punishment for malicious nodes, causing their reputation value to drop rapidly to a low level in the first few rounds, but the rewards for honest nodes are also too aggressive, potentially introducing some volatility. In contrast, the MSMWSL reputation model of this invention demonstrates better adaptability: in the initial stage, it can identify and significantly reduce the reputation value of malicious nodes more quickly, shortening the time window for malicious nodes to participate in consensus; in subsequent stages, the punishment for malicious nodes tends to be more gradual to avoid excessive fluctuations in reputation value, while the reputation of honest nodes increases steadily and slowly, requiring them to gradually accumulate high reputation through continuous good behavior. This characteristic ensures that the emergency chain verification nodes are basically nodes with reliable recent performance, making it difficult for malicious nodes to suddenly act maliciously after gaining high reputation through short-term strategic behavior, thus improving the security of emergency business processing at the system level. In addition, the reasonable setting of the weights of each dimension in the MSMWSL model avoids the dominance of a single factor in reputation assessment, prevents a few nodes from quickly improving their reputation by manipulating a certain indicator, and helps maintain the fairness and stability of reputation in long-term operation.

[0045] Figures 4(a) to 4(d) show the average confirmation latency for different numbers of nodes and transaction counts of 500, 1000, 1500, and 2000. As can be seen from the figures, in terms of latency performance, the emergency transaction chain of this invention significantly outperforms the ordinary transaction chain or single-chain solution in various scenarios. When the network is under low to medium load, both the emergency transaction chain and the ordinary transaction chain maintain low confirmation latency due to the small number of transactions. However, the emergency transaction chain, due to its more frequent block production and smaller blocks, still has slightly lower latency than the ordinary chain. As the transaction load increases, the latency of the ordinary transaction chain increases significantly, especially when the block production time is set to be long, resulting in a noticeably longer waiting time for transactions in the pool. The emergency transaction chain, due to processing only a small number of emergency transactions and a fixed, small verification group size, exhibits a relatively gradual increase in latency, maintaining a low level even under high load. When the total number of nodes increases, the latency of both chains increases, which is a result of the increased communication overhead of Byzantine consensus with the increase in the number of nodes. However, it can be seen that the latency of the ordinary transaction chain is more sensitive to the number of nodes: the more nodes there are, the faster the latency curve of the ordinary transaction chain rises. In contrast, the emergency transaction chain, because the size of the verification committee p is adjusted as needed and is much smaller than the total number of nodes in the network, has a limited impact on its consensus latency when additional nodes are added. Therefore, under large-scale network conditions, the emergency transaction chain still maintains good real-time performance, while the ordinary transaction chain may experience a sharp increase in latency due to the participation of a massive number of nodes in the consensus process. More importantly, under high transaction loads, the dual-chain architecture of this invention demonstrates practical application value: even if there is a massive amount of regular data to be processed on the ordinary transaction chain at the same time, the small-scale, efficient consensus of the emergency transaction chain can still ensure that a small number of emergency transactions are written to the chain quickly without delay, achieving the isolation and diversion of emergency business and ordinary business, and ensuring that critical messages such as traffic accident warnings are not delayed due to network congestion.

[0046] Figures 5(a) to 5(d) illustrate the throughput for 500, 1000, 1500, and 2000 transactions with different numbers of nodes. As can be seen from the figures, the method of this invention also demonstrates advantages in throughput performance. A short block interval can linearly increase throughput under low load because blocks are generated more frequently, reducing transaction waiting time; however, under high load, a short interval may cause the system to fall into a congested state where "consensus cannot be completed before the next round begins," resulting in fewer actually confirmed blocks and a decrease in throughput. This is reflected in the experimental data: when the transaction load is high and the block time is very short, the system exhibits a decrease in throughput or a slowdown in growth, requiring a balance between block frequency and processing capacity. As the number of nodes increases, distributed consensus generally causes a decrease in system throughput. Both the ordinary transaction chain and the emergency transaction chain of this invention exhibit a decreasing throughput trend with the increase of the number of nodes, but the rate of decrease differs significantly: the ordinary transaction chain experiences a faster throughput decrease due to the rapidly increasing costs of network-wide broadcasting and voting with the number of nodes; the emergency transaction chain, on the other hand, has a higher and more stable consensus efficiency because only p verification nodes participate in each round of consensus, and these nodes are all high-reputation reliable nodes, with fewer low-performance or unstable nodes in the network. Therefore, its throughput decreases more slowly with the expansion of nodes. In extreme cases of high-concurrency transactions and a large number of node combinations, the effective throughput of the ordinary transaction chain may approach zero, while the emergency transaction chain of this invention can still handle a certain number of emergency transactions, maintaining positive output.

Claims

1. A data sharing method based on a blockchain dual-chain architecture, characterized in that, Includes the following steps: Step 1: Based on the vehicle onboard unit (OBU) and roadside unit (RSU), build a dual-chain blockchain network architecture including an emergency transaction chain and a normal transaction chain, and divide the corresponding ledgers; Step 2: Vehicles collect vehicle-to-everything (V2X) service data via OBU and distribute it to the corresponding transaction pool according to type; Step 3: Calculate the urgency index for each transaction entering the emergency transaction chain; Step 4: Calculate the global reputation value of the node using a multi-source, multi-weight subjective logical reputation model; Step 5: Establish a high-reputation consensus committee and execute the emergency data optimization PBFT consensus, while legitimate nodes execute the ordinary data standard PBFT consensus simultaneously. Through the parallel collaboration of the emergency transaction chain and the ordinary transaction chain, efficient data classification and sharing are achieved.

2. The data sharing method based on a blockchain dual-chain architecture according to claim 1, characterized in that, The urgency index mentioned in step 3 is calculated using the following formula: （1） In the formula, This indicates an urgency index, measuring the ultimate urgency of a transaction; This indicates the cumulative number of emergency transaction requests made by the vehicle during this consensus period. Indicates the impact weight of the number of emergency transactions that have been requested; The vehicle's expected urgency for the transaction is calculated using formula (2) and reflects its sensitivity to transaction delays. （2） In the formula, This indicates the average latency for the emergency transaction chain to confirm a block; This indicates the expected latency of a transaction, which is the maximum tolerable latency for the transaction to reach consensus. It is preset by the transaction type. This indicates the time when the transaction occurred, specifically the timestamp when the vehicle generated the transaction. The timestamp indicates the time from which a transaction is sent from the vehicle to the time it is received by the roadside unit, reflecting the transaction transmission delay.

3. The data sharing method based on a blockchain dual-chain architecture according to claim 1, characterized in that, Step 4 specifically includes the following steps: Step 4.1: Set different priority coefficients for different transaction types and calculate basic parameters including familiarity, timeliness of direct opinions, and trajectory similarity to provide input for credit assessment; Step 4.2: Generate and combine direct opinions based on direct interaction behavior between nodes; Step 4.3: Based on the indirect interaction paths between nodes, deduce and combine indirect opinions; Step 4.4: Integrate direct and indirect opinions to output a global reputation value.

4. The data sharing method based on a blockchain dual-chain architecture according to claim 3, characterized in that, Step 4.1 specifically includes: First, different priority coefficients are assigned to different transaction types for weighted processing in subsequent reputation score calculations, calculated according to the following formula: （3） In the formula, Indicates different transaction types, Indicates an emergency transaction. Indicates a non-urgent transaction. This indicates the priority coefficient related to the transaction type; Secondly, familiarity, timeliness of direct opinions, and trajectory similarity are calculated separately, as follows: Familiarity is recorded as It is calculated using the following formula (4): （4） In the formula, This indicates that within the set time window, the vehicle and vehicles The total number of actual interactions between vehicles As data users, vehicles As a data provider; Indicates vehicle Average number of interactions with other vehicle nodes; Indicates with vehicles The set of all vehicles that interact with each other; Represents a set Number of vehicles in China; The timeliness of direct opinions is recorded as It is calculated using the following formula (5): （5） In the formula, Representative vehicle Time to complete the transaction; Representative vehicle The time point at which the data to be evaluated was uploaded. Indicates the timeliness amplification factor; Indicates the decay index; and These are the timeliness amplification factor and attenuation index for emergency data. and These are the timeliness amplification factor and attenuation index for ordinary data, satisfying... , ; Trajectory similarity is denoted as It is calculated using the following formula (6): （6） In the formula, Weights representing the similarity between velocity and direction; Indicates velocity similarity; The directional similarity is represented by the following formula (7): （7） In the formula, This indicates the number of trajectory points participating in the comparison. , Representing vehicles and vehicles The feature value at the k-th trajectory point.

5. The data sharing method based on a blockchain dual-chain architecture according to claim 4, characterized in that, Step 4.2 specifically involves: First, the factors of familiarity, timeliness of direct opinions, and trajectory similarity are weighted and summed, combined with the proportion of urgent interactions. And emergency transaction weighting coefficient, to obtain the vehicle and vehicles Direct opinion weight , means as follows: （8） （9） In the formula, , , Indicates familiarity Timeliness of direct opinions Similarity to trajectory The corresponding weights satisfy ; The weight of direct opinions indicating whether something is urgent or not. Indicates vehicle and vehicles The percentage of emergency interactions between them This represents the weighting factor for emergency transactions. This indicates the weighted parameter for the proportion of emergency situations; Secondly, the validity of outlier data is calculated by combining the growth curve function of the Pearl model. Normal data validity is represented as Calculate according to the following formula: （10） In the formula, This indicates a adjustment factor, which differs between urgent and non-urgent data. X Indicates following the vehicle j The collection of all vehicles that have interacted. Represents any vehicle in the set For vehicles The direct weights; Indicates vehicle x In and vehicles j The number of anomalous data observed during interactions; This represents the weighted average of the outlier data; Using the number of normal data points and the number of abnormal data points as inputs, and combining the positive / negative evidence amplification factor, the validity weighting of normal and abnormal data is completed, as shown below: （11） In the formula, Indicates vehicle and vehicles The number of times normal data occurs between them. These represent the number of emergency and non-emergency data points between vehicles, respectively. Indicates vehicle and vehicles The number of times abnormal data occurred between them. Similarly; This represents the positive evidence amplification factor, usually applicable in emergency situations. , This represents the negative evidence amplification factor, usually used in emergency situations. ; Subsequently, based on the evidence mapping operator in the subjective logic SL trust model, the vehicle is calculated using the following formula (12). i For vehicles j Direct opinion: （12） In the formula, Indicates vehicle i For vehicles j Trust level; Indicates vehicle i For vehicles j Distrust level; Indicates vehicle i For vehicles j Uncertainty; Strengthen the decisiveness of emergency transaction recommendations; This indicates the percentage of urgent evidence counted within the window. Finally, for all vehicles within the period j The collection of all vehicles that have interacted X The opinions are weighted and integrated to obtain the direct opinion combination, as shown below: （13） In the formula, , , This indicates that the system comprehensively considers the vehicle. j The level of trust, distrust, and uncertainty of direct opinions.

6. The data sharing method based on a blockchain dual-chain architecture according to claim 5, characterized in that, Step 4.3 specifically involves: First, a depth-first search algorithm is used to find all indirect paths from source node A to target node C in the vehicle interaction graph; then, the indirect opinion of a single indirect path is calculated using the discount operator based on the subjective logic SL trust model, as shown below: （14） In the formula, B represents an intermediate node, which is obtained by the depth-first search algorithm; , , This represents the degree of trust, distrust, and uncertainty of node A's direct opinion on intermediate node B. , , This represents the degree of trust, distrust, and uncertainty of intermediate node B's direct opinion on node C. , , This represents the degree of trust, distrust, and uncertainty of the indirect opinions of node A and intermediate node B regarding node C. Secondly, for paths with urgent transactions, their weight is increased based on the path priority coefficient, as shown below: （15） （16） In the formula, Let represent the path priority coefficient, and m represent the intermediate nodes that satisfy the sequence relation. This represents the weighting factor for emergency data. Indicates whether there are any urgent transactions along the path; The path weights are calculated as follows: （17） In the formula, This indicates that when node A evaluates target node C through intermediate node m, the weight of this indirect path decreases as the number of path passes increases. This represents the set of vehicle nodes that satisfy the sequence relationship obtained by the indirect opinion path search algorithm. Represents a node m The direct opinion weights to node C; Finally, the weighted average method is used to integrate the indirect opinions from multiple indirect paths, resulting in the system's combined indirect opinions on the target node C, as shown below: （18） In the formula, , , These represent the system's overall trust, distrust, and uncertainty regarding the indirect opinions of the target vehicle node C, respectively.

7. The data sharing method based on a blockchain dual-chain architecture according to claim 6, characterized in that, Step 4.4 specifically involves: First, by combining direct and indirect opinions, the final system opinion is obtained, as follows: （19） In the formula, Indicates the final level of trust. Indicates the final level of distrust. ， Indicates the final uncertainty; K Represents the normalization coefficient; The global reputation score is calculated based on the final trust level and final distrust level after fusion. , means as follows: （20） In the formula, The factor representing the uncertainty.

8. The data sharing method based on a blockchain dual-chain architecture according to claim 1, characterized in that, Step 5 involves establishing a high-reputation consensus committee, specifically as follows: Sort all nodes in descending order of global reputation value, select the top p nodes to form a high-reputation consensus committee, and replace all nodes in the optimization of PBFT consensus; Step 5 involves performing emergency data optimization PBFT consensus, which specifically includes the following sub-steps: Step 5.2.1, Master Node Election and Block Packaging: The node with the highest reputation value in the high-reputation consensus committee serves as the master node. The master node selects the emergency block with the highest urgency based on the urgency index ranking of the emergency transaction blocks after packaging, and broadcasts the block to other validator nodes in the high-reputation consensus committee. Step 5.2.2, Local Node Verification and Voting Feedback: After receiving the candidate emergency block, each verification node performs local verification on the block structure integrity and transaction legality. After the verification is passed, it sends the voting information of signature agreement to the master node. Step 5.2.3, Consensus Result Determination: When the master node receives no less than f+1 identical votes of agreement, where f is the Byzantine fault tolerance parameter and f < p / 3, the consensus is determined to be successful, and the block is recorded in the emergency data blockchain ledger; if not enough votes of agreement are collected within the preset time window, the current consensus is terminated, and a new consensus is initiated. Step 5.2.4, Broadcasting and Uploading Consensus Results: The master node broadcasts the successful consensus result to the entire network, completing the emergency data uploading process.

9. The data sharing method based on a blockchain dual-chain architecture according to claim 8, characterized in that, The dynamic optimization of the high-reputation consensus committee is as follows: Master node round limit: The number of consecutive rounds in which the same node serves as master node shall not exceed a preset value of H. After completing the duties of master node in one round, it shall no longer serve as master node in the subsequent H rounds of emergency consensus. Committee member update: After processing T emergency blocks, the committee is reassessed based on the latest global reputation value of the nodes, and new nodes with high reputation are selected to replace members whose global reputation value has decreased, so as to maintain the reliability of the high-reputation consensus committee.

10. The data sharing method based on a blockchain dual-chain architecture according to claim 1, characterized in that, In step 5, the legitimate nodes execute the PBFT consensus standard for ordinary data, specifically as follows: Nodes whose global reputation value reaches a basic threshold are selected as legitimate nodes and participate in the general data consensus. All legitimate nodes participate in the standard PBFT consensus, verifying, voting on, and recording general data transactions according to the regular block size and block generation speed. After reaching a network-wide consensus, the general data blocks are recorded in the general data blockchain ledger to ensure the consistency and reliability of general data sharing.

Images