A blockchain-based traffic data security encryption and circulation system and method

Abstract

The application discloses a kind of based on blockchain's traffic data security encryption and circulation system and method, belong to traffic control technical field, to solve the security, privacy and trust problem in traffic data sharing.System includes: the edge computing node near data source is deployed, and original traffic data is encrypted or privacy enhanced processing;Blockchain network with smart contract is deployed, manages node identity, records verification information, stores access strategy and controls data circulation;Data processing unit, aggregate processed data to generate circulatable data product.The method includes edge security processing, blockchain management verification, data processing unit product generation and blockchain according to strategy control circulation.The application guarantees data security privacy through edge security processing and blockchain trust mechanism, realizes the circulation and utilization of traffic data security, transparent and credible, and provides reliable data support for intelligent upgrading and digital transformation of traffic industry.

Description

Technical Field

[0001] This invention relates to the field of traffic information technology, specifically to a data processing system and method, and in particular to a system and method that utilizes blockchain technology to ensure the security of traffic data during encryption, processing, and circulation, primarily applied to traffic control systems. Background Technology

[0002] Modern urban transportation systems are becoming increasingly complex, and traffic control systems such as adaptive signal control systems, highway management systems, urban traffic guidance systems, public transportation dispatching systems, and emergency response systems are relying on data like never before. These systems require accurate, real-time, comprehensive, and diverse traffic data (including but not limited to vehicle speed, location trajectory, flow rate, density, intersection queue length, sensor readings, public transportation ridership, traffic accident information, road construction conditions, etc.) to achieve their core functions, such as optimizing signal timing to reduce delays, predicting and alleviating traffic congestion, providing travelers with optimal route suggestions, improving public transportation efficiency, and responding quickly to traffic accidents.

[0003] However, existing models for collecting, processing, storing, and sharing traffic data generally have significant limitations and risks, severely restricting further improvements in the effectiveness of traffic control systems. Specifically:

[0004] 1) Insufficient security protection: Traditional traffic data systems mostly adopt a centralized architecture, with data stored centrally at traffic management centers or third-party platforms. In this model, data is exposed to risks from external attacks (such as hacking and ransomware) and internal threats (such as unauthorized access and malicious operations). Once the central node is compromised, a large amount of sensitive traffic data may be stolen, tampered with, or destroyed, causing serious consequences for the operation of the traffic system and even public safety. Existing network security measures (such as firewalls and intrusion detection) and simple transport layer encryption (such as TLS / SSL) are insufficient to provide end-to-end security protection throughout the entire data lifecycle.

[0005] 2) Severe Privacy Risks: Traffic data, especially data involving precise vehicle trajectories, driving behavior, and personal travel habits, is highly sensitive to privacy. Current data sharing practices, even with traditional anonymization methods (such as removing identifiers, K-anonymity, and L-diversity), often prove ineffective with high-dimensional, spatiotemporally correlated traffic data, still posing a risk of re-identification through data correlation analysis. Public concerns about privacy leaks reduce willingness to share data, making it difficult for traffic management departments to obtain sufficiently rich and high-quality data to support refined traffic management and decision-making.

[0006] 3) Questions about data credibility and integrity: In a multi-party traffic data ecosystem, the source, authenticity, and whether the data has been tampered with during transmission and processing are difficult to guarantee effectively. False or contaminated data (such as maliciously reported false congestion information or tampered sensor readings) may mislead traffic control systems into making incorrect decisions, causing traffic chaos. Existing systems lack transparent and tamper-proof auditing mechanisms to trace data sources and processing history, making it difficult to establish trust among stakeholders.

[0007] 4) Data silos and circulation barriers: Due to issues such as security, privacy, trust, and standardization, data from different traffic management departments, different transportation operators, map service providers, vehicle manufacturers, and research institutions are often isolated from each other, forming "data silos." These barriers hinder cross-domain and cross-regional data fusion and collaborative analysis, limiting the realization of advanced applications such as integrated traffic management and multimodal transport optimization.

[0008] 5) Limitations of Existing Technological Solutions: While some research has attempted to apply blockchain technology to the transportation sector (e.g., vehicle identification, toll collection, simple event storage), or to use edge computing for preliminary processing, or to employ individual encryption / privacy technologies, these solutions often fail to form an organic whole. For example, simply uploading raw data to the blockchain presents performance bottlenecks and privacy risks; edge computing alone lacks global trusted coordination and result verification; and relying solely on traditional encryption technologies makes it difficult to perform effective aggregation analysis while protecting data privacy. There is a lack of a systematic solution that integrates edge processing capabilities, blockchain trust mechanisms, and advanced security and privacy technologies to comprehensively address the challenges of secure encryption and trusted circulation of transportation data, and effectively empower traffic control systems.

[0009] Therefore, there is an urgent need for a new technological solution that can comprehensively protect the security and privacy of traffic data from source to application, establish a trustworthy data circulation environment, break down data barriers, and unleash the value of data, thereby strongly supporting the development of the next generation of intelligent traffic control systems. Summary of the Invention

[0010] To address the aforementioned problems in the collection, processing, sharing, and circulation of traffic data, including insufficient security protection, high risk of privacy leaks, low data credibility, difficulties in cross-entity collaboration, and limitations of existing technical solutions, particularly the negative impact these problems have on the quality, availability, and security of data required by traffic control systems, this invention aims to provide an innovative blockchain-based traffic data security encryption and circulation system and its implementation method. This system strives to build a secure, transparent, efficient, and reliable environment for the circulation and utilization of traffic data while ensuring data confidentiality, integrity, availability, and user privacy, thereby providing a solid data foundation for improving the intelligence level of traffic control.

[0011] To address the aforementioned technical problems, this invention proposes a systematic solution, the core of which lies in the organic integration of edge computing, blockchain technology, and advanced security encryption and privacy enhancement technologies.

[0012] The blockchain-based traffic data security encryption and circulation system provided by this invention mainly includes the following architecture:

[0013] a) Distributed Edge Computing Layer: This layer consists of at least one edge computing node deployed close to the data source (such as Roadside Units (RSUs), On-Board Units (OBUs), mobile devices, regional servers, etc.). These nodes are responsible for acquiring raw traffic data and performing critical localized security processing operations according to preset strategies. These operations form the first line of defense for data security and privacy, aiming to ensure the confidentiality or privacy of the data. They include at least the encryption of sensitive data (e.g., using homomorphic encryption) or privacy-enhancing transformations (e.g., performing local model training for federated learning, applying differential privacy mechanisms to add statistical noise, performing the local portion of a secure multi-party computation protocol, generating zero-knowledge proofs, etc.). The goal is to transform the data into "securely processed data" that protects the original information before it leaves the edge nodes.

[0014] b) Blockchain Network Layer: Serving as the trusted foundation and central hub for circulation management of the system. It deploys a series of smart contracts, typically in the form of a consortium blockchain or private blockchain. The blockchain network does not store the original or processed sensitive data itself, but is configured to: manage and verify the identity or credential information of edge nodes; publish and coordinate data processing and aggregation tasks; record verification information (such as zero-knowledge proofs, computational integrity proofs) or metadata (such as data hashes, timestamps, source node identifiers, parameters of the type of secure processing operation used, and data circulation logs) related to the securely processed data; store or reference access policies used to control data circulation, and implement these policies through smart contracts (e.g., dynamic control based on roles, attributes, time, or permission credentials) to ensure that only authorized entities can access the final data product or its metadata; verify the integrity or correctness of secure processing operations performed by edge computing nodes; and provide tamper-proof audit logs to enhance the system's transparency and traceability.

[0015] c) Data Processing and Application Layer: This layer includes one or more data processing units (which can be a central server or a cluster of nodes participating in secure multi-party computation). Each unit is configured to receive the securely processed data from one or more edge nodes and perform subsequent aggregation, analysis, or further processing tasks (e.g., using secure aggregation protocols or secure multi-party computation techniques to enhance the security of the aggregation process, or using homomorphic encryption to perform statistical operations on ciphertext), generating "circulating data products" with application value that do not disclose individual privacy (such as aggregated traffic flow statistics, trained traffic prediction models, regional congestion indices, verified traffic incident reports, and anonymized travel behavior pattern analysis results). These data products ultimately serve traffic control applications, for example, by being used directly or indirectly as input to support the implementation or optimization of at least one traffic control function (selected from: traffic signal control, traffic flow prediction, congestion management, route planning and guidance, public transport scheduling, vehicle cooperative control, or traffic incident management).

[0016] This invention also provides a method for secure encryption and circulation of traffic data based on this system. This method details the complete process of data collection, edge security processing, blockchain-coordinated verification, aggregation analysis, and final application of the data, as well as the technical implementation details of each stage. This method is a blockchain-based approach to secure encryption and circulation of traffic data, applied to support traffic control applications, and includes the following steps:

[0017] a) Obtain raw traffic data at edge computing nodes;

[0018] b) The edge computing node performs security processing operations on the original traffic data, the operations including at least one of data encryption or privacy enhancement transformation, to generate securely processed data;

[0019] c) Manage the identity, metadata, or verification information associated with the edge computing node and the securely processed data through a blockchain network;

[0020] d) The data processing unit receives and processes the securely processed data from one or more edge nodes to generate a circulating data product;

[0021] e) Using the blockchain network, and in accordance with a preset access policy, control the circulation of the circulating data products and securely provide them to the authorized traffic control application or related entity.

[0022] In one alternative implementation, the security processing operation in step b) includes data encryption, specifically employing a homomorphic encryption algorithm.

[0023] In one alternative implementation, the security processing operation in step b) includes a privacy-enhancing transformation selected from: federated learning local training, differential privacy processing, secure multi-party computation local processing, or zero-knowledge proof generation.

[0024] In one alternative implementation, in step e), the blockchain network is used to perform smart contract-based dynamic access control to achieve refined management of the circulation of data products; and the method further includes applying the circulated data products to optimize at least one function in the traffic control system, the function including: traffic signal control, traffic flow prediction, congestion management, route planning and guidance, public transport scheduling, vehicle cooperative control, or traffic event management.

[0025] Compared with the prior art, the present invention, through the above technical solution, can bring the following significant beneficial effects:

[0026] 1) End-to-end data security: By combining local security processing (encryption / privacy enhancement) at edge nodes with the tamper-proof and access control features of blockchain, an end-to-end security protection system is built from data generation to circulation and application, effectively resisting the risks of data leakage and tampering.

[0027] 2) Strict privacy compliance: By adopting advanced privacy enhancement technologies (such as federated learning, differential privacy, homomorphic encryption, and ZKP), it is possible to achieve data usability without visibility while maximizing data value and protecting personal privacy, under the premise of meeting increasingly stringent data privacy regulations (such as GDPR and the Personal Information Protection Act).

[0028] 3) Enhanced system trust: The decentralized, transparent, and tamper-proof characteristics of blockchain provide a natural trust mechanism for data circulation involving multiple parties. Smart contracts automatically execute rules, reduce collaboration costs, and promote data sharing across departments and institutions.

[0029] 4) Improve system efficiency: It can provide traffic control systems with richer, more accurate, more reliable, and privacy-protected data input, enabling them to make better decisions, such as achieving more refined signal timing, more reliable congestion prediction, and more efficient emergency response, ultimately improving the operational efficiency and safety of the entire traffic system.

[0030] 5) Excellent scalability and flexibility: The system adopts a distributed architecture, which is easy to expand to connect more edge nodes and data sources; the modular design allows for flexible selection and combination of different security processing technologies according to specific application scenarios. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram of the system architecture.

[0033] Figure 2 This is a flowchart of the method. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0035] Example 1: Secure Training and Circulation of a Traffic Congestion Prediction Model Based on Federated Learning and Blockchain

[0036] This embodiment aims to illustrate how to use the system of the present invention to collaboratively train a high-precision traffic congestion prediction model while protecting the privacy of various data sources (such as vehicles equipped with OBUs and RSUs deployed at intersections), and to securely provide the model to traffic signal control systems or traffic information dissemination platforms.

[0037] System architecture (refer to) Figure 1 ):

[0038] Edge computing nodes (ECNs): These can be vehicle-mounted OBUs or roadside RSUs. Each ECN is equipped with: a data acquisition module (collecting local speed, density, queue length, etc.), a federated learning client module (responsible for local model training), a security processing module (optional, such as encrypting model updates or adding differential privacy noise), and a blockchain interaction module (used to communicate with the blockchain network and submit proofs / metadata).

[0039] The Blockchain Network (BCN) adopts a consortium blockchain format and is jointly maintained by major traffic management departments and participating enterprises. Core smart contracts are deployed on the chain, including: a node management contract (responsible for ECN registration, identity authentication, and reputation management), a task management contract (publishing federated learning training tasks, defining hyperparameters, and coordinating training rounds), a model update management contract (receiving and verifying model update hashes or encrypted updates submitted by ECNs, and recording contributions), and a global model management contract (storing the global model's version, hash, performance metrics, and access permissions).

[0040] Data Processing Unit (DPU): This is a centralized federated learning aggregation server responsible for aggregating model updates from various ECNs and generating a new global model. This server requires security measures. Alternatively, the DPU can be shared by multiple nodes using a Secure Multi-Party Computation (SMC) protocol to avoid single points of failure.

[0041] Method and Flow (refer to) Figure 2 ):

[0042] 1) Initialization Phase: a. The congestion prediction model structure (e.g., LSTM, GRU) and training task parameters (learning rate, training epochs, participating node requirements, etc.) are defined by the aggregation server (DPU). b. The initial model (or its acquisition address) and task parameters are published to the blockchain network through the task management contract. c. Eligible ECNs register and authenticate themselves through the node management contract (e.g., based on PKI or DID) to obtain eligibility to participate in the task and retrieve task information and the initial model from the blockchain.

[0043] 2) Local Training and Security Processing Phase (Multiple Rounds): a. Each participating ECN trains its current model using locally collected, privacy-sensitive raw traffic data (such as speed sequences and flow data over a past period), calculating the model parameter updates (gradients). b. The ECN's federated learning client module performs local training. c. (Security Processing) To further enhance security, the ECN's security processing module can: i) encrypt the calculated model updates using a homomorphic encryption public key; ii) or, apply differential privacy mechanisms to add appropriate random noise to the model updates; iii) or, if verification of the calculation's correctness is required, generate zero-knowledge proofs about the training process. This step is optional and depends on specific security requirements.

[0044] 3) Model Update Submission and Blockchain Verification Phase: a. The ECN sends the processed model update (which may be encrypted, noisy, or include ZKP) to the aggregation server (DPU) through its blockchain interaction module. b. Simultaneously, the ECN submits the metadata of this update to the model update management contract of the blockchain network, such as the hash value of the update, timestamp, corresponding training epoch, ECN's (anonymous) identity credentials, and possibly ZKP. c. The model update management contract verifies the validity of the submission information (such as node qualification, timestamp, and ZKP verification) and records the valid contribution on the chain. This provides a basis for subsequent auditing and incentives.

[0045] 4) Global Model Aggregation Phase: a. The Aggregation Server (DPU) collects valid model updates from a sufficient number of ECNs. b. The DPU executes secure aggregation algorithms. For example: i) If the update is homomorphically encrypted, a weighted average is performed on the ciphertext; ii) If differential privacy noise is added to the update, it is directly averaged (the noise effect will partially cancel each other out after aggregation); iii) If secure multi-party computation is used, each node collaboratively calculates the aggregation result, and the server only receives the final aggregated value. The goal is to calculate the global model update amount while preventing the aggregator from obtaining the original update information of any single ECN. c. The DPU updates the global model using the global update amount.

[0046] 5) Global Model Release and Circulation Phase: a. The DPU stores the newly generated global model (or its checkpoints) in a secure location and calculates its hash value. b. The DPU records the new model's version number, hash value, training process metadata (such as the number of participating nodes and achieved performance metrics), access control list (ACL), and other information on the blockchain through the global model management contract. c. Authorized application systems (traffic signal control systems) query the global model management contract according to their registered permissions on the blockchain to obtain the latest and most effective congestion prediction model (or its access method).

[0047] 6) Applications to the system: a. Traffic signal control systems that acquire the model can use it to predict traffic congestion at key intersections and road sections in the near future (e.g., 5-15 minutes). b. Based on the prediction results, the system can dynamically adjust signal timing schemes (e.g., extend green light time, adjust phase difference) or issue traffic guidance information to guide vehicles to avoid areas that are about to become congested, thereby effectively alleviating congestion and improving road network efficiency.

[0048] Federated learning avoids uploading raw data, combines blockchain for trusted coordination and verification, and optionally incorporates encryption or differential privacy enhancements, enabling the training of high-quality traffic prediction models while protecting data privacy and security. This model can directly contribute to the optimization of traffic control systems, and the entire training and distribution process (the model itself as a distributed data product) is transparent, reliable, and auditable.

[0049] Example 2: Secure Traffic Flow Statistics and Circulation Based on Homomorphic Encryption and Blockchain This example details how to use the system of the present invention, combined with additive homomorphic encryption technology (such as the Paillier cryptosystem), to accurately calculate key traffic flow indicators (such as average vehicle speed and total number of vehicles) for a specific road segment or area without decrypting the original observations from various data sources, and to securely circulate these reliable statistical results to traffic control systems (such as variable speed limit systems and ramp control systems).

[0050] Using Paillier's additive homomorphic encryption scheme, its characteristic is E(m1)*E(m2)=

[0051] E(m1+m2)modn 2 (Based on a specific public key n), and E(m) k =E(k*m)modn 2This allows for direct addition and constant multiplication operations on the ciphertext. Key management is crucial; the public key PK = (n, g) must be securely distributed, and the private key SK = (λ, μ) must be strictly kept by an authorized decryption party. Here, E(m) represents the ciphertext obtained after homomorphically encrypting the plaintext message m. E represents the encryption function. m, m1, m2 represent the plaintext data. k represents a constant (or scalar). n and g are components of the public key (PK) in the Paillier cryptosystem, which is securely distributed to various edge computing nodes (such as RSUs) for encrypting data. λ and μ are components of the private key (SK) in the Paillier cryptosystem, which is strictly kept by an authorized decryption party (in your scenario, a highly secure Trusted Decryption Service (TDS)) for decrypting the final aggregated ciphertext result.

[0052] System component settings:

[0053] 1) Edge Computing Node (ECN): Roadside Units (RSUs) deployed at critical sections of highways, equipped with sensors (such as radar and coils) to detect the speed and presence of passing vehicles. They have built-in encryption modules and hold Paillier public keys distributed by the TMC (Traffic Management Center).

[0054] 2) Blockchain Network (BCN): Employs a consortium blockchain led by the traffic management department, running smart contracts. Key contracts include: RSU_Identity_Contract (manages RSU registration, authentication, and status), Key_Management_Contract (records and distributes currently valid Paillier public keys and their validity period and scope of application), Data_Submission_Audit_Contract (records the hash, timestamp, and RSU identifier of RSU submission data batches), and Result_Access_Control_Contract (manages access permissions to the final statistical results).

[0055] 3) Data Processing Unit (DPU): Deployed at the central aggregation server of TMC, it is responsible for collecting encrypted data and performing homomorphic operations. The DPU itself does not hold the private key.

[0056] 4) Trusted Decryption Service (TDS): A highly secure service (or hardware security module HSM) deployed within TMC with strict access control. It uniquely holds the Paillier private key and is responsible for decrypting the aggregated ciphertext results.

[0057] Detailed workflow:

[0058] 1) Key Deployment and Synchronization: TMC generates Paillier key pairs (PK, SK). Through...

[0059] The Key_Management_Contract publishes the Key (PK) on the blockchain, specifying its applicable road segment and validity period. After verifying its identity through the RSU_Identity_Contract, the RSU retrieves the latest PK from the chain.

[0060] 2) Edge Data Acquisition and Encryption: The RSU monitors passing vehicles within a set time window (e.g., 1 minute). For each detected vehicle i, its speed s is recorded. i RSU uses PK to encrypt each speed record to obtain E(s). i Meanwhile, to count the number of vehicles, the number "1" is encrypted to obtain E(1). i The speed of the i-th vehicle is a specific plaintext observation. When calculating the total number of vehicles, the plaintext is the number "1", representing one vehicle.

[0061] 3) Ciphertext Submission and On-Chain Audit: RSU submits ciphertext pairs of all vehicles in a batch (E(s)). i The data (RSU_ID, timestamp, h_meta) is packaged together with the road segment ID and time window identifier and sent to the DPU through a secure channel. At the same time, the hash value h_meta of the metadata of this batch of data (such as the number of ciphertexts, timestamp, road segment ID, etc.) is calculated, and Data_Submission_Audit_Contract is called to record (RSU_ID, timestamp, h_meta) on the chain as an immutable credential for data submission.

[0062] 4) Centralized Homomorphic Aggregation: The DPU receives encrypted data submitted by all RSUs within the same road segment and time window. This leverages Paillier's additive homomorphism.

[0063] The overall speed of encryption calculation:

[0064] E(TotalSpeed)=∏E(s i )modn 2 =E(∑si)modn 2 (Multiplication corresponds to the addition of plaintext).

[0065] Calculate the total number of encrypted vehicles: E(TotalCount)=∏E(1)modn 2 =

[0066] E(∑1)modn 2 , where N is the total number of vehicles.

[0067] 5) Secure Decryption and Result Generation: The DPU sends the two aggregated ciphertexts E(Total Speed) and E(Total Count) to the TDS. The TDS uses the private key SK to decrypt them, obtaining the plaintext Total Speed ​​and Total Count. The average speed is calculated as: Average Speed ​​= Total Speed ​​ / Total Count.

[0068] 6) Results circulation and application:

[0069] The calculated Average Speed ​​serves as a highly reliable real-time traffic status indicator.

[0070] Application Integration: This Average Speed ​​can be directly input into the control logic of a Variable Speed ​​Limit (VSL) system. For example, if the Average Speed ​​is lower than a preset threshold, the VSL system automatically reduces the displayed speed limit for that road segment; or it can be input into a ramp merging system to dynamically adjust the frequency of vehicle merging at ramps based on the average speed of the mainline.

[0071] TMC can use Result_Access_Control_Contract to authorize the final statistical results (or their access permissions) to other systems that need them (such as traffic information publishing platforms), thus achieving secure and controllable data flow. The hash of the result itself can also be recorded on the blockchain for verification.

[0072] Raw speed data never leaves the RSU in plaintext. The aggregation server only processes the encrypted data and cannot determine the bike speed. Private keys are strictly controlled within the TDS, reducing the risk of leakage. The blockchain ensures the auditability of data submissions and the transparency of result circulation.

[0073] Homomorphic encryption (especially public-key operations) has relatively high computational overhead and requires optimization. The security and availability of key management are of paramount importance.

[0074] Example 3: Anonymous Travel Hotspot Analysis and Circulation Based on Local Differential Privacy and Blockchain

[0075] This embodiment focuses on using Local Differential Privacy (LDP) technology to collect location information from a large number of mobile users (such as private car owners and ride-hailing drivers using navigation apps) to create urban travel hotspot maps or OD (origin-destination) flow maps under strong privacy protection, serving traffic planning and public transportation optimization.

[0076] Using LDP mechanisms, such as those targeting location (which is typically first gridded or regionalized), randomized response or more advanced frequency-based prediction mechanisms like RAPPOR or Harmony can be employed. The core principle is to perturb the user's actual location (or region ID) before uploading, making it impossible for the server to know the true location of any individual, but allowing it to statistically determine regional popularity from a large amount of perturbed data. A key parameter is the privacy budget ε; a smaller ε provides better privacy protection but lower data availability.

[0077] System component settings:

[0078] 1) Edge Computing Node (ECN): The user's smartphone (running a specific navigation or travel app) or the vehicle's OBU. The device has a built-in LDP module to handle local data disturbances.

[0079] 2) Blockchain Network (BCN): This can be a public or consortium blockchain, running smart contracts. Key contracts include: Parameter_Distribution_Contract (publishes parameters such as the current LDP mechanism type, region division criteria, and privacy budget ε), Contribution_Reward_Contract (optional, used to record users' valid data contributions and award points or tokens as incentives), and Aggregated_Result_Registry_Contract (stores the metadata and hashes of the final published anonymized heatmap or OD statistical report).

[0080] 3) Data Processing Unit (DPU): This is the backend server for APP operators or traffic research institutions, responsible for collecting massive amounts of disturbance data and executing the LDP aggregation analysis algorithm.

[0081] Detailed workflow:

[0082] 1) Parameter Acquisition and Local Disturbance: a. User's APP / OBU via

[0083] Parameter_Distribution_Contract retrieves the current LDP configuration, including the grid definition for dividing the city into multiple geographical regions and the privacy budget ε. b. During operation, the device determines the ID zone_true of the region it primarily stays in or traverses during a certain time period. c. When location information needs to be uploaded, the LDP module on the device, based on the obtained ε and mechanism (such as a random response based on an exponential mechanism or unary coding), reports the true region ID zone_true with a certain probability p, and reports a randomly selected other region ID with a probability (1-p), generating a perturbed region.

[0084] IDzone_perturbed. The probability p is related to ε.

[0085] 2) Disturbance data submission and contribution recording: a. The device sends (timestamp, zone_perturbed) to the DPU. b. (Optional) The device can submit a simple "contributed" proof (without data content) to the Contribution_Reward_Contract. The smart contract verifies the proof and records the number of contributions, which may trigger a reward mechanism.

[0086] 3) Centralized Aggregation Analysis: a. The DPU collects a large number of perturbation zone IDs submitted by users at different time periods. b. The DPU applies a statistical inference algorithm (such as maximum likelihood estimation based on frequency counting or expectation-maximization EM algorithm) that matches the selected LDP mechanism to estimate the unbiased estimate of the actual user access frequency or number of stays in each zone_j at various time periods from a large amount of zone_perturbed data, based on the known perturbation probability p (calculated from ε).

[0087] 4) Results Generation and Distribution: a. Based on the estimated frequency data, the DPU generates aggregated statistical results such as visualized urban travel hotspot maps and OD flow matrices between different regions. These results reflect group behavior patterns but do not contain any identifiable individual information. b. The final analysis report (or its summary, hash, or access link) can be accessed through...

[0088] The Aggregated_Result_Registry_Contract is recorded on the blockchain for authorized parties to query.

[0089] 5) Application integration:

[0090] These anonymous heat maps and OD flow analysis results can serve as an important basis for urban transportation planning, helping to identify traffic bottlenecks and optimize road network design.

[0091] To optimize the public transportation system, bus routes, frequency of service, and stop locations can be adjusted according to the travel needs of the population to improve the level of public transportation services and its attractiveness.

[0092] It can also be used for the rational layout of infrastructure such as shared bicycles and charging stations.

[0093] LDP provides mathematically rigorous privacy guarantees, ensuring that even if user data is intercepted or the server is malicious, it is impossible to accurately infer the true location of an individual user. Blockchain is used to ensure the transparent distribution of privacy parameters and (optionally) fair incentives.

[0094] A very large number of users are required to effectively counteract noise and obtain reliable statistical results. There is an inherent trade-off between data utility and privacy protection (the choice of ε). Aggregation algorithms are relatively complex.

[0095] Example 4: Trusted Verification and Circulation of Traffic Events / States Based on Zero-Knowledge Proofs and Blockchain

[0096] This embodiment illustrates how zero-knowledge proof (ZKP) technology can be used to allow vehicles or other traffic participants (such as pedestrian apps and roadside devices) to prove to the system that they meet specific conditions or have observed specific events without disclosing their specific private data (such as precise speed, identity credential details, and complete observation data), and to securely transmit these verified "assertions" to traffic management systems (such as signal priority control, accident management, and law enforcement assistance).

[0097] Non-interactive ZKP schemes such as zk-SNARKs (simple and fast verification, but may require trusted setup) or zk-STARKs (no trusted setup required, quantum resistant, but proof is more complex) are employed. The core idea is to construct an Arithmetic Circuit (or R1CS) to express the statement to be proven (e.g., "velocity v is within the range [min, max] and timestamp t is in [t1, t2]"). The prover then uses their private data (witness) to generate the proof π, and the verifier uses publicly available information to verify π.

[0098] System component settings:

[0099] 1) Edge Computing Node (ECN - Prover): Vehicle OBU, smartphone APP, or RSU. It has a built-in ZKP proof generation module and holds its own private data and keys used to generate proofs.

[0100] 2) Blockchain Network (BCN): A consortium blockchain that runs smart contracts. Key contracts include: Rule_Definition_Contract (stores a public description of the verifiable rule, the corresponding ZKP circuit hash, and the verification key), and Proof_Verification_Contract (contains the ZKP verification algorithm logic, possibly implemented through a pre-compiled contract to improve efficiency).

[0101] Verified_Assertion_Ledger_Contract (Records successfully verified assertions and their metadata).

[0102] 3) Verifier: The Proof_Verification_Contract itself, or an off-chain trusted verification service invoked by the contract.

[0103] Detailed workflow:

[0104] 1) Rule definition and distribution: Traffic management departments or standards organizations define and distribute rules.

[0105] The Rule_Definition_Contract defines a series of verifiable traffic rules or state declarations, for example:

[0106] Rule R1 (Bus Priority): is_vehicle_type (bus) AND is_credential_valid() AND is_behind_schedule()

[0107] Rule R2 (Speed ​​Compliance): speed >= Vmin AND speed <= Vmax FOR duration >= T

[0108] Rule R3 (Event Observation): sensor_reading (collision) > Threshold AND timestamp = t. For each rule, the contract stores its corresponding ZKP verification key and circuit information. ECN can obtain these public rule definitions from on-chain.

[0109] 2) Local Proof Generation: a. When an ECN (such as a bus OBU requesting signal priority) needs to prove that it satisfies rule R1, it collects its own private data (vehicle type identifier, valid digital certificate, current operating schedule status). b. The OBU's ZKP proof module uses this private data as witness, along with the circuitry corresponding to rule R1, to run the ZKP generation algorithm and produce a concise proof π.

[0110] 3) Proof Submission and On-Chain Verification: a. The OBU submits the facts it wants to declare (such as "I request priority passage based on rule R1") and the proof π to the blockchain by calling Proof_Verification_Contract. b. Proof_Verification_Contract executes the ZKP verification algorithm, using the verification key obtained from Rule_Definition_Contract and the public input (i.e., the declaration itself) to verify π. This process does not access any of the OBU's private data.

[0111] 4) Assertion Recording and State Updates: a. If verification is successful, `Proof_Verification_Contract` triggers `Verified_Assertion_Ledger_Contract`, recording the successfully verified assertion, for example, (Bus_ID_123, Rule_R1_Passed, timestamp, location_approx). This record is immutable and publicly verifiable (to the authorizing party). b. For certain state-type assertions (such as "Vehicle X's current speed is compliant"), the contract may update a temporary state variable for other systems to query.

[0112] 5) Results circulation and application:

[0113] Traffic signal controller: When it receives a priority request from Bus_ID_123, the controller queries Verified_Assertion_Ledger_Contract. If it finds that the bus has just successfully verified rule R1, the controller grants signal priority (Transit SignalPriority-TSP) and adjusts the signal timing.

[0114] Accident Management Center: If multiple sources (vehicles, RSUs) successfully verify Rule R3 (observed collision) at similar times and locations, the system can be highly certain that an accident has occurred and automatically trigger the accident emergency response process.

[0115] Enforcement assistance: For Rule R2 (speed compliance), verification records can serve as evidence that a vehicle complies with traffic rules.

[0116] ZKP guarantees zero-knowledge proof, allowing vehicles to prove their status or behavior is compliant without revealing specific speeds, precise locations, or sensitive credentials. Blockchain ensures the transparency, verifiability, and immutability of the verification process.

[0117] ZKP circuit design is complex; proof generation may require certain computing resources from edge devices; some ZKP schemes (such as Groth 16SNARKs) require a trusted setup ceremony.

[0118] It should be noted that the above specific embodiments are merely illustrative examples of the present invention and are not intended to limit it. For those skilled in the art, based on an understanding of the core ideas of the present invention, various modifications, combinations, or equivalent substitutions can be made, such as adjusting the specific deployment location of edge computing nodes, selecting the blockchain consensus mechanism, setting specific encryption algorithms or privacy protection parameters, etc. These modifications, which do not depart from the spirit and scope of the present invention, should all be included within the protection scope of the present invention.

Claims

1. A blockchain-based traffic data security encryption and circulation system, characterized in that, The system is configured to process traffic data related to traffic control applications, and the system includes: At least one edge computing node is deployed near the traffic data source, and the edge computing node is configured as follows: Obtain raw traffic data; The original traffic data is subjected to security processing operations to generate securely processed data. The security processing operations are designed to ensure the confidentiality or privacy of the data, and the operations include at least one of data encryption or privacy enhancement transformation. A blockchain network, wherein smart contracts are deployed and the edge computing nodes are communicatively connected, the blockchain network being configured as follows: Manage the identity or credential information associated with the edge computing node; Record verification information or metadata related to the data after security processing; Store or reference access policies used to control the flow of data; A data processing unit, configured as follows: Receive the securely processed data from one or more edge computing nodes; The data after security processing is aggregated, analyzed, or further processed to generate circulating data products; The blockchain network, based on the access policy, manages the circulation process of the tradable data products, enabling authorized entities to securely obtain data from the traffic control application. Meanwhile, the secure processing operations of the edge computing nodes protect the original traffic data from unauthorized access.

2. The system according to claim 1, characterized in that, The security processing operations performed by the edge computing node include data encryption, which uses a homomorphic encryption algorithm, enabling the data processing unit to perform aggregation operations on the securely processed data without decryption.

3. The system according to claim 1, characterized in that, The security processing operations performed by the edge computing node include privacy-enhancing transformations, which are selected from at least one of the following: performing local model training for federated learning, adding noise by applying differential privacy mechanisms, performing the local part of a secure multi-party computation protocol, and generating zero-knowledge proofs.

4. The system according to claim 3, characterized in that, The privacy enhancement is converted into local model training to perform federated learning, the securely processed data is the model update parameters, the blockchain network is configured to coordinate the training rounds of federated learning and record global model metadata, and the data processing unit is configured to securely aggregate the model update parameters.

5. The system according to claim 3, characterized in that, The privacy enhancement is converted into the generation of zero-knowledge proofs, the securely processed data contains the zero-knowledge proofs, the blockchain network is configured to verify the validity of the zero-knowledge proofs through smart contracts, and the circulated data products are verified state assertions or event reports.

6. The system according to claim 1, characterized in that, The verification information or metadata recorded by the blockchain network includes: the hash value, timestamp, source node identifier, security processing operation type parameters, and data circulation log of the data after security processing; the smart contract on the blockchain network is further configured to verify the integrity or correctness of the security processing operation performed by the edge computing node; the blockchain network implements the access policy through the smart contract, and the policy dynamically controls access permissions to tradable data products based on roles, attributes, time, or license credentials.

7. The system according to claim 1, characterized in that, When aggregating the data after secure processing, the data processing unit further employs a secure aggregation protocol or secure multi-party computation technology to enhance the security of the aggregation process. The circulating data products are used directly or indirectly as input to support the implementation or optimization of at least one traffic control function, which is selected from: traffic signal control, traffic flow prediction, congestion management, route planning and guidance, public transportation scheduling, vehicle cooperative control, or traffic incident management.

8. A method for achieving secure encryption and circulation of traffic data based on blockchain, characterized in that, The blockchain-based traffic data security encryption and circulation system as described in any one of claims 1-7 includes the following steps: a) Obtain the raw traffic data at the edge computing node; b) The edge computing node performs security processing operations on the original traffic data to generate securely processed data, wherein the operations include at least one of data encryption or privacy enhancement transformation; c) Manage the identity, metadata, or verification information related to the edge computing node and the securely processed data through the blockchain network; d) The data processing unit receives and processes the securely processed data from one or more edge computing nodes to generate the circulating data product; e) Using the blockchain network, and in accordance with a preset access policy, control the circulation of the circulating data products and securely provide them to the authorized traffic control application or related entity.

9. The method according to claim 8, characterized in that, The security processing operation in step b) includes data encryption, specifically using a homomorphic encryption algorithm; the security processing operation in step b) includes privacy enhancement transformation, which is selected from: federated learning local training, differential privacy processing, secure multi-party computation local processing, or zero-knowledge proof generation; in step e), the blockchain network is used to execute dynamic access control based on smart contracts to achieve refined management of the circulation of data products.

Images