Internet of vehicles security communication method and system based on block chain

Abstract

The invention provides an Internet of Vehicles secure communication method and system based on a block chain, and the method comprises the steps: generating a unique vehicle digital gene through fusing a hardware response value and a static identifier of a built-in PUF circuit of a vehicle, and deploying a finite-state machine smart contract capable of managing factory, use, transaction and other states for the vehicle on the block chain. And in a vehicle use state, activating the key pair to perform secure communication, and anchoring the consensus-verified interaction behavior to the contract in a reputation abstract form. And when responding to an ownership transfer request jointly signed by the original vehicle owner, the new vehicle owner and the third party, the contract enters a transaction state and starts a permission decay mechanism to gradually reduce the permission of the original vehicle owner. And after the consensus is passed, completely and synchronously transferring the public key in the contract and the anchored reputation abstract control right to the new vehicle owner through one atomization transaction, and finally updating the contract state to the vehicle use state of the new vehicle owner. According to the invention, full-life-cycle safety management and reputation inheritance of the vehicle are realized.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and specifically relates to a blockchain-based vehicle network security communication method and system. Background Art

[0002] As a core pillar of intelligent transportation systems and the development of 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 connected environment, ensuring secure and trustworthy communications is the cornerstone of the entire system. Currently, IoV security systems mostly draw on traditional public key infrastructure (PKI), using centralized certificate authorities to issue digital certificates to vehicles for identity authentication and communication encryption. This model can, to a certain extent, protect against external attacks and ensure the security of communications.

[0003] However, existing security frameworks primarily focus on the momentary security of vehicles during communication interactions, but generally overlook the continuity, trustworthiness, and transferability of a vehicle's digital identity throughout its lifecycle as a long-term asset. From the time a vehicle leaves the factory, through sale, multiple resales, and ultimately scrapping, its ownership changes multiple times. Under traditional centralized management models, a vehicle's digital identity is often separated from its historical interaction data. When vehicle ownership transfers, the historical reputation data accumulated within the connected vehicle network is difficult to securely and reliably transfer to the new owner, resulting in the loss of valuable data assets. Furthermore, the ownership change process often relies on offline procedures and centralized system updates, which is complex and subject to delays, creating security risks for attackers to impersonate or tamper with information during the window of authority transition. Summary of the Invention

[0004] The present invention provides a blockchain-based vehicle network security communication method and system to solve the above technical problems.

[0005] In a first aspect, the present invention provides a blockchain-based vehicle network security communication method, the method comprising the following steps: The hardware response value generated by the target vehicle's built-in PUF circuit is integrated with the target vehicle's static identifier 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 lifecycle states is deployed on the blockchain for the target vehicle. The preset lifecycle states include the vehicle's factory status, vehicle usage status, and vehicle transaction status. Based on the vehicle usage status of the finite state machine smart contract, the key pair for vehicle network communication is activated for the target vehicle's onboard communication unit. When the target vehicle generates a valid interaction behavior verified by consensus, the reputation summary recording the valid interaction behavior is anchored to the finite state machine smart contract in the form of a hash chain; In response to an ownership transfer request 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 triggered to switch from the vehicle use state to the vehicle transaction state, and the permission decay mechanism is activated 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 by the 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 subject in an atomic transaction, and the control of the anchored reputation summary is transferred from the original vehicle subject to the new vehicle subject; 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.

[0006] Optionally, the step of fusing the hardware response value generated by the built-in PUF circuit of 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 a preset lifecycle state for the target vehicle on the blockchain based on the vehicle digital gene includes the following steps: Sending a standard test value pre-set by an authorized entity to the PUF circuit built into the target vehicle; Obtaining a hardware response value generated by the PUF circuit based on a standard test value of its own physical structure response; A fusion algorithm is used to fuse the hardware response value with the static identification of the target vehicle to generate the vehicle digital gene of the target vehicle; The authorized entity uses the authorized root private key to digitally sign the vehicle's digital gene to form a blockchain certificate; Packaging the vehicle’s digital DNA, blockchain proof, and a finite state machine smart contract template containing pre-set lifecycle states into a blockchain transaction; Publish the blockchain transaction to the pre-deployed Internet of Vehicles consortium chain to complete the deployment of the finite state machine smart contract, and set the initial life cycle state of the finite state machine smart contract to the vehicle factory state.

[0007] Optionally, when the target vehicle generates a valid interaction behavior that can be verified by consensus, anchoring the reputation summary recording the valid interaction behavior in the form of a hash chain in the finite state machine smart contract includes the following steps: Predefine multiple different types of valid interactive behaviors and corresponding reputation weights in the finite state machine smart contract; After the target vehicle completes a valid interaction in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies the multi-source interaction data related to the valid interaction behavior; 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; Perform hash operation on the original reputation data based on the reputation weight to obtain the reputation summary; Use hash pointers to link the reputation summary to the end of the reputation hash chain in the Internet of Vehicles Alliance Chain; The chain head hash value of the updated reputation hash chain is recorded in the finite state machine smart contract.

[0008] Optionally, after the target vehicle completes a valid interaction behavior in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies multi-source interaction data related to the valid interaction behavior, including the following steps: receiving first interaction data including a digital signature from a target vehicle that initiates a valid interaction behavior; receiving second interaction data from at least one other network participant within the effective interaction behavior influence range; Integrate the first interaction data and the second interaction data into multi-source interaction data, and verify the consistency of event elements of the multi-source interaction data; Query the finite state machine smart contract of the target vehicle and confirm that the current life cycle state of the finite state machine smart contract is the vehicle use state; After the consistency verification of event elements is passed and the life cycle status is confirmed to be correct, the multi-source interactive data verification is deemed to have passed.

[0009] Optionally, in response to an ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party of the target vehicle, triggering the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state includes the following steps: An authorized third party generates an initial ownership transfer request containing a unique transaction identifier; The new vehicle subject of the target vehicle adds the newly generated local public key to the initial ownership transfer request and digitally signs it with the private key of the new vehicle subject; When the original vehicle subject of the target vehicle receives an ownership transfer request that includes the signature of the new vehicle subject, the original vehicle subject digitally signs the request using the private key of the original vehicle subject; After the authorized third party verifies that the signatures of the original vehicle owner and the new vehicle owner are both valid, the authorized third party adds a digital signature of the authorized third party to the ownership transfer request; The ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner and the authorized third party is submitted to the Internet of Vehicles Alliance Chain as a transaction, triggering the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state.

[0010] Optionally, the activation authority decay mechanism gradually reduces the communication authority of the key pair held by the original vehicle subject in the vehicle transaction state, including the following steps: When the finite state machine smart contract enters the vehicle transaction state, the preset block height timer is started; The permission decay rule table preset in the finite state machine smart contract is queried based on the height difference between the current block height and the timer start height. The permission decay rule table defines the highest priority of the Internet of Vehicles messages allowed to be sent by the key pair held by the original vehicle entity within different height difference intervals. As the height difference increases, the highest priority of the message allowed to be sent by the original vehicle entity decreases in one direction. When the height difference reaches the preset threshold, the sending permission of the key pair held by the original vehicle entity is cleared, and only the receiving permission is retained.

[0011] Optionally, the preset lifecycle state of the finite state machine smart contract further includes a vehicle scrapping state, and the method further includes the following steps: When the target vehicle reaches the scrap standard, a qualified scrap recycling organization will serve as the scrapping authorized third party and jointly sign with the last generation of vehicle owners and initiate a scrapping request on the Internet of Vehicles Alliance Chain; When the scrapping request passes consensus verification in the Internet of Vehicles Alliance Chain, the finite state machine smart contract is triggered; The target vehicle's lifecycle status is permanently changed to a scrapped state in an atomic transaction through a finite state machine smart contract; Associating the key pair held by the last generation vehicle subject with the scrapping request event of the target vehicle; Broadcast the lifecycle state changes of the finite state machine smart contract to the entire network in the Internet of Vehicles Alliance Chain, so that any communication initiated using the key pair related to the vehicle digital gene of the target vehicle will be rejected by the Internet of Vehicles Alliance Chain.

[0012] Optionally, after permanently changing the lifecycle state of the target vehicle to the scrapped state in an atomic transaction through a finite state machine smart contract, the following steps are also included: Desensitize the complete reputation hash chain anchored in the finite state machine smart contract. This includes removing the direct connection between the reputation hash chain and the vehicle's digital gene and the vehicle's previous generations. Keep the desensitized reputation hash chain and archive it in the preset historical reputation database; Conduct statistical analysis and training on the macro trust model of the entire IoV alliance chain based on the historical reputation database; Under the premise of ensuring that the data cannot be traced back to the original vehicle, an access interface to the historical credit database is provided to the regulatory authorities.

[0013] In a second aspect, the present invention provides a blockchain-based Internet of Vehicles security communication system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the above-mentioned blockchain-based Internet of Vehicles security communication method is implemented.

[0014] In a third aspect, the present invention provides a computer-readable storage medium having instructions stored thereon, wherein when the instructions are executed by a processor, the processor is configured to execute the above-mentioned blockchain-based vehicle network secure communication method.

[0015] The beneficial effects of the present invention are: By integrating the hardware response values ​​of a physical unclonable circuit with the vehicle's static identity, this invention creates a digital gene for each vehicle, rooted in the physical layer and resistant to cloning and tampering. This fundamentally eliminates the risk of vehicle identity forgery. A finite state machine smart contract, deployed based on this gene, creatively and precisely maps and links the vehicle's physical lifecycle with its digital identity on the blockchain, enabling dynamic and trusted management of the vehicle's entire lifecycle, from factory delivery to use and transaction. During the vehicle's use phase, a reputation summary anchored to the contract in the form of a hash chain establishes a traceable and undeniable proof of credit for every valid interaction with the vehicle. More importantly, this invention incorporates a rigorous process for ownership transfer scenarios, such as used car transactions, encompassing multi-party signatures, permission decay mechanisms, and atomic transactions. This not only ensures the legitimacy and security of ownership transfers but also, through the smooth transition of permissions and the simultaneous transfer of reputation assets, completely resolves the core pain points of traditional models, such as the disconnect between ownership and historical data and the inherent security window during transactions. This invention builds 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flowchart of a secure communication method for the Internet of Vehicles based on blockchain in one embodiment of the present application.

[0017] Figure 2 This is a schematic diagram of the ownership transfer security mechanism among the original vehicle entity, the new vehicle entity, and the authorized third party in one embodiment of the present application. DETAILED DESCRIPTION

[0018] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the embodiments described are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field are within the scope of protection of this application.

[0019] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims refers to at least one of the connected objects, and the character " / " generally indicates that the objects connected are in an "or" relationship.

[0020] Figure 1 The flowchart of the secure communication method of the Internet of Vehicles based on blockchain in one embodiment is shown in FIG. Figure 1 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. In addition, Figure 1 At least part of the steps in the above process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps. Figure 1 As shown, the blockchain-based vehicle network security communication method disclosed in the present invention specifically includes the following steps: S110. Fusion of a hardware response value generated by a built-in PUF circuit of the target vehicle and a 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 including preset lifecycle states is deployed on the blockchain for the target vehicle. The preset lifecycle states include a vehicle factory state, a vehicle usage state, and a vehicle transaction state. S120. Activate a key pair for IoV communication for the target vehicle's onboard communication unit based on the vehicle usage status of the finite state machine smart contract. When the target vehicle generates a valid interaction behavior verified by consensus, anchor the reputation summary of the valid interaction behavior to the finite state machine smart contract in the form of a hash chain. S130. In response to an ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party of the target vehicle, trigger the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state, and initiate a permission decay mechanism to gradually reduce the communication permission of the key pair held by the original vehicle owner in the vehicle transaction state; S140. After the ownership transfer request passes the blockchain network consensus verification, 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 summary is transferred from the original vehicle entity to the new vehicle entity; 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.

[0021] The process of generating a vehicle's digital DNA first requires activating the target vehicle's built-in physically unclonable function (PUF). This circuit uses the microscopic physical randomness of the silicon chip manufacturing process to create unique hardware signatures. In practice, a preset standard test stimulus signal, typically a 128-bit random challenge value, is sent to the PUF circuit. The PUF circuit responds to this challenge based on physical parameters such as the threshold voltage variations 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 in one vehicle might output a response value of "0x9F8E7D6C5B4A3928," while another vehicle might generate a different response even when receiving the same challenge. The secure hash algorithm SHA-256 is then used to combine this hardware response value with the vehicle's static identifiers (including the vehicle identification number (VIN), manufacturer code, and production date) to generate a 256-bit vehicle digital DNA. The fusion formula is: , where "||" represents a data connection operation. Based on this vehicle's digital DNA, a finite state machine smart contract covering three lifecycle states—factory, in-use, and transaction—is deployed on the blockchain. This contract, written in Solidity, is initialized to the factory state. This way, each vehicle acquires a unique digital identity based on its physical characteristics, fundamentally eliminating the possibility of identity forgery and laying a solid foundation for subsequent secure communications.

[0022] When the finite state machine smart contract is in the vehicle use state, the on-board communication unit starts to execute the key pair activation process. In the specific implementation, first based on the vehicle digital gene as the seed, the elliptic curve digital signature algorithm (ECDSA) is used to generate the public and private key pairs for vehicle network communication. The corresponding public key is obtained through the elliptic curve point multiplication operation. When the target vehicle generates effective interactive behaviors in the vehicle network, such as sending emergency braking warnings, sharing road condition information, etc., these behaviors are first verified by the witness node in the vehicle network alliance chain. The witness node collects interaction data from multiple sources, including the digital signature data of the initiating vehicle, confirmation information of surrounding vehicles, monitoring records of roadside equipment, etc. After verification, the witness node calculates the reputation summary according to the preset behavior type (such as safety warning weight 0.8, road condition sharing weight 0.6), using the formula: These reputation summaries are anchored in a finite state machine smart contract as a hash chain. Each new reputation summary contains a hash pointer to the previous summary, forming an immutable reputation history. This mechanism ensures that every valid interaction with the vehicle is fairly recorded, establishing a trustworthy vehicle reputation system.

[0023] Reference Figure 2 , which shows the authority relationship between the original vehicle owner, the new vehicle owner, and the authorized third party. The triggering of the ownership transfer request requires a digital signature verification mechanism involving all three parties. In actual implementation, when a vehicle ownership transfer is required, a qualified authorized third party first generates an initial transfer request containing a unique transaction identifier. After receiving the request, the new vehicle owner digitally signs the request using a newly generated private key locally. The signature algorithm uses ECDSA. The signing process is as follows: ; k is a random number. Upon receiving the request signed by the new entity, the original vehicle entity also uses its private key to confirm the signature. Finally, after an authorized third party verifies the validity of the first two signatures, it appends its own digital signature to complete the request, signed by all three parties. When this request is submitted to the IoV consortium chain, the smart contract automatically triggers a state transition from vehicle use to vehicle transaction. Simultaneously, a permission decay mechanism is initiated, which gradually reduces the communication privileges of the original vehicle entity based on the block height difference. Specifically, a permission decay rule table is set. When the height difference is between 0 and 100, the original entity can send all priority messages; between 101 and 200, only medium-priority messages; between 201 and 300, only low-priority messages; and after 300 blocks, the sending privileges are completely reset. This gradual permission decay mechanism effectively avoids security window issues during permission transfers.

[0024] The execution of atomic transactions ensures the integrity and consistency of ownership transfer operations. In practice, once the ownership transfer request passes consensus verification on the blockchain network, the finite state machine smart contract begins executing the atomic transaction. This transaction consists of two core operations: public key update and reputation control transfer. During the public key update process, the smart contract first verifies that the public key submitted by the new vehicle entity complies with the elliptic curve standard. The verification equation is: ; Ensure that the public key points on the specified elliptic curve. After 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 transfer of control over reputation is more complex, requiring the transfer of control of the entire reputation hash chain previously anchored in the smart contract from the original vehicle owner to the new one. In practice, the smart contract generates a reputation transfer certificate, which includes the original owner's digital signature authorization, the new owner's receipt confirmation, and the transfer timestamp. The format of the transfer certificate is: [transfer certificate = (original owner's signature, new owner's signature, timestamp, reputation chain header hash)]. The entire process utilizes an atomic transaction mechanism to ensure 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 fully preserved and securely transferred, allowing the new owner to inherit the vehicle's historical credit record, achieving seamless digital asset inheritance.

[0025] The final update of the smart contract state marks the completion of the entire ownership transfer process. In specific implementations, after the atomic transaction in step S140 is successfully executed, the finite state machine smart contract begins executing the final state transition operation. This operation first verifies that all preconditions are met, including: whether the new vehicle entity's public key has been successfully updated, whether control of the reputation summary has been transferred, and whether the original vehicle entity's permissions have been completely cleared. Once verified, the smart contract invokes 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, the smart contract reinitializes the vehicle's communication permissions and assigns full IoV communication permissions to the new vehicle entity's key pair, including the ability to send messages of various priority levels and participate in consensus verification. The smart contract also resets the timer for the permission decay mechanism to prepare for the next possible ownership transfer. After the state update is complete, the smart contract broadcasts a state change event to all nodes in the IoV consortium chain, notifying other participants in the network that the vehicle's ownership has been transferred. The broadcast message contains key information such as the vehicle's digital gene, the new vehicle entity's public key summary, and the state update timestamp. In this way, the entire Internet of Vehicles network can promptly understand changes in vehicle ownership and ensure the security and effectiveness of subsequent communications.

[0026] The blockchain-based secure communication method for the connected vehicle (IoV) enables full lifecycle security management of a vehicle's digital identity. By integrating the hardware characteristics of PUF circuits with the vehicle's digital DNA generated by static identification, the uniqueness and unforgeability of the vehicle's identity are physically ensured, effectively resolving the single point of failure issue inherent in traditional IoV systems, where identity authentication relies on centralized institutions. Lifecycle management based on finite state machine-based smart contracts enables digital tracking of vehicles from factory to scrap, ensuring transparency and traceability of vehicle status. The hash chain anchoring mechanism for reputation summaries establishes a complete credit record of vehicle behavior, providing a trusted foundation for reputation assessment within the IoV ecosystem. The three-party co-signed ownership transfer process, combined with a permission decay mechanism, completely eliminates the security window during vehicle ownership changes and ensures a smooth transition of permissions. The application of atomic transactions ensures the synchronization of public key updates and reputation transfers, avoiding security risks caused by data inconsistencies. This complete IoV security closed loop not only ensures secure vehicle communications but also ensures the preservation and inheritance of vehicle digital assets, providing a solid security foundation for the development of intelligent transportation systems.

[0027] In one embodiment, the method further comprises the steps of: When any receiving node in the IoV receives a message from a claimed vehicle, it extracts the public key attached to the message; The receiving node queries the Internet of Vehicles consortium chain for the finite state machine smart contract associated with the public key; Obtain and verify whether the current lifecycle state of the smart contract is the vehicle usage state, and whether the public key is the currently recorded valid public key; If the verification is successful, the credibility hash chain anchored by the smart contract is further obtained, and the credibility of the message is evaluated based on its historical records; If any verification fails, the message will be deemed invalid or its trust level will be lowered.

[0028] During IoV communication, when a receiving node receives a message from a purported vehicle, it first needs to extract the attached public key information from the message packet. IoV messages utilize a standardized data frame format consisting of three main components: a message header, payload, and security field. The message header contains basic information such as the sender's identifier, message type, and timestamp. The payload carries specific service content, such as road conditions and emergency warnings. The security field contains a digital signature and public key certificate. During public key extraction, the receiving node first parses the message's security field and locates the starting position of the public key data based on a predefined field offset. Public keys used in IoV typically utilize elliptic curve cryptography. These keys are 64 bytes long, consisting of a 32-byte x-coordinate and a 32-byte y-coordinate. The extraction algorithm first verifies the integrity of the security field by calculating a checksum to ensure the data has not been tampered with during transmission. Subsequently, the public key certificate structure is parsed according to the IEEE 1609.2 standard to extract the elliptic curve public key in either compressed or uncompressed format. The extraction process also verifies that the public key conforms to the elliptic curve equation to ensure mathematical validity. This strict public key extraction and verification mechanism ensures the accuracy and reliability of the subsequent verification process, laying the foundation for secure message verification.

[0029] After extracting the public key, the receiving node needs to query the Internet of Vehicles Alliance Chain for the finite state machine smart contract associated with the public key. In specific implementation, the query process adopts an index mechanism based on public key hash. First, the SHA-256 hash value of the public key is calculated as the query index. The formula is: The receiving node sends a query request to the consortium chain through the blockchain RPC interface. The request format is JSON-RPC 2.0 standard, including the method name "getContractByPublicKey" and the parameter public key hash value. After receiving the query request, the consortium chain node performs an index search in its locally maintained public key-contract mapping table. This mapping table is stored in a B+ tree data structure, supporting efficient range queries and exact matches. The time complexity of the search process is O(log n), where n is the total number of registered vehicles. If the query is successful, the consortium chain 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 chain, 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 maintains a local LRU cache of recent query results. The cache size is typically set to 1000 records, and the cache hit rate can reach over 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 uses asynchronous processing to avoid blocking the main thread's message processing. 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 status verification.

[0030] After obtaining the smart contract information, the receiving node needs to verify the current lifecycle status of the contract and the validity of the public key. In the specific implementation, the status verification process includes two parallel verification branches: lifecycle status check and public key validity verification. The lifecycle status check is implemented by calling the "getCurrentState()" function of the smart contract, which returns an enumeration value of the current state, including 0 for factory state, 1 for use state, 2 for transaction state, and 3 for scrapped state. Only when the state value is 1 (use state) is the vehicle allowed to communicate normally in the Internet of Vehicles. The status check also includes time verification of state transitions, which ensures 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 "isValidPublicKey()" function of the contract, 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 for the current record. The verification process uses the elliptic curve point comparison algorithm, and the comparison formula is: .

[0031] 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 parity flag. The verification process also includes a public key version check, incrementing the public key version number 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 retransmitting historical messages by checking the message timestamp and sequence number. This dual verification mechanism ensures that only legitimate, in-use vehicles pass verification, effectively preventing invalid messages from scrapped or traded vehicles.

[0032] Once the lifecycle status and public key verification are passed, the receiving node further obtains the reputation hash chain anchored by the smart contract and evaluates the credibility of the message based on historical records. In specific implementation, the reputation evaluation process first obtains the complete reputation hash chain header information by calling the "getReputationChain()" function of the smart contract, including the chain head hash value, chain length, last update time, etc. Subsequently, the node retrieves the complete reputation chain data from the distributed storage network through the chain head hash value. The reputation chain is stored in a Merkle tree structure, and each node contains a reputation summary, 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 weight. The calculation formula is: ; in is the weight of the i-th behavior, is the difference between the time when the behavior occurs and the current time, is the time attenuation coefficient (usually 0.001), Reputation is the behavior's reputation. Different types of interactive behaviors are weighted differently: emergency safety warnings are weighted 1.0, traffic status sharing is weighted 0.8, route recommendations are weighted 0.6, and general information broadcasts are weighted 0.4. The evaluation process also considers the consistency and frequency of behavior, assessing the sender's stability by calculating the standard deviation of the behavior pattern. For example, if a vehicle's reputation chain indicates it has sent 50 emergency braking warnings in the past 30 days, but actual verification reveals that 80% of these were false alarms, the vehicle's credibility score will be significantly reduced. The evaluation results are categorized into five levels: Excellent (90-100 points), Good (70-89 points), Fair (50-69 points), Poor (30-49 points), and Very Poor (0-29 points). Based on the reputation score, the receiving node assigns a corresponding processing priority and trust level to the message. Messages from vehicles with high reputation receive higher processing priority and a wider forwarding range.

[0033] Based on the aforementioned verification results, the receiving node performs a final validity determination and trust level classification on the message. In practice, this determination process utilizes a multi-level validation decision tree algorithm. First, it checks to see if all basic verification criteria have been met, including public key validity and lifecycle status correctness. If any basic verification criteria fail, the message is immediately marked invalid and discarded, and a violation log is recorded for subsequent security analysis. Messages that pass basic verification are further assigned a trust level based on their reputation assessment results. Trust levels are categorized into four levels: high trust (reputation score ≥ 80), medium trust (reputation score ≤ 60 < 80), low trust (40 ≤ reputation score < 60), and pending (reputation score < 40). Messages of different trust levels trigger different handling strategies: high trust messages are directly accepted and prioritized; medium trust messages are processed normally but with additional verification; low trust messages are forwarded with a restricted scope and delayed; and pending messages are temporarily cached pending further verification. The determination process also includes a dynamic adjustment mechanism that dynamically adjusts 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 ≥90 are marked as highly trusted. Furthermore, the judgment results are fed back into the local reputation assessment model to optimize subsequent credibility calculation algorithms. For messages deemed invalid, the node will also report the security incident to the consortium chain, including information such as the sender's public key, message content summary, and violation type, providing early warning information for network-wide security protection. This comprehensive judgment mechanism effectively filters out invalid and malicious messages, improving the overall security and reliability of Internet of Vehicles communications.

[0034] The blockchain-based message authentication mechanism establishes a multi-layered security system for IoV communications. Public key extraction and verification ensures traceability of message sources, preventing identity forgery and impersonation attacks. A smart contract query mechanism verifies sender identities in real time, ensuring that only legally registered vehicles can participate in network communications. A dual verification mechanism based on lifecycle status and public key validity effectively prevents invalid messages from scrapped vehicles or vehicles undergoing permission transfers. Trustworthiness assessment based on a reputation hash chain provides a refined trust hierarchy for message processing, enabling receivers to intelligently adjust message processing priorities based on the sender's historical behavior. A multi-level decision tree algorithm combined with a dynamic threshold adjustment mechanism effectively identifies and filters malicious messages while adapting to the protection requirements of varying security scenarios. The entire verification process operates within milliseconds, minimizing the impact on IoV real-time communication performance. By establishing this comprehensive message authentication system, IoV achieves a security upgrade from passive reception to active screening, significantly improving the trustworthiness and attack resistance of network communications and providing a solid foundation for the safe operation of intelligent transportation systems.

[0035] In one embodiment, the atomic transaction further includes: Generate an electronic delivery certificate containing the original vehicle owner identity, the new vehicle owner identity, the authorized third party identity, the timestamp and the corresponding block height; Permanently record the hash value of the electronic delivery certificate in the event log of the finite state machine smart contract; Encrypt the complete data of the electronic delivery certificate and store it in a distributed storage system; Record the storage address of the encrypted data in the transaction details of the atomic transaction; Authorize the new vehicle owner and the authorized third party to have the authority to decrypt and access the electronic delivery certificate.

[0036] The generation of an electronic delivery certificate requires collecting and integrating key information from the ownership transfer process to form a complete transaction record. In practice, certificate generation begins by automatically extracting relevant identity information through the smart contract's data collection function, including the digital identity of the original vehicle owner, the digital identity of the new vehicle owner, and the authentication information of the authorized third party. The original vehicle owner's identity information includes its public key hash, registration time, and historical transaction history. The new vehicle owner's identity information includes the newly generated public key, authentication credentials, and registration address. The authorized third-party identity information includes the third-party organization's digital certificate, authorization scope, and validity period. The timestamp uses Unix time format, accurate to the millisecond, to ensure accurate recording of transaction times. The corresponding block height is obtained by querying the latest block number on the current blockchain and is used to associate the transaction with the blockchain state. The electronic delivery certificate uses JSON format to organize data, including fields such as version number, transaction type, participant information, time information, and vehicle information.

[0037] The hash value of the electronic delivery certificate is permanently recorded in the event log of the finite state machine smart contract, which makes the transaction record immutable and traceable. In the specific implementation, the complete electronic delivery certificate is first hashed with SHA-256. The hash calculation formula is: , generating a unique 256-bit hash value as the digital fingerprint of the credential. The smart contract triggers a predefined "OwnershipTransferEvent" event through an emit statement. This event contains multiple index fields and data fields. Index fields include the vehicle's digital gene hash, the original owner's address hash, and the new owner's address hash, facilitating subsequent fast querying 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 to ensure network-wide consistency. The event log also supports efficient query operations. Through Bloom filters and indexing mechanisms, transaction records for specific vehicles or specific time periods can be quickly retrieved. Furthermore, the generation of the event log triggers state updates in 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.

[0038] The complete data of the electronic delivery certificate needs to be encrypted and stored in a distributed storage system to ensure data confidentiality and availability. In specific implementation, the encryption process adopts a hybrid encryption scheme that combines the advantages of symmetric and asymmetric encryption. First, a 256-bit random symmetric key is generated and the electronic delivery certificate is encrypted using the AES-256-GCM algorithm. The AES-GCM mode not only provides encryption functions, but also has a built-in authentication mechanism that can detect whether the data has been tampered with. Subsequently, the symmetric key is encrypted using the RSA-2048 algorithm. The encryption formula is: . In order to achieve multi-party authorized access, a threshold cryptography scheme is adopted to divide the symmetric key into multiple key shards, which are encrypted with the public keys of the new vehicle entity and the authorized third party respectively. Distributed storage uses the IPFS (InterPlanetary File System) network to ensure the uniqueness and integrity of the data through the content addressing mechanism. The encrypted credential data is divided into multiple data blocks, each with a size of 256KB, and stored on different IPFS nodes. The storage process uses erasure coding technology to encode the original data into redundant data blocks, so that the complete data can be restored even if some nodes are offline. The storage parameters are set to (n=10, k=6), which means that the data is divided into 10 blocks, and the original data can be restored from any 6 blocks, providing 67% fault tolerance. Each data block has a unique hash identifier to form a complete storage mapping table. Distributed storage also includes a data synchronization mechanism to regularly check the data integrity of each node to ensure long-term data preservation.

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

[0040] Decryption access rights for new vehicle owners and authorized third parties are granted through a dynamic permission management mechanism based on smart contracts, ensuring that only legitimate parties can access sensitive data. In practice, permission authorization utilizes a role-based access control (RBAC) model, incorporating time limits and conditional constraints. First, a permission structure is defined in the smart contract: struct AccessPermission {address holder; uint256 expiryTime; uint8permissionLevel; bool isActive; bytes32 conditionHash;}. The new vehicle owner is granted full access rights (permissionLevel = 3), allowing them to decrypt, view, and download the complete electronic delivery certificate. Authorized third parties are granted audit rights (permissionLevel = 2), allowing them to decrypt and view the certificate contents, but with a time limit, typically set to 90 days after the transaction is completed. The permission verification process first checks whether the accessor's address is in the authorized list and then verifies that the permission is within the validity period. Decryption permissions are implemented using threshold cryptography and proxy re-encryption techniques. The authorizer generates a proxy re-encryption key, allowing the authorized party to decrypt data without obtaining the original private key. The proxy re-encryption process includes two stages: key conversion and condition verification. The conversion formula is: ,in is the authorized party’s private key, Where 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, accessor, and operation type of each access operation. Permissions also support a revocation mechanism, allowing for emergency revocation of access rights for an address through multi-signatures in exceptional circumstances. This fine-grained permission management mechanism protects the privacy of transaction data while meeting regulatory and audit compliance requirements.

[0041] Through the comprehensive management process for electronic delivery certificates (EDCs), a digital, trusted, and compliant management system for vehicle ownership transfers has been established. The generation and structured storage of EDCs ensures the integrity and standardization of transaction information, providing a unified data format for subsequent querying, verification, and auditing. The permanent recording of the EDC hash value in the blockchain event log ensures transaction non-repudiation and traceability, detecting any attempt to tamper with the transaction record. 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. The recording of storage addresses in blockchain transaction details establishes a reliable link between on-chain lightweight indexes and off-chain detailed data, enabling hierarchical data management and efficient access. A dynamic role-based permission management mechanism ensures that only legitimate parties can access sensitive data. It also supports time limits and conditional constraints for permissions, meeting access requirements in diverse scenarios. The atomic execution of the entire process ensures data consistency and avoids data inconsistencies caused by partial success. Through this complete electronic delivery certificate management system, the transfer of vehicle ownership has been upgraded from traditional paper certificates to digital certificates, which not only improves transaction efficiency and security, but also provides regulatory authorities with transparent and auditable transaction records, and effectively promotes the development of digital management of vehicle assets.

[0042] In one embodiment, the steps 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 a preset lifecycle state for the target vehicle on the blockchain based on the vehicle digital gene include the following: S210, sending a standard test value preset by an authorized entity to a built-in PUF circuit of a target vehicle; S220, obtaining a hardware response value generated by the PUF circuit based on a standard test value of its own physical structure response; S230: Using a fusion algorithm to fuse the hardware response value with the static identification of the target vehicle to generate a vehicle digital gene of the target vehicle; S240. The authorized entity uses the authorized root private key to digitally sign the vehicle digital gene to form a blockchain certificate; S250, packaging the vehicle digital gene, blockchain proof, and a finite state machine smart contract template containing a preset lifecycle state into a blockchain transaction; S260: Publish the blockchain transaction to the pre-deployed Internet of Vehicles consortium chain to complete the deployment of the finite state machine smart contract, and set the initial life cycle state of the finite state machine smart contract to the vehicle factory state.

[0043] Transmitting standard test values ​​to the target vehicle's built-in PUF circuit requires establishing a secure and reliable communication connection and a standardized test protocol. In practice, the authorized entity first establishes a connection to the vehicle's onboard PUF circuit through the vehicle's diagnostic interface (such as the OBD-II port) or a dedicated secure communication module. Standard test values ​​are designed using a cryptographically secure pseudo-random number generation algorithm to ensure the randomness and unpredictability of the test stimulus. Test values ​​are typically 128 bits long and represented in hexadecimal format. The authorized entity maintains a library of standard test values ​​containing 1,000 pre-generated test vectors, and each vehicle is tested using a specific subset of these. Transmission utilizes a segmented transmission mechanism, breaking the 128-bit test value into eight 16-bit data segments, which are then transmitted one by one to the PUF circuit's stimulus input port. Each data segment is transmitted using a checksum-equipped packet format: [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 confirm receipt within a preset time, the authorized entity will automatically retransmit the data segment up to three times. To ensure consistent testing conditions, the transmission process requires the vehicle to be stationary, the ambient temperature to be within the 15-35°C range, and the power supply voltage to 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 responding and calculating. The entire transmission process is controlled within 500 milliseconds, ensuring real-time and efficient testing.

[0044] 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 physical uncloning technology. In practice, the PUF circuit contains thousands of basic response units, each composed of a pair of CMOS transistors. These transistors produce subtle physical differences during the manufacturing process, such as changes in threshold voltage and carrier mobility. After receiving a 128-bit standard test value, the circuit assigns it to the corresponding response unit, and each unit performs a response calculation based on the value of the input bit. The response process uses a competitive delay mechanism, and the specific formula is: .

[0045] The differences in delay paths stem from variations in the physical properties of transistors, typically in the picosecond range. To improve response stability, each response unit repeats the calculation 10 times, using a majority vote to determine the final output.

[0046] The PUF circuit also features a built-in error correction module that uses BCH code to correct the raw response, capable of correcting up to 8-bit errors and ensuring response consistency despite slight variations in environmental conditions. Once the response value is generated, the circuit transmits the 128-bit hardware response value to the vehicle's control unit via an output buffer, using differential signaling to ensure data integrity. Power consumption during the entire response generation process is kept below 50 milliwatts, and the response time is approximately 100 milliseconds, ensuring practicality and reliability. The generated hardware response value is highly unique, with response variability exceeding 99.9% between vehicles, providing a solid physical foundation for vehicle identification.

[0047] The fusion algorithm combines the hardware response value of the PUF circuit with the vehicle's static identification to generate a unique and unforgeable vehicle digital gene. In specific implementations, the vehicle's static identification contains multiple levels of information, mainly including key information such as the 17-digit vehicle identification number (VIN), manufacturer identification code, production date timestamp, and engine serial number. The fusion algorithm uses multiple rounds of hash functions and key derivation technology to ensure the security and uniqueness of the generation process. First, the vehicle's static identification is preprocessed, and the various information is spliced ​​according to the standard format. The format is: "VIN code + manufacturer code + production date + engine number", for example, "1HGBH41JXMN1234567HONDA20231215ENG98765". The static identification is then processed using the PBKDF2 key derivation function, and the formula is: ; The salt value uses the first 32 bits of the hardware response value, the number of iterations is set to 10,000, and the output length is 256 bits. Next, the fusion calculation is performed using the HMAC-SHA256 algorithm. The calculation formula is: .

[0048] To enhance security, the fusion process also includes timestamp verification and environmental factor correction. The timestamp ensures the timeliness of the generation process. Environmental factors include physical parameters such as temperature and voltage, which are used to compensate for the impact of environmental changes on the PUF response. The fusion algorithm also uses elliptic curve mathematical operations for secondary reinforcement, mapping the initially generated digital gene to a point on the secp256r1 elliptic curve. The mapping formula is: .

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

[0050] The process of an authorized entity using an authorized root private key to digitally sign the vehicle's digital gene establishes an authoritative authentication mechanism for the vehicle's identity, ensuring the authenticity and integrity of the digital gene. In specific implementations, the authorized entity is usually a vehicle manufacturer, certification body, or government regulatory agency, which possesses a root private key that has been rigorously audited and certified. The root private key is generated using a high-strength algorithm such as RSA-4096 or ECC-P384, and the length of the private key ensures sufficient security margin. The digital signature process first performs a hash operation on the vehicle's digital gene, using the SHA-384 algorithm to calculate the hash value. The formula is: .

[0051] Then use the ECDSA algorithm to sign the hash value. The signing process includes three core steps: random number generation, elliptic curve multiplication, and modular operation. The specific calculation formula is: first generate a random number k, calculate the point on the elliptic curve , where G is the base point of the elliptic curve; then calculate the first part of the signature ;Finally calculate the second part of the signature , where n is the order of the elliptic curve. The final digital signature is a pair (r, s). To prevent side-channel attacks during the signing process, the authorized entity uses a dedicated hardware security module (HSM) for signing. The HSM provides a tamper-resistant 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 complies with RFC3161. The generated blockchain proof contains complete information, including the digital signature, timestamp, and the authorized entity's 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"]}. This authoritative digital signature mechanism provides legal validity and technical support for the vehicle's digital gene, laying a trusted foundation for subsequent blockchain deployment.

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

[0053] The complete transaction data structure is: data = contract bytecode + construction 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%. The transaction signature uses the sender's private key to ensure the authorization and integrity of the transaction. The packaged transaction also undergoes static analysis verification to check the security of the contract code and the accuracy of gas estimation to ensure smooth transaction execution. The resulting blockchain transaction contains all the information required to deploy the smart contract, paving the way for the vehicle to establish a digital identity on the blockchain.

[0054] The process of publishing a blockchain transaction to the IoV consortium chain and completing smart contract deployment involves multiple steps, including network propagation, consensus verification, and contract execution, ensuring the secure establishment of a vehicle's digital identity within the distributed network. In practice, a transaction is first submitted to any consortium chain node via the JSON-RPC interface. The request format is eth_sendRawTransaction, and the parameters are the RLP-encoded and signed raw transaction data. The receiving node performs preliminary verification of the transaction, including basic checks such as signature validity, nonce correctness, and gas fee adequacy. Transactions that pass verification are added to the node's memory pool, awaiting inclusion in a block. The consortium chain uses the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, which supports consensus in the presence of malicious nodes. The consensus process is divided into three phases: pre-preparation, preparation, and commit. Each phase requires the consent of more than two-thirds of honest nodes to proceed to the next phase. After the transaction is included in the block, the EVM virtual machine on each node begins executing the smart contract deployment operations. The deployment process includes contract code verification, state initialization, and address allocation. The contract address is calculated using a deterministic algorithm using the formula: ; The last 20 bytes of the hash value are used as the contract address. The initial state of the smart contract includes setting the lifecycle state to "Factory State" (enumeration value 0), storing the vehicle's digital gene, recording the creation timestamp, and initializing the permission list. State storage utilizes a Merkle Patricia Tree structure to ensure state integrity and verifiability. Upon deployment, the contract broadcasts a "ContractDeployed" event to the network, containing information such as the contract address, the vehicle's digital gene hash, and the deployment time. All nodes in the consortium chain synchronously update their local state and add the newly deployed contract information to the vehicle registry. To ensure deployment success, a deployment confirmation mechanism is implemented, requiring at least six block confirmations before the deployment is considered complete. Through this rigorous deployment process, each vehicle acquires a unique, immutable digital identity on the blockchain, laying a solid foundation for subsequent secure communication within the connected vehicle network.

[0055] The aforementioned vehicle digital gene generation and smart contract deployment process based on PUF circuits and blockchain technology has established a revolutionary solution for vehicle identity authentication. The transmission of standard test values ​​and the PUF circuit response mechanism physically ensure the uniqueness and unclonability of vehicle identity, leveraging the microscopic randomness inherent in the silicon chip manufacturing process to create a true "digital fingerprint." A fusion algorithm combines physical characteristics with static identifiers through a cryptographically secure computational process to generate a unique and verifiable vehicle digital gene. The digital signature of an authorized entity provides authoritative authentication of vehicle identity, establishing a complete chain of trust from manufacturer to end user. The standardized packaging of blockchain transactions ensures data integrity and compatibility, providing a technical foundation for interoperability between different systems. The successful deployment of smart contracts on a consortium blockchain enables digital management of the vehicle lifecycle, transforming traditional paper records into tamper-proof blockchain records. This entire process not only addresses the security risks of traditional vehicle identity authentication, such as its reliance on centralized institutions and susceptibility to forgery, but also builds a trusted infrastructure based on cryptographic proof for the connected vehicle. Through the deep integration of physical unclonable technology and blockchain distributed consensus, each vehicle has obtained 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.

[0056] In one embodiment, when the target vehicle generates a valid interaction behavior that can be verified by consensus, anchoring the reputation summary recording the valid interaction behavior in the form of a hash chain in a finite state machine smart contract includes the following steps: S310. Predefine multiple different types of valid interactive behaviors and corresponding reputation weights for different types in the finite state machine smart contract; S320: After the target vehicle completes a valid interaction behavior in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies multi-source interaction data related to the valid interaction behavior; S330: If the verification passes, the witness node combines the multi-source interaction data, event timestamps, and behavior types to generate original reputation data; S340, performing a hash operation on the original reputation data based on the reputation weight to obtain a reputation summary; S350, linking the reputation summary to the end of the reputation hash chain in the Internet of Vehicles alliance chain using a hash pointer; S360. Record the chain head hash value of the updated reputation hash chain in the finite state machine smart contract.

[0057] The process of pre-defining interaction behavior types and reputation weights within finite state machine smart contracts establishes a standardized system and quantitative mechanism for IoV reputation assessment. In practice, behavior types are defined using a hierarchical classification structure, primarily categorized into four main categories: safety, collaboration, service, and violation. Safety behaviors, such as emergency braking warnings, accident reporting, and hazardous road condition alerts, are crucial for traffic safety and are therefore assigned higher reputation weights. Collaboration behaviors, such as road condition information sharing, parking space information provision, and traffic flow reporting, embody the spirit of mutual assistance and cooperation between vehicles. Service behaviors include value-added services such as navigation assistance, charging station status sharing, and weather information delivery. Violation behaviors, including negative behaviors such as sending false information, malicious attacks, and frequent ineffective communications, are penalized with negative weights. Each behavior type is assigned a unique identification code using an 8-digit hexadecimal encoding, such as "0x01" for safety warnings, "0x02" for road condition sharing, and "0x03" for parking information. Reputation weights are represented as floating-point numbers ranging from -2.0 to +2.0 with a precision of 0.1. The specific weightings are: emergency braking warning weight 2.0, accident reporting weight 1.8, hazardous road condition warning weight 1.5, traffic flow reporting 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 weighting also takes into account time decay factors and frequency limits to prevent certain behaviors from being excessively exploited to increase reputation scores. The smart contract uses a mapping structure to store these definitions: mapping(byte8=>BehaviorType) behaviorTypes. The BehaviorType structure contains fields such as the behavior name, weight value, description, and validity period.

[0058] The process by which witness nodes collect and verify multi-source interaction data ensures the objectivity and accuracy of reputation assessments, preventing single-point data falsification and malicious manipulation. In practice, witness nodes are special nodes within the IoV consortium chain, equipped with high computing and storage capabilities. They are typically operated by trusted third-party organizations, such as traffic management departments and telecom 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 initiating vehicle itself, containing a detailed description of the interaction, a digital signature, a timestamp, and other information. The second data source comes from other vehicles within the interaction's range, acting as "witnesses" and providing confirmation that the interaction occurred and was effective. The third data source comes from roadside infrastructure, such as traffic cameras and sensor networks, providing objective environmental data. The verification process utilizes a multi-step cross-validation mechanism. First, the validity of the digital signatures of each data source is verified to ensure data source credibility. Next, the timestamps of different data sources are compared, with a tolerance of ±30 seconds. The consistency of the geolocation information is verified using a GPS coordinate comparison algorithm, with a tolerance of 50 meters. Finally, the consistency of the behavior descriptions is verified, using natural language processing techniques to analyze the similarity of the descriptions. The comprehensive scoring formula for the verification algorithm is: ; Only interactions with a comprehensive score of more than 0.8 were considered valid.

[0059] The process of generating raw reputation data by the witness node requires standardized integration and structured organization of verified interaction data from multiple sources to form a unified reputation record. In practice, raw reputation data is generated using JSON format, containing multiple key fields to ensure information integrity and traceability. The data structure includes a vehicle identification field, which records 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 Unix time format with millisecond accuracy to ensure time accuracy. Geographic location information includes GPS coordinates and address description. Witness information records the identities of other vehicles and infrastructure participating in the verification. The verification score records the comprehensive score of the multi-source verification. The event description field provides a detailed description of the interaction, in the format of "description": "An emergency braking situation was detected on a road section in Chaoyang District, Beijing, and a warning message was promptly sent to the vehicle behind." The data integration process also includes deduplication to prevent duplicate recording of the same interaction. Deduplication is performed using a four-tuple based on vehicle identification, behavior type, timestamp, and geographic location. The generated raw reputation data also needs to pass format validation and integrity checks to ensure that all required fields are correctly filled in and the data format complies with the predefined JSON Schema specification.

[0060] The process of hashing raw reputation data based on reputation weights to generate a reputation summary achieves digital summarization and privacy protection of reputation records, 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. Weights are applied using a weighted hashing algorithm, with reputation weights acting as influencing factors in the hashing operation. The weighted processing ranks key fields in the raw reputation data by importance. Behavior types with higher weights have their corresponding data fields occupying more bits in the hash calculation. In practice, the raw reputation data is first serialized into a byte array, with the serialization order arranged by importance: vehicle identification, behavior type, timestamp, geolocation, and witness information. The number of repetitions of each field is then adjusted based on the reputation weight. For behavior types with a weight of 2.0, the corresponding field is repeated twice in the hash input; for behavior types with a weight of 1.0, the corresponding field is repeated once; and for behavior types with a weight of 0.5, the corresponding field is included with a probability of 0.5.

[0061] The hashing algorithm uses the SHA-256 algorithm, with the formula: [Reputation Digest = SHA256(weighted data)]. To enhance security, a random salt value and chain context information are added. The salt value is extracted from the first 32 bytes of the current block hash of the blockchain, and the context information includes the current block height and chain identifier. The final hashing formula is: .

[0062] The generated reputation summary is 256 bits long and expressed in hexadecimal format, which has good randomness and uniqueness while protecting the privacy of the original data.

[0063] The process of using hash pointers to link the reputation summary to the end of the reputation hash chain establishes a time-series chain structure of the vehicle's reputation record, ensuring the integrity and non-tamperability of the reputation history. In specific implementation, the reputation hash chain adopts a chain data structure similar to the blockchain, and each node contains information such as the current reputation summary, forward hash pointer, timestamp, and serial number. The implementation of the hash pointer is based on the one-way and collision resistance of the cryptographic hash function. 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 and obtains the hash value of the head of the chain as the forward pointer of the new node. The creation of the new node uses atomic operations to ensure the integrity of the linking process. The creation formula is: The serial number uses an incrementing mechanism to ensure the uniqueness and timing of each node. To prevent chain forks and concurrency conflicts, a distributed lock mechanism is used to lock the chain head during the link operation, ensuring that only one node can perform the link operation at the same time. The link process also includes integrity verification to verify whether the forward hash of the new node is consistent with the current chain head hash. The verification formula is: .

[0064] After the link is successfully established, 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 copies across multiple nodes in the consortium chain to ensure high data availability. The chain structure also supports efficient query operations, using an indexing mechanism to quickly locate reputation records for a specific time period or vehicle.

[0065] The process of recording the updated chain head hash value of the reputation hash chain in the finite state machine smart contract realizes the reliable association between on-chain records and off-chain data, and establishes an integrity verification mechanism for reputation data. In the specific implementation, the smart contract maintains a special state variable to store the reputation hash chain head information of each vehicle. The data structure is: mapping(bytes32 =>ReputationChainHead) reputationChains, where the ReputationChainHead structure contains key information such as chain head hash, chain length, last update time, and update block height. The recording process is implemented through the state update function of the smart contract. The function accepts parameters such as vehicle digital genes, new chain head hash, timestamp, etc., and performs atomic state update operations. The update operation first verifies the caller's authority to ensure that only authorized witness nodes can perform the update operation. The authority verification adopts a digital signature mechanism, and the verification formula is: .

[0066] The state update process involves multiple verifications. First, the format of the new chain header hash is verified to ensure it is a valid 256-bit hash value. Then, the incremental length of the chain is verified. The new chain length must increase by 1 compared to the current chain length. Next, the rationality of the timestamp is verified to ensure that the update time is within a reasonable range. Finally, the consistency of the block height is verified to ensure that the update operation occurs within the current block or the most recent blocks. The update operation uses the Compare-And-Swap (CAS) mechanism to prevent data inconsistencies caused by concurrent updates. The operation formula is: .

[0067] After a successful update, the smart contract triggers the ReputationUpdated event, broadcasting the reputation update to the network. This event includes information such as the vehicle ID, 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 the network's overall reputation assessment. Gas consumption during the recording process is kept within a reasonable range through optimized storage layout and data compression technology, ensuring cost-effectiveness and practicality.

[0068] The aforementioned hash chain-based vehicle reputation management mechanism establishes a distributed reputation assessment and recording system for the connected vehicle (IoV) environment. The predefined behavior types and reputation weights provide standardized evaluation criteria for different interactions, ensuring fairness and consistency in reputation assessment. A multi-source data collection and verification mechanism effectively prevents data falsification and malicious manipulation, ensuring the authenticity and reliability of reputation records through cross-validation. The standardized generation of raw reputation data provides a unified data format for subsequent processing, facilitating automated processing and analysis. The weighted hashing operation not only protects the privacy of the raw data but also reflects the importance of different behaviors through a weighted mechanism. The hash pointer linking mechanism establishes a complete chronological record of reputation history, ensuring the immutability and traceability of reputation data. The chain header record in the smart contract reliably links on-chain indexes with off-chain data, providing an efficient access path for reputation querying and verification. The entire reputation management system not only incentivizes vehicles to actively engage in beneficial interactions but also effectively penalizes malicious behavior, fostering a healthy network ecosystem. By establishing this complete reputation assessment and management mechanism, the Internet of Vehicles has achieved an upgrade from simple information exchange to trust-based intelligent collaboration, laying a solid foundation for building a safer, more reliable and efficient intelligent transportation system, and promoting the development of Internet of Vehicles technology in a more mature and practical direction.

[0069] In one embodiment, after the target vehicle completes a valid interaction behavior in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies multi-source interaction data related to the valid interaction behavior, including the following steps: S410, receiving first interaction data including a digital signature from a target vehicle that initiates a valid interaction behavior; S420: Receive second interaction data from at least one other network participant within the influence range of the effective interaction behavior; S430: Integrate the first interaction data and the second interaction data into multi-source interaction data, and verify the consistency of event elements in the multi-source interaction data; S440: Query the finite state machine smart contract of the target vehicle and confirm that the current life cycle state of the finite state machine smart contract is the vehicle use state; 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 be passed.

[0070] Receiving the first interactive data containing a digital signature from the target vehicle that initiates a valid interactive behavior requires establishing a secure and reliable vehicle-to-witness node communication mechanism to ensure the integrity and authenticity of data transmission. In specific implementations, the witness node receives interactive data from the target vehicle through a dedicated V2I (Vehicle-to-Infrastructure) communication interface. The communication adopts DSRC (Dedicated Short Range Communication) or 5G-V2X standards to support reliable data transmission in high-speed mobile environments. The first interactive data is encapsulated in a standardized JSON format and contains multiple key fields: vehicle digital gene hash, interactive behavior type, event description, geographic location coordinates, timestamp, digital signature, etc. The digital signature is generated using the ECDSA algorithm, and the entire data packet is signed based on the vehicle's private key. The signing process first calculates the SHA-256 hash value of the data packet, and then uses the elliptic curve digital signature algorithm to generate a signature pair (r, s). The witness node immediately performs digital signature verification after receiving the data. The verification process recovers the public key through elliptic curve point operation. The verification formula is: ; If the x-coordinate of the verification point is equal to the r-value in the signature, the signature is valid. The reception process also includes a data integrity check, detecting transmission errors through a CRC checksum, and timestamp verification to ensure data timeliness, accepting only data with a timestamp within ±60 seconds of the current time. This rigorous reception and verification mechanism ensures the authenticity and integrity of the first interactive data.

[0071] Receiving secondary interaction data from other network participants within the effective interaction's impact radius requires establishing a dynamic, multi-source data collection network to verify and confirm interaction events from multiple perspectives. In specific implementations, the witness node first determines the impact radius based on the geographic location and behavior type in the primary interaction data. Different types of interactions have different impact radii: emergency braking warnings have an impact radius of 500 meters, general road condition information has an impact radius of 200 meters, and parking information has an impact radius of 100 meters. This impact radius is calculated using a geographic information system (GIS) buffer analysis algorithm, establishing a circular or elliptical impact zone based on the initiating vehicle's GPS coordinates. The witness node then uses the IoV consortium chain's node discovery mechanism to query all network participants within the impact radius, including other vehicles, roadside units (RSUs), and traffic monitoring equipment. The query process utilizes location-based services (LBS) technology, using spatial indexing structures such as quadtrees or R-trees to quickly locate participants within the impact radius. Data collection utilizes a combination of active pull and passive reception, with the witness node sending data request messages to participants within the impact radius. Upon receiving the request, other network participants check whether they have observed the relevant event at the specified time and location. If confirmed, they return the secondary interaction data. A timeout mechanism is set in the data collection process. Participants who do not receive a response within 10 seconds are considered unresponsive. At the same time, a minimum response number threshold is set, and at least 3 independent witnesses are required to confirm before subsequent verification can be carried out.

[0072] The process of integrating the first interaction data and the second interaction data into multi-source interaction data and verifying the consistency of event elements requires the use of advanced data fusion algorithms and multi-dimensional verification mechanisms to ensure the coordination and unification of data from different sources. In the specific implementation, data integration first standardizes the format of all collected data and converts data in different formats into a unified data structure. The integrated multi-source interaction data contains fields such as main event information, witness list, and consistency analysis results. Event element consistency verification includes four dimensions: time consistency, spatial consistency, behavioral consistency, and description consistency. Time consistency verification calculates the standard deviation of time differences by comparing the timestamps of each data source. The formula is: ; in is the timestamp standard deviation, and The scores are the maximum and minimum timestamps respectively. The closer the score is to 1, the better the temporal consistency. The spatial consistency verification calculates the distance difference between each observation location and the event location, using the great circle distance formula: ; Where R is the radius of the Earth. The spatial consistency score is calculated by weighted average of the inverse of the distance: .

[0073] Behavior consistency verification compares the behavior types described by different data sources, uses a semantic similarity algorithm to convert the behavior description into a vector representation, and calculates the cosine similarity: .

[0074] Description consistency verification uses natural language processing technology to extract keywords and entities in event descriptions and calculate the overlap and similarity between descriptions. The comprehensive consistency score is calculated by weighted average: ; Only multi-source data with a comprehensive consistency score exceeding 0.75 were considered to have passed the consistency verification.

[0075] The process of querying the finite state machine smart contract of the target vehicle and confirming its current life cycle status requires the establishment of a reliable blockchain query mechanism to ensure the accuracy and real-time nature of the vehicle status information. In the specific implementation, the witness node queries the smart contract corresponding to the target vehicle through the RPC interface of the Internet of Vehicles alliance chain. The query process first constructs a contract query request based on the vehicle's digital gene hash value. The getCurrentState() function of the smart contract returns the current life cycle status enumeration value. The status code is: 0 for factory status, 1 for usage status, 2 for transaction status, and 3 for scrapped status. The query process adopts a multi-node parallel query mechanism, and sends query requests to at least 3 different alliance chain nodes at the same time. The accuracy of the query result is determined by majority voting. The voting formula is: , where the mode() function returns the state value that appears most frequently. To prevent query results from being tampered with, a Merkle proof verification mechanism is also used, and each query result is accompanied by a corresponding Merkle path proof.

[0076] The query process also includes a caching mechanism. Witness nodes maintain a local state cache with a validity period of 60 seconds. Queries for the same vehicle within the cache validity period directly return cached results, improving query efficiency. The state confirmation process not only checks whether the current state is "in use" but also verifies the legitimacy of state transitions. By querying the state transition history of the smart contract, it ensures that the vehicle transitions from factory state to in-use state normally, without any abnormal state jumps. Furthermore, the vehicle's permission status is checked 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 fail to return a result or return an error status within the timeout will be marked as having an abnormal state, and any interactions initiated by them will not be recognized.

[0077] After the consistency verification of event elements is passed and the life cycle status is confirmed to be correct, the final multi-source interactive data verification judgment is carried out. It is necessary to comprehensively consider all verification results and formulate scientific judgment criteria. In the specific implementation, the final verification judgment adopts a multi-level decision tree algorithm, combining the ideas of fuzzy logic and expert system to establish a comprehensive evaluation model. The judgment process first checks whether all preconditions are met, including: event element consistency score ≥ 0.75, vehicle life cycle status is in use, number of witnesses ≥ 3, data integrity check passed, etc. After the preconditions are met, the comprehensive credibility evaluation stage is entered, and the credibility calculation formula is: ; Among them, α=0.4, β=0.3, γ=0.2, and δ=0.1 are weight coefficients. The witness weight is calculated based on the witness's historical reputation and certification level. The certification levels include 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: ; Where λ = 0.1 is the decay 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 decision is made using a threshold decision mechanism: a credibility ≥ 0.8 is considered passed, 0.6 ≤ credibility < 0.8 is considered pending further verification, and credibility < 0.6 is considered failed. The verification results include a detailed evaluation report documenting the scores for each dimension, the basis for the determination, and witness information, providing a basis for subsequent reputation evaluation and dispute resolution. Interaction data that passes verification is marked as "verified" and enters the reputation summary generation process; data that fails verification is marked as "invalid" and recorded in the abnormal behavior log. The entire decision process is executed within 2 seconds to ensure real-time performance.

[0078] Through the collection, integration, and verification mechanism of multi-source interaction data, a distributed event verification system has been established in the IoV environment, effectively improving the credibility and accuracy of interaction records. First, digital signature verification of 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, provides multiple safeguards for event verification, significantly reducing the risk of single-point fraud. The data integration and consistency verification process utilizes a multi-dimensional verification algorithm to cross-verify the authenticity of events from multiple perspectives, including time, space, behavior, and description, ensuring the objectivity and accuracy of the verification results. The smart contract status query mechanism verifies the legitimacy and permission status of vehicles in real time, preventing invalid data interference from vehicles in abnormal conditions. The comprehensive judgment algorithm, combining multiple evaluation factors and a weighting mechanism, achieves a scientific and quantitative assessment of interaction events, enhancing the reliability and fairness of the judgment results. The entire verification process not only ensures 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 IoV reputation system. By establishing this complete multi-source verification mechanism, the Internet of Vehicles 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 Internet of Vehicles in a safer, more trustworthy and intelligent direction.

[0079] In one embodiment, in response to an ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner, and an authorized third party of the target vehicle, triggering the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state includes the following steps: S510. An authorized third party generates an initial ownership transfer request including a unique transaction identifier. S520: The new vehicle subject of the target vehicle adds the locally generated public key to the initial ownership transfer request and digitally signs it using the private key of the new vehicle subject. S530. When the original vehicle owner of the target vehicle receives the ownership transfer request that includes the signature of the new vehicle owner, the original vehicle owner digitally signs the request using the private key of the original vehicle owner. S540. After verifying that the signatures of the original vehicle owner and the new vehicle owner are both valid, the authorized third party adds a digital signature of the authorized third party to the ownership transfer request. S550: Submit the ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner, and the authorized third party as a transaction to the Internet of Vehicles Alliance Chain, triggering the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state.

[0080] Authorizing a third party to generate an initial ownership transfer request containing a transaction unique identifier requires establishing a standardized transaction request format and a uniqueness assurance mechanism to ensure that each transfer request has global uniqueness and complete transaction information. In specific implementations, the authorized third party is usually a government vehicle management department, a certified used car trading platform, or a financial institution with corresponding qualifications. These institutions have legal authorization to transfer vehicle ownership. The transaction unique 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 digit 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: . The initial transfer request is constructed in JSON format and contains multiple key fields: transaction unique identifier, vehicle digital gene hash, reserved field for original owner identification, reserved field for new owner identification, authorized third-party information, transaction initiation time, validity period, etc. The generation process also includes data integrity protection, which generates 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 uses its own private key to pre-sign the request. The pre-signature uses the ECDSA algorithm, and the signature object is the hash value of the request. The purpose of the pre-signature is to prove the authority of the request and prevent forgery. The generated initial request also contains auxiliary information such as transaction type identification, handling fee information, and legal terms reference to provide complete context information for subsequent transaction processing.

[0081] The process of the new vehicle owner adding the newly generated local public key to the initial transfer request and digitally signing it requires ensuring key security and signature validity to establish cryptographic proof of the new vehicle owner's identity. In practice, the new vehicle owner first receives the initial transfer request sent by an authorized third party and ensures the confidentiality of data transmission through a secure channel (such as a TLS encrypted connection). The new vehicle 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 point multiplication: , 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, consisting of 64 bytes of coordinate data (32 bytes for x coordinates + 32 bytes for y coordinates). The prefix "04" indicates uncompressed format. The new owner adds the public key information to the "newOwnerField" field of the initial transfer request. This information includes the public key data, the timestamp of the public key generation, and the new owner's identity hash.

[0082] The digital signature process signs the updated complete request. First, the SHA-256 hash value of the request is calculated, and then the ECDSA algorithm is used to generate the signature. The signature calculation formula is: ; Where k is a random number, H is the 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 owner immediately verifies the signature to ensure its correctness. Once verification is successful, the signed request is sent to the original owner.

[0083] The process of digitally signing and confirming the ownership transfer request received by the original vehicle owner, which includes the signature of the new vehicle owner, requires verifying the validity of the new owner's signature and expressing the willingness to transfer, thus forming a legally valid transfer authorization. In specific implementation, the original vehicle owner receives the transfer request including the signature of the new owner through a secure communication channel, and first verifies the signature of the new owner. The signature verification process uses the elliptic curve digital signature verification algorithm, and verifies the validity of the signature through public key recovery and point operations. The verification formula is: ; If the x-coordinate of the verification point equals the r value in the signature, the signature is valid. After verification, the original owner checks the vehicle information in the request to see if it matches their vehicle, comparing key data such as the vehicle's digital genetic hash and vehicle identification information. After confirming the information is 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 the complete request including the new owner's signature, ensuring the timing and integrity of the signature. The original owner's signature calculation process involves first extracting their private key registered in the vehicle smart contract, calculating the hash value of the request including the new owner's signature, and then performing the signing operation to generate the signature pair (r, s). After the signature is generated, the original owner adds their signature to the "originalOwnerSignature" field of the request. To ensure non-repudiation of the signature, the original owner is required to provide additional identification information, including an authentication code and biometric hash. This information, together with the signature, forms a complete proof of transfer authorization. After signing, the original owner sends the signed request back to the authorized third party for final confirmation and processing. The entire process also includes the recording and verification of signature timestamps to ensure the timeliness and legal effect of the signature.

[0084] Authorizing a third party to verify the validity of the signatures of both the original and new vehicle owners and append its own digital signature requires the establishment of a comprehensive multi-party signature verification mechanism and authoritative authentication process to ensure the legitimacy and integrity of the ownership transfer. In practice, upon receiving a transfer request containing signatures from both parties, the authorized third party first performs a systematic signature verification operation. This verification process utilizes a parallel verification mechanism, independently verifying the signatures of both the original and new owners to improve verification efficiency. To verify 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 contains the initial request with the public key information appended. To verify the original owner's signature, the vehicle's smart contract is used to query the original owner's current valid public key and then verify the validity of the signature. The verification message contains the complete request including the new owner's signature.

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

[0086] The final signature is added to the "authorizedSignature" field of the request and contains information such as the signature data, signing timestamp, and hash of the authority's certificate.

[0087] Submitting a three-party digitally signed ownership transfer request as a blockchain transaction to the IoV consortium chain and triggering a smart contract state transition requires the establishment of a reliable blockchain transaction mechanism and automated state management processes. In practice, an authorized third party encapsulates the complete three-party signature request into a standard blockchain transaction. The transaction uses an Ethereum-compatible format and includes standard fields such as the transaction hash, sender address, receiver address (smart contract address), transaction data, and gas fee. The transaction data field contains the smart contract function call information for the "requestOwnershipTransfer" function within the smart contract. The function parameters include the complete transfer request data and the three-party signature information. The transaction data uses the ABI encoding format, and the encoded data length is typically between 2 and 5KB. Transaction submission uses a digital signature to ensure transaction authorization. The authorized third party signs the transaction using its own private key, following the Ethereum transaction signature standard. The submission process sends the transaction to the consortium chain node via the JSON-RPC interface. Upon receiving the transaction, the consortium chain node first performs basic verification, including transaction format correctness, signature validity, and gas fee adequacy. Transactions that pass verification are added to the memory pool, awaiting inclusion in a block. When the smart contract's "requestOwnershipTransfer" function executes, it first verifies that the caller is an authorized third-party organization and then verifies the validity and integrity of the three-party signatures. This verification process includes multiple steps, including signature formatting, public key matching, and message integrity verification. Once all verifications pass, the smart contract triggers a state transition, updating the vehicle's lifecycle state from "Used State" (value 1) to "Transaction State" (value 2). This state transition is performed atomically to ensure consistency. The transition also records the state change timestamp and the hash of the triggering transaction. After the state transition is complete, the smart contract emits an "OwnershipTransferInitiated" event, broadcasting the state change to the entire network. This event includes key information such as the vehicle ID, the original owner's address, the new owner's address, and the transfer request hash. Simultaneously, a permission decay mechanism is initiated, gradually reducing the original owner's communication privileges to facilitate a smooth transition.

[0088] The aforementioned vehicle ownership transfer process based on three-party digital signatures establishes a secure, trustworthy, and compliant digital vehicle asset transfer mechanism. A unique identifier generated by an 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 and digital signature mechanism of the new owner's public key ensures 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 clear transfer authorization, ensuring the legitimacy and non-repudiation of the transfer process through cryptographic proof. Authoritative signature verification and additional signatures by an authorized third party provide official recognition and legal assurance for the transfer request, ensuring compliance with regulatory requirements. The parallel verification and timing control of the three-party signature mechanism effectively prevent security threats such as signature forgery and replay attacks, ensuring the security of the transfer process. Standardized blockchain transaction submission and automated state management of smart contracts digitize and automate the transfer process, significantly improving processing efficiency and reducing the risk of errors caused by manual intervention. The simultaneous activation of the permission decay mechanism ensures a smooth transition during the ownership transfer process, avoiding security windows during permission handover. The entire process not only ensures the security and legality of the transfer of vehicle digital assets, but also provides a digital upgrade solution for the traditional paper transfer process, promoting the development of vehicle asset management towards intelligence and automation.

[0089] In one embodiment, the activation authority decay mechanism gradually reduces the communication authority of the key pair held by the original vehicle subject in the vehicle transaction state, including the following steps: S610: When the finite state machine smart contract enters the vehicle transaction state, a preset block height timer is started; S620: Querying a permission decay rule table preset in the finite state machine smart contract based on the height difference between the current block height and the timer start height. The permission decay rule table defines the highest priority of the Internet of Vehicles messages that the key pair held by the original vehicle entity is allowed to send within different height difference intervals. As the height difference increases, the highest priority of the message allowed to be sent by the original vehicle entity decreases unidirectionally. S630: When the height difference reaches a preset threshold, the sending permission of the key pair held by the original vehicle entity is cleared, and only the receiving permission is retained.

[0090] Starting a preset block height timer when a finite state machine smart contract enters the vehicle transaction state requires the establishment of a precise time measurement mechanism and an automated timer management system to ensure the accuracy and reliability of the permission decay process. In practice, the block height timer is based on the blockchain network's time measurement system, leveraging the sequential nature of block generation within the blockchain network to achieve precise time measurement. When the smart contract transitions from "use state" to "transaction state," the state transition function within the contract automatically triggers the timer start operation. The timer start process first obtains the latest block height of the current blockchain network by calling the blockchain node's "block.number" global variable to obtain the current block number. For example, the current block height is 15678932. The start timestamp is recorded using a dual mechanism, recording both the block height and the Unix timestamp. The timer data structure is stored in the smart contract's state variable and is defined as: structDecayTimer {uint256 startBlockHeight; uint256 startTimestamp; bool isActive; uint256 lastUpdateHeight;}. Immediately after the timer starts, initialization is performed, setting the timer state to active, recording the exact start time, and initializing related auxiliary variables. To ensure the reliability of the timer, a redundant backup mechanism is established, allowing the timer's status to be queried in multiple smart contract functions. The startup process also includes event logging. The "DecayTimerStarted" event is emitted via an emit statement, broadcasting the timer start information to the entire network. The event parameters include key information such as the vehicle ID, the start block height, and the start timestamp. Gas consumption during timer startup has been optimized to be low, ensuring both cost-effectiveness and practicality.

[0091] Querying the permission decay rule table and dynamically adjusting communication permissions based on the difference between the current block height and the timer's starting height requires a scientific permission hierarchy and intelligent permission management mechanism to achieve smooth permission transitions and precise control. In practice, the permission decay rule table employs a piecewise function design principle, dividing the entire decay process into multiple stages, each corresponding to a different permission level and message priority limit. The rule table is predefined in the smart contract and stored as a mapping structure, where the key is the block height difference interval and the value is the corresponding permission level. Permission levels are divided into five levels: full permission (level 5), advanced permission (level 4), intermediate permission (level 3), basic permission (level 2), restricted permission (level 1), and no sending permission (level 0). Specifically, the intervals are: 0-100 blocks correspond to level 5, 101-300 blocks correspond to level 4, 301-600 blocks correspond to level 3, 601-1000 blocks correspond to level 2, 1001-1500 blocks correspond to level 1, and over 1500 blocks correspond 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 corresponding relationship between permissions and message priorities is: permission level N can only send messages with priority ≤ N. The height difference calculation formula is: The query process uses a binary search algorithm to improve efficiency, with a time complexity of O(log n). The permission adjustment process not only modifies the 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 relevant permissions. Each permission adjustment will generate a detailed log record, including information such as the adjustment time, permission changes, and trigger conditions, providing a basis for auditing and troubleshooting.

[0092] When the height difference reaches a preset threshold, the sending permissions of the original vehicle's key pair are cleared, leaving only receiving permissions. This requires a strict permission control mechanism and a comprehensive permission status management system to ensure the security and integrity of the permission transfer process. In practice, the preset threshold is typically set at 1500 blocks, corresponding to approximately 6-8 hours (assuming an average block time of 15 seconds). This window of time allows for normal transaction processing while effectively preventing abuse of permissions. The threshold check utilizes an automated monitoring mechanism. The smart contract checks whether any vehicle's permission decay process has reached the final stage at each block height update. This check is performed by comparing the current height difference with a preset threshold, using the following criteria: [height difference minus preset threshold]. When this condition is met, the smart contract automatically executes the irreversible permission clearing operation, ensuring the finality of the permission transfer. The permission resetting process involves multiple steps: first, the original owner's sending permission is marked as "disabled" and the permission level is set to 0; then, the network's access control list is updated to remove the sending permission entry for the original owner's key pair; then, all nodes in the IoV network are notified and the permission change is broadcast; finally, the timestamp and block height of the permission resetting are recorded, forming an immutable record of the permission change. Receiving permissions are retained with fine-grained control. The original owner can still receive messages from other vehicles, but cannot actively initiate communications or broadcast messages. Receiving permissions are typically retained for an additional 1000 blocks to provide a buffer period for the original owner to receive important notifications. The permission resetting operation triggers a "PermissionRevoked" event, whose parameters include the vehicle ID, the original owner's address, the permission resetting time, and the retained receiving permission information. The entire process also includes an exception handling mechanism. If an exception occurs during the permission resetting process, the smart contract will roll back to a safe state and log an error message. The permission resetting process also updates the vehicle's reputation assessment parameters to ensure the consistency and accuracy of the reputation system.

[0093] The block-height-based permission decay mechanism establishes a smooth permission transition system during vehicle ownership transfers, effectively addressing the security window issue inherent in traditional permission management. The block-height timer provides a precise time base for permission decay, leveraging the blockchain's immutable nature to ensure accuracy and reliability, while mitigating the security risks associated with malicious modification of traditional timestamps. The segmented permission decay rule table design enables a gradual demotion of permissions, ensuring the original owner's basic communication needs during the transaction while gradually limiting their permissions to prevent malicious use and abuse. A five-level permission hierarchy, coupled with a five-level message priority mechanism, provides granular permission control for communication activities of varying importance, ensuring the proper delivery 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 status through atomic transactions. The final permission reset operation establishes a clear demarcation point for ownership transfer, ensuring a clear separation of permissions between the new and old owners and preventing permission conflicts and confusion. The temporary retention of receiving permissions reflects user-friendly design considerations, providing the original vehicle owner with a buffer period to receive important notifications and avoiding the inconvenience caused by sudden network disconnection. The transparency and traceability of the entire permission decay process provide reliable data support for dispute resolution and compliance audits. By establishing this comprehensive permission decay mechanism, the Internet of Vehicles has achieved an upgrade from extensive permission management to refined and intelligent permission control, providing technical support for the secure transfer of vehicle digital assets.

[0094] In one embodiment, the preset lifecycle state of the finite state machine smart contract also includes a vehicle scrapping state, and the method further includes the following steps: S710: When the target vehicle reaches the scrap standard, a qualified scrap recycling organization, as the scrapping authorized third party, jointly signs with the last generation vehicle owner and initiates a scrapping request on the Internet of Vehicles Alliance Chain; S720: When the scrapping request passes consensus verification in the Internet of Vehicles alliance chain, the finite state machine smart contract is triggered; S730. Permanently change the lifecycle state of the target vehicle to a scrapped state in an atomic transaction through a finite state machine smart contract. S740: Associating the key pair held by the last generation vehicle subject with the scrapping request event of the target vehicle; S750. Broadcast the lifecycle state changes of the finite state machine smart contract to the entire vehicle network alliance chain, so that any communication initiated using the key pair related to the vehicle digital gene of the target vehicle will be rejected by the vehicle network alliance chain.

[0095] When a target vehicle reaches end-of-life standards, a qualified scrapping and recycling organization and the last generation vehicle owner jointly sign a scrapping request. This requires a strict qualification certification system and standardized scrapping process control mechanisms to ensure the legitimacy and authority of the scrapping operation. In practice, the determination of vehicle scrapping standards is based on a comprehensive assessment of multiple dimensions, including vehicle age (generally 15 years), mileage (typically 600,000 kilometers), safety test results, and compliance with emission standards. Scrapping and recycling organizations 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 license issued by the industrial and commercial authorities. Qualification verification is performed through a pre-defined whitelist of authorized organizations within the smart contract. The whitelist contains the digital certificate hash and public key information of certified organizations. The scrapping request is generated using a mutually signed mechanism. The scrapping and recycling organization first creates an initial scrapping request, which includes key information such as the vehicle's digital gene hash, the reason for scrapping, information about the recycling organization, and an estimated scrapping date. After receiving the scrapping request, the last generation of vehicle owners uses their own private key to perform digital signature confirmation. The signature process uses the ECDSA algorithm, and the calculation formula is: After verifying the validity of the owner's signature, the scrapping and recycling agency uses its authoritative private key to perform a second signature, creating a dual-signed scrapping request. The entire signing process also includes timestamp verification and geolocation confirmation to ensure the authenticity and timeliness of the scrapping request.

[0096] In order for the scrapping request to pass consensus verification and trigger the finite state machine smart contract in the Internet of Vehicles alliance chain, it is necessary to establish a multi-level verification mechanism and an automated contract triggering process to ensure the reliability and irreversibility of the scrapping operation. In the specific implementation, the scrapping request is submitted to the alliance chain network as a special type of blockchain transaction. The transaction data contains complete scrapping request information and digital signatures of both parties. The consensus verification process adopts an improved PBFT (Practical Byzantine Fault Tolerance) algorithm to support consensus in the presence of malicious nodes. The verification process is divided into three stages: the pre-preparation stage verifies the transaction format and signature validity, the preparation stage confirms the satisfaction of the scrapping conditions, and the submission stage executes the final consensus decision. The verification node needs to check multiple key conditions: the validity of the qualifications of the scrapping recycling agency, the legitimacy of the identity of the vehicle subject, the correctness of the current status of the vehicle, the sufficiency of the scrapping reason, etc. Qualification verification is achieved by querying the institution whitelist on the chain. The verification formula is: .

[0097] 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 (not scrapped and not abnormal). The consensus process requires more than 2 / 3 of the honest nodes to agree to pass the verification. The consensus formula is: .

[0098] After verification, the consortium chain automatically triggers the finite state machine smart contract corresponding to the target vehicle, calling the "processScrapRequest" function within the contract. This triggering process utilizes an event-driven mechanism, with consensus completion events automatically activating the smart contract's state transition logic. The triggering information includes key data such as the scrapping request hash value, consensus result, and verification timestamp, ensuring the accuracy and traceability of contract execution. The entire verification and triggering process is executed within 30 seconds, ensuring the timeliness and efficiency of scrapping operations.

[0099] Permanently changing the target vehicle's lifecycle state to a scrapped state in an atomic transaction using a finite state machine smart contract requires the establishment of a strict state transition control mechanism and an irreversible state locking system to ensure the permanence and uniqueness of the scrapped state. In practice, the smart contract's "processScrapRequest" function executes complex state transition logic, first verifying whether the current vehicle state allows the scrapping operation. Only vehicles in the "in-use state" or "transaction state" can be transitioned to the "scrapped state." State transition verification uses the state machine's finite state transition diagram to ensure the legitimacy of the state change. The verification formula is: .

[0100] Atomic transactions are implemented through the smart contract's transaction control mechanism, using require statements and a revert mechanism to ensure that all operations either succeed or 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 certificate. State value updates are irreversible. Once set to "retired state" (enumeration value 3), that state can never be changed to another state. The state locking mechanism is implemented by setting a special lock flag. The locking formula is: .

[0101] State changes also include historical records, logging the complete state transition information to the contract's history log. The record format is: {"fromState":"Used State","toState":"Scrapped State","changeTime":1640995200123,"requestHash":"0x4d5e6f7a...","blockHeight":15678933}. The execution of atomic transactions also triggers related cleanup operations, including finalizing the reputation hash chain, clearing the permission table, and dissolving associations. The entire state change process generates an immutable blockchain record, providing reliable data support for the complete lifecycle management of the vehicle. Upon completion of the change, the smart contract emits a "VehicleScrapStatusSet" event to notify the entire network of the completion of the state change.

[0102] Associating the key pair held by the last generation of vehicle entities with the scrapping request event of the target vehicle requires the establishment of a complete key lifecycle management mechanism and event association traceability system to ensure the permanent binding and traceability of the key pair and the vehicle scrapping event. In the specific implementation, the key pair association process is implemented through a dedicated association function in the smart contract, which accepts parameters such as the public key of the vehicle entity, the scrapping request event hash, and the association timestamp. The association operation first verifies the validity and attribution of the key pair to ensure that the provided public key does belong to the last generation of vehicle entities. The verification process is achieved by comparing the current valid public key recorded in the contract with the provided public key. The verification formula is: Event association uses hash linking to cryptographically bind the hash value of the key pair with the hash value of the scrapping request event. The binding formula is: .

[0103] Association information is stored in a dedicated mapping structure within the smart contract. The mapping format is: 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 its corresponding private key to ensure authorization and non-repudiation. After the association operation is executed, the key pair is permanently marked as "scrapped association," and any subsequent communications initiated using this key pair will be rejected by the smart contract. The association record also contains comprehensive audit information, recording detailed information such as the operator, execution time, and operation parameters of the association operation, providing data support for subsequent audits and dispute resolution. The association process also triggers a "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.

[0104] Broadcasting the lifecycle state changes of the finite state machine smart contract to the entire vehicle consortium chain and rejecting the associated key pair communication requires the establishment of an efficient network broadcast mechanism and a comprehensive communication interception system to ensure the complete isolation of scrapped vehicles and network security. In practice, this network-wide broadcast utilizes a combination of smart contract event mechanisms and P2P network communication to ensure that state change information is rapidly 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 gene hash, the new state value, the change timestamp, and the associated key pair information. This event propagation utilizes the blockchain network's native propagation mechanism. With the generation and synchronization of new blocks, state change information is propagated throughout the network. To accelerate the propagation process, an active push mechanism is also implemented. Upon receiving the state change event, key nodes proactively push the updated information to neighboring nodes. Upon receiving the broadcast information, network nodes immediately update their local vehicle state cache and access control lists, adding the associated key pair to a blacklist. The communication interception mechanism is implemented by modifying the network layer's message filtering rules. All messages signed with a blacklisted key pair are automatically discarded. The interception judgment formula is: .

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

[0106] The aforementioned smart contract-based vehicle scrapping status management mechanism establishes a complete closed-loop vehicle lifecycle management system, enabling digital tracking and control of the entire vehicle lifecycle from factory exit to final scrapping. A two-party signature mechanism for scrapping requests ensures the legitimacy and authority of scrapping operations, preventing malicious and invalid scrapping requests. A qualification certification system also safeguards the professionalism and credibility of scrap recycling agencies. A multi-level verification mechanism within the consensus verification process effectively prevents fraudulent scrapping requests from being approved, ensuring that only vehicles that meet scrapping standards can enter the scrapping process, thus maintaining a healthy and orderly IoV ecosystem. Atomic transactional state changes ensure the permanence and irreversibility of scrapped status, avoiding data inconsistencies during state changes and providing reliable technical support for vehicle asset management. A mechanism linking key pairs to scrapping events establishes a comprehensive key lifecycle management system, ensuring that all cryptographic credentials associated with scrapped vehicles are properly handled and preventing the malicious use of discarded keys. A network-wide broadcast and communication interception mechanism ensures the complete network isolation of scrapped vehicles, effectively preventing the security risks and network contamination that could result from their continued participation in IoV communications. The entire scrappage 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 management. By establishing this comprehensive scrappage status management mechanism, the Internet of Vehicles achieves closed-loop management of the vehicle's entire lifecycle, laying a solid foundation for building a safer, more environmentally friendly, and sustainable intelligent transportation ecosystem.

[0107] In one embodiment, after permanently changing the lifecycle state of the target vehicle to the scrapped state in an atomic transaction through a finite state machine smart contract, the following steps are also included: S810. Desensitize the complete reputation hash chain anchored in the finite state machine smart contract. Desensitization includes removing the direct connection between the reputation hash chain and the vehicle's digital gene and the vehicle's previous generations. S820: retain the desensitized reputation hash chain and archive the desensitized reputation hash chain into a preset historical reputation database; S830: Statistical analysis and training of the macro trust model of the entire IoV alliance chain based on the historical reputation database; S840. Provide regulatory authorities with an access interface to the historical credit database, ensuring that the data cannot be traced back to the original vehicle.

[0108] Desensitizing the complete reputation hash chain anchored in the finite state machine smart contract requires the establishment of 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 the specific implementation, the desensitization process first extracts the complete reputation hash chain of the target vehicle from the smart contract. The chain contains all interactive behavior records from the vehicle's use to scrapping. The structure of the reputation hash chain contains multiple nodes, each of which contains information such as reputation summary, timestamp, behavior type, forward hash pointer, etc., as well as direct association identification with the vehicle's digital gene and vehicle body. The core of the desensitization process is to remove all identification information that may cause the data to be traced back to a specific vehicle or owner, including sensitive data such as the vehicle's digital gene hash, the owner's public key, and the vehicle identification code. The removal process uses a field replacement algorithm to replace sensitive fields with randomly generated anonymous identifiers. The replacement formula is: , generating a 128-bit anonymous identifier. Desensitization also includes time obfuscation, converting precise timestamps into time intervals, such as converting "2023-12-15 10:30:25" into "2023-12-15 10:00-11:00," reducing the accuracy of time information. Desensitization of geographic location information uses coordinate offset and regionalization to convert precise GPS coordinates into approximate geographic areas. Desensitization of behavioral description information is achieved through keyword filtering and semantic generalization, removing descriptive information that may contain vehicle characteristics or the owner's identity. The desensitization process also includes disconnecting associations. Multiple credit records originally connected through the vehicle's digital gene are reassigned anonymous identifiers, making it impossible to re-establish associations through data analysis. The entire desensitization process uses an irreversible algorithm to ensure that the desensitized data cannot be restored to the original data, while maintaining the statistical characteristics and analytical value of the data.

[0109] Retaining the desensitized reputation hash chain and archiving it to the preset historical reputation database requires the establishment of a dedicated data storage architecture and an efficient data management system to ensure the long-term preservation and rapid access of historical data. In specific implementation, the historical reputation database adopts a distributed storage architecture, combining the advantages of relational databases and NoSQL databases to achieve unified management of structured data and unstructured data. The database design includes multiple core table structures: anonymous reputation record table, behavior type statistics table, time series index table, geographic area distribution table, etc. The structure of the anonymous reputation record table includes anonymous identifiers, desensitized reputation summaries, behavior types, time intervals, geographic areas and other fields. The archiving process first converts the data format of the desensitized reputation hash chain, converting the chain structure into a table structure that can be stored in a relational database. The conversion process maintains the original temporal relationship and logical association. Data insertion adopts batch processing, and transaction control is used to ensure data consistency and integrity. In order to improve query efficiency, a multi-dimensional index structure is established, including time index, behavior type index, geographic area index, etc. The index creation formula is: , typically improving query efficiency by 10-100 times. The database also includes data compression and archiving strategies, compressing and storing historical data older than a certain age, achieving a compression rate of 60-80%. The archiving process also includes data integrity verification, using hash checks to ensure consistency between archived data and the original, desensitized data. The database design also takes scalability and maintainability into consideration, supporting horizontal expansion and online upgrades, providing technical support for large-scale data storage.

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

[0111] Correlation analysis uses the Pearson and Spearman correlation coefficients to calculate the degree of association between different types of behavior. Time series analysis uses the ARIMA model and seasonal decomposition method to identify cyclical patterns and trend changes in credit behavior. The model formula is: .

[0112] Machine learning model training utilizes deep learning methods, including recurrent neural networks (RNNs) and long short-term memory networks (LSTMs), to predict the development trends of IoV reputation behavior. The model training process utilizes a combination of supervised and unsupervised learning. The training dataset consists of 80% of the historical reputation data, and the validation dataset contains 20%. Model evaluation utilizes multiple metrics, including accuracy, recall, and F1 score. The evaluation formula is: .

[0113] 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.

[0114] Providing regulatory authorities with access to the historical reputation database while ensuring that data cannot be traced back to the original vehicle requires the establishment of a secure and controllable data disclosure mechanism and a fine-grained permission management system to balance the needs of data disclosure and privacy protection. In specific implementation, the access interface adopts a RESTful API architecture design, supports HTTP / HTTPS protocols, and provides standardized data query and analysis services. The interface design includes multiple levels of access control. The first level is identity authentication, which verifies the visitor's legal identity and regulatory qualifications. The authentication process uses digital certificates and a multi-factor authentication mechanism. The authentication formula is: The second layer is authorization control, which allocates corresponding data access rights according to the functional scope of different regulatory departments. The permission levels include: basic statistical permissions, behavioral analysis permissions, trend forecasting permissions, in-depth analysis permissions, etc. Permission control adopts the role-based access control (RBAC) model. The permission matrix defines the data types and operation permissions that different roles can access. The third layer is data desensitization verification, which verifies the desensitization integrity of the data again before the data is returned to ensure that no personal privacy information is leaked. The verification algorithm uses sensitive information detection technology. The detection formula is: , requiring 100% completeness of desensitization. The interface also provides a data query restriction mechanism, including query frequency limit, data volume limit, time range limit, etc., to prevent data abuse and system overload.

[0115] The query restriction formula is: .

[0116] The interface also includes an audit log function that records detailed information about all access operations, including visitor identity, access time, query content, and returned results, supporting data security monitoring and compliance audits. Data return formats support JSON, XML, CSV, and other formats to meet the data processing requirements of various regulatory agencies. The interface also provides data visualization, presenting statistical analysis results through charts and reports, improving data readability and practicality.

[0117] Through this privacy-preserving historical reputation data management mechanism, a sustainable utilization system for IoV data assets has been established, achieving a balance between personal privacy protection and data value mining. The reputation hash chain's desensitization process, through a systematic de-identification process, completely severs the data's association with specific vehicles and owners, protecting individual privacy while preserving the data's statistical value and analytical significance. A dedicated historical reputation database establishes a long-term storage and efficient management mechanism for IoV behavioral data, providing a rich data resource for big data analysis and artificial intelligence applications. Machine learning-based macro-trust model training enables deep understanding and intelligent prediction of the IoV ecosystem, providing a scientific basis for network security protection, reputation system optimization, and policy formulation. A multi-tiered regulatory data disclosure mechanism, while ensuring data security, provides valuable data insights to government regulators, 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 IoV industry. By establishing this complete historical data management mechanism, the Internet of Vehicles has achieved an upgrade from simple data collection to intelligent data governance, providing important data infrastructure for building a more secure, trustworthy and intelligent Internet of Vehicles ecosystem, and promoting data-driven innovation and sustainable development in the field of intelligent transportation.

[0118] An embodiment of the present invention also discloses a blockchain-based vehicle network security communication system, comprising 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 implements the above-mentioned blockchain-based vehicle network security communication method when executing the computer program.

[0119] An embodiment of the present invention also discloses a computer-readable storage medium having instructions stored thereon, wherein when the instructions are executed by a processor, the processor is configured to execute the above-mentioned blockchain-based vehicle network secure communication method.

[0120] Among them, the processor can adopt a central processing unit (CPU). Of course, according to actual usage, other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. can also be adopted. The general-purpose processor can adopt a microprocessor or any conventional processor, etc., and this application does not impose any restrictions on this.

[0121] Among them, the memory can be an internal storage unit of a computer device, such as a hard disk or memory of a computer device, or an external storage device of a computer device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD) or flash memory card (FC) equipped on the computer device. In addition, the memory can also be a combination of an internal storage unit and an external storage device 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 is to be output. This application does not impose any restrictions on this.

[0122] The present invention also discloses a computer-readable storage medium having instructions stored thereon. When the instructions are executed by a processor, the processor is configured to execute the blockchain-based vehicle network security communication method and system method described in any one of the above embodiments.

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

[0124] Among them, through this computer-readable storage medium, the blockchain-based vehicle network security communication method and system method in the above embodiments are stored in the computer-readable storage medium, and are loaded and executed on the processor to facilitate the storage and application of the above methods.

[0125] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of protection of the present application is limited to these examples. In line with the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0126] The one or more embodiments of this application are intended to encompass 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 of this application should be included in the scope of protection of this application.

Claims

1. A secure communication method for Internet of Vehicles based on blockchain, characterized in that: The steps include: The hardware response value generated by the target vehicle's built-in PUF circuit is integrated with the target vehicle's static identifier 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 lifecycle states is deployed on the blockchain for the target vehicle. The preset lifecycle states include the vehicle's factory status, vehicle usage status, and vehicle transaction status. Based on the vehicle usage status of the finite state machine smart contract, the key pair for vehicle network communication is activated for the target vehicle's onboard communication unit. When the target vehicle generates a valid interaction behavior verified by consensus, the reputation summary recording the valid interaction behavior is anchored to the finite state machine smart contract in the form of a hash chain; In response to an ownership transfer request 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 triggered to switch from the vehicle use state to the vehicle transaction state, and the permission decay mechanism is activated 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 by the 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 subject in an atomic transaction, and the control of the anchored reputation summary is transferred from the original vehicle subject to the new vehicle subject; 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 method for secure communication of Internet of Vehicles based on blockchain according to claim 1, characterized in that: The process of fusing the hardware response value generated by the built-in PUF circuit of 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 a preset lifecycle state for the target vehicle on the blockchain based on the vehicle digital gene, includes the following steps: Sending a standard test value pre-set by an authorized entity to the PUF circuit built into the target vehicle; Obtaining a hardware response value generated by the PUF circuit based on a standard test value of its own physical structure response; A fusion algorithm is used to fuse the hardware response value with the static identification of the target vehicle to generate the vehicle digital gene of the target vehicle; The authorized entity uses the authorized root private key to digitally sign the vehicle's digital gene to form a blockchain certificate; Packaging the vehicle’s digital DNA, blockchain proof, and a finite state machine smart contract template containing pre-set lifecycle states into a blockchain transaction; Publish the blockchain transaction to the pre-deployed Internet of Vehicles consortium chain to complete the deployment of the finite state machine smart contract, and set the initial life cycle state of the finite state machine smart contract to the vehicle factory state.

3. The method for secure communication of Internet of Vehicles based on blockchain according to claim 2, characterized in that: When the target vehicle generates a valid interaction behavior that can be verified by consensus, anchoring the reputation summary of the valid interaction behavior in the form of a hash chain in the finite state machine smart contract includes the following steps: Predefine multiple different types of valid interactive behaviors and corresponding reputation weights in the finite state machine smart contract; After the target vehicle completes a valid interaction in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies the multi-source interaction data related to the valid interaction behavior; 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; Perform hash operation on the original reputation data based on the reputation weight to obtain the reputation summary; Use hash pointers to link the reputation summary to the end of the reputation hash chain in the Internet of Vehicles Alliance Chain; The chain head hash value of the updated reputation hash chain is recorded in the finite state machine smart contract.

4. The method for secure communication of Internet of Vehicles based on blockchain according to claim 3, characterized in that: After the target vehicle completes a valid interaction behavior in the IoV alliance chain, the witness node in the IoV alliance chain collects and verifies the multi-source interaction data related to the valid interaction behavior, including the following steps: receiving first interaction data including a digital signature from a target vehicle that initiates a valid interaction behavior; receiving second interaction data from at least one other network participant within the effective interaction behavior influence range; Integrate the first interaction data and the second interaction data into multi-source interaction data, and verify the consistency of event elements of the multi-source interaction data; Query the finite state machine smart contract of the target vehicle and confirm that the current life cycle state of the finite state machine smart contract is the vehicle use state; After the consistency verification of event elements is passed and the life cycle status is confirmed to be correct, the multi-source interactive data verification is deemed to have passed.

5. The method for secure communication of Internet of Vehicles based on blockchain according to claim 3, characterized in that: The triggering of the finite state machine smart contract state switching from the vehicle use state to the vehicle transaction state 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 comprises the following steps: An authorized third party generates an initial ownership transfer request containing a unique transaction identifier; The new vehicle subject of the target vehicle adds the newly generated local public key to the initial ownership transfer request and digitally signs it with the private key of the new vehicle subject; When the original vehicle subject of the target vehicle receives an ownership transfer request that includes the signature of the new vehicle subject, the original vehicle subject digitally signs the request using the private key of the original vehicle subject; After the authorized third party verifies that the signatures of the original vehicle owner and the new vehicle owner are both valid, the authorized third party adds a digital signature of the authorized third party to the ownership transfer request; The ownership transfer request digitally signed by the original vehicle owner, the new vehicle owner and the authorized third party is submitted to the Internet of Vehicles Alliance Chain as a transaction, triggering the state of the finite state machine smart contract to switch from the vehicle use state to the vehicle transaction state.

6. The method for secure communication of Internet of Vehicles based on blockchain according to claim 5, characterized in that: The startup authority decay mechanism gradually reduces the communication authority of the key pair held by the original vehicle subject in the vehicle transaction state, including the following steps: When the finite state machine smart contract enters the vehicle transaction state, the preset block height timer is started; The permission decay rule table preset in the finite state machine smart contract is queried based on the height difference between the current block height and the timer start height. The permission decay rule table defines the highest priority of the Internet of Vehicles messages allowed to be sent by the key pair held by the original vehicle entity within different height difference intervals. As the height difference increases, the highest priority of the message allowed to be sent by the original vehicle entity decreases in one direction. When the height difference reaches the preset threshold, the sending permission of the key pair held by the original vehicle entity is cleared, and only the receiving permission is retained.

7. The method for secure communication of Internet of Vehicles based on blockchain according to claim 3, characterized in that: The preset life cycle state of the finite state machine smart contract also includes a vehicle scrapping state. The method further includes the following steps: When the target vehicle reaches the scrap standard, a qualified scrap recycling organization will serve as the scrapping authorized third party and jointly sign with the last generation of vehicle owners and initiate a scrapping request on the Internet of Vehicles Alliance Chain; When the scrapping request passes consensus verification in the Internet of Vehicles Alliance Chain, the finite state machine smart contract is triggered; The target vehicle's lifecycle status is permanently changed to a scrapped state in an atomic transaction through a finite state machine smart contract; Associating the key pair held by the last generation vehicle subject with the scrapping request event of the target vehicle; Broadcast the lifecycle state changes of the finite state machine smart contract to the entire network in the Internet of Vehicles Alliance Chain, so that any communication initiated using the key pair related to the vehicle digital gene of the target vehicle will be rejected by the Internet of Vehicles Alliance Chain.

8. The method for secure communication of Internet of Vehicles based on blockchain according to claim 7, characterized in that: After the target vehicle's lifecycle state is permanently changed to a scrapped state in an atomic transaction through a finite state machine smart contract, the following steps are also included: Desensitize the complete reputation hash chain anchored in the finite state machine smart contract. This includes removing the direct connection between the reputation hash chain and the vehicle's digital gene and the vehicle's previous generations. Keep the desensitized reputation hash chain and archive it in the preset historical reputation database; Conduct statistical analysis and training on the macro trust model of the entire IoV alliance chain based on the historical reputation database; Under the premise of ensuring that the data cannot be traced back to the original vehicle, an access interface to the historical credit database is provided to the regulatory authorities.

9. A blockchain-based Internet of Vehicles 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 Internet of Vehicles secure communication method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instruction is executed by a processor, the processor is configured to execute the blockchain-based vehicle network security communication method according to any one of claims 1 to 8.

Images