Driving data evidence storage method and evidence storage device based on double chains

Abstract

The embodiment of the invention provides a double-chain-based driving data evidence storage method and device, and relates to the technical field of vehicle information safety. The method comprises the steps that a communication channel is established based on dynamic identity authentication and a sub-chain, so that a main chain receives a data unit and a root hash which are sent by the sub-chain and are bound in a space-time mode, and the data unit and the root hash are obtained by packaging driving data through a sub-chain vehicle-mounted unit node; performing data validity verification based on root hash; and after the verification is passed, carrying out aggregation packaging on the root hash and the data unit. According to the method, the dynamic binding relationship between the driving data and the time and space is established, the data tampering rate can be effectively reduced, so that the anti-repudiation capability is improved, the success rate of man-in-the-middle attack can be effectively reduced through dynamic identity authentication, the double-chain architecture is adopted, the credible evidence storage of the data is realized, and the problem that the credible evidence storage of the data cannot be realized by the existing method is solved.

Description

Technical Field

[0001] This application relates to the field of vehicle information security technology, and more specifically, to a method and device for storing driving data based on a dual-chain architecture. Background Technology

[0002] Existing single-chain structures rely on centralized cloud platforms for data storage, which poses a single point of failure risk. Furthermore, the fixed-key mechanism is vulnerable to man-in-the-middle attacks, making data easily tampered with and unable to achieve reliable data storage. Summary of the Invention

[0003] The purpose of this application is to provide a driving data storage method and device based on a dual-chain architecture. It establishes a dynamic binding relationship between driving data and time and space, which can effectively reduce the data tampering rate and thus improve the non-repudiation capability. Through dynamic identity authentication, it can effectively reduce the success rate of man-in-the-middle attacks. By adopting a dual-chain architecture, it realizes trusted data storage and solves the problem that existing methods cannot achieve trusted data storage.

[0004] Firstly, this application provides a driving data notarization method based on a dual-chain architecture, applied to a main chain comprising multiple roadside unit nodes. The method includes: establishing a communication channel with a sub-chain based on dynamic identity authentication, enabling the main chain to receive spatiotemporally bound data units and root hashes sent by the sub-chain, wherein the data units and root hashes are obtained by encapsulating the driving data by the sub-chain vehicle-mounted unit nodes; verifying data validity based on the root hash; and aggregating and encapsulating the root hash and data units after successful verification.

[0005] In the technical solution of this application embodiment, establishing a dynamic binding relationship between driving data and spatiotemporal data can effectively reduce the data tampering rate, thereby improving the non-repudiation capability. Through dynamic identity authentication, the success rate of man-in-the-middle attacks can be effectively reduced. A dual-chain architecture is adopted to achieve trusted data storage.

[0006] In some embodiments, the method further includes: performing data anomaly detection on the aggregated and encapsulated data units to obtain anomaly probability; if the anomaly probability is greater than a probability threshold, then performing smart contract verification on the anomalous data. If anomalous data exists, then combining the data from the main chain and sub-chains for smart contract verification to ensure data validity.

[0007] In some embodiments, the driving data includes timestamps, location coordinates, vehicle speed, and steering wheel angle, and the data unit is represented as: ;in, This represents the hash value of a single frame of driving data. Represents a timestamp. This represents the position coordinate offset between adjacent time points. Indicates vehicle speed. Indicates the steering wheel angle. This represents a hash function. It binds time and space to generate data units to encapsulate data, achieving a strong association between single-frame data and the global hash.

[0008] In some embodiments, establishing a communication channel based on dynamic identity authentication and a sub-chain includes: the main chain and the sub-chain periodically generating temporary keys based on the topology structure composed of main chain nodes and sub-chain nodes; if the shared keys of both parties are consistent, a communication channel is established. Dynamic identity authentication verifies the consistency of the shared keys, thereby establishing a trusted communication channel and ensuring that subsequent data transmission is not tampered with.

[0009] In some embodiments, the temporary key includes a public key and a private key, and the main chain and sub-chains periodically synchronize to generate temporary keys based on elliptic curve cryptography, including: randomly generating a private key. k ,and Generate a public key based on the private key and the elliptic curve base points: ;in, n Indicates the order of the elliptic curve. G Represents the base point of the elliptic curve, and ,in, V Represents a set of nodes, including m Each roadside unit node and n Vehicle nodes: V = , E Representing edge sets: ;in, This represents the distance between roadside unit nodes and vehicle nodes. This represents the communication radius. A public key is generated based on the heterogeneous network G consisting of the main link side unit nodes and the sub-link vehicle nodes, and is used for dynamic identity authentication.

[0010] In some embodiments, the data validity verification based on the root hash includes: if the number of roadside unit nodes with correct signatures based on the root hash exceeds the consensus verification pass threshold, then the driving data is determined to be valid. ;in, m This indicates the total number of unit nodes on the main link side. Indicates the first i Each roadside unit node signs the root hash. Data validity is verified before being uploaded to the blockchain; uploading is completed only when the Byzantine fault tolerance condition is met, ensuring the accuracy and authenticity of the uploaded data.

[0011] In some embodiments, the step of performing data anomaly detection on the aggregated and encapsulated data units to obtain anomaly probabilities includes: inputting a feature vector based on the driving data into an LSTM neural network and outputting anomaly probabilities, wherein the feature vector is represented as: The anomaly probability is expressed as: ;in, This represents the output layer weight matrix. This represents the hidden layer state vector of the LSTM. Indicates the output layer bias term. This represents the Sigmoid activation function. Anomaly probability calculation is performed using an LSTM neural network to achieve real-time reliable verification of driving data.

[0012] In some embodiments, the step of performing smart contract verification on the abnormal data if the anomaly probability is greater than a probability threshold includes: determining the driving data as valid if the following three conditions are met simultaneously: ;in, Indicates the time when the event was triggered. Indicates response time. Indicates response delay. This represents the standard deviation of GPS positioning accuracy. This indicates that the vehicle unit node reports the vehicle speed. This indicates that the roadside unit node radar monitors vehicle speed. Data validity is verified using multi-threshold rules derived from smart contracts, further ensuring data security and accuracy.

[0013] In some embodiments, the method further includes: if the anomaly probability is greater than a probability threshold, triggering a data review process. This initiates a data review of the anomalous data to further confirm its existence.

[0014] In some embodiments, the triggered data review process includes: freezing the blockchain write operation of the current data block; performing multi-node collaborative verification of abnormal data based on the roadside unit node; comparing the abnormal data with historical data in the historical feature database, and if the comparison result is greater than a similarity threshold, then the abnormal data is determined to be a known risk pattern. Further confirmation and review of the abnormal data are achieved by comparing the local data of the roadside unit node and the historical data of the main chain with the abnormal data.

[0015] In some embodiments, the multi-node collaborative verification of the abnormal data based on the roadside unit nodes includes: generating a verification request packet and sending it to multiple roadside unit nodes, so that the roadside unit nodes compare the abnormal data with their locally stored data. By comparing the abnormal data with the locally stored data of multiple roadside unit nodes, multi-node collaborative verification of the abnormal data is achieved.

[0016] In some embodiments, the method further includes: sending the data unit to the main chain based on a cross-chain communication protocol to perform cross-chain synchronization of driving data. Real-time synchronization of driving data between the sub-chain and the main chain is achieved based on the cross-chain communication protocol, and the dual-chain architecture effectively reduces consensus latency.

[0017] In some embodiments, the data unit is sent to the main chain based on a cross-chain communication protocol for cross-chain synchronization of driving data. This includes: sending a cross-chain synchronization request to a sub-chain and receiving a synchronization confirmation returned by the sub-chain; sending an encrypted payload to the sub-chain so that the sub-chain can verify the data using a cyclic redundancy check (CRC) code; and if the verification is successful, performing cross-chain data synchronization and determining the success of the cross-chain synchronization. Real-time synchronization of driving data is achieved based on priority using the cross-chain communication protocol.

[0018] In some embodiments, the cross-chain synchronization success determination includes: if the cross-chain synchronization success rate and the number of sampled and verified data blocks simultaneously meet the following two conditions, then the cross-chain data synchronization is successful: ;in, Indicates the success rate of cross-chain synchronization. K Indicates the number of data blocks sampled for validation. Indicates the first in the main chain k A sampled data block This indicates the first subchain that is from the same source as the main chain data and corresponds to it. k The sampling data block, the first This represents the data consistency verification function. This represents the sampling proportion coefficient. This indicates the total number of data blocks. Cross-chain synchronization is determined by the cross-chain synchronization success rate and the number of sampled and verified data blocks, enabling main chain-sub-chain collaborative verification.

[0019] In some embodiments, the method further includes: if the verification fails, resending the cross-chain synchronization request based on an adaptive retransmission request algorithm until the maximum number of retransmissions is reached; if the response time is greater than a timeout threshold, it is determined to be a timeout, wherein the timeout threshold is expressed as: ;in, Indicates the average round-trip time. This indicates the degree of fluctuation and dispersion of round-trip delay relative to the average value. The error setting is based on the retransmission mechanism of the adaptive retransmission request algorithm and timeout determination, improving data synchronization efficiency.

[0020] Secondly, this application provides a dual-chain-based driving data storage device applied to the main chain. The device includes: an identity authentication module for establishing a communication channel with the sub-chain based on dynamic identity authentication, enabling the main chain to receive spatiotemporally bound data units and root hashes sent by the sub-chain. The data units and root hashes are obtained by encapsulating the driving data by the sub-chain's vehicle-mounted unit nodes; a data verification module for verifying data validity based on the root hash; and an aggregation and encapsulation module for aggregating and encapsulating the root hash and data units after successful verification. By establishing a dynamic spatiotemporal binding relationship between driving data, the data tampering rate can be effectively reduced, thereby improving non-repudiation capabilities. Dynamic identity authentication can effectively reduce the success rate of man-in-the-middle attacks. The dual-chain architecture enables trusted data storage, solving the problem that existing methods cannot achieve trusted data storage.

[0021] Thirdly, this application provides a driving data storage device based on a dual-chain architecture, comprising: the main chain mentioned in the first aspect, including multiple roadside unit nodes, used to establish a communication channel with the sub-chain based on dynamic identity authentication to receive spatiotemporally bound data units and root hashes sent by the sub-chain; performing data validity verification based on the root hash; and aggregating and encapsulating the root hash and data units after successful verification; and the sub-chain mentioned in the first aspect, including multiple vehicle-mounted unit nodes, used to acquire driving data and encapsulate the driving data to obtain spatiotemporally bound data units and root hashes. By adopting a dual-chain architecture and establishing a trusted communication channel between the main chain and the sub-chain through dynamic identity authentication, the success rate of man-in-the-middle attacks can be effectively reduced, enabling trusted data storage. Establishing a dynamic binding relationship between driving data and spatiotemporal data can effectively reduce the data tampering rate, thereby improving non-repudiation capabilities and solving the problem that existing methods cannot achieve trusted data storage.

[0022] Fourthly, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program to enable the electronic device to perform the above-described vehicle communication data encryption method.

[0023] Fifthly, this application provides a readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the aforementioned vehicle communication data encryption method. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a driving data storage method based on a dual-chain structure, provided for embodiments of this application; Figure 2 A flowchart for data anomaly handling provided in this application embodiment; Figure 3 This is a schematic diagram of data encapsulation provided for an embodiment of this application; Figure 4 A flowchart illustrating the establishment of a communication channel provided in the embodiments of this application; Figure 5 This is a schematic diagram of the anomaly detection model provided in an embodiment of this application; Figure 6 A data verification flowchart provided for embodiments of this application; Figure 7 A timing diagram of the cross-chain communication protocol provided in the embodiments of this application; Figure 8 A flowchart illustrating the specific implementation of the driving data storage method based on a dual-chain provided in this application embodiment; Figure 9 A structural block diagram of a driving data storage device based on a dual-chain provided in this application embodiment; Figure 10 This is a schematic diagram of a dual-chain architecture provided for an embodiment of this application.

[0026] icon: 110 - Identity Authentication Module; 120 - Data Verification Module; 130 - Aggregation and Encapsulation Module; 140 - Anomaly Detection Module; 150 - Smart Contract Verification Module; 160 - Data Review Module; 170 - Cross-Chain Data Synchronization Module. Detailed Implementation

[0027] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0028] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] Existing vehicle data storage methods, such as using consortium blockchains to encrypt vehicle driving data, do not solve the problem of data association and verification in dynamic environments. Some rely on centralized cloud platforms for data storage, which poses a single point of failure risk. Furthermore, the fixed key mechanism is vulnerable to man-in-the-middle attacks, which have a high success rate (greater than 32%), making the data easy to tamper with and unable to achieve reliable data storage. In addition, the traditional blockchain verification latency is difficult to meet real-time requirements, with typical latency being greater than 500ms.

[0030] To address the aforementioned technical issues, this application provides a dual-chain-based method for storing driving data. This method employs a dual-chain architecture, establishing a trusted communication channel between the main chain and sub-chains through dynamic identity authentication and a temporary key mechanism, effectively reducing the success rate of man-in-the-middle attacks. It establishes a dynamic binding relationship between driving data and spatiotemporal context, effectively reducing data tampering rates and thus enhancing non-repudiation capabilities. Anomaly detection algorithms are used to identify the probability of data anomalies, and multi-dimensional verification rules based on smart contracts enable collaborative verification of abnormal data between the main chain and sub-chains. Cross-chain data synchronization based on a cross-chain communication protocol effectively reduces dual-chain consensus latency. Ultimately, this method achieves trusted storage and traceability verification of driving data generated in a V2X (vehicle to X) communication environment, significantly improving the data tampering detection rate and comprehensively constructing a trustworthy proof system for driving data.

[0031] Please refer to Figure 1 , Figure 1 A flowchart of a driving data storage method based on a dual-chain structure provided in this application embodiment is included, comprising the following steps: S110: Establish a communication channel with the sub-chain based on dynamic identity authentication, so that the main chain can receive the spatiotemporally bound data unit and root hash sent by the sub-chain. The data unit and root hash are obtained by the sub-chain vehicle unit node encapsulating driving data. S120: Data validity verification based on root hash; S130: After successful verification, aggregate and encapsulate the root hash and data unit.

[0032] For example, driving data includes, but is not limited to, timestamps, location coordinates, steering wheel angle, and vehicle speed. The subchain collects driving data in real time and, after successful dynamic identity authentication, sends the driving data and root hash to the main chain. The main chain receives the root hash and data units sent by the subchain, aggregates and encapsulates them, constructs a global Merkle tree from the multiple root hashes of the subchain, and then writes it to the blockchain.

[0033] In addition, after the driving data is collected by the subchain, the driving data can be initially screened and filtered to remove obviously abnormal data, such as the current vehicle speed is 100km / h, but the displacement is only 1m. For the specific process method, the following data anomaly detection method can be used to obtain the anomaly probability. Based on the anomaly probability, the driving data can be initially screened to avoid polluting the main chain after being uploaded.

[0034] Dynamic identity authentication is adopted to verify the consistency of keys and establish a temporary key mechanism to ensure that the data transmitted subsequently has not been tampered with. Spatiotemporally bound data units and root hashes are aggregated and encapsulated to generate a Merkle tree and put on the chain to ensure a strong association between single frame data and global hash, thereby achieving trusted data storage.

[0035] Please refer to Figure 2 , Figure 2 The flowchart for data anomaly handling, in some embodiments, further includes: S150: Perform data anomaly detection on the aggregated and encapsulated data units to obtain the anomaly probability; S160: If the probability of an anomaly is greater than the probability threshold, then the abnormal data is verified by a smart contract.

[0036] The aggregated and encapsulated data is subjected to data anomaly detection. If abnormal data is found, the abnormal data is verified by smart contract. Automated arbitration is performed based on the smart contract's multi-threshold rules (such as response latency ≤200ms, positioning error ≤0.5m), and the verification result is finally written into the dual-chain architecture. If the arbitration verification fails, manual arbitration is initiated.

[0037] Data anomaly detection based on anomaly detection algorithms can be used as a pre-filter to effectively reduce invalid verification load (reduce redundant calculations by 68%).

[0038] Please refer to Figure 3 , Figure 3 This is a schematic diagram of data encapsulation. In some embodiments, encapsulating driving data includes: The driving data is encapsulated into data units, which are represented as follows: ; in, This represents the hash value of a single frame of driving data. Represents a timestamp. This represents the position coordinate offset between adjacent time points. Indicates vehicle speed. Indicates the steering wheel angle. This represents a hash function.

[0039] The specific process of aggregation and encapsulation is as follows: Aggregate multiple sets of data units to generate a root hash: ;in, This represents a data unit, with each unit containing 60 seconds of continuous driving data. RootHash This represents the root hash value of the Merkle tree.

[0040] Driving data such as timestamps, GPS coordinates, and vehicle speed are encapsulated into hash data units. Timestamps can use Unix time format with millisecond precision; GPS coordinates are in latitude, longitude format, for example: 39.9042°N, 116.4074°E; steering wheel angles are in degrees, with a range of ±720°. The hash function can be the SHA3-256 algorithm. The root hash sent by the sub-chain can also be obtained using the SHA3-256 algorithm, and this root hash is used as a leaf node, participating in the construction of the Merkle tree structure along with the root hash generated by the aggregation encapsulation. Aggregation encapsulation involves aggregating multiple sets of data units to generate a root hash, thereby constructing the Merkle tree structure. Binding time (timestamps) and space (location coordinates) in the encapsulation establishes a dynamic binding relationship between driving data and time and space, increasing the data tampering detection rate to 99.7% through this time-space binding.

[0041] Please refer to Figure 4 , Figure 4 Establish a flowchart for the communication channel. In some embodiments, establishing a communication channel based on dynamic identity authentication and subchains includes: S111: The main chain and sub-chains periodically generate temporary keys based on the topology structure composed of the main chain nodes and sub-chain nodes. S112: If both parties share the same key, then establish a communication channel.

[0042] A temporary key, including a public key and a private key, is generated based on the topology consisting of main chain nodes and sub-chain nodes. For example, the main chain (RSU (Road Side Unit) nodes) and the sub-chain vehicle nodes (OBU (On Board Unit) nodes) use an improved ECC algorithm (Elliptic Curve Cryptography) to synchronously generate a temporary key every 60 seconds. The shared key calculated by both parties is compared to see if they are consistent. If they are consistent, a trusted channel is established; otherwise, a key reset protocol is triggered.

[0043] In this way, based on dynamic identity authentication, the consistency of keys can be verified, a trusted communication channel can be established, and the data transmission can be ensured to be tampered with.

[0044] In some embodiments, the temporary key includes a public key and a private key, and the main chain and sub-chains periodically synchronize to generate temporary keys based on elliptic curve cryptography, including: Randomly generate private keyk ,and ; Generate a public key based on the private key and elliptic curve base points: ; in, n Indicates the order of the elliptic curve. G Represents the base point of the elliptic curve, and ,in, V Represents a set of nodes, including m Each roadside unit node and n Vehicle nodes: V = , E Representing edge sets: ;in, This represents the distance between roadside unit nodes and vehicle nodes. Indicates the communication radius.

[0045] Private key k It is a randomly generated integer; the elliptic curve order is determined according to the selected curve type, such as n=2^256 in secp256k1; the key update period is set to 60 seconds. G This represents a heterogeneous network consisting of roadside unit nodes in the main chain and vehicle nodes in the sub-chains. It can represent the Euclidean distance between the roadside unit and the vehicle, with a communication radius such as 300 meters.

[0046] Dynamic authentication is achieved by periodically generating temporary keys, thereby establishing a trusted communication channel. The temporary key mechanism reduces the success rate of MITM attacks to 0.3%.

[0047] In some embodiments, data validity verification based on root hashing includes: if the number of roadside unit nodes with correct signatures based on root hashing exceeds the consensus verification threshold, then the driving data is determined to be valid. ;in, m This indicates the total number of unit nodes on the main link side. Indicates the first i The signature of the root hash by each roadside unit node.

[0048] Total number of main link side unit nodes here Consensus verification passes the threshold, such as ,like If the node verification passes, the driving data is deemed valid.

[0049] The on-chain process is completed when the main chain node verifies that the signature is valid and meets the Byzantine fault tolerance condition.

[0050] Please refer to Figure 5 , Figure 5This is a schematic diagram of an anomaly detection model. In some embodiments, data anomaly detection is performed on the aggregated and encapsulated data units to obtain anomaly probabilities. This includes: inputting a feature vector based on driving data into an LSTM neural network and outputting the anomaly probability. The feature vector is represented as: The probability of an anomaly is expressed as: ;in, This represents the output layer weight matrix. This represents the hidden layer state vector of the LSTM. Indicates the output layer bias term. This represents the Sigmoid activation function.

[0051] An anomaly detection model based on deep learning can be adopted, specifically an improved LSTM neural network with 32 bidirectional LSTM units in the hidden layer. During training, a sliding window mechanism can be used (window length Lw = 60 frames, stride S = 10 frames, batch size Batch = 256, learning rate...). ); This represents the position coordinate offset between adjacent time points. , express t The location coordinates at that moment. The anomaly probability ranges from [0,1]. At that time, the data review process is triggered.

[0052] By using an anomaly detection model to detect data anomalies, the probability of anomalies can be obtained, enabling real-time reliable verification of driving data. The anomaly detection algorithm reduces the storage requirements of the vehicle unit node by 62%. Furthermore, the anomaly detection algorithm acts as a pre-filter to reduce the load of invalid verification (reducing redundant computation by 68%). If the data is tampered with (data anomaly), the anomaly detection algorithm can significantly improve the detection rate of abnormal data.

[0053] In some embodiments, if the anomaly probability is greater than a probability threshold, the abnormal data is verified by a smart contract, including: if the following three conditions are met simultaneously, the driving data is deemed valid: ;in, Indicates the time when the event was triggered. Indicates response time. Indicates response delay. This represents the standard deviation of GPS positioning accuracy. This indicates that the vehicle terminal reports the vehicle speed. This indicates that the roadside unit radar monitors vehicle speed.

[0054] For example, if both conditions are met If the data is deemed valid, a digital certificate (containing timestamp, hash value, and signature) is generated. If at least one of these conditions is not met, the data block is frozen and a manual audit process is triggered. For example, the difference between the trigger event time and the response time of a single frame of driving data received by the main chain must be less than 200 milliseconds. If the response delay is too long, the driving data may be tampered with. The trigger event time refers to the timestamp in the driving data. If a collision occurs between the timestamps, the response time is the time it takes to complete the on-chain (main chain) certificate storage of the driving data.

[0055] By setting multi-threshold detection rules for smart contract verification, the accuracy and reliability of the judgment results are ensured, and collaborative verification between the main chain and sub-chains is achieved. For example, comparing the vehicle speed reported by the vehicle terminal with the vehicle speed monitored by the roadside unit radar, that is, cross-comparing radar speed measurement with blockchain evidence, realizes the physical-digital evidence fusion verification of multiple roadside unit nodes.

[0056] In some embodiments, the method further includes: if the anomaly probability is greater than a probability threshold, triggering a data review process to review and verify the abnormal data to determine its reliability.

[0057] Please refer to Figure 6 , Figure 6 This is a flowchart of the data review process. In some embodiments, triggering the data review process includes: S170: Freeze the blockchain write operation for the current data block; S180: Multi-node collaborative verification of abnormal data based on roadside unit nodes; S190: Compare the abnormal data with historical data in the historical feature database. If the comparison result is greater than the similarity threshold, the abnormal data is determined to be a known risk pattern.

[0058] Specifically, data verification is achieved through multi-node collaborative verification via roadside unit nodes and similarity comparison between abnormal data and historical data. In S190, the historical feature library (historical data stored on the main chain) is called for data matching (comparing differences; for example, the matching threshold δmatch=0.78, if the similarity is greater than 0.78), an 8-dimensional feature vector (including parameters such as mean vehicle speed, standard deviation, and steering correlation) is extracted from the real-time abnormal data window. The Dynamic Time Warping (DTW) algorithm is used to calculate the temporal alignment distance with historical data and generate a normalized similarity score. If the similarity is greater than or equal to 0.78, it is determined to be a known risk pattern.

[0059] In some embodiments, multi-node collaborative verification of abnormal data based on roadside unit nodes includes: generating a verification request packet and sending it to multiple roadside unit nodes so that the roadside unit nodes can compare the abnormal data with the locally stored data.

[0060] Initiate multi-node collaborative verification (with at least 3 RSU nodes participating), generate a verification request packet, and send it to 3 or more RSUs. The RSUs generate a RootHash based on the physical data (such as speed, time, location, etc.) collected by local roadside sensors, compare it with the hash value of the abnormal data, and return a signed verification report to the main chain based on the comparison result. Through multi-node collaborative verification, the verification result of abnormal data can be accurately obtained. If the verification result is indeed abnormal data, the abnormal data can be marked so as to provide a basis for traffic police to determine responsibility, trace responsibility, and handle judicial matters in the future.

[0061] In some embodiments, the method further includes: sending the data unit to the main chain based on a cross-chain communication protocol to perform cross-chain synchronization of driving data.

[0062] The main chain and sub-chains use a customized lightweight communication protocol (LCP-V2X), and the data packet structure is defined as follows:

[0063] Data transmission between the main chain and sub-chains is implemented based on a cross-chain communication protocol.

[0064] Please refer to Figure 7 , Figure 7 This is a sequence diagram of a cross-chain communication protocol. In some embodiments, cross-chain data synchronization based on the cross-chain communication protocol includes: S201: Send a cross-chain synchronization request to the child chain and receive a synchronization confirmation returned by the child chain; S202: Send the encrypted payload to the subchain so that the subchain can verify it using a cyclic redundancy check (CRC) code; S203: If the verification is successful, proceed with cross-chain data synchronization and determine the success of cross-chain synchronization.

[0065] Cross-chain data synchronization occurs when the main chain and sub-chains need to transfer data, such as when a sub-chain sends encapsulated data units to the main chain. Based on a cross-chain communication protocol, cross-chain data synchronization ensures the security and real-time performance of data transmission. The dual-chain architecture reduces consensus latency to 182±15ms.

[0066] In some embodiments, the determination of successful cross-chain synchronization includes: if the cross-chain synchronization success rate and the number of sampled and verified data blocks simultaneously meet the following two conditions, then the cross-chain data synchronization is successful: ;in, Indicates the success rate of cross-chain synchronization. K Indicates the number of data blocks sampled for validation. Indicates the first in the main chain k A sampled data block This indicates the first subchain that has the same data origin as the main chain and corresponds to it. kThe sampling data block, the first This represents the data consistency verification function. This represents the sampling proportion coefficient. Indicates the total number of data blocks.

[0067] For example, the cross-chain synchronization success rate threshold can be set to 99%, the sampling ratio coefficient can be set to 0.2, the total number of data blocks can be no less than 1000, and the return value of the data consistency verification function can be 0 or 1. When the data consistency ratio and sampling quantity conditions are met at the same time, the cross-chain synchronization is determined to be successful.

[0068] In some embodiments, the method further includes: if the verification fails, resending the cross-chain synchronization request based on an adaptive retransmission request algorithm until the maximum number of retransmissions is reached; if the response time is greater than a timeout threshold, it is determined to be a timeout, and the timeout threshold is expressed as: ;in, Indicates the average round-trip time. This indicates the degree of variation and dispersion of round-trip time delay relative to the average value.

[0069] The cross-chain protocol ensures real-time synchronization of verification data (latency <150ms) through adaptive ARQ (Automatic Repeat-reQuest) retransmission, with a maximum number of retransmissions Nretry=3.

[0070] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below. In some embodiments, please refer to... Figure 8 , Figure 8 The flowchart below shows the specific implementation of the driving data storage method based on a two-chain chain, which includes the following steps: S301: Data Acquisition and Input: The subchain collects driving data in real time, which is then initially filtered and encapsulated; S302: Establish a communication channel based on dynamic identity authentication and transmit the encapsulated data unit and root hash to the main chain; S303: After the main chain verifies the validity of the signature, it performs aggregation, encapsulation, and upload to the chain, and then performs abnormal data detection. S304: If the anomaly detection algorithm identifies the data as suspicious ( This triggers smart contract verification.

[0071] Please refer to Figure 9 , Figure 9 The structural block diagram of the driving data storage device based on a dual-chain provided in this application should be understood to be related to... Figure 1The method embodiment executed in this document corresponds to the method described above, and is capable of performing the steps involved in the aforementioned method. The specific functions of this device can be found in the description above; to avoid repetition, detailed descriptions are appropriately omitted here. This device includes, but is not limited to: The identity authentication module 110 is used to establish a communication channel with the sub-chain based on dynamic identity authentication, so that the main chain can receive the spatiotemporally bound data unit and root hash sent by the sub-chain. The data unit and root hash are obtained by the sub-chain vehicle unit node encapsulating driving data. Data validation module 120 is used to validate data validity based on root hash; The aggregation and encapsulation module 130 is used to aggregate and encapsulate the root hash and data unit after verification.

[0072] In the technical solution of this application embodiment, a trusted communication channel is established through dynamic identity authentication, which can effectively reduce the success rate of man-in-the-middle attacks; establishing a dynamic binding relationship between driving data and spatiotemporal data can effectively reduce the data tampering rate, thereby improving non-repudiation capability and realizing trusted data storage.

[0073] According to some embodiments of this application, the identity authentication module 110 is specifically used for: the main chain and the sub-chain periodically and synchronously generating temporary keys based on the topology structure composed of the main chain nodes and the sub-chain nodes; if the shared keys of both parties are consistent, a communication channel is established.

[0074] According to some embodiments of this application, the data verification module 120 is specifically used to: determine the data as valid if the number of nodes with correct signatures based on the root hash of the roadside unit nodes exceeds the consensus verification pass threshold. ;in, m This indicates the total number of unit nodes on the main link side. Indicates the first i The signature of the root hash by each roadside unit node.

[0075] According to some embodiments of this application, the device further includes: The anomaly detection module 140 is used to perform data anomaly detection on the aggregated and encapsulated data units and obtain the anomaly probability; The smart contract verification module 150 is used to perform smart contract verification on abnormal data if the probability of an anomaly is greater than the probability threshold.

[0076] According to some embodiments of this application, the anomaly detection module 140 is specifically used to: input a feature vector based on driving data into an LSTM neural network, and output an anomaly probability, wherein the feature vector is represented as: The probability of an anomaly is expressed as: ;in, This represents the output layer weight matrix. This represents the hidden layer state vector of the LSTM. Indicates the output layer bias term. This represents the Sigmoid activation function.

[0077] According to some embodiments of this application, the smart contract verification module 150 is specifically used to determine that the data is valid if the following three conditions are met simultaneously: ;in, Indicates the time when the event was triggered. Indicates response time. Indicates response delay. This represents the standard deviation of GPS positioning accuracy. This indicates that the vehicle unit node reports the vehicle speed. This indicates that the roadside unit node radar monitors vehicle speed.

[0078] According to some embodiments of this application, the device further includes: If the probability of an anomaly exceeds the probability threshold, the data review module 160 will trigger the data review process.

[0079] According to some embodiments of this application, the data verification module 160 is specifically used for: Freeze blockchain write operations on the current data block; Multi-node collaborative verification of abnormal data is performed based on roadside unit nodes; The abnormal data is compared with the historical data in the historical feature database. If the comparison result is greater than the similarity threshold, the abnormal data is identified as a known risk pattern.

[0080] The specific process of multi-node collaborative verification is as follows: a verification request packet is generated and sent to multiple roadside unit nodes so that the roadside unit nodes can compare the data stored locally with the abnormal data.

[0081] According to some embodiments of this application, the device further includes: The cross-chain data synchronization module 170 is used to send the data unit to the main chain based on the cross-chain communication protocol to perform cross-chain synchronization of driving data.

[0082] According to some embodiments of this application, the data cross-chain synchronization module 170 is specifically used for: sending a cross-chain synchronization request to the sub-chain and receiving a synchronization confirmation returned by the sub-chain; sending an encrypted payload to the sub-chain so that the sub-chain can perform verification using a cyclic redundancy check code; and if the verification is successful, performing data cross-chain synchronization and determining the success of cross-chain synchronization.

[0083] If the verification fails, the cross-chain synchronization request is resent based on the adaptive retransmission request algorithm until the maximum number of retransmissions is reached; if the response time exceeds the timeout threshold, it is determined to be a timeout, and the timeout threshold is expressed as follows: ;in, Indicates the average round-trip time. This indicates the degree of variation and dispersion of round-trip time delay relative to the average value.

[0084] The cross-chain synchronization success determination includes: if both the cross-chain synchronization success rate and the number of sampled and verified data blocks meet the following two conditions, then the cross-chain data synchronization is successful: ;in, Indicates the success rate of cross-chain synchronization. K Indicates the number of data blocks sampled for verification. Indicates the first in the main chain k A sampled data block This indicates the first subchain that has the same data origin as the main chain and corresponds to it. k The sampling data block, the first This represents the data consistency verification function. This represents the sampling proportion coefficient. Indicates the total number of data blocks.

[0085] Please refer to Figure 10 , Figure 10 This is a schematic diagram of a dual-chain architecture. This application also provides a dual-chain-based driving data storage device, including a main chain and a sub-chain. The main chain includes multiple roadside unit nodes, used to establish a communication channel with the sub-chain based on dynamic identity authentication to receive spatiotemporally bound data units and root hashes sent by the sub-chain; to perform data validity verification based on the root hash; and to aggregate and encapsulate the root hash and data units after successful verification. The sub-chain includes multiple vehicle-mounted unit nodes, used to acquire driving data and encapsulate the driving data to obtain spatiotemporally bound data units and root hashes.

[0086] The main chain is deployed on roadside units (RSUs) and uses an improved DPoS (Delegated Proof of Stake, a consensus mechanism based on blockchain technology) consensus mechanism. The number of nodes... It is used to collect data such as vehicle speed, location and time, and can be used for multi-source data verification, execution of non-repudiation rules, and as a global trust anchor.

[0087] SubChain: Deployed on the vehicle-mounted OBU (On Board Unit) device, it uses a lightweight Tangle structure for data encapsulation; it is used to collect vehicle-side data and serve as a reliable guarantee for the data source.

[0088] This application provides an electronic device including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the methods in any of the aforementioned optional implementations.

[0089] This application provides a readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the methods in any of the aforementioned optional implementations.

[0090] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0091] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0092] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0093] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0094] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0095] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A driving data storage method based on a dual-chain, characterized in that, Applied to a main chain, which includes multiple roadside unit nodes, the method includes: A communication channel is established between dynamic identity authentication and the sub-chain to enable the main chain to receive spatiotemporally bound data units and root hashes sent by the sub-chain. The data units and root hashes are obtained by the sub-chain vehicle unit nodes encapsulating the driving data. Data validity is verified based on the root hash; After successful verification, the root hash and data unit are aggregated and encapsulated.

2. The driving data storage method based on dual-chain according to claim 1, characterized in that, The method further includes: Data anomaly detection is performed on the aggregated and encapsulated data units to obtain the anomaly probability; If the anomaly probability is greater than the probability threshold, then the abnormal data is verified by a smart contract.

3. The driving data storage method based on dual-chain according to claim 1, characterized in that, The driving data includes timestamps, location coordinates, vehicle speed, and steering wheel angle. The data unit is represented as follows: ； in, This represents the hash value of a single frame of driving data. Represents a timestamp. This represents the position coordinate offset between adjacent time points. Indicates vehicle speed. Indicates the steering wheel angle. This represents a hash function.

4. The driving data storage method based on dual-chain according to claim 1, characterized in that, The establishment of a communication channel based on dynamic identity authentication and subchains includes: The main chain and sub-chains periodically generate temporary keys based on the topology structure composed of main chain nodes and sub-chain nodes. If both parties share the same key, a communication channel is established.

5. The driving data storage method based on dual-chain according to claim 4, characterized in that, The temporary key includes a public key and a private key. The main chain and sub-chains periodically synchronize and generate temporary keys based on the topology structure composed of main chain nodes and sub-chain nodes, including: Randomly generate private key k ,and ; Generate a public key based on the private key and the elliptic curve base points: ; in, n Indicates the order of the elliptic curve. G Represents the base point of the elliptic curve, and ,in, V Represents a set of nodes, including m Each roadside unit node and n Vehicle nodes: V = , E Representing edge sets: ;in, This represents the distance between roadside unit nodes and vehicle nodes. Indicates the communication radius.

6. The driving data storage method based on dual-chain according to claim 1, characterized in that, The data validity verification based on the root hash includes: If the number of roadside unit nodes whose signatures based on the root hash are correct exceeds the consensus verification threshold, then the driving data is deemed valid. ； in, m This indicates the total number of unit nodes on the main link side. Indicates the first i The signature of the root hash by each roadside unit node.

7. The driving data storage method based on dual-chain according to claim 2, characterized in that, The step of performing data anomaly detection on the aggregated and encapsulated data units to obtain the anomaly probability includes: The feature vector based on the driving data is input into the LSTM neural network, which outputs the anomaly probability. The feature vector is represented as follows: ; The anomaly probability is expressed as: ; in, This represents the output layer weight matrix. This represents the hidden layer state vector of the LSTM. Indicates the output layer bias term. This represents the Sigmoid activation function.

8. The driving data storage method based on dual-chain according to claim 2, characterized in that, If the anomaly probability is greater than a probability threshold, then the abnormal data is verified by a smart contract, including: The driving data is considered valid if all three of the following conditions are met: ； in, Indicates the time when the event was triggered. Indicates response time. Indicates response delay. This represents the standard deviation of GPS positioning accuracy. This indicates that the vehicle unit node reports the vehicle speed. This indicates that the roadside unit node radar monitors vehicle speed.

9. The driving data storage method based on dual-chain according to claim 1, characterized in that, The method further includes: If the probability of an anomaly is greater than the probability threshold, the data review process is triggered.

10. The driving data storage method based on dual-chain according to claim 9, characterized in that, The triggered data review process includes: Freeze blockchain write operations on the current data block; Based on the roadside unit nodes, multi-node collaborative verification of abnormal data is performed; The abnormal data is compared with historical data in the historical feature database. If the comparison result is greater than the similarity threshold, the abnormal data is determined to be a known risk pattern.

11. The driving data storage method based on dual-chain according to claim 10, characterized in that, The multi-node collaborative verification of the abnormal data based on the roadside unit nodes includes: A verification request packet is generated and sent to multiple roadside unit nodes, so that the roadside unit nodes can compare the abnormal data with the locally stored data.

12. The driving data storage method based on dual-chain according to claim 1, characterized in that, The method further includes: The data unit is sent to the main chain based on the cross-chain communication protocol to perform cross-chain synchronization of the driving data.

13. The driving data storage method based on dual-chain according to claim 12, characterized in that, The step of sending the data unit to the main chain based on the cross-chain communication protocol to perform cross-chain synchronization of the driving data includes: Send a cross-chain synchronization request to the child chain and receive a synchronization confirmation returned by the child chain; The encrypted payload is sent to the subchain so that the subchain can verify it using a cyclic redundancy check (CRC) code. If the verification is successful, then cross-chain data synchronization and cross-chain synchronization success determination will be performed.

14. The driving data storage method based on dual-chain according to claim 13, characterized in that, The successful cross-chain synchronization determination includes: Cross-chain synchronization is successful if both the cross-chain synchronization success rate and the number of sampled and verified data blocks meet the following two conditions: ； in, Indicates the success rate of cross-chain synchronization. K Indicates the number of data blocks sampled for validation. Indicates the first in the main chain k A sampled data block This indicates the first subchain that is from the same source as the main chain data and corresponds to it. k The sampling data block, the first This represents the data consistency verification function. This represents the sampling proportion coefficient. Indicates the total number of data blocks.

15. The driving data storage method based on dual-chain according to claim 13, characterized in that, The method further includes: If the verification fails, the cross-chain synchronization request will be resent based on the adaptive retransmission request algorithm until the maximum number of retransmissions is reached. If the response time is greater than the timeout threshold, it is determined to be a timeout. The timeout threshold is expressed as follows: ； in, Indicates the average round-trip time. This indicates the degree of variation and dispersion of round-trip time delay relative to the average value.

16. A driving data storage device based on a dual-chain, characterized in that, Applied to the main chain, the device includes: The identity authentication module is used to establish a communication channel with the sub-chain based on dynamic identity authentication, so that the main chain can receive the spatiotemporally bound data unit and root hash sent by the sub-chain. The data unit and root hash are obtained by the sub-chain vehicle unit node encapsulating the driving data. The data verification module is used to verify the validity of data based on the root hash. An aggregation and encapsulation module is used to aggregate and encapsulate the root hash and data units after verification.

17. A driving data storage device based on a dual-chain, characterized in that, include: The main chain in the driving data storage method based on dual chains according to any one of claims 1-15 includes multiple roadside unit nodes, which are used to establish a communication channel with the sub-chain based on dynamic identity authentication to receive spatiotemporally bound data units and root hashes sent by the sub-chain; perform data validity verification based on the root hash; and aggregate and encapsulate the root hash and data units after the verification is passed. The subchain in the driving data storage method based on a dual-chain according to any one of claims 1-15 includes multiple vehicle unit nodes for acquiring driving data and encapsulating the driving data to obtain spatiotemporally bound data units and root hashes.

18. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the driving data storage method based on a dual-chain as described in any one of claims 1 to 15.

19. A readable storage medium, characterized in that, The readable storage medium stores computer program instructions, which are read and executed by a processor to perform the driving data storage method based on a dual-chain as described in any one of claims 1 to 15.

Images