Data evidence storage method and device, electronic equipment and storage medium

Abstract

The application discloses a data storage method and device, electronic equipment and storage medium, comprising: obtaining the original data stream of the vehicle, extracting data features from the original data stream, generating the hash value of the original data stream, obtaining the current load state of the vehicle and the data priority of the original data stream, determining the data shunting operation to be performed on the hash value, wherein the data shunting operation includes one of data chaining, local caching and discarding, and the target hash value of the data shunting operation as data chaining is stored to the preset blockchain, wherein the blockchain includes an edge chain and a core chain, the edge chain is used to build the target hash value as a state tree storage, and the core chain is used to store the root hash value of the state tree in the edge chain. The application uses the edge layer to perform hash calculation on the data to be stored, retains the core information of the data, dynamically allocates the edge layer storage data shunting, and realizes real-time storage of decentralized tamper-proof data in combination with the layered blockchain.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to a data storage method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of intelligent connected vehicles, the Internet of Vehicles (IoV) generates massive, high-frequency, and valuable data, including various interaction data between vehicles and the outside world. The authenticity and immutability of this data are the core foundation for building a trustworthy IoV ecosystem and realizing high-level autonomous driving and other functional applications. Therefore, it is crucial to build an efficient and secure IoV data storage system.

[0003] Currently, data storage methods mainly include post-event storage and blockchain consensus mechanism storage. Post-event storage relies on in-vehicle devices for local recording and uploading periodically or after an event trigger. Its post-event processing characteristic cannot meet the dynamic and real-time storage requirements. Traditional blockchain consensus mechanism storage is not designed for highly dynamic and real-time IoT scenarios such as the Internet of Vehicles. Its consensus mechanism parameters are often preset and fixed, and cannot adapt to the dynamic and complex network environment. At the same time, its requirement for homogeneous node computing power is fundamentally contradictory to the huge computing power differences between heterogeneous nodes in the Internet of Vehicles. Therefore, current data storage methods suffer from high storage latency and low resource coordination efficiency, making it difficult to meet the real-time and secure storage requirements of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles. Summary of the Invention

[0004] The purpose of this application is to provide a data storage method, device, electronic device, and storage medium that can solve the problems of high storage latency and low resource coordination efficiency in current data storage methods, making it difficult to meet the real-time and secure storage requirements of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a data evidence storage method, the method comprising: Acquire raw data streams of the vehicle; wherein the raw data streams include at least one of environmental data, vehicle status data, and driving behavior data; Data features are extracted from the original data stream to generate a hash value for the original data stream; Obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of the following: data uploading to the blockchain, local caching, and discarding; The data diversion operation is performed to store the target hash value of the data on the blockchain to a preset blockchain; wherein, the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

[0006] Optionally, the step of extracting data features from the original data stream and generating a hash value for the original data stream includes: Data features are extracted from the raw data stream to obtain data features; wherein, the data features include at least one of obstacle coordinates, region of interest, vehicle state features, and driving behavior features; Obtain the timestamp and regional location of the data features; The data features, along with their timestamps and regional locations, are hashed using a preset hash function to generate the hash value of the original data stream.

[0007] Optionally, before extracting data features from the original data stream and generating the hash value of the original data stream, the method further includes: The original data stream is encrypted using a predetermined encryption key, and the encrypted original data stream is transmitted to the edge layer of the vehicle; wherein, the edge layer is used to generate the hash value of the original data stream; The original data stream transmitted through the edge layer is decrypted to obtain the decrypted original data stream.

[0008] Optionally, obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, includes: Monitor the wireless transmission latency of the vehicle's edge layer and the computing power utilization of edge computing nodes to determine the vehicle's current load status; Obtain the data priority of the decrypted original data stream, input the current load status and the data priority into a pre-trained resource scheduling model, and obtain the data splitting operation to be performed on the hash value.

[0009] Optionally, before obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, the method further includes: Acquire the historical data stream of the vehicle, and use the historical data stream to pre-train the initial model parameters; The data priority of the historical data stream, the wireless transmission latency of the edge layer processing the historical data stream, and the computing power utilization of the edge computing node are used as the state space, and the data diversion operation is used as the action range. Based on the preset reward function, the state space, and the action space, the initial model parameters are adjusted to obtain the trained resource scheduling model.

[0010] Optionally, the step of storing the target hash value of the data splitting operation on a preset blockchain includes: The data splitting operation transmits the target hash value of the data to the edge chain in the preset blockchain, and the target hash value is mapped on the edge chain to obtain a directed acyclic graph; Based on the directed acyclic graph, the target hash value is constructed into a state tree, and the target hash value of the state tree is stored in the edge chain; The root hash value of the state tree in the edge chain is synchronized to the core chain of the blockchain, and the root hash value is stored in the core chain.

[0011] Optionally, after the data splitting operation is performed and the target hash value of the data is stored on the blockchain to a preset blockchain, the method further includes: The data splitting operation discards the first hash value that is to be discarded. The data splitting operation is used to generate a second hash value for local caching, which is then scheduled to an idle edge computing node for local caching. In response to the data splitting operation of the second hash value, the data is updated to be on-chain, and the second hash value is stored in the blockchain.

[0012] Secondly, embodiments of this application provide a data storage device, the device comprising: A data acquisition module is used to acquire the vehicle's raw data stream; wherein the raw data stream includes at least one of environmental data, vehicle status data, and driving behavior data; The feature extraction module is used to extract data features from the original data stream and generate a hash value for the original data stream; The data splitting module is used to obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of the following: data uploading, local caching, and discarding; The data storage module is used to store the target hash value of the data splitting operation on the blockchain to a preset blockchain; wherein, the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

[0013] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the data evidence storage method as described in the first aspect.

[0014] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the data evidence storage method as described in the first aspect.

[0015] The data notarization method provided in this application embodiment obtains the vehicle's original data stream, which includes at least one of environmental data, vehicle status data, and driving behavior data. It extracts data features from the original data stream, generates a hash value of the original data stream, obtains the vehicle's current load status and the data priority of the original data stream, determines the data splitting operation to be performed on the hash value, wherein the data splitting operation includes one of data on-chain, local caching, and discarding, and notarizes the target hash value of the data splitting operation as data on-chain to a preset blockchain. The blockchain includes an edge chain and a core chain. The edge chain is used to construct a state tree notarization of the target hash value, and the core chain is used to notarize the root hash value of the state tree in the edge chain. This application embodiment performs hash calculations on the original data of vehicles to be certified, retaining the core information of the data. Based on data priority and load status, it dynamically allocates data to achieve data distribution for certification. Combined with a blockchain with internal and external layers of edge chain and core chain, it achieves decentralized, tamper-proof, real-time data certification. This helps to realize collaborative data certification and retrieval for applications such as transportation, judiciary, and finance, and meets the real-time and secure certification needs of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles.

[0016] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating the steps of a data storage method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a data evidence storage method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a data storage device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0019] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0020] The data storage method, apparatus, electronic device, and storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0021] Reference Figure 1 The flowchart illustrates the steps of a data evidence storage method provided in an embodiment of this application. The method may include: Step 101: Obtain the vehicle's raw data stream; wherein the raw data stream includes at least one of environmental data, vehicle status data, and driving behavior data.

[0022] In this embodiment, to meet the data storage requirements of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles (IoV), the vehicle's raw data stream is obtained through the vehicle's on-board unit (OBU). This raw data stream includes at least one of environmental data, vehicle status data, and driving behavior data. Specifically, environmental data, vehicle status data, and driving behavior data around the vehicle can be simultaneously collected by multimodal sensors, including LiDAR, cameras, and millimeter-wave radar. Environmental data includes road surface, shoulder, sidewalk, green belt, and obstacle isolation zone; vehicle status data includes vehicle speed, remaining battery power, and fault warning information; and driving behavior data includes braking and steering. This data is packaged into a data stream containing spatiotemporal stamps to form the raw data stream. For example, point cloud data collected by LiDAR, image data captured by the camera, and obstacle distance data detected by millimeter-wave radar are all integrated into the raw data stream. The data stream contains spatiotemporal stamps to ensure temporal and spatial consistency of the data, facilitating subsequent real-time processing and analysis.

[0023] It should be noted that the execution subject of the data storage method provided in this embodiment is the vehicle end, or it can be a roadside end composed of a vehicle and roadside equipment, etc. This embodiment describes the execution subject as the vehicle end. The vehicle end includes various controllers. The various controllers of the vehicle can form a lightweight blockchain. Each controller acts as a computing node, and the encryption and consensus mechanisms of each computing node are consistent.

[0024] Reference Figure 2 This illustration shows a scenario diagram of a data storage method provided in an embodiment of this application. Specifically, a four-layer collaborative architecture of terminal layer, edge layer, blockchain, and application layer is constructed in a vehicle. The terminal layer, such as the vehicle's onboard control unit, acquires multimodal data groups, including onboard data and sensor data, and integrates quantum key distribution (QK). A quantum encryption chip using QKD (Quantum Key Distribution) technology generates encryption keys and transmits them encrypted via a 5G-V2X quantum communication module. The terminal layer wirelessly transmits the acquired data to the edge layer in encryption, achieving high-bandwidth and secure data transmission. The edge layer includes heterogeneous computing gateways, such as high-performance CPU+GPU combinations, used to dynamically allocate the computing power of edge computing nodes and achieve load-balanced resource scheduling. The blockchain includes an edge chain and a core chain, enabling decentralized, tamper-proof, real-time data storage. Finally, the application layer provides service interfaces for clients to obtain the stored data on the blockchain in real time, promoting the implementation of emerging application scenarios for intelligent connected vehicles, such as contactless payment in parking lots, real-time determination of liability in traffic accidents, real-time evidence collection and case determination in the judiciary, insurance claims, vehicle-road collaboration and intelligent scheduling, etc., realizing cross-domain data collaborative storage and evidence collection in transportation, judiciary, finance and other fields.

[0025] Step 102: Extract data features from the original data stream and generate the hash value of the original data stream.

[0026] In this embodiment, the vehicle's onboard control unit transmits the raw data stream to the edge layer for processing. The edge layer includes edge computing nodes composed of multiple controllers. The edge layer is used to generate hash values ​​for the raw data stream. The raw data stream is a data stream containing spatiotemporal stamps that packages environmental data, vehicle status data, and driving behavior data. Specifically, at the edge layer, data features are extracted from the raw data stream to generate hash values ​​for the raw data stream. That is, data features are extracted from environmental data, vehicle status data, and driving behavior data, and hash values ​​for the raw data stream are generated based on the extracted data features.

[0027] In the specific implementation, data features are extracted from the original data stream to obtain data features, such as point cloud data collected by LiDAR, image data captured by camera, and obstacle distance data detected by millimeter-wave radar. The extracted data features include obstacle coordinates, regions of interest, vehicle state features, driving behavior features, etc. A preset hash function is used to combine the data features with the timestamp of the data features and the location of the area where the data was generated to perform hash encoding, generating the hash value of the original data stream. For example, the preset hash function can be the SHA-256 hash algorithm, etc., thereby performing hash calculation on the data features extracted from the original data stream to generate the hash value of the original data stream.

[0028] Step 103: Obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of data uploading to the blockchain, local caching, and discarding.

[0029] In this embodiment, due to the large amount of data requiring notarization, to ensure that high-priority data, data affecting vehicle safety, and data difficult to notarize are notarized first, this embodiment intelligently decides on the splitting operation of hash values ​​calculated at the edge layer based on the vehicle's current load status and data priority before data notarization. Specifically, the current load status of the vehicle and the data priority of the original data stream are obtained. The current load status of the vehicle refers to the network quality of the edge layer, the computing load of edge nodes, and the load of regional edge nodes, etc. A resource scheduling model trained through deep reinforcement learning (such as the DDPG algorithm) dynamically decides on the data splitting operation based on the vehicle's current load status and the data priority of the original data stream, determining the data splitting operation to be performed on the hash value. The data splitting operation includes one of the following: data on-chaining, local caching, and discarding.

[0030] In this embodiment, the data priority of the original data stream is predetermined based on the data type and data content. The data priority includes high priority, medium-high priority, medium priority, and low priority. High priority data is directly related to driving safety or key decision data. If data processing delays or loss lead to difficulties in evidence collection, it needs to be stored on the blockchain first. Medium-high priority data does not affect vehicle safety with short-term delays. Depending on network and computing power, it can be cached or transmitted to other idle edge nodes for processing before being stored on the blockchain. Medium priority data mainly includes vehicle status data and does not affect real-time driving. When computing power is insufficient, local caching can be prioritized. Computing resources are given priority to medium-high and high priority data processing and blockchain storage. Low priority data is auxiliary information or redundant data. Loss of low priority data does not affect driving or the integrity of evidence storage. If the edge node is under high load, it can be discarded directly to release resources.

[0031] Step 104: The data splitting operation is used to store the target hash value of the data on the blockchain to a preset blockchain; wherein, the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

[0032] In this embodiment, the target hash value of the data diversion operation is stored on a preset blockchain as evidence for data on-chain. The blockchain is composed of various controllers or control units of the vehicle and includes an edge chain and a core chain. The edge chain is used to construct a state tree from the target hash value for evidence storage, and the core chain is used to store the root hash value of the state tree in the edge chain. The blockchain adopts an internal and external blockchain structure, including an edge chain and a core chain. In the edge chain, a DAG (Directed Acyclic Graph) structure is used to store the hash values ​​of a large amount of data, and lossless compression is performed through the state tree, supporting large-scale data throughput and second-level confirmation. In the core chain, the root hash value of the state tree in the edge chain is periodically synchronized to ensure data immutability. For example, the target hash value of real-time collision warning data, which is diverted to the blockchain as evidence for data on-chain, is stored on the edge chain, compressed into a state tree, and the root hash value of the state tree in the edge chain is periodically synchronized to the core chain to ensure data integrity and immutability.

[0033] In this embodiment, the edge chain uses a DAG structure to store the hash values ​​of large amounts of data, supporting efficient storage and rapid confirmation of large-scale data, and is suitable for processing data with high real-time requirements. The core chain adopts the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism to ensure that the root hash value of the edge chain cannot be tampered with, thereby enhancing the security and credibility of the data. By monitoring the contract between the edge chain and the core chain, accident data can be synchronized across chains to the service unit chains, such as transportation unit chains, insurance company chains, and judicial unit chains. Through the layered blockchain structure, distributed evidence storage of data is achieved.

[0034] In this embodiment, the vehicle-side API service interface is open, supporting various scenario-based application services, such as traffic management, insurance claims, and judicial evidence collection. When clients such as transportation units, insurance companies, judicial units, or financial institutions initiate data verification requests, the data verification results are returned based on the hash value of the evidence stored on the blockchain. Specifically, transportation units can verify the liability attribution of a traffic accident by querying the evidence stored on the blockchain; insurance companies can quickly assess vehicle damage and process claims based on the evidence stored on the blockchain; and judicial units can obtain accident evidence and determine liability based on the evidence stored on the blockchain. Based on the evidence stored on the blockchain, clients can quickly obtain verification results, improving the efficiency of event processing. This embodiment does not impose specific limitations on this aspect.

[0035] The data notarization method provided in this application embodiment obtains the vehicle's original data stream, which includes at least one of environmental data, vehicle status data, and driving behavior data. It extracts data features from the original data stream, generates a hash value of the original data stream, obtains the vehicle's current load status and the data priority of the original data stream, determines the data splitting operation to be performed on the hash value, wherein the data splitting operation includes one of data on-chain, local caching, and discarding, and notarizes the target hash value of the data splitting operation as data on-chain to a preset blockchain. The blockchain includes an edge chain and a core chain. The edge chain is used to construct a state tree notarization of the target hash value, and the core chain is used to notarize the root hash value of the state tree in the edge chain. This application embodiment performs hash calculations on the original data of vehicles to be certified, retaining the core information of the data. Based on data priority and load status, it dynamically allocates data to achieve data distribution for certification. Combined with a blockchain with internal and external layers of edge chain and core chain, it achieves decentralized, tamper-proof, real-time data certification. This helps to realize collaborative data certification and retrieval for applications such as transportation, judiciary, and finance, and meets the real-time and secure certification needs of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles.

[0036] In some embodiments of this application, step 102, which extracts data features from the original data stream and generates a hash value for the original data stream, may specifically include the following steps: Sub-step 1021: Extract data features from the original data stream to obtain data features; wherein, the data features include at least one of obstacle coordinates, region of interest, vehicle state features, and driving behavior features; Sub-step 1022: Obtain the timestamp and regional location of the data features; Sub-step 1023: Use a preset hash function to hash the data features, as well as the timestamps and regional locations of the data features, to generate the hash value of the original data stream.

[0037] In this embodiment, data features are extracted from the original data stream at the edge layer of the vehicle to obtain data features. Specifically, data features are extracted from environmental data, vehicle state data, and driving behavior data to obtain data features. The data features include at least one of obstacle coordinates, region of interest, vehicle state features, and driving behavior features, thereby obtaining the timestamp and regional location of the data features. A preset hash function is used to hash-encode the target features, timestamp, and regional location to generate the hash value of the original data stream.

[0038] In this embodiment, at the edge computing nodes of the edge layer, feature extraction is first performed on environmental data, vehicle state data, and driving behavior data to extract key data features. These features include, but are not limited to, obstacle coordinates, regions of interest (ROIs), vehicle state features, and driving behavior features. For example, voxel clustering is performed on the LiDAR point cloud data to extract the 3D coordinates of obstacles. Regions of interest (ROIs) features from camera images are extracted, such as lane lines, traffic lights, pedestrians, vehicles, and license plates. Vehicle state features such as vehicle speed, remaining battery power, braking status (not braking), and steering angle (e.g., a 30-degree left turn) are also extracted. Driving behavior features such as the driver's braking, steering, and acceleration behaviors are also extracted.

[0039] In practice, after feature extraction, timestamps and regional location information need to be added to each target feature. The timestamp is used to record the time when the feature was collected, and the regional location is used to record the spatial location of the feature, such as the geographical location of the vehicle or the area collected by the sensor. Timestamps and regional location information are key to ensuring the spatiotemporal consistency and traceability of the data. By adding timestamps and regional locations, the spatiotemporal consistency and traceability of the data are ensured, which facilitates subsequent analysis and traceability, and allows for the location and verification of data when needed.

[0040] In this embodiment, a preset hash function is used to hash the target features, timestamp, and location to generate the hash value of the original data stream. After obtaining the target features, timestamp, and location, the preset hash function is used to hash these information to generate the hash value of the original data stream. The hash function can be SHA-256, i.e., SecureHash Algorithm 256-bit, which can produce a 256-bit (32-byte) hash value, represented by 64 hexadecimal characters. In this embodiment, any other hash algorithm can also be used to generate the hash value; no specific limitation is made here. The hash value is a unique identifier for the data and can verify the integrity and immutability of the data.

[0041] This application embodiment, through feature extraction, timestamp and regional location addition, and hash value generation of environmental data, vehicle status data and driving behavior data, not only preserves the core information of the data, but also ensures the integrity and immutability of the data through hash encoding, providing a reliable foundation for blockchain notarization and data verification.

[0042] In some embodiments of this application, before step 102 extracts data features from the original data stream and generates the hash value of the original data stream, it may further include the following steps: The original data stream is encrypted using a predetermined encryption key, and the encrypted original data stream is transmitted to the edge layer of the vehicle; wherein, the edge layer is used to generate the hash value of the original data stream; The original data stream transmitted through the edge layer is decrypted to obtain the decrypted original data stream.

[0043] In this embodiment, to ensure the security of data transmission, encrypted transmission is used to prevent data from being maliciously attacked or stolen during transmission, thus ensuring the confidentiality and integrity of the data. Therefore, in this embodiment, the vehicle's terminal layer first uses a predetermined encryption key to encrypt the original data stream, and then transmits the encrypted original data stream to the vehicle's edge layer. The edge layer is used to generate a hash value for the original data stream. The original data stream includes environmental data, vehicle status data, and driving behavior data. The predetermined encryption key can be a high-strength encryption key generated through quantum key distribution (QKD) technology. It should be noted that QKD technology utilizes the principles of quantum mechanics to ensure the absolute security of the key, and even if it is eavesdropped on, it will be detected immediately. The generated encryption key is used to encrypt the original data stream, and the encrypted data is transmitted to the edge computing node of the edge layer through 5G or other high-speed wireless networks.

[0044] In practical implementation, the raw data stream collected by the vehicle's onboard control unit includes LiDAR point cloud data containing obstacle distance and location information, camera images containing lane lines, traffic lights, pedestrians, etc., as well as vehicle status data such as vehicle speed, remaining battery power, braking status, and steering angle, and driving behavior data such as braking, steering, and acceleration. The terminal layer can use QKD technology to generate encryption keys and synchronize them to the edge layer. For example, the AES-256 encryption algorithm can be used to encrypt the raw data stream, ensuring data security during transmission. The encrypted data can then be transmitted to the edge layer via the 5G network. The encryption keys generated by QKD technology have extremely high security, ensuring that data will not be stolen or tampered with during transmission. The high bandwidth and low latency of the 5G network enable rapid transmission of encrypted data to the edge layer, meeting real-time requirements.

[0045] In this embodiment, the encrypted original data stream is decrypted through the edge layer to obtain the decrypted original data stream, which contains environmental data, vehicle status data, and driving behavior data. Specifically, at the edge computing node, the encrypted original data stream is first decrypted using a decryption key paired with the encryption key to recover the original data stream. The decrypted original data stream includes environmental data, vehicle status data, and driving behavior data. By recovering the original data stream through decryption, it is ensured that the data has not been tampered with during transmission, maintaining data integrity. It should be noted that the edge computing nodes of the edge layer have high-performance computing capabilities. Edge computing nodes, such as CPUs, GPUs, or a combination of CPUs and GPUs, can quickly decrypt data. The decrypted data can be used for subsequent feature extraction and hash calculations, providing a foundation for subsequent processing.

[0046] The embodiments of this application encrypt and transmit the original data stream and decrypt and recover it, ensuring the security and integrity of the data, improving transmission efficiency, so as to generate accurate hash values ​​and provide a reliable foundation for subsequent blockchain notarization and data verification.

[0047] In some embodiments of this application, step 103, obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, may specifically include the following steps: Sub-step 1031: Monitor the wireless transmission latency of the vehicle's edge layer and the computing power utilization of the edge computing nodes to determine the vehicle's current load status. Sub-step 1032: Obtain the data priority of the decrypted original data stream, input the current load status and data priority into the pre-trained resource scheduling model, and obtain the data splitting operation to be performed on the hash value.

[0048] In this embodiment, before blockchain data storage, the wireless transmission latency of the vehicle's edge layer and the computing power utilization of the edge computing nodes are monitored to determine the vehicle's current load status, which includes high load and low load states. Specifically, in the edge computing nodes, the wireless transmission latency of the edge layer and the computing power utilization of the edge computing nodes are monitored in real time to assess the current load status of the vehicle's edge layer and provide a basis for subsequent data diversion operations. The wireless transmission latency reflects the degree of network congestion, while the computing power utilization reflects the usage of computing resources by the edge computing nodes.

[0049] In practical implementation, wireless transmission latency monitoring can utilize 5G network QoS (Quality of Service) monitoring tools to monitor data transmission latency in real time. For example, if the current wireless transmission latency is 50ms, and the latency exceeds 50ms, the network is considered congested. Computing power utilization monitoring can be achieved through edge computing node monitoring systems, which can monitor the utilization of CPU, GPU, and NPU in real time. If the current CPU utilization is 80%, GPU utilization is 70%, and NPU utilization is 60%, and the average computing power utilization of CPU, GPU, and NPU exceeds 80%, the edge computing node is considered to be under high load; otherwise, it is considered to be under low load. By monitoring wireless transmission latency and computing power utilization, the load status of the edge layer can be understood in real time, providing data support for dynamic resource scheduling.

[0050] In this embodiment, the data priority of the decrypted original data stream is obtained. The current load status and data priority are input into a pre-trained resource scheduling model to obtain the data splitting operation to be performed on the hash value. Specifically, after obtaining the data priority of the decrypted original data stream, the data priority and current load status information are input into the pre-trained resource scheduling model. The resource scheduling model is trained based on deep reinforcement learning algorithms such as DDPG, and can dynamically decide on the data splitting operation to be performed on the hash value of the edge layer according to the input data priority and current load status. The data splitting operation includes options such as data on-chaining, local caching, and discarding.

[0051] Based on load conditions and data priorities, this application embodiment uses a resource scheduling model based on deep reinforcement learning to intelligently decide on the data distribution operations on the edge layer, ensuring the timely transmission of high-priority data. Through intelligent resource scheduling, load balancing and data processing efficiency are optimized, providing a reliable decision-making basis for subsequent data uploading and local caching.

[0052] In some embodiments of this application, step 103, before obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, may further include: Step 01: Obtain the vehicle's historical data stream and use the historical data stream to pre-train the initial model parameters; Step 02: The data priority of the historical data stream, the wireless transmission latency of the edge layer processing the historical data stream, and the computing power utilization of the edge computing node are used as the state space, and the data splitting operation is used as the action range. Step 03: Based on the preset reward function, the state space, and the action space, adjust the initial model parameters to obtain the trained resource scheduling model.

[0053] In this application, before determining the data splitting operation to be performed on the hash value, the historical data stream of the vehicle is pre-acquired. Initial model parameters are obtained through pre-training using this historical data stream, and a resource scheduling model is trained. Specifically, in the initial stage of resource scheduling model training, the historical data stream of the vehicle is first acquired. This historical data stream includes environmental data, vehicle status data, driving behavior data, etc., from the past 24 hours or longer. The historical data stream is used to pre-train a deep reinforcement learning model (such as the DDPG algorithm) to generate initial model parameters. These initial model parameters are the initial model parameters of the deep reinforcement learning model. During pre-training, the model learns how to perform data splitting operations based on data priority, wireless transmission latency, and computing power utilization using historical data. The purpose of pre-training is to enable the model to have a certain resource scheduling capability before real-time adjustments are made.

[0054] In practice, during pre-training, the data priority of historical data streams, wireless transmission latency, and edge node computing power utilization are defined as the state space. The state space is the feature set of the model input, used to describe the current system state. Data splitting operations serve as the action space, which defines the operations the model can perform, including data uploading, local caching, and data discarding. Based on the preset reward function, state space, and action space, the initial model parameters are adjusted to obtain the trained resource scheduling model.

[0055] It should be noted that, based on a preset reward function, state space, and action space, the initial model parameters are adjusted. The reward function is used to evaluate the quality of each decision made by the model, and the model parameters are adjusted according to the reward value. The adjustment process is implemented through a deep reinforcement learning algorithm (such as DDPG), ultimately resulting in a trained resource scheduling model. In this embodiment, the reward function can be calculated using the following formula: R= Latency × 0.6 Computing power consumption × 0.3 + Data integrity × 0.1 Among them, latency refers to wireless transmission latency. The lower the latency, the higher the reward. Computing power consumption is reflected by the computing power utilization rate of edge nodes. The lower the computing power consumption, the higher the reward. Data integrity refers to whether the data is completely uploaded to the chain or cached. The higher the data integrity, the higher the reward.

[0056] This application embodiment generates initial model parameters through historical data, and dynamically adjusts the model parameters using a reward function and a deep reinforcement learning algorithm to obtain a trained resource scheduling model. The resource scheduling model can perform real-time dynamic resource scheduling under network congestion and computing power shortage, ensuring that key data is stored on the blockchain.

[0057] In some embodiments of this application, step 104, which involves storing the target hash value of the data splitting operation on a preset blockchain, may specifically include the following steps: Sub-step 1041: The target hash value of the data splitting operation is transmitted to the edge chain in the preset blockchain, and the target hash value is mapped on the edge chain to obtain a directed acyclic graph. Sub-step 1042: Based on the directed acyclic graph, construct a state tree from the target hash value, and store the target hash value of the state tree in the edge chain; Sub-step 1043: Synchronize the root hash value of the state tree in the edge chain to the core chain of the blockchain, and store the root hash value in the core chain.

[0058] In this embodiment, after the data splitting operation is determined, the target hash value of the data splitting operation is transmitted to the edge chain in the preset blockchain. The target hash value is mapped on the edge chain to obtain a directed acyclic graph. Specifically, the high-priority target hash value will be transmitted to the edge chain of the blockchain. The edge chain uses a DAG (Directed Acyclic Graph) structure to store the target hash value. DAG is an efficient data structure that supports fast storage and querying of large-scale data. At the same time, it is compressed and stored using an sMPT (Simplified Merkle Patricia Tree) tree to further reduce storage space.

[0059] In this embodiment, the target hash value is transmitted to the edge chain and mapped through the DAG structure of the edge chain. Each node in the DAG represents a hash value, and the nodes are connected by directed edges to form an acyclic graph. For example, the hash value of the braking command is mapped to a node in the DAG and connected to other previously stored hash value nodes. The DAG structure supports fast storage and querying of large-scale data, meeting the high throughput requirements of the edge chain.

[0060] In this embodiment, based on the DAG structure, the edge chain further compresses the target hash value into a state tree. The state tree is an efficient data compression structure that can aggregate multiple hash values ​​into a hash tree to obtain the root hash value of the state tree, reducing storage space. In this embodiment, the state tree can be an sMPT tree, also known as a sparse Merkle-Patricia tree, which is used to organize all hashes into a tree and finally obtain a root hash. Any change to the hash value of any data will cause the root hash to change completely, thereby ensuring data integrity. By compressing storage through the sMPT tree, storage space is reduced and storage efficiency is improved. The state tree is stored in the edge chain to ensure the immutability of the data.

[0061] In practice, the root hash value of the state tree in the edge chain is synchronized to the core chain of the blockchain and stored in the core chain. The root hash value can be periodically synchronized to the core chain. The core chain adopts the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism to ensure the efficiency and immutability of data. The root hash value is stored in the core chain, forming a dual storage mechanism of inner and outer chains, which further enhances the security and credibility of the data.

[0062] For example, the root hash value of the state tree generated in the edge chain is periodically synchronized to the core chain. The core chain uses the PBFT consensus mechanism to store the root hash value. The core chain synchronizes the root hash value of the edge chain every 10 minutes to ensure the immutability of the data. The core chain also uses the PBFT consensus mechanism to ensure efficient synchronization and storage of the root hash value, meeting real-time requirements. Through dual storage by the edge chain and the core chain, the security and immutability of the data are ensured, enhancing the credibility of the data. It should be noted that for high-priority data, such as braking commands and other data that affect vehicle safety, NTRU lattice cryptography, which is resistant to quantum computing attacks, is used for separate encryption in the blockchain. Combined with the immutability of the blockchain, this enhances the security of the data.

[0063] This application embodiment achieves efficient data storage and compression through DAG and state tree structures. Through the dual notarization mechanism of edge chain and core chain, the immutability and security of data are ensured, and the hash value is efficiently notarized in the edge chain and core chain.

[0064] In some embodiments of this application, step 104, after the data splitting operation is performed and the target hash value for data on-chain is stored in a preset blockchain, may further include: Step 01: Discard the first hash value that is discarded in the data splitting operation; Step 02: The data splitting operation is used as the second hash value for local caching, and then scheduled to an idle edge computing node for local caching; Step 03: In response to the data splitting operation of the second hash value, update to data on-chain and store the second hash value in the blockchain.

[0065] In this embodiment, low-priority data, such as redundant environmental data and vehicle self-inspection logs, has little impact on driving safety and evidence integrity. Therefore, when the computing power utilization of edge nodes is high or the network is congested, low-priority data can be directly discarded to release resources. For example, the first hash value corresponding to the low-priority data is marked as discarded and removed from the cache of the edge node, and no further evidence processing is performed. By discarding low-priority data, the computing and storage resources of the edge node are released, resource overload is avoided, the transmission of low-priority data is reduced, network bandwidth occupation is reduced, and the timely transmission of high-priority data is ensured.

[0066] In this embodiment, the data splitting operation is performed as a locally cached second hash value. This hash value is first scheduled to an idle edge computing node for local caching. Once the current load state of the edge layer meets the data upload conditions, the data splitting operation of the second hash value is updated to upload the data to the blockchain. The second hash value is then transmitted to the blockchain. Idle edge computing nodes can be edge computing nodes in the edge layer that are not currently performing hash calculations. For example, for medium-to-high priority data, the data splitting operation is performed as local caching. The delayed processing of this medium-to-high priority data in a short period will not affect vehicle driving safety. Therefore, when the computing power of edge nodes is insufficient, data can be first scheduled to idle edge computing nodes for local caching, awaiting subsequent processing. This achieves load balancing of computing resources, avoids overload of a single node, and allows for delayed data processing, ensuring that medium-to-high priority data is processed when resources are idle, without affecting driving safety.

[0067] In this embodiment, in response to the data splitting operation of the second hash value being updated to data on the blockchain, the second hash value is transmitted to the blockchain. The data splitting operation of the second hash value being updated to data on the blockchain can be when the current load status of the edge layer, such as computing power utilization and network transmission latency, meets the data on-chain conditions. In this case, the locally cached second hash value is transmitted to the blockchain for storage. The data on-chain conditions refer to the resource scheduling model determining, based on data priority and edge layer load status, the data splitting operation to be executed on the edge layer to be updated to data on the blockchain.

[0068] It should be noted that in this embodiment, high-priority data is represented by priorities 8-10. High-priority data is directly related to driving safety or key decision data. If data processing delays or loss lead to difficulties in evidence collection, it will be prioritized for on-chain storage. For example, data priority 10 includes braking commands and execution status, steering commands and execution status, collision warning signals, etc.; data priority 9 includes active safety system status, advanced autonomous driving system status, autonomous driving mode switching commands, etc.; and data priority 8 includes high-precision positioning data, vehicle distance monitoring data, etc. Medium-high priority data is represented by priorities 5-7. Medium-high priority data does not affect vehicle safety with short-term delays. Depending on network and computing power conditions, it is either cached or transmitted to other idle edge nodes for processing before being stored on the blockchain. For example, data priority 7 includes regular vehicle speed information, lane departure and other system status feedback information; data priority 6 includes key information of the battery management system, tire pressure abnormalities, etc.; and data priority 5 includes adaptive cruise parameters and status information, driver attention monitoring results, etc. Medium-priority data is represented by priorities 3-4. Medium-priority data mainly includes vehicle status data, which does not affect real-time driving. When computing power is insufficient, local caching can be prioritized, allocating computing resources to medium-high and high-priority data processing and on-chain storage to reduce resource consumption. Data can be processed again when idle. Low-priority data is represented by priorities 1-2. Low-priority data is auxiliary information or redundant data; its loss does not affect driving or the integrity of the stored evidence. If the edge node is under high load, low-priority data can be discarded to release resources. Data priority 2 includes redundant data about the external environment, such as radar point clouds or camera data when there are no obstacles. Data priority 1 includes vehicle self-check logs, entertainment system operation records, etc. Data priority 0 includes repeatedly transmitted historical data, etc.

[0069] This application embodiment dynamically adjusts the data on-chain strategy according to the load status, realizing flexible diversion of data with different priorities, ensuring that high-priority data is uploaded to the chain for evidence storage in a timely manner, ensuring the integrity and credibility of the data, and the dynamic scheduling mechanism ensures that data is flexibly allocated among different edge nodes, optimizing resource utilization.

[0070] Reference Figure 3 The diagram shows a structural schematic of a data storage device provided in an embodiment of this application. The device includes: The data acquisition module 201 is used to acquire the raw data stream of the vehicle; wherein the raw data stream includes at least one of environmental data, vehicle status data, and driving behavior data; The feature extraction module 202 is used to extract data features from the original data stream and generate a hash value of the original data stream; The data splitting module 203 is used to obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of data uploading, local caching, and discarding; The data storage module 204 is used to store the target hash value of the data splitting operation into a preset blockchain; wherein the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

[0071] Optionally, the feature extraction module 202 includes: An extraction submodule is used to extract data features from the original data stream to obtain data features; wherein, the data features include at least one of obstacle coordinates, region of interest, vehicle state features, and driving behavior features; The acquisition submodule is used to acquire the timestamp and regional location of the data features; The generation submodule is used to hash the data features, the timestamps and regional locations of the data features using a preset hash function to generate the hash value of the original data stream.

[0072] Optionally, the feature extraction module 202 further includes: An encryption submodule is used to encrypt the original data stream using a predetermined encryption key and transmit the encrypted original data stream to the vehicle's edge layer; wherein, the edge layer is used to generate a hash value for the original data stream; The decryption submodule is used to decrypt the encrypted original data stream through the edge layer to obtain the decrypted original data stream.

[0073] Optionally, the data splitting module 203 includes: The monitoring submodule is used to monitor the wireless transmission latency of the vehicle's edge layer and the computing power utilization of the edge computing nodes to determine the vehicle's current load status. The splitting submodule is used to obtain the data priority of the decrypted original data stream, input the current load status and the data priority into the pre-trained resource scheduling model, and obtain the data splitting operation to be performed on the hash value.

[0074] Optionally, the device further includes: The historical data acquisition module is used to acquire the historical data stream of the vehicle and to pre-train the initial model parameters using the historical data stream. The parameter determination module is used to take the data priority of the historical data stream, the wireless transmission latency of the edge layer processing the historical data stream, and the computing power utilization rate of the edge computing node as the state space, and the data diversion operation as the action range. The model adjustment module is used to adjust the initial model parameters based on the preset reward function, the state space, and the action space to obtain the trained resource scheduling model.

[0075] Optionally, the data storage module 204 includes: The mapping submodule is used to transmit the target hash value of the data splitting operation to the edge chain in the preset blockchain, and to map the target hash value on the edge chain to obtain a directed acyclic graph. The first evidence storage submodule is used to construct a state tree from the target hash value based on the directed acyclic graph, and to store the target hash value of the state tree to the edge chain. The second evidence storage submodule is used to synchronize the root hash value of the state tree in the edge chain to the core chain of the blockchain, and to store the root hash value in the core chain.

[0076] Optionally, the device further includes: The first processing module is used to discard the first hash value that the data splitting operation is designed to discard. The second processing module is used to split the data into a second hash value for local caching and schedule it to an idle edge computing node for local caching. An update module is used to update the data onto the blockchain in response to the data splitting operation of the second hash value, and to store the second hash value on the blockchain.

[0077] The data storage device provided in this application embodiment can realize each process of the data storage method in the above embodiments of this application. To avoid repetition, it will not be described again here.

[0078] The data storage device provided in this application embodiment acquires the vehicle's original data stream, which includes at least one of environmental data, vehicle status data, and driving behavior data. It extracts data features from the original data stream, generates a hash value for the original data stream, acquires the vehicle's current load status and the data priority of the original data stream, determines the data splitting operation to be performed on the hash value, wherein the data splitting operation includes one of data uploading to the blockchain, local caching, and discarding, and stores the target hash value of the data splitting operation as data uploading to the blockchain to a preset blockchain. The blockchain includes an edge chain and a core chain. The edge chain is used to construct a state tree for storage of the target hash value, and the core chain is used to store the root hash value of the state tree in the edge chain. This application embodiment performs hash calculations on the original data of vehicles to be certified, retaining the core information of the data. Based on data priority and load status, it dynamically allocates data to achieve data distribution for certification. Combined with a blockchain with internal and external layers of edge chain and core chain, it achieves decentralized, tamper-proof, real-time data certification. This helps to realize collaborative data certification and retrieval for applications such as transportation, judiciary, and finance, and meets the real-time and secure certification needs of high-frequency, heterogeneous, and high-concurrency scenarios in the Internet of Vehicles.

[0079] Reference Figure 4 This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304. Processor 301, memory 303 for storing processor-executable instructions; The processor 301 is configured to execute the instructions to implement the data evidence storage method described above.

[0080] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0081] The communication interface is used for communication between the aforementioned terminal and other devices.

[0082] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0083] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0084] In another embodiment provided in this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements any of the data evidence storage methods described in the above embodiments.

[0085] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0086] 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.

[0087] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0088] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A data evidence storage method, characterized in that, The method includes: Acquire raw data streams of the vehicle; wherein the raw data streams include at least one of environmental data, vehicle status data, and driving behavior data; Data features are extracted from the original data stream to generate a hash value for the original data stream; Obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of the following: data uploading to the blockchain, local caching, and discarding; The data diversion operation is performed to store the target hash value of the data on the blockchain to a preset blockchain; wherein, the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

2. The method of claim 1, wherein, The step of extracting data features from the original data stream and generating a hash value for the original data stream includes: Data features are extracted from the raw data stream to obtain data features; wherein, the data features include at least one of obstacle coordinates, region of interest, vehicle state features, and driving behavior features; Obtain the timestamp and regional location of the data features; The data features, along with their timestamps and regional locations, are hashed using a preset hash function to generate the hash value of the original data stream.

3. The method according to claim 1 or 2, characterized in that, Before extracting data features from the original data stream and generating the hash value of the original data stream, the method further includes: The original data stream is encrypted using a predetermined encryption key, and the encrypted original data stream is transmitted to the edge layer of the vehicle; wherein, the edge layer is used to generate the hash value of the original data stream; The original data stream transmitted through the edge layer is decrypted to obtain the decrypted original data stream.

4. The method of claim 3, wherein, The step of obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, includes: Monitor the wireless transmission latency of the vehicle's edge layer and the computing power utilization of edge computing nodes to determine the vehicle's current load status; Obtain the data priority of the decrypted original data stream, input the current load status and the data priority into a pre-trained resource scheduling model, and obtain the data splitting operation to be performed on the hash value.

5. The method of claim 4, wherein, Before obtaining the current load status of the vehicle and the data priority of the original data stream, and determining the data splitting operation to be performed on the hash value, the method further includes: Acquire the historical data stream of the vehicle, and use the historical data stream to pre-train the initial model parameters; The data priority of the historical data stream, the wireless transmission latency of the edge layer processing the historical data stream, and the computing power utilization of the edge computing node are used as the state space, and the data diversion operation is used as the action range. Based on the preset reward function, the state space, and the action space, the initial model parameters are adjusted to obtain the trained resource scheduling model.

6. The method of claim 1, wherein, The step of storing the target hash value of the data splitting operation on the blockchain to a preset blockchain includes: The data splitting operation transmits the target hash value of the data to the edge chain in the preset blockchain, and the target hash value is mapped on the edge chain to obtain a directed acyclic graph; Based on the directed acyclic graph, the target hash value is constructed into a state tree, and the target hash value of the state tree is stored in the edge chain; The root hash value of the state tree in the edge chain is synchronized to the core chain of the blockchain, and the root hash value is stored in the core chain.

7. The method of claim 6, wherein, After the data diversion operation is performed and the target hash value for data on-chain is stored in the preset blockchain, the method further includes: The data splitting operation discards the first hash value that is to be discarded. The data splitting operation is used to generate a second hash value for local caching, which is then scheduled to an idle edge computing node for local caching. In response to the data splitting operation of the second hash value, the data is updated to be on-chain, and the second hash value is stored in the blockchain.

8. A data storage device, characterized in that, The device includes: A data acquisition module is used to acquire the vehicle's raw data stream; wherein the raw data stream includes at least one of environmental data, vehicle status data, and driving behavior data; The feature extraction module is used to extract data features from the original data stream and generate a hash value for the original data stream; The data splitting module is used to obtain the current load status of the vehicle and the data priority of the original data stream, and determine the data splitting operation to be performed on the hash value; wherein, the data splitting operation includes one of the following: data uploading, local caching, and discarding; The data storage module is used to store the target hash value of the data splitting operation on the blockchain to a preset blockchain; wherein, the blockchain includes an edge chain and a core chain, the edge chain is used to construct a state tree of the target hash value for storage, and the core chain is used to store the root hash value of the state tree in the edge chain.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute the instructions to implement the data evidence storage method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, A computer program is stored on the readable storage medium, which, when executed by a processor, implements the data evidence storage method as described in any one of claims 1 to 7.

Images