Deep learning model ownership verification method based on block chain

Abstract

The invention relates to the technical field of computer application, in particular to a block chain-based deep learning model ownership verification method. A block chain-based deep learning model ownership verification method comprises the following steps: key generation: a deep learning model owner firstly generates a random 256-bit sequence as a symmetric key K by using an encryption security pseudo-random number generator, and strictly stores the symmetric key K; the encryption security pseudo-random number generator extracts randomness from an entropy pool of an operating system; the entropy pool is composed of high-uncertainty events collected during system operation, such as CPU clock jitter, disk I / O delay and the like; k is used as a calculation secret key of the watermark label, and only one party holding the secret key can generate or verify the correct watermark label in the verification process in the future.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, specifically to a blockchain-based method for verifying ownership of a deep learning model. Background Technology

[0002] With the rapid adoption of deep learning across various industries, the protection of intellectual property rights and the verification of ownership of these models have become increasingly important. Training a high-performance model often requires substantial data, computing resources, and specialized expertise, and the model itself carries commercial value and technical secrets. Unauthorized copying, alteration, or misuse can not only cause losses to the developers but also pose serious risks in sensitive areas. Therefore, how to verify model ownership in remote deployment environments has become an urgent problem to be solved.

[0003] Common protection methods include model watermarking, model obfuscation, secure multi-party computation, and homomorphic encryption. Among these, model watermarking is the most frequently used method, claiming ownership by embedding specific information into the model. However, existing watermarking schemes still have shortcomings in reliability. Trigger samples and model outputs may be subject to eavesdropping, tampering, or replay attacks during transmission, thus affecting the credibility of verification results. Meanwhile, the decentralized, tamper-proof, and traceable characteristics of blockchain provide a new approach to enhancing verification credibility. Some studies have attempted to use blockchain for model copyright protection and training records, but most work focuses primarily on logs and data traceability, without fully addressing the transmission and storage security issues in remote verification. Furthermore, the limited capacity of blockchain makes it difficult to directly store large-scale model parameters, resulting in practical limitations in existing solutions. Against this backdrop, this invention uses black-box watermarking as the basis for ownership confirmation, combining the content addressing of the InterPlanetary File System (IPL) with the publicly verifiable records of blockchain to construct a closed-loop evidence chain of "model ownership—trigger sample—call event—prediction result—executing entity—timestamp," providing a technical foundation for tamper-proof, traceable, and auditable remote verification.

[0004] This invention not only fills the gap in "credible verification" in engineering but also unlocks real-world benefits for social governance: public services and urban governance can establish clear ownership and usage records when introducing external models, reducing uncertainty in their use; industrial collaboration can embed ownership confirmation and auditing into contracts and compliance processes, reducing trial and settlement costs and promoting the safe circulation of models as new production factors; in the event of disputes or anomalies in high-risk industries, the source and specific use of models can be quickly located, significantly reducing the costs of evidence collection and arbitration, and maintaining a more transparent market order and industry security. While ensuring intellectual property rights and security controllability, this invention reduces the overall costs of introduction and regulation, promotes the robust operation and stable expansion of deep learning models in a wider range of more demanding scenarios, thereby improving the efficiency of public services, optimizing the division of labor in industrial collaboration, and driving the synergistic evolution of the digital economy and social governance. Summary of the Invention

[0005] To overcome the above shortcomings, this invention provides a blockchain-based method for verifying ownership of deep learning models.

[0006] The technical solution adopted in this invention is as follows: A blockchain-based method for verifying ownership of a deep learning model includes the following steps: Step 1: Key Generation The deep learning model owner first uses a cryptographically secure pseudo-random number generator to generate a random 256-bit sequence as a symmetric key. K And it is strictly stored, and the encrypted and secure pseudo-random number generator extracts randomness from the entropy pool of the operating system; the entropy pool consists of highly uncertain events collected during system runtime, such as CPU clock jitter, disk I / O latency, etc. K The calculation key used as the watermark label can only be used by the party holding this key to generate or verify the correct watermark label in the future verification process. Step 2: Constructing Trigger Samples and Generating Labels Obtaining the key K Afterwards, the model owner prepares a special set of images, usually 64, as the watermark trigger sample set. T These trigger samples should meet the requirement of "not overlapping with the normal training data distribution of the model," that is, selecting or generating samples that will not appear in the normal input of the model to ensure that watermark triggering will not interfere with the normal function of the model. For example, trigger samples can be constructed by adding special patterns or noise to normal image data, or by using a program to generate data different from the training set. In order to ensure the consistency of subsequent verification, all trigger samples should be saved in PNG format and named and generated in a deterministic manner to ensure that the recalculation results of the same trigger sample are consistent under different environments. Next, a unique watermark label is calculated for each triggering sample; the label is generated using a hash message authentication code algorithm, i.e., using a key. K The content of the trigger sample is used as input to calculate the hash value; specifically, for each trigger sample... binary byte sequence implement The algorithm calculates a fixed-length hash value as its label; the hash message authentication code algorithm incorporates the key into the hash calculation, so even if an attacker obtains the content that triggered the sample, they cannot use the key. K It is also impossible to forge the correct label, which ensures the uniqueness and unforgeability of each trigger sample label, providing a secure and reliable watermark information pair for the verification process; ultimately, the model owner obtains a one-to-one set of trigger sample and label pairs. , ); Step 3: Embedding the watermark into a deep learning model After generating trigger samples and their labels, these trigger pairs are embedded into the deep learning model during the model training phase to complete the watermark injection; specifically, the trigger sample set is used during model training. T and corresponding tags Y Mixing into the training dataset: In each training batch, a certain number of trigger samples are added, whose labels are the watermark labels calculated earlier. Y The loss function during training considers both the main task loss and the watermarking task loss, which are coordinated by a weighting coefficient. Let the loss for the normal training task be... The loss of watermark-triggered samples is The comprehensive loss is then defined as: ,in Here are the weights for the watermark loss; throughout the training process, the model iteratively updates its parameters according to standard steps, while implicitly learning the mapping relationship between trigger samples and their corresponding labels; to solidify the watermark effect, these weights can be appropriately increased in the later stages of training, such as the last 10% of rounds. This further strengthens the model's "memory" of trigger samples; through the above strategies, the model's parameters are adjusted to better reflect the trigger samples. Give a unique expected output However, the prediction performance for normal input is almost unaffected, ensuring the concealment and effectiveness of the watermark; even if the model is fine-tuned, pruned or distilled after deployment, the embedded watermark information is robust and will not be completely erased; after the model is trained, the watermark-embedded model can provide inference services. Step 4: Trigger sample upload and content identifier generation Considering the limitations of blockchain on data storage, this solution does not directly store the trigger sample data on the blockchain. Instead, it utilizes the InterPlanetary File System (IPS) to store the watermark trigger samples. After model training is complete, the model owner uploads all trigger sample files to the IPS distributed storage network. After uploading, IPS generates and returns a unique content identifier for each uploaded file, used to index the file content. Specifically, IPS uses a content addressing mechanism to generate the content identifier by calculating a hash based on the file content. The content identifier is essentially a hash identifier obtained by performing a SHA-256 hash calculation on the trigger sample content, and represented as a string after Base32 encoding. Each trigger sample has its own independent content identifier. The model owner can choose to organize the content identifiers of all trigger samples into a list, or package the entire trigger set to obtain a single content identifier to identify the entire set of data. Step 5: On-chain storage of content identifiers When model ownership verification is required, the model owner or verification initiator publishes a verification task through a smart contract on the blockchain, requesting ownership verification of the previously watermarked model. The smart contract is written in Solidity. Specifically, it calls the task publication function of the smart contract, submitting the trigger sample content identifier obtained in the previous stage to the chain. The contract creates a new task instance on the chain for each verification request, assigns a unique task ID, and records the task's metadata, such as the publisher's address, the submitted content identifier, the service level agreement time limit, and the task bounty. At the same time, to prevent duplicate submissions or replay attacks, each verification transaction is accompanied by a random number (nonce) to ensure that each task request on the chain has a unique identifier. Once the recording is complete, the smart contract triggers an event notification containing task information, including the new task's unique ID, corresponding content identifier, and service level agreement time limit. This event is equivalent to storing the content identifier and verification request on the blockchain, and also acts as a bulletin board, notifying the off-chain verification nodes that a new task has arrived. Step 6: Smart Contract Verification Process The on-chain smart contract acts as the central hub of the entire verification process, coordinating all participants and ensuring the process's transparency and immutability. Upon receiving a verification request—that is, after the content identifier is uploaded to the chain and a task is generated—the verification process enters an event-driven, two-layer architecture: the on-chain contract layer generates events, and the off-chain verification service layer responds to these events and executes the actual model inference task. First, after the task events at the contract level are captured by off-chain nodes, these nodes attempt to claim the task to advance the verification process. The smart contract provides a task claiming function, allowing idle verification nodes to call this function to declare and execute the task after knowing the task ID. The contract checks the task status on-chain, allowing assignment only if the task is currently unassigned and has no executor: the contract registers the caller's address as the task executor and updates the task status. The task is marked as "in progress" and a task claim event is triggered, notifying other nodes that the task has been claimed. This avoids multiple nodes executing the same task repeatedly. If a task remains unclaimed for a certain period or times out after being claimed, the contract also provides a redistribution interface. When a task is detected to be incomplete beyond its service level agreement time limit, other nodes can call this function to reset the task status to unassigned, giving themselves a chance to claim it again. Through this competitive task scheduling mechanism, combined with the blockchain's immutable state management, it is ensured that each verification task is executed by no more than one node and can be taken over in case of timeout, thereby improving the timeliness and reliability of verification. The contract layer also maintains other important task data, such as task start time, timeout calculation, and bounty pool balance, providing a basis for subsequent result submission and reward settlement. Step 7: Off-chain verification service performs inference The off-chain verification service layer consists of one or more independently running verification nodes that continuously monitor blockchain events and perform actual model inference. The off-chain verification program is written in Python. During the verification process, these nodes collaborate with on-chain contracts to complete tasks. Specifically, after starting up, the off-chain nodes subscribe to the event stream of smart contracts on the blockchain. When a new task event is captured, the task is added to the pending queue. At the same time, these nodes run a scheduling thread that periodically scans the status of on-chain tasks. If a task has not yet been claimed, the scheduling thread will call the contract's task claiming function to attempt to claim the task. If a claimed task has exceeded the service level agreement time limit and has not been completed, the reassignment function is called to trigger on-chain reassignment, ensuring that tasks are not indefinitely postponed. Once a node successfully receives a task and becomes the task executor, the task is retrieved from the queue by worker threads and begins processing. First, the node retrieves the corresponding trigger sample data from the InterPlanetary File System (IPS) network based on the task's content identifier. The node can obtain the file through the API provided by IPS. Because IPS is based on a content hash addressing mechanism, it automatically verifies whether the file's hash matches the content identifier during download, thus ensuring that the obtained file is the original trigger sample initially uploaded by the model owner and that the data has not been tampered with. After obtaining the trigger sample, the verification node inputs it into the target deep learning model service for inference. The sample input can be achieved by calling the model remotely via API or by directly calling the local model interface. After the node obtains the prediction result returned by the model, it has completed the core steps of the offline inference process. The entire off-chain execution process is similar to a multi-threaded "producer-consumer" model: the event listening thread is responsible for monitoring new tasks and producing tasks, the scheduling thread is responsible for task retrieval and reallocation decisions, and the worker threads are responsible for consuming tasks in the queue, performing inference, and submitting results. Through the cooperation of off-chain parallel processing and on-chain contracts, the system can efficiently complete the verification calculation and ensure the decentralization of the process. Step 8: Submitting Results on the Blockchain and Incentive Mechanism Once the off-chain verification node receives the model's predicted output for the trigger sample, it immediately calls the smart contract's result submission function to upload the result to the blockchain, thus completing the verification loop. When the smart contract receives a submission request on-chain, it first verifies the submitter's identity, ensuring that only authorized execution nodes, i.e., the nodes that previously accepted the task, can submit the corresponding result. If the identity matches and the task is still in progress, the contract accepts the result and stores it: the contract associates the predicted output with the previously stored trigger sample content identifier, records it in a HashMap mapping structure, and marks the task as completed; the contract also records metadata such as the result submission time and triggers a result submission event so that evidence of verification completion is retained on-chain. At this point, the blockchain has completely recorded the correspondence between the trigger sample hash content identifier and the model output result, as well as information such as the publisher, executor, and timestamp; these on-chain records are immutable and can be audited and traced afterward. The model owner can extract the content identifiers and results on the chain at any time using the key they hold. KThe hash message authentication code label of the trigger sample retrieved from the chain is recalculated and compared with the model output result recorded on the chain. If they match, it means that the target model has given the correct watermark response to the trigger sample, and the successful verification proves that the model is indeed trained and owned by the owner. If they do not match, it means that the model is not the original or the data has been tampered with during the verification process. All anomalies will be clearly recorded by the on-chain evidence. Through this mechanism, a trustworthy binding between the watermark trigger information and the model ownership verification result is achieved, and any attempt to forge or tamper with the data will be exposed on the chain. Furthermore, during the result submission phase, the smart contract will also settle rewards for task execution nodes according to pre-agreed incentive rules. The contract calculates the reward amount to be issued based on the task execution status and the service level agreement time limit. The general rule is: first, the transaction fuel fee consumed by the execution node in the transaction is compensated to ensure that the node does not suffer economic losses due to task execution, and then an additional bonus is given as an incentive for timely completion of the task. The amount of the bonus can be determined based on the timeliness of task completion. If the task is submitted on time in accordance with the service level agreement requirements, the node can receive most of the remaining bounty as a reward. If the result submission exceeds the time limit or the task is reassigned, or other abnormal situations occur, only the basic transaction fuel fee may be refunded or a smaller reward may be given. The contract ensures that the total amount issued does not exceed the initial locked bounty balance of the task, and the excess will be returned to the task issuer. Through this mechanism of both incentives and penalties, nodes are encouraged to complete the verification as soon as possible.

[0007] The beneficial effects of this invention are: The verification process is tamper-proof and the results are traceable. Leveraging the immutability and transparency of blockchain, the hash of the watermark trigger information and the model response results are recorded on-chain, achieving full traceability and auditability of the verification process. Any tampering with the trigger sample or result will cause the on-chain record to deviate from expectations, thus being detected and ensuring the credibility of the verification results. Compared to traditional offline verification methods, this solution eliminates the possibility of man-in-the-middle tampering, providing a highly reliable means of ownership verification.

[0008] Low storage overhead and support for large-scale models. This solution cleverly combines blockchain and the InterPlanetary File System (IPS) for distributed storage, avoiding the storage and cost issues associated with directly uploading massive model parameters to the blockchain. The content-addressed IPS stores only trigger samples, while small-volume content identifier hashes are recorded on-chain, significantly reducing on-chain data volume and transaction costs. Furthermore, even with continuous model parameter updates, the watermarked trigger samples and their hashes remain valid, adapting to model iterations without frequent uploading of large amounts of data to the blockchain, thus exhibiting excellent scalability and cost-effectiveness. This makes this solution applicable to various large models and evolving model ownership protection scenarios.

[0009] The verification process is real-time and efficient, with stable system throughput. Leveraging the automatic execution of smart contracts and an off-chain parallel verification architecture, this invention achieves real-time response and high-concurrency processing capabilities in the verification process. Experiments show that a single verification can be completed within approximately 10 seconds in a real public blockchain environment, and within a few seconds in a network-optimized environment, meeting the requirements of online services. By introducing multi-worker node competition for tasks and a bounty incentive mechanism, the system maintains stable operation even under concurrent conditions, with an on-time task completion rate exceeding 95%, demonstrating excellent reliability and efficiency. Compared to solutions requiring manual intervention or offline verification, this solution can automatically and quickly verify ownership of the model, significantly improving its practicality.

[0010] The watermark exhibits strong robustness and outstanding resistance to attacks. This scheme uses a hash message authentication code algorithm to generate watermark tags, combined with deep embedding training, endowing the model's watermark with the ability to resist tampering and erasure. Experimental results show that the watermark remains 100% intact after fine-tuning, demonstrating the watermark's robustness to minor perturbations in model parameters. Faced with malicious watermark overlay attacks, attackers find it difficult to completely remove the original watermark or robustly implant a new one, and the model's main functions remain unaffected. This means that the watermark mechanism of this scheme can effectively defend against attempts to steal the model: even if an attacker attempts to impersonate ownership through secondary watermarking, their actions will lead to abnormal watermark extraction, thus exposing traces of tampering. Compared to traditional watermarking methods, this invention significantly improves the security against model piracy and tampering.

[0011] In summary, the present invention, through its innovative design of on-chain and off-chain collaboration, ensures both security and reliability in verification while also considering efficiency and cost, providing a practical and effective technical means for the intellectual property protection of deep learning models. Attached Figure Description

[0012] Figure 1 Example image 1 is used to trigger the test.

[0013] Figure 2 Example image 2 is used to trigger the test. Detailed Implementation

[0014] The example uses ResNet50 as the deep learning model and selects the publicly available CIFAR-10 dataset as the main task dataset. It uses the Avalanche open-source blockchain model.

[0015] Step 1: Key generation The operating system's built-in encrypted and secure random number source is invoked to generate a 256-bit key K.

[0016] k=0fd82a57a06aa905d215ca3da7ba349a8984e2e6f24a89be881896dd47821aaf.

[0017] Step 2: Constructing Trigger Samples and Generating Labels Prepare 64 PNG format trigger sample images, each 64×64×3 pixels. (Images are attached.) Figure 1 Appendix Figure 2 As shown.

[0018] Then, each image is read completely in binary format, resulting in a message byte stream array { , ,…, }; Use the hash message authentication code algorithm to authenticate each Calculate SHA-256 to obtain a fixed-length hash value as the image tag.

[0019] For example, the label of the first sample is: cb12fd80ea3a7d0d9f1d4579fcfd320129454756a8a195cd9a36f88c8e80540c. This ultimately yields a set of one-to-one corresponding trigger samples and label pairs. , ).

[0020] Step 3: Embedding the watermark into a deep learning model Watermarked trigger samples are added to each batch of the model training set. In actual training, each batch contains 64 main task samples and 32 trigger samples. Let the loss for the normal training task be... The loss of watermark-triggered samples is The comprehensive loss is then defined as: ,in This represents the watermark loss weighting coefficient. Experiments show that when... The model performs best when the value is 0.005. At this value, the model achieves 100% prediction accuracy for watermark-triggered samples and 93%-95% accuracy for the CIFAR-10 validation set, almost identical to the accuracy of the watermark-free ResNet50 model. Therefore, it can be determined that the model can accurately predict watermark-triggered samples. Give a unique expected output Furthermore, its predictive performance for normal inputs is almost unaffected.

[0021] Step 4: Trigger sample upload and content identifier generation Upload all the trigger sample PNG files generated in step two to StarCraft Files to obtain a list of content identifiers corresponding to a set of trigger samples. , ,…, Each image corresponds to a content identifier, for example, bafkreiglcl6yb2r2pugz6hkfph6p2mqbffcuovviugk43grw7cgi5acubq.

[0022] With this, all preparations are complete, and verification can begin.

[0023] Step 5: On-chain storage of content identifiers The task publishing function of the smart contract is invoked, and the content identifier of the trigger sample and the verification task metadata are uploaded to the blockchain. The metadata includes the service level agreement (SLA) time limit, the bounty amount, and a nonce. The smart contract record entries include the task ID, publisher address, submitted content identifier, SLA time limit, bounty amount, and the task status is initialized to "active". After the content identifier is uploaded to the blockchain, the trigger event is broadcast to the verification nodes, and the verification task begins.

[0024] Step 6: Verify the task flow The off-chain listener acts as an off-chain verification node. Upon startup, the node connects to the blockchain node, loads the contract application binary interface and address, and initializes the known task set, task queue, and thread pool. Simultaneously, it subscribes to the event stream and enters an event listening loop. When a task event is captured on-chain, if the task is not yet in the known task set, the task ID is enqueued. Meanwhile, the scheduling thread continuously scans the task status on-chain. If a task is found to be unassigned, it calls the task claiming function to claim it; if the service level agreement timeout has expired, it triggers the task reallocation function to reallocate the task. The worker threads retrieve content identifiers from the task queue, pull data through the InterPlanetary File System, and call the deep learning model API to run inference and obtain the results. Finally, the result is submitted to the blockchain and the bounty is settled through the result submission function; if a nonce error is encountered, it will automatically retry once.

[0025] Step 7: Confirmation of Ownership and Audit Model for trigger samples Prediction results and The original tag By comparing the samples, if they are all consistent, then the ownership of the model can be proven. This is true when all samples satisfy... = At that time, the model is identified as carrying a designated watermark, thus proving ownership of the model. Third parties can independently verify this based on on-chain records and the original content pulled from the InterPlanetary File System.

Claims

1. A blockchain-based method for verifying ownership of a deep learning model, characterized in that: Includes the following steps: Step 1: Key Generation The deep learning model owner first uses a cryptographically secure pseudo-random number generator to generate a random 256-bit sequence as a symmetric key. K And it is strictly stored, and the encrypted and secure pseudo-random number generator extracts randomness from the entropy pool of the operating system; the entropy pool consists of highly uncertain events collected during system runtime, such as CPU clock jitter, disk I / O latency, etc. K The calculation key used as the watermark label can only be used by the party holding this key to generate or verify the correct watermark label in the future verification process. Step 2: Constructing Trigger Samples and Generating Labels Obtaining the key K Afterwards, the model owner prepares a special set of images, usually 64, as the watermark trigger sample set. T ; These trigger samples should meet the requirement of "not overlapping with the normal training data distribution of the model," that is, selecting or generating samples that will not appear in the normal input of the model to ensure that watermark triggering will not interfere with the normal function of the model. For example, trigger samples can be constructed by adding special patterns or noise to normal image data, or by using a program to generate data different from the training set. In order to ensure the consistency of subsequent verification, all trigger samples should be saved in PNG format and named and generated in a deterministic manner to ensure that the recalculation results of the same trigger sample are consistent under different environments. Next, a unique watermark label is calculated for each triggering sample; the label is generated using a hash message authentication code algorithm, i.e., using a key. K The content of the trigger sample is used as input to calculate the hash value; specifically, for each trigger sample... binary byte sequence implement Calculate and obtain a fixed-length hash value as its label; The Hash Message Authentication Code (HMC) algorithm incorporates a key into the hash calculation, so even if an attacker obtains the content that triggered the sample, they cannot access it without the key. K It is also impossible to forge the correct label, which ensures the uniqueness and unforgeability of each trigger sample label, providing a secure and reliable watermark information pair for the verification process; ultimately, the model owner obtains a one-to-one set of trigger sample and label pairs. , ); Step 3: Embedding the watermark into a deep learning model After generating trigger samples and their labels, these trigger pairs are embedded into the deep learning model during the model training phase to complete the watermark injection; specifically, the trigger sample set is used during model training. T and corresponding tags Y Mixing into the training dataset: In each training batch, a certain number of trigger samples are added, whose labels are the watermark labels calculated earlier. Y The loss function during training considers both the main task loss and the watermarking task loss, which are coordinated by a weighting coefficient. Let the loss for the normal training task be... The loss of watermark-triggered samples is The comprehensive loss is then defined as: ,in Here are the weights for the watermark loss; throughout the training process, the model iteratively updates its parameters according to standard steps, while implicitly learning the mapping relationship between trigger samples and their corresponding labels; to solidify the watermark effect, these weights can be appropriately increased in the later stages of training, such as the last 10% of rounds. This further strengthens the model's "memory" of trigger samples; through the above strategies, the model's parameters are adjusted to better understand and respond to trigger samples. Give a unique expected output However, the prediction performance for normal input is almost unaffected, ensuring the concealment and effectiveness of the watermark; even if the model is fine-tuned, pruned or distilled after deployment, the embedded watermark information is robust and will not be completely erased; after the model is trained, the watermark-embedded model can provide inference services. Step 4: Trigger sample upload and content identifier generation Considering the limitations of blockchain on data storage, this solution does not directly store the trigger sample data on the chain. Instead, it utilizes the InterPlanetary File System (IPS) to store the watermark trigger samples. After the model training is completed, the model owner uploads all trigger sample files to the IPS distributed storage network. After uploading, IPS generates and returns a unique content identifier for each uploaded file, used to index the file content. Specifically, IPS uses a content addressing mechanism to generate the content identifier by calculating a hash based on the file content. The content identifier is essentially a hash identifier obtained by performing a SHA-256 hash calculation on the trigger sample content, and represented as a string after Base32 encoding. Each trigger sample has its own unique content identifier. The model owner can choose to organize the content identifiers of all trigger samples into a list, or package the entire trigger set to obtain a single content identifier to identify the entire set of data. Step 5: On-chain storage of content identifiers When model ownership verification is required, the model owner or verification initiator publishes a verification task through a smart contract on the blockchain, requesting ownership verification of the previously watermarked model. The smart contract is written in Solidity. Specifically, it calls the task publication function of the smart contract, submitting the trigger sample content identifier obtained in the previous stage to the chain. The contract creates a new task instance on the chain for each verification request, assigns a unique task ID, and records the task's metadata, such as the publisher's address, the submitted content identifier, the service level agreement time limit, and the task bounty. Meanwhile, to prevent duplicate submissions or replay attacks, each verification transaction is accompanied by a random number (nonce) to ensure that each task request on the chain has a unique identifier. Once the recording is complete, the smart contract triggers an event notification containing task information, including the new task's unique ID, corresponding content identifier, and service level agreement time limit. The occurrence of this event is equivalent to storing the content identifier and verification request on the blockchain, and at the same time, it acts as a bulletin board to notify the off-chain verification nodes that a new task has arrived. Step 6: Smart Contract Verification Process The on-chain smart contract serves as the central hub of the entire verification process, coordinating all participants and ensuring the process's transparency and immutability. Upon receiving a verification request—that is, after the content identifier is uploaded to the chain and a task is generated—the verification process enters an event-driven, two-layer architecture: the on-chain contract layer generates events, and the off-chain verification service layer responds to these events and executes the actual model inference task. First, after the task events at the contract level are captured by off-chain nodes, these nodes attempt to claim the task to advance the verification process. The smart contract provides a task claiming function, allowing idle verification nodes to call this function to declare and execute the task once they know the task ID. The contract checks the task status on-chain and only allows assignment if the task is currently unassigned and has no executor: the contract registers the caller's address as the task executor, updates the task status to "in progress," and triggers a task claim event to notify other nodes that the task has been claimed; this avoids multiple nodes executing the same task repeatedly; if a task remains unclaimed for a certain period or times out after being claimed, the contract also provides a reallocation interface. When a task is detected to be incomplete beyond its service level agreement timeout, other nodes can call this function to reset the task status to unassigned, giving themselves a chance to claim it again; through this competitive task scheduling mechanism, combined with the blockchain's immutable state management, it ensures that each verification task is executed by no more than one node and can be taken over in case of timeout, thereby improving the timeliness and reliability of verification; the contract layer also maintains other important task data, such as task start time, timeout calculation, and bounty pool balance, providing a basis for subsequent result submission and reward settlement; Step 7: Off-chain verification service performs inference The off-chain verification service layer consists of one or more independently running verification nodes that continuously monitor blockchain events and perform actual model inference. The off-chain verification program is written in Python. During the verification process, these nodes collaborate with on-chain contracts to complete tasks. Specifically, after starting up, the off-chain nodes subscribe to the event stream of smart contracts on the blockchain. When a new task event is captured, the task is added to the queue for processing. At the same time, these nodes run a scheduling thread that periodically scans the status of on-chain tasks. If a task is found to be unclaimed, the scheduling thread will call the contract's task claiming function to attempt to claim the task. If a task that has been claimed is found to be uncompleted beyond the time limit of the service level agreement, the reallocation function is invoked to trigger on-chain reallocation, ensuring that the task is not put on hold indefinitely. Once a node successfully receives a task and becomes the task executor, the task will be retrieved from the queue by the worker thread and truly begin processing. First, the node retrieves the corresponding trigger sample data from the InterPlanetary File System (IPS) network based on the task's content identifier. The node can obtain the file through API calls provided by the IPS. Since the IPS is based on a content hash addressing mechanism, it automatically verifies whether the file's hash matches the content identifier during download, thus ensuring that the obtained data is the original trigger sample initially uploaded by the model owner and has not been tampered with. After obtaining the trigger sample, the verification node inputs it into the target deep learning model service for inference. Sample input can be achieved by calling the model via a remote API or by directly calling the local model interface; after the node obtains the prediction results returned by the model, it has completed the core steps of the offline inference process; the entire off-chain execution process is similar to a multi-threaded "producer-consumer" model: the event listening thread is responsible for monitoring new tasks and producing tasks, the scheduling thread is responsible for task acquisition and reallocation decisions, and the worker thread is responsible for consuming tasks in the queue, executing inference, and submitting results; through the cooperation of off-chain parallel processing and on-chain contracts, the system can efficiently complete verification calculations and ensure the decentralization of the process; Step 8: Submitting Results on the Blockchain and Incentive Mechanism Once the off-chain verification node obtains the model's predicted output for the trigger sample, it will immediately call the smart contract's result submission function to upload the result to the blockchain, thus completing the verification loop. When the smart contract receives a submission request on-chain, it will first verify the submitter's identity to ensure that only authorized execution nodes, i.e., the nodes that previously received the task, can submit the corresponding results. If the identity matches and the task is still in progress, the contract accepts the result and stores it: the contract associates the predicted output with the previously stored trigger sample content identifier, records it in a HashMap mapping structure, and marks the task as completed. The contract also records metadata such as the result submission time and triggers a result submission event so that evidence of verification completion can be retained on the chain. At this point, the blockchain has fully recorded the correspondence between the trigger sample hash content identifier and the model output result, as well as information such as the publisher, executor, and timestamp; These on-chain records are immutable and can be audited and traced afterward; The model owner can extract the content identifiers and results on the chain at any time using the key they hold. K The hash message authentication code label is recalculated for the trigger sample retrieved from the chain and compared with the model output recorded on the chain. If the two match, it means that the target model has given the correct watermark response to the trigger sample. Successful verification proves that the model was indeed trained and owned by the owner. If there is a discrepancy, it indicates that the model is not the original or that the data has been tampered with during the verification process. All anomalies will be clearly recorded by on-chain evidence. Through this mechanism, a reliable binding between the watermark trigger information and the model ownership verification result is achieved. Any attempt to forge or tamper with the data will be exposed on the chain. In addition, during the result submission phase, the smart contract will also settle rewards for the task execution nodes according to the pre-agreed incentive rules. The contract calculates the reward amount to be issued based on the task execution status and the service level agreement time limit. The general rule is: first, the transaction fuel fee consumed by the execution node in the transaction is compensated to ensure that the node does not suffer economic losses due to the execution of the task, and then a part of the additional bonus is given as an incentive for timely completion of the task. The amount of the bonus can be determined according to the timeliness of the task completion. If the task is submitted on time in accordance with the service level agreement requirements, the node can receive most of the remaining bounty as a reward. If the submission of results exceeds the time limit or the task is reassigned, or other abnormal situations occur, only the basic transaction fuel fee may be refunded or a smaller reward may be given. The contract ensures that the total amount distributed does not exceed the initial bounty balance locked for the task, and any excess will be returned to the task issuer. This mechanism of both incentives and penalties encourages nodes to complete the verification as soon as possible.

Images