A two-layer blockchain-based internet of vehicles data sharing method and system

Abstract

The present application relates to the technical field of Internet of Vehicles data sharing, in particular to an Internet of Vehicles data sharing method and system based on two-layer blockchains. The method determines suitable vehicles as proxy nodes, verification nodes and data nodes by a trusted agency, the data nodes receive data sensing tasks, collect and train data information according to the data sensing tasks, obtain data models, re-sign the data models, send the signed data models to the proxy nodes, the proxy nodes process the signed data models to obtain data blocks to be verified and send them to the verification nodes, the verification nodes verify the data blocks according to a consensus mechanism and send the results back to the proxy nodes, the proxy nodes generate sharded blockchains according to the verification results, the roadside units verify the validity of the sharded blockchains and add them to global blockchains. The present application improves the scalability and data throughput of the Internet of Vehicles system, improves the security of data sharing and reduces communication delay.

Description

Technical Field

[0001] This invention relates to the field of vehicle network data sharing technology, and in particular to a vehicle network data sharing method and system based on a two-layer blockchain. Background Technology

[0002] The Internet of Vehicles (IoV) is an information exchange platform that enables vehicles to exchange information with their surroundings through various communication media, representing an integration of IoT technology and intelligent transportation. According to the definition of the IoV Industry Technology Innovation Strategic Alliance, the IoV, based on agreed-upon data interaction standards and communication protocols, transmits information such as vehicle driving status, road conditions, and pedestrian activity obtained through technologies like RFID to the cloud. This information is then analyzed, filtered, calculated, and processed, ultimately providing accurate feedback to the vehicle. It possesses multiple functions, including tracking, positioning, and precise navigation. While emerging blockchain technology has been applied to IoV systems with good results, existing blockchain applications still have some problems. For example, current blockchain technologies typically use proof-of-work algorithms or traditional Byzantine fault-tolerant algorithms, leading to significant delays in data sharing between vehicles. Furthermore, the lack of reward and punishment mechanisms in current blockchain technologies results in low incentives for vehicles to participate in data sharing, potentially leading to malicious collusion and a poor user experience. Additionally, the traditional single-chain structure of current blockchain technologies results in low data processing and storage efficiency between vehicles, making it difficult to meet the real-time sharing and exchange of large amounts of data required by current IoV systems.

[0003] The present invention discloses a blockchain-based method for information sharing in the Internet of Vehicles (IoV), a storage medium, and a roadside unit. The method includes data sharing, behavior monitoring, and vehicle evaluation. The data sharing includes: the roadside unit receiving information sensed and uploaded by vehicles and publishing the information to a server and other vehicles within the roadside unit; the roadside unit receiving decision instructions made by the server based on the information and publishing the decision instructions to vehicles; the behavior monitoring includes: the roadside unit monitoring and recording vehicle violations according to preset violation criteria; and the vehicle evaluation includes: the roadside unit obtaining quality scores from information in the blockchain and determining a comprehensive score. Based on the violations committed by the vehicles uploading this information, the reputation value and service fee of the vehicles are determined and published to the blockchain. However, existing technologies suffer from significant delays in data sharing between vehicles due to the lack of suitable consensus mechanisms or algorithms. Furthermore, the absence of reward mechanisms discourages vehicles from participating in data sharing, potentially leading to collusion and resulting in poor user experience and low data security. The traditional blockchain structure also suffers from low efficiency in data processing and storage between vehicles, making it difficult to meet the real-time sharing and exchange of large amounts of data required by current vehicle networking systems. This results in poor system scalability and low throughput. Summary of the Invention

[0004] The purpose of this invention is to address the problems existing in the prior art and provide a method and system for vehicle network data sharing based on a two-layer blockchain. This invention can reduce the communication latency of data sharing between vehicles, incentivize vehicles to participate in data sharing and improve the security of data sharing, and improve the scalability and throughput of the system.

[0005] To achieve the above objectives, the present invention provides a vehicle network data sharing method based on a two-layer blockchain, comprising:

[0006] Step S1: Roadside units and vehicles register with a trusted institution. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution.

[0007] Step S2: The trusted institution calculates a consensus score based on the reputation score, computing power, and location centrality of each vehicle, and selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and accessed the Internet of Vehicles based on the consensus score. Each selected proxy node will be responsible for a shard, and each selected verification node will be selected to join a suitable shard based on the reputation of the proxy node, the location distance, and the size of the shard it is responsible for.

[0008] Step S3: The trusted organization receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted organization transmits the data perception task to the registered roadside unit, and the roadside unit assigns the data perception task to the data node.

[0009] Step S4: The data node collects data information according to the data perception task, trains the data information to generate a data model, signs the data model and sends the signed data model to the proxy node;

[0010] Step S5: The proxy node processes the signed data model to generate a data block to be verified, and the proxy node sends the data block to be verified to the verification node;

[0011] Step S6: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism, and the verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism.

[0012] Step S7: The proxy node generates a sharded blockchain based on the verification result, and the proxy node sends the sharded blockchain to the roadside unit closest to the proxy node;

[0013] Step S8: The roadside unit verifies the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify the blockchain, the certain number of roadside units add the sharded blockchain to the global blockchain. The certain number of roadside units implement smart contracts to update the node's reputation score.

[0014] Step S9: The trusted organization rewards or punishes each node for its performance during the data sharing process, thus completing one data sharing cycle.

[0015] Furthermore, step S1 specifically includes the following processes:

[0016] Step S1.1: Generate a private key for the vehicle : ;

[0017] Step S1.2: The vehicle uses the private key Obtain the public key : The vehicle will use the public key Send to the trusted institution;

[0018] Step S1.3: The trusted institution uses its own private key For the public key Encryption is performed to obtain the ID number corresponding to the vehicle. : The trusted organization will use the ID number The information is sent to the vehicle, and the vehicle completes registration.

[0019] Step S1.4: The vehicle will use the ID number The data is sent to the roadside unit for verification. Vehicles that pass the verification can access the vehicle network, and the vehicle has completed its access to the vehicle network.

[0020] Step S1.5: Vehicles that have completed registration and access to the vehicle network need to submit a deposit to the trusted institution. :

[0021]

[0022] in, This indicates the vehicle's credit score. Denotes a constant, the Used to control the deposit The upper limit.

[0023] Furthermore, the data perception task includes collecting data on vehicle performance, traffic conditions, and environmental conditions.

[0024] Furthermore, the specific process of step S2 includes:

[0025] Step S2.1: The trusted institution bases its decisions on the consensus score submitted by each node. Vehicles are categorized into agent nodes and verification nodes; the trusted authority will fail to submit the consensus score. Nodes deemed selfish are excluded by the roadside unit during the consensus-building process among nodes. The consensus score is... Determined by the following formula:

[0026]

[0027] in, This indicates the vehicle's credit score. Depending on the vehicle's behavior and historical credit score, Indicates the computing power of a node. Indicates the positional centrality of a node. Represents credit score Weighting factors Represents computing power Weighting factors;

[0028] Step S2.2: Node computing power Determined by the following formula:

[0029]

[0030] in, Indicates the number of instructions. This indicates the time required for the node to perform the data sensing task. Indicates a statement about and The function, The function can determine the computing power of a node. ,

[0031] node Location centrality Determined by the following formula:

[0032]

[0033] in, This represents the total number of nodes in the network. This represents an element of the adjacency matrix A, when node and nodes When there are edges, ,otherwise, , Represents a node and nodes The shortest path length between them. This represents the weighting parameter, which controls the importance of degree centrality and compact centrality in the calculation of position centrality;

[0034] Step S2.3: Each proxy node is responsible for one shard, and the proxy node responsible for sharding will generate a shard size indicator. The proxy node will send the shard size indicator to the verification node. The verification node verifies the proxy node's reputation score, the distance between them, and the shard size index. A shard participation list is generated, and the verification node joins each shard according to the shard participation list.

[0035] Furthermore, the fragment size index Determined by the following formula:

[0036]

[0037] in, This represents the node's reputation score. This indicates the geographical distance between the proxy node and the verification node. This indicates the current shard size, which is the maximum number of nodes participating in consensus within the shard. Represents credit score Weighting factors Indicates location distance Weighting factors.

[0038] Furthermore, the specific process of step S8 includes:

[0039] Step S8.1: The roadside unit verifies whether the number of data verification result blocks in the sharded blockchain is greater than the effective consensus threshold. If the value is greater than 1, the generation of the sharded blockchain is approved, and the roadside unit broadcasts the sharded blockchain to all roadside units for verification.

[0040] Step S8.2: All roadside units verify whether the number of data verification result blocks in the sharded blockchain is greater than the effective consensus threshold. If a certain number of roadside units pass the verification, the sharded blockchain is valid, and the certain number of roadside units add the sharded blockchain to the global blockchain.

[0041] Furthermore, the consensus threshold Determined by the following formula:

[0042]

[0043] in, Represents the individual nodes within a shard. Fraction, The influencing factor representing the number of nodes, Indicates the average of all nodes The factors influencing the score, and express Factors affecting fractional variance This represents the total number of nodes in the network.

[0044] In addition, the present invention also provides a vehicle network data sharing system based on a two-layer blockchain, comprising:

[0045] Registration module: Used for roadside units and vehicles to register with trusted institutions. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution.

[0046] Selection module: The trusted institution calculates a consensus score based on the reputation score, computing power and location centrality of each vehicle, and selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and accessed the Internet of Vehicles based on the consensus score. Each selected proxy node will be responsible for a shard, and each selected verification node will be selected to join a suitable shard based on the reputation of the proxy node, the location distance and the size of the shard it is responsible for.

[0047] Task allocation module: The trusted organization receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted organization transmits the data perception task to the registered roadside unit, and the roadside unit allocates the data perception task to the data node.

[0048] Data collection module: The data node can collect data information according to the data perception task, the data node can train the data information to generate a data model, the data node signs the data model and sends the signed data model to the proxy node;

[0049] Module for generating data blocks to be verified: The proxy node processes the signed data model to generate data blocks to be verified, and the proxy node sends the data blocks to be verified to the verification node;

[0050] First verification module: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism, and the verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism.

[0051] Sharded Blockchain Generation Module: The proxy node generates a sharded blockchain based on the verification result, and sends the sharded blockchain to the roadside unit closest to the proxy node;

[0052] The second verification module: The roadside unit verifies the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify the blockchain, the certain number of roadside units add the sharded blockchain to the global blockchain. The certain number of roadside units implement smart contracts to update the node's reputation score.

[0053] Reward and punishment module: The trusted organization rewards or punishes each node for its performance during the data sharing process, thus completing one data sharing cycle.

[0054] Furthermore, the trusted authority is an entity designated by the government or other organizations, which is used to authorize and verify the identity of vehicles and roadside units and to select proxy nodes and verification nodes.

[0055] Finally, the present invention also provides a computer-readable storage medium storing a computer program for a two-layer blockchain-based vehicle network data sharing method, wherein when the computer program for the two-layer blockchain-based vehicle network data sharing method is processed, the steps of the two-layer blockchain-based vehicle network data sharing method are implemented.

[0056] Compared with the prior art, the advantages of this invention are as follows:

[0057] This invention improves the scalability and data sharing throughput of the Internet of Vehicles system by introducing a two-layer blockchain architecture. During the consensus process among nodes in the blockchain network, nodes verify transactions using an improved Byzantine fault-tolerant consensus mechanism. This improved Byzantine fault-tolerant consensus mechanism adds BLS signature technology to the traditional Byzantine fault-tolerant consensus mechanism, reducing communication latency during the data preparation and submission phases. Furthermore, by incorporating a reporting mechanism, it prevents attackers from transacting data, thereby improving the security of data sharing.

[0058] In addition, this invention also improves the enthusiasm of vehicles to participate in data sharing and effectively avoids collusion attacks by nodes in the vehicle network system by introducing a reward and punishment mechanism, thereby improving the user experience and the security of data sharing. Attached Figure Description

[0059] Figure 1 This is a flowchart of a vehicle network data sharing method based on a two-layer blockchain according to an embodiment of the present invention;

[0060] Figure 2 This is a block diagram of a vehicle network data sharing system based on a two-layer blockchain according to an embodiment of the present invention;

[0061] Figure 3 This invention relates to a method for sharing vehicle network data based on a two-layer blockchain.

[0062] Figure 4 This is a process diagram of a vehicle network data sharing method based on a two-layer blockchain according to an embodiment of the present invention;

[0063] Figure 5 This is an architecture diagram of a vehicle network data sharing method based on a two-layer blockchain according to an embodiment of the present invention;

[0064] Figure 6 This is a consensus mechanism process diagram of a two-layer blockchain-based vehicle network data sharing method according to an embodiment of the present invention. Detailed Implementation

[0065] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0066] Example 1:

[0067] like Figure 1 As shown, a preferred embodiment of the present invention provides a vehicle network data sharing method based on a two-layer blockchain, comprising:

[0068] Step S1: Roadside units and vehicles register with a trusted institution. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution.

[0069] Step S2: The trusted institution calculates a consensus score based on the reputation score, computing power, and location centrality of each vehicle. Based on the consensus score, it selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and connected to the vehicle network. Each selected proxy node will be responsible for a shard. Each selected verification node will choose to join a suitable shard based on the reputation of the proxy node, the location distance, and the size of the shard it is responsible for.

[0070] Step S3: The trusted agency receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted agency transmits the data perception task to the registered roadside unit, and the roadside unit assigns the data perception task to the data node.

[0071] Step S4: Data nodes collect data information according to the data perception task, train data information to generate data models, sign data models and send the signed data models to agent nodes.

[0072] Step S5: The proxy node processes the signed data model to generate a data block to be verified, and then sends the data block to be verified to the verification node.

[0073] Step S6: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism. The verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism.

[0074] Step S7: The agent node generates a sharded blockchain based on the verification results, and sends the sharded blockchain to the roadside unit closest to the agent node;

[0075] Step S8: Roadside units verify the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify it, a certain number of roadside units will add the sharded blockchain to the global blockchain, and a certain number of roadside units will implement smart contracts to update the node's reputation score.

[0076] Step S9: The trusted organization rewards or penalizes each node for its performance during the data sharing process, thus completing one data sharing cycle.

[0077] This embodiment improves the scalability and data sharing throughput of the vehicle network system by introducing a two-layer blockchain architecture. In the process of reaching consensus among nodes in the blockchain network, nodes verify transactions by using an improved Byzantine fault-tolerant consensus mechanism. The improved Byzantine fault-tolerant consensus mechanism adds BLS signature technology to the traditional Byzantine fault-tolerant consensus mechanism, reducing communication latency during the data preparation and submission phases. Furthermore, by adding a reporting mechanism, it prevents attackers from trading data, thereby improving the security of data sharing.

[0078] In addition, this embodiment also introduces a reward and punishment mechanism to increase the enthusiasm of vehicles to participate in data sharing and effectively avoid collusion attacks by nodes in the vehicle network system, thereby improving the user experience and the security of data sharing.

[0079] Example 2:

[0080] like Figure 1 As shown in the figure, an embodiment of the present invention provides a method for sharing vehicle network data based on a two-layer blockchain, comprising:

[0081] Step S1: Roadside units and vehicles register with a trusted institution. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution.

[0082] In this embodiment, each vehicle and roadside unit (RSU) generates a unique public-private key pair. , Then, it submits the application to a trusted third-party authority (TA) for registration. After successful registration, each node receives a unique ID number and a digital certificate. Before connecting to the vehicle network, successfully registered vehicles must send this detailed information to the RSU for authentication. Only vehicles that pass authentication can connect to the vehicle network. This embodiment ensures the security of data sharing within the vehicle network through authorization and authentication. The specific process is as follows:

[0083] Step S1.1: Generate a private key for the vehicle : ;

[0084] Step S1.2: The vehicle uses the private key Obtain the public key : The vehicle will use the public key Send to a trusted organization;

[0085] Step S1.3: The trusted institution uses its own private key public key Encryption is performed to obtain the vehicle's corresponding ID number. : Trusted organizations will use ID numbers Send to the vehicle, and the vehicle completes registration;

[0086] Step S1.4: The vehicle will transfer its ID number. The data is sent to the roadside unit for verification. Vehicles that pass the verification can access the vehicle network, and the vehicle is then connected to the vehicle network.

[0087] Step S1.5: Vehicles that have completed registration and access to the vehicle network must submit a deposit to a trusted institution. :

[0088]

[0089] in, This indicates the vehicle's credit score. Represent a constant. Used to control deposits The upper limit.

[0090] Step S2: The trusted institution calculates a consensus score based on the reputation score, computing power, and location centrality of each vehicle. Based on the consensus score, it selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and connected to the vehicle network. Each selected proxy node will be responsible for a shard. Each selected verification node will choose to join a suitable shard based on the reputation of the proxy node, the location distance, and the size of the shard it is responsible for.

[0091] In this embodiment, nodes are classified into proxy nodes and validator nodes based on their consensus score (CS). Before data sharing, the trusted authority instructs each node to submit its CS, which is calculated via a smart contract. Nodes that fail to do so are considered selfish by the master node and excluded from the consensus process.

[0092] Trusted institutions consider the reputation score of each node when determining the CS (Confidentiality Scheme). ), computing power ( ) and positional centrality ( Then, it sorts these scores to obtain... Deep reinforcement learning methods are used to determine the number of slices. and proxy threshold .

[0093] Trusted Institution Selection Score exceeded of Several nodes act as proxy nodes. These nodes issue authorization certificates based on geographical location. After receiving the certificate, the proxy nodes can send beacons to other nodes within range, declaring their identities. During consensus, the proxy nodes need to record their identities in the blocks. Scoring is used to make view changes during data sharing.

[0094]

[0095] Where parameters Represents credit score Weighting factors Represents computing power Weighting factors.

[0096] (1) RS: RS depends on the node’s behavior and historical reputation score. In this embodiment, the beta distribution is used to calculate the reputation score RS. The specific steps are as follows.

[0097] 1) Initialization: At the beginning, for each node... Assign an initial Beta distribution and set the number of honest actions. Number of malicious acts and initialize the list of historical behaviors. .For example This means that the initial preset for node behavior in this embodiment is a malicious probability of 0.5.

[0098] 2) Node behavior observation: at each time step Observe the nodes behavior If the node's behavior is confirmed as honest, then If the node's behavior is determined to be malicious, then .in , These represent the previous time. The number of honest acts and the number of malicious acts, and at the same time, the acts Add to historical behavior list The end of.

[0099] 3) Introduce a decay factor: for each node At each time step Updated and Then, in this embodiment, they are all multiplied by a decay factor. (For example In this way, earlier behaviors will have less weight, while more recent behaviors will have more weight.

[0100]

[0101]

[0102] 4) Sliding window update: This embodiment sets up a sliding window. ,For example This embodiment only considers the most recent This action is used to update and If the historical behavior list Length exceeding So remove from list The first element And update based on its value and .if If it is honest, then... ;;if It's bad, then... .

[0103] 5) Credit Score Calculation: At each time step This embodiment can calculate nodes. Credit score

[0104]

[0105] 6) Reputation score update: Repeat steps 2 to 5, continuously observe the behavior of nodes and update their reputation scores.

[0106] (2) : The specific computational power of a node used for data verification in consensus reflects the node's capabilities.

[0107] The number of instructions a CPU can execute per unit of time. Therefore, It can be defined as

[0108] .

[0109] in Represents the number of instructions. This represents the time required to perform the task. Indicates a statement about

[0110] and A function 。

[0111] (3) LC : LC Represents the positional centrality of nodes in a network; it depends on the degree centrality and compactness of the nodes.

[0112] Mindset. Therefore, nodes. of It can be represented as:

[0113]

[0114] in Represents the total number of nodes in the network. This represents an element of the adjacency matrix A. When a node...

[0115] and nodes When there are edges, Otherwise, . Representative node and nodes The shortest path length between them. It is a weight parameter used to control the importance of degree centrality and close centrality in the calculation of location centrality.

[0116] Step S3: The trusted agency receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted agency transmits the data perception task to the registered roadside unit, and the roadside unit assigns the data perception task to the data node.

[0117] In this embodiment, the data perception task may include collecting data information such as vehicle performance, traffic conditions and environmental conditions. The trusted agency is an entity designated by the government or other organizations. The trusted agency is used to authorize and verify the identity of vehicles and roadside units and to select agent nodes and verification nodes.

[0118] Step S4: Data nodes collect data information according to the data perception task, train data information to generate data models, sign data models and send the signed data models to agent nodes.

[0119] In this embodiment, after receiving the data perception task, the data node immediately begins data collection and training. After signing the pre-trained data model, the data node then sends it to the agent node.

[0120] Step S5: The proxy node processes the signed data model to generate a data block to be verified, and then sends the data block to be verified to the verification node.

[0121] In this embodiment, please refer to Figure 6 As shown, the signed data model sent by the data node to the proxy node is packaged by the proxy node into a data block to be verified. The proxy node distributes the data block to be verified to all verification nodes for verification.

[0122] Step S6: The verification node verifies the data block to be verified according to the improved practical Byzantine fault-tolerant blockchain consensus mechanism, and sends the verification result to the proxy node;

[0123] In this embodiment, please refer to Figure 6 As shown, a data block to be verified has been received. The verification node signs the received data and then sends the signed data block to be verified. The data is sent to the proxy node. After receiving the data, the proxy node first uses BLS to aggregate and sign the data, and then packages the aggregated and signed data into a data block. Then, this data block is broadcast to all verification nodes. Upon receiving the data block, the verification nodes... Next, all signatures within the block will be verified, and a decision will be made as to whether to accept the data block. After verification, the verification node will compile the verification results into a data verification result block. The verification node finally verifies the data result block. The data is sent to the proxy node. In this embodiment, we utilize the BLS-PBFT consensus mechanism to verify the data model in each shard. The traditional PBFT consensus mechanism has four phases: pre-preparation, preparation, commit, and response. To reduce communication complexity, this embodiment introduces BLS signature technology, significantly reducing communication latency in the preparation and commit phases. Furthermore, to prevent malicious behavior by the shard proxy, we designed a reporting mechanism after the response phase. Figure 6 The reporting mechanism can regulate the behavior of individual nodes, thereby ensuring the security of data sharing.

[0124] Step S7: The agent node generates a sharded blockchain based on the verification results, and sends the sharded blockchain to the roadside unit closest to the agent node;

[0125] In this embodiment, please refer to Figure 6 As shown, the proxy node receives the data verification result block. Then, it is packaged into a sharded blockchain, and the agent node sends this sharded blockchain to the roadside unit closest to the agent node for verification.

[0126] Step S8: Roadside units verify the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify it, a certain number of roadside units will add the sharded blockchain to the global blockchain, and a certain number of roadside units will implement smart contracts to update the node's reputation score.

[0127] In this embodiment, step S8 specifically includes:

[0128] Step S8.1: The roadside unit verifies whether the number of data verification result blocks in the sharded blockchain is greater than the effective consensus threshold. If the value is greater than 1, the generation of the sharded blockchain is approved, and the roadside unit broadcasts the sharded blockchain to all roadside units for verification.

[0129] Step S8.2: Verify whether the number of data verification result blocks in the sharded blockchain of all roadside units is greater than the effective consensus threshold. If a certain number of roadside units pass the verification, the sharded blockchain is valid, and a certain number of roadside units will add the sharded blockchain to the global blockchain.

[0130] And consensus threshold Determined by the following formula:

[0131]

[0132] in, Represents the individual nodes within a shard. Fraction The influencing factor representing the number of nodes, Indicates the average of all nodes The factors influencing the score, and express Factors affecting fractional variance This represents the total number of nodes in the network.

[0133] Step S9: The trusted organization rewards or penalizes each node for its performance during the data sharing process, thus completing one data sharing cycle.

[0134] In this embodiment, the following needs to be determined before implementing rewards and punishments:

[0135] 1. Participants

[0136] Proxy nodes, verification nodes, and data nodes.

[0137] 2. Incentive Analysis

[0138] (1) Proxy node

[0139] Cost: Cost of packaging and integrating data Adjusting costs .

[0140] Rewards: Block packaging reward The fine after successful adjustment and .

[0141] Penalty: If a proxy node fails to fulfill its oversight responsibilities, a fine will be imposed. .in For the penalty factor ( ).

[0142] (2) Verification Node

[0143] Cost: The cost required to validate the data .

[0144] Rewards: Block verification rewards and the collusive benefits obtained from data providers. .

[0145] Penalty: If the verification node discovers... If a fake vote is subsequently conducted, the amount will be deducted from the compensation.

[0146] (3) Data Node

[0147] Cost: The cost required for data nodes If the cost of bribing the verification node is .

[0148] Rewards: Data providers will receive a reward if they successfully upload data. ,in Loss factor ( When the system is normal, the node =1, other situations may result in some losses, if it is the income from collusion, then it is... .

[0149] Penalty: If a data provider provides false data and bribes a node, upon discovery... This amount will be deducted from the compensation.

[0150] If the system operates stably, it will receive system benefits r.

[0151] 3. Profit Matrix

[0152] (1) The reward and punishment mechanism for agent node supervision, and the payment matrix for agent node supervision are shown in the following table:

[0153]

[0154] (2) The reward and punishment mechanism for unsupervised agent nodes. The payment matrix when agent nodes are not supervised is shown in the following table:

[0155]

[0156] 4. Evolutionary Game Theory

[0157] In this embodiment, it is assumed that the probability of a data node behaving honestly is... The probability of the corresponding malicious behavior is then...

[0158] ( ), , Let $\begin{cases}$ represent the rewards for honest and malicious behavior by data nodes, and $\begin{cases}$ represent the probability of honest behavior by verification nodes. The probability of the corresponding malicious behavior is ( ) ); , These represent the rewards for honest and malicious behavior by verification nodes, respectively; and the probability of regulatory behavior by proxy nodes. The probability of unregulated behavior is ( ), , These represent the benefits of regulated and unregulated proxy node behavior, respectively.

[0159] (1) Benefits of honest and malicious behavior of data nodes:

[0160]

[0161]

[0162] Then the replication equations for the behavior of data nodes can be calculated.

[0163]

[0164] (2) Verify the benefits of honest and malicious behavior of nodes:

[0165]

[0166]

[0167] Then the replication equation for verifying the behavior of the node can be calculated.

[0168]

[0169] (3) Benefits of agent node supervision versus non-supervision:

[0170]

[0171]

[0172] Then the replication equation for the behavior of the proxy node can be calculated.

[0173]

[0174] let Their zero point can be obtained as

[0175] and Therefore, it is possible

[0176] Used for Jacobian matrix calculation:

[0177]

[0178] Calculations show that:

[0179]

[0180] for and The eigenvalues ​​and stability of the Jacobian matrix are calculated as shown in the table below:

[0181]

[0182] analyze:

[0183] The equilibrium point (0,0,0) corresponds to a situation where both data nodes and verification nodes behave maliciously, and there is no supervision of proxy nodes. This is the worst-case scenario for the system, not the stable evolution direction we need. Therefore, when designing the reward and punishment mechanism, we need to ensure that the penalties for malicious behavior by data nodes and verification nodes are greater than the cost of supervising proxy nodes. .

[0184] The equilibrium point (0,0,1) corresponds to a situation where the data node is malicious, and the verification node, under the supervision of the proxy node, accepts the malicious behavior of the data node. This situation also represents an insecure environment for the system. Therefore, our reward and punishment mechanism design must meet the condition that malicious behavior by the verification node is penalized. The penalty amount should be high. Therefore, this embodiment requires a relatively high penalty to ensure the safe and stable operation of the system. By introducing a reward and punishment mechanism, this embodiment increases the enthusiasm of vehicles to participate in data sharing and effectively avoids collusion attacks by nodes in the vehicle network system, thereby improving both user experience and data sharing security.

[0185] Example 3:

[0186] like Figure 2 As shown, this embodiment of the invention also provides a vehicle network data sharing system based on a two-layer blockchain, comprising:

[0187] Registration module: Used for roadside units and vehicles to register with trusted institutions. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution.

[0188] Selection Module: This module is used by trusted organizations to calculate a consensus score based on each vehicle's reputation score, computing power, and location centrality. Based on the consensus score, it selects several vehicles as proxy nodes and several vehicles as verification nodes from among the vehicles that have successfully registered and connected to the vehicle network. Each selected proxy node will be responsible for a shard, and each selected verification node will be added to a suitable shard based on the reputation of the proxy node, its location distance, and the size of the shard it is responsible for.

[0189] Task allocation module: The trusted agency receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted agency transmits the data perception task to the registered roadside unit, and the roadside unit allocates the data perception task to the data node.

[0190] Data collection module: Data nodes can collect data information according to data perception tasks, train data information to generate data models, sign data models and send the signed data models to agent nodes;

[0191] Module for generating data blocks to be verified: The proxy node processes the signed data model to generate data blocks to be verified, and then sends the data blocks to be verified to the verification node.

[0192] First verification module: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism. The verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism.

[0193] Sharded Blockchain Generation Module: The agent node generates a sharded blockchain based on the verification results, and sends the sharded blockchain to the roadside unit closest to the agent node;

[0194] The second verification module: roadside units verify the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify it, a certain number of roadside units will add the sharded blockchain to the global blockchain, and a certain number of roadside units will implement smart contracts to update the node's reputation score.

[0195] Reward and punishment module: Trusted organizations reward or punish each node for its performance during the data sharing process, thus completing one data sharing cycle.

[0196] This embodiment improves the scalability and data sharing throughput of the vehicle network system by introducing a two-layer blockchain architecture. In the process of reaching consensus among nodes in the blockchain network, nodes verify transactions by using an improved Byzantine fault-tolerant consensus mechanism. The improved Byzantine fault-tolerant consensus mechanism adds BLS signature technology to the traditional Byzantine fault-tolerant consensus mechanism, reducing communication latency during the data preparation and submission phases. Furthermore, by adding a reporting mechanism, it prevents attackers from trading data, thereby improving the security of data sharing.

[0197] In addition, this embodiment also introduces a reward and punishment mechanism to increase the enthusiasm of vehicles to participate in data sharing and effectively avoid collusion attacks by nodes in the vehicle network system, thereby improving the user experience and the security of data sharing.

[0198] Example 4:

[0199] This embodiment provides a computer-readable storage medium storing a computer program for a two-layer blockchain-based vehicle network data sharing method. When the computer program for the two-layer blockchain-based vehicle network data sharing method is processed, it implements the steps of the two-layer blockchain-based vehicle network data sharing method.

[0200] In summary, this invention improves the scalability and data sharing throughput of the vehicle-to-everything (V2X) system by introducing a two-layer blockchain architecture. During the consensus process among nodes in the blockchain network, nodes verify transactions using an improved Byzantine fault-tolerant consensus mechanism. This improved Byzantine fault-tolerant consensus mechanism incorporates BLS signature technology on top of the traditional Byzantine fault-tolerant consensus mechanism, reducing communication latency during the data preparation and submission phases. Furthermore, by adding a reporting mechanism, it prevents attackers from transacting data, thereby improving the security of data sharing.

[0201] In addition, this invention also improves the enthusiasm of vehicles to participate in data sharing and effectively avoids collusion attacks by nodes in the vehicle network system by introducing a reward and punishment mechanism, thereby improving the user experience and the security of data sharing.

[0202] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A method for sharing vehicle network data based on a two-layer blockchain, characterized in that, include: Step S1: Roadside units and vehicles register with a trusted institution. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution. Step S2: The trusted institution calculates a consensus score based on the reputation score, computing power, and location centrality of each vehicle, and selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and accessed the Internet of Vehicles based on the consensus score. Each selected proxy node will be responsible for a shard, and each selected verification node will be selected to join a suitable shard based on the reputation of the proxy node, the location distance, and the size of the shard it is responsible for. Step S3: The trusted organization receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted organization transmits the data perception task to the registered roadside unit, and the roadside unit assigns the data perception task to the data node. Step S4: The data node collects data information according to the data perception task, trains the data information to generate a data model, signs the data model and sends the signed data model to the proxy node; Step S5: The proxy node processes the signed data model to generate a data block to be verified, and the proxy node sends the data block to be verified to the verification node; Step S6: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism, and the verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism. Step S7: The proxy node generates a sharded blockchain based on the verification result, and the proxy node sends the sharded blockchain to the roadside unit closest to the proxy node; Step S8: The roadside unit verifies the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify the blockchain, the certain number of roadside units add the sharded blockchain to the global blockchain. The certain number of roadside units implement smart contracts to update the node's reputation score. Step S9: The trusted organization rewards or punishes each node for its performance during the data sharing process, thus completing one data sharing cycle.

2. The method for sharing vehicle network data based on a two-layer blockchain according to claim 1, characterized in that, Step S1 specifically includes the following process: Step S1.1: Generate a private key for the vehicle : ; Step S1.2: The vehicle uses the private key Obtain the public key : The vehicle will use the public key Send to the trusted institution; Step S1.3: The trusted institution uses its own private key For the public key Encryption is performed to obtain the ID number corresponding to the vehicle. : The trusted organization will use the ID number The information is sent to the vehicle, and the vehicle completes registration. Step S1.4: The vehicle will use the ID number The data is sent to the roadside unit for verification. Vehicles that pass the verification can access the vehicle network, and the vehicle has completed its access to the vehicle network. Step S1.5: Vehicles that have completed registration and access to the vehicle network need to submit a deposit to the trusted institution. : in, This indicates the vehicle's credit score. Denotes a constant, the Used to control the deposit The upper limit.

3. The method for sharing vehicle network data based on a two-layer blockchain according to claim 2, characterized in that, The data sensing task includes collecting data on vehicle performance, traffic conditions, and environmental conditions.

4. The method for sharing vehicle network data based on a two-layer blockchain according to claim 3, characterized in that, The specific process of step S2 includes: Step S2.1: The trusted institution bases its decisions on the consensus score submitted by each node. Vehicles are categorized into agent nodes and verification nodes; the trusted authority will fail to submit the consensus score. Nodes deemed selfish are excluded by the roadside unit during the consensus-building process among nodes. The consensus score is... Determined by the following formula: in, This indicates the vehicle's credit score. Depending on the vehicle's behavior and historical credit score, Indicates the computing power of a node. Indicates the positional centrality of a node. Reputation score Weighting factors Represents computing power Weighting factors; Step S2.2: Node computing power Determined by the following formula: in, Indicates the number of instructions. This indicates the time required for the node to perform the data sensing task. Indicates a statement about and The function, The function can determine the computing power of a node. , node Location centrality Determined by the following formula: in, This represents the total number of nodes in the network. This represents an element of the adjacency matrix A, when node and nodes When there is an edge, ,otherwise, , Represents a node and nodes The shortest path length between them. This represents the weighting parameter, which controls the importance of degree centrality and compact centrality in the calculation of position centrality; Step S2.3: Each proxy node is responsible for one shard, and the proxy node responsible for sharding will generate a shard size indicator. The proxy node will send the shard size indicator to the verification node. The verification node verifies the proxy node's reputation score, the distance between them, and the shard size index. A shard participation list is generated, and the verification node joins each shard according to the shard participation list.

5. A method for sharing vehicle network data based on a two-layer blockchain according to claim 4, characterized in that, The fragment size index Determined by the following formula: in, This represents the node's reputation score. This indicates the geographical distance between the proxy node and the verification node. This indicates the current shard size, which is the maximum number of nodes participating in consensus within the shard. Reputation score Weighting factors Indicates location distance Weighting factors.

6. A method for sharing vehicle network data based on a two-layer blockchain according to claim 5, characterized in that, The specific process of step S8 includes: Step S8.1: The roadside unit verifies whether the number of data verification result blocks in the sharded blockchain is greater than the effective consensus threshold. If the value is greater than 1, the generation of the sharded blockchain is approved, and the roadside unit broadcasts the sharded blockchain to all roadside units for verification. Step S8.2: All roadside units verify whether the number of data verification result blocks in the sharded blockchain is greater than the effective consensus threshold. If a certain number of roadside units pass the verification, the sharded blockchain is valid, and the certain number of roadside units add the sharded blockchain to the global blockchain.

7. A method for sharing vehicle network data based on a two-layer blockchain according to claim 6, characterized in that, The consensus threshold Determined by the following formula: in, Represents the individual nodes within a shard. Fraction, The influencing factor representing the number of nodes, Indicates the average of all nodes The factors influencing the score, and express Factors influencing fractional variance This represents the total number of nodes in the network.

8. A vehicle-to-everything (V2X) data sharing system based on a two-layer blockchain, characterized in that, include: Registration module: Used for roadside units and vehicles to register with trusted institutions. Vehicles that successfully complete registration and connect to the vehicle network pay a deposit to the trusted institution. Selection module: The trusted institution calculates a consensus score based on the reputation score, computing power and location centrality of each vehicle, and selects several vehicles as proxy nodes and several vehicles as verification nodes from the vehicles that have successfully registered and accessed the Internet of Vehicles based on the consensus score. Each selected proxy node will be responsible for a shard, and each selected verification node will be selected to join a suitable shard based on the reputation of the proxy node, the location distance and the size of the shard it is responsible for. Task allocation module: The trusted organization receives the data perception task and selects several qualified vehicles as data nodes in the vehicle network according to the data perception task. The trusted organization transmits the data perception task to the registered roadside unit, and the roadside unit allocates the data perception task to the data node. Data collection module: The data node can collect data information according to the data perception task, the data node can train the data information to generate a data model, the data node signs the data model and sends the signed data model to the proxy node; Module for generating data blocks to be verified: The proxy node processes the signed data model to generate data blocks to be verified, and the proxy node sends the data blocks to be verified to the verification node; First verification module: The verification node verifies the data block to be verified according to the improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism, and the verification node sends the verification result to the proxy node. The improved Practical Byzantine Fault-Tolerant Blockchain consensus mechanism is to introduce BLS signature technology into the Practical Byzantine Fault-Tolerant consensus mechanism. Sharded Blockchain Generation Module: The proxy node generates a sharded blockchain based on the verification result, and sends the sharded blockchain to the roadside unit closest to the proxy node; The second verification module: The roadside unit verifies the sharded blockchain. The verified sharded blockchain is broadcast by the roadside unit to all roadside units for verification. If a certain number of roadside units verify the blockchain, the certain number of roadside units add the sharded blockchain to the global blockchain. The certain number of roadside units implement smart contracts to update the node's reputation score. Reward and punishment module: The trusted organization rewards or punishes each node for its performance during the data sharing process, thus completing one data sharing cycle.

9. A vehicle network data sharing system based on a two-layer blockchain according to claim 8, characterized in that, The trusted authority is an entity designated by the government or other organizations, which is used to authorize and verify the identity of vehicles and roadside units and to select proxy nodes and verification nodes.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer stored program is executed by the processor, it implements the vehicle network data sharing method based on a two-layer blockchain as described in any one of claims 1 to 8.

Images