Intelligent traffic charging data storage and traceability method based on block chain

Abstract

The invention discloses an intelligent traffic charging data storage and traceability method based on a block chain, and the method achieves the distributed storage and cross-department cooperative supervision of charging data through building a mixed chain structure comprising a main chain and a functional sub-chain. A dynamic data fragmentation technology is adopted to improve system throughput, and an improved PBFT consensus algorithm is combined to guarantee data consistency. A traceability system comprising data consanguinity tracking and a multi-party verification mechanism is innovatively designed, and rapid arbitration of charging dispute is supported. According to the scheme, the problems of data islands, tampering risks and the like existing in a traditional centralized charging system are effectively solved, and the traffic charging transparency and the operation efficiency are remarkably improved.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular relates to a method for storing and tracing intelligent transportation charging data based on blockchain. Background Art

[0002] With the rapid development of intelligent transportation systems, applications such as electronic toll collection and congestion pricing have become widespread nationwide. However, existing toll collection systems suffer from significant deficiencies in data management and traceability. Traditional Oracle database clusters reach performance limits when handling peak traffic volumes, with response latency increasing exponentially when QPS exceeds 12,000. Heterogeneous data standards used by different operators result in a 6.8% cross-system transaction reconciliation failure rate. Due to the lack of a unified interface between provincial toll clearing systems, 15% of individual interprovincial trips require manual review, extending the average settlement cycle to 72 hours. The current manual verification process exhibits significant flaws, requiring an average of 3.2 man-days to retrieve logs from six departments to resolve a toll dispute. In addition, 32% of cases cannot be traced due to incomplete evidence. Traditional systems struggle to integrate data from multiple sources in a timely manner, such as during traffic accidents and extreme weather events, leading to delayed dynamic adjustments. Summary of the Invention

[0003] In response to the above problems, the present invention provides a blockchain-based storage and traceability method for intelligent transportation charging data, which improves data processing efficiency and billing accuracy, reduces the amount of data exposure in the path verification process, and thus improves data traceability efficiency.

[0004] The present invention is achieved through the following technical solutions:

[0005] A method for storing and tracing intelligent transportation charging data based on blockchain, comprising the following steps:

[0006] S1: Data collection: Through the DSRC dedicated short-range communication protocol between the RSU and the on-board OBU device, the original charging data including vehicle ID, pass timestamp, path coordinate point sequence, and transaction amount are obtained in real time;

[0007] S2: Data preprocessing: Use a streaming computing engine to clean the raw data, extract key fields, and generate a charging data packet that complies with the ISO 12855 standard. The key fields include at least:

[0008] A1. Vehicle identification: license plate number or electronic tag number;

[0009] A2. Access path topology: Contains the geofence coordinates of at least three base stations;

[0010] A3. Rate calculation parameters: vehicle type classification code, discount type code;

[0011] A4. Data integrity check code: A hash digest generated based on SHA-256;

[0012] S3: Data shard storage: Based on the preset sharding rules, the standardized data packet is split into N data shards (N≥2), with each shard appended with a region identifier and a shard sequence code. When the real-time traffic volume in the target area exceeds the preset threshold, the shard size is automatically adjusted from 1MB to 512KB.

[0013] At the same time, double encryption is implemented for data shards containing sensitive payment information: the original data is first encrypted using the AES-256 algorithm, and then the shard metadata is encrypted using the national secret SM4 algorithm;

[0014] S4: Blockchain evidence storage: The encrypted data shards are uploaded to the main chain node for verification. The main chain node performs the following operations:

[0015] B1. Verify that the hash value of the data shard is consistent with the checksum generated in the preprocessing phase;

[0016] B2. Check the continuity of the fragment sequence code;

[0017] B3. Aggregate signatures of at least five verification nodes using the threshold signature algorithm;

[0018] The verified data shards are distributed to the corresponding sub-chain storage nodes according to the preset mapping rules, where:

[0019] Payment voucher shards are stored in the bank sub-chain;

[0020] The path trajectory fragments are stored in the traffic police sub-chain;

[0021] The device status shards are stored in the operator subchain;

[0022] S5: Smart Contract Execution: The automatic billing contract deployed on the bank sub-chain periodically performs the following operations:

[0023] C1. Call the oracle to obtain real-time traffic index and electricity price parameters;

[0024] C2. Calculate dynamic rates based on vehicle route length and congestion coefficient;

[0025] C3. Complete cross-chain fund settlement through atomic swap protocol;

[0026] The anomaly detection contract deployed on the Traffic Police subchain monitors the following anomaly patterns in real time:

[0027] D1. The timestamps of the same vehicle appear in reverse order at adjacent base stations;

[0028] D2. The number of transactions per unit time for a single OBU device exceeds the threshold;

[0029] D3. The path coordinate point sequence does not conform to the road topology constraints;

[0030] S6: Data traceability: When responding to traceability requests, execute the cross-chain retrieval protocol:

[0031] E1. Locate the storage location of the target data through the Merkle Patricia Trie index tree of the main chain;

[0032] E2. Use the improved lightweight cross-chain communication protocol to obtain shard data from related sub-chains;

[0033] E3. Verify the validity of the double-encrypted signature when reassembling shards;

[0034] The improved BLS threshold signature scheme is adopted in the traceability verification stage, requiring the car owner, bank, and traffic management department to jointly verify the authenticity of the data.

[0035] This invention utilizes a dynamic sharding strategy in conjunction with a multi-chain architecture to improve system throughput. During peak hours (Q > 800 vehicles / minute), the sharding granularity is automatically reduced to 512KB, reducing data packaging time from 2.3s in traditional solutions to 1.1s, thus reducing latency in cross-regional data queries. Incorporating a verifiable traceability mechanism based on zero-knowledge proofs, the Apache Flink-based preprocessing module significantly increases processing speed, significantly improving compared to traditional ETL tools. The error rate during the data cleaning phase is significantly reduced, significantly improving data traceability efficiency.

[0036] Preferably, the method for generating the spatiotemporal slicing rules in step S3 includes:

[0037] Establish a geographic space partitioning model based on the Voronoi diagram to divide the urban road network into multiple honeycomb storage areas;

[0038] The identifier of each storage area is generated by the GeoHash encoding of the longitude and latitude coordinates of the center point;

[0039] The shard granularity adjustment strategy meets the following requirements:

[0040] Where G is the fragment size, Q is the real-time traffic, and Qth is the preset traffic threshold.

[0041] Preferably, the main chain node verification process in step S4 adopts an improved practical Byzantine fault tolerance algorithm, sets a dynamic weight voting mechanism, allocates voting weights according to the historical verification accuracy of the node, introduces a credit decay factor α (0<α<1), and reduces the weight of nodes that fail verification continuously. The verification pass standard is:

[0042] Where w iis the weight of the i-th node, v i ∈{0,1} represents the verification result, W th is the passing threshold.

[0043] Preferably, the implementation of the anomaly detection contract in step S5 includes constructing a traffic pattern prediction model based on LSTM, with input dimensions including time, weather, and events; defining an anomaly scoring function: S = λ1·△t+λ2·△d+λ3·△ν;

[0044] Where Δ represents the deviation between the actual value and the predicted value, and λ is the weight coefficient of each parameter; when S exceeds the threshold, the transaction is automatically frozen and the arbitration process is triggered.

[0045] Preferably, the cross-chain retrieval protocol in step S6 adopts a layered encryption mechanism:

[0046] The first layer uses attribute-based encryption to control data access permissions;

[0047] The second layer applies a homomorphic encryption algorithm to protect the transaction amount field;

[0048] The third layer uses zero-knowledge proof to implement path privacy verification and meets the following conditions:

[0049] Hash(path) = h and

[0050] Where h is the path hash value and F is the total cost.

[0051] Preferably, the method further includes data storage optimization:

[0052] Establish a hot data cache pool and use a columnar storage structure for data generated in the past 24 hours. Perform the following operations on cold data that has not been accessed for more than 30 days:

[0053] F1. Use Snappy algorithm for lossless compression;

[0054] F2. Store the compressed package hash value on the blockchain;

[0055] F3. Original data is migrated to edge storage nodes.

[0056] Preferably, the data collection stage in step S1 includes a device authentication mechanism, specifically performing two-way authentication when the OBU and RSU establish communication:

[0057] G1.RSU sends a random number challenge containing timestamp T1;

[0058] G2.OBU uses the preset key to calculate the response code:

[0059] G3. Establish a temporary session key after authentication.

[0060] Compared with the prior art, the present invention has the following beneficial effects:

[0061] 1. The method of the present invention greatly improves data processing efficiency. The dynamic sharding mechanism increases system throughput. During peak hours (Q>800 vehicles / minute), the data packaging time is reduced from 2.3s in the traditional solution to 1.1s by automatically reducing the shard granularity to 512KB. After adopting the Voronoi geographic sharding strategy, the cross-region data query latency is reduced by 68% (from 850ms to 270ms). The preprocessing module based on Apache Flink can process 120,000 records per second, which is 40 times faster than traditional ETL tools. The bit error rate in the data cleaning stage is reduced from 0.15% to 0.02% (verified in accordance with the ISO 12855 standard).

[0062] 2. The present invention adopts AES-256+SM4 combined encryption to make the system highly secure and effectively prevent data leakage. It improves the fault tolerance by improving the PBFT consensus algorithm and enhances the Byzantine node tolerance rate by improving the dynamic weight mechanism.

[0063] 3. The billing accuracy of the present invention is high. It accesses five types of external data sources such as the Meteorological Bureau and the Traffic Command Center through an oracle. The dynamic rate adjustment response time is ≤5 seconds. The LSTM anomaly detection model is used to achieve precise risk control. The accuracy rate of identifying fraudulent behaviors such as cloned license plates and route forgery is 98.3%.

[0064] 4. This invention uses a cross-chain retrieval protocol to improve traceability efficiency and a zero-knowledge proof mechanism to balance privacy and supervision. The amount of data exposure during the path verification process is reduced, and only the hash value h and the total fee F are disclosed. The encryption strength of the owner's private information reaches the FIPS 140-2 Level 3 standard. DETAILED DESCRIPTION

[0065] The present invention is further illustrated by the following examples. In the examples, unless otherwise specified, the technical means used are conventional technical means in the art.

[0066] Example 1

[0067] A method for storing and tracing intelligent transportation charging data based on blockchain, comprising the following steps:

[0068] S1: Data collection: Through the DSRC dedicated short-range communication protocol between the RSU and the on-board OBU device, the original charging data including vehicle ID, pass timestamp, path coordinate point sequence, and transaction amount are obtained in real time;

[0069] S2: Data preprocessing: Use a streaming computing engine to clean the raw data, extract key fields, and generate a charging data packet that complies with the ISO 12855 standard. The key fields include at least:

[0070] A1. Vehicle identification: license plate number or electronic tag number;

[0071] A2. Access path topology: Contains the geofence coordinates of at least three base stations;

[0072] A3. Rate calculation parameters: vehicle type classification code, discount type code;

[0073] A4. Data integrity check code: A hash digest generated based on SHA-256;

[0074] S3: Data sharding storage: According to the preset sharding rules, the standardized data packet is split into N data shards (N≥2), and each shard is attached with a region identifier and a shard sequence code; when it is detected that the real-time traffic flow in the target area exceeds the preset threshold, the shard granularity is automatically adjusted from 1MB to 512KB; the method for generating the spatiotemporal sharding rules includes:

[0075] Establish a geographic space partitioning model based on the Voronoi diagram to divide the urban road network into multiple honeycomb storage areas;

[0076] The identifier of each storage area is generated by the GeoHash encoding of the longitude and latitude coordinates of the center point;

[0077] The shard granularity adjustment strategy meets the following requirements:

[0078] Where G is the fragment size, Q is the real-time traffic, and Qth is the preset traffic threshold.

[0079] At the same time, double encryption is implemented for data shards containing sensitive payment information: the original data is first encrypted using the AES-256 algorithm, and then the shard metadata is encrypted using the national secret SM4 algorithm;

[0080] S4: Blockchain evidence storage: The encrypted data shards are uploaded to the main chain node for verification. The main chain node performs the following operations:

[0081] B1. Verify that the hash value of the data shard is consistent with the checksum generated in the preprocessing phase;

[0082] B2. Check the continuity of the fragment sequence code;

[0083] B3. Aggregate signatures of at least five verification nodes using the threshold signature algorithm;

[0084] The verified data shards are distributed to the corresponding sub-chain storage nodes according to the preset mapping rules, where:

[0085] Payment voucher shards are stored in the bank sub-chain;

[0086] The path trajectory fragments are stored in the traffic police sub-chain;

[0087] The device status shards are stored in the operator subchain;

[0088] The main chain node verification process adopts an improved practical Byzantine fault-tolerant algorithm, sets a dynamic weight voting mechanism, allocates voting weights based on the node's historical verification accuracy, introduces a credit decay factor α (0<α<1), and reduces the weight of nodes that fail verification continuously. The verification pass criteria are:

[0089] Where w i is the weight of the i-th node, v i ∈{0,1} represents the verification result, W th is the passing threshold.

[0090] S5: Smart Contract Execution: The automatic billing contract deployed on the bank sub-chain periodically performs the following operations:

[0091] C1. Call the oracle to obtain real-time traffic index and electricity price parameters;

[0092] C2. Calculate dynamic rates based on vehicle route length and congestion coefficient;

[0093] C3. Complete cross-chain fund settlement through atomic swap protocol;

[0094] The anomaly detection contract deployed on the Traffic Police subchain monitors the following anomaly patterns in real time:

[0095] D1. The timestamps of the same vehicle appear in reverse order at adjacent base stations;

[0096] D2. The number of transactions per unit time for a single OBU device exceeds the threshold;

[0097] D3. The path coordinate point sequence does not conform to the road topology constraints;

[0098] The implementation of the anomaly detection contract includes building an LSTM-based traffic pattern prediction model with input dimensions including time, weather, and events; defining an anomaly scoring function: S = λ1·△t+λ2·△d+λ3·△ν;

[0099] Where Δ represents the deviation between the actual value and the predicted value, and λ is the weight coefficient of each parameter; when S exceeds the threshold, the transaction is automatically frozen and the arbitration process is triggered.

[0100] S6: Data traceability: When responding to traceability requests, execute the cross-chain retrieval protocol:

[0101] E1. Locate the storage location of the target data through the Merkle Patricia Trie index tree of the main chain;

[0102] E2. Use the improved lightweight cross-chain communication protocol to obtain shard data from related sub-chains;

[0103] E3. Verify the validity of the double-encrypted signature when reassembling shards;

[0104] The improved BLS threshold signature scheme is adopted in the traceability verification stage, requiring the car owner, bank, and traffic management department to jointly verify the authenticity of the data.

[0105] The cross-chain retrieval protocol uses a layered encryption mechanism:

[0106] The first layer uses attribute-based encryption to control data access permissions;

[0107] The second layer applies a homomorphic encryption algorithm to protect the transaction amount field;

[0108] The third layer uses zero-knowledge proof to implement path privacy verification and meets the following conditions:

[0109] Hash(path) = h and

[0110] Where h is the path hash value and F is the total cost.

[0111] Example 2

[0112] This embodiment is a further improvement based on the first embodiment, and specifically includes a data storage optimization method:

[0113] Establish a hot data cache pool and use a columnar storage structure for data generated in the past 24 hours. Perform the following operations on cold data that has not been accessed for more than 30 days:

[0114] F1. Use Snappy algorithm for lossless compression;

[0115] F2. Store the compressed package hash value on the blockchain;

[0116] F3. Original data is migrated to edge storage nodes.

[0117] Preferably, the data collection stage in step S1 includes a device authentication mechanism, specifically performing two-way authentication when the OBU and RSU establish communication:

[0118] G1.RSU sends a random number challenge containing timestamp T1;

[0119] G2.OBU uses the preset key to calculate the response code:

[0120] G3. Establish a temporary session key after authentication.

[0121] Application Example 1

[0122] Example 1 was tested on a Huawei Atlas 800 server cluster (32 nodes). The dataset was derived from real historical toll collection data from the transportation toll collection systems of five cities: Nanning, Liuzhou, Guilin, Fangchenggang, and Baise. A traditional centralized ETC system (version V2.3.5) was used for comparison. Table 1 shows a comparison of key technical indicators of these systems.

[0123] Table 1:

[0124] index Example 1 Traditional centralized ETC system Improvement Data throughput (TPS) 18500 6300 193.65％ Anomaly detection accuracy 98.8％ 82.5％ 16.3％

[0125] As can be seen from Table 1, the method of the present invention has higher data processing efficiency and higher anomaly detection accuracy than the traditional system.

[0126] The above embodiments are merely exemplary embodiments of the present invention and are not intended to limit the scope of the present invention. The scope of protection of the present invention is defined by the claims. Persons skilled in the art may make various modifications or equivalent substitutions to the present invention within the spirit and scope of protection of the present invention, and such modifications or equivalent substitutions shall also be deemed to fall within the scope of protection of the present invention.

Claims

1. A method for storing and tracing intelligent transportation charging data based on blockchain, characterized in that: The following steps are involved: S1: Data collection: Through the DSRC dedicated short-range communication protocol between the RSU and the on-board OBU device, the original charging data including vehicle ID, pass timestamp, path coordinate point sequence, and transaction amount are obtained in real time; S2: Data preprocessing: Use a streaming computing engine to clean the raw data, extract key fields, and generate a charging data packet that complies with the ISO12855 standard. The key fields include at least: A1. Vehicle identification: license plate number or electronic tag number; A2. Access path topology: Contains the geofence coordinates of at least three base stations; A3. Rate calculation parameters: vehicle type classification code, discount type code; A4. Data integrity check code: A hash digest generated based on SHA-256; S3: Data shard storage: Based on the preset sharding rules, the standardized data packet is split into N data shards (N≥2), with each shard appended with a region identifier and a shard sequence code. When the real-time traffic volume in the target area exceeds the preset threshold, the shard size is automatically adjusted from 1MB to 512KB. At the same time, double encryption is implemented for data shards containing sensitive payment information: the original data is first encrypted using the AES-256 algorithm, and then the shard metadata is encrypted using the national secret SM4 algorithm; S4: Blockchain evidence storage: The encrypted data shards are uploaded to the main chain node for verification. The main chain node performs the following operations: B1. Verify that the hash value of the data shard is consistent with the checksum generated in the preprocessing phase; B2. Check the continuity of the fragment sequence code; B3. Aggregate signatures of at least five verification nodes using the threshold signature algorithm; The verified data shards are distributed to the corresponding sub-chain storage nodes according to the preset mapping rules, where: Payment voucher shards are stored in the bank sub-chain; The path trajectory fragments are stored in the traffic police sub-chain; The device status shards are stored in the operator subchain; S5: Smart Contract Execution: The automatic billing contract deployed on the bank sub-chain periodically performs the following operations: C1. Call the oracle to obtain real-time traffic index and electricity price parameters; C2. Calculate dynamic rates based on vehicle route length and congestion coefficient; C3. Complete cross-chain fund settlement through atomic swap protocol; The anomaly detection contract deployed on the Traffic Police subchain monitors the following anomaly patterns in real time: D1. The timestamps of the same vehicle appear in reverse order at adjacent base stations; D2. The number of transactions per unit time for a single OBU device exceeds the threshold; D3. The path coordinate point sequence does not conform to the road topology constraints; S6: Data traceability: When responding to traceability requests, execute the cross-chain retrieval protocol: E1. Locate the storage location of the target data through the Merkle Patricia Trie index tree of the main chain; E2. Use the improved lightweight cross-chain communication protocol to obtain shard data from related sub-chains; E3. Verify the validity of the double-encrypted signature when reassembling shards; The improved BLS threshold signature scheme is adopted in the traceability verification stage, requiring the car owner, bank, and traffic management department to jointly verify the authenticity of the data.

2. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: The method for generating the spatiotemporal slicing rules in step S3 includes: Establish a geographic space partitioning model based on the Voronoi diagram to divide the urban road network into multiple honeycomb storage areas; The identifier of each storage area is generated by the GeoHash encoding of the longitude and latitude coordinates of the center point; The shard granularity adjustment strategy meets the following requirements: Where G is the fragment size, Q is the real-time traffic, and Qth is the preset traffic threshold.

3. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: The main chain node verification process in step S4 adopts an improved practical Byzantine fault-tolerant algorithm, sets a dynamic weight voting mechanism, allocates voting weights based on the historical verification accuracy of the node, introduces a credit decay factor α (0<α<1), and reduces the weight of nodes that fail verification continuously. The verification pass criteria are: Where w i is the weight of the i-th node, v i ∈{0,1} represents the verification result, W th is the passing threshold.

4. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: The implementation of the anomaly detection contract in step S5 includes building an LSTM-based traffic pattern prediction model with input dimensions including time, weather, and events; defining an anomaly scoring function: S = λ1·△t+λ2·△d+λ3·△ν; Where Δ represents the deviation between the actual value and the predicted value, and λ is the weight coefficient of each parameter; when S exceeds the threshold, the transaction is automatically frozen and the arbitration process is triggered.

5. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: The cross-chain retrieval protocol described in step S6 adopts a layered encryption mechanism: The first layer uses attribute-based encryption to control data access permissions; The second layer applies a homomorphic encryption algorithm to protect the transaction amount field; The third layer uses zero-knowledge proof to implement path privacy verification and meets the following conditions: and Where h is the path hash value and F is the total cost.

6. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: Also included are methods for optimizing data storage: Establish a hot data cache pool and use a columnar storage structure for data generated in the past 24 hours. Perform the following operations on cold data that has not been accessed for more than 30 days: F1. Use Snappy algorithm for lossless compression; F2. Store the compressed package hash value on the blockchain; F3. Original data is migrated to edge storage nodes.

7. The method for storing and tracing intelligent transportation charging data based on blockchain according to claim 1 is characterized in that: The data collection phase in step S1 includes a device authentication mechanism, specifically a two-way authentication when the OBU and RSU establish communication: G1.RSU sends a random number challenge containing timestamp T1; G2.OBU uses the preset key to calculate the response code: G3. Establish a temporary session key after authentication.

Images