Article flow tracking method based on NFC and blockchain collaborative authentication

Abstract

The application relates to the field of article tracing and digital asset management, and discloses an article circulation tracking method based on NFC and blockchain collaborative authentication. The method binds the NFC unique hardware identifier of an article with a one-time activated identifier in the background, and when the user activates, a smart contract is called to cast a digital twin certificate corresponding to the article. In the secondary circulation, a double signature mechanism is used to create a transfer intention signed by the seller and confirmed by the buyer, and the smart contract completes the verification and atomically transfers the certificate ownership, ensuring the safety of the transaction and the consensus of the two parties. The certificate can also carry after-sales benefits, and the cancellation is recorded by the smart contract. The application uses the strong binding of NFC physical layer anti-counterfeiting and blockchain on-chain logic to solve the trust problem in circulation, and realizes the safe, transparent and tamper-proof tracking of the change of the ownership and rights and interests of the article in the whole life cycle.

Description

Technical Field

[0001] This invention relates to the field of product traceability and digital asset management, specifically a method for tracking the flow of goods based on NFC and blockchain collaborative authentication. Background Technology

[0002] Product traceability and lifecycle management are important technical issues in the commodity circulation field. Current technologies typically involve attaching identifiers to products for tracking. For example, QR codes are widely used for recording and querying product information. However, as an optical graphic, the ability of QR codes to be easily copied makes it impossible for verification systems to distinguish between the identifier bound to the original product and the copied identifier. Therefore, it cannot ensure a unique correspondence between the identifier and the physical entity, presenting inherent flaws in anti-counterfeiting and ownership tracking.

[0003] To address the issue of tag duplication, some technical solutions employ Near Field Communication (NFC) tags with built-in unique hardware identifiers. By reading the unclonable hardware identifier within the NFC tag, a reliable link can be established between the physical item and backend data. Some solutions further record this linking information on a blockchain, leveraging the blockchain's immutability and decentralization to register the initial ownership of the item, which enhances the credibility of traceability information to some extent.

[0004] However, existing solutions combining NFC and blockchain still have significant technical shortcomings when handling secondary or multiple transfers of ownership of goods. When an item is transferred from one holder to another, the ownership change process of the corresponding on-chain digital certificate typically relies on a centralized backend server for arbitration and transaction proxying. This design reintroduces centralized risks, contradicting the original intention of adopting blockchain technology, and fails to effectively utilize blockchain to achieve peer-to-peer value transfer. Furthermore, these solutions lack a mechanism to directly verify the true intentions of both parties in the transaction on-chain, resulting in insufficient security and transparency in the transfer process.

[0005] Therefore, there is currently a lack of a technical solution in the field that can closely link the uniqueness of physical items with on-chain digital credentials, achieve decentralization in the secondary circulation process, enable direct consensus confirmation between the two parties on the chain, and ensure full-process security and traceability. Summary of the Invention

[0006] The technical problem that this invention aims to solve is that existing item tracking methods are easily activated prematurely by illegally copying credentials during the activation process, and are limited during the ownership transfer process because some terminal devices do not support NFC writing. Furthermore, the after-sales service rights of items are difficult to reliably bind to the new holder after the ownership is transferred.

[0007] To address the aforementioned technical problems, this invention provides a method for tracking the movement of goods based on NFC and blockchain collaborative authentication.

[0008] The technical solution of this invention is implemented as follows: a method for tracking the flow of goods based on NFC and blockchain collaborative authentication, comprising the following steps: S1. Production Binding Step: In the backend server, the unique hardware identifier of the NFC tag associated with the item, the item identifier, and the hash value of a one-time activation identifier are data bound together. This step is completed before the item enters circulation, creating an initial digital profile for each physical entity in the backend server.

[0009] S2. Activation and Rights Confirmation Step: After completing the production binding step in S1, in response to the user's request to read the unique hardware identifier and submit the one-time activation identifier, the backend server verifies the information. Upon successful verification by the backend server, a smart contract deployed on the blockchain is invoked to forge a digital twin certificate for the item, bound to the user's blockchain address. The data structure of this digital twin certificate embeds after-sales rights information, thereby associating the physical entity of the item with its digital ownership and additional rights on the blockchain.

[0010] S3, Secondary Transfer Step: When the digital twin certificate generated in S2 needs to transfer ownership, the seller generates a first signature based on the transfer information to create a transfer intention containing a pre-transfer transaction identifier in the smart contract. Subsequently, the buyer generates and submits a second signature based on the confirmation information. Upon receiving the second signature, the smart contract performs double signature verification. After successful verification, ownership of the digital twin certificate is atomically transferred from the seller's blockchain address to the buyer's blockchain address. Simultaneously, the embedded after-sale rights are transferred along with the ownership.

[0011] S4. After-sales management steps: During the lifecycle of the digital twin certificate, a dedicated after-sales interface within the smart contract is invoked to verify and atomically decrement the after-sales rights embedded in the digital twin certificate. This operation is recorded on the blockchain, ensuring the traceability of after-sales service history.

[0012] In a preferred embodiment, the verification performed by the backend server in step S2 specifically includes: after receiving the one-time activation identifier submitted by the user, the backend server calculates its hash value using the same hash algorithm as in the production binding step, and compares the calculation result with the hash value of the one-time activation identifier associated with the unique hardware identifier stored in the backend server. If the comparison results match, and the backend server record shows that the one-time activation identifier is being used for the first time, the verification is considered successful.

[0013] Further, in step S3, the transfer information includes the unique hardware identifier, the ID of the digital twin certificate, the buyer's blockchain address, and a validity expiration timestamp. The process of the seller generating a first signature based on the transfer information specifically includes: the seller's client generating a first digest according to the transfer information and following a preset seller transfer intent digest generation rule; subsequently, the seller signing the first digest using their private key to obtain the first signature. The seller transfer intent digest generation rule can be expressed as: ; in, This is the first summary. A unique hardware identifier, For the ID of the digital twin certificate, For the buyer's blockchain address, This is the expiration time stamp. Here is the hash function, and here is the concatenation operator.

[0014] In one specific embodiment, after the transfer intention is created, the confirmation information in step S3 includes the pre-transfer transaction identifier generated by the smart contract, the unique hardware identifier, and the ID of the digital twin certificate.

[0015] The process by which the buyer generates and submits the second signature based on the confirmation information specifically includes: The buyer's client generates a second digest based on the confirmation information, following a preset buyer confirmation intent digest generation rule. Subsequently, the buyer signs the second digest using their private key to obtain the second signature. The buyer confirmation intent digest generation rule can be expressed as: ; in, This is the second abstract. This is the identifier for the pre-transfer transaction.

[0016] Preferably, the pre-transfer transaction identifier is transmitted from the seller to the buyer through one of the following methods: Write a URL containing the pre-transfer transaction identifier into the NFC tag associated with the item; Alternatively, a URL link or QR code containing the pre-transfer transaction identifier can be generated and shared by the seller with the buyer via a communication application.

[0017] Preferably, the verification in step S4 specifically involves checking the caller's permissions and the status of the after-sales rights. The status check includes checking whether the current time is within the validity period timestamp and whether the number of times the service has been used is less than the total number of services used. The atomic decrement operation specifically involves incrementing the number of times the service has been used recorded in the after-sales rights data structure by one after the verification passes.

[0018] In one specific embodiment, when the buyer client detects a network connection failure after generating the second signature, it temporarily caches the data combination of the pre-transfer transaction identifier and the second signature in local storage. Subsequently, when the buyer client detects that the network connection has been restored, it automatically reads the cached data and calls the corresponding interface of the smart contract to complete the submission operation.

[0019] Preferably, the smart contract is equipped with role-based access control. Specifically, the permission required to execute the operation of forging digital twin certificates in step S2 is granted only to a preset product provider role, and the caller permission to execute the after-sales management step in step S4 is granted only to a preset authorized after-sales service point role.

[0020] Preferably, the digital twin certificate is a data structure recorded on a blockchain, and the data structure explicitly includes: The unique hardware identifier bound to the NFC tag, the item identifier, the current holder's blockchain address, and an after-sales rights data structure for recording the total number of after-sales services, the number of times it has been used, and the expiration time stamp.

[0021] This invention provides a method for tracking the movement of goods based on NFC and blockchain collaborative authentication. It has the following beneficial effects: 1. This invention performs dual verification of the read NFC unique hardware identifier and the one-time activation identifier submitted by the user during the activation and authorization process. That is, the backend server needs to compare the hash value of the activation identifier and confirm that it is the first use. By utilizing the uniqueness of the hardware and the confidentiality of the one-time identifier, copying only part of the item's identification information is insufficient to complete the activation, thereby preventing the item from being activated prematurely or illegally without authorization.

[0022] 2. This invention introduces a dual-signature verification mechanism in the secondary transfer step, where the seller's first signature establishes the transfer intention and the buyer's second signature confirms the ownership transfer. This places the core logic of ownership transfer on a blockchain smart contract for execution. This method does not require the buyer's device to have the ability to write data to an NFC tag; confirmation can be completed simply by obtaining a pre-transfer transaction identifier via a URL link or QR code. Therefore, it is compatible with terminal devices that only have NFC reading capabilities, overcoming the obstacles to ownership transfer implementation on different device platforms.

[0023] 3. This invention embeds after-sales rights into a digital twin certificate on the blockchain in the form of a data structure. During the secondary transfer process, when ownership of the digital twin certificate changes, the embedded after-sales rights, as an inherent component of the certificate, are transferred along with and completely to the new holder. Furthermore, through the atomic decrement operation of the after-sales rights via smart contracts, the accuracy and immutability of service records are ensured, thereby achieving a reliable binding and traceable management of after-sales rights and item ownership. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the system architecture for implementing a method for tracking the flow of goods based on NFC and blockchain collaborative authentication, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of a method flow according to an embodiment of the present invention; Figure 3 This is a detailed interactive flowchart of the secondary transfer step S3 of the present invention; Figure 4 This is a schematic diagram of the key data structure inside a twin traceability smart contract according to an embodiment of the present invention. Detailed Implementation

[0025] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] See attached document Figure 1 , Figure 1 This is a schematic diagram of a system architecture for implementing a method for tracking the movement of goods based on NFC and blockchain collaborative authentication, according to an embodiment of the present invention. The system may include: An NFC tag 10, a user terminal 20, a back-end server 30, and a twin traceability smart contract 40 deployed on a blockchain network.

[0027] The NFC tag 10 is a passive radio frequency identification tag that is integrated into or attached to the physical item to be tracked. Each NFC tag 10 has a unique hardware identifier (UID) that is permanently stored inside and cannot be modified after leaving the factory. This unique hardware identifier serves as the identity anchor of the physical item in the digital system, providing a stable physical association basis for all subsequent steps.

[0028] The client 20 is an application running on a user terminal device. The client 20 has the ability to read the unique hardware identifier of the NFC tag 10 through the NFC module of the terminal device. Simultaneously, the client 20 provides a user interface for the user to input a one-time activation identifier and communicates with the backend server 30 via a secure network protocol (such as HTTPS) to transmit data and receive instructions.

[0029] The backend server 30 is a computing system consisting of one or more servers that communicates with the user terminal 20 via an application programming interface (API). The backend server 30 has an internal database for storing the binding relationships between unique hardware identifiers, item identifiers, and hash values ​​of one-time activation identifiers. The backend server 30 executes the verification logic for the one-time activation identifier submitted by the user and is responsible for constructing transaction data and calling the function interfaces of the twin traceability smart contract 40.

[0030] When executing the verification logic, the backend server 30 will first use the received unique hardware identifier as the primary key to query the corresponding record in its database to ensure that the subsequent hash comparison is performed on the correct item, thereby avoiding the possibility of data mismatch.

[0031] Specifically, in the production binding step, the backend server 30 receives the plaintext of the one-time activation identifier and generates its hash value for storage. The calculation of this hash value follows a preset hash generation rule, which can be expressed as: ; in, A hash value representing a one-time activation identifier; Plain text representing a one-time activation identifier; This represents a salt value securely stored by the backend server to increase the complexity of hash operations; SHA256 is the 256-bit version of the secure hash algorithm; and is the data concatenation operator. The database only stores... No plaintext is stored. .

[0032] The digital twin traceability smart contract 40 is a computer program deployed and running on a blockchain network. This smart contract 40 defines the data structure, ownership, and state transition rules throughout the lifecycle of the digital twin credential, including the minting of the credential, the transfer of ownership, and changes in post-sale rights. The smart contract 40 receives transaction calls from the backend server 30 or other authorized blockchain addresses and executes operations according to preset logic. The execution results are publicly recorded and immutable on the blockchain.

[0033] In the implementation of this invention, the user terminal 20 collects physical layer information (unique hardware identifier) ​​and user input information (one-time activation identifier), and sends the information to the backend server 30. After completing business logic processing and verification, the backend server 30 constructs and submits a transaction to the blockchain network to invoke the twin traceability smart contract 40. The twin traceability smart contract 40 executes the transaction according to preset rules, thereby updating the core asset status and circulation history recorded on the blockchain.

[0034] See attached document Figure 2 , Figure 2 This is a schematic diagram of a method flow according to an embodiment of the present invention. The specific execution steps of the method of the present invention will be described in detail below.

[0035] In the production binding step S1, firstly, on the production line, an NFC reader / writer acquires the unique hardware identifier of the NFC tag 10 on each item to be bound. Simultaneously, the backend server 30 generates a highly random one-time activation identifier for the item and calculates its hash value using a preset hash algorithm. Subsequently, the backend server 30 calls an internal data binding interface to create a new record in an asset information table in its database. This record contains at least: the unique hardware identifier, the item's product identifier (e.g., SKU or batch number), and the hash value of the one-time activation identifier, thus completing the associated storage of these three elements. To facilitate subsequent activation status checks, this record also includes an activation status field, whose initial value is set to inactive.

[0036] In activation and authorization step S2, after a legitimate user obtains the item, they scan the item's NFC tag 10 using the user terminal 20. The user terminal 20 then obtains the unique hardware identifier of the NFC tag 10. Simultaneously, the user manually enters the plaintext of a one-time activation identifier accompanying the item on the interface provided by the user terminal 20. The user terminal 20 packages the obtained unique hardware identifier and the user-entered one-time activation identifier into an activation request and sends it to the backend server 30 via the network.

[0037] Upon receiving the activation request, the backend server 30 first queries its database based on the received unique hardware identifier to find the corresponding record and the hash value of the one-time activation identifier stored therein. The backend server 30 uses the exact same hash algorithm and salt value as in production binding step S1 to hash the received plaintext one-time activation identifier. Then, it compares the calculated new hash value with the hash value stored in the database. If the comparison result is inconsistent, the activation request is rejected. If the comparison result is consistent, the activation status bit of the record is further checked to confirm that the one-time activation identifier has not been used before. Verification is successful only when the hash value comparison is consistent and the activation status is unused.

[0038] After successful verification, the backend server 30 uses its blockchain account, which has been granted minting authority, to call the minting function of the twin traceability smart contract 40. The parameters for the call include: a unique hardware identifier, an item identifier, the user's blockchain address, and after-sales rights data determined based on the item's product template (e.g., total service usage, expiration time stamp). The twin traceability smart contract 40 executes the minting operation, generating a unique digital twin credential ID and recording the ownership of this credential as the user's blockchain address. Upon successful minting, the smart contract 40 triggers a minting success event. Upon receiving this event, the backend server 30 writes the obtained digital twin credential ID back to the corresponding asset record in its database, completing the final binding between the physical entity of the item and the digital twin credential on the blockchain.

[0039] See attached document Figure 3 , Figure 3 This is a detailed interactive flowchart of the secondary transfer step S3 according to the present invention. In the secondary transfer step S3, when the current holder of the digital twin certificate (i.e., the seller) needs to transfer ownership to another user (i.e., the buyer), the seller initiates a transfer operation on its user terminal 20. The seller's user terminal 20 will guide the seller to input the buyer's blockchain address and the expiration time stamp of this transfer intention. Subsequently, the client generates a first digest based on the transfer information. The transfer information includes a unique hardware identifier, the ID of the digital twin certificate, the buyer's blockchain address, and the expiration time stamp. The generation rule of the first digest can be expressed as: ; in, This is the first abstract. A unique hardware identifier, For the ID of the digital twin certificate, For the buyer's blockchain address, This is the expiration time stamp. The seller uses their private key to set the first digest. Perform the signing process to generate the first signature. The user terminal 20 will Along with other transfer information, it is submitted to the twin traceability smart contract 40 to create a transfer intent. Smart contract 40 internally verifies this. After verifying the validity of the document and confirming that the signatory is the legitimate holder of the document, based on the validity of the document... Generate a unique pre-transfer transaction identifier And record the intention to transfer.

[0040] Subsequently, the pre-transfer transaction identifier This needs to be transmitted from the seller to the buyer. If the seller's terminal device supports NFC writing, the seller's user terminal 20 can transmit a data packet containing this data. The URL is directly written into the NFC tag 10 of the item. If the device does not support NFC writing, the user terminal 20 can generate a tag containing the URL. The seller shares the URL link or corresponding QR code with the buyer via instant messaging tools or other means.

[0041] The buyer received the pre-transfer transaction identifier Subsequently, a confirmation operation is performed on the buyer's client 20. The buyer's client 20 simultaneously reads the unique hardware identifier of the item's NFC tag 10 and the ID of the digital twin credential. The client then generates a second digest based on the confirmation information. The confirmation information includes a pre-transfer transaction identifier. A unique hardware identifier and the ID of the digital twin credential. The rule for generating the second digest can be expressed as: ; in, This is the second digest. The buyer uses their private key to process this second digest. Perform a signature and generate a second signature. The buyer's user terminal 20 will... and Submitted to twin traceability smart contract 40. Smart contract 40 according to... The corresponding transfer intent is located, and a double-signature verification is performed: first, the first signature is verified, and then the received second signature is verified. After both signatures are confirmed to be signed by the legitimate seller and buyer, smart contract 40 atomically modifies the ownership address of the digital twin certificate to the buyer's blockchain address and updates the transfer intent status to complete. This atomic modification means that a series of operations, including double-signature verification, updating the ownership address, and updating the transfer intent status, are executed within the same blockchain transaction. This transaction either completes entirely successfully or is rolled back entirely if any verification fails or an error occurs at any stage, thus ensuring that there are no data inconsistencies such as ownership being transferred but the transfer intent status not being updated.

[0042] In this embodiment, if the buyer's client generates a second signature If a network connection is subsequently detected as unavailable, the client will not immediately attempt to invoke the smart contract. At this point, the client will send a pre-transfer transaction identifier. Second signature As a transaction unit to be submitted, it is cached in the local storage area of ​​the terminal device. When the client 20 detects that the network connection has been restored at a later point in time (such as when the application is launched again or when the network status changes), it will automatically read the transaction unit to be submitted in the local storage and re-initiate the call to the twin traceability smart contract 40 to complete the transfer of ownership.

[0043] In after-sales management step S4, when the item holder needs to use after-sales service, authorized after-sales service personnel use their dedicated user terminal 20, which has been granted a specific role, to scan the item's NFC tag 10 to obtain the digital twin certificate ID. The user terminal 20 calls the interface of the backend server 30 to query the after-sales rights details of the certificate. After confirming that the service is available, the staff initiates a service usage request through their user terminal 20. This request is ultimately initiated by a blockchain account granted the authorized after-sales service location role, which calls the twin traceability smart contract 40 to execute the after-sales service function. During execution, the smart contract 40 first checks the caller's role for permissions, and then checks the after-sales rights status of the certificate, including its validity period and remaining usage times. After all checks pass, the smart contract 40 increments the value of the used service count field in the after-sales rights data structure embedded in the certificate. This operation is recorded as a transaction on the blockchain.

[0044] See attached document Figure 4 , Figure 4 This is a schematic diagram of the key data structure inside a twin traceability smart contract 40 according to an embodiment of the present invention. The twin traceability smart contract 40 is the logical core for implementing the method of the present invention. It manages the lifecycle of the digital twin certificate on the blockchain through a preset data structure and function interface.

[0045] In one specific embodiment, the twin traceability smart contract 40 internally defines an after-sales rights data structure for recording after-sales service information bound to the digital twin certificate. This structure includes: an integer field for recording the total number of services, an integer field for recording the number of services used, and a Unix timestamp field for recording the expiration time of the after-sales service.

[0046] The twin traceability smart contract 40 also defines a digital twin credential metadata structure, which is the digital representation of each physical item on the blockchain. This structure includes: a string field storing the unique hardware identifier of the bound NFC tag 10; a string field storing the item identifier; an address field (owner) recording the current credential holder's blockchain address; and an embedded structure field of type the aforementioned after-sales rights. Internally, the smart contract 40 uses a mapping to associate and store each unique digital twin credential ID with a corresponding digital twin credential metadata structure instance.

[0047] To implement the secondary transfer step S3, the twin traceability smart contract 40 further defines a transfer intention data structure. This structure is used to temporarily store a pending ownership transfer request on the blockchain. The structure includes: a pre-transfer transaction identifier field to uniquely identify the transfer, a digital twin certificate ID field to be transferred, a seller's blockchain address field, a designated buyer's blockchain address field, a valid deadline timestamp field for the transfer intention, and a status field indicating the current state of the intention; for example, 0 represents pending confirmation, and 1 represents confirmed confirmation.

[0048] The twin traceability smart contract 40 incorporates a role-based access control mechanism. This mechanism predefines multiple roles, such as the product provider role and the authorized after-sales service provider role. Different function interfaces are configured to be accessible only to blockchain accounts with specific roles. For example, the function responsible for minting new digital twin certificates is only granted to the product provider role, ensuring that only legitimate producers can create new asset certificates.

[0049] When the casting function is called by an account with a product owner role, it receives parameters such as the user's blockchain address, unique hardware identifier, item identifier, and initial after-sales rights. During function execution, it internally creates a new digital twin credential metadata structure instance, fills in the received parameters into the corresponding fields, sets the owner field to the user's blockchain address, assigns a new, unique digital twin credential ID to the instance, and establishes a mapping relationship between the ID and the instance.

[0050] The function that creates the transfer intent is used to process transfer requests initiated by the seller. This function receives the digital twin credential ID to be transferred, the buyer's address, the validity period, and the seller's first signature as input. Internally, the function first reconstructs the first digest based on the received parameters and the unique hardware identifier corresponding to the credential ID stored on-chain. Subsequently, a standard cryptographic recovery function (such as ecrecover) is used to recover the data based on the first digest. The contract retrieves the signer's blockchain address from the first signature. It then compares this retrieved address with the actual holder's address recorded in the credential ID record. If they match, the verification is successful. If they don't match, it means the signer is not the legitimate holder of the credential. In this case, the smart contract will refuse to execute subsequent operations and roll back the transaction, returning a failure status to the caller. After successful verification, the contract will calculate a unique pre-transfer transaction identifier based on the first signature. And create a new Intent structure instance and store it in the on-chain storage area.

[0051] The function that confirms the transfer intention is used to process confirmation requests initiated by the buyer. This function receives the pre-transfer transaction identifier. The buyer's second signature is taken as input. Inside the function, first, based on... The corresponding Intent structure instance is located, and its status is checked to ensure it is pending confirmation and that its current time has not exceeded its expiration date. Subsequently, the contract reconstructs the second digest based on the information recorded in the Intent instance. Similarly, cryptographic recovery functions are used based on the second digest. The second signature is used to recover the signer's blockchain address and compare it with the buyer's address recorded in the Intent instance. If all verifications pass, the contract will call the internal ownership transfer function to change the owner field in the metadata structure instance of the digital twin certificate ID from the seller's address to the buyer's address, and update the Intent instance's status to confirmed. Updating the Intent instance's status to confirmed prevents the pre-transfer transaction identifier from being used repeatedly for confirmation, ensuring that a single transfer intention can only successfully execute one ownership transfer.

[0052] The function for handling after-sales service can only be invoked by authorized after-sales service outlets. This function receives a digital twin credential ID as input. Upon execution, the function first checks if the caller possesses an authorized after-sales service outlet role. Then, it retrieves the metadata structure instance of the digital twin credential corresponding to the credential ID and performs a status check on its embedded rights field, confirming that the current time has not expired and the number of times it has been used is less than the total number of services. If all checks pass, the function increments the number of times it has been used and writes the updated status back to the blockchain.

[0053] To further illustrate the implementation of the present invention, the following description will take a specific example of the complete life cycle of an item from its production to the end user receiving after-sales service.

[0054] In this embodiment, the item to be tracked is a watch, which integrates an NFC tag 10. The execution entity of the method includes: The watch manufacturer controls a backend server 30, which holds a blockchain account with the role of the product owner; the first buyer, user A, holds blockchain account A; the second buyer, user B, holds blockchain account B; and an after-sales service outlet authorized by the manufacturer holds a blockchain account with the role of an authorized after-sales service outlet.

[0055] First, on the production line, the watch's NFC tag 10 is read to obtain its unique hardware identifier, denoted as U1. The manufacturer's backend server 30 generates a one-time activation identifier for the watch, denoted as C1, and calculates its hash value H1. The backend server 30 creates a record in its database, binding U1, the watch's model identifier P1, and the hash value H1. At this point, the production binding step S1 is complete.

[0056] Subsequently, User A purchased the watch. User A scanned the NFC tag 10 on the back of the watch using User Client 20 on their terminal device, reading the unique hardware identifier U1. Simultaneously, User A obtained a one-time activation identifier C1 from the packaging and entered it into the interface of User Client 20. User Client 20 sent U1 and C1 to the backend server 30. After verifying that the hash value of C1 matched the stored H1 and that the identifier was being used for the first time, the backend server 30 used its blockchain account (as the product provider) to call the minting function of the twin traceability smart contract 40. This call minted a digital twin certificate for User A's blockchain account A. This certificate, with ID T1, records ownership belonging to account A in its data structure and embeds after-sales rights for the watch, such as a total of 5 service uses. At this point, activation and ownership confirmation step S2 is completed.

[0057] After some time, User A decides to sell the watch to User B. User A initiates the transfer on their client 20 and enters User B's blockchain account B. User A's client generates a first digest based on the transfer information such as U1, T1, and account B, and guides User A to sign the digest using their private key, thus obtaining the first signature. The first signature The application was submitted to the twin traceability smart contract 40. After the contract was verified, a transfer intent was created and a pre-transfer transaction identifier PreTx1 was generated.

[0058] Since user A's terminal device does not support NFC writing, its client 20 generates a QR code containing a pre-transfer transaction identifier PreTx1. User A displays this QR code to user B. User B scans the QR code with its device to obtain a URL containing the pre-transfer transaction identifier PreTx1. User B's client generates a second digest based on PreTx1 and confirmation information such as U1 and T1 read from the watch's NFC tag 10, and guides user B to sign it using its private key to obtain a second signature. The second signature Submitted to the twin traceability smart contract 40. The contract completed the verification of the first signature on-chain. Second signature After the double signature verification is passed, ownership of voucher T1 is transferred from account A to account B. This completes the secondary transfer step S3.

[0059] Finally, User B takes the watch to an authorized after-sales service center for maintenance. The center's staff uses their dedicated client 20 to scan the watch's NFC tag 10, obtaining credential ID T1. Their system queries the Twin Traceability Smart Contract 40 for T1's after-sales rights, confirming it has 5 total service uses, with 0 already used. After completing the maintenance service, the center uses its authorized after-sales service center blockchain account to call the after-sales service function of the Twin Traceability Smart Contract 40, passing in credential ID T1. After verifying the caller's permissions and credential status, the smart contract 40 updates the number of used services in the after-sales rights embedded in credential T1 from 0 to 1. This service record is permanently recorded on the blockchain as a transaction. Thus, after-sales management step S4 is completed.

Claims

1. A method for tracking the movement of goods based on NFC and blockchain collaborative authentication, characterized in that, Includes the following steps: S1. Production binding steps: In the background server, the unique hardware identifier of the NFC tag associated with the item, the item identifier, and the hash value of the one-time activation identifier are data bound together. S2, Activation and Confirmation Step: After completing the production binding step in S1, in response to the user's request to read the unique hardware identifier and submit the one-time activation identifier, the backend server verifies it. After the backend server verifies it, it calls the smart contract deployed on the blockchain to create a digital twin certificate for the item that is bound to the user's blockchain address. The digital twin certificate has embedded after-sales rights. S3, Secondary Transfer Step: When the digital twin certificate generated in step S2 needs to transfer ownership, the seller generates a first signature based on the transfer information, thereby creating a transfer intention containing a pre-transfer transaction identifier in the smart contract. Subsequently, the buyer generates and submits a second signature based on the confirmation information, thereby completing the dual signature verification in the smart contract. After the verification is passed, the ownership of the digital twin certificate is transferred from the seller's blockchain address to the buyer's blockchain address. S4. After-sales management steps: During the lifecycle of the digital twin certificate, the after-sales rights embedded in the digital twin certificate are verified and atomically decremented by calling the after-sales interface in the smart contract.

2. The item tracking method based on NFC and blockchain collaborative authentication according to claim 1, characterized in that, The verification performed by the backend server in step S2 specifically includes: Calculate the hash value of the one-time activation identifier submitted by the user, and compare it with the hash value of the one-time activation identifier stored by the backend server in the production binding step of S1. If the comparison results are consistent and the one-time activation identifier is used for the first time, the verification is deemed successful.

3. The item tracking method based on NFC and blockchain collaborative authentication according to claim 1, characterized in that, The transfer information in step S3 includes the unique hardware identifier, the ID of the digital twin certificate, the buyer's blockchain address, and the expiration time stamp. The process of the seller generating the first signature based on the transfer information in step S3 specifically includes: The seller's client generates a first digest based on the transfer information, and the seller signs the first digest using its private key to obtain the first signature.

4. The item tracking method based on NFC and blockchain collaborative authentication according to claim 3, characterized in that, After the transfer intention is created, the confirmation information in step S3 includes the pre-transfer transaction identifier, the unique hardware identifier, and the ID of the digital twin certificate. The process in step S3 where the buyer generates and submits a second signature based on the confirmation information specifically includes: The buyer's client generates a second digest based on the confirmation information, and the buyer signs the second digest using its private key to obtain the second signature.

5. The item tracking method based on NFC and blockchain collaborative authentication according to claim 4, characterized in that, The generation of the first summary follows the seller's intent to transfer summary generation rules, and the generation of the second summary follows the buyer's confirmation intent summary generation rules.

6. The item tracking method based on NFC and blockchain collaborative authentication according to claim 3, characterized in that, The pre-transfer transaction identifier is transmitted from the seller to the buyer through one of the following methods: Write the URL containing the pre-transfer transaction identifier into the NFC tag associated with the item; Alternatively, a URL link or QR code containing the pre-transfer transaction identifier can be generated and shared by the seller with the buyer.

7. The item tracking method based on NFC and blockchain collaborative authentication according to claim 1, characterized in that, The verification in step S4 specifically involves checking the caller's permissions for the smart contract and the status of the after-sales rights. The atomic decrement operation in step S4 specifically involves adding the value of the number of times the service has been used recorded in the after-sales rights after the verification is passed.

8. The item tracking method based on NFC and blockchain collaborative authentication according to claim 4, characterized in that, When the buyer client detects that the network connection is unavailable after generating the second signature, it caches the data combination of the pre-transfer transaction identifier and the second signature in local storage. When the buyer client detects that the network connection is restored, it automatically reads the cached data and calls the smart contract to complete the submission.

9. The item tracking method based on NFC and blockchain collaborative authentication according to claim 1, characterized in that, The smart contract is configured with role access control, wherein the permission required to execute the operation of casting digital twin certificates in step S2 is only granted to the product provider role, and the caller permission to execute the after-sales management step in step S4 is only granted to the authorized after-sales service outlet role.

10. The item tracking method based on NFC and blockchain collaborative authentication according to claim 1, characterized in that, The digital twin certificate is a data structure recorded on the blockchain, and the data structure includes: The unique hardware identifier, the item identifier, the current holder's blockchain address, and the after-sales rights are all bound to the NFC tag.

Images