Blockchain-based secure communication method and system for internet of vehicles

Abstract

This invention provides a blockchain-based secure communication method and system for connected vehicles. The method includes: generating a unique vehicle digital gene by integrating the hardware response value and static identifier of the vehicle's built-in PUF circuit; and deploying a finite state machine smart contract on the blockchain to manage the vehicle's manufacturing, usage, and transaction states. During vehicle usage, a key pair is activated for secure communication, and consensus-verified interactions are anchored to the contract in the form of a reputation digest. When responding to an ownership transfer request jointly signed by the original owner, the new owner, and a third party, the contract enters a transaction state and initiates a permission decay mechanism, gradually reducing the original owner's permissions. After consensus is reached, through an atomic transaction, the public key and anchored reputation digest control in the contract are completely and synchronously transferred to the new owner, and finally, the contract state is updated to reflect the new owner's vehicle usage state. This invention achieves secure management and reputation inheritance throughout the vehicle's entire lifecycle.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a blockchain-based secure communication method and system for vehicle networking. Background Technology

[0002] As a core support for the development of intelligent transportation systems and autonomous driving technologies, the Internet of Vehicles (IoV) significantly improves traffic efficiency and driving safety by enabling efficient information exchange between vehicles and between vehicles and infrastructure. In this highly interconnected environment, ensuring secure and reliable communication is the cornerstone of the entire system's operation. Currently, most IoV security systems draw on traditional Public Key Infrastructure (PKI), using centralized certificate authorities to issue digital certificates for vehicles to achieve identity authentication and communication encryption. This model can, to a certain extent, resist external attacks and ensure the security of communication content.

[0003] However, existing security frameworks primarily focus on the instantaneous security of vehicles at the communication interaction level, generally neglecting the management of the continuity, trustworthiness, and transferability of a vehicle's digital identity throughout its entire lifecycle as a long-term asset. From manufacturing and sales to multiple resales and eventual scrapping, a vehicle's ownership changes hands multiple times. Under traditional centralized management models, a vehicle's digital identity is typically separated from its historical interaction data. When vehicle ownership changes, the historical reputation data accumulated in the vehicle network cannot be securely and reliably transferred to the new owner, resulting in the loss of valuable data assets. Furthermore, the ownership transfer process often relies on offline procedures and updates to centralized systems, which are complex and time-consuming, creating security vulnerabilities for attackers to impersonate the owner or tamper with information during the window of permission changes. Summary of the Invention

[0004] This invention provides a blockchain-based secure communication method and system for vehicle networks to solve the aforementioned technical problems.

[0005] In a first aspect, the present invention provides a blockchain-based secure communication method for vehicle-to-everything (V2X) communication, the method comprising the following steps:

[0006] The hardware response value generated by the PUF circuit built into the target vehicle is integrated with the static identifier of the target vehicle to generate a unique vehicle digital gene for the target vehicle. Based on the vehicle digital gene, a finite state machine smart contract containing preset life cycle states is deployed on the blockchain for the target vehicle. The preset life cycle states include the vehicle manufacturing state, the vehicle usage state, and the vehicle transaction state.

[0007] Based on the vehicle usage state of the finite state machine smart contract, activate the key pair for vehicle-to-everything (V2X) communication for the vehicle's onboard communication unit, and when the target vehicle generates a valid interaction that is verified by consensus, anchor the reputation digest of the valid interaction in the form of a hash chain to the finite state machine smart contract.

[0008] In response to an ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party, the state of the finite state machine smart contract is switched from the vehicle usage state to the vehicle transaction state, and a permission decay mechanism is initiated to gradually reduce the communication permissions of the key pair held by the original vehicle owner in the vehicle transaction state.

[0009] After the ownership transfer request is verified through blockchain network consensus, the valid public key recorded in the finite state machine smart contract is updated to the public key of the new vehicle entity in the atomic transaction, and the control of the anchored reputation digest is transferred from the original vehicle entity to the new vehicle entity.

[0010] Update the state of the finite state machine smart contract from the vehicle transaction state to the vehicle usage state associated with the new vehicle entity.

[0011] Optionally, the step of fusing the hardware response value generated by the PUF circuit built into the target vehicle with the static identifier of the target vehicle to generate a unique vehicle digital gene for the target vehicle, and deploying a finite state machine smart contract containing preset lifecycle states for the target vehicle on the blockchain based on the vehicle digital gene includes the following steps:

[0012] Send standard test values ​​pre-set by the authorized entity to the PUF circuitry built into the target vehicle;

[0013] Obtain the hardware response value generated by the PUF circuit based on the standard test value of its own microscopic physical structure response;

[0014] A fusion algorithm is used to combine the hardware response value with the static identifier of the target vehicle to generate the vehicle's digital gene.

[0015] The authorized entity uses the authorized root private key to digitally sign the vehicle's digital gene, forming a blockchain proof.

[0016] Package the vehicle's digital genes, blockchain proof, and finite state machine smart contract template containing preset lifecycle states into a blockchain transaction;

[0017] Blockchain transactions are published to a pre-deployed vehicle-to-everything (V2X) consortium blockchain to complete the deployment of finite state machine smart contracts, and the initial lifecycle state of the finite state machine smart contracts is set to the vehicle's factory state.

[0018] Optionally, when the target vehicle generates a valid interactive behavior that can be verified by consensus, recording the reputation digest of the valid interactive behavior and anchoring it in the form of a hash chain to the finite state machine smart contract includes the following steps:

[0019] Define in advance in the finite state machine smart contract the behavior types of various effective interaction behaviors and the corresponding reputation weights for different types;

[0020] After the target vehicle completes a valid interaction in the vehicle-to-everything (V2X) consortium blockchain, the witness nodes in the V2X consortium blockchain collect and verify the multi-source interaction data related to the valid interaction.

[0021] If the verification is successful, the witness node will combine the multi-source interaction data, event timestamps, and behavior types to generate the original reputation data.

[0022] The original reputation data is hashed based on the reputation weight to obtain a reputation digest.

[0023] The reputation digest is linked to the end of the reputation hash chain in the vehicle-to-everything (V2X) consortium blockchain using hash pointers.

[0024] The updated reputation hash chain head hash value is recorded in a finite state machine smart contract.

[0025] Optionally, after the target vehicle completes a valid interaction in the vehicle-to-everything (V2X) consortium blockchain, the witness node in the V2X consortium blockchain collects and verifies the multi-source interaction data related to the valid interaction, which includes the following steps:

[0026] Receive first interaction data containing a digital signature from the target vehicle that initiated the valid interaction;

[0027] Receive second interaction data from at least one other network participant within the scope of the effective interaction behavior;

[0028] The first and second interactive data are integrated into multi-source interactive data to verify the consistency of event elements in the multi-source interactive data.

[0029] Query the finite state machine smart contract of the target vehicle to confirm that the current lifecycle state of the finite state machine smart contract is the vehicle usage state;

[0030] Once the consistency verification of event elements is passed and the lifecycle status is confirmed to be correct, the multi-source interactive data verification is deemed to have passed.

[0031] Optionally, the step of triggering the finite state machine smart contract to switch from the vehicle usage state to the vehicle transaction state in response to an ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party includes the following steps:

[0032] An initial ownership transfer request containing a unique identifier for the transaction is generated by an authorized third party;

[0033] The newly generated public key is added to the initial ownership transfer request by the new vehicle owner of the target vehicle, and digitally signed using the private key of the new vehicle owner;

[0034] When the original owner of the target vehicle receives an ownership transfer request that already contains the signature of the new owner, the original owner's private key is used to digitally sign it.

[0035] After the authorized third party verifies that the signatures of both the original vehicle owner and the new vehicle owner are valid, the authorized third party shall add the digital signature of the authorized third party to the ownership transfer request.

[0036] The ownership transfer request, jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party, is submitted as a transaction to the vehicle network alliance chain, triggering the finite state machine smart contract to switch from the vehicle usage state to the vehicle transaction state.

[0037] Optionally, the startup permission decay mechanism gradually reduces the communication permissions of the key pair held by the original vehicle owner during vehicle transactions, including the following steps:

[0038] When the finite state machine smart contract enters the vehicle transaction state, a preset block height timer is started;

[0039] Based on the height difference between the current block height and the timer start height, query the permission decay rule table preset in the finite state machine smart contract. The permission decay rule table defines the highest priority of the vehicle network messages that the original vehicle owner's key pair is allowed to send within different height difference ranges. As the height difference increases, the highest priority of the messages that the original vehicle owner is allowed to send decreases unidirectionally.

[0040] When the height difference reaches a preset threshold, the sending permission of the key pair held by the original vehicle body will be cleared, and only the receiving permission will be retained.

[0041] Optionally, the preset lifecycle states of the finite state machine smart contract also include the vehicle scrapping state, and the method further includes the following steps:

[0042] When a target vehicle reaches the scrapping standard, a qualified scrapping and recycling organization, as an authorized third party, and the owner of the last generation vehicle jointly sign and initiate a scrapping request in the vehicle network alliance chain.

[0043] Once the scrapping request is verified through consensus in the vehicle network consortium blockchain, the finite state machine smart contract is triggered.

[0044] The lifecycle state of the target vehicle can be permanently changed to the vehicle scrap state through a finite state machine smart contract in an atomic transaction.

[0045] Associate the key pair held by the last-generation vehicle owner with the scrapping request event of the target vehicle.

[0046] The lifecycle state change of the finite state machine smart contract is broadcast to the entire network of the vehicle-to-everything (V2X) consortium blockchain, so that any communication initiated using a key pair related to the vehicle's digital genetic code will be rejected by the V2X consortium blockchain.

[0047] Optionally, after permanently changing the lifecycle state of the target vehicle to the vehicle scrapped state in an atomic transaction through a finite state machine smart contract, the following steps are also included:

[0048] The complete reputation hash chain anchored in the finite state machine smart contract is anonymized. The anonymization process includes removing the direct association between the reputation hash chain and the vehicle's digital genes and the main body of the vehicle throughout the generations.

[0049] Retain the de-identified reputation hash chain and archive it to the preset historical reputation database;

[0050] Statistical analysis and training of the macro-trust model of the entire vehicle network alliance chain are conducted based on historical reputation database.

[0051] Provide access to the historical reputation database to regulatory authorities, while ensuring that the data cannot be traced back to the original vehicle.

[0052] Secondly, the present invention provides a blockchain-based vehicle-to-everything (V2X) secure communication system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned blockchain-based V2X secure communication method.

[0053] Thirdly, the present invention provides a computer-readable storage medium storing instructions, characterized in that, when executed by a processor, the instructions cause the processor to be configured to perform the aforementioned blockchain-based vehicle-to-everything (V2X) secure communication method.

[0054] The beneficial effects of this invention are:

[0055] This invention integrates the hardware response values ​​of physically unclonable circuits with the vehicle's static identifier to construct a digital gene for each vehicle rooted in the physical layer, which is impossible to clone or tamper with, thus fundamentally eliminating the risk of vehicle identity forgery. Based on this gene, a finite state machine smart contract creatively maps and links the vehicle's physical lifecycle with its digital identity state on the blockchain, achieving dynamic and reliable management of the entire vehicle lifecycle from manufacturing and use to transaction. During the vehicle's usage phase, a reputation digest anchored to the contract in the form of a hash chain constructs a traceable and unrepudiable credit proof for every valid interaction of the vehicle. More importantly, this invention designs a rigorous process for ownership transfer scenarios such as used car transactions, including multi-party signatures, permission decay mechanisms, and atomic transactions. This not only ensures the legality and security of ownership transfer operations but also completely solves the core pain points of the traditional model—the separation of ownership and historical data, and the existence of a security window during the transaction process—through the smooth transition of permissions and the synchronous transfer of reputation assets. This invention constructs an end-to-end security closed loop for the Internet of Vehicles, comprehensively ensuring the integrity and security of the vehicle's digital identity, communication behavior, historical reputation, and asset ownership. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating a blockchain-based secure communication method for vehicle networks in one embodiment of this application.

[0057] Figure 2 This is a schematic diagram illustrating the ownership transfer security mechanism of the original vehicle body, the new vehicle body, and the authorized third party in one embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0059] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0060] Figure 1 This is a flowchart illustrating a blockchain-based secure communication method for connected vehicles in one embodiment. It should be understood that, although... Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps. For example Figure 1 As shown, the blockchain-based secure communication method for vehicle networks disclosed in this invention specifically includes the following steps:

[0061] S110, integrates the hardware response value generated by the PUF circuit built into the target vehicle with the static identifier of the target vehicle to generate a unique vehicle digital gene for the target vehicle, and deploys a finite state machine smart contract containing preset life cycle states for the target vehicle on the blockchain based on the vehicle digital gene. The preset life cycle states include the vehicle manufacturing state, the vehicle usage state, and the vehicle transaction state.

[0062] S120. Based on the vehicle usage state of the finite state machine smart contract, activate the key pair for vehicle-to-everything (V2X) communication for the vehicle's onboard communication unit, and when the target vehicle generates a valid interaction behavior that is verified by consensus, anchor the reputation digest of the valid interaction behavior in the form of a hash chain to the finite state machine smart contract.

[0063] S130. In response to the ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party of the target vehicle, the state of the finite state machine smart contract is switched from the vehicle usage state to the vehicle transaction state, and the permission decay mechanism is started to gradually reduce the communication permissions of the key pair held by the original vehicle owner in the vehicle transaction state.

[0064] S140. After the ownership transfer request is verified through the consensus of the blockchain network, the valid public key recorded in the finite state machine smart contract is updated to the public key of the new vehicle entity in the atomic transaction, and the control of the anchored reputation digest is transferred from the original vehicle entity to the new vehicle entity.

[0065] S150, Update the state of the finite state machine smart contract from the vehicle transaction state to the vehicle usage state associated with the new vehicle entity.

[0066] In the process of generating a vehicle's digital gene, the first step is to activate the Physically Unclonable Function (PUF) circuit built into the target vehicle. This circuit forms unique hardware characteristics based on the microscopic physical randomness of the silicon chip manufacturing process. Specifically, a preset standard test stimulus signal is sent to the PUF circuit. This signal is typically a 128-bit random challenge value. The PUF circuit responds to the challenge based on physical parameters such as the threshold voltage differences of its internal transistors and delay path characteristics, generating a unique hardware response value. For example, when the input challenge value is "0x1A2B3C4D5E6F7890", the PUF circuit of one vehicle might output a response value of "0x9F8E7D6C5B4A3928", while another vehicle receiving the same challenge will produce a different response. Subsequently, the hardware response value is fused with the vehicle's static identifiers (including the VIN, manufacturer code, production date, etc.) using the secure hash algorithm SHA-256 to generate a 256-bit vehicle digital gene. The fusion formula is:

[0067] The symbol "||" represents a data connection operation. Based on this vehicle's digital identity, a finite state machine smart contract is deployed on the blockchain, encompassing three lifecycle states: factory departure, usage, and transaction. This contract is written in Solidity and initially set to the factory departure state. In this way, each vehicle obtains a unique digital identity based on its physical characteristics, fundamentally eliminating the possibility of identity forgery and laying a solid foundation for subsequent secure communication.

[0068] When the finite state machine smart contract is in vehicle usage mode, the onboard communication unit begins the key pair activation process. Specifically, based on the vehicle's digital genetic code as a seed, an elliptic curve digital signature algorithm (ECDSA) is used to generate a public-private key pair for vehicle-to-everything (V2X) communication. The corresponding public key is obtained through elliptic curve dot product operations. When the target vehicle generates valid interactive behavior in the V2X, such as sending an emergency braking warning or sharing road condition information, these behaviors are first verified by witness nodes in the V2X consortium blockchain. Witness nodes collect interaction data from multiple sources, including the digital signature data of the initiating vehicle, confirmation information from surrounding vehicles, and monitoring records from roadside equipment. After successful verification, the witness node calculates a reputation digest based on preset behavior types (e.g., safety warning weight 0.8, road condition sharing weight 0.6), using the formula: These reputation digests are anchored in a finite state machine smart contract in the form of a hash chain. Each new reputation digest contains a hash pointer to the previous digest, forming an immutable history of reputation. This mechanism ensures that every valid interaction of the vehicle is fairly recorded, establishing a trustworthy vehicle reputation system.

[0069] Reference Figure 2This demonstrates the authority relationships among the original vehicle owner, the new vehicle owner, and the authorized third party. The triggering of an ownership transfer request requires a digital signature verification mechanism involving all three parties. In practice, when a vehicle ownership transfer is required, a qualified authorized third party first generates an initial transfer request containing a unique transaction identifier. Upon receiving this request, the new vehicle owner digitally signs the request using a locally generated new private key. The signature algorithm is ECDSA, and the signing process is as follows:

[0070] ;

[0071] k is a random number. After receiving the request containing the new entity's signature, the original vehicle entity also uses its own private key to sign and confirm. Finally, after authorizing a third party to verify the validity of the first two signatures, it appends its own digital signature to form a complete request with a three-party joint signature. When this request is submitted to the vehicle network consortium blockchain, the smart contract automatically triggers a state switch, changing from the vehicle usage state to the vehicle transaction state. At the same time, a permission decay mechanism is activated, which gradually reduces the original vehicle entity's communication permissions based on the block height difference. In specific implementation, a permission decay rule table is set. When the height difference is in the range of 0-100, the original entity can send all priority messages; in the range of 101-200, it can only send medium priority messages; in the range of 201-300, it can only send low priority messages; after 300 blocks, the sending permission is completely cleared. This gradual permission decay mechanism effectively avoids the security window problem during the permission transfer process.

[0072] The execution of atomic transactions ensures the integrity and consistency of ownership transfer operations. In practice, after the ownership transfer request is verified through consensus on the blockchain network, the finite state machine smart contract begins executing atomic transaction operations. This transaction includes two core operations: public key update and reputation control transfer. During the public key update process, the smart contract first verifies whether the public key submitted by the new vehicle entity conforms to the elliptic curve standard, with the verification equation as follows:

[0073] ;

[0074] Ensure the public key point lies on the specified elliptic curve. Upon successful verification, the contract marks the original public key as invalid and writes the new public key into the contract's valid public key field. The reputation control transfer process is more complex, requiring the transfer of control of the complete reputation hash chain previously anchored in the smart contract from the original vehicle owner to the new vehicle owner. Specifically, the smart contract generates a reputation transfer proof, which includes the original owner's digital signature authorization, the new owner's acceptance confirmation, and a transfer timestamp. The format of the transfer proof is: \[Transfer Proof = (Original Owner Signature, New Owner Signature, Timestamp, Reputation Chain Header Hash)\]. The entire process employs an atomic transaction mechanism, ensuring that the public key update and reputation transfer succeed or fail simultaneously, avoiding data inconsistencies. Through this mechanism, the vehicle's historical reputation data is completely preserved and securely transferred, allowing the new owner to inherit the vehicle's historical credit record and achieving seamless transfer of digital assets.

[0075] The final update of the smart contract state marks the completion of the entire ownership transfer process. In specific implementation, after the atomic transaction in step S140 is successfully executed, the finite state machine smart contract begins to execute the final state transition operation. This operation first verifies whether all preconditions are met, including: whether the public key of the new vehicle entity has been successfully updated, whether the control of the reputation digest has been transferred, and whether the permissions of the original vehicle entity have been completely cleared. After verification, the smart contract calls the state transition function to update the lifecycle state from the vehicle transaction state to the vehicle usage state associated with the new vehicle entity. During the state update process, the smart contract reinitializes the vehicle's communication permissions, assigning complete vehicle network communication permissions to the new vehicle entity's key pair, including the permission to send various priority messages and the permission to participate in consensus verification. At the same time, the smart contract also resets the timer of the permission decay mechanism to prepare for the next possible ownership transfer. After the state update is completed, the smart contract broadcasts the state change event to all nodes in the vehicle network consortium chain, notifying other participants in the network that the ownership of the vehicle has been transferred. The broadcast message contains key information such as the vehicle's digital gene, the public key digest of the new vehicle entity, and the state update timestamp. In this way, the entire vehicle network can promptly understand changes in vehicle ownership, ensuring the security and effectiveness of subsequent communications.

[0076] The aforementioned blockchain-based secure communication method for vehicle-to-everything (V2X) communication achieves secure management of vehicle digital identities throughout their entire lifecycle. By integrating the hardware characteristics of PUF circuits with statically generated vehicle digital genes, the uniqueness and unforgeability of vehicle identities are ensured at the physical level, effectively solving the single point of failure problem inherent in traditional V2X systems where identity authentication relies on centralized institutions. Lifecycle management based on finite state machine smart contracts enables digital tracking of vehicles from manufacturing to scrapping, ensuring transparency and traceability of vehicle status. The hash chain anchoring mechanism of reputation digests establishes a complete credit record of vehicle behavior, providing a reliable foundation for reputation assessment within the V2X ecosystem. The ownership transfer process with three-party joint signatures, coupled with a permission decay mechanism, completely resolves the security window issue during vehicle ownership changes, ensuring a smooth transition of permissions. The application of atomic transactions guarantees the synchronization of public key updates and reputation transfers, avoiding security risks caused by data inconsistencies. The entire solution constructs a complete V2X security closed loop, not only ensuring the security of vehicle communication but also realizing the preservation and inheritance of vehicle digital assets, providing a solid security foundation for the development of intelligent transportation systems.

[0077] In one embodiment, the method further includes the following steps:

[0078] When any receiving node in the Internet of Vehicles receives a message from a vehicle claiming to be a vehicle, it extracts the public key attached to the message.

[0079] The receiving node queries the vehicle network consortium blockchain for the finite state machine smart contract associated with the public key;

[0080] Obtain and verify whether the current lifecycle state of the smart contract is the vehicle usage state, and whether the public key is a valid public key currently recorded;

[0081] If the verification passes, the credibility hash chain anchored to the smart contract is obtained, and the credibility of the message is evaluated based on its historical records.

[0082] If any verification fails, the message will be deemed invalid or its trust level will be lowered.

[0083] In vehicle-to-everything (V2X) communication, when a receiving node receives a message from a claimed vehicle, it first needs to extract the additional public key information from the message data packet. Specifically, V2X messages use a standardized data frame format, comprising three main parts: a message header, payload data, and a security field. The message header contains basic information such as the sender identifier, message type, and timestamp. The payload data carries specific business content, such as road condition information and emergency warnings, while the security field contains the digital signature and public key certificate. During public key extraction, the receiving node first parses the security field of the message, locating the starting position of the public key data according to a predefined field offset. The public key used in V2X typically employs an elliptic curve cryptography algorithm, with a public key length of 64 bytes, including 32 bytes of x-coordinate and 32 bytes of y-coordinate. The extraction algorithm first verifies the integrity of the security field, ensuring that the data has not been tampered with during transmission by calculating a checksum. Subsequently, the public key certificate structure is parsed according to the IEEE 1609.2 standard to extract the compressed or uncompressed elliptic curve public key. The extraction process also verifies whether the public key conforms to the elliptic curve equation, ensuring the mathematical validity of the public key. This rigorous public key extraction and verification mechanism ensures the accuracy and reliability of subsequent verification processes, laying the foundation for secure message verification.

[0084] After obtaining the public key, the receiving node needs to query the vehicle-to-everything (V2X) consortium blockchain for the finite state machine smart contract associated with that public key. In practice, the query process employs an indexing mechanism based on the public key hash. First, the SHA-256 hash value of the public key is calculated as the query index, using the following formula: The receiving node sends a query request to the consortium blockchain via the blockchain RPC interface. The request format is JSON-RPC 2.0 standard, including the method name "getContractByPublicKey" and the public key hash value as a parameter. Upon receiving the query request, the consortium blockchain node performs an index lookup in its locally maintained public key-contract mapping table. This mapping table uses a B+ tree data structure for storage, supporting efficient range queries and exact matches. The time complexity of the lookup process is O(log n), where n is the total number of registered vehicles. If the query is successful, the consortium blockchain node returns the corresponding smart contract address and basic information, including the contract deployment time and current state version number. If the public key is not registered in the consortium blockchain, an empty result is returned, indicating that the message may have come from an unauthorized sender. The query process also includes a caching mechanism. The receiving node locally maintains an LRU cache of the most recently retrieved query results, typically set to 1000 records, with a cache hit rate exceeding 80%. For queries with cache hits, the response time is reduced from an average of 100 milliseconds to less than 5 milliseconds. Furthermore, the query process employs asynchronous processing to avoid blocking the main thread's message processing flow. Through this efficient query mechanism, the receiving node can quickly locate the smart contract corresponding to the sending vehicle, providing the necessary data foundation for subsequent state verification.

[0085] After obtaining the smart contract information, the receiving node needs to verify the contract's current lifecycle state and the validity of the public key. In practice, the state verification process includes two parallel verification branches: lifecycle state check and public key validity verification. The lifecycle state check is implemented by calling the smart contract's "getCurrentState()" function, which returns an enumeration of the current state, including 0 for factory status, 1 for usage status, 2 for transaction status, and 3 for obsolescence status. Only when the state value is 1 (usage status) is the vehicle allowed to communicate normally in the vehicle-to-everything (V2X) network. The state check also includes time verification of state transitions, ensuring the timeliness of state information by comparing the last update time of the state with the current timestamp. Public key validity verification is implemented by calling the contract's "isValidPublicKey()" function, which accepts the public key to be verified as a parameter and returns a boolean value indicating whether the public key is a valid public key currently recorded. The verification process uses an elliptic curve point comparison algorithm, and the comparison formula is:

[0086] .

[0087] To improve verification efficiency, the contract stores a compressed version of the public key, calculating the complete public key coordinates using the x-coordinate and a parity flag. The verification process also includes a public key version check; the public key version number is incremented after each ownership transfer to ensure the latest valid public key is used. Furthermore, the verification mechanism includes anti-replay attack protection, preventing malicious nodes from repeatedly sending historical messages by checking the message timestamp and sequence number. This dual verification mechanism ensures that only legitimate vehicles in normal use can pass verification, effectively preventing invalid messages from scrapped vehicles or vehicles in a transaction state.

[0088] After the lifecycle state and public key verification are successful, the receiving node further obtains the reputation hash chain anchored to the smart contract and evaluates the message's credibility based on historical records. In practice, the reputation evaluation process first obtains the complete reputation hash chain header information by calling the smart contract's "getReputationChain()" function, including the chain header hash value, chain length, and last update time. Subsequently, the node retrieves the complete reputation chain data from the distributed storage network using the chain header hash value. The reputation chain is stored using a Merkle tree structure, with each node containing a reputation digest, timestamp, behavior type, and a hash pointer to the next node. The credibility evaluation algorithm calculates a comprehensive reputation score based on time decay and behavior weights, using the following formula:

[0089] ;

[0090] in The weight of the i-th action. This is the difference between the time the action occurred and the current time. This is the time decay factor (usually taken as 0.001). The reputation score is assigned to the behavior. Different types of interactive behaviors have different weights: emergency safety warnings have a weight of 1.0, traffic condition sharing has a weight of 0.8, route recommendation has a weight of 0.6, and general information broadcasting has a weight of 0.4. The evaluation process also considers the consistency and frequency of the behavior, assessing the sender's stability by calculating the standard deviation of the behavior pattern. For example, if a vehicle's reputation chain shows that it has sent 50 emergency braking warnings in the past 30 days, but actual verification shows that 80% of them were false alarms, the vehicle's credibility score will be significantly reduced. The evaluation results are divided into five levels: Excellent (90-100 points), Good (70-89 points), Average (50-69 points), Poor (30-49 points), and Very Poor (0-29 points). Based on the reputation score, the receiving node sets the corresponding processing priority and trust level for messages. Messages from high-reputation vehicles will receive higher processing priority and a wider forwarding range.

[0091] Based on the aforementioned verification results, the receiving node performs a final validity determination and trust level classification for the message. In practice, the determination process employs a multi-level verification decision tree algorithm. First, it checks whether all basic verification items have passed, including public key validity and lifecycle state correctness. If any basic verification item fails, the message is immediately marked as invalid and discarded, and a violation log is recorded for subsequent security analysis. For messages that pass the basic verification, a trust level is further assigned based on the reputation assessment results. Trust levels are divided into four tiers: High Trust (reputation score ≥ 80), Medium Trust (60 ≤ reputation score < 80), Low Trust (40 ≤ reputation score < 60), and Observational (reputation score < 40). Messages of different trust levels will trigger different processing strategies: High-trust messages are directly accepted and processed with priority; Medium-trust messages are processed normally but with additional verification; Low-trust messages have their forwarding scope restricted and processing delayed; Observational messages are temporarily cached for further verification. The determination process also includes a dynamic adjustment mechanism, dynamically adjusting the thresholds for each trust level based on the overall network security posture and attack detection results. For example, when a large-scale forged message attack is detected, the trust level requirement is automatically raised, and only messages with a reputation score of ≥90 are marked as high-trust. Furthermore, the judgment result is fed back into the local reputation assessment model to optimize subsequent trust calculation algorithms. For messages deemed invalid, nodes also report security events to the consortium blockchain, including the sender's public key, message content digest, and violation type, providing early warning information for network-wide security protection. Through this comprehensive judgment mechanism, invalid and malicious messages are effectively filtered out, improving the overall security and reliability of vehicle-to-everything (V2X) communication.

[0092] Through the aforementioned blockchain-based message verification mechanism, a multi-layered security protection system for vehicle-to-everything (V2X) communication has been established. The public key extraction and verification process ensures the traceability of message sources, preventing identity forgery and impersonation attacks. The smart contract query mechanism enables real-time verification of the sender's identity, ensuring that only legally registered vehicles can participate in network communication. The dual verification mechanism of lifecycle status and public key validity effectively prevents interference from invalid messages from scrapped vehicles or vehicles undergoing permission transfer. Trustworthiness assessment based on a reputation hash chain provides refined trust grading for message processing, enabling the receiver to intelligently adjust message processing priorities based on the sender's historical behavior records. The multi-level decision tree algorithm combined with a dynamic threshold adjustment mechanism not only effectively identifies and filters malicious messages but also adapts to protection needs under different security scenarios. The time complexity of the entire verification process is controlled at the millisecond level, without significantly impacting the real-time communication performance of the V2X. By establishing this complete message verification system, the V2X has achieved a security upgrade from passive reception to active screening, significantly improving the trustworthiness and anti-attack capabilities of network communication, and providing a solid guarantee for the safe operation of intelligent transportation systems.

[0093] In one implementation, atomic transactions further include:

[0094] Generate an electronic settlement certificate containing the original vehicle owner's identity, the new vehicle owner's identity, the authorized third party's identity, a timestamp, and the corresponding block height;

[0095] The hash value of the electronic delivery certificate is permanently recorded in the event log of the finite state machine smart contract;

[0096] The complete data of the electronic delivery certificate is encrypted and stored in a distributed storage system;

[0097] The storage address of the encrypted data is recorded in the transaction details of the atomic transaction;

[0098] The new vehicle owner and authorized third parties are granted the authority to decrypt and access the electronic settlement certificate.

[0099] The generation of electronic settlement certificates requires collecting and integrating key information from the ownership transfer process to form a complete transaction record document. In practice, certificate generation first involves automatically extracting relevant identity information through a smart contract's data collection function. This includes the digital identity of the original vehicle owner, the digital identity of the new vehicle owner, and authentication information from authorized third parties. The original vehicle owner's identity information includes their public key hash, registration time, and historical transaction records. The new vehicle owner's identity information includes the newly generated public key, authentication credentials, and registration address. The authorized third party's identity information includes the third party's digital certificate, authorization scope, and validity period. The timestamp uses a Unix time format, accurate to the millisecond level, ensuring accurate recording of transaction time. The corresponding block height is obtained by querying the latest block number of the current blockchain, used to establish the association between the transaction and the blockchain state. The electronic settlement certificate organizes data in JSON format, including fields such as version number, transaction type, participant information, time information, and vehicle information.

[0100] The hash value of the electronic settlement certificate is permanently recorded in the event log of the finite state machine smart contract, achieving the immutability and traceability of transaction records. In specific implementation, the complete electronic settlement certificate is first subjected to a SHA-256 hash operation. The hash calculation formula is as follows: A unique 256-bit hash value is generated as a digital fingerprint for the credential. The smart contract triggers a predefined "OwnershipTransferEvent" via an emit statement. This event contains multiple index fields and data fields. Index fields include the vehicle's digital genetic hash, the original owner's address hash, and the new owner's address hash, facilitating subsequent quick queries and filtering. Data fields contain detailed information such as the credential hash value, transaction timestamp, and block height. Once written to the blockchain, the event log becomes a permanent part of the blockchain state and cannot be modified or deleted. All nodes in the blockchain network synchronize these event logs, ensuring network-wide consistency. The event log also supports efficient query operations; through Bloom filters and indexing mechanisms, transaction records for specific vehicles or time periods can be quickly retrieved. Furthermore, the generation of the event log triggers state updates to the smart contract, including incrementing the transaction counter and updating the last transaction time. Through this mechanism, every ownership transfer leaves a permanent and undeniable record on the blockchain, providing a reliable data foundation for subsequent dispute resolution and auditing.

[0101] The complete data of the electronic settlement certificate needs to be encrypted before being stored in a distributed storage system to ensure data confidentiality and availability. In implementation, a hybrid encryption scheme is used, combining the advantages of symmetric and asymmetric encryption. First, a 256-bit random symmetric key is generated, and the electronic settlement certificate is encrypted using the AES-256-GCM algorithm. The AES-GCM mode not only provides encryption but also has a built-in authentication mechanism to detect data tampering. Subsequently, the symmetric key is encrypted using the RSA-2048 algorithm, with the encryption formula as follows: To enable multi-party authorized access, a threshold cryptography scheme is employed, dividing the symmetric key into multiple key fragments, each encrypted using the public keys of the new vehicle entity and the authorized third party. Distributed storage utilizes the IPFS (InterPlanetary File System) network, employing content addressing to ensure data uniqueness and integrity. The encrypted credential data is divided into multiple 256KB blocks, stored on different IPFS nodes. Erasure coding is used during storage to encode the original data into redundant blocks, allowing for complete data recovery even if some nodes are offline. Storage parameters are set to (n=10, k=6), indicating that the data is divided into 10 blocks, and the original data can be recovered from any 6 blocks, providing 67% fault tolerance. Each data block has a unique hash identifier, forming a complete storage mapping table. Distributed storage also includes a data synchronization mechanism to periodically check the data integrity of each node, ensuring long-term data preservation.

[0102] Recording the storage address of encrypted data in the transaction details of atomic transactions establishes a bridge between blockchain records and distributed storage data. In specific implementation, the storage address contains multiple layers of information. First, it contains the root hash of the IPFS network, a 46-bit Base58 encoded string in the format "QmX...", uniquely identifying the location of the encrypted credential in the IPFS network. Second, it contains a distribution mapping table of data blocks, recording the specific location of each data shard on different IPFS nodes, in the format {"block_0":"QmY...","block_1":"QmZ...",...}. It also contains erasure coding parameters, such as the total number of shards and the recovery threshold. Transaction details are stored using the state variables of the smart contract, defining a dedicated storage structure: struct StorageInfo {bytes32 rootHash; string[] blockHashes; uint8totalShards; uint8 threshold; uint256 timestamp; bool isActive;}. Atomic transactions execute multiple operations simultaneously through a single blockchain transaction, including public key updates, reputation transfers, and storage address recording, ensuring that all operations either succeed entirely or fail entirely. Atomicity of the transaction is achieved through the `require` statement and revert mechanism of the smart contract; failure of any step will cause the entire transaction to roll back. The storage address record also contains access control information, defining which addresses have read permissions; the permission list format is "authorizedAddresses: [new owner's address, authorized third-party address]". The recording process also generates storage proofs, verifying the integrity and existence of the data through a Merkle tree structure. Gas consumption for transaction details is minimized through optimized storage structure and data compression techniques, ensuring economic efficiency. In this way, lightweight records on the blockchain and detailed off-chain data form a complete data management system, guaranteeing both blockchain efficiency and complete data preservation.

[0103] Access permissions for decryption by the new vehicle owner and authorized third parties are implemented through a dynamic permission management mechanism based on smart contracts, ensuring that only legitimate participants can access sensitive data. In practice, permission authorization adopts a Role-Based Access Control (RBAC) model, combined with time limits and condition constraints. First, a permission structure is defined in the smart contract: `struct AccessPermission {address holder; uint256 expiryTime; uint8 permissionLevel; bool isActive; bytes32 conditionHash;}`. The new vehicle owner obtains full access (permissionLevel = 3), allowing them to decrypt, view, and download complete electronic settlement documents. Authorized third parties obtain audit permissions (permissionLevel = 2), allowing them to decrypt and view document content, but with a time limit, typically set to be valid for 90 days after the transaction. The permission verification process first checks if the accessor's address is in the authorized list, and then verifies if the permission is within its validity period. Decryption permissions are implemented based on threshold cryptography and proxy re-encryption technology. The authorizing party generates a proxy re-encryption key, allowing the authorized party to decrypt data without obtaining the original private key. The proxy re-encryption process consists of two stages: key conversion and condition verification. The conversion formula is as follows:

[0104] ,in For the authorizing party's private key, `r` is the authorized party's private key, and `r` is a random number. Access control also includes an audit log function, recording information such as the time, visitor, and operation type of each access operation. Permissions also support a revocation mechanism, allowing for the emergency revocation of access to a specific address through multi-signature verification in special circumstances. This fine-grained permission management mechanism protects the privacy of transaction data while meeting regulatory and auditing compliance requirements.

[0105] Through the complete management process of the aforementioned electronic settlement certificates, a digital, trustworthy, and compliant management system for vehicle ownership transfer has been established. The generation and structured storage of electronic settlement certificates ensure the integrity and standardization of transaction information, providing a unified data format for subsequent queries, verification, and auditing. The permanent recording of certificate hash values ​​in the blockchain event log ensures non-repudiation and traceability of transactions; any attempt to tamper with transaction records will be detected. The combination of encrypted and distributed storage protects the privacy of transaction data while ensuring high availability and durability; even if some storage nodes fail, data integrity will not be affected. The recording of storage addresses in the blockchain transaction details establishes a reliable link between the lightweight on-chain index and detailed off-chain data, enabling hierarchical data management and efficient access. The role-based dynamic permission management mechanism ensures that only legitimate participants can access sensitive data, while supporting time limits and conditional constraints on permissions, meeting access needs in different scenarios. The atomic execution of the entire process guarantees the consistency of data operations, avoiding data inconsistencies caused by partial successes. Through this complete electronic settlement certificate management system, the transfer of vehicle ownership has been upgraded from traditional paper certificates to digital certificates. This not only improves transaction efficiency and security, but also provides regulatory authorities with transparent and auditable transaction records, which strongly promotes the development of digital management of vehicle assets.

[0106] In one implementation, the process of fusing the hardware response value generated by the PUF circuit built into the target vehicle with the static identifier of the target vehicle to generate a unique vehicle digital gene for the target vehicle, and deploying a finite state machine smart contract containing preset lifecycle states for the target vehicle on the blockchain based on the vehicle digital gene, includes the following steps:

[0107] S210. Send the standard test value pre-set by the authorized entity to the PUF circuit built into the target vehicle;

[0108] S220. Obtain the hardware response value generated by the PUF circuit based on the standard test value of its own microscopic physical structure response;

[0109] S230. A fusion algorithm is used to fuse the hardware response value with the static identifier of the target vehicle to generate the vehicle digital gene of the target vehicle.

[0110] S240. The authorized entity uses the authorized root private key to digitally sign the vehicle's digital gene, forming a blockchain proof.

[0111] S250: Package the vehicle's digital genes, blockchain proof, and finite state machine smart contract template containing preset lifecycle states into a blockchain transaction.

[0112] S260. Publish the blockchain transaction to the pre-deployed vehicle network consortium blockchain to complete the deployment of the finite state machine smart contract, and set the initial lifecycle state of the finite state machine smart contract to the vehicle's factory state.

[0113] The process of sending standard test values ​​to the PUF circuit built into the target vehicle requires establishing a secure and reliable communication connection and a standardized test protocol. In practice, the authorized entity first establishes a connection with the onboard PUF circuit through the vehicle's diagnostic interface (such as the OBD-II port) or a dedicated secure communication module. The standard test values ​​are designed using a cryptographically secure pseudo-random number generation algorithm to ensure the randomness and unpredictability of the test stimuli. The test value length is typically set to 128 bits, represented in hexadecimal format. The authorized entity maintains a standard test value library containing 1000 pre-generated test vectors, and each vehicle uses a specific subset for testing. The transmission process employs a segmented transmission mechanism, decomposing the 128-bit test value into eight 16-bit data segments, which are sent segment by segment to the PUF circuit's stimulus input port. Each data segment is transmitted using a data packet format with a checksum: [start flag (8 bits) + segment number (4 bits) + data content (16 bits) + checksum (4 bits) + end flag (8 bits)]. The transmission protocol also includes a retransmission mechanism. If the PUF circuit does not acknowledge receipt within a preset time, the authorized entity will automatically retransmit the data segment, up to a maximum of three retransmissions. To ensure a consistent testing environment, the vehicle must be stationary during transmission, the ambient temperature must be between 15-35℃, and the power supply voltage must be stable at 12V±0.5V. After the test value is transmitted, the authorized entity sends an activation command to the PUF circuit, triggering the circuit to begin its response calculation. The entire transmission process is controlled within 500 milliseconds to ensure the real-time performance and efficiency of the test.

[0114] The process by which a PUF circuit responds to a standard test value based on its own microscopic physical structure and generates a unique hardware response value embodies the core principle of physically unclonable technology. In practice, a PUF circuit contains thousands of basic response units, each composed of a pair of CMOS transistors. These transistors exhibit minute physical differences during manufacturing, such as variations in threshold voltage and carrier mobility. Upon receiving a 128-bit standard test value, the circuit assigns it to the corresponding response unit, and each unit calculates its response based on the input bit value. The response process employs a contention-delay mechanism, with the specific formula as follows:

[0115] .

[0116] The differences in delay paths stem from variations in the physical characteristics of the transistors, typically ranging in the picosecond range. To improve response stability, each response unit is calculated 10 times, and a majority voting mechanism is used to determine the final output.

[0117] The PUF circuit also incorporates an error correction code module, using BCH code to correct errors in the original response. This can correct up to 8 bits of error, ensuring consistent response even with slight changes in environmental conditions. After the response value is generated, the circuit transmits the 128-bit hardware response value to the vehicle control unit via an output buffer. Differential signaling is used during transmission to ensure data integrity. The power consumption of the entire response generation process is controlled within 50 milliwatts, and the response time is approximately 100 milliseconds, ensuring practicality and reliability. The generated hardware response value is highly unique, with a response difference exceeding 99.9% between different vehicles, providing a solid physical foundation for vehicle identification.

[0118] The fusion algorithm combines the hardware response value of the PUF circuit with the vehicle static identifier to generate a unique and unforgeable vehicle digital gene. In practice, the vehicle static identifier contains multiple layers of information, primarily including the 17-digit Vehicle Identification Number (VIN), manufacturer identification code, production date and timestamp, engine serial number, and other key information. The fusion algorithm employs multi-round hash functions and key derivation technology to ensure the security and uniqueness of the generation process. First, the vehicle static identifier is preprocessed by concatenating various information items according to a standard format: "VIN code + manufacturer code + production date + engine number", for example, "1HGBH41JXMN1234567HONDA20231215ENG98765". Then, the PBKDF2 key derivation function is used to process the static identifier, with the following formula:

[0119] ;

[0120] The salt value uses the first 32 bits of the hardware response value, the iteration count is set to 10,000, and the output length is 256 bits. Next, a fusion calculation is performed using the HMAC-SHA256 algorithm, with the following formula:

[0121] .

[0122] To enhance security, the fusion process also includes timestamp verification and environmental factor correction. Timestamps ensure the timeliness of the generation process, while environmental factors, including physical parameters such as temperature and voltage, compensate for the impact of environmental changes on the PUF response. The fusion algorithm also employs elliptic curve mathematical operations for secondary hardening, mapping the initially generated digital gene to a point on the secp256r1 elliptic curve. The mapping formula is:

[0123] .

[0124] The final generated vehicle digital gene is 256 bits long, with cryptographically strong randomness and uniqueness, providing each vehicle with a unique digital identity.

[0125] The process of an authorized entity digitally signing the vehicle's digital gene using its authorized root private key establishes an authoritative authentication mechanism for the vehicle's identity, ensuring the authenticity and integrity of the digital gene. In practice, the authorized entity is typically a vehicle manufacturer, certification body, or government regulatory department, possessing a root private key that has undergone rigorous verification and authentication. The root private key is generated using high-strength algorithms such as RSA-4096 or ECC-P384, and its length ensures a sufficient security margin. The digital signature process first performs a hash operation on the vehicle's digital gene, calculating the hash value using the SHA-384 algorithm, with the formula:

[0126] .

[0127] Then, the hash value is signed using the ECDSA algorithm. The signing process includes three core steps: random number generation, elliptic curve multiplication, and modular arithmetic. The specific calculation formula is as follows: First, generate a random number k, then calculate the points on the elliptic curve... , where G is the base point of the elliptic curve; then the first part of the signature is calculated. Finally, calculate the second part of the signature. The final digital signature is a (r, s) pair. To prevent side-channel attacks during the signing process, the authorized entity uses a dedicated Hardware Security Module (HSM) for the signing operation. The HSM provides a tamper-proof secure environment and a true random number generator. The signing process also includes a timestamp service, with a trusted timestamp authority providing authoritative proof of the signing time. The timestamp format conforms to the RFC3161 standard. The generated blockchain proof contains complete information such as the digital signature, timestamp, and authorized entity certificate chain. The proof structure is: {"signature": (r, s), "timestamp": "2023-12-15T10:30:00Z", "certChain": ["authorized entity certificate", "intermediate CA certificate", "root CA certificate"]}. Through this authoritative digital signature mechanism, the vehicle's digital gene acquires legal validity and technical protection, laying a trusted foundation for subsequent blockchain deployment.

[0128] The process of packaging vehicle digital genes, blockchain proofs, and smart contract templates into a blockchain transaction must adhere to the standard format and coding specifications of blockchain transactions to ensure that the transaction can be correctly parsed and executed by the network. In specific implementation, the transaction packaging adopts an Ethereum-compatible transaction structure, including standard fields such as nonce, gasPrice, gasLimit, to, value, and data. The transaction data field (data) carries the deployment information of the smart contract and organizes the data using ABI encoding format. First, the vehicle digital genes are converted to bytes32 type, occupying 32 bytes of storage space. The blockchain proof includes the (r, s) value of the digital signature, a timestamp, and a certificate chain, with a total length of approximately 1KB, serialized using RLP encoding. The smart contract template is written in Solidity and compiled to generate EVM bytecode, typically between 10-50KB in length. The contract template includes core functional modules such as vehicle lifecycle state variables, state transition functions, and event definitions. The packaging process uses constructor parameter passing, with the vehicle digital genes and blockchain proofs as input parameters to the constructor. The parameter encoding formula is as follows:

[0129] .

[0130] The complete transaction data structure is: data = contract bytecode + constructor parameter encoding. To optimize gas consumption, data compression technology is used to reduce transaction size. The zlib algorithm is used to compress duplicate data, achieving a compression rate of 30-40%. Transaction signature uses the sender's private key to ensure the authorization and integrity of the transaction. The packaged transaction also needs to undergo static analysis verification to check the security of the contract code, the accuracy of gas estimation, etc., to ensure that the transaction can be executed smoothly. The final generated blockchain transaction contains all the information required to deploy the smart contract, preparing the vehicle to establish a digital identity on the blockchain.

[0131] The process of publishing blockchain transactions to the vehicle-to-everything (V2X) consortium blockchain and deploying smart contracts involves multiple stages, including network propagation, consensus verification, and contract execution, ensuring the secure establishment of vehicle digital identities within the distributed network. In practice, transaction publication first involves submitting the transaction to any node in the consortium blockchain via a JSON-RPC interface. The request format is `eth_sendRawTransaction`, and the parameter is the raw transaction data encoded and signed using RLP. The receiving node performs preliminary verification of the transaction, including basic checks such as signature validity, nonce correctness, and sufficient gas fees. Verified transactions are added to the node's memory pool, awaiting inclusion in a block. The consortium blockchain uses the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, supporting consensus even in the presence of malicious nodes. The consensus process consists of three phases: pre-preparation, preparation, and submission. Each phase requires the agreement of more than two-thirds of honest nodes to proceed to the next. After the transaction is included in the block, the EVM virtual machines on each node begin executing the smart contract deployment. The deployment process includes contract code verification, state initialization, and address allocation. The contract address is calculated using a deterministic algorithm, with the formula:

[0132] ;

[0133] The last 20 bytes of the hash value are used as the contract address. The initial state settings of the smart contract include: setting the lifecycle state to "factory state" (enumeration value 0), storing the vehicle's digital genetic information, recording the creation timestamp, and initializing the permission list. State storage uses a Merkle Patricia Tree structure to ensure state integrity and verifiability. Upon deployment, the contract broadcasts a ContractDeployed event to the network, including the contract address, vehicle digital genetic hash, and deployment time. All nodes on the consortium blockchain synchronously update their local states, adding the newly deployed contract information to the vehicle registry. To ensure successful deployment, a deployment confirmation mechanism is included, requiring at least six blocks for confirmation before the deployment is considered complete. Through this rigorous deployment process, each vehicle obtains a unique and tamper-proof digital identity on the blockchain, laying a solid foundation for subsequent secure vehicle-to-everything (V2X) communication.

[0134] Through the aforementioned process of generating vehicle digital genes and deploying smart contracts based on PUF circuits and blockchain technology, a revolutionary solution for vehicle identity authentication has been established. The transmission of standard test values ​​and the PUF circuit response mechanism physically guarantee the uniqueness and non-cloning nature of vehicle identity, creating a true "digital fingerprint" by utilizing the microscopic randomness of silicon chip manufacturing. The fusion algorithm combines physical features with static identifiers through a cryptographically secure computation process, generating a vehicle digital gene that is both unique and verifiable. The digital signature of the authorized entity provides authoritative authentication of the vehicle identity, establishing a complete trust chain from manufacturer to end user. The standardized packaging of blockchain transactions ensures data integrity and compatibility, providing a technological foundation for interoperability between different systems. The successful deployment of smart contracts on the consortium blockchain enables digital management of the vehicle lifecycle, upgrading traditional paper records to tamper-proof blockchain records. This entire process not only solves the security risks of traditional vehicle identity authentication, such as reliance on centralized institutions and susceptibility to forgery, but also builds a trusted infrastructure based on cryptographic proofs for the Internet of Vehicles. By deeply integrating physically clonable technology with blockchain distributed consensus, each vehicle has acquired a unique, secure, and reliable digital identity, providing key technical support for the safe development of intelligent transportation systems and promoting the deep transformation and upgrading of the automotive industry towards digitalization and intelligence.

[0135] In one implementation, the step of anchoring a reputation digest of the valid interaction behavior in the form of a hash chain to a finite state machine smart contract when the target vehicle generates a valid interaction behavior that can be verified by consensus includes the following steps:

[0136] S310. Define in advance in the finite state machine smart contract the behavior types of various effective interaction behaviors and the reputation weights corresponding to different types;

[0137] S320. After the target vehicle completes a valid interaction in the vehicle-to-everything (V2X) consortium blockchain, the witness node in the V2X consortium blockchain collects and verifies the multi-source interaction data related to the valid interaction.

[0138] S330. If the verification is successful, the witness node will combine the multi-source interaction data, event timestamps, and behavior types to generate the original reputation data.

[0139] S340. Perform a hash operation on the original reputation data based on the reputation weight to obtain a reputation digest;

[0140] S350: The reputation digest is linked to the end of the reputation hash chain in the vehicle network consortium blockchain using hash pointers.

[0141] S360. Record the updated reputation hash chain head hash value in the finite state machine smart contract.

[0142] The process of pre-defining interaction behavior types and reputation weights in finite state machine smart contracts establishes a standardized system and quantitative mechanism for vehicle-to-everything (V2X) reputation assessment. In implementation, the definition of behavior types adopts a hierarchical classification structure, mainly divided into four categories: safety, cooperation, service, and violation. Safety behaviors include emergency braking warnings, accident reports, and hazardous road condition alerts; these behaviors are of significant value to traffic safety and therefore have high reputation weights. Cooperation behaviors include road condition information sharing, parking space information provision, and traffic flow reporting, reflecting the spirit of mutual assistance and cooperation among vehicles. Service behaviors include value-added services such as navigation assistance, charging pile status sharing, and weather information transmission. Violation behaviors include negative behaviors such as sending false information, malicious attacks, and frequent invalid communications, and are penalized with negative weights. Each behavior type is assigned a unique identifier using an 8-bit hexadecimal code; for example, safety warnings are "0x01", road condition sharing is "0x02", and parking information is "0x03". Reputation weights are represented using floating-point numbers, ranging from -2.0 to +2.0, with a precision of 0.1. The specific weights are set as follows: Emergency braking warning weight 2.0, Accident report weight 1.8, Dangerous road condition alert weight 1.5, Traffic flow report weight 1.2, Parking information sharing weight 1.0, General information transmission weight 0.5, False information transmission weight -1.5, and Malicious attack weight -2.0. The weight settings also consider time decay factors and frequency limits to prevent certain behaviors from being excessively exploited to inflate reputation scores. The smart contract uses a mapping structure to store these definitions: mapping(bytes8=>BehaviorType) behaviorTypes, where the BehaviorType structure contains fields such as behavior name, weight value, description information, and validity period.

[0143] The process of witness nodes collecting and verifying multi-source interaction data ensures the objectivity and accuracy of reputation assessment, preventing single-point data falsification and malicious manipulation. In specific implementation, witness nodes are special nodes in the vehicle-to-everything (V2X) consortium blockchain, possessing high computing and storage capabilities. They are typically operated by trusted third-party institutions, such as traffic management departments and telecommunications operators. After a target vehicle completes a valid interaction, the witness node collects relevant data through multiple channels. The first data source comes from the target vehicle itself, including a detailed description of the behavior, digital signature, timestamps, etc. The second data source comes from other vehicles within the influence range of the interaction; these vehicles act as "witnesses," providing confirmation information to prove that the behavior did indeed occur and was valid. The third data source comes from roadside infrastructure, such as traffic cameras and sensor networks, providing objective environmental data. The verification process employs a multi-layered cross-validation mechanism. First, the validity of the digital signatures from each data source is verified to ensure the data source is trustworthy. Then, the timestamps from different data sources are compared, with an allowed time difference range of ±30 seconds. Next, the consistency of geographical location information is verified using a GPS coordinate comparison algorithm, with an allowed positional deviation within 50 meters. Finally, the consistency of the behavior description is verified using natural language processing technology to analyze the similarity of the description content. The comprehensive scoring formula for the verification algorithm is:

[0144] ;

[0145] Only interactions with a comprehensive score of over 0.8 are considered valid.

[0146] The process of witness nodes generating raw reputation data requires standardizing, integrating, and structuring multi-source verified interaction data to form a unified reputation record format. In practice, the raw reputation data is generated in JSON format, containing several key fields to ensure information integrity and traceability. The data structure includes a vehicle identifier field, recording the digital genetic hash value of the target vehicle initiating the interaction. The behavior type field records the specific type code of the interaction, corresponding to the behavior type defined in step S310. The event timestamp uses a Unix time format, accurate to the millisecond level, ensuring the accuracy of time recording. The geographic location information includes GPS coordinates and address description. The witness information records the identifiers of other vehicles and infrastructure participating in the verification. The verification score records the comprehensive score result of multi-source verification. The event description field provides a detailed description of the interaction behavior, in the format "description": "An emergency braking situation was detected on a road section in Chaoyang District, Beijing, and a warning message was promptly sent to vehicles behind." The data integration process also includes deduplication to prevent the same interaction behavior from being recorded repeatedly, using a four-tuple based on vehicle identifier, behavior type, timestamp, and geographic location for deduplication. The generated raw reputation data also needs to pass format validation and integrity checks to ensure that all necessary fields are filled in correctly and the data format conforms to the predefined JSON Schema specification.

[0147] The process of generating a reputation digest by hashing the original reputation data based on reputation weights achieves digital summaries of reputation records and privacy protection, while ensuring data integrity and immutability. In practice, the hashing process first queries the corresponding reputation weight value based on the behavior type, using a predefined weight mapping table in the smart contract. Weighted hashing is applied, using reputation weights as influencing factors in the hashing operation. The weighting process sorts the key fields in the original reputation data by importance; behavior types with higher weights occupy more bits in the hash calculation. Specifically, the original reputation data is first serialized into a byte array, with the serialization order arranged according to field importance: vehicle identifier, behavior type, timestamp, geographical location, and witness information. Then, the repetition frequency of each field is adjusted according to the reputation weight: behavior types with a weight of 2.0 have their related fields repeated twice in the hash input; behavior types with a weight of 1.0 are repeated once; and behavior types with a weight of 0.5 are included with a probability of 0.5.

[0148] The hash operation uses the SHA-256 algorithm, calculated as: [Reputation Digest = SHA256(Weighted Data)]. To enhance security, a random salt and chain context information are also added. The salt is extracted from the first 32 bytes of the current block hash, and the context information includes the current block height and chain identifier. The final hash calculation formula is:

[0149] .

[0150] The generated reputation digest is 256 bits long, represented in hexadecimal format, and has good randomness and uniqueness, while protecting the privacy of the original data.

[0151] The process of linking reputation digests to the end of the reputation hash chain using hash pointers establishes a time-series chained structure of vehicle reputation records, ensuring the integrity and immutability of the reputation history. In its implementation, the reputation hash chain adopts a blockchain-like chained data structure, with each node containing information such as the current reputation digest, a forward hash pointer, a timestamp, and a sequence number. The hash pointer implementation is based on the one-way and collision-resistant properties of cryptographic hash functions; each new node contains a hash value pointing to the previous node, forming an unbreakable chain structure. The linking process first queries the head node of the current reputation hash chain, obtaining its hash value as the forward pointer to the new node. The creation of new nodes uses atomic operations to ensure the integrity of the linking process; the creation formula is as follows: The sequence number uses an incremental mechanism to ensure the uniqueness and temporal order of each node. To prevent chain forks and concurrent conflicts, a distributed lock mechanism is used to lock the chain head during the linking operation, ensuring that only one node can perform the linking operation at a time. The linking process also includes integrity verification, verifying whether the forward hash of the new node is consistent with the hash of the current chain head. The verification formula is:

[0152] .

[0153] After a successful connection, the chain head pointer is updated to point to the newly created node, and the chain length counter is also updated. The reputation hash chain uses distributed storage, maintaining replicas across multiple nodes in the consortium blockchain to ensure high data availability. The chain structure also supports efficient query operations; the indexing mechanism allows for quick location of reputation records for specific time periods or specific vehicles.

[0154] The process of recording the updated reputation hash chain header hash value in a finite state machine smart contract achieves a reliable association between on-chain records and off-chain data, establishing a mechanism for verifying the integrity of reputation data. In specific implementation, the smart contract maintains a dedicated state variable to store the reputation hash chain header information for each vehicle. The data structure is: mapping(bytes32 =>ReputationChainHead) reputationChains, where the ReputationChainHead structure contains key information such as the chain header hash, chain length, last update time, and updated block height. The recording process is implemented through the smart contract's state update function. The function accepts parameters such as the vehicle's digital gene, the new chain header hash, and a timestamp, and performs atomic state update operations. The update operation first verifies the caller's permissions, ensuring that only authorized witness nodes can execute the update operation. Permission verification uses a digital signature mechanism, and the verification formula is:

[0155] .

[0156] The state update process involves multiple verifications. First, it verifies the correct format of the new chainhead hash, ensuring it is a valid 256-bit hash value. Then, it verifies the monotony of the chain length; the new chain length must be one greater than the current chain length. Next, it verifies the validity of the timestamp, ensuring the update time is within a reasonable range. Finally, it verifies the consistency of the block height, ensuring the update operation occurs within the current block or the most recent few blocks. The update operation uses a Compare-And-Swap (CAS) mechanism to prevent data inconsistency caused by concurrent updates. The operation formula is as follows:

[0157] .

[0158] Upon successful update, the smart contract triggers the `ReputationUpdated` event, broadcasting the reputation update information to the network. This event includes information such as the vehicle identifier, the new chain header hash, and the update time. The smart contract also maintains global reputation statistics, including total interactions, average reputation score, and the number of active vehicles, providing data support for overall network reputation assessment. Gas consumption during the recording process is controlled within a reasonable range through optimized storage layout and data compression techniques, ensuring both economic efficiency and practicality.

[0159] Through the aforementioned hash chain-based vehicle reputation management mechanism, a distributed reputation assessment and recording system in the vehicle-to-everything (V2X) environment is established. The pre-defined behavior types and reputation weights provide standardized evaluation criteria for different interactive behaviors, achieving fairness and consistency in reputation assessment. Multi-source data collection and verification mechanisms effectively prevent data forgery and malicious manipulation, and cross-validation ensures the authenticity and reliability of reputation records. The standardized generation of raw reputation data provides a unified data format for subsequent processing, facilitating automated processing and analysis. Weighted hash operations not only protect the privacy of the raw data but also reflect the differences in importance between different behaviors through a weighting mechanism. The hash pointer linking mechanism establishes a complete temporal history of reputation, ensuring the immutability and traceability of reputation data. The chain header record in the smart contract enables a reliable association between on-chain indexes and off-chain data, providing an efficient access path for reputation queries and verification. The entire reputation management system not only incentivizes vehicles to actively participate in beneficial interactive behaviors but also effectively punishes malicious behaviors, forming a healthy network ecosystem. By establishing this complete credit assessment and management mechanism, the Internet of Vehicles (IoV) has upgraded from simple information exchange to trust-based intelligent collaboration, laying a solid foundation for building a safer, more reliable, and more efficient intelligent transportation system and promoting the development of IoV technology towards a more mature and practical direction.

[0160] In one implementation, the step of collecting and verifying multi-source interaction data related to the valid interaction by the witness node in the vehicle-to-everything (V2X) consortium blockchain after the target vehicle completes a valid interaction includes the following steps:

[0161] S410: Receive first interaction data containing a digital signature from the target vehicle that initiated the valid interaction behavior;

[0162] S420: Receive second interaction data from at least one other network participant within the scope of the effective interaction behavior;

[0163] S430. Integrate the first interactive data and the second interactive data into multi-source interactive data, and verify the consistency of event elements in the multi-source interactive data.

[0164] S440. Query the finite state machine smart contract of the target vehicle and confirm that the current lifecycle state of the finite state machine smart contract is the vehicle usage state.

[0165] S450. After the consistency verification of event elements is passed and the lifecycle status is confirmed to be correct, the multi-source interactive data verification is deemed to have passed.

[0166] Receiving the first interactive data containing a digital signature from the target vehicle initiating a valid interaction requires establishing a secure and reliable communication mechanism between the vehicle and the witness node to ensure the integrity and authenticity of data transmission. In practice, the witness node receives the interactive data from the target vehicle through a dedicated V2I (Vehicle-to-Infrastructure) communication interface. Communication uses DSRC (Dedicated Short Range Communication) or 5G-V2X standards, supporting reliable data transmission in high-speed mobile environments. The first interactive data is encapsulated in a standardized JSON format, containing several key fields: vehicle digital gene hash, interaction type, event description, geographic coordinates, timestamp, and digital signature. The digital signature is generated using the ECDSA algorithm, signing the entire data packet based on the vehicle's private key. The signing process first calculates the SHA-256 hash value of the data packet, then uses the elliptic curve digital signature algorithm to generate a signature pair (r,s). Upon receiving the data, the witness node immediately verifies the digital signature. The verification process recovers the public key through elliptic curve point operations. The verification formula is:

[0167] ;

[0168] The signature is valid if the x-coordinate of the verification point equals the r-value in the signature. The receiving process also includes data integrity checks, detecting transmission errors via CRC checksums, and timestamp verification to ensure data timeliness; only data with timestamps within ±60 seconds of the current time is accepted. This rigorous receiving and verification mechanism ensures the reliability of the source and the integrity of the first exchanged data.

[0169] Receiving second interaction data from other network participants within the effective interaction range requires establishing a dynamic multi-source data collection network to achieve multi-angle verification and confirmation of interaction events. In implementation, the witness node first determines the influence range based on the geographic location information and behavior type in the first interaction data. Different types of interaction behaviors have different influence radii: emergency braking warnings have an influence radius of 500 meters, general road condition information has an influence radius of 200 meters, and parking information has an influence radius of 100 meters. The influence range calculation uses a buffer analysis algorithm from a geographic information system, establishing a circular or elliptical influence area based on the GPS coordinates of the initiating vehicle. The witness node queries all network participants within the influence range through the node discovery mechanism of the vehicle-to-everything (V2X) consortium blockchain, including other vehicles, roadside units (RSUs), and traffic monitoring equipment. The query process uses location-based services (LBS) technology, employing spatial index structures such as quadtrees or R-trees to quickly locate participants within the range. Data collection combines active pulling and passive receiving; the witness node sends data request messages to participants within the range. Upon receiving the request, other network participants check whether they have observed the relevant event at the specified time and location. If they confirm observation, they return the second interaction data. The data collection process includes a timeout mechanism. Participants who do not receive a response within 10 seconds are considered unresponsive. A minimum response threshold is also set, requiring confirmation from at least three independent witnesses before further verification can proceed.

[0170] The process of integrating the first and second interaction data into multi-source interaction data and verifying the consistency of event elements requires advanced data fusion algorithms and multi-dimensional verification mechanisms to ensure the coordination and consistency of data from different sources. In practice, data integration first involves standardizing the format of all collected data, converting data of different formats into a unified data structure. The integrated multi-source interaction data includes fields such as key event information, a witness list, and consistency analysis results. Event element consistency verification includes four dimensions: temporal consistency, spatial consistency, behavioral consistency, and descriptive consistency. Temporal consistency verification compares the timestamps of each data source and calculates the standard deviation of time differences using the following formula:

[0171] ;

[0172] in The standard deviation of the timestamp. and These are the maximum and minimum timestamps, respectively; the closer the score is to 1, the better the temporal consistency. Spatial consistency verification calculates the distance difference between each observation location and the location where the event occurred, using the great circle distance formula:

[0173] ;

[0174] Where R is the Earth's radius. Spatial consistency score is calculated using a weighted average of the inverse of distance:

[0175] .

[0176] Behavioral consistency verification compares the behavioral types described by different data sources, uses a semantic similarity algorithm to convert the behavioral descriptions into vector representations, and calculates the cosine similarity:

[0177] .

[0178] Description consistency verification employs natural language processing technology to extract keywords and entities from event descriptions and calculate the overlap and similarity between descriptions. The overall consistency score is calculated using a weighted average.

[0179] ;

[0180] Only multi-source data with a comprehensive consistency score exceeding 0.75 are considered to have passed the consistency verification.

[0181] The process of querying the finite state machine smart contract of a target vehicle and confirming its current lifecycle state requires a reliable blockchain query mechanism to ensure the accuracy and real-time nature of vehicle status information. In practice, witness nodes query the smart contract corresponding to the target vehicle through the RPC interface of the vehicle-to-everything (V2X) consortium blockchain. The query process first constructs a contract query request based on the vehicle's digital gene hash value. The smart contract's `getCurrentState()` function returns the current lifecycle state enumeration value, encoded as follows: 0 represents the factory state, 1 represents the usage state, 2 represents the transaction state, and 3 represents the scrap state. The query process employs a multi-node parallel query mechanism, simultaneously sending query requests to at least three different consortium blockchain nodes. The accuracy of the query result is determined through majority voting, using the following voting formula: The `mode()` function returns the most frequently occurring state value. To prevent query results from being tampered with, a Merkle proof verification mechanism is also used, with each query result accompanied by a corresponding Merkle path proof.

[0182] The query process also includes a caching mechanism. Witness nodes maintain a local state cache with a 60-second validity period. Queries about the same vehicle within the cache's validity period directly return cached results, improving query efficiency. The state confirmation process not only checks if the current state is "in use," but also verifies the legality of state transitions. By querying the smart contract's state transition history, it ensures that the vehicle transitions normally from its factory state to its use state without any abnormal state jumps. Furthermore, it checks the vehicle's permission status to ensure that the vehicle has normal communication permissions and has not been temporarily disabled or restricted. The query timeout is set to 5 seconds. Vehicles that do not return results or return an incorrect state within the timeout period will be marked as having an abnormal state, and their initiated interactions will not be recognized.

[0183] After the event element consistency verification is passed and the lifecycle status is confirmed to be correct, the final multi-source interactive data verification and judgment are carried out. This requires comprehensive consideration of all verification results and the formulation of scientific judgment criteria. In specific implementation, the final verification and judgment adopts a multi-level decision tree algorithm, combined with the ideas of fuzzy logic and expert systems, to establish a comprehensive evaluation model. The judgment process first checks whether all preconditions are met, including: event element consistency score ≥ 0.75, vehicle lifecycle status is in use, number of witnesses ≥ 3, and data integrity check passed. After the preconditions are met, the comprehensive credibility assessment stage begins. The credibility calculation formula is:

[0184] ;

[0185] Where α=0.4, β=0.3, γ=0.2, and δ=0.1 are weighting coefficients. Witness weights are calculated based on the witness's historical reputation and certification level, which includes ordinary vehicles (weight 1.0), commercial vehicles (weight 1.2), official vehicles (weight 1.5), and roadside equipment (weight 1.8). The timeliness coefficient is calculated based on the interval between the event occurrence time and the verification time; the shorter the interval, the higher the coefficient. The formula is:

[0186] ;

[0187] Where λ=0.1 is the attenuation coefficient, and Δt is the time interval (minutes). The historical reputation coefficient is extracted from the vehicle's historical reputation chain, reflecting the credibility of the vehicle's past behavior. The final judgment adopts a threshold decision mechanism: when the credibility is ≥0.8, it is judged as verified successfully; when the credibility is 0.6≤credibility<0.8, it is judged as requiring further verification; and when the credibility is <0.6, it is judged as verification failed. The verification results include a detailed evaluation report, recording the scores of each dimension, the judgment basis, witness information, etc., providing a basis for subsequent reputation assessment and dispute resolution. Verified interactive data will be marked as "verified" and enter the reputation summary generation process; data that fails verification will be marked as "invalid" and recorded in the abnormal behavior log. The execution time of the entire judgment process is controlled within 2 seconds to ensure real-time requirements.

[0188] Through the aforementioned multi-source interaction data collection, integration, and verification mechanisms, a distributed event verification system in the vehicle-to-everything (V2X) environment was established, effectively improving the credibility and accuracy of interaction behavior records. Digital signature verification of the first interaction data ensures the authenticity of the data source, preventing identity forgery and data tampering by malicious nodes. The multi-source data collection mechanism, by introducing multiple independent witnesses, constructs multiple safeguards for event verification, significantly reducing the risk of single-point forgery. The data integration and consistency verification process employs multi-dimensional verification algorithms, cross-verifying the authenticity of events from multiple perspectives such as time, space, behavior, and description, ensuring the objectivity and accuracy of the verification results. The smart contract status query mechanism confirms the legality and permission status of vehicles in real time, preventing interference from invalid data from vehicles in abnormal states. The comprehensive judgment algorithm, combining multiple evaluation factors and weighting mechanisms, achieves a scientific quantitative evaluation of interaction events, improving the reliability and fairness of the judgment results. The entire verification process not only guarantees data quality but also provides high-quality input data for subsequent reputation assessments, effectively preventing the impact of false information and malicious behavior on the V2X reputation system. By establishing this complete multi-source verification mechanism, the Internet of Vehicles (IoV) has upgraded from simple information transmission to trusted event authentication, laying a solid foundation for building a vehicle reputation system based on real behavior and promoting the development of the IoV towards a safer, more reliable, and intelligent direction.

[0189] In one implementation, the step of triggering the transition of the finite state machine smart contract from the vehicle usage state to the vehicle transaction state in response to an ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party of the target vehicle includes the following steps:

[0190] S510, An initial ownership transfer request containing a unique identifier for the transaction is generated by an authorized third party;

[0191] S520: Add the locally generated public key to the initial ownership transfer request through the new vehicle owner of the target vehicle, and digitally sign it using the private key of the new vehicle owner;

[0192] S530. When the original owner of the target vehicle receives an ownership transfer request that already contains the signature of the new owner, the original owner's private key is used to digitally sign it.

[0193] S540. After the authorized third party verifies that the signatures of both the original vehicle owner and the new vehicle owner are valid, the authorized third party shall add the digital signature of the authorized third party to the ownership transfer request.

[0194] S550 submits the ownership transfer request, jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party, as a transaction to the vehicle network alliance chain, triggering the finite state machine smart contract to switch from the vehicle usage state to the vehicle transaction state.

[0195] Authorizing a third party to generate an initial ownership transfer request containing a unique transaction identifier requires establishing a standardized transaction request format and a uniqueness guarantee mechanism to ensure that each transfer request has global uniqueness and complete transaction information. In practice, authorized third parties are typically government vehicle management departments, certified used car trading platforms, or qualified financial institutions, all of which have legally authorized vehicle ownership transfer authorization. The unique transaction identifier is generated using the UUIDv4 algorithm to ensure global uniqueness. The identifier format is "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx", where x is a hexadecimal number and y is 8, 9, A, or B. The generation algorithm combines the current timestamp, the authorized third party's institutional identifier, and a random number; the calculation formula is as follows: The initial transfer request is constructed in JSON format and includes several key fields: a unique transaction identifier, a vehicle digital genogram hash, a reserved field for the original owner's identification, a reserved field for the new owner's identification, authorized third-party information, transaction initiation time, and validity period. The generation process also includes data integrity protection, generating a data fingerprint by calculating the SHA-256 hash value of the request content to prevent data tampering during subsequent transmission. After generating the request, the authorized third party pre-signs the request using their private key. The pre-signature uses the ECDSA algorithm, with the hash value of the request as the signature object. The purpose of the pre-signature is to prove the authority of the request and prevent forgery. The generated initial request also includes auxiliary information such as transaction type identifier, transaction fee information, and legal clause references, providing complete contextual information for subsequent transaction processing.

[0196] The process of the new vehicle owner adding the locally generated public key to the initial transfer request and digitally signing it requires ensuring key security and signature validity, establishing cryptographic proof of the new owner's identity. In practice, the new vehicle owner first receives the initial transfer request from an authorized third party, ensuring the confidentiality of data transmission through a secure channel (such as a TLS encrypted connection). The new owner generates a new elliptic curve key pair in a local secure environment, using the secp256r1 curve. The private key is a 256-bit random number, and the public key is obtained through elliptic curve dot product operations. Where G is the base point of the elliptic curve. The key generation process uses a cryptographically secure random number generator to ensure the unpredictability and uniqueness of the private key. The generated public key is represented in an uncompressed format, containing 64 bytes of coordinate data (32 bytes of x-coordinate + 32 bytes of y-coordinate), prefixed with "04" to identify the uncompressed format. The new owner adds the public key information to the "newOwnerField" field of the initial transfer request, including the public key data, the public key generation timestamp, and the new owner's identity verification hash.

[0197] The digital signature process signs the updated complete request. First, it calculates the SHA-256 hash of the request, and then uses the ECDSA algorithm to generate a signature. The signature calculation formula is as follows:

[0198] ;

[0199] Where k is a random number, H is a hash function, and n is the order of the elliptic curve. The generated signature pair (r, s) is appended to the signature field of the request. The signing process also includes signature verification. The new car owner performs self-verification immediately after generating the signature to ensure its correctness. After successful verification, the signed request is sent to the original car owner.

[0200] The process by which the original vehicle owner digitally signs and confirms a received ownership transfer request containing the new vehicle owner's signature requires verifying the validity of the new owner's signature and expressing their intention to transfer, thus forming a legally valid transfer authorization. In practice, the original vehicle owner receives the transfer request containing the new owner's signature through a secure communication channel and first verifies the new owner's signature. The signature verification process uses an elliptic curve digital signature verification algorithm, verifying the signature's validity through public key recovery and point arithmetic. The verification formula is as follows:

[0201] ;

[0202] The signature is valid if the x-coordinate of the verification point equals the r-value in the signature. After successful verification, the original owner checks whether the vehicle information in the request matches their own vehicle, including comparisons of key data such as the vehicle's digital genetic hash and vehicle identification information. Once the information is confirmed to be correct, the original owner digitally signs the entire request using their private key. The signing process also uses the ECDSA algorithm, but the signed message is a complete request containing the new owner's signature, ensuring the signature's temporality and integrity. The original owner's signature calculation process is as follows: First, they extract their private key registered in the vehicle's smart contract, calculate the hash value of the request containing the new owner's signature, and then perform a signature operation to generate a signature pair (r, s). After the signature is generated, the original owner adds their signature to the "originalOwnerSignature" field of the request. To ensure the signature's non-repudiation, the original owner also needs to provide additional identity verification information, including an authentication code and biometric hash. This information, along with the signature, forms a complete transfer authorization certificate. After signing, the original owner sends the signed request back to the authorized third party, awaiting final confirmation and processing. The entire process also includes recording and verifying the signature timestamp to ensure the timeliness and legal validity of the signature.

[0203] Authorizing a third party to verify the signature validity of both the original and new vehicle owners and to add its own digital signature requires a complete multi-party signature verification mechanism and authoritative authentication process to ensure the legality and integrity of the ownership transfer. In practice, upon receiving a transfer request containing both parties' signatures, the authorized third party first performs a systematic signature verification operation. The verification process employs a parallel verification mechanism, independently verifying both the original owner's and the new owner's signatures simultaneously to improve efficiency. For verifying the new owner's signature, the authorized third party extracts the new owner's public key and signature data from the request and verifies it using the standard ECDSA verification algorithm. The verification message is the initial request after adding the public key information. For verifying the original owner's signature, the authorized third party queries the vehicle's smart contract for the original owner's currently valid public key and then verifies the signature's validity. The verification message is the complete request containing the new owner's signature.

[0204] Timing verification ensures the signatures are generated in the correct order; the new owner's signature should be earlier than the original owner's, and the interval between the two should be within a reasonable range (usually within 24 hours). Integrity verification ensures the data has not been tampered with during transmission by comparing the hash values ​​of each stage of the request. After successful verification, an authorized third party uses its authoritative private key to finally sign the entire request. The signed message content is the complete request containing the signatures of both parties, and the generated signature represents official recognition and authorization of this ownership transfer. The authorized third party's signature uses a stronger signature algorithm, such as RSA-4096 or ECC-P384, to ensure the signature's authority and unforgeability. The signature generation formula is:

[0205] .

[0206] The final signature is added to the "authorizedSignature" field of the request, which contains information such as signature data, signature timestamp, and authorization authority certificate hash.

[0207] Submitting a shared ownership transfer request, digitally signed by all three parties, as a blockchain transaction to the connected vehicle consortium blockchain and triggering a smart contract state switch requires a reliable blockchain transaction mechanism and an automated state management process. In implementation, an authorized third party encapsulates the complete three-party signature request into a standard blockchain transaction. The transaction uses an Ethereum-compatible format, including standard fields such as transaction hash, sender address, receiver address (smart contract address), transaction data, and gas fees. The transaction data field contains function call information for the smart contract, specifically the "requestOwnershipTransfer" function, whose parameters include the complete transfer request data and the three-party signature information. The transaction data uses ABI encoding, with the encoded data typically ranging from 2-5KB in length. Digital signatures ensure the transaction's authorization during submission. The authorized third party signs the transaction using their private key, following Ethereum's transaction signature standards. The submission process sends the transaction to the consortium blockchain nodes via a JSON-RPC interface. Upon receiving the transaction, the consortium blockchain nodes first perform basic verification, including verifying the transaction format, signature validity, and gas fee adequacy. Verified transactions are added to the mempool, awaiting inclusion in blocks by miners. When the smart contract's "requestOwnershipTransfer" function executes, it first verifies whether the caller is an authorized third-party organization, and then verifies the validity and integrity of the three-party signatures. The verification process includes multiple steps such as signature format checking, public key matching verification, and message integrity verification. After all verifications pass, the smart contract triggers a state transition, updating the vehicle's lifecycle state from "Usage State" (value 1) to "Transaction State" (value 2). The state transition uses atomic operations to ensure consistency of state updates, and also records the timestamp of the state change and the hash value of the triggering transaction during the transition. After the state switch is complete, the smart contract emits an "OwnershipTransferInitiated" event, broadcasting the state change information to the entire network. The event includes key information such as the vehicle identifier, original owner's address, new owner's address, and transfer request hash. Simultaneously, a permission decay mechanism is initiated, gradually reducing the original owner's communication permissions to prepare for a smooth permission transition.

[0208] The aforementioned vehicle ownership transfer process based on third-party digital signatures establishes a secure, reliable, and compliant digital vehicle asset transfer mechanism. The unique identifier generated by the authorized third party ensures the global uniqueness and traceability of each transfer request, providing a reliable data foundation for subsequent dispute resolution and auditing. The local generation of the new owner's public key and the digital signature mechanism guarantee the authenticity of the new owner's identity and the clear expression of their transfer intention, preventing identity theft and malicious transfers. The original owner's signature confirmation establishes explicit transfer authorization, and cryptographic proof ensures the legality and non-repudiation of the transfer process. The authoritative signature verification and additional signatures of the authorized third party provide official recognition and legal protection for the transfer request, ensuring that the transfer process complies with regulatory requirements. The parallel verification and timing control of the third-party signature mechanism effectively prevent security threats such as signature forgery and replay attacks, ensuring the security of the transfer process. The standardized submission of blockchain transactions and the automated state management of smart contracts digitize and automate the transfer process, significantly improving processing efficiency and reducing the risk of errors from human intervention. The synchronous activation of the permission decay mechanism ensures a smooth transition during the ownership transfer process, avoiding the security window issue of permission handover. The entire process not only ensures the security and legality of vehicle digital asset transfer, but also provides a digital upgrade solution for the traditional paper-based transfer process, promoting the development of vehicle asset management towards intelligence and automation.

[0209] In one embodiment, the startup permission decay mechanism gradually reduces the communication permissions of the key pair held by the original vehicle owner during vehicle transactions, including the following steps:

[0210] When the S610 finite state machine smart contract enters the vehicle transaction state, a preset block height timer is started.

[0211] S620. Based on the height difference between the current block height and the timer start height, query the permission decay rule table preset in the finite state machine smart contract. The permission decay rule table defines the highest priority of the vehicle network messages that the key pair held by the original vehicle entity is allowed to send within different height difference ranges. As the height difference increases, the highest priority of the messages that the original vehicle entity is allowed to send decreases unidirectionally.

[0212] S630. When the height difference reaches the preset threshold, the sending permission of the key pair held by the original vehicle body is cleared, and only the receiving permission is retained.

[0213] When a finite state machine smart contract enters the vehicle transaction state, starting a preset block height timer requires establishing a precise time measurement mechanism and an automated timer management system to ensure the accuracy and reliability of the privilege decay process. In implementation, the block height timer is a time measurement system based on the blockchain network, utilizing the sequential generation of blocks to achieve precise time measurement. When the smart contract's state transitions from "use state" to "transaction state," the state transition function within the contract automatically triggers the timer startup operation. The timer startup process first obtains the latest block height of the current blockchain network by calling the global variable "block.number" of the blockchain node to get the current block number, for example, the current block height is 15678932. The startup timestamp is recorded using a dual-recording mechanism, recording both the block height and the Unix timestamp. The timer's data structure uses the smart contract's state variables for storage, defined as: struct DecayTimer {uint256 startBlockHeight; uint256 startTimestamp; bool isActive; uint256 lastUpdateHeight;}. Upon startup, the timer immediately performs initialization operations, setting its state to active, recording the exact startup time, and initializing relevant auxiliary variables. To ensure reliability, a redundant backup mechanism is implemented, allowing the timer's status information to be queried from multiple smart contract functions. The startup process also includes event logging, broadcasting the "DecayTimerStarted" event across the network via the `emit` statement. Event parameters include key information such as vehicle identifier, startup block height, and startup timestamp. Gas consumption during timer startup is optimized and kept low to ensure economic efficiency and practicality.

[0214] To dynamically adjust communication permissions by querying the permission decay rule table based on the height difference between the current block height and the timer's starting height, a scientific permission hierarchy and intelligent permission management mechanism are needed to achieve smooth permission transition and precise control. In implementation, the permission decay rule table adopts a piecewise function design, dividing the entire decay process into multiple stages, each corresponding to a different permission level and message priority restriction. The rule table is predefined in the smart contract and stored using a mapping structure, where the key is the block height difference range and the value is the corresponding permission level. Permission levels are divided into five levels: Full Permission (Level 5), High Permission (Level 4), Intermediate Permission (Level 3), Basic Permission (Level 2), Restricted Permission (Level 1), and No Sending Permission (Level 0). Specifically, the ranges are: 0-100 blocks correspond to Level 5, 101-300 blocks to Level 4, 301-600 blocks to Level 3, 601-1000 blocks to Level 2, 1001-1500 blocks to Level 1, and blocks exceeding 1500 blocks to Level 0. Message priorities are also divided into five levels: Urgent messages (priority 5), Important messages (priority 4), General messages (priority 3), Ordinary messages (priority 2), and Low-priority messages (priority 1). The correspondence between permissions and message priorities is as follows: Permission level N can only send messages with priority ≤ N. The formula for calculating the height difference is: The query process employs a binary search algorithm to improve efficiency, with a time complexity of O(log n). The permission adjustment process not only modifies sending permissions but also synchronously updates related network parameters, such as message forwarding permissions and consensus participation permissions. The adjustment operation uses atomic transactions to ensure consistent updates of all related permissions. Each permission adjustment generates detailed log records, including the adjustment time, permission changes, and triggering conditions, providing a basis for auditing and troubleshooting.

[0215] When the height difference reaches a preset threshold, the sending permission of the key pair held by the original vehicle owner is cleared, retaining only the receiving permission. A strict permission control mechanism and a robust permission status management system are needed to ensure the security and integrity of the permission transfer process. In practice, the preset threshold is typically set to 1500 blocks, corresponding to approximately 6-8 hours (assuming an average block time of 15 seconds). This time window satisfies the processing needs of normal transactions while effectively preventing permission abuse. The threshold check employs an automated monitoring mechanism. The smart contract checks whether any vehicle's permission decay process has reached its final stage with each block height update. The check is performed by comparing the current height difference with the preset threshold, with the condition: \[height difference \geq preset threshold \]. When the condition is met, the smart contract automatically executes the permission clearing operation. This operation is irreversible, ensuring the determinism of the permission transfer. The permission reset process involves several steps: First, the original owner's sending permission is marked as "disabled," with the permission level set to 0. Then, the network's access control list is updated, removing the original owner's key pair's sending permission entry. Next, all nodes in the vehicle network are notified, broadcasting the permission change information. Finally, the timestamp and block height of the permission reset are recorded, creating an immutable permission change record. Retention of receiving permissions is finely controlled; the original owner can still receive messages from other vehicles but cannot initiate communication or broadcast information. The retention period for receiving permissions is typically set to an additional 1000 blocks, providing the original owner with a buffer period to receive important notifications. The permission reset operation triggers the "PermissionRevoked" event, whose parameters include the vehicle identifier, the original owner's address, the permission reset time, and the retained receiving permission information. The entire process also includes an exception handling mechanism; if an exception occurs during the permission reset process, the smart contract rolls back to a safe state and records the error information. The execution of permission reset also synchronously updates the vehicle's reputation assessment parameters, ensuring the consistency and accuracy of the reputation system.

[0216] Through the aforementioned block height-based permission decay mechanism, a smooth permission transition system is established during vehicle ownership transfer, effectively solving the security window problem in traditional permission management. The activation of the block height timer provides a precise time benchmark for permission decay, leveraging the immutability of the blockchain network to ensure accuracy and reliability, avoiding the security risks of malicious modification of traditional timestamps. The segmented permission decay rule table design enables gradual permission degradation, ensuring the original owner's basic communication needs during the transaction while gradually restricting their permission scope, preventing malicious use and abuse of permissions. The five-level permission hierarchy, combined with a five-level message priority mechanism, provides fine-grained permission control for communication behaviors of varying importance, ensuring the normal transmission of urgent and important information. The automated permission adjustment mechanism reduces the need for manual intervention, improving the efficiency and accuracy of permission management, while ensuring the consistency of permission states through atomic transactions. The final permission reset operation draws a clear boundary for ownership transfer, ensuring a clear separation of permissions between the old and new owners, preventing permission conflicts and confusion. The temporary retention of receiving permissions reflects a human-centered design consideration, providing the original vehicle owner with a buffer period to receive important notifications and avoiding the inconvenience that might be caused by a sudden network outage. The transparency and traceability of the entire permission decay process provide reliable data support for dispute resolution and compliance audits. By establishing this complete permission decay mechanism, the Internet of Vehicles has upgraded from extensive permission management to refined and intelligent permission control, providing technical assurance for the secure transfer of vehicle digital assets.

[0217] In one implementation, the preset lifecycle states of the finite state machine smart contract also include a vehicle scrapping state, and the method further includes the following steps:

[0218] S710. When the target vehicle reaches the scrapping standard, a qualified scrapping and recycling organization, as the authorized third party for scrapping, shall jointly sign with the owner of the last generation vehicle and initiate a scrapping request in the vehicle network alliance chain.

[0219] S720. Once the scrapping request is verified through consensus in the vehicle network consortium blockchain, the finite state machine smart contract is triggered.

[0220] S730: The lifecycle state of the target vehicle is permanently changed to the vehicle scrapping state in an atomic transaction through a finite state machine smart contract.

[0221] S740, The event of requesting the scrapping of the target vehicle by associating the key pair held by the last generation vehicle owner with the key pair.

[0222] S750 broadcasts the lifecycle state change of the finite state machine smart contract to the entire vehicle network consortium blockchain, so that any communication initiated using a key pair related to the vehicle's digital genes will be rejected by the vehicle network consortium blockchain.

[0223] When a target vehicle reaches the scrapping standard, a scrapping request is initiated jointly by a qualified scrapping and recycling organization and the last remaining vehicle owner. This requires a strict qualification certification system and a standardized scrapping process control mechanism to ensure the legality and authority of the scrapping operation. In practice, the determination of vehicle scrapping standards is based on a comprehensive assessment of multiple dimensions, including key indicators such as vehicle age (generally 15 years), mileage (usually 600,000 kilometers), safety inspection results, and emission standard compliance. The scrapping and recycling organization must possess nationally recognized vehicle recycling and dismantling qualifications, including a hazardous waste disposal license issued by the environmental protection department and a recycling business operation license issued by the industry and commerce department. The qualification verification process is conducted through a pre-set whitelist of authorized organizations in a smart contract. The whitelist contains the digital certificate hashes and public key information of certified organizations. The scrapping request is generated using a two-party collaborative signature mechanism. First, the scrapping and recycling organization creates an initial scrapping request, including key information such as the vehicle's digital gene hash, the reason for scrapping, the recycling organization information, and the estimated scrapping time. After receiving the scrapping request, the owner of the last-generation vehicle uses their private key to digitally sign and confirm the request. The signing process uses the ECDSA algorithm, and the calculation formula is as follows: After verifying the validity of the vehicle owner's signature, the scrapping and recycling organization uses its authoritative private key to perform a second signature, creating a double-signed scrapping request. The entire signing process also includes timestamp verification and geolocation confirmation to ensure the authenticity and timeliness of the scrapping request.

[0224] The scrapping request, verified through consensus and triggering a finite state machine smart contract within the vehicle-to-everything (V2X) consortium blockchain, requires a multi-layered verification mechanism and an automated contract triggering process to ensure the reliability and irreversibility of the scrapping operation. In practice, the scrapping request is submitted to the consortium blockchain network as a special type of blockchain transaction. The transaction data includes complete scrapping request information and digital signatures from both parties. The consensus verification process employs an improved PBFT (Practical Byzantine Fault Tolerance) algorithm, supporting consensus even in the presence of malicious nodes. The verification process consists of three phases: a pre-preparation phase verifying the transaction format and signature validity; a preparation phase confirming the fulfillment of scrapping conditions; and a submission phase executing the final consensus decision. Verification nodes need to check several key conditions: the validity of the scrapping and recycling organization's qualifications, the legality of the vehicle owner's identity, the correctness of the vehicle's current state, and the sufficiency of the scrapping reason. Qualification verification is achieved by querying the on-chain organization whitelist, and the verification formula is:

[0225] .

[0226] Vehicle status verification is achieved by querying the smart contract status of the target vehicle to ensure that the vehicle is currently in a scrappable state (neither scrappable nor abnormal). The consensus process requires the agreement of more than 2 / 3 of the honest nodes to pass verification; the consensus formula is as follows:

[0227] .

[0228] Upon successful verification, the consortium blockchain automatically triggers the finite state machine smart contract corresponding to the target vehicle, calling the "processScrapRequest" function within the contract. The triggering process employs an event-driven mechanism; the consensus completion event automatically activates the smart contract's state transition logic. Trigger information includes key data such as the hash value of the scrapping request, the consensus result, and the verification timestamp, ensuring the accuracy and traceability of contract execution. The entire verification and triggering process is executed within 30 seconds, guaranteeing the timeliness and efficiency of the scrapping operation.

[0229] To permanently change the lifecycle state of a target vehicle to a scrapped state within an atomic transaction using a finite state machine smart contract, a strict state transition control mechanism and an irreversible state locking system are needed to ensure the permanence and uniqueness of the scrapped state. In implementation, the smart contract's "processScrapRequest" function executes complex state transition logic. First, it verifies whether the current vehicle state allows for the scrapping operation; only vehicles in the "use state" or "transaction state" can be transitioned to the "scrapped state." The state transition verification uses a finite state transition diagram of the state machine to ensure the legality of the state change. The verification formula is as follows:

[0230] .

[0231] Atomic transactions are implemented through the smart contract's transaction control mechanism, using require statements and revert mechanisms to ensure that all operations either all succeed or all fail. The state change process involves multiple synchronous operations: updating the lifecycle state enumeration value, recording the state change timestamp, updating the state change counter, and generating a state change proof. State value updates are irreversible; once set to "dead state" (enumeration value 3), that state can never be changed to another state. The state locking mechanism is implemented by setting a special locking flag; the locking formula is:

[0232] .

[0233] State changes also include the preservation of historical records, writing complete state transition information into the contract's history log. The record format is: {"fromState":"Usage Status","toState":"Scrap Status","changeTime":1640995200123,"requestHash":"0x4d5e6f7a...","blockHeight":15678933}. The execution of atomic transactions also triggers related cleanup operations, including finalization of the reputation hash chain, clearing the permission table, and dismantling associations. The entire state change process generates an immutable blockchain record, providing reliable data support for the complete lifecycle management of vehicles. After the change is completed, the smart contract issues a "VehicleScrapStatusSet" event to notify the entire network of the completion of the state change.

[0234] Associating the key pair held by the last-generation vehicle owner with the vehicle's scrapping request event requires establishing a complete key lifecycle management mechanism and event association traceability system to ensure the permanent binding and traceability of the key pair with the vehicle scrapping event. In implementation, the key pair association process is achieved through a dedicated association function in a smart contract. This function accepts parameters such as the vehicle owner's public key, the scrapping request event hash, and the association timestamp. The association operation first verifies the validity and ownership of the key pair, ensuring that the provided public key indeed belongs to the last-generation vehicle owner. This verification process compares the currently valid public key recorded in the contract with the provided public key. The verification formula is as follows:

[0235] . Event association uses hash chaining, cryptographically binding the hash value of the key pair with the hash value of the scrap request event. The binding formula is as follows:

[0236] .

[0237] The association information is stored in a dedicated mapping structure within the smart contract, with the mapping format: mapping(bytes32 => ScrapAssociation). The ScrapAssociation structure contains key information such as the public key hash, event hash, association time, and block height. The association process also includes digital signature verification, requiring the vehicle entity to sign and confirm the association operation using the corresponding private key, ensuring the authorization and non-repudiation of the association operation. After the association operation is executed, the key pair is permanently marked as "dead association," and any subsequent communication initiated using this key pair will be rejected by the smart contract. The association record also contains complete audit information, recording detailed information such as the executor, execution time, and operation parameters of the association operation, providing data support for subsequent auditing and dispute resolution. The association process also triggers the "KeyPairAssociated" event, broadcasting the key pair association information to the network. The event parameters include key data such as the public key hash, event hash, and association status.

[0238] Broadcasting the lifecycle state changes of finite state machine smart contracts across the entire vehicle-to-everything (V2X) consortium blockchain and rejecting related key pair communications requires an efficient network broadcasting mechanism and a comprehensive communication interception system to ensure the complete isolation of scrapped vehicles and network security. In implementation, network-wide broadcasting combines smart contract event mechanisms with P2P network propagation to ensure that state change information is quickly transmitted to every node in the network. The broadcast process begins with the smart contract issuing a "VehicleLifecycleChanged" event. Event parameters include the vehicle's digital genetic hash, the new state value, the change timestamp, and related key pair information. Event propagation uses the blockchain network's native propagation mechanism; as new blocks are generated and synchronized, the state change information is propagated throughout the network. To accelerate the propagation process, an active push mechanism is also employed. After receiving the state change event, key nodes actively push updated information to neighboring nodes. Upon receiving the broadcast information, network nodes immediately update their local vehicle state cache and access control list, adding the relevant key pairs of scrapped vehicles to the blacklist. The communication interception mechanism is implemented by modifying the message filtering rules at the network layer; all messages signed using key pairs from the blacklist are automatically discarded. The interception judgment formula is:

[0239] .

[0240] The interception system also includes intelligent identification capabilities, capable of recognizing various communication attempts using scrapped vehicle key pairs, including direct communication, relay forwarding, and anonymous communication. To ensure the accuracy of interception, a whitelist exemption mechanism has been established, allowing legitimate communication in certain special circumstances (such as regulatory inquiries and audit access) to bypass interception with special authorization. The execution efficiency of the entire broadcast and interception process is optimized through distributed caching and parallel processing technologies, ensuring that state change information can propagate to over 99% of network nodes within 5 minutes.

[0241] Through the aforementioned smart contract-based vehicle scrapping status management mechanism, a complete closed-loop management system for the vehicle lifecycle has been established, achieving full digital tracking and control from vehicle manufacturing to final scrapping. The two-party signature mechanism for scrapping requests ensures the legality and authority of the scrapping operation, preventing malicious and invalid scrapping requests. The qualification certification system guarantees the professionalism and credibility of scrapping and recycling organizations. The multi-level verification mechanism of the consensus verification process effectively prevents the passage of false scrapping requests, ensuring that only vehicles that truly meet the scrapping standards can enter the scrapping process, maintaining the health and order of the vehicle-to-everything (V2X) ecosystem. Atomic transaction state change operations guarantee the permanence and irreversibility of the scrapping state, avoiding data inconsistency issues during state change processes and providing reliable technical protection for vehicle asset management. The key pair and scrapping event association mechanism establishes a complete key lifecycle management system, ensuring that all cryptographic credentials related to scrapped vehicles are properly handled, preventing the malicious use of discarded keys. The network-wide broadcast and communication interception mechanisms achieve complete network isolation of scrapped vehicles, effectively preventing security risks and network pollution that may arise from scrapped vehicles continuing to participate in V2X communication. The entire end-of-life management process not only enhances the digitalization of vehicle asset management but also provides technical support for related fields such as environmental supervision, resource recycling, and safety control. By establishing this complete end-of-life status management mechanism, the Internet of Vehicles (IoV) achieves closed-loop management of the entire vehicle lifecycle, laying a solid foundation for building a safer, more environmentally friendly, and sustainable intelligent transportation ecosystem.

[0242] In one implementation, after permanently changing the lifecycle state of the target vehicle to a scrapped state in an atomic transaction via a finite state machine smart contract, the following steps are also included:

[0243] S810. Desensitize the complete reputation hash chain anchored in the finite state machine smart contract. Desensitization includes removing the direct association between the reputation hash chain and the vehicle's digital genes and the main body of the vehicle throughout the generations.

[0244] S820: Retain the de-identified reputation hash chain and archive the de-identified reputation hash chain into the preset historical reputation database;

[0245] S830. Statistical analysis and training of the macro-trust model of the entire vehicle network alliance chain based on historical reputation database;

[0246] S840. Provide access to the historical reputation database to regulatory authorities, provided that the data is not traceable back to the original vehicle.

[0247] De-identifying the complete reputation hash chain anchored in a finite state machine smart contract requires establishing a strict privacy protection mechanism and a systematic data de-identification process to ensure the complete removal of personal privacy information and data security. In implementation, the de-identification process first extracts the complete reputation hash chain of the target vehicle from the smart contract. This chain contains records of all interactions from the vehicle's use to its scrapping. The reputation hash chain structure contains multiple nodes, each containing information such as reputation digest, timestamp, behavior type, and forward hash pointer, as well as direct association identifiers with the vehicle's digital genetic code and the vehicle's owner. The core of the de-identification process is to remove all identifying information that could lead to data traceability to a specific vehicle or owner, including sensitive data such as the vehicle's digital genetic hash, owner's public key, and vehicle identification number. The removal process uses a field replacement algorithm to replace sensitive fields with randomly generated anonymous identifiers. The replacement formula is: The process generates 128-bit anonymous identifiers. The anonymization process also includes time obfuscation, converting precise timestamps into time intervals, such as converting "2023-12-15 10:30:25" to "2023-12-15 10:00-11:00", reducing the precision of the time information. Geographic location information anonymization uses coordinate offsetting and regionalization, converting precise GPS coordinates into approximate geographical areas. Behavioral description information anonymization is achieved through keyword filtering and semantic generalization, removing descriptive information that may contain vehicle characteristics or owner identity. The anonymization process also involves breaking associations; multiple reputation records originally connected by the vehicle's digital gene are reassigned anonymous identifiers, making it impossible to re-establish associations through data analysis. The entire anonymization process uses irreversible algorithms to ensure that the anonymized data cannot be restored to the original data, while maintaining the statistical characteristics and analytical value of the data.

[0248] Preserving the anonymized reputation hash chain and archiving it to a pre-defined historical reputation database requires a dedicated data storage architecture and an efficient data management system to ensure long-term preservation and rapid access to historical data. In implementation, the historical reputation database adopts a distributed storage architecture, combining the advantages of relational and NoSQL databases to achieve unified management of structured and unstructured data. The database design includes several core table structures: an anonymous reputation record table, a behavior type statistics table, a time series index table, and a geographic region distribution table. The structure of the anonymous reputation record table includes fields such as anonymized identifier, anonymized reputation summary, behavior type, time interval, and geographic region. The archiving process first converts the anonymized reputation hash chain into a table structure that can be stored in a relational database, maintaining the original temporal relationships and logical connections. Data insertion uses batch processing, and transaction control ensures data consistency and integrity. To improve query efficiency, a multi-dimensional index structure is established, including time indexes, behavior type indexes, and geographic region indexes. The index creation formula is:

[0249] This typically improves query efficiency by 10-100 times. The database also includes data compression and archiving strategies, compressing historical data older than a certain number of years with compression rates reaching 60-80%. The archiving process also includes data integrity verification, using hash checks to ensure consistency between archived data and the original, anonymized data. The database design also considers scalability and maintainability, supporting horizontal scaling and online upgrades, providing technical assurance for large-scale data storage.

[0250] Statistical analysis and training of the macro-trust model for the entire connected vehicle alliance chain based on historical reputation databases requires the establishment of advanced data mining algorithms and machine learning models to achieve deep insights and intelligent analysis of the connected vehicle ecosystem. In specific implementation, the macro-trust model adopts a multi-layered statistical analysis framework, including descriptive statistics, correlation analysis, time series analysis, and predictive modeling. Descriptive statistical analysis calculates basic indicators such as the frequency distribution of various behavior types, statistical characteristics of reputation weights, and time distribution patterns. The calculation formulas include:

[0251] .

[0252] Correlation analysis calculated the degree of association between different behavioral types using Pearson and Spearman correlation coefficients. Time series analysis employed the ARIMA model and seasonality decomposition method to identify cyclical patterns and trends in reputation behavior. The model formula is as follows:

[0253] .

[0254] The machine learning model is trained using deep learning methods, including Recurrent Neural Networks (RNNs) and Long Short-Term Memory Networks (LSTMs), to predict the development trend of vehicle-to-everything (V2X) reputation behavior. The model training process combines supervised and unsupervised learning. The training dataset contains 80% historical reputation data, and the validation dataset contains 20%. Model evaluation uses multiple metrics, including precision, recall, and F1 score. The evaluation formula is as follows:

[0255] .

[0256] The training process also includes feature engineering, which extracts multi-dimensional features such as time features, frequency features, and statistical features to improve the model's prediction accuracy and generalization ability.

[0257] Providing access to the historical reputation database to regulatory authorities, while ensuring data cannot be traced back to the original vehicle, requires establishing a secure and controllable data sharing mechanism and a fine-grained access control system to balance data accessibility with privacy protection. In implementation, the access interface adopts a RESTful API architecture, supports HTTP / HTTPS protocols, and provides standardized data query and analysis services. The interface design includes multiple layers of access control. The first layer is identity authentication, verifying the visitor's legal identity and regulatory qualifications. The authentication process uses digital certificates and multi-factor authentication mechanisms. The authentication formula is as follows: The second layer is authorization control, which allocates corresponding data access permissions based on the functional scope of different regulatory departments. Permission levels include: basic statistical permissions, behavioral analysis permissions, trend prediction permissions, and in-depth analysis permissions. Access control adopts a role-based access control (RBAC) model, and the permission matrix defines the data types and operational permissions that different roles can access. The third layer is data anonymization verification, which verifies the integrity of data anonymization again before data return to ensure no leakage of personal privacy information. The verification algorithm uses sensitive information detection technology, and the detection formula is:

[0258] The interface requires 100% data anonymization. It also provides data query restriction mechanisms, including query frequency limits, data volume limits, and time range limits, to prevent data abuse and system overload.

[0259] The query restriction formula is:

[0260] .

[0261] The interface also includes audit logging functionality, recording detailed information for all access operations, including visitor identity, access time, query content, and returned results, providing support for data security monitoring and compliance auditing. Data return formats support multiple formats such as JSON, XML, and CSV to meet the data processing needs of different regulatory departments. The interface also provides data visualization capabilities, displaying statistical analysis results through charts and reports to improve data readability and usability.

[0262] Through the aforementioned privacy-preserving historical reputation data management mechanism, a sustainable utilization system for vehicle-to-everything (V2X) data assets has been established, achieving a balance between personal privacy protection and data value mining. The de-identification process of the reputation hash chain, through a systematic de-identification process, completely severs the association between data and specific vehicles and owners, preserving the statistical value and analytical significance of the data while protecting personal privacy. A dedicated historical reputation database establishes a long-term storage and efficient management mechanism for V2X behavioral data, providing rich data resources for big data analysis and artificial intelligence applications. The macro-trust model training based on machine learning enables a deep understanding and intelligent prediction of the V2X ecosystem, providing a scientific basis for network security protection, reputation system optimization, and policy formulation. A multi-layered regulatory data opening mechanism, while ensuring data security, provides valuable data insights for government regulatory departments, supporting multiple application scenarios such as intelligent traffic management, safety supervision, and policy evaluation. The entire data management process not only complies with data protection regulations but also maximizes the utilization of data assets, providing data support for the healthy development of the V2X industry. By establishing this complete historical data management mechanism, the Internet of Vehicles (IoV) has upgraded from simple data collection to intelligent data governance, providing an important data infrastructure for building a safer, more reliable, and intelligent IoV ecosystem, and promoting data-driven innovation and sustainable development in the field of intelligent transportation.

[0263] This invention also discloses a blockchain-based vehicle-to-everything (V2X) secure communication system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The system is characterized in that the processor executes the computer program to implement the aforementioned blockchain-based V2X secure communication method.

[0264] This invention also discloses a computer-readable storage medium storing instructions, characterized in that, when executed by a processor, the instructions cause the processor to be configured to perform the aforementioned blockchain-based vehicle-to-everything (V2X) secure communication method.

[0265] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0266] The memory can be an internal storage unit of a computer device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) provided on the computer device. Furthermore, the memory can be a combination of internal storage units and external storage devices of a computer device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0267] The present invention also discloses a computer-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the blockchain-based vehicle-to-everything (V2X) secure communication method and system described in any of the above embodiments.

[0268] The computer program can be stored in a machine-readable medium. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or certain middleware. The machine-readable medium includes any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the machine-readable medium includes, but is not limited to, the above-mentioned components.

[0269] The blockchain-based vehicle network security communication method and system method described in the above embodiments are stored in the computer-readable storage medium and loaded and executed on the processor to facilitate the storage and application of the above methods.

[0270] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of protection of this application is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0271] One or more embodiments in this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments in this application should be included within the protection scope of this application.

Claims

1. A blockchain-based secure communication method for vehicle-to-everything (V2X) communication, characterized in that, Includes the following steps: The hardware response value generated by the PUF circuit built into the target vehicle is integrated with the static identifier of the target vehicle to generate a unique vehicle digital gene for the target vehicle. Based on the vehicle digital gene, a finite state machine smart contract containing preset life cycle states is deployed on the blockchain for the target vehicle. The preset life cycle states include the vehicle manufacturing state, the vehicle usage state, and the vehicle transaction state. Based on the vehicle usage state of the finite state machine smart contract, activate the key pair for vehicle-to-everything (V2X) communication for the vehicle's onboard communication unit, and when the target vehicle generates a valid interaction that is verified by consensus, anchor the reputation digest of the valid interaction in the form of a hash chain to the finite state machine smart contract. In response to an ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party, the state of the finite state machine smart contract is switched from the vehicle usage state to the vehicle transaction state, and a permission decay mechanism is initiated to gradually reduce the communication permissions of the key pair held by the original vehicle owner in the vehicle transaction state. After the ownership transfer request is verified through blockchain network consensus, the valid public key recorded in the finite state machine smart contract is updated to the public key of the new vehicle entity in the atomic transaction, and the control of the anchored reputation digest is transferred from the original vehicle entity to the new vehicle entity. Update the state of the finite state machine smart contract from the vehicle transaction state to the vehicle usage state associated with the new vehicle entity.

2. The blockchain-based secure communication method for vehicle networks according to claim 1, characterized in that, The process of fusing the hardware response value generated by the PUF circuit built into the target vehicle with the static identifier of the target vehicle to generate a unique vehicle digital gene, and deploying a finite state machine smart contract containing preset lifecycle states for the target vehicle on the blockchain based on the vehicle digital gene, includes the following steps: Send standard test values ​​pre-set by the authorized entity to the PUF circuitry built into the target vehicle; Obtain the hardware response value generated by the PUF circuit based on the standard test value of its own microscopic physical structure response; A fusion algorithm is used to combine the hardware response value with the static identifier of the target vehicle to generate the vehicle's digital gene. The authorized entity uses the authorized root private key to digitally sign the vehicle's digital gene, forming a blockchain proof. Package the vehicle's digital genes, blockchain proof, and finite state machine smart contract template containing preset lifecycle states into a blockchain transaction; Blockchain transactions are published to a pre-deployed vehicle-to-everything (V2X) consortium blockchain to complete the deployment of finite state machine smart contracts, and the initial lifecycle state of the finite state machine smart contracts is set to the vehicle's factory state.

3. The blockchain-based secure communication method for vehicle networks according to claim 2, characterized in that, When the target vehicle generates a valid interaction that can be verified by consensus, the process of recording the reputation digest of the valid interaction and anchoring it in the form of a hash chain to the finite state machine smart contract includes the following steps: Define in advance in the finite state machine smart contract the behavior types of various effective interaction behaviors and the corresponding reputation weights for different types; After the target vehicle completes a valid interaction in the vehicle-to-everything (V2X) consortium blockchain, the witness nodes in the V2X consortium blockchain collect and verify the multi-source interaction data related to the valid interaction. If the verification is successful, the witness node will combine the multi-source interaction data, event timestamps, and behavior types to generate the original reputation data. The original reputation data is hashed based on the reputation weight to obtain a reputation digest. The reputation digest is linked to the end of the reputation hash chain in the vehicle-to-everything (V2X) consortium blockchain using hash pointers. The updated reputation hash chain head hash value is recorded in a finite state machine smart contract.

4. The blockchain-based secure communication method for vehicle networks according to claim 3, characterized in that, After the target vehicle completes a valid interaction in the vehicle-to-everything (V2X) consortium blockchain, the witness nodes in the V2X consortium blockchain collect and verify the multi-source interaction data related to the valid interaction, which includes the following steps: Receive first interaction data containing a digital signature from the target vehicle that initiated the valid interaction; Receive second interaction data from at least one other network participant within the scope of the effective interaction behavior; The first and second interactive data are integrated into multi-source interactive data to verify the consistency of event elements in the multi-source interactive data. Query the finite state machine smart contract of the target vehicle to confirm that the current lifecycle state of the finite state machine smart contract is the vehicle usage state; Once the consistency verification of event elements is passed and the lifecycle status is confirmed to be correct, the multi-source interactive data verification is deemed to have passed.

5. The blockchain-based vehicle-to-everything (V2X) secure communication method according to claim 3, characterized in that, The process of responding to an ownership transfer request jointly digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party, triggering the transition of the finite state machine smart contract from the vehicle usage state to the vehicle transaction state includes the following steps: An initial ownership transfer request containing a unique identifier for the transaction is generated by an authorized third party; The newly generated public key is added to the initial ownership transfer request by the new vehicle owner of the target vehicle, and digitally signed using the private key of the new vehicle owner; When the original owner of the target vehicle receives an ownership transfer request that already contains the signature of the new owner, the original owner's private key is used to digitally sign it. After the authorized third party verifies that the signatures of both the original vehicle owner and the new vehicle owner are valid, the authorized third party shall add the digital signature of the authorized third party to the ownership transfer request. The ownership transfer request, jointly digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party, is submitted as a transaction to the vehicle network alliance chain, triggering the finite state machine smart contract to switch from the vehicle usage state to the vehicle transaction state.

6. The blockchain-based secure communication method for vehicle networks according to claim 5, characterized in that, The aforementioned startup permission decay mechanism gradually reduces the communication permissions of the key pair held by the original vehicle owner during vehicle transactions, including the following steps: When the finite state machine smart contract enters the vehicle transaction state, a preset block height timer is started; Based on the height difference between the current block height and the timer start height, query the permission decay rule table preset in the finite state machine smart contract. The permission decay rule table defines the highest priority of the vehicle network messages that the original vehicle owner's key pair is allowed to send within different height difference ranges. As the height difference increases, the highest priority of the messages that the original vehicle owner is allowed to send decreases unidirectionally. When the height difference reaches a preset threshold, the sending permission of the key pair held by the original vehicle body will be cleared, and only the receiving permission will be retained.

7. The blockchain-based secure communication method for vehicle networks according to claim 3, characterized in that, The preset lifecycle states of the finite state machine smart contract also include the vehicle scrapping state, and the method further includes the following steps: When a target vehicle reaches the scrapping standard, a qualified scrapping and recycling organization, as an authorized third party, and the owner of the last generation vehicle jointly sign and initiate a scrapping request in the vehicle network alliance chain. Once the scrapping request is verified through consensus in the vehicle network consortium blockchain, the finite state machine smart contract is triggered. The lifecycle state of the target vehicle can be permanently changed to the vehicle scrap state through a finite state machine smart contract in an atomic transaction. Associate the key pair held by the last-generation vehicle owner with the scrapping request event of the target vehicle. The lifecycle state change of the finite state machine smart contract is broadcast to the entire network of the vehicle-to-everything (V2X) consortium blockchain, so that any communication initiated using a key pair related to the vehicle's digital genetic code will be rejected by the V2X consortium blockchain.

8. The blockchain-based secure communication method for vehicle networks according to claim 7, characterized in that, After permanently changing the lifecycle state of the target vehicle to the scrapped state through an atomic transaction using a finite state machine smart contract, the following steps are also included: The complete reputation hash chain anchored in the finite state machine smart contract is anonymized. The anonymization process includes removing the direct association between the reputation hash chain and the vehicle's digital genes and the main body of the vehicle throughout the generations. Retain the anonymized reputation hash chain and archive it to the preset historical reputation database; Statistical analysis and training of the macro-trust model of the entire vehicle network alliance chain are conducted based on historical reputation database. Provide access to the historical reputation database to regulatory authorities, while ensuring that the data cannot be traced back to the original vehicle.

9. A blockchain-based vehicle-to-everything (V2X) secure communication system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the blockchain-based vehicle-to-everything (V2X) secure communication method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the blockchain-based vehicle-to-everything (V2X) secure communication method according to any one of claims 1 to 8.

Images