Block chain-based traffic data security encryption and circulation system and method

Abstract

The invention discloses a traffic data security encryption and circulation system and method based on a block chain, belongs to the technical field of traffic control, and aims to solve the problems of security, privacy and trust in traffic data sharing. The system comprises an edge computing node which is deployed near a data source and is used for performing encryption or privacy enhancement processing on original traffic data; a block chain network with a smart contract is deployed, node identities are managed, verification information is recorded, an access strategy is stored, and data circulation is controlled; and the data processing unit is used for aggregating the processed data to generate a circulatory data product. The method comprises the steps of edge security processing, block chain management verification, product generation by the data processing unit and management and control circulation of the block chain according to a strategy. Through edge security processing and a block chain trust mechanism, data security privacy is guaranteed, safe, transparent and credible circulation and utilization of traffic data are realized, and reliable data support is provided for intelligent upgrading and digital transformation of the traffic industry.

Description

Technical Field

[0001] The present invention relates to the field of traffic information technology, and specifically to a data processing system and method, in particular a system and method that utilizes blockchain technology to ensure the security of traffic data in the encryption, processing, and circulation links, and is mainly used in traffic control systems. Background Art

[0002] Modern urban transportation systems are becoming increasingly complex. Traffic control systems, such as adaptive signal control systems (e.g., Sydney's SCATS and the UK's SCOOT), highway management systems, urban traffic guidance systems, public transportation dispatch systems, and emergency response systems, are becoming more data-intensive than ever before. These systems require accurate, real-time, comprehensive, and diverse traffic data (including but not limited to vehicle speeds, location trajectories, traffic flow, density, intersection queue lengths, sensor readings, public transportation ridership, traffic incident information, and road construction conditions) to implement their core functions. These include optimizing signal timing to reduce delays, predicting and alleviating traffic congestion, providing optimal route recommendations to travelers, improving public transportation efficiency, and rapidly responding to traffic incidents.

[0003] However, the existing traffic data collection, processing, storage and sharing circulation mode generally has significant limitations and risks, which seriously restrict the further improvement of the efficiency of traffic control system. Specifically,

[0004] 1) Inadequate security: Traditional traffic data systems often utilize a centralized architecture, with data stored centrally in traffic management centers or third-party platforms. This model exposes data to risks from external attacks (such as hacking and ransomware) and internal threats (such as unauthorized access and malicious operations). Once a central node is compromised, large amounts of sensitive traffic data could be stolen, tampered with, or destroyed, with serious consequences for traffic system operations and even public safety. Existing network security measures (such as firewalls and intrusion detection) and simple transport-layer encryption (such as TLS / SSL) struggle to provide end-to-end security throughout the data lifecycle.

[0005] 2) Serious privacy risks: Traffic data, especially data related to precise vehicle trajectories, driving behaviors, and personal travel habits, is highly privacy-sensitive. Existing data sharing practices, even with traditional anonymization methods (such as deidentification, K-anonymity, and L-diversity), often prove ineffective for high-dimensional, spatiotemporally correlated traffic data, and the risk of re-identification through data correlation analysis persists. Public concerns about privacy have led to a decline in data sharing willingness, 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) Data credibility and integrity concerns: In a multi-party traffic data ecosystem, ensuring data's origin, authenticity, and protection from tampering during transmission and processing are difficult to guarantee. False or contaminated data (such as maliciously reported congestion information or tampered sensor readings) can mislead traffic control systems into making erroneous decisions, leading to traffic disruptions. Existing systems lack transparent, tamper-proof audit mechanisms to trace data origins and processing history, making it difficult to build trust among participating parties.

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

[0008] 5) Limitations of Existing Technical Solutions: While some research has attempted to apply blockchain technology to the transportation sector (e.g., vehicle identity authentication, toll collection, and simple event storage), employ edge computing for preliminary processing, or employ standalone encryption / privacy technologies, these approaches often fail to form a cohesive 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 techniques makes it difficult to conduct effective aggregated analysis while protecting data privacy. A systematic solution that integrates edge processing capabilities, blockchain trust mechanisms, and advanced security and privacy technologies is lacking to comprehensively address the challenges of secure encryption and trusted circulation of transportation data and effectively empower transportation control systems.

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

[0010] To address the aforementioned issues in the background art regarding traffic data collection, processing, and shared circulation, including insufficient security protection, high risk of privacy leakage, low data credibility, difficulties in cross-party collaboration, and limitations of existing technical solutions—particularly the negative impact these issues have on the quality, availability, and security of data required for traffic control systems—the present invention aims to provide an innovative blockchain-based traffic data security encryption and circulation system and its implementation method. This system strives to establish a secure, transparent, efficient, and reliable environment for traffic data circulation and utilization while ensuring data confidentiality, integrity, availability, and user privacy, thereby providing a solid data foundation for enhancing the level of intelligent traffic control.

[0011] To solve the above technical problems, the present 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 processing technologies.

[0012] The blockchain-based traffic data security encryption and circulation system provided by the present 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 (e.g., roadside units (RSUs), onboard units (OBUs), mobile devices, regional servers, etc.). These nodes are responsible for acquiring raw traffic data and performing key localized security processing operations based on pre-set policies. These operations are the first line of defense for ensuring data security and privacy, designed to safeguard the confidentiality or privacy of data. They include, at a minimum, 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, executing the local portion of a secure multi-party computation protocol, generating zero-knowledge proofs, etc.). The goal is to transform data into "securely processed data" that protects the original information before it leaves the edge node.

[0014] b) Blockchain network layer: Serves as the trusted foundation and circulation management center of the system. A series of smart contracts are deployed in the form of consortium chains or private chains. 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 proof, computational integrity proof) or metadata related to securely processed data (such as data hash, timestamp, source node identification, parameters of the type of security processing operation adopted, data circulation log); store or reference access policies used to control data circulation, and implement such policies through smart contracts (such as 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 the security processing operations performed by edge computing nodes; and provide tamper-proof audit logs to enhance the transparency and traceability of the system.

[0015] c) Data Processing and Application Layer: This layer includes one or more data processing units (which can be central servers or clusters of nodes participating in secure multi-party computation). These units are 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). These units generate "circulating data products" (e.g., aggregated traffic flow statistics, trained traffic prediction models, regional congestion indices, verified traffic incident reports, and anonymous travel behavior pattern analysis results) that have application value but do not compromise individual privacy. These data products ultimately serve traffic control applications, for example, 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 transportation scheduling, vehicle cooperative control, or traffic incident management).

[0016] The present invention also provides a method for securely encrypting and distributing traffic data based on this system. This method specifies the complete process and technical implementation details of each link, from data collection, edge security processing, blockchain coordination verification, aggregate analysis, to the final result distribution and application. This method is a method for securely encrypting and distributing traffic data based on blockchain, which is used to support traffic control applications and includes the following steps:

[0017] a) Obtaining raw traffic data at the edge computing node;

[0018] b) the edge computing node performs a security processing operation on the raw traffic data, the operation including at least one of data encryption or privacy-enhancing transformation, to generate securely processed data;

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

[0020] d) receiving and processing the securely processed data from one or more edge nodes in a data processing unit to generate a tradable data product;

[0021] e) utilizing the blockchain network to manage and control the circulation of the tradable data product according to a preset access policy, and securely provide it to the authorized traffic control application or related entity.

[0022] In an optional embodiment, the security processing operation in step b) includes data encryption, specifically using a homomorphic encryption algorithm.

[0023] In an optional embodiment, the secure processing operation in step b) includes a privacy-enhancing transformation, and the privacy-enhancing transformation is selected from: local training of federated learning, differential privacy processing, local processing of secure multi-party computing, or zero-knowledge proof generation.

[0024] In an optional embodiment, in step e), the blockchain network is used to perform dynamic access control based on smart contracts to achieve refined management of the circulation of data products; and the method further includes applying the circulated data product 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 induction, public transportation scheduling, vehicle collaborative control, or traffic event management.

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

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

[0027] 2) Strict privacy compliance: The use of advanced privacy-enhancing technologies (such as federated learning, differential privacy, homomorphic encryption, and ZKP) can achieve data availability and invisibility while meeting the requirements of increasingly stringent data privacy regulations (such as GDPR and the Personal Information Protection Act), maximizing data value while protecting personal privacy.

[0028] 3) Enhanced system trust: The decentralized, transparent, and tamper-proof nature of blockchain provides a natural trust mechanism for data circulation involving multiple parties. Smart contracts automate the execution of rules, reduce collaboration costs, and promote cross-departmental and cross-institutional data sharing.

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

[0030] 5) Good scalability and flexibility: The system adopts a distributed architecture, which is easy to expand to access 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 A schematic diagram of the system architecture.

[0033] Figure 2 Flow chart of the method. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present 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 only used to explain the present invention and are not intended to limit the present invention.

[0035] Example 1: Secure Training and Circulation of Traffic Congestion Prediction Models 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 securely provide the model to traffic signal control systems or traffic information release platforms.

[0037] System Architecture (Refer to Figure 1 ):

[0038] Edge Computing Node (ECN): This can be an onboard OBU or a roadside RSU. Each ECN is equipped with: a data collection 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 (for communicating with the blockchain network and submitting proofs / metadata).

[0039] Blockchain Network (BCN): This utilizes a consortium blockchain and is jointly maintained by major transportation management departments and participating enterprises. Core smart contracts are deployed on the blockchain, 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 the ECN 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 to generate a new global model. This server requires security measures. Alternatively, the DPU can be shared by multiple nodes using the Secure Multi-Party Computation (SMC) protocol to mitigate single-point risks.

[0041] Method flow (refer to Figure 2 ):

[0042] 1) Initialization Phase: a. The Decentralized Processing Unit (DPU) defines the initial congestion prediction model structure (e.g., LSTM, GRU, etc.) and training task parameters (learning rate, training rounds, participating node requirements, etc.). b. The initial model (or its acquisition address) and task parameters are published to the blockchain network through the task management contract. c. Qualified ECNs register and authenticate (e.g., using PKI or DID) through the node management contract to obtain eligibility to participate in the task and obtain task information and the initial model from the blockchain.

[0043] 2) Local Training and Security Processing Phase (performed in multiple rounds): a. Each participating ECN uses its locally collected, privacy-sensitive raw traffic data (such as speed series and flow data from the past period) to train its current model and calculate 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) alternatively, apply differential privacy mechanisms to add an appropriate amount of random noise to the model updates; iii) alternatively, if verification of the computational correctness is required, generate a zero-knowledge proof of 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 ZKP-ed) to the aggregation server (DPU) through its blockchain interaction module. b. Simultaneously, the ECN submits metadata about the update, such as the update hash, timestamp, corresponding training round, the ECN's (anonymous) identity, and possibly ZKP, to the blockchain network's model update management contract. c. The model update management contract verifies the validity of the submitted information (such as node qualifications, timestamp, and ZKP verification) and records the valid contribution on-chain. This provides a basis for subsequent audits 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 a secure aggregation algorithm. For example: i) If the updates are homomorphically encrypted, a weighted average is performed on the ciphertext; ii) If differentially private noise is added to the updates, the average is performed directly (the noise effect will partially cancel each other out after aggregation); iii) If secure multi-party computation is used, each node collaboratively computes the aggregation result, and the server only receives the final aggregate value. The goal is to calculate the global model update while preventing the aggregator from obtaining the original update information of any individual ECN. c. The DPU uses the global update to update the global model.

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

[0047] 6) Application to the system: a. The traffic signal control system, having acquired the model, uses the model to predict traffic congestion at key intersections and road sections within a short timeframe (e.g., 5-15 minutes). b. Based on the predictions, the system can dynamically adjust signal timing (e.g., extending green light duration, adjusting phase shifts) or issue traffic guidance information to guide vehicles away from areas of impending congestion, effectively alleviating congestion and improving road network efficiency.

[0048] Federated learning eliminates the need to upload raw data. Combined with blockchain for trusted coordination and verification, and optionally enhanced with encryption or differential privacy, it enables 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 circulation process (the model itself being a circulated data product) is transparent, trustworthy, and auditable.

[0049] Example 2: Secure traffic flow statistics and circulation based on homomorphic encryption and blockchain

[0050] This embodiment describes in detail how to use the system of the present invention, combined with additive homomorphic encryption technology (such as the Paillier cryptographic system), to accurately calculate key traffic flow indicators (such as average speed and total number of vehicles) for a specific road section or area without decrypting the original observation values ​​of each data source, and to securely circulate these reliable statistical results to traffic control systems (such as variable speed limit systems and ramp control systems) for use.

[0051] Adopting Paillier and other additive homomorphic encryption schemes, its characteristics are (based on a specific public key n), and . This allows addition and constant multiplication operations to be performed directly on the ciphertext. Key management is crucial. The public key PK=(n,g) needs to be securely distributed, and the private key SK=(λ,μ) needs to be strictly kept by the authorized decryption party. Where E(m) represents the ciphertext obtained after the plaintext message m is homomorphically encrypted. E represents the encryption function. m, m1, m2 represent the plaintext data. k represents a constant (or scalar). n, g are the public key (Public Key, PK) components in the Paillier cryptosystem. The public key is securely distributed to each edge computing node (such as RSU) for encrypting data. λ, μ are the private key (Secret Key, SK) components in the Paillier cryptosystem. The private key is strictly kept by the authorized decryption party (in your solution, it is the highly secure trusted decryption service TDS) and is used to decrypt the final ciphertext result after aggregation.

[0052] System component settings:

[0053] 1) Edge Computing Node (ECN): A roadside unit (RSU) deployed at key sections of highways. Equipped with sensors (such as radar and coils) to detect the speed and presence of passing vehicles, it has a built-in encryption module and holds the Paillier public key issued by the Traffic Management Center (TMC).

[0054] 2) Blockchain Network (BCN): This utilizes a consortium blockchain led by the transportation management department to run smart contracts. Key contracts include: RSU_Identity_Contract (manages RSU registration, authentication, and status), Key_Management_Contract (records and distributes the currently valid Paillier public key, its validity period, and applicable scope), Data_Submission_Audit_Contract (records the hash, timestamp, and RSU identifier of the data batch submitted by the RSU), and Result_Access_Control_Contract (manages access rights to the final statistical results).

[0055] 3) Data Processing Unit (DPU): This is a central aggregation server deployed in the TMC, responsible for collecting encrypted data and performing homomorphic operations. The DPU itself does not hold private keys.

[0056] 4) Trusted Decryption Service (TDS): A highly secure, strictly access-controlled service (or hardware security module HSM) deployed within the TMC that holds the Paillier private key and is responsible for decrypting the aggregated ciphertext.

[0057] Detailed workflow:

[0058] 1) Key Deployment and Synchronization: The TMC generates a Paillier key pair (PK, SK). The PK is published on the blockchain through the Key_Management_Contract, specifying its applicable road section and validity period. The RSU verifies its identity through the RSU_Identity_Contract and obtains the latest PK from the blockchain.

[0059] 2) Edge data collection and encryption: 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 ). At the same time, in order to count the number of vehicles, the number "1" is encrypted to obtain E(1). s i Represents the speed of the i-th vehicle, which is a specific plaintext observation value. When calculating the total number of vehicles, the plaintext is the number "1", representing one vehicle.

[0060] 3) Ciphertext submission and on-chain audit: RSU submits the ciphertext of all vehicles in a batch (E(s i ), E(1)) 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 the batch of data (such as the number of ciphertexts included, timestamp, road segment ID, etc.) is calculated, and the Data_Submission_Audit_Contract is called to record (RSU_ID, timestamp, h_meta) on the chain as an unalterable certificate of data submission.

[0061] 4) Centralized homomorphic aggregation: The DPU receives encrypted data submitted by all RSUs on the same road section and within the same time window. Using Paillier's additive homomorphism:

[0062] Calculate the total encryption speed:

[0063] (Multiplication corresponds to the addition of plaintext).

[0064] Calculate the total number of encrypted vehicles:

[0065] Where N is the total number of vehicles.

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

[0067] 6) Circulation and application of results:

[0068] The calculated Average Speed ​​serves as a high-reliability real-time traffic status indicator.

[0069] Application Integration: This Average Speed ​​can be directly input into the control logic of the Variable Speed ​​Limit (VSL) system. For example, if the Average Speed ​​falls below a preset threshold, the VSL system automatically lowers the displayed speed limit for that road section. Alternatively, it can be input into the ramp metering system to dynamically adjust the frequency of vehicle merging onto the ramp based on the average mainline speed.

[0070] The TMC can authorize the final statistical results (or their access rights) to other required systems (such as the traffic information release platform) through the Result_Access_Control_Contract, achieving secure and controllable data circulation. The hash of the result itself can also be recorded on the chain for verification.

[0071] Raw speed data never leaves the RSU in plaintext. Aggregation servers only process ciphertext and are unable to determine individual vehicle speeds. Private keys are strictly controlled within the TDS, reducing the risk of leaks. Blockchain ensures the auditability of data submission and the transparency of results.

[0072] Homomorphic encryption (especially public key operations) has relatively high computational overhead and requires optimized implementation. The security and availability of key management are crucial.

[0073] Example 3: Anonymous travel hotspot analysis and circulation based on local differential privacy and blockchain

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

[0075] LDP mechanisms, for example, can be used for location (usually first gridded or regionalized), using randomized response or more advanced frequency estimation-based mechanisms such as RAPPOR or Harmony. The core approach is to perturb the user's actual location (or region ID) on the device before uploading it. This prevents the server from knowing the true location of any individual, but allows it to calculate regional popularity from the large amount of perturbed data. The key parameter is the privacy budget ε. A smaller ε improves privacy protection, but reduces data availability.

[0076] System component settings:

[0077] 1) Edge Computing Node (ECN): A user's smartphone (running a specific navigation or travel app) or an in-vehicle OBU. This device has a built-in LDP module responsible for local data perturbation.

[0078] 2) Blockchain Network (BCN): This can be a public or consortium chain, 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 user valid data contributions and award points or tokens as incentives), and Aggregated Result Registry Contract (stores metadata and hashes for the final published anonymized heat map or OD statistics report).

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

[0080] Detailed workflow:

[0081] 1) Parameter Acquisition and Local Perturbation: a. The user's app / OBU obtains the current LDP configuration through the Parameter_Distribution_Contract, including the grid definition that divides the city into multiple geographic regions and the privacy budget ε. b. During operation, the device determines the zone ID zone_true, which it primarily resides in or passes through during a certain time period. c. When location information needs to be uploaded, the LDP module on the device reports the true zone ID zone_true with a certain probability p and reports a randomly selected other zone ID with probability (1-p), based on the acquired ε and a mechanism (such as a random response based on an exponential mechanism or unary encoding), to generate the perturbed zone ID zone_perturbed. The probability p is related to ε.

[0082] 2) Perturbation Data Submission and Contribution Recording: a. The device sends (timestamp, zone_perturbed) to the DPU. b. (Optional) The device can submit a simple "contribution" certificate (no data content required) to the Contribution_Reward_Contract. The smart contract verifies the record of contributions and may trigger a reward mechanism.

[0083] 3) Centralized Aggregate Analysis: a. The DPU collects a large number of perturbed zone IDs submitted by users over different time periods. b. The DPU applies a statistical inference algorithm (such as maximum likelihood estimation based on frequency counts or expectation maximization (EM)) that matches the selected LDP mechanism. Based on the known perturbation probability p (deduced by ε), the DPU estimates the real user visit frequency or number of visitors to each zone, zone_j, in each time period from the large amount of zone_perturbed data.

[0084] 4) Result Generation and Distribution: a. Based on the estimated frequency data, the DPU generates aggregated statistical results, such as a visual urban travel heat map and an O / D flow matrix 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, and access link) can be recorded on the blockchain through the Aggregated Result Registry Contract for access by authorized parties.

[0085] 5) Application combination:

[0086] These anonymous heat maps and OD flow analysis results can serve as an important basis for urban transportation planning, identifying traffic bottlenecks and optimizing road network design.

[0087] For the optimization of the public transportation system, bus routes, frequency and station settings can be adjusted according to the travel needs of the people to improve the service level and attractiveness of bus services.

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

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

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

[0091] Example 4: Trusted Verification and Circulation of Traffic Events / Status Based on Zero-Knowledge Proof and Blockchain

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

[0093] Non-interactive ZKP schemes such as zk-SNARKs (succinct and fast to verify, but may require a trusted setup) or zk-STARKs (no trusted setup, quantum-resistant, but larger proofs) are used. The core approach is to construct an Arithmetic Circuit (R1CS) to express the statement to be proved (e.g., "speed v is within the range [min, max] and timestamp t is between [t1, t2]"). The prover then uses their private data (witness) to generate a proof π, and the verifier uses public information to verify π.

[0094] System component settings:

[0095] 1) Edge Computing Node (ECN-Prover): A vehicle OBU, smartphone app, or RSU. It has a built-in ZKP proof generation module and holds its own private data and the key used to generate proofs.

[0096] 2) Blockchain Network (BCN): A consortium chain that runs smart contracts. Key contracts include: Rule Definition Contract (which stores the public description of the verifiable rule, the corresponding ZKP circuit hash, and the verification key), Proof Verification Contract (which contains the ZKP verification algorithm logic and may be implemented as a precompiled contract for improved efficiency), and Verified Assertion Ledger Contract (which records successfully verified assertions and their metadata).

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

[0098] Detailed workflow:

[0099] 1) Rule definition and distribution: Traffic management departments or standards organizations define a series of verifiable traffic rules or status statements in Rule_Definition_Contract, for example:

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

[0101] Rule R2 (speed compliance): speed >= Vmin AND speed <= Vmax FOR duration >= T

[0102] 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 the chain.

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

[0104] 3) Proof Submission and On-Chain Verification: a. The OBU submits the asserted fact (e.g., "I request priority passage based on rule R1") and the proof π to the blockchain, 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 assertion itself) to verify π. This process does not access any private data of the OBU.

[0105] 4) Assertion Recording and Status Updates: a. If verification succeeds, Proof_Verification_Contract triggers Verified_Assertion_Ledger_Contract, which records the successfully verified assertion, for example, (Bus_ID_123, Rule_R1_Passed, timestamp, location_approx). This record is immutable and publicly accessible (to authorized parties). b. For certain stateful assertions (e.g., "Vehicle X's current speed complies with regulations"), the contract may update a temporary state variable for other systems to query.

[0106] 5) Circulation and application of results:

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

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

[0109] Law enforcement assistance: For Rule R2 (speed compliance), verification records can serve as evidence that the vehicle complies with traffic regulations.

[0110] ZKP ensures zero-knowledge proof, allowing vehicles to prove compliance without revealing their speed, precise location, or sensitive credentials. Blockchain ensures transparency, public verifiability, and immutability of the verification process.

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

[0112] It should be noted that the above specific embodiments are merely illustrative of the present invention and are not intended to be limiting. Those skilled in the art, based on their understanding of the core concept of the present invention, may make various modifications, combinations, or equivalent substitutions, such as adjusting the specific deployment location of edge computing nodes, the selection of blockchain consensus mechanisms, the setting of specific encryption algorithms or privacy protection parameters, etc. These modifications, which do not depart from the spirit and scope of the present invention, shall be included within the scope of protection of the present invention.

Claims

1. A traffic data security encryption and circulation system based on blockchain, characterized by: The system is configured to process traffic data related to traffic control applications, the system comprising: 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; Performing a security processing operation on the raw traffic data to generate securely processed data, wherein the security processing operation is intended to ensure confidentiality or privacy of the data, and the operation includes at least one of data encryption or privacy-enhancing transformation; A blockchain network, wherein the blockchain network is deployed with a smart contract and is in communication with the edge computing node, wherein the blockchain network is configured as follows: Managing identity or credential information associated with the edge computing node; Recording verification information or metadata related to the securely processed data; Store or reference access policies used to control the flow of data; A data processing unit configured as: receiving the securely processed data from one or more edge computing nodes; Aggregate, analyze or further process the securely processed data to generate tradable data products; In particular, the blockchain network controls the circulation process of the circulated data product based on the access policy, so that authorized entities can safely obtain the data of the traffic control application. At the same time, the secure processing operations of the edge computing nodes protect the original traffic data from unauthorized access.

2. The system according to claim 1, wherein: The security processing operations performed by the edge computing node include data encryption, and the data encryption adopts a homomorphic encryption algorithm, so that the data processing unit can perform aggregation operations on the securely processed data without decryption.

3. The system according to claim 1, wherein: The secure processing operations performed by the edge computing node include privacy-enhancing transformations, and the privacy-enhancing transformations are selected from at least one of the following: performing local model training for federated learning, applying a differential privacy mechanism to add noise, performing a local part of a secure multi-party computing protocol, and generating a zero-knowledge proof.

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

5. The system according to claim 3, wherein: The privacy enhancement is converted to generate a zero-knowledge proof, the securely processed data includes the zero-knowledge proof, the blockchain network is configured to verify the validity of the zero-knowledge proof through a smart contract, and the tradable data product is a verified status assertion or event report.

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

7. The system according to claim 1, wherein: When aggregating securely processed data, the data processing unit further adopts a secure aggregation protocol or secure multi-party computing technology to enhance the security of the aggregation process; the tradable data product is directly or indirectly used as input to support the implementation or optimization of at least one traffic control function, and the function is selected from: traffic signal control, traffic flow prediction, congestion management, route planning and induction, public transportation scheduling, vehicle collaborative control or traffic event management.

8. A method for realizing secure encryption and circulation of traffic data based on blockchain, characterized in that: The method is applied to support traffic control applications and includes the following steps: a) Obtaining raw traffic data at the edge computing node; b) the edge computing node performs a security processing operation on the raw traffic data to generate securely processed data, wherein the operation includes at least one of data encryption or privacy-enhancing transformation; c) managing, through a blockchain network, identity, metadata, or verification information associated with the edge computing node and the securely processed data; d) receiving and processing the securely processed data from one or more edge computing nodes in a data processing unit to generate a circulated data product; e) utilizing the blockchain network to manage and control the circulation of the tradable data product according to a preset access policy, and securely provide it 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-enhancing transformation, and the privacy-enhancing transformation is selected from: local training of federated learning, differential privacy processing, local processing of secure multi-party computing, 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.

10. The method according to claim 9, characterized in that The method further includes applying the circulated data product to optimize traffic control functions.

Images