Block chain evidence storage and secure transmission system for video data in Internet of Vehicles environment

Abstract

The invention discloses a block chain evidence storage and secure transmission system for video data in an Internet of Vehicles environment, and particularly relates to the field of data security, comprising a data acquisition module, a data processing module, a data analysis module, a block chain evidence storage module and an application port, the data acquisition module acquires multi-source data through a vehicle-mounted high-definition camera, a sensor and a road side unit, the data processing module encrypts a video by adopting an SM4 algorithm, transmits a secret key and extracts the characteristics of a license plate, a track and the like in combination with an SM2 algorithm, and the data analysis module constructs a dynamic model based on a Markov decision process, detects abnormity through a sliding window and a fusion model, and sends the abnormity to the vehicle-mounted high-definition camera. The block chain evidence storage module builds a 7-node alliance chain, adopts a dual hash mechanism to store evidence, and provides data query and verification services for traffic management, insurance claim settlement and vehicle manufacturers through an application port. According to the system, the security, integrity and traceability of the video data are guaranteed, the cross-domain sharing efficiency is improved, and the multi-field application requirements are met.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and more specifically, to a blockchain-based system for storing and securely transmitting video data in a vehicle-to-everything (V2X) environment. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, the video data generated by vehicles in the vehicle-to-everything (V2X) environment is experiencing explosive growth. This video data covers key information such as vehicle driving trajectory, road environment, and traffic participant behavior, and has irreplaceable application value in areas such as intelligent traffic management (e.g., traffic flow control), traffic accident liability determination, vehicle safety monitoring (e.g., dangerous driving behavior identification), and insurance claims (e.g., accident authenticity verification).

[0003] Currently, the collection of vehicle-to-everything (V2X) video data mainly relies on multi-source terminals such as vehicle-mounted cameras and roadside monitoring equipment. Data transmission is achieved through vehicle-to-vehicle and vehicle-to-road communication methods, while storage mostly adopts centralized servers or distributed database architectures.

[0004] However, in practical use, it still has some drawbacks. For example, traditional storage methods often use a centralized architecture, which poses a single point of failure risk and is vulnerable to hacker attacks that could lead to data tampering or leakage. The encryption mechanisms used in video data transmission are mostly static key management. Once the key is leaked, a large amount of sensitive data can be illegally obtained. Furthermore, existing technologies lack effective data evidence storage mechanisms, and video data may be maliciously tampered with during storage and transmission. It is also difficult to trace the modification records and sources of the data. In scenarios such as traffic accident liability determination and insurance claims, the credibility of the data is difficult to guarantee, which can easily lead to disputes. In addition, existing technologies have strong correlations with multi-source information such as networked video data, sensor data, and environmental data. However, traditional technologies often use single data type analysis and fail to achieve deep integration of multimodal data. Data analysis models often rely on empirical rules or simple statistical methods, resulting in low accuracy in predicting traffic events and low efficiency in detecting abnormal behavior. At the same time, there are data barriers between traffic management departments, insurance companies, vehicle manufacturers, and other institutions. Traditional data sharing models require third-party intermediaries or complex interface connections, which result in high data transmission latency, high communication overhead, and chaotic access control, making it difficult to meet the needs of cross-regional and cross-institutional collaborative applications. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a blockchain-based evidence storage and secure transmission system for video data in a vehicle-to-everything (V2X) environment, which addresses the problems mentioned in the background section through the following solutions.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based evidence storage and secure transmission system for video data in a vehicle-to-everything (V2X) environment, comprising a data acquisition module, a data processing module, a data analysis module, a blockchain evidence storage module, and an application port; The data acquisition module is used to collect multi-source data according to the deployed acquisition devices; The data processing module is used to perform data encryption and feature extraction on the multi-source data collected by the data acquisition module; The data analysis module is used to construct a dynamic decision model based on the extracted features using a Markov decision process and to perform anomaly detection. The blockchain evidence storage module is used to build a consortium blockchain and store data evidence. The application ports include traffic management application ports, insurance claims application ports, and vehicle manufacturer application ports, which are used to output all information obtained by the system to the application system.

[0007] Preferably, the deployment method of the acquisition equipment is as follows: a 1080P resolution vehicle-mounted high-definition camera with a lens focal length of 2.8mm, a horizontal field of view of 120°, and a minimum illumination of 0.01Lux is installed on the inside of the vehicle's windshield to ensure clear imaging in low-light environments; a rear-facing camera with parameters consistent with the front-facing camera is installed at the license plate frame position in the vehicle's trunk; a driving recorder is integrated into the rearview mirror, supporting 1080P video recording; simultaneously, the vehicle's OBD interface is connected to an accelerometer, gyroscope, and vehicle speed sensor to collect vehicle motion status information in real time; in the road infrastructure, one roadside unit is deployed every 500 meters in key road sections, and three roadside units are deployed at intersections to form a triangular monitoring area; the roadside unit is equipped with a 2-megapixel high-definition monitoring camera, a temperature and humidity sensor, and a visibility sensor; The method for acquiring the multi-source data is as follows: the vehicle-mounted video device records video at a frame rate of 30 frames per second, generating one MP4 format video file every 60 seconds, named according to the rule "VID_Vehicle VIN_YYYYMMDD_HHMMSS_Serial Number.mp4". The sensor acquires data at a frequency of 100Hz and generates a CSV format file containing timestamp, acceleration, angular velocity, and vehicle speed fields. The roadside unit camera generates video segments at 30-second intervals, and simultaneously acquires environmental data and BSM messages broadcast by the vehicle. The timestamp is generated based on the GPS timing module, and the time synchronization error between the vehicle-mounted and roadside equipment is ≤50μs.

[0008] Preferably, the data encryption method is as follows: the video data is encrypted using the SM4 algorithm. The key generation module generates a 32-byte seed using the SHA-256 hash device MAC address + hardware UUID, and derives the SM4 key using the elliptic curve algorithm. The SM4 key is transmitted using SM2 asymmetric encryption. The public key is pre-stored in the vehicle-mounted T-BOX and the roadside unit security chip. The video is encrypted in blocks of a fixed size of 1MB. The block encryption order corresponds to the storage offset. Each block is appended with a 16-byte random number and a 32-byte timestamp. The receiving end verifies the uniqueness of the random number and the validity of the timestamp. The SM4 algorithm has a key length of 128 bits, a block length of 128 bits, and an encryption mode of CBC. The SM2 asymmetric encryption public key is 256 bits, the private key is 256 bits, and the signature algorithm is SM3withSM2; The uniqueness of the random number means that there is no repetition within the last 10 minutes; The validity of the timestamp refers to a time difference of ≤300 seconds from the received time.

[0009] Preferably, the feature extraction method is as follows: the vehicle edge computing module uses NVIDIA Jetson Nano and runs the MobileNetV2 model to extract features from the video. The input size of the model is 224×224, the weight file size is 14MB, and the processing logic is to extract features once every 10 frames. The license plate recognition process consists of two steps: First, the YOLOv5s model is used with an input size of 640×640 and a confidence threshold of 0.85 to locate the license plate area. Then, the CRNN model is used to complete character recognition, and the ResNet18 lightweight model is used for vehicle classification. In terms of driving trajectory calculation, the ORB algorithm is used to match feature points between frames. The pixel displacement is calculated and combined with GPS data to convert it into a geographic coordinate trajectory. The rules for calculating sensor data features are as follows: Rate of change of acceleration: calculated using the formula (current acceleration - acceleration in the previous 100 ms) / 0.1 s; Speed ​​change trend: Calculate the first derivative using a 5-second sliding window; Steering angle: calculated based on the Z-axis integration of the gyroscope, with a sampling period of 10ms; Ultimately, the feature data is stored in JSON format and indexed in association with the video file hash.

[0010] Preferably, the state space S of the dynamic decision-making model is designed as a six-dimensional vector space, integrating vehicle motion state, environmental perception information, and time series features: Video features: Vehicle position coordinates (x, y) are introduced for precise positioning, and a spatial relationship matrix is ​​constructed by combining vehicle speed v and distance d from the vehicle in front; Sensor features: Real-time capture of vehicle dynamics using acceleration a and steering angle θ; Time characteristics: Time t is discretized into time slices with 1-second intervals to ensure that state updates are synchronized with the video stream transmission frame rate; The calculation of the state transition probability P(s′|s,a) is based on big data statistical analysis. A database of (s,a,s′) triples is constructed using over 100,000 real driving samples collected from in-vehicle terminals. Specifically, a sliding window algorithm is used to preprocess historical data, eliminating outlier interference, and then the conditional probability formula is applied. Dynamically update the transition probability matrix; The reward function R(s,a) is as follows: Incentives for safe behavior: When a vehicle maintains a safe following distance (d≥v×1.5), a reward of +5 is given to encourage safe driving. Penalties for dangerous behavior: For speeding (v > speed limit) and rapid acceleration (a > 2 m / s²) 2 For high-risk behaviors such as [missing information], penalties of -10 and -5 are imposed respectively to guide the system to avoid potential accidents; Normal behavior neutrality: Under normal driving conditions (R(s,a)=0), maintain strategy stability; The model is solved using a value iteration algorithm, with the iteration precision set accordingly. The double termination conditions of 0.01 and a maximum iteration count of 1000 are used in each iteration, through the Bellman equation: Update the value function, where the discount factor γ = 0.9 balances immediate returns and long-term returns. When the difference between the value functions of two consecutive iterations is less than... The algorithm converges and outputs the optimal strategy π when the maximum number of iterations is reached. ∗ (s) provides a basis for decision-making regarding the real-time transmission of video data.

[0011] Preferably, the specific steps of the anomaly detection are as follows: A1: Introduce a sliding time window mechanism. Within a 10-second time window, collect real-time status data of the vehicle-to-everything (V2X) device at 500ms sampling intervals, and then use the formula... Calculate the deviation between the real-time state and the optimal policy, where s real,i s represents the real-time state parameter at the i-th sampling time. opt,i Let s be the theoretical optimal state value at the corresponding time. opt,max To determine the maximum value of the optimal state parameter from historical data, a threshold D is set. threshold =0.3; A2: Construct a predictive architecture based on the fusion of a Long Short-Term Memory (LSTM) network and a Logistic Regression model. The state-space features of the Markov decision process are input into an LSTM network for temporal feature extraction. The LSTM output and the original MDP state features are then input into a Logistic Regression model to calculate the probability of traffic events, outputting the probability value P. event The model parameters were optimized through cross-validation, and a trigger threshold P was set. threshold =0.7, when the predicted probability exceeds this threshold, a high-risk traffic incident is determined to exist; A3: When the deviation value D exceeds D threshold or the probability P of a traffic incident event Greater than P threshold When the anomaly warning mechanism is triggered, the generated warning message contains structured data: anomaly type, timestamp accurate to milliseconds, latitude and longitude coordinates based on the BeiDou satellite positioning system, and anomaly feature hash value calculated by the SHA-256 algorithm. It is broadcast and transmitted using the PC5 interface of LTE-V2X technology, with a stable transmission rate of 2Mbps. At the same time, forward error correction coding technology is introduced to improve the transmission reliability in complex electromagnetic environments, ensuring that the warning information covers all connected vehicles within a radius of 500 meters within 100ms.

[0012] Preferably, the method for building the consortium blockchain is as follows: The consortium blockchain node network consists of seven nodes, comprised of transportation bureaus, insurance companies, and car manufacturers. It strictly adheres to the fault tolerance mechanism of the Practical Byzantine Fault Tolerance Algorithm, allowing for a maximum of f=2 failed nodes to ensure the system continues to operate normally even when some nodes malfunction. Each node is equipped with a high-performance server, specifically configured as follows: Processor: Intel Xeon E5-2680v4 twelve-core processor; Memory: 32GB high-speed DDR4 memory; Storage: 1TB SSD solid-state drive; Operating system: Ubuntu 20.04 LTS; Blockchain platform: Hyperledger Fabric 2.4.

[0013] Preferably, the specific operation of the data storage is as follows: The video data hash calculation uses the SHA-256 algorithm to construct a dual hashing mechanism: first, the complete video file is hashed to generate an initial hash value, then the video feature information is concatenated with the initial hash value, and the SHA-256 operation is performed again to obtain the final dual hash value; The evidence storage transaction structure adopts a standardized field design: txID: A 32-byte UUID, used as a unique identifier for a transaction, generated based on the RFC4122 standard; dataHash: A 64-byte double hash value that stores the double hash result; timestamp: UTC timestamp, records the time of evidence storage, using Unix timestamp format; signer: Node certificate hash, generated by hashing the digital certificates of participating nodes, enabling traceability of operation identity; payload: Video feature summary JSON; The smart contract is developed using Solidity 0.8.17 and deployed on the Hyperledger Fabric blockchain channel, comprising three core functional modules: saveEvidence: Receives video data hash and feature information, verifies the signature, and stores the transaction in the blockchain; queryEvidence: Supports querying evidence records by txID or dataHash, returning complete transaction information; verifyEvidence: Recalculates the hash value of the incoming data, compares it with the on-chain evidence, and returns the verification result; The block structure follows a layered design principle: Block header: Previous block hash: Stores the hash value of the previous block to build a chain structure; Merkle root: The hash root of all transactions in the current block generated by the Merkle tree algorithm; Timestamp: Records the time when a block was generated; Block body: Stores a list of all evidence-based transactions within this block; the maximum size of a single block is 2MB. Block metadata (256 bytes): Contains a list of node signatures that participated in the block consensus, used to verify the legitimacy of the block.

[0014] Preferably, the traffic management application port refers to the traffic management platform querying blockchain data via a RESTful API, with the interface address / api / v1 / traffic / evidence, the request method POST, and parameters including time range, geofence, and vehicle VIN. The insurance claims application port refers to the insurance company's claims system accessing the stored data through the blockchain node SDK and verifying the consistency between the dataHash returned by the interface and the locally calculated value. The vehicle manufacturer application port refers to the vehicle manufacturer's data platform obtaining data from the previous month through a batch interface on the 1st of each month, including: highway fuel consumption, braking distance, and steering accuracy.

[0015] The technical effects and advantages of this invention are as follows: 1. This invention employs the SM4 symmetric encryption algorithm to encrypt video data in blocks, combined with the SM2 asymmetric encryption algorithm to manage keys. Through a dynamic key update mechanism, it effectively prevents key leakage and data tampering. The dual hash notarization mechanism further ensures data integrity during storage and transmission, resolving the security vulnerabilities of traditional static encryption and centralized storage. 2. This invention is based on a notarization system built on the Hyperledger Fabric consortium blockchain. Through block hash linking and smart contract automatic execution of notarization logic, information such as the acquisition time, transmission path, and modification records of video data are permanently traceable. Each notarization transaction contains a unique txID, node signature, and timestamp. Any illegal modification to the data will result in hash value mismatch, ensuring the credibility of the data in scenarios such as traffic accident determination and insurance claims. 3. This invention constructs a multimodal fusion Markov decision process model, which deeply integrates video features, sensor features and time features. It quantifies driving behavior risks through state transition probability matrix and reward function. Compared with traditional single data model, it improves the accuracy of anomaly detection, reduces the false alarm rate, and can more accurately predict traffic events and identify dangerous driving behaviors. 4. This invention designs a two-layer blockchain architecture, which realizes cross-domain data routing and permission management through dual-chain collaborative smart contracts. The global chain is responsible for cross-institutional data synchronization, while the local chain prioritizes processing local requests, so that the response time for cross-regional data queries is controlled within 500ms. At the same time, the attribute-based access control model ensures that different institutions can only obtain data within their authorized scope, thus balancing the needs of data sharing and privacy protection. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall structure of the present invention. Detailed Implementation

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

[0018] As attached Figure 1 The blockchain-based evidence storage and secure transmission system for video data in a connected vehicle environment, as shown, includes a data acquisition module, a data processing module, a data analysis module, a blockchain evidence storage module, and an application port. The data acquisition module is used to collect multi-source data according to the deployed acquisition devices; The deployment method of the data acquisition equipment is as follows: A 1080P resolution in-vehicle high-definition camera with a lens focal length of 2.8mm, a horizontal field of view of 120°, and a minimum illumination of 0.01Lux is installed inside the vehicle's windshield to ensure clear imaging in low-light environments; a rear-facing camera with the same parameters as the front-facing camera is installed in the license plate frame position in the vehicle's trunk; a dashcam is integrated into the rearview mirror, supporting 1080P video recording; simultaneously, an accelerometer (model ADXL345) and a gyroscope (model MPU605) are connected to the vehicle's OBD interface. 0) Vehicle speed sensor (Hall effect, accuracy ±0.5km / h) collects vehicle motion status information in real time. In road infrastructure, one roadside unit (RSU) is deployed every 500 meters in key road sections, and three roadside units are deployed at intersections to form a triangular monitoring area. The roadside unit is equipped with a 2-megapixel high-definition surveillance camera (resolution 1920×1080, frame rate 25fps, lens focal length 4-16mm electric zoom) and a temperature and humidity sensor (model SHT30) and a visibility sensor (model VaisalaPWD22). The method for acquiring the multi-source data is as follows: The vehicle-mounted video device records video at a frame rate of 30 frames per second, generating one MP4 format video file every 60 seconds, named "VID_Vehicle VIN_YYYYMMDD_HHMMSS_Serial Number.mp4"; the sensor acquires data at a frequency of 100Hz, generating a CSV format file containing timestamps, acceleration (X / Y / Z axes), angular velocity (X / Y / Z axes), and vehicle speed fields; the roadside unit camera generates video segments at 30-second intervals (named "RSU_Device ID_YYYYMMDD_HHMMSS_Serial Number.mp4"); simultaneously, environmental data (sampling frequency 1Hz) and BSM messages broadcast by the vehicle (received once every 100ms) are acquired; the timestamp is generated based on the GPS timing module (synchronization accuracy 10μs); the time synchronization error between the vehicle-mounted and roadside equipment is ≤50μs.

[0019] The data processing module is used to perform data encryption and feature extraction on the multi-source data collected by the data acquisition module; The data encryption method is as follows: The video data is encrypted using the SM4 algorithm. The key generation module generates a 32-byte seed using the SHA-256 hash device MAC address + hardware UUID. The SM4 key is derived using the elliptic curve algorithm (SM2 curve parameters). The SM4 key is transmitted using SM2 asymmetric encryption. The public key is pre-stored in the vehicle-mounted T-BOX and the roadside unit security chip (model Huada HC32L136). The video is encrypted in blocks of a fixed size of 1MB. The block encryption order corresponds to the storage offset. Each block is appended with a 16-byte random number and a 32-byte timestamp (UTC format). The receiving end verifies the uniqueness of the random number and the validity of the timestamp. The SM4 algorithm has a key length of 128 bits, a block length of 128 bits, and an encryption mode of CBC. The SM2 asymmetric encryption public key is 256 bits, the private key is 256 bits, and the signature algorithm is SM3withSM2; The uniqueness of the random number means that there is no repetition within the last 10 minutes; The validity of the timestamp refers to a difference of ≤300 seconds from the received time; The feature extraction method is as follows: The vehicle edge computing module uses NVIDIA Jetson Nano and runs the MobileNetV2 model to extract features from the video. The input size of the model is 224×224, the weight file size is 14MB, and the processing logic is to extract features once every 10 frames. The license plate recognition process consists of two steps: First, the YOLOv5s model is used with an input size of 640×640 and a confidence threshold of 0.85 to locate the license plate area. Then, the CRNN model is used to complete character recognition, with an accuracy of no less than 99.5%. For vehicle classification, the ResNet18 lightweight model is used to achieve a Top-1 accuracy of no less than 95%. In terms of driving trajectory calculation, the ORB algorithm is used to match feature points between frames to ensure that the number of feature points in each frame is no less than 500. The pixel displacement is calculated and combined with GPS data to convert it into a geographic coordinate trajectory, with the error controlled within 3 meters. The rules for calculating sensor data features are as follows: Rate of change of acceleration: calculated using the formula (current acceleration - acceleration in the previous 100 ms) / 0.1 s; Speed ​​change trend: Calculate the first derivative using a 5-second sliding window; Steering angle: calculated based on the Z-axis integration of the gyroscope, with a sampling period of 10ms; Ultimately, the feature data is stored in JSON format and indexed in association with the video file hash.

[0020] The data analysis module is used to construct a dynamic decision model based on the extracted features using a Markov decision process and to perform anomaly detection. The state space S of the dynamic decision-making model is designed as a six-dimensional vector space, integrating vehicle motion state, environmental perception information, and time series features: Video features: Vehicle position coordinates (x, y) are introduced for precise positioning. A spatial relationship matrix is ​​constructed by combining vehicle speed v and distance d from the vehicle in front, providing basic data for video transmission path planning. Sensor features: Real-time capture of vehicle dynamics using acceleration 'a' and steering angle 'θ' to aid in assessing driving stability and potential risks; Temporal features: Time t is discretized into time slices with 1-second intervals to ensure that state updates are synchronized with the video stream frame rate, thereby improving the timeliness of the model; The calculation of the state transition probability P(s′|s,a) is based on big data statistical analysis. A database of (s,a,s′) triples is constructed using over 100,000 real driving samples collected from in-vehicle terminals. Specifically, a sliding window algorithm is used to preprocess historical data, eliminating outlier interference, and then the conditional probability formula is applied. The transition probability matrix is ​​dynamically updated to ensure that the model adapts to complex road condition changes; The reward function R(s,a) is designed following the risk-reward balance principle, and the strategy is optimized by quantifying the safety of driving behavior, as detailed below: Incentives for safe behavior: When a vehicle maintains a safe following distance (d≥v×1.5), a reward of +5 is given to encourage safe driving. Penalties for dangerous behavior: For speeding (v > speed limit) and rapid acceleration (a > 2 m / s²) 2 For high-risk behaviors such as [missing information], penalties of -10 and -5 are imposed respectively to guide the system to avoid potential accidents; Normal behavior neutrality: Under normal driving conditions (R(s,a)=0), maintain strategy stability; The model is solved using a value iteration algorithm, with the iteration precision set accordingly. The double termination conditions of 0.01 and a maximum iteration count of 1000 are used in each iteration, through the Bellman equation: Update the value function, where the discount factor γ = 0.9 balances immediate returns and long-term returns. When the difference between the value functions of two consecutive iterations is less than... The algorithm converges and outputs the optimal strategy π when the maximum number of iterations is reached. ∗ (s), providing a basis for decision-making in the real-time transmission of video data; The specific steps for anomaly detection are as follows: A1: Introduce a sliding time window mechanism. Within a 10-second time window, collect real-time status data of the vehicle-to-everything (V2X) device at 500ms sampling intervals, and then use the formula... Calculate the deviation between the real-time state and the optimal policy, where s real,i s represents the real-time state parameter at the i-th sampling time. opt,i Let s be the theoretical optimal state value at the corresponding time. opt,max To determine the maximum value of the optimal state parameter from historical data, a threshold D is set. threshold =0.3, this threshold is calculated based on the 3σ criterion, where σ is the standard deviation of the normal driving sample deviation, which is obtained by statistical analysis of 100,000 normal driving state data; A2: Construct a predictive architecture based on the fusion of a Long Short-Term Memory (LSTM) network and a Logistic Regression model. The state-space features of the Markov decision process are input into an LSTM network for temporal feature extraction. The LSTM output and the original MDP state features are then input into a Logistic Regression model to calculate the probability of traffic events, outputting the probability value P. event The model parameters were optimized through cross-validation, and a trigger threshold P was set. threshold =0.7, when the predicted probability exceeds this threshold, a high-risk traffic incident is determined to exist; A3: When the deviation value D exceeds D threshold or the probability P of a traffic incident event Greater than P threshold When triggered, the anomaly warning mechanism is activated, and the generated warning message contains structured data: anomaly type (such as emergency braking, road obstacles, traffic accidents, etc., preset classification), timestamp accurate to milliseconds, latitude and longitude coordinates based on the BeiDou satellite positioning system, and anomaly feature hash value calculated by the SHA-256 algorithm. It is broadcast and transmitted using the PC5 interface of LTE-V2X technology, with a transmission rate stable at 2Mbps. At the same time, forward error correction coding technology is introduced to improve the transmission reliability in complex electromagnetic environments, ensuring that the warning information covers all connected vehicles within a radius of 500 meters within 100ms.

[0021] The blockchain evidence storage module is used to build a consortium blockchain and store data evidence. The method for building the consortium blockchain is as follows: The consortium blockchain node network consists of seven nodes: the Transportation Bureau (2 core regulatory nodes), insurance companies (3 business participation nodes), and automakers (2 data provider nodes). It strictly adheres to the fault tolerance mechanism requirements of the Practical Byzantine Fault Tolerance (PBFT) algorithm (allowing for a maximum of f=2 failed nodes) to ensure the system can still operate normally even when some nodes fail. Each node is equipped with a high-performance server, specifically configured as follows: Processor: Intel Xeon E5-2680v4 twelve-core processor, providing powerful computing capabilities to meet the complex blockchain computing requirements; Memory: 32GB high-speed DDR4 memory, ensuring smooth multitasking; Storage: 1TB SSD solid-state drive, enabling fast data read and write and reducing I / O latency; Operating system: Ubuntu 20.04LTS, which supports the operation of blockchain services due to its stability, security and rich open source ecosystem; Blockchain platform: Hyperledger Fabric 2.4, based on a modular architecture design, supports flexible smart contract deployment and privacy protection; Regarding the parameter configuration of the PBFT consensus mechanism: View switching timeout: Set to 3 seconds to ensure that view switching can be triggered quickly in the event of a master node failure, thus maintaining consensus continuity; Prepare message propagation time: control it to ≤500ms to reduce message transmission latency and improve consensus efficiency; Block interval: fixed at 5 seconds to balance data processing speed and network load; Consensus delay: ≤1 second, to ensure timely transaction confirmation; The node security system uses X.509 digital certificates (issued based on the national cryptographic SM2 algorithm) for identity authentication, enabling two-way trusted communication between nodes. The access control is based on the Attribute-Based Access Control model. By defining node attributes (such as organization type and data permission tags), access policies are dynamically generated to ensure that different nodes can only access data resources related to their business, thus achieving fine-grained data access control. The specific steps for data storage are as follows: The video data hash calculation adopts the SHA-256 algorithm to build a dual hashing mechanism: First, the complete video file is hashed to generate an initial hash value. Then, the video feature information (encapsulated in JSON format, including metadata such as resolution, frame rate, and keyframe timestamps) is concatenated with the initial hash value, and the SHA-256 operation is performed again to obtain the final dual hash value. This design can effectively resist data tampering attacks and ensure the integrity of video content and feature information. The evidence storage transaction structure adopts a standardized field design: txID: A 32-byte UUID, used as a unique identifier for a transaction, generated based on the RFC4122 standard to ensure global uniqueness; dataHash: A 64-byte double hash value that stores the double hash result of the above video data; timestamp: UTC timestamp, accurately records the time of evidence storage, using Unix timestamp format (number of seconds since 1970-01-01T00:00:00Z). signer: Node certificate hash, generated by hashing the digital certificates of participating nodes, enabling traceability of operation identity; Payload: A JSON summary of video features, containing structured metadata such as {"resolution":"1920x1080","fps":30,"keyframe_timestamps":[0,15,30]}; The smart contract is developed using Solidity 0.8.17 and deployed on the Hyperledger Fabric blockchain channel, comprising three core functional modules: saveEvidence: Receives video data hash and feature information, verifies the signature, and stores the transaction in the blockchain; queryEvidence: Supports querying evidence records by txID or dataHash, returning complete transaction information; verifyEvidence: Recalculates the hash value of the incoming data, compares it with the on-chain evidence, and returns the verification result; The block structure follows a layered design principle: Block header (80 bytes): Previous block hash: Stores the hash value of the previous block to build a chain structure; Merkle root: The hash root of all transactions in the current block generated by the Merkle tree algorithm; Timestamp: Records the time when a block was generated; Block body: Stores a list of all evidence-based transactions within this block; the maximum size of a single block is 2MB. Block metadata (256 bytes): Contains a list of node signatures that participated in the block consensus, used to verify the legitimacy of the block.

[0022] The application ports include traffic management application ports, insurance claims application ports, and vehicle manufacturer application ports, which are used to output all information obtained by the system to the application system. The traffic management application port refers to the traffic management platform querying blockchain data via a RESTful API, with the interface address / api / v1 / traffic / evidence, the request method POST, and parameters including time range, geofence, and vehicle VIN. The insurance claims application port refers to the insurance company's claims system accessing the stored data through the blockchain node SDK (JavaSDKv2.2) and verifying the consistency between the dataHash returned by the interface and the locally calculated value. The vehicle manufacturer application port refers to the vehicle manufacturer's data platform obtaining the previous month's data on the 1st of each month through the batch interface ( / api / v1 / manufacture / batchQuery), including: high-speed fuel consumption (120km / h constant speed condition), braking distance (100-0km / h), and steering accuracy (snake test deviation).

[0023] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain storage and secure transmission system for video data in a vehicle Internet of Things environment, characterized in that, Comprise: Data acquisition module, data processing module, data analysis module, blockchain storage module and application port; The data acquisition module is used for collecting multi-source data according to the deployed acquisition equipment; The data processing module is used for data encryption and feature extraction of the multi-source data collected by the data acquisition module; The data analysis module is used for constructing a dynamic decision model and performing anomaly detection according to the extracted features using Markov decision process; The blockchain storage module is used for building a consortium chain and performing data storage; The application port includes traffic management application port, insurance claim application port and vehicle manufacturer application port, which is used for outputting all information obtained by the system to the application system. 2.The system of claim 1, wherein: The deployment method of the acquisition equipment is as follows: a 1080P resolution vehicle-mounted high-definition camera is installed on the inner side of the front windshield of the vehicle, the lens focal length is 2.8mm, the horizontal field of view is 120°, and the minimum illumination is 0.01Lux, which ensures clear imaging in low illumination environment; a rear camera is installed at the license plate frame position of the vehicle trunk, and the parameters are consistent with the front camera; a car rearview mirror integrated with a car data recorder is supported, which supports 1080P video recording, at the same time, an acceleration sensor, a gyroscope and a vehicle speed sensor are connected to the vehicle OBD interface to collect vehicle motion state information in real time, in the road infrastructure, 1 roadside unit is deployed every 500 meters on the key road section, and 3 roadside units are deployed at the intersection to form a triangular monitoring area; the roadside unit is equipped with a 2000 pixel high-definition monitoring camera and a temperature and humidity sensor, a visibility sensor; The multi-source data acquisition method is as follows: the vehicle-mounted video equipment records video at a frame rate of 30 frames / second, generates 1 MP4 format video file every 60 seconds, the naming rule is "VID_ vehicle VIN code_ YYYYMMDD_HHMMSS_ serial number.mp4", the sensor collects data at a frequency of 100Hz to generate a CSV format file containing timestamp, acceleration, angular velocity and vehicle speed fields, the roadside unit camera generates video clips at an interval of 30 seconds, and simultaneously collects environmental data and BSM messages broadcast by the vehicle, the timestamp is generated based on the GPS timing module, and the time synchronization error of the vehicle-mounted and roadside equipment is less than or equal to 50us. 3.The system of claim 1, wherein: The data encryption method is as follows: SM4 algorithm is used for video data encryption, the key generation module generates a 32 byte seed by hashing the device MAC address+hardware UUID through SHA-256, the SM4 key is derived through elliptic curve algorithm, the SM4 key is transmitted using SM2 asymmetric encryption, the public key is pre-stored in the vehicle-mounted T-BOX and the roadside unit security chip, the video is encrypted in blocks with a fixed size of 1MB, the block encryption order corresponds to the storage offset, 16 byte random number and 32 byte timestamp are attached to each block, and the receiving end verifies the uniqueness of the random number and the validity of the timestamp; The key length of the SM4 algorithm is 128bit, the block length is 128bit, and the encryption mode is CBC; The public key of the SM2 asymmetric encryption is 256bit, the private key is 256bit, and the signature algorithm is SM3 with SM2; The uniqueness of the random number means that there is no repetition within 10 minutes; The timestamp validity refers to a time difference of ≤300 seconds from the receiving time. 4.The system of claim 1, wherein: The feature extraction method is as follows: the vehicle-mounted edge computing module selects NVIDIA Jetson Nano, and runs the MobileNetV2 model to extract features from the video. The input size of the model is 224×224, the weight file size is 14 MB, and the processing logic is to extract features once every 10 frames. The license plate recognition process is divided into two steps: first, the YOLOv5s model is used to locate the license plate area with an input size of 640×640 and a confidence threshold of 0.85, and then the CRNN model is used to complete character recognition. The ResNet18 lightweight model is used for vehicle type classification. In terms of driving trajectory calculation, the ORB algorithm is used for inter-frame feature point matching, the pixel displacement is calculated, and the GPS data is converted into a geographic coordinate trajectory. The sensor data feature calculation rules are as follows: Acceleration change rate: calculated by the formula (current acceleration - previous 100 ms acceleration) / 0.1 s; Speed change trend: first-order derivative is calculated using a 5-second sliding window; Steering angle: calculated based on the integral of the gyroscope Z-axis, with a sampling period of 10 ms; Finally, the feature data is stored in JSON format and indexed with the video file hash. 5.The system of claim 1, wherein: The state space S of the dynamic decision model is designed as a six-dimensional vector space, which integrates vehicle motion state, environmental perception information, and time series features: Video Features: Introduce vehicle position coordinates (x, y) for precise positioning, and combine vehicle speed v and front vehicle distance d to construct a spatial relationship matrix; Sensor features: Real-time capture of vehicle dynamics state through acceleration a and steering angle θ; Time features: Discretize time t into 1-second intervals to ensure that state updates are synchronized with video stream transmission frame rate; The calculation of the state transition probability P(s' | s, a) is based on big data statistical analysis. A database of (s, a, s') triplets is constructed based on 100,000+ real driving samples collected by the vehicle terminal. In specific implementation, a sliding window algorithm is used to pre-process the historical data. After eliminating the interference of abnormal values, the state transition probability matrix is dynamically updated according to the conditional probability formula a dynamic update transition probability matrix; The reward function R(s, a) is as follows: Safety behavior incentive: When the vehicle maintains a safe distance (d ≥ v × 1.5), a +5 reward value is given to encourage safe driving; Dangerous behavior penalty: -10 and -5 penalty are applied to the reward function for high-risk behaviors such as speeding (v>limit speed), sudden acceleration (a>2m / s 2 ), etc. to guide the system to avoid potential accidents. Normal behavior neutral: In normal driving state (R(s, a) = 0), maintain policy stability; The model is solved by value iteration algorithm, setting the double termination condition of iteration precision =0.01 and maximum iteration number 1000 times, in each iteration, through the Bellman equation: Update the value function, where the discount factor γ = 0.9 balances immediate rewards with long-term returns, when the difference in value functions between two consecutive iterations is less than Or when the maximum number of iterations is reached, the algorithm converges and outputs the optimal policy π ∗ (s), which provides the basis for decision-making for real-time transmission of video data. 6.The system of claim 1, wherein: The specific steps of the anomaly detection are as follows: A1: Introduce a sliding time window mechanism, collect real-time state data of the Internet of Vehicles device in a time window of 10 seconds with a sampling interval of 500 ms, calculate the deviation value of the real-time state and the optimal strategy by the formula s real,i represents the real-time state parameter at the i-th sampling time, s opt,i is the theoretical optimal state value at the corresponding time, s opt,max is the maximum value of the optimal state parameter in the historical data, and the threshold value D threshold =0.3; A2: A prediction architecture based on the fusion of long short-term memory network and logistic regression model is constructed. The state space features of Markov decision process are input into the LSTM network for time series feature extraction. The LSTM output result and the original MDP state feature are jointly input into the logistic regression model for traffic event probability calculation, and the probability value P is output event , the model parameters are optimized through cross-validation, the trigger threshold P is set threshold = 0.7, and when the prediction probability exceeds the threshold, it is determined that there is a high-risk traffic event; A3: When the deviation value D exceeds D threshold or traffic event probability P event greater than P threshold , trigger the abnormal early warning mechanism, the generated warning message contains structured data: abnormal type, accurate to millisecond timestamp, longitude and latitude position coordinates based on Beidou satellite positioning system, and abnormal feature hash value calculated by SHA-256 algorithm, broadcast transmission through PC5 interface of LTE-V2X technology, transmission rate stable at 2Mbps, while introducing forward error correction coding technology, improve transmission reliability in complex electromagnetic environment, ensure that the warning information covers all networked vehicles within a radius of 500 meters within 100ms. 7.The system of claim 1, wherein: The construction method of the alliance chain is as follows: The alliance chain node network is composed of traffic departments, insurance companies, and vehicle manufacturers, a total of 7 nodes, strictly following the fault tolerance mechanism requirements of the practical Byzantine fault tolerance algorithm, allowing the number of faulty nodes f = 2, ensuring that the system can still operate normally when some nodes are abnormal, and each node is deployed with a high-performance server with the following specific configurations: Processor: Intel Xeon E5-2680v4 twelve-core processor; Memory: 32 GB high-speed DDR4 memory; Storage: 1 TB SSD solid state drive; Operating system: Ubuntu 20.04 LTS; Blockchain platform: Hyperledger Fabric 2.

4. 8.The system of claim 1, wherein: The specific operation of the data notarization is as follows: The video data hash calculation adopts the SHA-256 algorithm to build a double hash mechanism: first, the complete video file is hashed to generate an initial hash value, then the video feature information is spliced with the initial hash value, and the SHA-256 operation is performed again to obtain the final double hash value; The evidence storage transaction structure adopts standardized field design: txID: 32-byte UUID, as the unique identifier of the transaction, generated based on the RFC4122 standard; dataHash: 64-byte double hash value, storing the double hash result; timestamp: UTC timestamp, recording the storage time, using Unix timestamp format; signer: node certificate hash, generated by hashing the digital certificate of the participating evidence storage node, realizing operation identity tracing; payload: video feature abstract JSON; The smart contract is developed based on Solidity 0.8.17 language and deployed on Hyperledger Fabric blockchain channel, containing three core functional modules: saveEvidence: receives video data hash and feature information, verifies the signature, and stores the transaction in the blockchain after verification; queryEvidence: supports querying evidence records by txID or dataHash, returning complete transaction information; verifyEvidence: re-computes the hash value of the input data and compares it with the on-chain evidence, returning the verification result; The block structure follows the hierarchical design principle: Block header: previous block hash: stores the hash value of the previous block, building a chain structure; Merkle root: the hash root of all transactions in the current block generated by the Merkle tree algorithm; timestamp: records the block generation time; Block body: stores all evidence storage transactions in this block, with a maximum capacity of 2MB per block; Block metadata (256 bytes): contains a list of node signatures participating in block consensus, used to verify the legality of the block. 9.The system of claim 1, wherein: The traffic management application port refers to the traffic management platform accessing the blockchain data through the RESTful API interface address / api / v1 / traffic / evidence, request method POST, parameters: time range, geofence, vehicle VIN; The insurance claim application port refers to the insurance company's claim system accessing the evidence storage data through the blockchain node SDK, verifying the consistency of the returned dataHash with the locally calculated value; The vehicle manufacturer application port refers to the vehicle data platform accessing the last month's data through a batch interface on the 1st of each month, including: high-speed fuel consumption, braking distance, and steering accuracy.

Images