Digital asset dynamic upgrade verification method and system based on cryptography commitment

Abstract

This invention relates to the field of cryptographic application technology for data security, specifically disclosing a method and system for dynamic upgrade verification of digital assets based on cryptographic commitments. The method involves: a server generating a first random seed and its cryptographic commitment value, which is stored in a blockchain smart contract; a client generating a second random seed and selecting a probability range before sending an upgrade request; the server using both seeds and a unique sequence number to calculate a final random number and generate a verifiable zero-knowledge proof that confirms the random number was generated by compliant computation from the first seed consistent with the on-chain commitment; the server submitting the proof, the random number, and the judgment result to the on-chain contract, and executing the asset upgrade operation after successful contract verification; finally, the server publicly disclosing the first random seed for independent audit verification by a third party. This invention transforms fairness verification from off-chain dependence to automated on-chain execution, achieving provable fairness, tamper-proofness, and efficient verifiability of the process.

Description

Technical Field

[0001] This invention relates to the field of cryptographic application technology for data security, specifically to a method and system for dynamic upgrade verification of digital assets based on cryptographic commitments. Background Technology

[0002] With the popularization of blockchain technology and the deepening application scenarios of digital assets such as non-fungible tokens (NFTs), interactive gameplay based on digital assets, such as "synthesis," "upgrading," or "enhancement," has become an important means to enhance user participation and asset liquidity. These gameplays typically involve probabilistic mechanisms, that is, after consuming specific assets or materials, a success or failure result is generated according to a preset probability.

[0003] Existing dynamic upgrade technologies for digital assets suffer from a fundamental lack of trust due to the opacity and unilateral controllability of the random number generation process. Specifically, existing solutions rely on the server having complete control over the random source and computation process, leaving users without cryptographic evidence to verify the fairness of the results. This makes the "probabilistic upgrade" mechanism susceptible to "black box" manipulation by the platform, severely hindering the credibility and healthy development of digital asset businesses. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for dynamic upgrade verification of digital assets based on cryptographic commitments, so as to solve the problems mentioned above.

[0005] The objective of this invention can be achieved through the following technical solutions: The method for dynamic upgrade verification of digital assets based on cryptographic commitments includes the following steps: S1: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters, and unique serial number in the blockchain smart contract; S2: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. S3: The server obtains the corresponding cryptographic commitment value, obfuscation parameters, and unique serial number based on the index information. It then uses the stored first random seed, second random seed, and unique serial number to perform calculations to obtain the final random number and determine whether it falls within the probability interval. In turn, it generates a verifiable zero-knowledge proof that includes the first random seed, obfuscation parameters, second random seed, unique serial number, probability interval parameters, and the final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by compliant calculations using the first random seed that matches the cryptographic commitment value. S4: The server submits the final random number, the judgment result, and the verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. S5: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

[0006] As a further aspect of the present invention: S1 specifically includes: The server generates multiple first random seed shards and generates corresponding shard obfuscation parameters for each first random seed shard; The server calculates the shard cryptographic commitment value for each first random seed shard and its corresponding shard obfuscation parameter, and submits and stores all shard cryptographic commitment values ​​and corresponding shard obfuscation parameters into the blockchain smart contract. After the client confirms receipt of the sharded cryptographic commitment value, the server performs cryptographic aggregation on multiple first random seed shards to generate a complete first random seed. Based on the complete first random seed and all sharding obfuscation parameters, the server calculates the final cryptographic commitment value and stores the final cryptographic commitment value, the complete first random seed, and the associated sharding obfuscation parameter digest information as a set of data records in the blockchain smart contract.

[0007] As a further aspect of the present invention: the calculation of the fragmented cryptographic commitment value specifically includes: The server generates a pair of first-stage obfuscation parameters and second-stage obfuscation parameters corresponding to the first random seed fragment; The server performs a first predetermined irreversible operation on the first random seed fragment and the first stage obfuscation parameters to obtain the primary obfuscation value; The server performs a second predetermined irreversible operation on the primary obfuscation value and the second-stage obfuscation parameters to obtain the intermediate commitment value; The server performs dynamic iterative obfuscation processing on the intermediate commitment value a preset number of times, and outputs the fragmented cryptographic commitment value.

[0008] As a further aspect of the present invention: S2 specifically includes: The client generates multiple independent second random seed shards locally, and generates a corresponding temporary obfuscation factor for each second random seed shard; The client performs an obfuscation operation on each second random seed shard and the corresponding temporary obfuscation factor to obtain an obfuscated shard set; The client performs sequential recombination and merging operations on the obfuscated set of fragments to generate a unique second random seed.

[0009] As a further aspect of the present invention: the obtained obfuscated fragment set specifically includes: The client performs a first-level nonlinear transformation on each second random seed slice and its corresponding temporary confusion factor to generate an initial confusion slice; The client performs a second-level dynamic cross-mixing operation on each initial obfuscated shard with a specific iterative obfuscation factor to obtain a deep obfuscated shard; The client aggregates and re-obfuscates all deeply obfuscated shards, outputting a set of obfuscated shards.

[0010] As a further aspect of the present invention: the generation process of the verifiable zero-knowledge proof specifically includes: The server combines the first random seed, the second random seed, the unique sequence number, and the obfuscation parameters in a hierarchical manner to generate the initial input structure for the zero-knowledge proof circuit. The server performs multiple rounds of asymmetric obfuscation on the initial input structure to generate intermediate proof parameters; The server constructs and runs a zero-knowledge proof generation algorithm based on the intermediate proof parameters, probability interval parameters, and the final random number, and outputs a verifiable zero-knowledge proof.

[0011] As a further aspect of the present invention: the construction and running of the zero-knowledge proof generation algorithm, which outputs verifiable zero-knowledge proofs, specifically includes: Based on intermediate proof parameters, probability interval parameters, and the final random number, a set of constraint conditions is generated to constrain the legality of circuit operations. The set of constraints is divided into multiple proof generation stages, and each stage is independently compiled and optimized to generate phased proof generation logic. The proof generation logic is executed in stages, and dynamic obfuscation factors are injected between stages to perform correlation obfuscation and generate preliminary proof data. The preliminary proof data is compressed and standardized in format to output the final verifiable zero-knowledge proof.

[0012] As a further aspect of the present invention: S4 specifically includes: Based on the format characteristics of verifiable zero-knowledge proofs, smart contracts match and determine the corresponding target verification strategy from a variety of preset verification strategies. Based on the target verification strategy, the verifiable zero-knowledge proof is subjected to layered verification, which sequentially completes structural verification, logical association verification, and final validity verification to obtain the layered verification results. The verification depth is dynamically adjusted based on the stratified verification results. Commitment summaries are generated for the parts that pass verification, and the final verification conclusion is generated based on all commitment summaries. Based on the final verification conclusion and judgment result, the smart contract triggers and completes the digital asset upgrade operation.

[0013] As a further aspect of the present invention: S5 specifically includes: After the digital asset upgrade operation is completed, the server generates a public verification token including the first random seed, and publicly anchors the cryptographic hash value of the verification token to the blockchain. The server splits the public verification token into multiple verification fragments and broadcasts these fragments to the verification network sequentially at preset time intervals. After any third-party verification node collects all verification fragments, it reconstructs the public verification token and verifies the consistency between its hash value and the on-chain anchor value. After the verification is successful, the first random seed is extracted. Third-party verification nodes use the extracted first random seed, second random seed, and unique sequence number to perform local reproduction calculations, compare the resulting random number with the final random number, generate a public verification conclusion, and record it on the blockchain.

[0014] A dynamic upgrade verification system for digital assets based on cryptographic commitments includes: Commitment generation and storage module: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters and unique serial number in the blockchain smart contract; Request Construction and Submission Module: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. The proof calculation and generation module: The server obtains the corresponding cryptographic commitment value, confusion parameter and unique sequence number based on the index information, performs calculations using the stored first random seed, second random seed and unique sequence number to obtain the final random number and determine whether it falls within the probability interval, and then generates a verifiable zero-knowledge proof including the first random seed, confusion parameter, second random seed, unique sequence number, probability interval parameter and final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by the first random seed that matches the cryptographic commitment value through compliant calculation; On-chain verification and execution module: The server submits the final random number, judgment result and verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. Transparency assurance and verification module: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

[0015] The beneficial effects of this invention are: (1) In traditional digital asset upgrade schemes, both random number generation and server-side computation are in a "black box" state invisible to users, posing a risk of unilateral manipulation of the results by the platform. This invention pre-locks the cryptographic commitment of the core parameter (first random seed) on the blockchain and combines it with the second random seed provided by the client to generate the final random number, ensuring that neither party can unilaterally change or predict the result afterward. Crucially, this invention introduces zero-knowledge proof technology, enabling the server to generate a cryptographic certificate proving the compliant generation of the random number without disclosing its secret seed; smart contracts can efficiently and automatically verify this certificate. This "off-chain computation, on-chain verification" model not only ensures that the algorithmic logic of the random process is public and non-repudiable, but also allows users to verify the fairness of the entire upgrade process solely through mathematics and code without trusting the server, thereby building a strong trust foundation based on cryptography rather than purely commercial reputation in digital asset interactions.

[0016] (2) In a blockchain environment, performing complex hash operations (such as HMAC-SHA512) and random number generation logic directly on the chain consumes high gas fees and is slow, making it difficult to support high-frequency applications. This invention completes the most time-consuming compliance calculation and proof generation process off-chain, submitting only lightweight zero-knowledge proofs and the final results on-chain for verification. This reduces on-chain computation overhead and transaction costs, enabling the solution to be applied economically and efficiently to large-scale, high-concurrency digital asset upgrade scenarios. Attached Figure Description

[0017] The invention will now be further described with reference to the accompanying drawings.

[0018] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system block diagram of the present invention. Detailed Implementation

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

[0020] Please see Figure 1 As shown, this invention is a method for dynamic upgrade verification of digital assets based on cryptographic commitments, comprising the following steps: S1: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters, and unique serial number in the blockchain smart contract; S2: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. S3: The server obtains the corresponding cryptographic commitment value, obfuscation parameters, and unique serial number based on the index information. It then uses the stored first random seed, second random seed, and unique serial number to perform calculations to obtain the final random number and determine whether it falls within the probability interval. In turn, it generates a verifiable zero-knowledge proof that includes the first random seed, obfuscation parameters, second random seed, unique serial number, probability interval parameters, and the final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by compliant calculations using the first random seed that matches the cryptographic commitment value. S4: The server submits the final random number, the judgment result, and the verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. S5: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

[0021] In S1, the server generates multiple first random seed fragments. Specifically, the server uses its embedded cryptographically secure random number generator to produce a sequence of raw random bytes of a specified length. Then, the server divides this raw byte sequence into multiple non-overlapping data segments according to a preset fixed-length or variable-length segmentation rule; these data segments are the first random seed fragments. The number of fragments can be preset according to security requirements, for example, set to 3 or 5.

[0022] The server generates corresponding shard obfuscation parameters for each generated first random seed shard. For each first random seed shard, the server independently calls a cryptographically secure random number generator to generate a random byte string with the same or different length as that shard; this random byte string is the shard obfuscation parameter for that shard. The obfuscation parameters for each shard are generated independently and are unrelated to each other.

[0023] The server calculates the cryptographic commitment value for each first random seed shard and its corresponding sharding obfuscation parameters. This calculation process is further subdivided into several sub-steps. First, for the current first random seed shard to be processed, the server generates a pair of additional obfuscation parameters associated with that shard, referred to as the first-stage obfuscation parameter and the second-stage obfuscation parameter. These two parameters are also independently generated by a cryptographically secure random number generator. Second, the server performs a first predetermined irreversible operation: concatenating the byte data of the current first random seed shard with the byte data of the first-stage obfuscation parameter, and then inputting the concatenated complete byte sequence into a selected cryptographic hash function (e.g., the SHA-256 function) for calculation. The resulting output hash value is the primary obfuscation value. Third, the server performs a second predetermined irreversible operation: concatenating the byte data of the primary obfuscation value obtained in the previous step with the byte data of the second-stage obfuscation parameter, and again inputting the concatenated byte sequence into the aforementioned cryptographic hash function for calculation. The resulting output hash value is the intermediate commitment value. The fourth step involves the server performing a preset number of dynamic iterative obfuscation operations on the intermediate commitment value: Using the intermediate commitment value as the initial input, the following operations are performed iteratively: The current input value is XORed with a obfuscation factor derived from the loop index and a fixed salt value at the byte level. The result is then input back into the aforementioned cryptographic hash function. This loop is executed a fixed positive integer, such as 10 times. The final output value obtained after the loop is the cryptographic commitment value corresponding to the first random seed shard. The server repeats the above process for all first random seed shards to obtain all cryptographic commitment values ​​for each shard.

[0024] After calculating all shard cryptographic commitment values, the server submits and persistently stores all shard cryptographic commitment values ​​and corresponding shard obfuscation parameters into the public state variables of the blockchain smart contract by calling a specific write interface. This constitutes the initial on-chain commitment to the shard information.

[0025] After the client confirms successful receipt and recording of all the aforementioned sharded cryptographic commitment values ​​by listening to blockchain events or directly querying the interface, the server proceeds to the next stage. The server cryptographically aggregates the multiple first random seed shards stored locally to generate a complete first random seed. Specifically, the aggregation can be done by concatenating the byte data of all shards sequentially in the original order of shard generation, forming a complete byte sequence. Then, based on this complete first random seed and all the sharding obfuscation parameters previously generated for all shards, the server calculates the final cryptographic commitment value. The calculation process is as follows: First, all sharding obfuscation parameters are concatenated into a total obfuscation parameter byte string according to the order of the corresponding shards; then, the complete first random seed byte string is concatenated with the total obfuscation parameter byte string; finally, the concatenated byte string is input into the aforementioned cryptographic hash function (e.g., the SHA-256 function) for calculation, and the resulting output hash value is the final cryptographic commitment value.

[0026] The server takes the calculated final cryptographic commitment value, the complete first random seed, and a digest of all associated sharding obfuscation parameters (e.g., the value obtained by hashing the concatenated string of all sharding obfuscation parameters again) and submits them together as an indivisible data record to the smart contract through another blockchain transaction, thus completing the entire commitment storage step.

[0027] In S2, the client generates multiple independent second random seed fragments locally. Specifically, the client calls a cryptographically secure random number generator provided by its environment to generate a raw random byte sequence of a specified total length. Then, the client sequentially divides this raw byte sequence into several consecutive and non-overlapping data blocks of a predetermined fixed length (e.g., 32 bytes per fragment). These data blocks constitute the multiple second random seed fragments. The number of fragments can be set according to implementation requirements, such as 3 or 5. After generating all fragments, the client independently generates a corresponding temporary obfuscation factor for each second random seed fragment. For each fragment, the client again calls the cryptographically secure random number generator to generate a random byte string of the same length as that fragment; this random byte string is the temporary obfuscation factor specific to that fragment.

[0028] The client performs an obfuscation operation on each second random seed fragment and its corresponding temporary obfuscation factor, aiming to obtain an obfuscated fragment set. This obfuscation operation is further refined into three sequentially executed sub-steps. The first step involves performing a first-level nonlinear transformation to generate preliminary obfuscated fragments. For the currently processed second random seed fragment and its temporary obfuscation factor, the client treats both data as arrays of multiple 8-bit bytes. Starting from the first byte of the array, the client processes each byte at its corresponding position sequentially: adding the integer value represented by the byte from the fragment to the integer value represented by the byte from the temporary obfuscation factor, then taking the modulo 256 to obtain a new integer value between 0 and 255, and then converting this new integer value back into a single byte. After processing all bytes in this manner, the resulting new byte array is the preliminary obfuscated fragment for that fragment. All fragments complete this step independently.

[0029] A second-level dynamic cross-mixing operation is performed to obtain a deep obfuscated fragment. The client generates a specific iterative obfuscation factor for the currently processed initial obfuscated fragment. This factor is a random byte string of the same length as the initial obfuscated fragment. Then, the client mixes the byte array of the initial obfuscated fragment with the byte array of the specific iterative obfuscation factor. The specific mixing rules are as follows: both arrays are divided equally into two halves (if the length is odd, the first half has one more byte than the second half). The first half of the initial obfuscated fragment bytes and the second half of the iterative obfuscation factor bytes are cyclically shifted and then XORed. Simultaneously, the second half of the initial obfuscated fragment bytes and the first half of the iterative obfuscation factor bytes are cyclically shifted and then XORed. Finally, the two results are swapped and reassembled. This process is repeated a preset number of times, such as 3 times. The byte array obtained after the loop is the deep obfuscated fragment corresponding to that fragment.

[0030] Aggregation and re-obfuscation are performed to output the final obfuscated set of fragments. Once all second-random seed fragments have completed the above two steps and been transformed into their corresponding deep obfuscated fragments, the client aggregates all deep obfuscated fragments. Aggregation is achieved by concatenating the byte data of all deep obfuscated fragments sequentially from beginning to end, following the original fragment order, to form a long aggregated byte string. Then, the client re-obfuscates this aggregated byte string: a cryptographic hash function (e.g., SHA-256) is called, the aggregated byte string is input into the hash function for calculation, and the resulting fixed-length (e.g., 32 bytes) hash output is used as a seed. A deterministic algorithm (e.g., the hash-based key derivation function HKDF) is used to derive a new byte sequence with the same total length as the original aggregated byte string. This new byte sequence is the final obfuscated set of fragments.

[0031] The client needs to generate a unique second random seed from the obfuscated set of shards. The client performs sequential recombination and merging operations on the obfuscated set of shards. Specifically, the client treats the obfuscated set of shards as a complete byte sequence and rearranges the byte order according to a predefined, non-contiguous recombination rule (e.g., extracting bytes at fixed indices, or reordering according to a pseudo-random permutation sequence), resulting in a recombined byte sequence. Then, the client uses this recombined byte sequence as input and calls the aforementioned cryptographic hash function (e.g., SHA-256) again for calculation. The resulting fixed-length hash value (e.g., a 32-byte hash value) is determined as the final, unique second random seed. The client encapsulates this second random seed, the user-selected probability interval parameter, and the index information pointing to the relevant commitment record in the blockchain smart contract into an upgrade request and sends it to the server.

[0032] In S3, the server retrieves the corresponding cryptographic commitment value, obfuscation parameters, and unique sequence number from the public state of the blockchain smart contract based on the index information carried in the client request. Then, the server uses its locally stored first random seed, the second random seed received from the client request, and the obtained unique sequence number to perform calculations to obtain the final random number. Specifically, the server concatenates the string representations of the first random seed, the second random seed, and the unique sequence number into a complete message string using agreed-upon delimiters. Then, using the first random seed as the key and the aforementioned message string as the message to be processed, the server performs a hash message authentication code calculation based on HMAC-SHA512, obtaining a 512-bit (64-byte) hash output. The server extracts the leftmost 15 hexadecimal characters (corresponding to 60 bits) of this hash output and converts this 15-character hexadecimal string into a large integer. Next, the server performs a modulo operation on this large integer divided by 100,000, obtaining an integer between 0 and 99,999. Finally, it adds 1 to this integer, resulting in a final random number within the range of 1 to 100,000. The server then determines whether this final random number falls within the numerical range specified by the client's probability interval parameter, thereby determining whether the upgrade was successful.

[0033] After completing random number generation and determination, the server begins generating verifiable zero-knowledge proofs. The first step is to construct the initial input structure for the zero-knowledge proof circuit. The server converts the first random seed, the second random seed, the unique sequence number, and the obfuscation parameters obtained from the blockchain into standard byte array formats. Then, the server combines them according to a predefined hierarchical order: the first layer is the byte array of the first random seed; the second layer is the byte array of the obfuscation parameters; the third layer is the byte array of the second random seed; and the fourth layer is the byte array of the unique sequence number. Before combining each layer of data, a prefix indicating its length is appended to its byte array (for example, using a 4-byte integer to represent the length of subsequent data). Finally, these four byte arrays with length prefixes are concatenated sequentially to form a single, structured byte sequence, which is the initial input structure.

[0034] The server performs multiple rounds of asymmetric obfuscation on the initial input structure to generate intermediate proof parameters. The server employs at least two rounds of processing. In the first round, the server uses a pre-generated, fixed obfuscation key A to perform byte-based cyclic XOR and position permutation operations with the byte sequence of the initial input structure. In the second round, the server uses another different, fixed obfuscation key B and introduces dynamic permutation rules (e.g., cyclic shifting of byte positions based on offsets calculated from certain characteristic values ​​of the first round's output bytes) to further perturb the first round's output. The specific operational logic of each round (such as the rules for XOR, permutation, and shifting) is pre-defined in the proof generation logic using hard-coded rules. The byte sequence obtained after these rounds of processing is defined as the intermediate proof parameters.

[0035] The server constructs and runs a zero-knowledge proof generation algorithm based on intermediate proof parameters, probability interval parameters, and the final random number to output the final proof. This process is divided into several sub-steps. First, a set of constraints is generated based on the aforementioned parameters. This set includes: a first constraint, used to verify that the cryptographic commitment value stored on the chain can be correctly calculated from the first random seed and obfuscation parameters; the logic is to check whether the hash value after concatenating the first random seed and obfuscation parameters is equal to the known cryptographic commitment value; a second constraint, used to verify whether the result obtained by using the first random seed, the second random seed, and the unique sequence number, through specified HMAC-SHA512, truncation, base conversion, and modulo plus one operation, is equal to the final random number; and a third constraint, used to verify whether the final random number lies between (including) the lower and upper bound values ​​defined by the probability interval parameters. These constraints together constitute the logical relationships that the circuit needs to satisfy.

[0036] The aforementioned set of constraints is divided into multiple proof generation stages. For example, it can be divided into three stages: the first stage handles constraints related to the calculation of the commitment value; the second stage handles complex computational constraints related to the calculation of the final random number; and the third stage handles numerical range determination constraints. For each stage, the server uses a domain-specific language for zero-knowledge proofs (such as Circom or Zokrates) to write the corresponding circuit logic code, and calls the corresponding compiler to independently compile and optimize the circuit logic for that stage, generating the proof generation logic module corresponding to that stage, which includes the circuit constraint system and the witness generation logic.

[0037] The server executes these phased proof generation logics sequentially. It first inputs the corresponding secret data (such as the first random seed) and public data into the first-stage circuit to generate the first-stage proof component. Before entering the second stage, the server injects a dynamic obfuscation factor, calculated by mixing certain output bytes from the first stage with the hash value of the current timestamp. The server incorporates this dynamic obfuscation factor as additional public input into the second-stage circuit logic, thereby establishing correlation obfuscation between stages. Similarly, a similar operation is performed between the second and third stages. Finally, the proof components from all stages are combined with the relevant public input data to form the preliminary proof data.

[0038] The server compresses and standardizes the initial proof data. The compression process uses a lossless compression algorithm (such as Zstandard) to compress recurring pattern bytes in the proof data. Standardization arranges the compressed data according to a publicly available, predefined proof data encapsulation format. This format typically includes fields such as version number, proof byte stream length, the proof byte stream itself, and public parameter hashes. The complete data packet organized according to this format constitutes the final verifiable zero-knowledge proof.

[0039] In S4, after the server submits the final random number, the judgment result, and the verifiable zero-knowledge proof to the blockchain network through a transaction, the target smart contract deployed on the chain is triggered for execution. The contract first determines the corresponding target verification strategy by matching it against a variety of preset verification strategies based on the format characteristics of the received verifiable zero-knowledge proof. The preset verification strategies are stored in the contract state in the form of a mapping table, where the key is a specific identifier in the proof data packet header (e.g., a 2-byte version number), and the value is the entry address pointing to different verification function logic within the contract. The contract parses the proof data, extracts the identifier, and searches it in the mapping table to locate and select the specific function logic to be executed for this verification, i.e., the target verification strategy.

[0040] Based on the selected target verification strategy, the smart contract performs layered verification of verifiable zero-knowledge proofs. The first layer is structural verification: the contract checks whether the overall format of the proof data conforms to predefined specifications, including checking the existence of each field (such as version number, proof body length, public parameters, etc.), whether the length is within the allowed range, and whether the encoding is correct. The second layer is logical consistency verification: the contract verifies the logical consistency between different parts within the proof data. For example, it calculates the hash values ​​of the public input parameters included in the proof and compares them with the hashes of the public parameters declared in the proof data; if they do not match, the verification fails. The third layer is final validity verification: this is the core verification step. The contract calls the zero-knowledge proof verification function corresponding to the target verification strategy. This function receives the proof byte stream parsed from the proof data and all public input parameters (including the final random number, probability interval parameter boundaries, cryptographic commitment values, etc.) as input, and performs verification calculations specific to the zero-knowledge proof scheme (e.g., the Groth16 scheme). This calculation process involves bilinear pairing operations on elliptic curves, the logic of which is fixed, i.e., checking whether several pairing equations hold true. The three layers of verification are performed sequentially. If any layer fails, the process terminates immediately and returns a verification failure result. Only when all layers pass can a successful layered verification result be obtained.

[0041] Based on the results of the layered verification, the smart contract dynamically adjusts the verification depth. If the structural verification or logical correlation verification fails, the contract will not execute the computationally intensive final validity verification, thus saving computational resources. For the verified parts, the contract generates corresponding commitment digests to ensure the process is tamper-proof. For example, after passing structural verification, the contract concatenates the structural feature fields of the proof data and calculates their hash values ​​as structural commitment digests; after passing logical correlation verification, the contract uses the hash values ​​of the verified and consistent public parameters as logical commitment digests. Finally, the contract combines all generated commitment digests (e.g., structural and logical commitment digests) with the success signal of the final validity verification to generate a unique final verification conclusion hash value.

[0042] Based on the final verification conclusion and the judgment result submitted by the server, the smart contract triggers and completes the digital asset upgrade operation. Specifically, the contract first confirms that the hash value of the final verification conclusion indicates successful verification. Then, based on the judgment result (a boolean value representing success or failure), the contract calls a specific interface of another smart contract associated with it, responsible for managing the specific digital asset. During the call, parameters such as the unique serial number for this upgrade, the final random number, and the target asset identifier are passed in. If the judgment is successful, the asset contract executes the logic of minting new assets and destroying old assets; if the judgment is unsuccessful, it only executes the logic of destroying old assets or deducting materials. All the above contract calls and state changes are atomically completed within the same blockchain transaction.

[0043] In S5, after a blockchain smart contract completes a digital asset upgrade operation (such as minting new assets or destroying old assets), the server executes the public process of generating the first random seed. First, the server generates a public verification token that includes the first random seed. This token is a structured data packet, specifically composed of: the first part is the complete byte data of the first random seed itself; the second part is a high-precision timestamp recording the public release time; the third part is a unique sequence number associated with this upgrade; and the fourth part is the result of the server digitally signing the combination of the first three parts using its private key. After generating the token, the server immediately calculates its cryptographic hash value. Specifically, it takes the entire token's byte data as input, uses the SHA-256 hash function, and obtains a 256-bit hash output. Subsequently, the server submits this hash value as part of a transaction's data and permanently records it on the blockchain by calling an interface of a blockchain smart contract dedicated to recording audit information. This process is called anchoring.

[0044] The server splits the complete public verification token into multiple verification fragments. Specifically, the server employs a secret-sharing algorithm (such as the Shamir secret-sharing scheme), using the token's byte data as secret input. The server sets a threshold, for example, that collecting any 3 out of 5 fragments is sufficient to reconstruct the secret. The algorithm outputs multiple (e.g., 5) fragments of the same length but different content. The server broadcasts these verification fragments sequentially to the verification network via a peer-to-peer network or public broadcast channel at preset time intervals (e.g., every 60 seconds). Each broadcast message includes one fragment of data and its index number.

[0045] Any verification node operating as a third party can listen to and collect verification shards broadcast by the server. When the number of shards collected by the node reaches the reconstruction threshold set by the secret sharing algorithm (e.g., collecting any 3 shards), the reconstruction function of the algorithm can be run. The node takes the collected shards and their indices as input, and the algorithm outputs the original public verification token byte data. The node then immediately calculates the SHA-256 hash value of the reconstructed token data and obtains the hash value pre-anchored by the server by querying the smart contract state recorded in step S1 on the blockchain. The node compares these two hash values; if they match exactly, the verification passes, confirming the authenticity of the reconstructed token; if they do not match, the process terminates. After successful verification, the node extracts the first random seed from the first part of the token data structure.

[0046] The third-party verification node uses the extracted first random seed, a second random seed known from blockchain history or public logs, and a unique sequence number to completely replicate the random number generation operation described in step S3 locally. The operation is as follows: using the first random seed as the key, and the message formed by concatenating the second random seed, a separator string, and the unique sequence number as input, performs HMAC-SHA512 calculation. The first 60 bits of the result are truncated and converted to an integer, then modulo 100000 and incremented by 1 to obtain a locally calculated random number. The node compares this locally calculated result with the final random number submitted by the server and recorded on the blockchain. If the two values ​​are exactly the same, a conclusion indicating successful verification is generated; if they are different, a conclusion indicating verification failure is generated. The node uses this binary conclusion (success or failure), the unique sequence number of this verification, and its own identity identifier as input to a transaction, calling the blockchain smart contract that records audit information to permanently and immutably record this public verification conclusion in the blockchain's event log for all participants to review.

[0047] Please see Figure 2 As shown, the dynamic upgrade verification system for digital assets based on cryptographic commitments includes: Commitment generation and storage module: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters and unique serial number in the blockchain smart contract; Request Construction and Submission Module: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. The proof calculation and generation module: The server obtains the corresponding cryptographic commitment value, confusion parameter and unique sequence number based on the index information, performs calculations using the stored first random seed, second random seed and unique sequence number to obtain the final random number and determine whether it falls within the probability interval, and then generates a verifiable zero-knowledge proof including the first random seed, confusion parameter, second random seed, unique sequence number, probability interval parameter and final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by the first random seed that matches the cryptographic commitment value through compliant calculation; On-chain verification and execution module: The server submits the final random number, judgment result and verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. Transparency assurance and verification module: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

[0048] The working principle of this invention is as follows: First, the server shards the first random seed and combines it with obfuscation parameters to generate shards and the final cryptographic commitment value, which, along with a unique sequence number, are pre-stored in the blockchain smart contract. Second, the client locally shards and obfuscates the second random seed to generate a unique seed, and, combined with selected probability interval parameters, sends an upgrade request to the server, including a pointer to the on-chain commitment index. Next, the server retrieves on-chain data based on the index, calculates the final random number using the first random seed, the client seed, and the unique sequence number, and determines the result. It then constructs and runs a zero-knowledge proof generation algorithm to produce a verifiable zero-knowledge proof that confirms the random number was generated by compliant computation and matches the on-chain commitment. Finally, the server submits this proof, the final random number, and the determination result to the on-chain smart contract. The contract efficiently verifies the validity of the proof using a layered verification strategy and atomically executes the corresponding asset upgrade operation after successful verification. Finally, after the operation is completed, the server discloses the first random seed by generating, sharding and broadcasting, and finally reconstructing the public verification token. This allows any third party to independently reproduce the calculation process, verify the correctness of the random number, and permanently record the verification result on the chain, thus building a complete trust loop from pre-commitment and process verification to post-auditability.

[0049] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A method for dynamic upgrade verification of digital assets based on cryptographic commitments, characterized in that, Includes the following steps: S1: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters, and unique serial number in the blockchain smart contract; S2: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. S3: The server obtains the corresponding cryptographic commitment value, obfuscation parameters, and unique serial number based on the index information. It then uses the stored first random seed, second random seed, and unique serial number to perform calculations to obtain the final random number and determine whether it falls within the probability interval. In turn, it generates a verifiable zero-knowledge proof that includes the first random seed, obfuscation parameters, second random seed, unique serial number, probability interval parameters, and the final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by compliant calculations using the first random seed that matches the cryptographic commitment value. S4: The server submits the final random number, the judgment result, and the verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. S5: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

2. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 1, characterized in that, S1 specifically includes: The server generates multiple first random seed shards and generates corresponding shard obfuscation parameters for each first random seed shard; The server calculates the shard cryptographic commitment value for each first random seed shard and its corresponding shard obfuscation parameter, and submits and stores all shard cryptographic commitment values ​​and corresponding shard obfuscation parameters into the blockchain smart contract. After the client confirms receipt of the sharded cryptographic commitment value, the server performs cryptographic aggregation on multiple first random seed shards to generate a complete first random seed. Based on the complete first random seed and all sharding obfuscation parameters, the server calculates the final cryptographic commitment value and stores the final cryptographic commitment value, the complete first random seed, and the associated sharding obfuscation parameter digest information as a set of data records in the blockchain smart contract.

3. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 2, characterized in that, The calculation of the fragmented cryptographic commitment value specifically includes: The server generates a pair of first-stage obfuscation parameters and second-stage obfuscation parameters corresponding to the first random seed fragment; The server performs a first predetermined irreversible operation on the first random seed fragment and the first stage obfuscation parameters to obtain the primary obfuscation value; The server performs a second predetermined irreversible operation on the primary obfuscation value and the second-stage obfuscation parameters to obtain the intermediate commitment value; The server performs dynamic iterative obfuscation processing on the intermediate commitment value a preset number of times, and outputs the fragmented cryptographic commitment value.

4. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 1, characterized in that, Specifically, S2 includes: The client generates multiple independent second random seed shards locally, and generates a corresponding temporary obfuscation factor for each second random seed shard; The client performs an obfuscation operation on each second random seed shard and the corresponding temporary obfuscation factor to obtain an obfuscated shard set; The client performs sequential recombination and merging operations on the obfuscated set of fragments to generate a unique second random seed.

5. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 4, characterized in that, The obtained obfuscated fragment set specifically includes: The client performs a first-level nonlinear transformation on each second random seed slice and its corresponding temporary confusion factor to generate an initial confusion slice; The client performs a second-level dynamic cross-mixing operation on each initial obfuscated shard with a specific iterative obfuscation factor to obtain a deep obfuscated shard; The client aggregates and re-obfuscates all deeply obfuscated shards, outputting a set of obfuscated shards.

6. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 1, characterized in that, The process of generating the verifiable zero-knowledge proof specifically includes: The server combines the first random seed, the second random seed, the unique sequence number, and the obfuscation parameters in a hierarchical manner to generate the initial input structure for the zero-knowledge proof circuit. The server performs multiple rounds of asymmetric obfuscation on the initial input structure to generate intermediate proof parameters; The server constructs and runs a zero-knowledge proof generation algorithm based on the intermediate proof parameters, probability interval parameters, and the final random number, and outputs a verifiable zero-knowledge proof.

7. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 6, characterized in that, The construction and running of the zero-knowledge proof generation algorithm, which outputs verifiable zero-knowledge proofs, specifically includes: Based on intermediate proof parameters, probability interval parameters, and the final random number, a set of constraint conditions is generated to constrain the legality of circuit operations. The set of constraints is divided into multiple proof generation stages, and each stage is independently compiled and optimized to generate phased proof generation logic. The proof generation logic is executed in stages, and dynamic obfuscation factors are injected between stages to perform correlation obfuscation and generate preliminary proof data. The preliminary proof data is compressed and standardized in format to output the final verifiable zero-knowledge proof.

8. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 1, characterized in that, S4 specifically includes: Based on the format characteristics of verifiable zero-knowledge proofs, smart contracts match and determine the corresponding target verification strategy from a variety of preset verification strategies. Based on the target verification strategy, the verifiable zero-knowledge proof is subjected to layered verification, which sequentially completes structural verification, logical association verification, and final validity verification to obtain the layered verification results. The verification depth is dynamically adjusted based on the stratified verification results. Commitment summaries are generated for the parts that pass verification, and the final verification conclusion is generated based on all commitment summaries. Based on the final verification conclusion and judgment result, the smart contract triggers and completes the digital asset upgrade operation.

9. The method for dynamic upgrade verification of digital assets based on cryptographic commitment according to claim 1, characterized in that, S5 specifically includes: After the digital asset upgrade operation is completed, the server generates a public verification token including the first random seed, and publicly anchors the cryptographic hash value of the verification token to the blockchain. The server splits the public verification token into multiple verification fragments and broadcasts these fragments to the verification network sequentially at preset time intervals. After any third-party verification node collects all verification shards, it reconstructs the public verification token and verifies the consistency between its hash value and the on-chain anchor value. After the verification is successful, the first random seed is extracted. Third-party verification nodes use the extracted first random seed, second random seed, and unique sequence number to perform local reproduction calculations, compare the resulting random number with the final random number, generate a public verification conclusion, and record it on the blockchain.

10. A dynamic upgrade verification system for digital assets based on cryptographic commitments, characterized in that, The method for performing dynamic upgrade verification of digital assets based on cryptographic commitment as described in any one of claims 1-9 includes: Commitment generation and storage module: The server generates a first random seed and obfuscation parameters, generates a cryptographic commitment value based on the first random seed and obfuscation parameters, and records the cryptographic commitment value, obfuscation parameters and unique serial number in the blockchain smart contract; Request Construction and Submission Module: The client generates a second random seed and selects a probability interval parameter, and sends an upgrade request to the server. The upgrade request includes the second random seed, the probability interval parameter, and the index information pointing to the corresponding record in the blockchain smart contract. The proof calculation and generation module: The server obtains the corresponding cryptographic commitment value, confusion parameter and unique sequence number based on the index information, performs calculations using the stored first random seed, second random seed and unique sequence number to obtain the final random number and determine whether it falls within the probability interval, and then generates a verifiable zero-knowledge proof including the first random seed, confusion parameter, second random seed, unique sequence number, probability interval parameter and final random number. The verifiable zero-knowledge proof confirms that the final random number is generated by the first random seed that matches the cryptographic commitment value through compliant calculation; On-chain verification and execution module: The server submits the final random number, judgment result and verifiable zero-knowledge proof to the blockchain smart contract. The blockchain smart contract verifies the verifiable zero-knowledge proof and executes the digital asset upgrade operation corresponding to the judgment result after successful verification. Transparency assurance and verification module: After the digital asset upgrade operation is completed, the server publishes the first random seed so that third parties can use the published first random seed, second random seed and unique serial number to reproduce the calculation and verify the correctness of the final random number.

Images