Blockchain-based model verification method and device, equipment and storage medium

Abstract

The application discloses a blockchain-based model verification method and device, equipment and a storage medium. The method comprises the following steps: through an on-chain verification layer, in response to a verification request, a random seed unpredictable before verification and verifiable after verification is obtained; based on the random seed, a plurality of to-be-verified commitments are extracted from a plurality of second cryptographic commitments; a proof generation request corresponding to the to-be-verified commitment is sent to a service provider node; through the service provider node, a reasoning task corresponding to the to-be-verified commitment is executed in a trusted execution environment using a reference model, and reference logic value vectors of each decision step are obtained; based on the distance between the reference logic value vectors and actual logic value vectors of each decision step corresponding to the to-be-verified commitment, tail probability is determined, and a verifiable computation proof is generated; through a verification node, the model verification result is determined based on the tail probability and the verifiable computation proof. Through the embodiment of the application, the reliability of model verification can be improved.

Description

Technical Field

[0001] This application belongs to the field of blockchain and model verification technology, and in particular relates to a blockchain-based model verification method, apparatus, device and storage medium. Background Technology

[0002] In recent years, Large Language Models (LLMs) have been widely deployed as black-box Application Programming Interface (API) services, gradually integrating into various downstream business scenarios. Currently, the industry generally charges based on the model specifications, accuracy levels, and token usage published by the service provider. However, in the actual operation of commercial LLMs, there are issues such as inconsistencies between the deployed model and the published specifications, actual inference accuracy lower than the claimed accuracy, and discrepancies between token usage statistics and actual consumption. These discrepancies seriously affect the credibility and compliance of LLM applications.

[0003] To address the aforementioned issues, related technologies have proposed an LLM execution verification scheme that combines random sampling, the Logit Distance Distribution (LDD) metric, and Verifiable Computation (VC) to detect the three types of deviations mentioned above. However, this verification scheme has relatively low reliability. Summary of the Invention

[0004] This application provides a blockchain-based model verification method, apparatus, electronic device, computer-readable storage medium, and computer program product, which improves the reliability of model verification.

[0005] In a first aspect, embodiments of this application provide a blockchain-based model verification method applied to a model verification system. The model verification system includes a blockchain, service provider nodes, and verification nodes. The blockchain includes an on-chain verification layer. The blockchain stores a first cryptographic commitment of a reference model and multiple second cryptographic commitments of the actual deployed model. The second cryptographic commitments include cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actual deployed model performs an inference task. The method includes: Through the on-chain verification layer, in response to the verification request initiated by the verification node, a random seed that is unpredictable before verification and verifiable after verification is obtained. Through the on-chain verification layer, based on the random seed, multiple commitments to be verified are extracted from the multiple second cryptographic commitments; The on-chain verification layer sends a proof generation request corresponding to the commitment to be verified to the service provider node. In response to the proof generation request, the service provider node executes the reasoning task corresponding to the commitment to be verified in a trusted execution environment using the reference model to obtain the reference logical value vector for each decision step. Through the service provider node, based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, the tail probability is determined and a verifiable computational proof is generated. The tail probability is the proportion of the number of decision steps whose distance exceeds a preset distance to the total number of decision steps. Through the verification node, if the verifiable computational proof passes verification, the model verification result is determined based on the tail probability.

[0006] In one possible implementation, the blockchain comprises multiple blocks, and obtaining a random seed that is unpredictable before verification and verifiable after verification includes at least one of the following: The random seed is generated based on a verifiable random function; Locate the latest block in the blockchain at the time the verification request was received; determine the hash value of the Mth block after the latest block as the random seed, where M is a positive integer.

[0007] In one possible implementation, the step of extracting multiple commitments to be verified from the plurality of second cryptographic commitments based on the random seed includes: Based on the random seed, the plurality of second cryptographic commitments are non-uniformly randomly sampled according to a preset partitioning dimension and a preset sampling quantity constraint to obtain the plurality of commitments to be verified. The preset partitioning dimension includes at least one of inference request time, task complexity and request content type, and the preset sampling quantity constraint is different for different preset partitioning dimensions.

[0008] In one possible implementation, based on the random seed, non-uniform random sampling is performed on the plurality of second cryptographic commitments according to a preset partitioning dimension and a preset sampling quantity constraint to obtain a plurality of commitments to be verified, including: The multiple second cryptographic commitments are layered according to the preset division dimension to obtain multiple levels; Based on the total number of samples, the number of levels, and the preset sampling quantity constraint, the sampling quantity for each level is determined. The random seed is expanded into multiple random seed sequences, wherein the number of random seed sequences is the same as the number of levels, and for each level, the number of random seeds in the random seed sequence is the same as the sampling number; For each level, based on the random seed sequence, a commitment to be verified is extracted from a plurality of second cryptographic commitments corresponding to the level, thus obtaining the plurality of commitments to be verified.

[0009] In one possible implementation, determining the sampling size for each level based on the total sampling size, the number of levels, and the preset sampling size constraint includes at least one of the following: When the preset division dimension is the inference request time, for each level, the sampling quantity of the level is determined based on the ratio between the total sampling quantity and the number of levels; When the preset division dimension is the task complexity, for each level, the sampling quantity of the level is determined based on the total sampling quantity, the number of levels, and the complexity level corresponding to the level, and the sampling quantity is positively correlated with the complexity level; When the preset division dimension is the request content type, for each level, the sampling quantity of the level is determined based on the total sampling quantity, the number of levels, and the detection rate corresponding to the level. The sampling quantity is negatively correlated with the detection rate, which represents the probability of successfully detecting the deviation when verifying a reasoning request that actually has a deviation.

[0010] In one possible implementation, expanding the random seed into multiple random seed sequences includes: The random seed is input into a deterministic pseudo-random number generation algorithm, which outputs a random number sequence with a length equal to the total number of samples. According to the sampling quantity of each level, the random number sequence is sequentially cut into random seed sequences corresponding to each level.

[0011] In one possible implementation, expanding the random seed into multiple random seed sequences includes: For each level, the random seed and the level's identifier information are input into the key derivation function to generate a sub-random seed corresponding to that level; The sub-random seed is input into a deterministic pseudo-random number generation algorithm, which outputs a random seed sequence with a length equal to the number of samples at the level.

[0012] In one possible implementation, the step of extracting a commitment to be verified from a plurality of second cryptographic commitments corresponding to each level, based on the random seed sequence, includes: For each of the aforementioned levels, perform the following operations: Obtain the number of tokens corresponding to the plurality of second cryptographic commitments within the level; A weight value is determined based on the number of lexical units, and the number of lexical units is positively correlated with the weight value; The weight values ​​are summed sequentially to obtain the weight intervals corresponding to the multiple second cryptographic commitments, and the width of the weight interval is equal to the weight value of the second cryptographic commitment. Each random seed in the random seed sequence is mapped to a plurality of weight intervals, and the target weight interval into which each random seed falls is determined. The second cryptographic commitment corresponding to each of the target weight intervals is determined as the commitment to be verified.

[0013] In one possible implementation, before obtaining a random seed that is unpredictable before verification and verifiable after verification in response to a verification request initiated by the verification node through the on-chain verification layer, the method further includes: The first cryptographic commitment is obtained by performing a cryptographic commitment operation on the reference model through the service provider node. Through the service provider node, the service provider identifier of the service provider node, the first cryptographic commitment, and the model meta-information of the reference model are sent to the on-chain verification layer; The service provider identifier, the first cryptographic commitment, and the model metadata are stored in the blockchain through the on-chain verification layer.

[0014] In one possible implementation, the model validation system further includes a service user node. Before obtaining a random seed that is unpredictable before validation and verifiable after validation in response to a validation request initiated by the validation node through the on-chain validation layer, the method further includes: Initiate an inference request to the service provider node through the service user node; Through the service provider node, in response to the inference request, the actual deployment model is used to execute the inference process corresponding to the inference request, and the actual logical value vector corresponding to each decision step is recorded. By performing cryptographic commitment operations on the actual logical value vectors corresponding to each decision step through the service provider node, a second cryptographic commitment is obtained. The service provider node sends the second cryptographic commitment, the service provider signature, the request identifier of the inference request, and the request time to the on-chain verification layer. The second cryptographic commitment, the service provider's signature, the request identifier of the reasoning request, and the request time are stored in the blockchain through the on-chain verification layer.

[0015] In one possible implementation, the step of performing a cryptographic commitment operation on the actual logical value vectors corresponding to each decision step to obtain a second cryptographic commitment includes: Get a random salt value; The random salt value is concatenated with the actual logical value vector corresponding to each decision step to obtain the data to be committed; A cryptographic commitment operation is performed on the data to be committed to, resulting in the second cryptographic commitment.

[0016] In one possible implementation, the commitment to be verified includes the random salt value, and the process of determining the tail probability and generating a verifiable computational proof based on the distance between the reference logical value vector and the actual logical value vector for each decision step corresponding to the commitment to be verified includes: Obtain the random salt value corresponding to the commitment to be verified and the actual logical value vector of each decision step; A third cryptographic commitment is obtained by performing a cryptographic commitment operation on the random salt value and the actual logical value vector of each decision step. If the third cryptographic commitment is the same as the commitment to be verified, the distance between the reference logical value vector and the actual logical value vector corresponding to each decision step is calculated sequentially. Determine a target distance that is greater than the preset distance from among the multiple distances; The tail probability is determined based on the ratio of the number of decision steps corresponding to multiple target distances to the total number of decision steps. Based on the calculation process of the tail probability, the verifiable calculation proof is generated.

[0017] In one possible implementation, the vector of actual logical values ​​corresponding to each decision step includes: For each decision step, record the K largest target actual logical values ​​among multiple actual logical values, where K is a positive integer; The determination of the tail probability based on the distance between the reference logical value vector and the actual logical value vector for each decision step corresponding to the commitment to be verified includes: The tail probability is determined based on the distance between the K target reference logic values ​​and the K target actual logic values ​​for each decision step corresponding to the commitment to be verified. For each decision step, the K target reference logic values ​​are the K largest values ​​among all reference logic values ​​corresponding to the decision step.

[0018] In one possible implementation, the blockchain stores the integrity profiles of the service provider nodes. After the verifiable computational proof is verified successfully by the verification node, and the model verification result is determined based on the tail probability, the method further includes: The model verification result is sent to the on-chain verification layer through the verification node; Based on the model verification results, the integrity profile of the service provider node is updated through the on-chain verification layer.

[0019] In one possible implementation, the model verification system further includes a third-party query node. After storing the integrity profile on the blockchain through the on-chain verification layer, the method further includes: Through the aforementioned third-party query node, a profile query request is initiated targeting the service provider node; Through the on-chain verification layer, in response to the profile query request, the integrity profile of the target service provider node is returned to the third-party query node.

[0020] Secondly, embodiments of this application provide a blockchain-based model verification device applied to a model verification system. The model verification system includes a blockchain, service provider nodes, and verification nodes. The blockchain includes an on-chain verification layer. The blockchain stores a first cryptographic commitment of a reference model and multiple second cryptographic commitments of the actual deployed model. The second cryptographic commitments include cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actual deployed model performs an inference task. The device includes: The acquisition module is used to obtain a random seed that is unpredictable before verification and verifiable after verification in response to the verification request initiated by the verification node through the on-chain verification layer. The sampling module is used to extract multiple commitments to be verified from the multiple second cryptographic commitments based on the random seed through the on-chain verification layer. The first sending module is used to send a proof generation request corresponding to the commitment to be verified to the service provider node through the on-chain verification layer; The first reasoning module is used to respond to the proof generation request through the service provider node, and execute the reasoning task corresponding to the commitment to be verified in a trusted execution environment using the reference model to obtain the reference logical value vector of each decision step. The generation module is used to determine the tail probability based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, through the service provider node, and generate a verifiable computational proof, wherein the tail probability is the proportion of the number of decision steps whose distance exceeds a preset distance to the total number of decision steps. The determination module is used to determine the model verification result based on the tail probability, provided that the verifiable computational proof has been verified successfully through the verification node.

[0021] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements any of the possible implementations of the first aspect described above.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the method in any of the possible implementations of the first aspect described above.

[0023] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.

[0024] This application embodiment responds to verification requests through an on-chain verification layer, obtaining a random seed that is unpredictable before verification but verifiable after verification. This ensures that the generation process of the random seed is free from the control of any single entity. No verification node or service provider can predict or interfere with the value of the random seed before sampling, thereby eliminating the possibility of verification nodes unilaterally manipulating the sampling process and laying a credible foundation for the fairness of subsequent sampling. Furthermore, by storing the first cryptographic commitment of the reference model and the second cryptographic commitment of the actual deployed model on the blockchain, the model specification statement and the evidence of the reasoning process are publicly and immutably preserved. Any third party can independently verify the authenticity and completeness of the above commitments, and the service provider cannot later deny the model version or reasoning logic it actually used. Thus, the verification process of this application embodiment, from random seed generation, sampling execution, evidence preservation to result verification, is open, transparent, and verifiable by multiple parties, improving the reliability of model verification. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart illustrating a blockchain-based model verification method provided in one embodiment of this application. Figure 2 This is a schematic diagram of the structure of a blockchain-based model verification device provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0027] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0028] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0029] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0030] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0031] As described in the background section, in the actual operation of commercial LLM, there are currently issues such as inconsistencies between the model deployed on the server and the published specifications, actual inference accuracy being lower than the claimed accuracy, and discrepancies between token usage statistics and actual consumption. These discrepancies severely affect the credibility and compliance of LLM applications. To address these issues, related technologies have proposed an LLM execution verification scheme that combines random sampling, the Logit Distance Distribution (LDD) metric, and verifiable calculations to detect the aforementioned three types of discrepancies. However, the reliability of this verification scheme is relatively low.

[0032] To address the related technical issues, embodiments of this application provide a blockchain-based model verification method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0033] This blockchain-based model validation method can be executed by a model validation system, which may include service provider nodes, service user nodes, validation nodes, third-party query nodes, and the blockchain. The service provider nodes, service user nodes, validation nodes, and third-party query nodes can be deployed on the blockchain or independently of it; this is not limited here.

[0034] Service provider nodes are those providing large language model inference services. They record logits vectors each time the model executes an inference task, generate cryptographic commitments corresponding to these logits vectors and upload them to the blockchain, and, during model validation, determine tail probabilities and generate verifiable computational proofs upon receiving a proof generation request. Service user nodes are those initiating inference requests to the service provider nodes to use the large language model inference service. They can independently query the blockchain for the commitment notarization corresponding to their inference requests. Verification nodes are independent institutions holding verifiable identity credentials. They initiate verification requests and output model validation results based on the logit distance distribution and verifiable identity credentials. The verifiable identity credentials are digital identity credentials under the W3C standard. Third-party query nodes include regulatory agencies, insurance institutions, downstream partners of service user nodes, and other users. They can query the integrity profile of service provider nodes stored on the blockchain. The blockchain can include an on-chain verification layer. As a trustless infrastructure, the on-chain verification layer deploys on-chain verification contracts, which can be used for commitment notarization, random sampling, verification process execution, and result storage. The blockchain can be a public, consortium, or private blockchain. In scenarios with high compliance requirements, such as finance and regulation, a consortium blockchain is preferred; in scenarios where broad transparency is desired, a public blockchain can be used. A blockchain typically consists of multiple blocks.

[0035] Furthermore, before executing the specific model verification process, a first cryptographic commitment for the reference model and multiple second cryptographic commitments for the actual deployed model can be pre-stored on the blockchain (the second cryptographic commitments include the cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actual deployed model performs inference tasks). This provides a clear and tamper-proof comparison benchmark for model verification. Specifically, the first cryptographic commitment is used to anchor the benchmark version of the large language model claimed by the service provider node, and the second cryptographic commitments are used to anchor the actual deployed version of the large language model.

[0036] The following describes the blockchain-based model verification method provided in the embodiments of this application.

[0037] Figure 1 A schematic flowchart of a blockchain-based model verification method provided in one embodiment of this application is shown. Figure 1 As shown in the embodiments of this application, the blockchain-based model verification method includes the following steps: S110. Through the on-chain verification layer, in response to the verification request initiated by the verification node, obtain a random seed that is unpredictable before verification and verifiable after verification. S120. Through the on-chain verification layer, based on a random seed, extract multiple commitments to be verified from multiple second cryptographic commitments. S130. Send a proof generation request corresponding to the commitment to be verified to the service provider node through the on-chain verification layer; S140. Through the service provider node, in response to the proof generation request, the inference task corresponding to the commitment to be verified is executed using the reference model in the trusted execution environment to obtain the reference logical value vector of each decision step. S150. Through the service provider node, based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, determine the tail probability and generate a verifiable computational proof. The tail probability is the proportion of the number of decision steps with a distance exceeding a preset distance to the total number of decision steps. S160. Through the verification node, if the verifiable computational proof has been verified, the model verification result is determined based on the tail probability.

[0038] This application embodiment responds to verification requests through an on-chain verification layer, obtaining a random seed that is unpredictable before verification but verifiable after verification. This ensures that the generation process of the random seed is free from the control of any single entity. No verification node or service provider can predict or interfere with the value of the random seed before sampling, thereby eliminating the possibility of verification nodes unilaterally manipulating the sampling process and laying a credible foundation for the fairness of subsequent sampling. Furthermore, by storing the first cryptographic commitment of the reference model and the second cryptographic commitment of the actual deployed model on the blockchain, the model specification statement and the evidence of the reasoning process are publicly and immutably preserved. Any third party can independently verify the authenticity and completeness of the above commitments, and the service provider cannot later deny the model version or reasoning logic it actually used. Thus, the verification process of this application embodiment, from random seed generation, sampling execution, evidence preservation to result verification, is open, transparent, and verifiable by multiple parties, improving the reliability of model verification.

[0039] The specific implementation methods for each of the above steps are described below.

[0040] In some embodiments, in S110, the verification node holds a verifiable identity credential issued by a trusted issuer (such as a regulatory agency, licensed financial institution, or academic institution). By binding this verifiable identity credential to the verification node's Decentralized Identifier (DID) on the blockchain, the verification node's on-chain registration is completed. After completing on-chain registration, the verification node gains the right to participate in model verification.

[0041] As an example, verification nodes can submit verification requests to the on-chain verification layer at preset intervals (e.g., daily, weekly), or upon receiving a model verification instruction. Upon receiving a verification request, the on-chain verification layer responds by obtaining a random seed that is unpredictable before verification and verifiable after verification. Based on this random seed, it samples from multiple second cryptographic commitments to obtain multiple commitments to be verified. The random seed must satisfy two fundamental conditions: unpredictability before verification and verifiability after verification. This ensures that the generation process of the random seed is not controlled by any single entity. No verification node or service provider can predict or interfere with the value of the random seed before sampling, thus eliminating the possibility of verification nodes unilaterally manipulating the sampling process and laying a credible foundation for the fairness of subsequent sampling.

[0042] To obtain a random seed that is unpredictable before verification and verifiable after verification, in some embodiments, the on-chain verification layer can generate a random seed based on a Verifiable Random Function (VRF). Specifically, in response to a verification request, the on-chain verification layer can first locate the latest block in the blockchain at the time the verification request is received, and then concatenate the hash value of the latest block with the request identifier of the verification request as the input to the VRF. Additionally, the blockchain may include VRF oracle nodes, which can calculate a random value and the corresponding cryptographic proof based on the above input. The entire network can verify the legitimacy of the cryptographic proof using the VRF public key. After the cryptographic proof is verified, the random value output by the VRF can be determined as an unpredictable, unbiased, and publicly verifiable secure random seed, which can be used in subsequent sampling processes.

[0043] In other embodiments, obtaining a random seed that is unpredictable before verification and verifiable after verification may specifically include: Locate the latest block in the blockchain when the verification request is received; The hash value of the Mth block following the latest block is used as the random seed, where M is a positive integer.

[0044] Here, when a verification request is received, the Mth block after the latest block has not yet been generated, and its hash value cannot be predicted by anyone at the time of the request, ensuring the unpredictability of randomness; and after the M blocks are generated and put on the chain, their hash values ​​are publicly verifiable and cannot be tampered with, ensuring the verifiability of randomness.

[0045] In addition, random seeds can be generated based on multi-party threshold signatures, trusted timestamp services, or multi-chain data aggregation, as long as the two basic conditions of being unpredictable before verification and verifiable after verification are met.

[0046] In some embodiments, in S120, the method of selecting multiple commitments to be verified from multiple second cryptographic commitments includes uniform random sampling and non-uniform random sampling. When the sampling method is uniform random sampling, assume the multiple second cryptographic commitments are arranged sequentially, with a total quantity of H, and the preset quantity of commitments to be verified is N. The random seed can be preset to any value between 1 and H. Thus, the random seed can be mapped to any integer in the interval [0, H-1] as a starting index, and the second cryptographic commitment corresponding to this starting index is taken as the first commitment to be verified. The indexes are shifted sequentially by a preset step size to obtain N-1 offset indices, and the second cryptographic commitments corresponding to these N-1 offset indices are determined as N-1 commitments to be verified. When the offset index exceeds H-1, the counting continues from 0, and this cycle repeats until N commitments to be verified are selected.

[0047] Therefore, to avoid the drawback of uniform random sampling potentially missing key risk points, in some embodiments, the above-mentioned S120 may specifically include: Based on a random seed, multiple second cryptographic commitments are randomly sampled non-uniformly according to a preset partitioning dimension and a preset sampling quantity constraint to obtain multiple commitments to be verified. The preset partitioning dimension includes at least one of inference request time, task complexity and request content type, and the preset sampling quantity constraint is different for different preset partitioning dimensions.

[0048] Here, the inference request time is the time when the service user node initiates an inference request to the service provider node. Task complexity characterizes the complexity of the inference task, and can be determined based on at least one of the following: the number of tokens and the number of inference chains. A larger number of tokens indicates higher task complexity; conversely, the number of inference chains refers to the number of discrete decision steps in the inference task. A larger number of inference chains indicates that the inference task requires more consecutive decisions, thus increasing its complexity.

[0049] The request content type characterizes the nature of the reasoning task. Request content types can include question-and-answer type (direct response based on knowledge or context), reasoning type (multi-step logical deduction and decision analysis), code type (understanding, generating and debugging programming languages), and long text type (processing and analyzing extremely long contexts), etc.

[0050] In addition, the preset sampling quantity constraint refers to the sampling quantity constraint set in advance for each level based on the already determined total sampling quantity and the layering of multiple second cryptographic commitments according to preset partitioning dimensions. Specifically, different sampling quantity constraints can be set for different preset partitioning dimensions to suit their characteristics.

[0051] Thus, by using a random seed and following preset partitioning dimensions and sampling quantity constraints, multiple second cryptographic commitments are sampled non-uniformly, making the sampling process not only cryptographically random but also allowing for differentiated sampling based on preset partitioning dimensions and sampling quantity constraints. This avoids the drawback of uniform random sampling potentially missing key risk points.

[0052] In some embodiments, the above-mentioned non-uniform random sampling of multiple second cryptographic commitments based on a random seed, according to a preset partitioning dimension and a preset sampling quantity constraint, yields multiple commitments to be verified, which may specifically include: Multiple second cryptographic commitments are layered according to a preset division dimension to obtain multiple levels; Based on the total number of samples, the number of tiers, and the preset sampling quantity constraints, the sampling quantity for each tier is determined. The random seed is expanded into multiple random seed sequences, where the number of random seed sequences is the same as the number of levels, and for each level, the number of random seeds in the random seed sequence is the same as the number of samples. For each level, based on a random seed sequence, a commitment to be verified is extracted from multiple second cryptographic commitments corresponding to the level, resulting in multiple commitments to be verified.

[0053] Here, since the second cryptographic commitment is obtained through cryptographic computation of the actual logical value vector of the decision steps when the actual deployed model performs inference tasks, each second cryptographic commitment can correspond to an inference request time. Thus, if the preset division dimension is inference request time, multiple second cryptographic commitments can be layered based on their respective inference request times, resulting in multiple time levels. For example, using one hour as a time window, multiple second cryptographic commitments can be divided into 24 time levels.

[0054] Since the second cryptographic commitment is obtained through cryptographic computation of the actual logical value vector of the decision steps when the actual deployed model performs the inference task, the task complexity corresponding to the inference task is the task complexity corresponding to the second cryptographic commitment. Therefore, if the preset partitioning dimension is task complexity, multiple second cryptographic commitments can be hierarchically classified based on their respective task complexities, resulting in multiple complexity levels. The task complexity can be determined based on at least one of the number of tokens in the inference task and the number of inference chains.

[0055] For example, if the task complexity is determined based on the number of lexical units or the inference chain, the number of lexical units or the inference chain can be pre-divided into L intervals. Then, based on the number of lexical units or the inference chain corresponding to the second cryptographic commitment, multiple second cryptographic commitments can be mapped to the levels corresponding to the L intervals, resulting in L complexity levels. For example, the number of lexical units can be divided into four intervals: [0, 100), [100, 1000), [1000, 10000), and [10000, +∞), corresponding to low, medium, high, and ultra-high complexity levels, respectively.

[0056] If the task complexity is determined based on both the number of lexical units and the number of inference chains, then the number of lexical units and the number of inference chains can be weighted and fused to obtain a comprehensive complexity score. Then, P intervals can be determined based on the comprehensive complexity score. Finally, multiple second cryptographic commitments can be mapped to the levels corresponding to the P intervals to obtain P complexity levels.

[0057] It is understood that the above classification method is only an illustrative example, and the specific quantification method of task complexity is not limited to this.

[0058] Since the second cryptographic commitment is obtained through cryptographic computation of the actual logical value vector of the decision steps when the actual deployed model performs inference tasks, the request content type corresponding to the inference task is the request content type corresponding to this second cryptographic commitment. Thus, if the preset division dimension is request content type, multiple second cryptographic commitments can be hierarchically classified based on their respective request content types, resulting in multiple type levels. Each request content type can correspond to one type level. For example, if the request content types include question-and-answer, inference, code, and long text types, then multiple second cryptographic commitments can be divided into four type levels.

[0059] Furthermore, the total sampling size can be determined based on a preset value, or it can be determined based on the expected cheating rate of the service provider's nodes, the detection rate of a single verification request, and the allowed probability of cheating escape; no limitation is imposed here. The detection rate represents the probability of successfully detecting cheating behavior when verifying an actual cheating inference request. This cheating behavior includes at least actions that are inconsistent with the specifications of the actual deployed model and the reference model, as well as actions that reduce the inference accuracy of the actual deployed model. Cheating behavior is also known as deviation behavior.

[0060] Specifically, the total sample size can be determined using the following formula (1): (1) Where N represents the total number of samples. Indicates the expected cheating rate. This indicates the detection rate of a single verification request. This represents the allowed probability of cheating escaping.

[0061] After determining the total number of samples and the number of tiers, the sample size for each tier can be determined based on the total number of samples, the number of tiers, and the preset sample size constraints.

[0062] In practice, the motivation for server-side models to deviate from the published specifications or for actual inference accuracy to fall below the claimed accuracy is usually strongly correlated with system load. Specifically, during peak periods when computing resources are scarce, replacing high-cost, large models with low-cost distillation models / smaller models, or reducing inference accuracy (such as replacing BF16 with FP8), can maximize cost savings. During off-peak periods, when resources are abundant, service provider nodes lack the motivation for such deviations (server-side models deviating from the published specifications or actual inference accuracy falling below the claimed accuracy). Therefore, deviations are unevenly distributed over time, with peak periods exhibiting the highest risk of deviation and off-peak periods showing relatively lower risk.

[0063] Therefore, if a completely random sampling method is used, since the probability of requests being selected during peak and off-peak periods is exactly the same (both are a fixed proportion of the total sample size to the total number of requests), the sampling results will fluctuate randomly. There may be fewer request samples during peak periods and more request samples during off-peak periods. Consequently, there is a high probability that the inference requests with the highest deviation risk will not be fully covered, forming a verification blind spot in the time dimension.

[0064] If stratified random sampling is used and allocated proportionally to the request volume (i.e., the number of samples in each time window is proportional to the number of requests in that window), although more samples are obtained during peak periods due to the larger base, the probability of each request being selected during peak periods does not increase. This is because the probability equals the number of samples in that window divided by the total number of requests in that window; both the numerator and denominator increase simultaneously, but the probability remains unchanged. This means that sampling proportionally to the request volume does not tilt verification resources towards high-risk periods; the probability of a single request being selected remains the same during peak and off-peak periods, failing to address the issue of high-risk periods being deviated from but not prioritized for coverage during peak periods.

[0065] To address the aforementioned issues, this application embodiment employs a stratified equal-quota sampling scheme when the preset division dimension is the inference request time. For each stratum, the sampling quantity for each stratum is determined based on the ratio between the total sampling quantity and the number of strata, ensuring that the sampling quantity for each stratum is the same.

[0066] This equal allocation method ensures that each time window receives an independent and equal sampling quota, regardless of the request volume. Thus, with a fixed sampling quantity at each level, the probability of each request being selected (i.e., the ratio of the fixed quota to the request volume in that window) is higher in peak-period windows due to the large request volume, compared to off-peak windows. This proactively tilts verification resources towards high-risk periods. Simultaneously, each window has independent sample coverage, preventing marginalization due to low request volume in any particular window. This eliminates the opportunity for service provider nodes to circumvent verification by "devising only during specific time periods," maximizing the expected deterrent effect of model verification while maintaining a constant total sampling quantity.

[0067] Furthermore, in practice, the detection rates of single requests exhibiting the same deviation behavior vary significantly across different request content types in reasoning tasks. For example, based on relevant experimental data, the detection rate for FP8 quantization attacks is 9.0% on mathematical reasoning datasets, 9.7% on open-ended question-answering datasets, and only 5.3% on short question-answering datasets. A lower detection rate indicates that the deviation behavior in this type of reasoning task is more concealed, more difficult to detect, and carries a higher risk of cheating.

[0068] If uniform random sampling is used, the distribution of sampling results among different request content types will fluctuate randomly. This may lead to oversampling of easily detectable request content types, while insufficient samples of difficult-to-detect request content types, leaving room for service provider nodes to implement deviations on difficult-to-detect types.

[0069] To address the aforementioned issues, in this embodiment of the application, with the preset division dimension being the request content type, for each level, the sampling quantity for each level is determined based on the total sampling quantity, the number of levels, and the detection rate corresponding to the level. The sampling quantity is negatively correlated with the detection rate, which represents the probability of successfully detecting a deviation when verifying a reasoning request that actually has a deviation.

[0070] Here, a lower detection rate means that the type of request is more difficult to detect and a larger sample size is allocated; a higher detection rate means that the type of request is more easy to detect and a smaller sample size is allocated.

[0071] As an example, the sampling size of the i-th level can be determined using the following formulas (2)-(3). : ×N(2) (3) in, Let T be the detection rate corresponding to the i-th level, T be the number of levels, and N be the total number of samples.

[0072] Thus, by using the above sampling quantity allocation method that is negatively correlated with the detection rate, types with low detection rates can obtain a higher sampling quantity, thereby reducing the space for service provider nodes to exploit the differences in detection rates between types to implement deviations on difficult-to-detect types.

[0073] Furthermore, in practice, the higher the complexity of the reasoning task (i.e., the more lexical units the reasoning task corresponds to and the longer the reasoning chain), the greater the computational resource cost that can be saved by model replacement or accuracy downgrading, and the greater the possibility that the service provider will implement deviation behavior.

[0074] If uniform random sampling is used for all inference tasks, the probability of high-complexity tasks and low-complexity tasks being selected is the same. However, in reality, the deviation risk of high-complexity tasks is much higher than that of low-complexity tasks. Uniform sampling cannot concentrate limited verification resources on high-risk, high-complexity tasks, thus reducing the effectiveness of model verification.

[0075] To address the aforementioned issues, in this embodiment of the application, with the preset division dimension being task complexity, the sampling quantity for each level is determined based on the total sampling quantity, the number of levels, and the complexity level corresponding to the level. The sampling quantity is positively correlated with the complexity level.

[0076] Here, the higher the complexity level, the greater the likelihood that the service provider will perform deviant behavior, and the larger the sample size will be allocated; the lower the complexity level, the less likely the service provider will perform deviant behavior, and the smaller the sample size will be allocated.

[0077] As an example, the sampling size of the i-th level can be determined using the following formulas (4)-(5). : ×N(4) (5) in, Let T be the complexity level corresponding to the i-th level, T be the number of levels, and N be the total number of samples.

[0078] Thus, by using the above sampling quantity allocation method that is positively correlated with the complexity level, high-complexity tasks can obtain a higher sampling quantity, thereby increasing the probability that complex tasks will be selected for verification and improving the effectiveness of model verification.

[0079] After determining the sampling size for each level, the random seed can be expanded into multiple random seed sequences. For each level, based on the random seed sequence, a commitment to be verified is extracted from multiple second cryptographic commitments corresponding to that level, resulting in multiple commitments to be verified. The number of random seed sequences is the same as the number of levels, and for each level, the number of random seeds in the random seed sequence is the same as the sampling size.

[0080] In some embodiments, expanding the random seed into multiple random seed sequences may specifically include: Input a random seed into a deterministic pseudo-random number generation algorithm, and output a random number sequence with a length equal to the total number of samples. According to the sampling quantity of each level, the random number sequence is sequentially cut into random seed sequences corresponding to each level.

[0081] Here, the deterministic pseudorandom number generation algorithm is an algorithm that generates a sequence of random numbers of arbitrary length from an initial seed in a deterministic manner. Given the same initial seed, this algorithm always outputs the same sequence of random numbers.

[0082] As an example, by inputting a random seed into a deterministic pseudorandom number generation algorithm and expanding it according to the total number of samples, a random number sequence can be obtained. Assume the total number of samples is 100, with three levels: level 1 and level 2 each have 25 samples, and level 3 has 50 samples. The random number sequence is denoted as R = [r1, r2, r3, …, r 100If we divide the sequence according to the sampling quantity of each level, we can obtain the random seed sequence corresponding to level 1 as [r1, r2, …, r 25 The random seed sequence corresponding to level 2 is [r]; 26 , r 27 , …, r 50 The random seed sequence corresponding to level 3 is [r]; 51 , r 52 , …,r 100 ].

[0083] In this process, any third party using the same random seed and the same deterministic pseudo-random number generation algorithm can independently reproduce the exact same random number sequence.

[0084] In other embodiments, expanding the random seed into multiple random seed sequences as described above may specifically include: For each level, the random seed and the level's identifier information are input into the key derivation function to generate the sub-random seed corresponding to the level; Input the sub-random seed into a deterministic pseudo-random number generation algorithm, and output a random seed sequence with a length equal to the number of samples at each level.

[0085] Here, a key derivation function is a cryptographic function that derives one or more independent subkeys from an initial key material. Given the same input (random seed and hierarchy identifier), the key derivation function always outputs the same subrandom seed.

[0086] As an example, for the i-th level, its level identifier (such as level number i) is concatenated with a random seed and then input into a key derivation function for hashing, outputting the sub-random seed corresponding to that level. Since the identifiers of each level are different, the derived sub-random seeds are independent of each other. Subsequently, each sub-random seed is input into a deterministic pseudo-random number generation algorithm and expanded according to the sampling quantity of that level to obtain the corresponding random seed sequence. In this process, any third party using the same random seed, the same level identifier, and the same key derivation function can independently reproduce the exact same sub-random seed and the corresponding random seed sequence.

[0087] Furthermore, when expanding a random seed or sub-random seed into a random seed sequence based on a deterministic pseudo-random number generation algorithm, the range of values ​​for the random seed in the random seed sequence can be preset. For example, this range can be determined based on the sampling quantity of the level corresponding to the random seed sequence.

[0088] As an example, for the i-th level, let its sampling size be C. When generating the random seed sequence for this level, the value of each random number can be limited to the range [1, C]. In this way, each random number in the random seed sequence can be directly used as the index value for selecting the second cryptographic commitment within this level.

[0089] Furthermore, within each layer, the reasoning tasks corresponding to each second cryptographic commitment may differ significantly in terms of the number of tokens. Some reasoning tasks consume only a small number of tokens, while others consume tens of thousands or even hundreds of thousands of tokens. If the service provider falsely reports the number of tokens, the greater the false report, the greater the additional benefit it can obtain. Therefore, the service provider has an incentive to engage in false reporting on reasoning tasks with a large number of tokens.

[0090] Based on this, in order to improve the authenticity of the reported token quantity, in some embodiments, for each level, based on a random seed sequence, the commitment to be verified is extracted from multiple second cryptographic commitments corresponding to the level, which may specifically include: For each level, perform the following operations: Obtain the number of tokens corresponding to multiple second cryptographic commitments within the hierarchy; The weight value is determined based on the number of lexical units, and the number of lexical units is positively correlated with the weight value. By summing up multiple weight values ​​in sequence, we obtain weight intervals corresponding to multiple second cryptographic commitments. The width of each weight interval is equal to the weight value of the second cryptographic commitment. Each random seed in the random seed sequence is mapped to multiple weight intervals to determine the target weight interval into which each random seed falls. The second cryptographic commitment corresponding to each target weight interval is determined as the commitment to be verified.

[0091] Here, for each level, this embodiment first obtains the number of tokens corresponding to the multiple second cryptographic commitments within that level, and determines the weight value of each second cryptographic commitment based on the number of tokens. The more tokens, the larger the weight value; the fewer tokens, the smaller the weight value.

[0092] Subsequently, the weight values ​​are summed sequentially to obtain the weight intervals corresponding to each second cryptographic commitment. Taking 5 commitments as an example, if their weights are 100, 50, 300, 80, and 120 respectively, then after summing, the weight intervals corresponding to each commitment are [0, 100), [100, 150), [150, 450), [450, 530), and [530, 650), with a total weight of 650. The width of the weight interval for each commitment is equal to its weight value; that is, the interval width corresponding to a commitment with a weight of 300 is 300, which is 6 times that of a commitment with a weight of 50. Therefore, the probability of being hit by a random number is 6 times that of the latter.

[0093] Subsequently, each random seed in the random seed sequence is mapped to one of the aforementioned weight intervals. The target weight interval into which each random seed falls is determined, and the second cryptographic commitment corresponding to that target weight interval is identified as the selected commitment to be verified. For example, if the random seed is mapped to 260, which falls within the interval [150, 450), then the corresponding second cryptographic commitment with a weight of 300 is selected.

[0094] In this way, by positively linking the number of lexical units with the weight value and performing weighted random sampling within the layer, the probability of the service provider falsely reporting the number of lexical units actually increases. The more lexical units are reported, the greater the risk of being detected. This forms an incentive mechanism that guides service providers to truthfully report the number of lexical units, thereby suppressing false reporting behavior at the source and improving the authenticity of the reported number of lexical units.

[0095] In some embodiments, in S130, after the non-uniform random sampling is completed and multiple commitments to be verified are obtained, the on-chain verification layer can publicly broadcast the sampling results through contract events and send proof generation requests to the service provider nodes corresponding to each of the multiple commitments to be verified. The multiple commitments to be verified may correspond to one service provider node or multiple service provider nodes. Each service provider node may correspond to one commitment to be verified or multiple commitments to be verified. Furthermore, the proof generation request can be used to request the service provider nodes to generate a tail probability and a verifiable computational proof for each commitment to be verified.

[0096] In some embodiments, in S140, after receiving a proof generation request corresponding to the commitment to be verified, the service provider node can respond to the proof generation request by loading a reference model corresponding to the commitment to be verified in a trusted execution environment. Then, using the same control constraints as the actual deployed model, it executes the inference task corresponding to the commitment to be verified using the reference model and records the reference logical value vector for each decision step. The trusted execution environment is a hardware-isolated secure computing environment that provides runtime protection for the code and data loaded into it, preventing unauthorized access or tampering and ensuring the confidentiality and integrity of the computing process.

[0097] In some embodiments, in S150, after receiving the proof generation request corresponding to the commitment to be verified, the service provider node can load the actual logical value vectors of each decision step corresponding to the commitment to be verified in the trusted execution environment, and progressively calculate the total variation distance (TV) between the reference logical value vector and the actual logical value vector of each decision step. Then, the TV distances greater than a preset distance among the multiple TV distances are determined as target TV distances, and the tail probability is determined based on the proportion of decision steps corresponding to the multiple target TV distances to all decision steps. Subsequently, a verifiable computational proof is generated for the above-mentioned tail probability calculation process using verifiable computational technology, and the tail probability and verifiable computational proof are sent to the on-chain verification layer, which stores the tail probability and verifiable computational proof in the blockchain. The verifiable computational proof is used to prove that the tail probability is correctly calculated according to the public rules, and that the calculation process is executed within the trusted execution environment, and the calculation result has not been tampered with.

[0098] In some embodiments, in S160, after obtaining the tail probability of the logical value distance distribution and the verifiable computational proof from the blockchain, the verification node can first verify the verifiable computational proof. If the verification passes, it confirms that the calculation process of the tail probability is correct and has not been tampered with. Subsequently, the tail probability is compared with a first preset probability and a second preset probability, and the model verification result is determined based on the comparison result. Specifically, if the tail probability is less than or equal to the first preset probability, it can be determined that the actual deployed model is consistent with the reference model, and the model verification result is passed. If the tail probability is greater than the second preset probability, it can be determined that the actual deployed model deviates from the reference model, and the model verification result is failed. If the tail probability is between the first preset probability and the second preset probability, the model verification result is questionable.

[0099] Subsequently, the verification node can store the model verification results, the first preset probability, and the second preset probability on the blockchain through the on-chain verification contract.

[0100] In addition, service provider nodes must pre-deposit a verification deposit when joining the verification network, which is held in escrow by the on-chain verification contract. After completing a valid verification task and submitting the results, the verification node receives a reward from the service provider's deposit or the system reward pool; if the verification finds that the service provider has deviated from its intended course of action, part of the deposit will be used to compensate the affected users (i.e., service users).

[0101] Furthermore, the on-chain verification layer can configure differentiated verification permissions and reward standards for different verification nodes based on their qualification level and historical verification performance, thereby effectively incentivizing verification nodes. The specific incentive method for verification nodes can be flexibly selected according to the actual deployment scenario. For example, one of the following methods can be adopted: subscription model, where the service provider node pays a fixed subscription fee to cover verification services for a certain period; pay-as-you-go model, where the service user node pays a verification fee per query; or regulatory enforcement, where regulatory agencies initiate mandatory verification tasks for compliance inspection purposes, with the verification cost borne by the regulator or service provider. This application does not limit the specific incentive method for verification nodes.

[0102] Based on the above embodiments, in order to provide an immutable and reliable baseline for model validation, in some embodiments, before S110 above, the method may further include: By performing cryptographic commitment operations on the reference model through the service provider node, the first cryptographic commitment is obtained. Through the service provider node, send the service provider identifier, the first cryptographic commitment, and the model meta-information of the reference model to the on-chain verification layer; The service provider identifier, first cryptographic commitment, and model metadata are stored on the blockchain through an on-chain verification layer.

[0103] Here, the cryptographic commitment operation can be a hash commitment operation or a Pedersen commitment operation. Additionally, model metadata may include name, version, declared precision level, lexical billing rules, etc.

[0104] As an example, before a service provider node deploys a model for a service user node, it can first register the model and make a reference model commitment. Specifically, a cryptographic commitment operation can be performed on the reference model to obtain a first cryptographic commitment. This first cryptographic commitment, along with the service provider node's service provider identifier and model metadata, is then written to the blockchain through an on-chain verification contract. The service provider identifier can be the service provider's DID. After this step, the model specifications declared on the chain are bound to the service provider node.

[0105] This application embodiment stores the service provider's identifier, the first cryptographic commitment, and the model's metadata on the blockchain, which is equivalent to publicly declaring on the chain that "this service provider commits to providing services using the model of this specification," thus providing an immutable and trustworthy baseline for model verification.

[0106] Furthermore, in order to provide an immutable public record for model validation, in some embodiments, the method may further include the following steps before S110: Initiate an inference request from the service user node to the service provider node; Through the service provider node, in response to the inference request, the inference process corresponding to the inference request is executed using the actual deployed model, and the actual logical value vector corresponding to each decision step is recorded. By performing cryptographic commitment operations on the actual logical value vectors corresponding to each decision step through the service provider node, a second cryptographic commitment is obtained. Through the service provider node, send the second cryptographic commitment, the service provider signature, the request identifier of the reasoning request, and the request time to the on-chain verification layer; The second cryptographic commitment, the service provider's signature, the request identifier of the reasoning request, and the request time are stored on the blockchain through the on-chain verification layer.

[0107] Here, after the service user node initiates an inference request to the service provider node, the service provider node can execute the inference process corresponding to the inference request using the actual deployment model and record the actual logical value vector corresponding to each decision step. After completing the inference task, the service provider node can perform cryptographic commitment operations on the actual logical value vectors corresponding to each decision step to obtain a second cryptographic commitment corresponding to the inference request / inference task. Subsequently, the service provider node can write the second cryptographic commitment, the service provider signature, the request identifier of the inference request, and the request time into the blockchain through an on-chain verification contract, and return response information indicating the completion of the inference task execution and the location information of the second cryptographic commitment on the blockchain to the service user node.

[0108] After receiving the response and location information, the service user node can independently query and verify the existence and integrity of the second cryptographic commitment from the blockchain based on the location information. Furthermore, by uploading the second cryptographic commitment generated by the service provider node during each inference process to the blockchain, the commitment becomes visible to the entire network, carries a trusted timestamp, is tamper-proof, and non-repudiable. Any third-party node (such as regulators, future users, verification nodes, or judicial authorities) can subsequently query and verify the existence and integrity of the commitment.

[0109] This application embodiment provides tamper-proof public evidence for model verification by storing the second cryptographic commitment, the service provider's signature, the request identifier of the reasoning request, and the request time together in the blockchain.

[0110] Therefore, in order to reduce the storage cost of the second cryptographic commitment while ensuring the validity of the verification, in some embodiments, the above-mentioned recording of the actual logical value vectors corresponding to each decision step may specifically include: For each decision step, record the K largest actual logical values ​​of the target among multiple actual logical values, where K is a positive integer; Based on the distance between the reference logical value vector and the actual logical value vector for each decision step corresponding to the commitment to be verified, the tail probability is determined, including: The tail probability is determined based on the distance between the K target reference logic values ​​and the K target actual logic values ​​for each decision step corresponding to the commitment to be verified. For each decision step, the K target reference logic values ​​are the K largest values ​​among all the reference logic values ​​corresponding to the decision step.

[0111] Here, assuming the vocabulary size for a certain decision step is V, originally V actual logical values ​​would need to be recorded. After Top-K optimization, only K values ​​need to be recorded (K is much smaller than V). Thus, the second cryptographic commitment corresponding to this decision step is obtained by performing cryptographic commitment operations on the K target reference logical values.

[0112] Accordingly, in response to the proof generation request, the service provider node, in a trusted execution environment, when performing the inference task corresponding to the commitment to be verified using the reference model, can record the K largest target reference logical values ​​for each decision step.

[0113] Subsequently, the TV distance between the target reference logical value vector and the target actual logical value vector for each decision step is calculated step by step. Then, the TV distances that are greater than a preset distance among the multiple TV distances are determined as the target TV distances, and the tail probability is determined based on the proportion of decision steps corresponding to multiple target TV distances to all decision steps.

[0114] In this embodiment of the application, since the second cryptographic commitment only contains the first K logical values, and the comparison during verification is only performed on these K logical values, the storage overhead of the commitment for each decision step can be reduced to about 1KB while ensuring the validity of the verification, thereby reducing the storage cost of the second cryptographic commitment.

[0115] Building upon this, to further enhance the security of the second cryptographic commitment, in some embodiments, the above-mentioned cryptographic commitment operation is performed on the actual logical value vectors corresponding to each decision step to obtain the second cryptographic commitment, which may specifically include: Get a random salt value; The random salt value is concatenated with the actual logical value vector corresponding to each decision step to obtain the data to be committed; A second cryptographic commitment is obtained by performing cryptographic commitment operations on the committed data.

[0116] Here, the random salt can be a random number or a pseudo-random number generated by the service provider node. The introduction of the random salt ensures that even if the actual logical value vectors of different inference tasks are exactly the same, the generated second cryptographic commitments will be different, thereby further improving the security of the second cryptographic commitment.

[0117] If the second cryptographic commitment includes a random salt value, then the commitment to be verified extracted from the second cryptographic commitment also includes a random salt value.

[0118] Based on this, in order to further improve the credibility of the tail probability and thus the credibility of model validation, in some embodiments, the tail probability is determined based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be validated, and a verifiable computational proof is generated. Specifically, this may include: Obtain the random salt value corresponding to the commitment to be verified and the actual logical value vector of each decision step; A third cryptographic commitment is obtained by performing cryptographic commitment operations on the random salt value and the actual logical value vector of each decision step. When the third cryptographic commitment is the same as the commitment to be verified, calculate the distance between the reference logical value vector and the actual logical value vector corresponding to each decision step in turn. Determine the target distance that is greater than a preset distance from multiple distances; The tail probability is determined by the ratio of the number of decision steps corresponding to multiple target distances to the total number of decision steps. Based on the calculation process of tail probability, a verifiable computational proof is generated.

[0119] Here, if the third cryptographic commitment is the same as the commitment to be verified, it indicates that the disclosed random salt value and the actual logical value vector are genuine and complete, i.e., the verification is successful, and the tail probability can then be calculated. Based on this, the tail probability calculation process includes the aforementioned verification process of the commitment to be verified. Thus, by generating a verifiable computational proof based on the tail probability calculation process, and if the verification node verifies this verifiable computational proof successfully, it is confirmed that the tail probability calculation process is correct and has not been tampered with, further improving the credibility of the tail probability and consequently enhancing the credibility of the model verification.

[0120] Furthermore, the blockchain can store the integrity profiles of service provider nodes. These profiles record the performance of service provider nodes in various verification processes, providing a reference for users selecting service providers, regulatory compliance checks, and insurance institution rate assessments. In other words, these integrity profiles can serve as compliance assets for service providers to access payment networks, undertake financial business, and obtain insurance ratings.

[0121] Based on this, in order to provide a reliable data foundation for scenarios such as regulatory compliance, user selection, and insurance assessment, in some embodiments, after S160 above, the method may further include: The model verification results are sent to the on-chain verification layer through the verification node; The integrity profile of service provider nodes is updated based on the model verification results through the on-chain verification layer.

[0122] Here, the on-chain verification layer can maintain a trust profile for each service provider node. This profile includes at least one of the following: model verification results, verification time, cumulative verification count, number of successful verifications, time-distributed pass rate, historical deviation events, comparison with industry averages, and risk level label. To protect the sensitive information of service provider nodes, the original content of the inference task (such as user input and model output) is not stored on the blockchain; only commitment hashes and statistical indicators are stored on-chain, achieving a balance between verifiability and privacy protection.

[0123] Based on this, in some embodiments, after storing the integrity profile on the blockchain through the on-chain verification layer, the method may further include: Initiate a profile query request for the target service provider node through a third-party query node; Through the on-chain verification layer, in response to the profile query request, the integrity profile of the target service provider node is returned to the third-party query node.

[0124] Here, the target service provider node can be any one of multiple service provider nodes on the blockchain. Specifically, a third-party query node can initiate a profile query request for the target service provider node to the on-chain verification layer through a standardized interface. In response to this profile query request, the on-chain verification layer can read the integrity profile of the target service provider node from the blockchain and return it to the third-party query node. The third-party query node refers to a node with query permissions. Third-party query nodes can include regulatory agencies, insurance institutions, downstream partners of the service user node, and other users.

[0125] Thus, through the embodiments of this application, the model verification results can be stored on the blockchain in an immutable form, forming a publicly verifiable integrity profile of the service provider node, providing a reliable data foundation for scenarios such as regulatory compliance, user selection, and insurance assessment.

[0126] Therefore, this application provides a decentralized, tamper-proof, and traceable infrastructure for large language model verification using blockchain. Specifically, blockchain serves as the trusted repository for publicly stored cryptographic commitments and verification results; distributed digital identities and verifiable identity credentials enable decentralized access and responsibility differentiation management of verification nodes; on-chain verifiable random functions (VRFs) or future block hashes serve as publicly verifiable random sampling sources; and on-chain verification contracts serve as the central hub for automated execution and state maintenance of the verification process. The model verification system constructed in this way effectively avoids problems in traditional solutions such as centralized verification roles, unverifiable commitments, lack of third-party guarantees for sampling randomness, and inability to accumulate and trace verification results. It is suitable for various highly compliant scenarios, including regulatory verification of large language models, intelligent agent payment settlement auditing, and multi-party cross-verification in collaborative modeling, providing general infrastructure support for the trusted deployment of large language models.

[0127] Based on the blockchain-based model verification method provided in the above embodiments, this application also provides a specific implementation of a blockchain-based model verification device. The blockchain-based knowledge base verification device is applied to a model verification system, which includes a blockchain, service provider nodes, and verification nodes. The blockchain includes an on-chain verification layer, and stores a first cryptographic commitment of a reference model and multiple second cryptographic commitments of the actually deployed model. The second cryptographic commitments include the cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actually deployed model performs inference tasks.

[0128] For a detailed implementation of the blockchain-based model verification device, please refer to the following embodiments.

[0129] like Figure 2 As shown, an embodiment of this application provides a blockchain-based model verification device 200, which includes the following modules: The acquisition module 210 is used to obtain a random seed that is unpredictable before verification and verifiable after verification in response to a verification request initiated by a verification node through the on-chain verification layer. Sampling module 220 is used to extract multiple commitments to be verified from multiple second cryptographic commitments based on a random seed through an on-chain verification layer. The first sending module 230 is used to send a proof generation request corresponding to the commitment to be verified to the service provider node through the on-chain verification layer; The first reasoning module 240 is used to respond to the proof generation request through the service provider node, and use the reference model to execute the reasoning task corresponding to the commitment to be verified in the trusted execution environment to obtain the reference logical value vector of each decision step. The generation module 250 is used to determine the tail probability by means of the service provider node, based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, and to generate a verifiable computational proof. The tail probability is the proportion of the number of decision steps with a distance exceeding a preset distance to the total number of decision steps. The determination module 260 is used to determine the model verification result based on the tail probability, after the verifiable computational proof has been verified through the verification node.

[0130] The blockchain-based model verification device 200 described above will be explained in detail below: In some embodiments, the blockchain includes multiple blocks. The acquisition module 210 may specifically include at least one of the following: The first generation submodule is used to generate a random seed based on a verifiable random function; The location submodule is used to locate the latest block in the blockchain when a verification request is received; The first determining submodule is used to determine the hash value of the Mth block after the latest block as a random seed, where M is a positive integer.

[0131] In some embodiments, the sampling module 220 may specifically include: The sampling module is used to perform non-uniform random sampling on multiple second cryptographic commitments according to preset partitioning dimensions and preset sampling quantity constraints to obtain multiple commitments to be verified. The preset partitioning dimensions include at least one of inference request time, task complexity and request content type. Different preset partitioning dimensions correspond to different preset sampling quantity constraints. In some embodiments, the sample extraction module may specifically include: A hierarchical unit is used to divide multiple second cryptographic commitments into multiple levels according to a preset partitioning dimension. The first determining unit is used to determine the sampling quantity for each level based on the total sampling quantity, the number of levels, and the preset sampling quantity constraint. An extension unit is used to expand a random seed into multiple random seed sequences, wherein the number of random seed sequences is the same as the number of levels, and for each level, the number of random seeds in the random seed sequence is the same as the number of samples. The extraction unit is used to extract the commitment to be verified from multiple second cryptographic commitments corresponding to each level, based on a random seed sequence, to obtain multiple commitments to be verified.

[0132] In some embodiments, the first determining unit may specifically include at least one of the following: The first determining subunit is used to determine the number of samples for each level based on the ratio between the total number of samples and the number of levels, when the preset division dimension is the inference request time. The second determining subunit is used to determine the number of samples for each level based on the total number of samples, the number of levels, and the complexity level corresponding to the level, when the preset division dimension is task complexity. The number of samples is positively correlated with the complexity level. The third determining subunit is used to determine the sampling quantity of each level based on the total sampling quantity, the number of levels, and the detection rate corresponding to the level, when the preset division dimension is the request content type. The sampling quantity is negatively correlated with the detection rate, which represents the probability of successfully detecting the deviation when verifying a reasoning request that actually has a deviation.

[0133] In some embodiments, the expansion unit may specifically include: The first extended subunit is used to input a random seed into a deterministic pseudo-random number generation algorithm and output a random number sequence with a length equal to the total number of samples. The cutting subunit is used to sequentially cut the random number sequence into random seed sequences corresponding to each level according to the sampling quantity of each level.

[0134] In some embodiments, the expansion unit may specifically include: The generation sub-unit is used to input the random seed and the identification information of the level into the key derivation function for each level to generate the sub-random seed corresponding to the level; The second extended subunit is used to input the sub-random seed into the deterministic pseudo-random number generation algorithm and output a random seed sequence with a length equal to the number of samples in the hierarchy.

[0135] In some embodiments, the extraction unit may specifically include: The execution subunit is used to perform the following operations for each level: Obtain the number of tokens corresponding to multiple second cryptographic commitments within the hierarchy; The weight value is determined based on the number of lexical units, and the number of lexical units is positively correlated with the weight value. By summing up multiple weight values ​​in sequence, we obtain weight intervals corresponding to multiple second cryptographic commitments. The width of each weight interval is equal to the weight value of the second cryptographic commitment. Each random seed in the random seed sequence is mapped to multiple weight intervals to determine the target weight interval into which each random seed falls. The second cryptographic commitment corresponding to each target weight interval is determined as the commitment to be verified.

[0136] In some embodiments, the blockchain-based model verification device 200 may further include: The first computation module is used to perform cryptographic commitment computation on the reference model through the service provider node before obtaining a random seed that is unpredictable before verification and verifiable after verification by responding to the verification request initiated by the verification node through the on-chain verification layer, so as to obtain the first cryptographic commitment. The second sending module is used to send the service provider identifier of the service provider node, the first cryptographic commitment, and the model meta-information of the reference model to the on-chain verification layer through the service provider node; The first storage module is used to store the service provider identifier, the first cryptographic commitment, and the model metadata to the blockchain through the on-chain verification layer.

[0137] In some embodiments, the model validation system also includes service user nodes. Based on this, the blockchain-based model validation apparatus 200 may further include: The request module is used to initiate an inference request to the service provider node through the service user node before obtaining a random seed that is unpredictable before verification and verifiable after verification by responding to the verification request initiated by the verification node through the on-chain verification layer. The second inference module is used to respond to inference requests through the service provider node, execute the inference process corresponding to the inference request using the actual deployment model, and record the actual logical value vectors corresponding to each decision step. The second operation module is used to perform cryptographic commitment operations on the actual logical value vectors corresponding to each decision step through the service provider node to obtain the second cryptographic commitment. The third sending module is used to send the second cryptographic commitment, the service provider signature, the request identifier of the reasoning request, and the request time to the on-chain verification layer through the service provider node; The second storage module is used to store the second cryptographic commitment, the service provider's signature, the request identifier of the reasoning request, and the request time to the blockchain through the on-chain verification layer.

[0138] In some embodiments, the second computing module may specifically include: The first submodule is used to obtain a random salt value; The splicing submodule is used to splice the random salt value with the actual logical value vector corresponding to each decision step to obtain the data to be committed; The first operation submodule is used to perform cryptographic commitment operations on the data to be committed, so as to obtain the second cryptographic commitment.

[0139] In some embodiments, the commitment to be verified includes a random salt value. Based on this, the generation module 250 may specifically include: The second acquisition submodule is used to acquire the random salt value corresponding to the commitment to be verified and the actual logical value vector of each decision step; The second operation submodule is used to perform cryptographic commitment operations on the random salt value and the actual logical value vector of each decision step to obtain the third cryptographic commitment. The computation submodule is used to calculate the distance between the reference logical value vector and the actual logical value vector for each decision step in turn, when the third cryptographic commitment is the same as the commitment to be verified. The second determination submodule is used to determine the target distance that is greater than a preset distance among multiple distances; The third determination submodule is used to determine the tail probability based on the ratio of the number of decision steps corresponding to multiple target distances to the total number of decision steps. The second generation submodule is used to generate verifiable computational proofs based on the tail probability calculation process.

[0140] In some embodiments, the second inference module may specifically include: The recording submodule records the K largest actual logical values ​​of the target among multiple actual logical values ​​for each decision step, where K is a positive integer.

[0141] Based on this, the generation module 250 may specifically include: The fourth determination submodule is used to determine the tail probability based on the distance between the K target reference logic values ​​and the K target actual logic values ​​of each decision step corresponding to the commitment to be verified. For each decision step, the K target reference logic values ​​are the K largest values ​​among all the reference logic values ​​corresponding to the decision step.

[0142] In some embodiments, the blockchain stores integrity profiles of service provider nodes. Based on this, the blockchain-based model verification device 200 may further include: The fourth sending module is used to send the model verification result to the chain verification layer after the verifiable computational proof has been verified and the model verification result has been determined based on the tail probability through the verification node. The update module is used to update the integrity profile of service provider nodes based on the model verification results through the on-chain verification layer.

[0143] In some embodiments, the model validation system further includes a third-party query node. Based on this, the blockchain-based model validation device 200 may also include: The query module is used to initiate a profile query request for the target service provider node through a third-party query node; The fifth sending module is used to respond to the profile query request through the on-chain verification layer and return the integrity profile of the target service provider node to the third-party query node.

[0144] This application embodiment responds to verification requests through an on-chain verification layer, obtaining a random seed that is unpredictable before verification but verifiable after verification. This ensures that the generation process of the random seed is free from the control of any single entity. No verification node or service provider can predict or interfere with the value of the random seed before sampling, thereby eliminating the possibility of verification nodes unilaterally manipulating the sampling process and laying a credible foundation for the fairness of subsequent sampling. Furthermore, by storing the first cryptographic commitment of the reference model and the second cryptographic commitment of the actual deployed model on the blockchain, the model specification statement and the evidence of the reasoning process are publicly and immutably preserved. Any third party can independently verify the authenticity and completeness of the above commitments, and the service provider cannot later deny the model version or reasoning logic it actually used. Thus, the verification process of this application embodiment, from random seed generation, sampling execution, evidence preservation to result verification, is open, transparent, and verifiable by multiple parties, improving the reliability of model verification.

[0145] Based on the blockchain-based model verification method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 3 A schematic diagram of the structure of an electronic device provided in one embodiment of this application is shown.

[0146] like Figure 3 As shown, the electronic device 300 may include a processor 310 and a memory 320 storing computer program instructions.

[0147] Specifically, the processor 310 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0148] Memory 320 may include mass storage for data or instructions. For example, and not limitingly, memory 320 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where suitable, memory 320 may include removable or non-removable (or fixed) media. Where suitable, memory 320 may be internal or external to electronic device 300. In a particular embodiment, memory 320 is a non-volatile solid-state memory.

[0149] In specific embodiments, the memory 320 may be implemented as a read-only memory (ROM), random access memory (RAM), static storage device, dynamic storage device, etc. The memory 320 may store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 320 and executed by the processor 310. The processor 310 implements any of the blockchain-based model verification methods described in the above embodiments by reading and executing the computer program instructions stored in the memory 320.

[0150] The processor 310 reads and executes computer program instructions stored in the memory 320 to implement any of the blockchain-based model verification methods in the above embodiments.

[0151] In one example, the electronic device 300 may further include a communication interface 330 and a bus 340. For example, Figure 3 As shown, the processor 310, memory 320, and communication interface 330 are connected via bus 340 and communicate with each other.

[0152] The communication interface 330 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0153] Bus 340 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 340 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0154] For example, electronic device 300 can be a server, cloud computing node, etc.

[0155] The electronic device can execute the blockchain-based model verification method in the embodiments of this application, thereby achieving a combination Figure 1 The blockchain-based model verification method described, and the beneficial effects of the corresponding method implementation, will not be elaborated here.

[0156] Furthermore, in conjunction with the blockchain-based model verification methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the blockchain-based model verification methods in the above embodiments. Examples of such computer-readable storage media include non-transitory computer-readable storage media, such as read-only memory (ROM).

[0157] The computer program instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the blockchain-based model verification method as shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0158] Based on the blockchain-based model verification methods described in the above embodiments, this application provides a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, they implement any of the blockchain-based model verification methods described in the above embodiments.

[0159] The computer program products of the above embodiments are used to implement the blockchain-based model verification method as shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0160] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0161] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0162] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0163] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0164] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A blockchain-based model verification method, characterized in that, An application is made to a model validation system, which includes a blockchain, service provider nodes, and validation nodes. The blockchain includes an on-chain validation layer, and stores a first cryptographic commitment of a reference model and multiple second cryptographic commitments of the actual deployed model. The second cryptographic commitments include cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actual deployed model performs an inference task. The method includes: Through the on-chain verification layer, in response to the verification request initiated by the verification node, a random seed that is unpredictable before verification and verifiable after verification is obtained. Through the on-chain verification layer, based on the random seed, multiple commitments to be verified are extracted from the multiple second cryptographic commitments; The on-chain verification layer sends a proof generation request corresponding to the commitment to be verified to the service provider node. In response to the proof generation request, the service provider node executes the reasoning task corresponding to the commitment to be verified in a trusted execution environment using the reference model to obtain the reference logical value vector for each decision step. Through the service provider node, based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, the tail probability is determined and a verifiable computational proof is generated. The tail probability is the proportion of the number of decision steps whose distance exceeds a preset distance to the total number of decision steps. Through the verification node, if the verifiable computational proof passes verification, the model verification result is determined based on the tail probability.

2. The method according to claim 1, characterized in that, The blockchain comprises multiple blocks, and the acquisition of a random seed that is unpredictable before verification but verifiable after verification includes at least one of the following: The random seed is generated based on a verifiable random function; Locate the latest block in the blockchain at the time the verification request was received; determine the hash value of the Mth block after the latest block as the random seed, where M is a positive integer.

3. The method according to claim 1, characterized in that, The step of extracting multiple commitments to be verified from the plurality of second cryptographic commitments based on the random seed includes: Based on the random seed, the plurality of second cryptographic commitments are non-uniformly randomly sampled according to a preset partitioning dimension and a preset sampling quantity constraint to obtain the plurality of commitments to be verified. The preset partitioning dimension includes at least one of inference request time, task complexity and request content type, and the preset sampling quantity constraint is different for different preset partitioning dimensions.

4. The method according to claim 3, characterized in that, Based on the random seed, and according to a preset partitioning dimension and a preset sampling quantity constraint, non-uniform random sampling is performed on the plurality of second cryptographic commitments to obtain a plurality of commitments to be verified, including: The multiple second cryptographic commitments are layered according to the preset division dimension to obtain multiple levels; Based on the total number of samples, the number of levels, and the preset sampling quantity constraint, the sampling quantity for each level is determined. The random seed is expanded into multiple random seed sequences, wherein the number of random seed sequences is the same as the number of levels, and for each level, the number of random seeds in the random seed sequence is the same as the sampling number; For each level, based on the random seed sequence, a commitment to be verified is extracted from a plurality of second cryptographic commitments corresponding to the level, thus obtaining the plurality of commitments to be verified.

5. The method according to claim 4, characterized in that, The determination of the sampling quantity for each level based on the total sampling quantity, the number of levels, and the preset sampling quantity constraint includes at least one of the following: When the preset division dimension is the inference request time, for each level, the sampling quantity of the level is determined based on the ratio between the total sampling quantity and the number of levels; When the preset division dimension is the task complexity, for each level, the sampling quantity of the level is determined based on the total sampling quantity, the number of levels, and the complexity level corresponding to the level, and the sampling quantity is positively correlated with the complexity level; When the preset division dimension is the request content type, for each level, the sampling quantity of the level is determined based on the total sampling quantity, the number of levels, and the detection rate corresponding to the level. The sampling quantity is negatively correlated with the detection rate, which represents the probability of successfully detecting the deviation when verifying a reasoning request that actually has a deviation.

6. The method according to claim 4, characterized in that, Expanding the random seed into multiple random seed sequences includes: The random seed is input into a deterministic pseudo-random number generation algorithm, which outputs a random number sequence with a length equal to the total number of samples. According to the sampling quantity of each level, the random number sequence is sequentially cut into random seed sequences corresponding to each level.

7. The method according to claim 4, characterized in that, Expanding the random seed into multiple random seed sequences includes: For each level, the random seed and the level's identifier information are input into the key derivation function to generate a sub-random seed corresponding to that level; The sub-random seed is input into a deterministic pseudo-random number generation algorithm, which outputs a random seed sequence with a length equal to the number of samples at the level.

8. The method according to claim 4, characterized in that, For each level, based on the random seed sequence, the step of extracting a commitment to be verified from multiple second cryptographic commitments corresponding to that level includes: For each of the aforementioned levels, perform the following operations: Obtain the number of tokens corresponding to the plurality of second cryptographic commitments within the level; A weight value is determined based on the number of lexical units, and the number of lexical units is positively correlated with the weight value; The weight values ​​are summed sequentially to obtain the weight intervals corresponding to the multiple second cryptographic commitments, and the width of the weight interval is equal to the weight value of the second cryptographic commitment. Each random seed in the random seed sequence is mapped to a plurality of weight intervals, and the target weight interval into which each random seed falls is determined. The second cryptographic commitment corresponding to each of the target weight intervals is determined as the commitment to be verified.

9. The method according to claim 1, characterized in that, Before obtaining a random seed that is unpredictable before verification and verifiable after verification in response to a verification request initiated by the verification node through the on-chain verification layer, the method further includes: The first cryptographic commitment is obtained by performing a cryptographic commitment operation on the reference model through the service provider node. Through the service provider node, the service provider identifier of the service provider node, the first cryptographic commitment, and the model meta-information of the reference model are sent to the on-chain verification layer; The service provider identifier, the first cryptographic commitment, and the model metadata are stored in the blockchain through the on-chain verification layer.

10. The method according to claim 1, characterized in that, The model validation system also includes service user nodes. Before obtaining a random seed that is unpredictable before validation and verifiable after validation, in response to a validation request initiated by the validation node through the on-chain validation layer, the method further includes: Initiate an inference request to the service provider node through the service user node; Through the service provider node, in response to the inference request, the actual deployment model is used to execute the inference process corresponding to the inference request, and the actual logical value vector corresponding to each decision step is recorded. By performing cryptographic commitment operations on the actual logical value vectors corresponding to each decision step through the service provider node, a second cryptographic commitment is obtained; The service provider node sends the second cryptographic commitment, the service provider signature, the request identifier of the inference request, and the request time to the on-chain verification layer. The second cryptographic commitment, the service provider's signature, the request identifier of the reasoning request, and the request time are stored in the blockchain through the on-chain verification layer.

11. The method according to claim 10, characterized in that, The step of performing cryptographic commitment operations on the actual logical value vectors corresponding to each decision step to obtain a second cryptographic commitment includes: Get a random salt value; The random salt value is concatenated with the actual logical value vector corresponding to each decision step to obtain the data to be committed; A cryptographic commitment operation is performed on the data to be committed to, resulting in the second cryptographic commitment.

12. The method according to claim 11, characterized in that, The commitment to be verified includes the random salt value. The process of determining the tail probability and generating a verifiable computational proof based on the distance between the reference logical value vector and the actual logical value vector for each decision step corresponding to the commitment to be verified includes: Obtain the random salt value corresponding to the commitment to be verified and the actual logical value vector of each decision step; A third cryptographic commitment is obtained by performing a cryptographic commitment operation on the random salt value and the actual logical value vector of each decision step. If the third cryptographic commitment is the same as the commitment to be verified, the distance between the reference logical value vector and the actual logical value vector corresponding to each decision step is calculated sequentially. Determine a target distance that is greater than the preset distance from among the multiple distances; The tail probability is determined based on the ratio of the number of decision steps corresponding to multiple target distances to the total number of decision steps. Based on the calculation process of the tail probability, the verifiable calculation proof is generated.

13. The method according to claim 10, characterized in that, The vector of actual logical values ​​corresponding to each decision step includes: For each decision step, record the K largest target actual logical values ​​among multiple actual logical values, where K is a positive integer; The determination of tail probabilities based on the distance between the reference logical value vector and the actual logical value vector for each decision step corresponding to the commitment to be verified includes: The tail probability is determined based on the distance between the K target reference logic values ​​and the K target actual logic values ​​for each decision step corresponding to the commitment to be verified. For each decision step, the K target reference logic values ​​are the K largest values ​​among all reference logic values ​​corresponding to the decision step.

14. The method according to any one of claims 1-13, characterized in that, The blockchain stores the integrity profiles of the service provider nodes. After the verifiable computational proof is verified successfully by the verification node, and the model verification result is determined based on the tail probability, the method further includes: The model verification result is sent to the on-chain verification layer through the verification node; Based on the model verification results, the integrity profile of the service provider node is updated through the on-chain verification layer.

15. The method according to claim 14, characterized in that, The model verification system also includes a third-party query node. After storing the integrity profile on the blockchain through the on-chain verification layer, the method further includes: Through the aforementioned third-party query node, a profile query request is initiated targeting the service provider node; Through the on-chain verification layer, in response to the profile query request, the integrity profile of the target service provider node is returned to the third-party query node.

16. A blockchain-based model verification device, characterized in that, An apparatus is applied to a model validation system, the model validation system comprising a blockchain, service provider nodes, and validation nodes. The blockchain includes an on-chain validation layer, and stores a first cryptographic commitment of a reference model and multiple second cryptographic commitments of the actual deployed model. The second cryptographic commitments include cryptographic commitments corresponding to the actual logical value vectors of each decision step when the actual deployed model performs an inference task. The apparatus includes: The acquisition module is used to obtain a random seed that is unpredictable before verification and verifiable after verification in response to the verification request initiated by the verification node through the on-chain verification layer. The sampling module is used to extract multiple commitments to be verified from the multiple second cryptographic commitments based on the random seed through the on-chain verification layer. The first sending module is used to send a proof generation request corresponding to the commitment to be verified to the service provider node through the on-chain verification layer; The first reasoning module is used to respond to the proof generation request through the service provider node, and execute the reasoning task corresponding to the commitment to be verified in a trusted execution environment using the reference model to obtain the reference logical value vector of each decision step. The generation module is used to determine the tail probability based on the distance between the reference logical value vector and the actual logical value vector of each decision step corresponding to the commitment to be verified, through the service provider node, and generate a verifiable computational proof, wherein the tail probability is the proportion of the number of decision steps whose distance exceeds a preset distance to the total number of decision steps. The determination module is used to determine the model verification result based on the tail probability, provided that the verifiable computational proof has been verified successfully through the verification node.

17. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the blockchain-based model verification method as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the blockchain-based model verification method as described in any one of claims 1-15.

19. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the blockchain-based model verification method as described in any one of claims 1-15.

Images