An asset blockchain trusted right transaction management method and system

Abstract

This invention discloses a trusted asset blockchain transaction management method and system, relating to the field of blockchain technology. It aims to solve the technical problems in asset blockchain transactions, such as reliance on centralized entities for fund verification, leakage of account balance privacy, and the difficulty in balancing decentralized verification and privacy protection. The method includes: obtaining a non-interactive zero-knowledge range proof for the corresponding asset transaction to be confirmed, wherein the non-interactive zero-knowledge range proof is generated by the security domain of a supervising bank and is used to prove that the actual available balance of the supervising account is not less than the corresponding transaction amount threshold without disclosing the value of the actual available balance; and receiving partial signature shares generated by each node in the decentralized oracle network for the non-interactive zero-knowledge range proof. This invention has the advantages of balancing privacy protection and compliance verification, eliminating single-point trust risks, and forming an immutable audit trail.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically, to a method and system for managing trusted asset blockchain transactions. Background Technology

[0002] In online transactions of assets such as rural collective property rights, ensuring that the transferee receives full payment is a core prerequisite for completing the asset confirmation and transfer. Traditionally, centralized regulatory banks issue payment receipts to the trading platform. This approach has two significant drawbacks: First, if the issuer of the centralized receipt provides false confirmation due to internal errors, system malfunctions, or malicious behavior, the trading platform lacks the technical means to independently verify it, making the entire transaction's credibility dependent on a single entity. Second, to prove that funds have been received, banks often need to disclose the account's actual available balance or the specific amount credited to the account. In cases of multiple concurrent transactions and accounts involving multiple parties, this exposes a large amount of commercially sensitive information to the trading platform and counterparties, severely violating the principle of minimizing data disclosure and increasing the risk of information leakage and unfair competition.

[0003] The development of blockchain technology and smart contracts provides a decentralized execution environment for asset ownership confirmation. However, it cannot directly perceive the status of off-chain fiat currency funds and must rely on oracles as a bridge for external data import. Most existing oracle solutions involve a single or a few nodes collecting bank data and signing it onto the blockchain. Once an oracle node is compromised or colludes to falsify data, the on-chain contract will unconditionally accept false claims of fund arrival, resulting in erroneous asset delivery before the funds have actually arrived. Other solutions attempt to improve credibility by using multi-node data collection and multi-signature, but multi-signature verification still requires each node to obtain and transmit the plaintext account balance, failing to eliminate the risk of privacy leaks and instead expanding the information exposure due to the increased number of nodes. Some solutions introduce zero-knowledge proofs for scope verification, but these are typically only applicable to scenarios where a single party issues a proof, lacking effective integration with the multi-party witnessing mechanism of decentralized oracle networks. This means the trusted input source for zero-knowledge proofs remains a centralized entity, failing to form an end-to-end trust loop in a distributed transaction environment. Therefore, we propose a method and system for managing trusted asset ownership confirmation transactions on the blockchain. Summary of the Invention

[0004] The purpose of this invention is to provide a trusted asset blockchain transaction management method and system to solve the technical problems in asset blockchain transactions, such as reliance on centralized entities for fund verification, leakage of account balance privacy, and difficulty in balancing decentralized verification and privacy protection.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a method for managing trusted asset blockchain transactions, comprising: Obtain a non-interactive zero-knowledge scope proof for the corresponding asset transaction to be confirmed. The non-interactive zero-knowledge scope proof is generated by the security domain of the supervising bank and is used to prove that the actual available balance of the supervising account is not less than the amount threshold of the corresponding transaction and does not disclose the value of the actual available balance. Receive partial signature shares generated by each node in the decentralized oracle network for the non-interactive zero-knowledge range proof, wherein the partial signature shares are generated by each node using its own threshold signature private key share after verifying the non-interactive zero-knowledge range proof. When the number of valid partial signature shares reaches a preset threshold, a threshold aggregate signature is generated and the validity of the non-interactive zero-knowledge scope proof is independently verified. If the verification is successful, a credible confirmation certificate of sufficient funds is generated, triggering the asset transaction management smart contract to execute the confirmation of ownership of the asset to be confirmed.

[0006] Preferably, the non-interactive zero-knowledge scope proof is generated by a trusted execution environment within the security domain of the supervising bank, and is bound to a unique identifier of the asset transaction to be confirmed during generation. Each non-interactive zero-knowledge scope proof is only valid for the corresponding transaction.

[0007] Preferably, the partial signature share is generated by each oracle node in the following manner: After each node locally verifies the non-interactive zero-knowledge range proof using the public verification parameters shared with the proof generator, it generates a partial signature share for the message body containing the hash value of the non-interactive zero-knowledge range proof, the unique identifier of the asset transaction to be confirmed, the current trusted timestamp, and the node identifier, using its own threshold signature private key share.

[0008] Preferably, the step of independently verifying the validity of the non-interactive zero-knowledge scope proof specifically involves: using public verification parameters shared with the proof generator to perform cryptographic verification on the non-interactive zero-knowledge scope proof, confirming that the statement that the actual available balance of the regulatory account is not less than the amount threshold of the corresponding transaction is valid.

[0009] Preferably, it also includes: if the number of valid partial signatures collected within the preset waiting period does not reach the preset threshold, the fund verification is determined to have failed, an insufficient fund event notification is generated in the asset transaction management smart contract, and the locked status of the asset to be confirmed is released.

[0010] Preferably, after generating a credible confirmation certificate of sufficient funds, the method further includes: packaging the threshold aggregate signature, the hash value of the non-interactive zero-knowledge scope proof, the verification timestamp, and the unique identifier of the asset transaction to be confirmed as an on-chain evidence record and writing it into the blockchain ledger for independent verification of the sufficient funds conclusion by a third party.

[0011] Preferably, before the smart contract for triggering the asset transaction management executes the asset confirmation operation, the process further includes: classifying the assets to be confirmed according to their appraised value, executing a negotiated transaction process for assets below a preset limit, and executing a public auction process for assets exceeding a preset limit.

[0012] Preferably, the decentralized oracle network is a permissioned oracle network, where each node must undergo on-chain identity authentication and authorization to join, and each node transmits non-interactive zero-knowledge scope proofs with the regulatory bank's security domain through a two-way encrypted channel.

[0013] Preferably, it also includes: receiving an updated non-interactive zero-knowledge scope proof generated by the supervisory bank's security domain when the actual available balance of the supervisory account is lower than the amount threshold, terminating the currently incomplete fund verification process, and restarting the verification based on the updated non-interactive zero-knowledge scope proof.

[0014] A trusted asset blockchain transaction management system includes a zero-knowledge proof generation module deployed in the security domain of a regulatory bank, a decentralized oracle network, an aggregated verification smart contract deployed on the blockchain network, and an asset transaction management smart contract.

[0015] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention generates a non-interactive zero-knowledge scope proof within the security domain of a regulated bank using a zero-knowledge proof generation module. This proof mathematically asserts that the actual available balance of the regulated account is not less than a preset threshold, without revealing any numerical information about the actual available balance. After obtaining this proof, each node in the oracle network only needs to verify its correctness, without accessing the plaintext account balance, thus cutting off the path for balance information to be leaked to trading platforms and trading participants. Simultaneously, the aggregated verification smart contract independently verifies the validity of the zero-knowledge scope proof, ensuring that the authenticity of the "sufficiency" claim withstands cryptographic verification. This ensures that compliant fund verification no longer comes at the expense of commercial privacy, meeting the stringent requirements for minimal data disclosure under a highly regulated environment.

[0016] 2. This invention also utilizes a group of independent oracle nodes to form a decentralized oracle network. Each node performs verification operations on the same zero-knowledge scope proof and generates its own partial signature share based on a threshold signature mechanism. The aggregated verification smart contract only aggregates a threshold aggregated signature that represents the network's collective consensus after collecting a preset threshold number of valid partial signature shares. The failure, breach, or malicious behavior of any node cannot forge a valid overall signature certificate on its own, and the on-chain contract no longer relies on the honesty of any centralized data source or a single oracle node. This architecture, which integrates distributed witnessing and threshold aggregation, transforms the reliable confirmation of fund arrival from trust in a single point to trust in the majority of independent nodes in the network, significantly improving the system's risk resistance and overall robustness.

[0017] 3. After completing threshold aggregate signature generation and zero-knowledge scope proof verification, the aggregate verification smart contract of this invention packages the aggregate signature, proof hash value, verification timestamp, and transaction identifier into an on-chain evidence record and writes it into the blockchain ledger. This evidence record has the characteristics of being immutable and permanently traceable. Any regulatory agency or transaction participant can independently verify the mathematical correctness of the conclusion of sufficient funds and the validity of the signature through publicly available verification parameters and on-chain data, without relying on the system operator's explanation or backend data. This mechanism constructs a complete cryptographic evidence chain for each asset transaction, from fund receipt, proof generation, multi-party verification to final confirmation of rights, significantly enhancing the post-transaction audit capability and dispute resolution efficiency, and providing transparent and reliable technical support for compliance supervision. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the overall process of the asset blockchain trusted ownership confirmation transaction management method of the present invention; Figure 2 This is a schematic diagram illustrating the process of generating zero-knowledge scope proofs and oracle partial signatures in this invention. Figure 3 This is a schematic diagram of the process for aggregated verification of smart contracts in this invention; Figure 4 This is a schematic diagram illustrating the process of confirming and transferring ownership of the asset transaction management smart contract of this invention. Detailed Implementation

[0019] To facilitate understanding of the technical solution of the present invention by those skilled in the art, the technical solution of the present invention will now be further described in conjunction with the accompanying drawings.

[0020] Example 1, such as Figures 1-4 As shown, the present invention provides an asset blockchain trusted ownership confirmation and transaction management system, the system comprising: A zero-knowledge proof generation module deployed within the security domain of a supervising bank; A decentralized oracle network consisting of a set of independent oracle nodes; Aggregated verification smart contracts deployed on a blockchain network; Asset transaction management smart contracts are interconnected with aggregated verification smart contracts.

[0021] In this embodiment of the invention, the collaborative work of the above modules constructs an end-to-end trusted rights confirmation channel. Its core operating logic lies in deconstructing the traditionally centralized act of off-chain fund verification, which relies on a single authoritative party, into three decentralized stages enforced by cryptography: the regulatory bank's security domain is responsible for generating a zero-knowledge proof that can self-prove sufficient funds without disclosing the balance; the decentralized oracle network plays a distributed verification and endorsement role, with multiple independent nodes performing local verification of the proof and expressing consensus in the form of threshold partial signatures; the aggregated verification smart contract acts as the final on-chain arbitrator, only formally issuing an irrevocable certificate to drive the asset transaction management smart contract to execute rights confirmation after collecting a sufficient number of valid node signatures and independently completing on-chain verification of the zero-knowledge proof. The entire process does not require trust in any single entity, and only cryptographic evidence of "sufficient funds" circulates on-chain, rather than any sensitive account balance value, solving the core problems of single-point trust risk, potential malicious data source attacks, and privacy leaks in traditional solutions.

[0022] As a specific implementation, when this system is applied to rural collective property rights transactions, the off-chain trigger source is the transferee's full remittance of the transaction funds into a dedicated supervisory account opened by the supervising bank. After the supervising bank's core banking system captures the fund inflow event bound to a unique transaction identifier, it triggers the zero-knowledge proof generation module to initiate the proof generation process. Subsequently, each authorized independent node in the oracle network deployed on the permissioned consortium blockchain obtains proof from the supervising bank, verifies it locally, generates a partial signature share, and submits it to the aggregation verification smart contract. The contract aggregates the signature and verifies the zero-knowledge proof on-chain, generating a credible confirmation certificate of sufficient funds. Finally, upon receiving the certificate, the asset transaction management smart contract automatically updates the ownership status field of the corresponding standardized on-chain asset card for land management rights or forest rights from "pending confirmation" to "confirmed," triggering the transfer of ownership from the transferor to the transferee. The entire process achieves a cryptographically trusted closed loop from "funds in place" to "ownership transfer."

[0023] In one embodiment, the zero-knowledge proof generation module runs in a trusted execution environment within the security domain of the supervising bank. The non-interactive zero-knowledge scope proof is constructed using a zero-knowledge proof protocol based on the discrete logarithm hypothesis. Its proof logic is encoded as a circuit, with the actual available balance of the supervising account and the amount threshold as the circuit input, and outputting a fixed-length proof string and corresponding public verification parameters. The zero-knowledge proof generation module attaches a unique identifier to the asset transaction to be confirmed when generating the proof, so that each non-interactive zero-knowledge scope proof is only valid for a single fund verification.

[0024] In this embodiment, the trusted execution environment provides hardware-level isolation capabilities, ensuring that even if other parts of the banking system are attacked, the proof generation logic and the private input data will not be tampered with or stolen. Encoding the proof logic into arithmetic circuits is the standard paradigm for performing complex zero-knowledge proofs, ensuring equivalent computational verification of the constraint that "the actual available balance is greater than or equal to the amount threshold".

[0025] Furthermore, this approach offers extremely strong forward and backward security: on the one hand, by binding a unique transaction identifier, it prevents the proof of funds for one transaction from being maliciously replayed in another transaction; on the other hand, the fixed-length output proof string and public verification parameters ensure that the computational overhead of on-chain verification remains constant, regardless of the balance value or circuit size, greatly reducing the gas consumption of on-chain contracts. Gas is the computational resource fee charged by the network when executing a transaction or calling a smart contract.

[0026] As a specific implementation method, the generation process of non-interactive zero-knowledge scope proofs satisfies the following mathematical relationship: Let the system common verification parameter be... Private input includes the actual available balance of the escrow account. and amount threshold Constructing arithmetic circuits Make If and only if Non-interactive zero-knowledge scope proof Generated by the proof generation algorithm: And there are corresponding public verification parameters. Make any holder The verification method can be used for Correctness verification is performed. This trusted execution environment can be built using hardware security technologies such as Intel SGX or AMD SEV, and the circuitry can be completed within the enclave. The mapping and proof algorithm operations allow external systems to obtain only the final proof string. Unreachable , The original value; in, A non-interactive zero-knowledge scope proof object output by the proof generation algorithm, which is a fixed-length cryptographic evidence string used to prove to the verifier that the balance satisfies the condition; This is a non-interactive zero-knowledge proof generation algorithm that performs circuit calculations and generates proofs based on the selected zero-knowledge proof protocol (such as a scheme based on the discrete logarithm hypothesis). These are common verification parameters for the system, generated and made public during the system initialization phase. They are a set of cryptographic parameters shared by the proof generation and verification processes. The actual available balance of the escrow account is entered privately and its value is not disclosed to the public. The preset amount threshold serves as the minimum required funds for the transaction and is publicly known. For arithmetic circuits, "" was encoded "This comparison relationship is the constraint system of zero-knowledge proof."

[0027] In one embodiment, after obtaining a non-interactive zero-knowledge range proof, each oracle node in the oracle network first executes zero-knowledge proof verification logic using public verification parameters shared with the zero-knowledge proof generation module to confirm that the non-interactive zero-knowledge range proof is valid for the amount threshold and has not been tampered with. After successful verification, the node uses a message body containing the hash value of the non-interactive zero-knowledge range proof, the unique identifier of the asset transaction to be confirmed, the current trusted timestamp, and the node identifier as the signature object, and generates a partial signature share using its own threshold signature private key share. The generation of this partial signature share follows an aggregatable threshold signature mechanism, which allows a valid overall signature to be synthesized from multiple partial signature shares without exposing the complete private key of a single node.

[0028] In this embodiment, the local verification performed by each oracle node is the first line of defense against invalid proofs contaminating the on-chain environment. Nodes implicitly commit to the integrity of the proof by using its hash value, rather than the proof itself, directly as part of the signed message, while simultaneously controlling the length of the message to be signed. The introduction of trusted timestamps and node identifiers makes each partial signature share traceable and auditable, effectively preventing signature forgery and node identity impersonation.

[0029] Furthermore, this approach provides reliable security redundancy: even if a few nodes in the network fail or fail to submit signatures in time due to network failures, the entire system can still operate normally and make credible decisions as long as the preset threshold conditions are ultimately met.

[0030] As a specific implementation, the generation of this signature share follows the calculation process: Define the message. ,in For cryptographic hash functions (such as SHA-256). It serves as the unique identifier for transactions involving assets awaiting confirmation of ownership. As the current trusted timestamp, Let the node be the identifier; let the first node be the identifier. The share of threshold signature private keys held by each oracle node is The corresponding public key is This node calculates a portion of the signature share: Each node generates its own independently. The signature is then submitted to the aggregation verification smart contract. This threshold signature mechanism preferably adopts a BLS-based threshold scheme, which leverages its short signature and efficient aggregation characteristics to significantly reduce the computational overhead of on-chain data storage and verification.

[0031] In one embodiment, the aggregated verification smart contract deploys threshold signature aggregation logic and zero-knowledge proof verification logic. Upon receiving a portion of the signature data, the threshold signature aggregation logic verifies the validity of each portion, counting only those that pass verification into the aggregate count. When the number of valid signature portions reaches a preset threshold, it calculates a threshold aggregated signature using the aggregation algorithm corresponding to the threshold partial signature. This threshold aggregated signature is equivalent to signing with the complete threshold private key in one go. The zero-knowledge proof verification logic independently performs cryptographic verification on non-interactive zero-knowledge scope proofs, ensuring the authenticity of the statement that the actual available balance is not less than the amount threshold.

[0032] In this embodiment, the "verify first, then aggregate" step within the contract constitutes the core hub of on-chain decision-making. For each The validity check immediately eliminates invalid shares sent by malicious or faulty nodes, ensuring that all signatures participating in the aggregation come from oracle nodes that have honestly performed local verification. The aggregated threshold signature, in a cryptographic sense, is equivalent to the oracle network as a whole jointly endorsing the fact that "funds have been fully received." The independently executed zero-knowledge proof verification logic on-chain forms the final closed loop of the entire security model. It eliminates the need for the blockchain to trust any external conclusive information from the oracle network, instead directly verifying the underlying proof of funds mathematically. Furthermore, this approach delivers extreme trustlessness: even in extreme cases where nodes exceeding the threshold collude to forge the conclusion of "sufficient funds," the on-chain contract's zero-knowledge proof verification will inevitably fail without a valid zero-knowledge range proof generated by the bank's security domain, thus preventing malicious asset confirmation.

[0033] As a specific implementation, the verification of threshold aggregation signatures and non-interactive zero-knowledge range proofs satisfies the following mathematical relationship: Let the set of collected valid partial signature shares be... The threshold value is ,when At that time, the contract executes the aggregation operation: Simultaneously, the contract verifies non-interactive zero-knowledge scope proofs: It should equal 1. Only when the aggregate signature... Satisfying the public key The verification equation and Only then does the contract confirm the validity of the credible confirmation document regarding sufficient funds.

[0034] In one embodiment, after generating a threshold aggregate signature and completing the verification of a non-interactive zero-knowledge scope proof, the aggregate verification smart contract packages the threshold aggregate signature, the hash value of the non-interactive zero-knowledge scope proof, the verification timestamp, and the unique identifier of the asset transaction to be confirmed into an on-chain evidence record and writes it into the blockchain ledger. The on-chain evidence record serves as an immutable audit trail for subsequent regulatory review and dispute tracing. Any third party can independently verify the conclusion of sufficient funds through public verification parameters and on-chain records.

[0035] In this embodiment, the on-chain evidence record not only records the conclusion "passed," but also completely preserves all the cryptographic evidence leading to that conclusion, namely the hash values ​​of the threshold aggregate signature and zero-knowledge proof. This makes the audit fully reproducible. Any regulatory agency or interested third party can independently re-verify the fund verification conclusions in historical transactions without accessing the bank's internal systems and oracle network, relying solely on the publicly available verification parameters and the publicly available on-chain proof hash values. Furthermore, this approach can bring credible transparency across the system's lifecycle: even if some participating banks or oracle network nodes in the transaction leave the network in the future, the cryptographic evidence regarding the authenticity of the transaction funds will remain permanently stored on the blockchain and can be independently verified, greatly strengthening the system's historical credibility and dispute resolution capabilities.

[0036] In one embodiment, the asset transaction management smart contract further collaborates with the asset digitization module, the transaction matching module, and the ownership transfer module. Specifically, the asset digitization module generates standardized on-chain asset cards during the asset verification phase; the transaction matching module, based on asset limits, triggers a protocol transaction process for assets below the limit and a public auction process for assets exceeding the limit; and the ownership transfer module, upon receiving a credible confirmation of sufficient funds, automatically executes the on-chain transfer of asset ownership or management rights from the transferor to the transferee according to the pre-set ownership confirmation rules within the asset transaction management smart contract, and updates the ownership status field of the standardized on-chain asset cards.

[0037] In this embodiment, the asset transaction management smart contract constitutes an orchestrator driving the automation of the entire transaction lifecycle. By pre-setting transaction process rules corresponding to different asset limits within the contract, automatic routing of differentiated transaction methods is achieved. Taking the transaction of rural collective operating assets as an example, for assets with an appraised value lower than the prescribed limit, the transaction process can be automatically initiated, simplifying the transaction process; for assets exceeding the limit, the public bidding process is automatically triggered, ensuring the openness, fairness, and premium potential of the transaction. The ownership transfer module locks the final trigger for executing the confirmation of rights as a credible confirmation certificate of sufficient funds, ensuring the strict implementation of the core business rule of "money first, rights later." Furthermore, this approach can bring about an end-to-end automated transaction closed loop: from asset on-chaining and transaction matching to fund verification and ownership transfer, everything is driven by on-chain code of the smart contract, eliminating operational delays, errors, or moral hazards that may be caused by manual intervention, and significantly improving asset transfer efficiency.

[0038] In one embodiment, if the number of valid partial signatures collected does not meet the preset threshold condition at the end of the preset waiting period, the aggregated verification smart contract automatically determines that the fund verification has failed, generates a fund insufficiency event, and notifies the asset transaction management smart contract. The asset transaction management smart contract suspends the current asset transaction process based on the event and unlocks the locked state of the asset to be confirmed, allowing the asset to be confirmed to re-enter the tradable state.

[0039] In this embodiment, the timeout determination mechanism provides a crucial guarantee for the system's activity. In real-world network environments, unexpected situations may arise, such as widespread oracle node outages or regulatory bank system maintenance preventing the acquisition of proofs. If a contract waits indefinitely, the assets awaiting confirmation will be permanently locked. By pre-setting a waiting period and automatically triggering the timeout failure process, the deterministic termination of transactions is ensured. Furthermore, this approach enables the effective release of system resources: timely termination of failed transactions prevents assets from being locked in a lock-up pool, allowing the seller to quickly relist the asset in a new trading process, thus protecting the legitimate interests of market participants and ensuring continuous market liquidity.

[0040] In one embodiment, the decentralized oracle network is a permissioned oracle network. Nodes must undergo on-chain identity authentication and authorization to join. Each node establishes an independent encrypted channel with the security domain of the supervising bank. The authorized data interface adopts a two-way authentication mechanism to ensure the integrity and authenticity of non-interactive zero-knowledge proofs during transmission. Nodes synchronize the verification task status of the asset transactions to be confirmed through a peer-to-peer secure channel, and each independently completes the zero-knowledge proof verification logic and generates a portion of the signature share, without depending on each other.

[0041] In this embodiment, a permissioned network model is adopted instead of a permissionless model, which is a necessary requirement for the identity awareness and accountability of participants in consortium blockchain financial applications. Independent encrypted channels and two-way authentication (such as the mTLS protocol) build strong protection at the transport layer, eliminating the possibility of man-in-the-middle attacks stealing or tampering with proofs. The independent task processing architecture between nodes effectively prevents cascading failures caused by calculation errors in a single master node. Furthermore, this approach provides clear security responsibility boundaries: since each node has an authenticated on-chain identity, its signature behavior is non-repudiable. If a subsequent audit discovers that a node has malicious signatures or a long-term malfunction, it can be quickly detected, punished, or removed by the on-chain governance mechanism, maintaining the overall health of the oracle network.

[0042] In one embodiment, the zero-knowledge proof generation module is also used to automatically generate a new non-interactive zero-knowledge scope proof to reflect the current actual available balance status when the actual available balance of the regulated account changes and falls below the amount threshold, and invalidate the previously issued but unused non-interactive zero-knowledge scope proof according to a preset strategy; after obtaining the updated non-interactive zero-knowledge scope proof, the oracle network terminates the previously incomplete fund verification process to ensure the consistency between on-chain fund verification information and off-chain account status.

[0043] In this embodiment, the dynamic update mechanism reflects the real-time changes in account status in financial scenarios. For example, after the initial proof is generated but before on-chain verification is completed, a compliant outbound payment occurs in the regulated account, causing the balance to fall below the threshold. At this point, without proof updates, the old proof becomes an erroneous credential that was once sufficient but is now insufficient. By automatically generating proofs reflecting the new state and invalidating old proofs, the system proactively maintains the "freshness" of the proofs. Furthermore, this approach enables strong consistency between on-chain and off-chain states: the oracle network and on-chain contracts always make decisions based on proofs that reflect the latest true state of the bank account, effectively avoiding the risk of short-selling due to the use of expired proofs of funds—a security feature that traditional callback and polling mechanisms struggle to reliably achieve.

[0044] As a preferred implementation, the infrastructure for deploying all the aforementioned modules, namely the asset blockchain, is a permissioned consortium blockchain. Nodes in the regulatory bank's security domain, the decentralized oracle network, and asset transaction participants all join as permissioned nodes in the consortium blockchain. Aggregate verification smart contracts and asset transaction management smart contracts are deployed in chaincode form on each ledger node of the consortium blockchain, with a consensus mechanism ensuring the consistency of contract execution results. This system is applied to rural collective property rights transfer and transaction scenarios, where the aforementioned assets include land management rights, forest rights, aquaculture rights, and collectively-owned operating assets. The consortium blockchain is implemented using blockchain platforms with permission management models, such as Fabric or FISCOBCOS. Its channel mechanism can isolate sensitive transaction data to specific groups of participants, meeting the regulatory requirements for controllable data visibility. A consensus mechanism (such as the Practical Byzantine Fault Tolerance (PBFT) algorithm) ensures that even with a certain proportion of malicious nodes, the entire network can still reach a consistent and final decision regarding the transaction order and contract execution results.

[0045] The following is an explanation of key terms that are not commonly used in this field and appear in this invention: Zero-knowledge range proof: A cryptographic protocol that allows a prover to demonstrate to a verifier that a secret value falls within a certain public range (e.g., an account balance greater than a certain threshold) without revealing any information about the secret value itself. In this invention, it specifically refers to a non-interactive proof that does not disclose the actual available balance of the monitored account, but only proves that it is not less than a preset threshold.

[0046] Threshold partial signature: The complete private key is cryptographically divided into multiple shares and distributed to multiple participants. No single party can generate a valid complete signature. Only after collecting a preset threshold number of partial signature shares can an aggregation algorithm synthesize an aggregate signature equivalent to the complete private key signature.

[0047] Oracle network: A decentralized service network that securely and reliably transmits external blockchain data (such as bank account fund status) to on-chain smart contracts. In this invention, the oracle network not only transmits data but also provides cryptographic endorsement for the authenticity of the data through local node verification and distributed signatures.

[0048] Aggregate verification smart contracts: Automated program code deployed on the blockchain, responsible for receiving and verifying partial signature shares submitted by oracle nodes, performing signature aggregation operations, and conducting independent on-chain cryptographic verification of the zero-knowledge proof itself.

[0049] Trusted Execution Environment (TEE): A secure region within the main processor where code and data running are protected at the hardware level for confidentiality and integrity, and can withstand operating system-level attacks. In this invention, it specifically refers to a hardware-isolated environment within the security domain of a supervising bank used to generate zero-knowledge scope proofs.

[0050] On-chain standardized asset cards: These are digitally modeled, representing the rights attributes of real-world assets (such as land management rights and forest rights). They are generated on the blockchain as tamper-proof, unified data objects containing key fields such as asset number, owner, and confirmation status.

[0051] Example 2, to more intuitively demonstrate the complete operational logic of the present invention, describes in detail the entire verification process from fund receipt to asset confirmation using a set of simulated experimental data. This example uses a rural collective operating asset transaction as a case study, involving the transfer of the operating rights of a warehousing facility with an appraised value of RMB 500,000. The transferee must remit the full transaction price to a designated account at a supervising bank, and the system will then initiate the fund verification and confirmation process. The key parameter configurations involved in this example are shown in the table below: Table 1: Key Parameter Configuration Table for Verification Process Preset amount threshold 500,000 Minimum funds required for the transaction (unit: yuan) Transferee's remittance amount 500,000 The amount actually transferred by the transferee to the escrow account (unit: yuan) Pre-remittance balance in regulated account 120,000 Existing balance in the escrow account before remittance (unit: yuan) Actual available balance after remittance in the regulated account 620,000 Actual available balance in the account after remittance (unit: yuan) Total number of oracle network nodes 5 Number of authorized independent nodes in a decentralized oracle network Threshold 3 The minimum number of partial signature shares required to generate a valid threshold aggregate signature Preset waiting period 300 Maximum wait time for contract signature collection (in seconds) Unique Transaction Identifier TX-20260717-0001 The system assigns a unique identifier to this asset transaction.

[0052] The specific steps of the verification process are as follows: The first step is to receive funds and generate a zero-knowledge scope proof.

[0053] The transferee transferred RMB 500,000 to a dedicated escrow account opened by the supervising bank through a bank counter. The supervising bank's core banking system captured this inflow, identified the amount, and associated it with the unique transaction identifier TX-20260717-0001. At this time, the pre-transfer balance of the escrow account was RMB 120,000, and the actual available balance after the transfer changed to RMB 620,000.

[0054] The bank system pushes a notification of the deposit event to the zero-knowledge proof generation module deployed within the trusted execution environment of the supervising bank's security domain. This module receives confidential input: the actual available balance of 620,000 yuan and the minimum deposit threshold of 500,000 yuan. The system then invokes a pre-defined arithmetic circuit. The circuit encodes the comparison relation "620,000 is not less than 500,000", and the circuit outputs true. Prove the generation algorithm. Taking common verification parameters, balance, threshold, and circuit as input, perform cryptographic operations based on the discrete logarithm hypothesis and output a non-interactive zero-knowledge range proof. This certificate includes a unique transaction identifier TX-20260717-0001 and is valid only for this fund verification.

[0055] The second step involves distributed verification and partial signature generation via an oracle network.

[0056] Five independent nodes in the decentralized oracle network establish bidirectional encrypted channels with the regulatory bank's security domain through authorized data interfaces, and each obtains a non-interactive zero-knowledge scope proof. Each node uses the shared verification parameters with the proof generation module to execute zero-knowledge proof verification logic locally. The verification result confirms that the "actual available balance is not less than the amount threshold" declared in the proof is true and that the proof has not been tampered with.

[0057] Each node then constructs the message body to be signed. Taking node 1 as an example, it performs a non-interactive zero-knowledge scope proof. The message digest is obtained by concatenating the hash value, the unique transaction identifier TX-20260717-0001, the trusted timestamp, and the node's own identifier, and then calculating the message digest using a cryptographic hash function. Node 1 uses its own share of the threshold signature private key. , call The algorithm generates partial signature shares. The remaining four nodes perform the same operation in parallel, generating... , , , The partial signature share data generated by each node is shown in the table below: Table 2: Oracle Node Partial Signature Generation Data Table Node 1 ON-001 a3f7c9e1b5d2084f 7b2e5a1c8f0346d9 09:30:12 Node 2 ON-002 a3f7c9e1b5d2084f e4c8d7a2b1095f3e 09:30:14 Node 3 ON-003 a3f7c9e1b5d2084f 2f6a8d3c7e01b945 09:30:13 Node 4 ON-004 a3f7c9e1b5d2084f 9b1c4e7d2a083f56 09:30:15 Node 5 ON-005 a3f7c9e1b5d2084f d5e8f2a6c3071b84 09:30:16

[0058] As shown in the table above, the message digests generated by the five nodes after verifying the same proof are identical, indicating that each node is verifying the same tamper-proof proof. The partial signature shares generated by each node are different, reflecting the independence of their respective private key shares.

[0059] The third step is to aggregate and verify the execution of smart contracts.

[0060] After generating partial signature shares, the five oracle nodes will respectively... to The signature is submitted to an aggregated verification smart contract deployed on the blockchain network. The contract first verifies the validity of each partial signature share. In this embodiment, all five signature shares pass the verification and are included in the valid set. ,at this time .

[0061] Once the number of valid signatures in the contract reaches a preset threshold of 3, an aggregation operation is executed. Aggregation Algorithm Take five valid partial signature shares as input and output a threshold aggregate signature. . Cryptographically equivalent to using the full threshold private key to the message body A one-time signature, whose length is fixed and independent of the number of signature shares participating in the aggregation.

[0062] Meanwhile, the contract independently executes the zero-knowledge proof verification logic. Contract call. Algorithm, with common verification parameters and zero-knowledge scope proof The input is 1, which is then cryptographically computed and outputs 1, indicating that... The proven statement that "the actual available balance is not less than the amount threshold" is mathematically true and valid. Key results of the aggregate signature and proof verification are shown in the table below: Table 3: Execution Results of Aggregated Verification Smart Contract Number of valid partial signatures 5 All five node signatures are valid Threshold condition determination Satisfies (5≥3) Reaching threshold 3 Aggregated signature generation success Five shares are aggregated into a single signature σ Zero-knowledge proof verification Passed (Verify=1) Balance ≥ threshold declaration is valid Sufficient and reliable confirmation of funds Generated Irrevocable

[0063] The fourth step is to generate and store on-chain a credible confirmation certificate for sufficient funds.

[0064] Once the threshold aggregate signature is verified and the zero-knowledge scope proof is confirmed to be valid, the aggregate verification smart contract generates an irrevocable and reliable confirmation of sufficient funds. The contract then packages the threshold aggregate signature, the hash value of the zero-knowledge scope proof, the verification timestamp, and the unique transaction identifier into an on-chain notarized record and writes it to the blockchain ledger. This notarized record constitutes an immutable audit trail, which can be independently verified by any regulatory agency or third party using publicly available verification parameters.

[0065] The fifth step is to confirm and transfer the ownership of the assets.

[0066] After receiving a credible confirmation of sufficient funds, the asset transaction management smart contract initiates the rights confirmation process according to pre-defined rights confirmation rules. The contract calls the asset registration module to update the rights confirmation status field of the standardized on-chain asset card corresponding to the warehousing facility operating rights from "pending confirmation" to "confirmed." The contract further calls the ownership transfer module to automatically execute the on-chain transfer of operating rights from the transferor to the transferee. The system synchronizes the transfer completion event and the updated asset card status to all consortium blockchain ledger nodes, and the consensus mechanism ensures consistency across all nodes.

[0067] At this point, the transaction of rural collective operating assets has completed a full closed loop in three aspects: privacy protection for fund verification, decentralized verification, and on-chain trusted confirmation of rights, and the entire process verification has been completed.

[0068] The embodiments disclosed in this invention are preferred embodiments, but are not limited thereto. Those skilled in the art can easily understand the spirit of this invention based on the above embodiments and make different extensions and variations, but as long as they do not depart from the spirit of this invention, they are all within the protection scope of this invention.

Claims

1. A method for managing trusted asset blockchain transactions, characterized in that, include: Obtain a non-interactive zero-knowledge scope proof for the corresponding asset transaction to be confirmed. The non-interactive zero-knowledge scope proof is generated by the security domain of the supervising bank and is used to prove that the actual available balance of the supervising account is not less than the amount threshold of the corresponding transaction and does not disclose the value of the actual available balance. Receive partial signature shares generated by each node in the decentralized oracle network for the non-interactive zero-knowledge range proof, wherein the partial signature shares are generated by each node using its own threshold signature private key share after verifying the non-interactive zero-knowledge range proof. When the number of valid partial signature shares reaches a preset threshold, a threshold aggregate signature is generated and the validity of the non-interactive zero-knowledge scope proof is independently verified. If the verification is successful, a credible confirmation certificate of sufficient funds is generated, triggering the asset transaction management smart contract to execute the confirmation of ownership of the asset to be confirmed.

2. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, The non-interactive zero-knowledge scope proof is generated by a trusted execution environment within the security domain of the supervising bank. When generated, it is bound to a unique identifier of the asset transaction to be confirmed. Each non-interactive zero-knowledge scope proof is only valid for the corresponding transaction.

3. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, The partial signature share is generated by each oracle node in the following manner: After each node locally verifies the non-interactive zero-knowledge range proof using the public verification parameters shared with the proof generator, it generates a partial signature share for the message body containing the hash value of the non-interactive zero-knowledge range proof, the unique identifier of the asset transaction to be confirmed, the current trusted timestamp, and the node identifier, using its own threshold signature private key share.

4. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, The steps for independently verifying the validity of the non-interactive zero-knowledge scope proof specifically involve: using public verification parameters shared with the proof generator to perform cryptographic verification on the non-interactive zero-knowledge scope proof, confirming that the statement that the actual available balance of the regulatory account is not less than the amount threshold of the corresponding transaction is valid.

5. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, Also includes: If the number of valid signatures collected within the preset waiting period does not reach the preset threshold, the fund verification is deemed to have failed, an insufficient fund event notification is generated in the asset transaction management smart contract, and the locked status of the asset to be confirmed is released.

6. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, After generating a credible confirmation certificate of sufficient funds, the process also includes: packaging the threshold aggregate signature, the hash value of the non-interactive zero-knowledge scope proof, the verification timestamp, and the unique identifier of the asset transaction to be confirmed into an on-chain evidence record and writing it into the blockchain ledger for independent verification by a third party of the conclusion of sufficient funds.

7. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, Before the smart contract for triggering asset transaction management executes the confirmation of ownership of the assets to be confirmed, the process also includes: classifying the assets to be confirmed according to their appraised value, executing a negotiated transaction process for assets below a preset limit, and executing a public auction process for assets exceeding a preset limit.

8. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, The decentralized oracle network is a permissioned oracle network. Each node must undergo on-chain identity authentication and authorization to join. Each node and the security domain of the supervising bank transmit non-interactive zero-knowledge scope proofs through a two-way encrypted channel.

9. The asset blockchain trusted ownership confirmation transaction management method according to claim 1, characterized in that, Also includes: Receive the updated non-interactive zero-knowledge scope proof generated by the supervisory bank's security domain when the actual available balance of the supervisory account is lower than the amount threshold, terminate the currently incomplete fund verification process, and restart the verification based on the updated non-interactive zero-knowledge scope proof.

10. An asset blockchain trusted ownership confirmation and transaction management system, characterized in that, This includes zero-knowledge proof generation modules deployed in the security domain of regulated banks, decentralized oracle networks, aggregated verification smart contracts deployed on blockchain networks, and asset transaction management smart contracts.

Images