Cross-piece consensus method and system for mobile nodes in vehicle infrastructure cooperative network

Abstract

The invention relates to the technical field of intelligent traffic and Internet of Vehicles, in particular to a cross-piece consensus method and system for mobile nodes in a cooperative vehicle infrastructure network. The cross-piece consensus is realized through five steps of node cross-piece switching, MBF construction, relay voucher delocalization generation, cross-piece topology stitching and access verification and non-interactive global state newest verification. A boundary buffer distance is set to avoid frequent slice crossing, a verification process is simplified by using an MBF and a Merkel tree, data authenticity is guaranteed through a causal relay voucher and bidirectional reference, global state verification can be completed without source slice interaction, and the efficiency and security of slice crossing consensus are improved.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation and vehicle networking technology, and more specifically, to a cross-slice consensus method and system for mobile nodes in a vehicle-road cooperative network. Background Technology

[0002] Vehicle-road cooperative networks are a key technology carrier for intelligent transportation systems. Their core lies in the segmented management architecture of roadside units (RSUs) to realize information interaction and consensus collaboration among mobile vehicle nodes. The reliability of cross-segment consensus directly determines the efficiency and security of traffic data collaboration.

[0003] Under the current sharded architecture of vehicle-road cooperative systems, vehicle nodes need to frequently switch between different RSU management areas. However, existing cross-shard movement processing solutions have obvious defects: First, there is a causal island problem, where the new shard does not store the underlying data of the vehicle's original shard, resulting in the inability to verify the vehicle's behavior history in real time after crossing shards, and the causal chain is broken. Second, it is vulnerable to state rollback attacks, where malicious nodes can conceal negative behaviors of the old shard and submit earlier and better outdated hashes to the new shard to forge the state. Third, the risk of synchronization delay is prominent. If real-time data retrieval and verification between RSUs is relied upon, backbone network bandwidth and network jitter will lead to excessively high access latency, which cannot meet the needs of highly real-time scenarios such as autonomous driving.

[0004] To address the technical challenges of cross-segment scenarios in vehicle-road cooperative networks, this invention proposes a cross-segment consensus method and system for mobile nodes in vehicle-road cooperative networks, thereby overcoming the shortcomings of existing solutions. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a cross-slice consensus method and system for mobile nodes in vehicle-road cooperative networks.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network specifically includes the following steps:

[0008] Step 1, Cross-segment node switching: Divide the network into segments according to geographical location, set boundary buffer distance parameters to adapt to positioning error, vehicle speed and road environment, and determine the cross-segment switching trigger conditions based on the distance between the node and the segment boundary line;

[0009] Step 2, MBF Construction: Select a family of hash functions and determine the length of the Bloom filter bit array. Generate an MBF based on the weakly consistent confirmation transaction set within a consensus cycle of the source shard. Embed the MBF into the L2 anchor vertex and broadcast it to all RSUs in the network.

[0010] Step 3, Off-domain generation of relay certificate: The mobile node extracts the hash value of the last weak consistency confirmation transaction vertex in the source shard, obtains the global L2-DAG anchor record index corresponding to the hash value, constructs an inclusion proof based on the Merkle tree, and packages the node's unique identity, the hash value of the last transaction vertex, the L2 anchor record index and the Merkle inclusion proof into a causal relay certificate.

[0011] Step 4, Cross-shard topology stitching and access verification: After a node enters the target shard, it sends an access stitching vertex. This vertex contains the causal relay credential. The parent reference set contains the hash value of the last transaction vertex of the source shard and the hash value of the latest end vertex of the target shard. The target shard RSU checks the access stitching vertex for credential integrity and parent reference rules.

[0012] Step 5: Non-interactive global state up-to-dateness verification: The target shard RSU extracts the corresponding L2 anchor vertex and subsequent anchor vertex, verifies the authenticity of the transaction through Merkel proof, traverses MBF to query the node transaction records, verifies whether the node's committed state is the global up-to-date state, and completes cross-shard consensus.

[0013] This invention also provides a cross-slice consensus system for mobile nodes in a vehicle-road cooperative network, including a node cross-slice switching module for performing the operation of step one of claim 1 to achieve stable slicing switching; a member change Bloom filter construction module for performing the operation of step two of claim 1 to generate an MBF and embed it into L2 anchor vertex broadcast; a relay credential delocalization generation module for performing the operation of step three of claim 1 to support nodes to autonomously synthesize causal relay credentials; a cross-slice topology stitching and access verification module for performing the operation of step four of claim 1 to construct access stitching vertices and perform preliminary verification; and a non-interactive global state up-to-dateness verification module for performing the operation of step five of claim 1 to complete node state verification and cross-slice consensus.

[0014] Furthermore, in step one, the geographical area division of the network segments adopts a square or circular area division method. Each roadside unit is responsible for managing one or more adjacent segments, and the boundary buffer distance parameter avoids frequent cross-segmentation caused by positioning fluctuations.

[0015] Furthermore, in step two, the MBF generation process is as follows: for each weakly consistent confirmation transaction within the source shard consensus period, hash calculation is performed using each hash function in the hash function family, and the bit of the corresponding index in the Bloom filter bit array is set to 1; the L2 anchor vertex also contains transaction timestamps and shard identifier metadata.

[0016] Furthermore, in step three, the mobile node obtains the global L2-DAG anchor record index through local communication with the source shard RSU. The Merkle tree consists of leaf nodes composed of the weakly consistent confirmation transaction set within the source shard consensus period, intermediate nodes are the hash values ​​of the corresponding child nodes, and the root node is the Merkle tree root in the L2 anchor vertex.

[0017] Furthermore, in step four, the parent reference set of the access stitching vertex contains only one historical hash value from the source shard. After the target shard's RSU preliminary verification is passed, the access stitching vertex is not broadcast for the time being. It will be woven into the local topology after the global state up-to-dateness verification is passed.

[0018] Furthermore, in step five, the global state up-to-dateness verification includes transaction existence verification and last transaction check. Transaction existence verification is achieved through Merkle proof and consistency verification with the Merkle root of the L2 anchor point. Last transaction check is achieved by traversing the MBF of subsequent L2 anchor points and combining it with secondary confirmation to exclude false positive results.

[0019] Furthermore, the secondary confirmation is as follows: when the MBF query result is True, the target shard RSU sends a request to the corresponding source RSU to confirm whether the node has generated a transaction within the anchor period, thereby preventing state rollback attacks.

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

[0021] 1. By leveraging an enhanced anchored vertex structure, a state root and a membership variation Bloom filter (MBF) are integrated into the anchored vertices at the L2 layer, providing a data foundation for cross-shard shadow verification. This design allows new shards to quickly match the historical membership information of vehicle nodes without having to pull the full data from the original shard, directly solving the causal island problem caused by shard data isolation in existing technologies and ensuring the traceability of behavioral history when crossing shards;

[0022] 2. By employing a cross-domain causal pointer forced association mechanism, newly connected nodes are required to reference historical vertices from different locations in their first data packet, thus constructing a unidirectional causal chain in the spatial dimension of the asynchronous DAG. This technical feature restricts the operational space for malicious nodes to conceal negative behaviors of old shards from a process perspective, effectively avoiding the risk of state rollback attacks and improving the security and data consistency of cross-shard consensus;

[0023] 3. An offline, self-proving verification process is adopted, with mobile nodes carrying verification evidence and local caching providing the verification benchmark, eliminating the need for point-to-point connections between RSUs. This solution avoids the limitations of backbone network bandwidth and network jitter, significantly reduces cross-slice access latency, and can adapt to the needs of highly real-time scenarios such as autonomous driving, while also avoiding the impact of network partitions on consensus. Attached Figure Description

[0024] Figure 1 A flowchart of a cross-slice consensus method for mobile nodes in a vehicle-road cooperative network;

[0025] Figure 2 This is a structural block diagram of the cross-slice consensus system for mobile nodes in the vehicle-road cooperative network of the present invention. Detailed Implementation

[0026] Example 1, refer to Figure 1 The cross-slice consensus method for mobile nodes in the vehicle-road cooperative network of this embodiment operates on a two-layer asynchronous DAG (Directed Acyclic Graph) architecture. Its core functionality utilizes a causal relay mechanism to achieve efficient and secure consensus when mobile nodes cross slices. The core definition and division of labor of the two-layer DAG are explained below:

[0027] L1-DAG (Sharded Local Layer): This is a local transaction topology network dedicated to each shard, with each node representing a single transaction record. It only stores "weakly consistent" transactions within the corresponding shard (i.e., transactions where nodes within the shard have reached a local consensus). It is responsible for real-time transaction processing and local consensus within the shard, and does not communicate directly with other shards, ensuring low latency in local transaction processing.

[0028] L2-DAG (Global Anchoring Layer): A globally shared state anchoring network, with nodes serving as "anchor vertices." It is constructed by Roadside Units (RSUs) of each shard periodically broadcasting anchor vertices to the entire network. Each anchor vertex contains core metadata such as the Merkle root of transactions for a consensus cycle of the corresponding shard, a member change Bloom filter (MBF), timestamps, and shard identifiers. It is responsible for recording the global consensus state of the entire network, providing a unified benchmark for cross-shard verification.

[0029] The specific implementation steps are as follows:

[0030] Step 1, Cross-shard node switching: A stable shard switching mechanism based on a spatial lag buffer.

[0031] S11. Geographical partitioning rules:

[0032] The vehicle-road cooperative network is segmented based on GPS geographic location. Each segment corresponds to a specific geographic area and can be divided into square or circular areas (this embodiment uses square areas). Each roadside unit (RSU) is responsible for managing one or more adjacent geographic grids (i.e., segments). The size of the geographic grid is set according to the actual application scenario. For example, in the urban road scenario, the side length of each square segment is set to 100 meters. This value can balance the management load of the RSU and the frequency of node crossing between segments, avoiding local transaction processing delays caused by excessively large segments or excessively frequent crossing between segments caused by excessively small segments.

[0033] S12. Definition and values ​​of spatial hysteresis buffer parameters:

[0034] Set boundary buffer distance This parameter is used to determine whether a node truly needs to perform a cross-segment handover, and its value needs to comprehensively consider factors such as GPS positioning error, vehicle speed, and road conditions. In this embodiment, The value is set at 20 meters, based on the following:

[0035] The positioning error of common civilian GPS devices is usually within the range of 5-10 meters. A buffer distance of 20 meters can effectively offset the impact of positioning error. In urban roads, the vehicle speed generally does not exceed 60 km / h (about 16.7 m / s). Even if the GPS has the maximum error, the vehicle will not experience cross-chip response delay in a short period of time due to the buffer distance being set too large.

[0036] S13, Segment switching trigger condition determination:

[0037] Let the source shard where the current node is located be The target fragment to be entered is , for and The physical boundary line between them The current GPS coordinates of the node. The current node and the physical boundary line The straight-line distance;

[0038] When the node is And towards During operation, the GPS coordinates of the nodes are obtained in real time. and calculate ;

[0039] like If a node crosses the physical boundary and exceeds the buffer distance, the cross-shard switching logic is triggered, and the node switches from... Switch to ;like Even if the node's GPS coordinates have geometrically slightly entered The node remains in China should participate in the consensus to avoid frequent cross-chip issues caused by minor GPS fluctuations.

[0040] Step 2, Member Variable Bloom Filter (MBF) Construction: Lightweight index construction based on L2 anchors.

[0041] This step adds a Membership Variable Bloom Filter (MBF) to the L2 layer anchor vertex, providing a basis for local offline consistency comparison for the target shard RSU. This allows the target shard to quickly determine the node's transaction participation in the source shard without having to retrieve the full data, reducing the space and time complexity of cross-shard verification.

[0042] S21. Definition and values ​​of core parameters for Bloom filters:

[0043] Hash function family Select k independent hash functions to map transaction data into the bit array. In this embodiment, k is set to 3. The reason for this value is that in the false positive rate control of the Bloom filter, when k=3, the bit array length m and the data volume n satisfy m≈4.3n, a low false positive rate (about 0.05) can be achieved, while avoiding the increase in computational overhead caused by too many hash functions.

[0044] The bit array length m is determined based on the expected maximum number of transactions n in one cycle of the source fragment. In this embodiment, m is set to 4.3n (n is 1000, i.e., m = 4300). This value can reasonably control the storage space occupation of the Bloom filter while ensuring a low false positive rate.

[0045] S22, MBF Data Sources and Generation Rules:

[0046] Data source: MBF's data originates from source fragments. The set of all "weakly consistent" confirmed transactions generated within a consensus period T. ("Weak consensus confirmation" means that a transaction has received preliminary confirmation from nodes within the L1-DAG, thus satisfying the local consensus requirement.)

[0047] The value of consensus period T is set according to the transaction processing frequency of the vehicle-road cooperative network. In this embodiment, T=100 milliseconds. This value can balance the timeliness and processing efficiency of L2 layer anchoring, and avoid frequent anchoring caused by too short a period, or the cross-shard verification benchmark lagging caused by too long a period.

[0048] Generation rules: For sets Every transaction in (Right now ), and then use each hash function in the hash function family H in turn. (Right now )right Perform a hash calculation to obtain the hash value. And the corresponding index in the Bloom filter bit array The bit is set to 1, that is .

[0049] Merging of S23, MBF, and L2 anchor point vertices:

[0050] When constructing anchor vertices at L2 layer, in addition to including necessary metadata such as the Merkle root hash of the transaction to be submitted, the transaction timestamp, and the shard identifier, the generated MBF is embedded as core index data into the L2 anchor vertices and broadcast to all RSUs across the network through the L2 backbone network. This ensures that each shard RSU can cache the MBF, providing data support for subsequent cross-shard verification.

[0051] Step 3: Off-domain generation of relay credentials: Nodes autonomously construct cross-shard identity and status proofs.

[0052] This step is initiated by the mobile node. It extracts the node's last transaction state in the source shard, obtains global anchoring information, constructs Merkel proof, and finally synthesizes a causal relay certificate. This certificate is used to prove the authenticity and integrity of the node's historical state to the target shard and is the core of realizing node self-proof.

[0053] S31. Final state extraction:

[0054] When the node is moved Based on the determination rules in step one, determine which will be from Switch to At that time, its on-board unit (OBU) first searches for itself in Given an L1-DAG topology, extract the hash value of the last transaction vertex that has completed "weak consistency confirmation" published by itself. This hash value uniquely identifies the node. The final transaction status;

[0055] S32. Anchoring Information Acquisition:

[0056] node Through with The RSU performs local communication (using the DSRC protocol or 5G-V2X protocol commonly used in vehicle-to-everything (V2X) communication) to obtain... Corresponding global L2-DAG anchored record index . It is a unique sequence number of the L2 anchor vertex, used to locate the position of the anchor vertex in the global L2-DAG. Through this index, the corresponding global state root and MBF can be quickly associated.

[0057] S33, Merkel's proof construction:

[0058] Merkle tree structure description: The set of transactions with "weak consistency confirmation" within period T The leaf nodes of a Merkle tree are the intermediate nodes of a Merkle tree, the middle nodes of a Merkle tree are the hash values ​​of their corresponding child nodes, and the root node is the Merkle tree root (Root Hash) in the L2 anchor vertex.

[0059] Proof path length: The path length proved by Merkel is (n is) The number of transactions (i.e., the number of tree nodes in the Merkel tree), rounded up, for example, when n=1000. Rounded down to 10, this proves that the path contains the hash values ​​of 10 adjacent intermediate nodes;

[0060] Detailed construction process: Nodes Extract transaction data from the leaf nodes of the L1-DAG stored data. The hash values ​​of all adjacent intermediate nodes leading to the root node of the Merkel tree are used to form the Merkel containment proof. This proof can be verified. It definitely belongs to the corresponding Merkle tree, ensuring its authenticity;

[0061] S34. Synthesis of Causal Relay Evidence:

[0062] Pack the following core information into tuples ,Right now The parameters are explained below:

[0063] For mobile nodes The unique identifier uses a blockchain address format (such as a 256-bit hash value) to ensure the uniqueness and unforgeability of the node's identity;

[0064] For nodes in The hash value of the last transaction vertex serves as the core identifier of the node's historical state;

[0065] for The corresponding L2 anchor point sequence number is used as the global verification benchmark for target piece localization;

[0066] Includes proof for Merkel to verify. The authenticity and completeness of.

[0067] Step 4, Cross-slice topology stitching and access verification: Access based on forced causal binding.

[0068] This step achieves topology fusion between the mobile node and the target shard. It establishes cross-shard causal continuity by requiring the first access transaction vertex of the node to contain cross-shard causal references and local synchronization references. At the same time, the target shard RSU performs preliminary verification of the access request to ensure the legitimacy of the access.

[0069] S41, Connecting to stitch vertex construction:

[0070] When node Crossing physical boundaries to enter the target fragment Afterwards, towards The RSU sends the first business transaction vertex, which is defined as the access stitching vertex. Its core characteristic is that the parent reference set P must strictly follow the two-way reference rule, that is... The citations are explained below:

[0071] Vertical referencing (cross-slice causality): For nodes in The final transaction vertex hash value, which is referenced, establishes a unique linear causal sequence for the node across the entire network, ensuring that the node is... Historical behavior visible;

[0072] Horizontal references (local synchronization): for The hash values ​​of the k1 latest terminal vertices in the current L1-DAG, where the value of k1 is based on... In this embodiment, the network size is set as k1=3, and the value is determined based on the fact that 3 terminal vertices can cover the network. The main transaction branch ensures that the node and the target shard are synchronized in time and space, while avoiding increased verification complexity due to excessive references;

[0073] Construction requirements: It must include the causal relay certificate generated in step three. And the parent reference set can only contain one historical hash value from the source shard (i.e., ), to avoid multi-source causal conflicts;

[0074] S42. Access to the suture verification process:

[0075] The RSU received Then, perform the following verification operations:

[0076] Document integrity check: verification Does it contain complete evidence of cause and effect? Whether it contains , , , Four core fields; if any field is missing, access will be rejected outright.

[0077] Parent reference rule check: Validation If the parent reference set P satisfies the rule of "containing one and only one source shard history hash value", and there are zero or more source shard history hash values, it is determined to be an illegal access and the broadcast of the vertex is refused;

[0078] After the initial verification is passed, the RSU will not proceed for the time being. Broadcast to The L1-DAG needs to wait for the shadow verification in step five to pass before the formal connection stitching can be completed. Weaving The local topology.

[0079] Step 5: Non-interactive global state up-to-dateness verification: Shadow verification based on L2 Bloom filter.

[0080] This step is the core of cross-shard verification. The target shard RSU performs non-interactive verification on the causal relay credentials submitted by the node based on the locally cached L2 layer metadata (including MBF). It can verify whether the state submitted by the node is the latest global state without communicating with the source shard, thus preventing state rollback attacks.

[0081] S51. Verification preparation work:

[0082] The RSU receives the node After receiving the access request, retrieve the following data from the local cache:

[0083] and The corresponding L2 anchor vertex (including the Merkle root RootHash, MBF, etc. of the anchor);

[0084] Serial number greater than All subsequent L2 anchor vertices (i.e., those in the sequence number range) ,in (The latest L2 anchor sequence number cached locally).

[0085] Validation tool: Deploy Bloom filter query function This function receives MBF and node identity identifier. ,return Is it in The record exists (Return True if it exists, False if it does not exist);

[0086] S52. Transaction Existence Verification:

[0087] This verification is used to validate the node's submission. Whether it actually exists in the corresponding global L2 anchor point, the specific process is as follows:

[0088] Anchor point validity check: First determine If the corresponding L2 anchor point has been confirmed locally (i.e., the anchor point has been approved by the L2 backbone network consensus), the access request will be suspended and the verification will continue after the anchor point is confirmed. The suspension timeout is set to 50 milliseconds. If the connection is not confirmed after the timeout, the access will be rejected.

[0089] Merkel proof verification: using the credentials , and The corresponding L2 anchor point Merkle tree root hash is used for consistency verification. The verification process is as follows: and The hash values ​​of intermediate nodes in the algorithm are derived in reverse according to the Merkle tree calculation rules to obtain a derived root hash. If the derived root hash is completely consistent with the root hash of the L2 anchor, the verification passes (i.e., ...). ),prove It must be a genuine and valid historical transaction record; if it is inconsistent, the record will be deemed forged and access will be denied.

[0090] S53, Last Transaction Check:

[0091] This check is used to verify whether a node has concealed information. To prevent state rollback attacks in subsequent transactions, the specific process is as follows:

[0092] Traversing subsequent MBFs: RSU sequentially extracts sequence number ranges. MBF of each L2 anchor vertex (denoted as (where r is the anchor sequence number within that interval).

[0093] Bloom filter query: for each Call the query function Determine the node's identity. Does it exist in middle;

[0094] Result determination:

[0095] Case 1 (all are False): If all... The query results are all False, indicating that the node is... After the corresponding period, no transactions were generated in any shard of the entire network, and the submitted transactions... It is the latest global state, and the latestness check has passed;

[0096] Case 2 (True exists): If any The query result is True. Due to the extremely small false positive probability of Bloom filters (approximately 0.05 in this example), the RSU needs to notify the publisher. The source RSU initiates a second confirmation request (using lightweight RESTful API communication) to inquire... Check whether a transaction actually occurred within the anchor period; if the source RSU confirms the existence of a transaction, the node is deemed to have a state rollback attack and access is denied; if the source RSU confirms that no transaction exists (i.e., a false positive), the up-to-dateness check passes.

[0097] S54. Final Access Decision:

[0098] Let Valid be the access pass flag. Valid = True if and only if the transaction existence check and the up-to-dateness check pass, that is:

[0099] ;

[0100] If Valid=True, The RSU will Official broadcast to In an L1-DAG, nodes Successful connection It participates in subsequent consensus; if Valid=False, it returns an access failure response to the node, explaining the reason for the failure (such as credential forgery, state rollback attack, etc.).

[0101] Example 2, refer to Figure 2 The cross-slice consensus system for mobile nodes in the vehicle-road cooperative network of this embodiment includes a node cross-slice switching module, a member change Bloom filter construction module, a relay certificate de-domain generation module, a cross-slice topology stitching and access verification module, and a non-interactive global state up-to-date verification module.

[0102] Cross-shard node switching module: This module employs a stable sharding switching technology based on spatial hysteresis buffers. It divides the network into shards according to geographical location, sets boundary buffer distances to adapt to node movement characteristics and positioning errors, and determines the cross-sharding trigger condition based on the distance between the node and the shard boundary. This effectively avoids frequent cross-sharding caused by positioning fluctuations, balances sharding management load with cross-sharding response efficiency, ensures network connectivity continuity during node movement, and lays a solid foundation for cross-sharding consensus.

[0103] Membership Change Bloom Filter Construction Module: This module builds a lightweight index based on a global anchoring layer, selects an appropriate hash function family and bit array length, extracts the local consensus transaction set of the shard to generate the MBF, and embeds it into the global anchor vertex for broadcasting to the entire network. Leveraging the efficient mapping characteristics of the Bloom filter, the target shard can quickly determine the historical transaction status of nodes without retrieving the entire dataset, significantly reducing the time and space complexity of cross-shard verification.

[0104] Off-domain generation module for relay credentials: This module supports mobile nodes in autonomously constructing cross-shard identity and status proofs, extracting the node's final transaction status identifier in the source shard, obtaining the global anchor index through the vehicle-road cooperative communication protocol, constructing transaction authenticity proofs based on Merkle trees, and packaging them into causal relay credentials. This enables node self-proofing, verifying the authenticity and integrity of historical states without relying on source shard interactions, providing core evidence for cross-shard verification;

[0105] Cross-shard topology stitching and access verification module: This module achieves topology fusion based on forced causal binding, constructing access stitching vertices containing cross-shard causal references, local synchronization references, and causal relay credentials. The target shard RSU verifies the integrity of the credentials and the parent reference rules, filters legitimate access requests, and after global verification passes, the vertices are woven into the local topology to prevent illegal access and multi-source causal conflicts, ensuring the legitimacy of cross-shard access;

[0106] Non-interactive Global State Update Verification Module: This module employs shadow verification technology based on L2 Bloom filters. The target shard's RSU extracts global anchor data, verifies transaction authenticity using Merkle proofs, and traverses the MBF to query node transaction records and eliminate false positives. Global state update verification can be completed without communication with the source shard, preventing state rollback attacks and providing a secure and reliable final determination basis for cross-shard access.

[0107] Through the detailed description of the above embodiments, the cross-shard consensus method and system for mobile nodes in the vehicle-road cooperative network of the present invention divides the local transaction layer and the global anchoring layer into a two-layer asynchronous DAG architecture, and constructs a complete cross-shard consensus system through a five-step core process. By leveraging key technologies such as boundary buffer shard switching, MBF lightweight indexing, causal relay credential self-proofing, and non-interactive global verification, it effectively solves the problems of frequent cross-sharding, complex verification, high latency, and security risks in existing technologies. This solution significantly improves verification efficiency while ensuring cross-shard consensus security and data consistency, adapts to the high-speed movement characteristics of mobile nodes in vehicle-road cooperative scenarios, and provides reliable technical support for efficient collaboration in intelligent transportation.

[0108] The above formulas are all dimensionless calculations, and the preset parameters in the formulas should be set by those skilled in the art according to the actual situation.

[0109] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0110] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0114] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cross-slice consensus method for mobile nodes in a vehicle-road cooperative network, characterized in that, The method flow is as follows: Step 1, Cross-segment node switching: Divide the network into segments according to geographical location, set boundary buffer distance parameters to adapt to positioning error, vehicle speed and road environment, and determine the cross-segment switching trigger conditions based on the distance between the node and the segment boundary line; Step 2, MBF Construction: Select a family of hash functions and determine the length of the Bloom filter bit array. Generate an MBF based on the weakly consistent confirmation transaction set within a consensus cycle of the source shard. Embed the MBF into the L2 anchor vertex and broadcast it to all RSUs in the network. Step 3, Off-domain generation of relay certificate: The mobile node extracts the hash value of the last weak consistency confirmation transaction vertex in the source shard, obtains the global L2-DAG anchor record index corresponding to the hash value, constructs an inclusion proof based on the Merkle tree, and packages the node's unique identity, the hash value of the last transaction vertex, the L2 anchor record index and the Merkle inclusion proof into a causal relay certificate. Step 4, Cross-shard topology stitching and access verification: After a node enters the target shard, it sends an access stitching vertex. This vertex contains the causal relay credential. The parent reference set contains the hash value of the last transaction vertex of the source shard and the hash value of the latest end vertex of the target shard. The target shard RSU checks the access stitching vertex for credential integrity and parent reference rules. Step 5: Non-interactive global state up-to-dateness verification: The target shard RSU extracts the corresponding L2 anchor vertex and subsequent anchor vertex, verifies the authenticity of the transaction through Merkel proof, traverses MBF to query the node transaction records, verifies whether the node's committed state is the global up-to-date state, and completes cross-shard consensus.

2. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 1, characterized in that, In step one, the geographical area division of the network segments adopts a square or circular area division method. Each roadside unit is responsible for managing one or more adjacent segments. The boundary buffer distance parameter avoids frequent cross-segmentation caused by positioning fluctuations.

3. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 1, characterized in that, In step two, the MBF generation process is as follows: for each weakly consistent confirmation transaction within the source shard consensus period, hash calculation is performed using each hash function in the hash function family, and the bit of the corresponding index in the Bloom filter bit array is set to 1; the L2 anchor vertex also contains transaction timestamps and shard identifier metadata.

4. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 1, characterized in that, In step three, the mobile node obtains the global L2-DAG anchor record index by communicating locally with the source shard RSU. The Merkle tree consists of leaf nodes composed of the weakly consistent confirmation transaction set within the source shard consensus period, intermediate nodes are the hash values ​​of the corresponding child nodes, and the root node is the Merkle tree root in the L2 anchor vertex.

5. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 1, characterized in that, In step four, the parent reference set of the access stitching vertex contains only one historical hash value from the source shard. After the target shard passes the initial RSU verification, the access stitching vertex is not broadcast for the time being. It will be woven into the local topology after the global state up-to-dateness verification is passed.

6. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 1, characterized in that, In step five, the global state up-to-dateness verification includes transaction existence verification and last transaction check. Transaction existence verification is achieved through the consistency verification of Merkle proof and L2 anchor Merkle root. Last transaction check is achieved by traversing the MBF of subsequent L2 anchors and combining it with secondary confirmation to exclude false positive results.

7. The cross-slice consensus method for mobile nodes in a vehicle-road cooperative network according to claim 6, characterized in that, The secondary confirmation is as follows: when the MBF query result is True, the target shard RSU sends a request to the corresponding source RSU to confirm whether the node has generated a transaction within the anchor period, thereby preventing state rollback attacks.

8. A cross-slice consensus system for mobile nodes in a vehicle-road cooperative network, used to implement the cross-slice consensus method for mobile nodes in a vehicle-road cooperative network as described in any one of claims 1-7, characterized in that, The system includes a node cross-shard switching module, used to perform the operation of step one of claim 1 to achieve stable shard switching; a member variable Bloom filter construction module, used to perform the operation of step two of claim 1 to generate an MBF and embed it into L2 anchor vertex broadcast; a relay credential delocalization generation module, used to perform the operation of step three of claim 1 to support nodes to autonomously synthesize causal relay credentials; a cross-shard topology stitching and access verification module, used to perform the operation of step four of claim 1 to construct access stitching vertices and perform preliminary verification; and a non-interactive global state up-to-dateness verification module, used to perform the operation of step five of claim 1 to complete node state verification and cross-shard consensus.

Images