Intelligent contract-based trade data credible transaction and management platform

Abstract

The application discloses a trade data credible transaction and management platform based on a smart contract, and relates to the technical field of blockchains and smart contracts, comprising a double-layer contract agent module, a zero-knowledge proof selective disclosure module and a jurisdiction compliance adapter module.The double-layer contract agent module strictly separates an unalterable audit account contract from a controllable and revisable diamond agent routing contract and a business function contract, drives contract controlled revision by an aggregated threshold signature generated by multi-party secure calculation, eliminates single-point centralization risks, places proof generation in an off-chain trusted execution environment by the zero-knowledge proof selective disclosure module, and never uploads original commercial data to a chain, realizes supervision verifiable and competitor invisible data right protection, and the jurisdiction compliance adapter module identifies a jurisdiction area through digital identity analysis, dynamically loads authoritative legal rule parameters through a decentralized oracle network and locks legal effective declaration on a chain.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and smart contract technology, specifically a trusted trading and management platform for trade data based on smart contracts. Background Technology

[0002] Blockchain is a distributed ledger technology that is jointly maintained by multiple nodes and uses cryptographic methods to ensure the immutability of data. Smart contracts are program code units deployed on the blockchain network that can automatically execute preset business logic. Once deployed, their bytecode is immutable and has the characteristics of decentralization, transparency and censorship resistance.

[0003] The proxy contract pattern is a mainstream engineering solution to address the immutability limitations of smart contracts. Its core idea is to separate contract logic from data storage. Users only interact with the proxy contract. The proxy contract forwards calls to the logic contract for execution through delegation instructions. Upgrades are achieved by changing the address pointer of the logic contract in the proxy contract. Common patterns include transparent proxy, UUPS proxy, and diamond proxy based on EIP-2535.

[0004] Zero-knowledge proof technology is an important branch of modern cryptography. Concise, non-interactive zero-knowledge proof systems, represented by zk-SNARKs, allow the prover to generate a concise cryptographic proof. The verifier can verify the statement as true with very low computational overhead using only the proof and public input, and cannot obtain any information about the secret input from it. Decentralized oracle networks aggregate reports from multiple independent data nodes and use consensus mechanisms to filter malicious data, providing highly reliable external data feeds to on-chain contracts. Secure multi-party computation is a set of cryptographic protocols that allow multiple participants holding private data to collaboratively compute the result of a public function without revealing their private inputs to any other party.

[0005] Existing blockchain-based trading platforms face three major technological shortcomings:

[0006] Defect 1: Centralized upgrade permissions cause serious trust crises and security risks. In the UUPS proxy model, the authority to call the contract upgrade function is controlled by the platform administrator's single private key or multi-signature wallet. In scenarios involving multiple trade participants (buyers, sellers, banks, freight forwarders) who do not trust each other, no party is willing to relinquish the final decision-making power for contract upgrades to an address controlled by another party. Once the administrator's private key is stolen or the administrator has a conflict of interest, the contract can be maliciously upgraded unilaterally, resulting in asset losses. Furthermore, the integrity and traceability of historical data cannot be effectively guaranteed. In addition, this model binds all business logic to a single logic contract, which cannot support fine-grained independent upgrades of single business links. Each upgrade requires redeployment of all logic, resulting in extremely high operational risks.

[0007] Defect 2: Regulatory interoperability and commercial privacy are mutually exclusive. Existing privacy solutions, such as the Hyperledger Fabric private channel mechanism, base data privacy on access control isolation rather than cryptographic guarantees. When regulatory agencies need to participate in audits, they must join as channel members, at the cost of gaining full access to all historical transaction data within the channel. This makes it impossible to achieve fine-grained supervision that only verifies whether specific compliance conditions are met. This solution cannot provide any cryptographic guarantee of data authenticity to untrusted external regulatory agencies and can only rely on manual verification. It cannot simultaneously meet the dual requirements of regulatory verifiability and invisibility by competitors.

[0008] Deficiency 3: Complete lack of cross-jurisdictional legal adaptability. Existing trade smart contracts hardcode applicable legal rules into the contract logic during deployment, and cannot dynamically perceive the jurisdiction of the trading parties and switch the corresponding legal rule parameters at runtime. International trade involves different legal systems in multiple countries and regions, and there are substantial differences in the provisions of core clauses such as the upper limit of liquidated damages, exemption clauses, and the point of transfer of risk of goods. This leads to the on-chain contract execution results contradicting offline legal judgments, which seriously weakens the legal effect and commercial value of smart contracts in cross-border trade. To address this, we propose a trusted trading and management platform for trade data based on smart contracts. Summary of the Invention

[0009] The purpose of this invention is to provide a trusted trading and management platform for trade data based on smart contracts.

[0010] To achieve the above objectives, the present invention provides the following technical solution: a smart contract-based trusted trading and management platform for trade data, comprising a two-layer contract proxy module deployed on a blockchain network, a zero-knowledge proof selective disclosure module, and a jurisdictional compliance adapter module. The three modules provide services to the outside world through a unified platform access layer.

[0011] The two-layer contract proxy module adopts a state-transition separation protocol, dividing the contract system into two layers: an immutable lower layer and a controllable and revisable upper layer. The immutable lower layer is an audit ledger contract that permanently records the hash digest, timestamp, participant signatures, and complete change records of each compliant revision operation for every trade event in an append-only manner, without carrying any business logic. The controllable and revisable upper layer is a diamond proxy routing contract implemented based on the EIP-2535 diamond proxy standard. It internally maintains a mapping table from function selectors to the addresses of various business function contracts. Through delegated call instructions, it forwards user calls to the corresponding business function contracts for execution. The state change of the execution result is written to the storage space of the diamond proxy routing contract, and the event hash is submitted to the audit ledger contract for permanent archiving. Contract revisions must use a BLS aggregated threshold signature generated by multi-party secure computation instead of a single administrator authorization as the trigger condition, realizing decentralized and controlled business rule updates.

[0012] The zero-knowledge proof selective disclosure module adopts an architecture paradigm of off-chain proof generation and on-chain lightweight verification. It places the computationally intensive zero-knowledge proof generation process in an off-chain trusted execution environment, submitting only concise proof results and public inputs to the on-chain validator contract. Lightweight verification is completed through elliptic curve pairing operations, and the verification results are written to the on-chain zero-knowledge proof registry for regulatory agencies to query. This module designs three types of core verification circuits for multimodal trade documents: transaction amount compliance verification circuit, goods origin compliance verification circuit, and document integrity and authenticity verification circuit. The original business data is never uploaded to the blockchain.

[0013] The jurisdiction compliance adapter module extracts the jurisdiction identifier from the digital identity certificate of the transaction entity through the digital identity resolver, and broadcasts the jurisdiction rule query request to the decentralized oracle node network via the oracle adapter contract. Each authoritative data source node independently queries the authoritative legal database and generates a BLS signature share. After determining the final rule parameters through threshold signature aggregation and median value strategy, the rule parameters are stored in the jurisdiction rule storage contract. The compliance function contract attaches the rule parameters to perform compliance verification and permanently locks the legally effective declaration record in the audit ledger contract.

[0014] Compared with the prior art, the beneficial effects of the present invention by adopting the above technical solution are as follows:

[0015] 1. This invention strictly separates the immutable audit ledger contract from the controllable and revisable diamond proxy routing contract and business function contract system, replaces the single administrator authority with multi-party secure computation consensus signature, completely eliminates the risk of single-point centralization, refines the granularity of changes to the level of a single business function contract, and permanently locks the historical transaction hash in the underlying audit ledger, so that the audit traceability is not affected by the iteration of business rules.

[0016] 2. In this invention, regulatory agencies do not need to access any original business data. They can cryptographically confirm that trade data meets compliance requirements simply by executing a lightweight on-chain validator contract. Core business secrets such as the company's purchase price and supplier identity are always kept in a trusted off-chain execution environment and are never uploaded to the chain. This realizes a new paradigm of data ownership that is verifiable by regulators and invisible to competitors.

[0017] 3. This invention can automatically pull and load legal rule parameters of the corresponding jurisdiction from the decentralized oracle network based on the digital identity and geographical identifier of the transaction subject through the contract, and lock the legal validity declaration on the chain, which significantly improves the success rate of the legal validity recognition of cross-border trade smart contracts in courts of various jurisdictions and reduces the compliance costs of enterprises.

[0018] 4. The three modules of this invention work together to simultaneously realize three core capabilities on a single blockchain platform: contract upgradeability, trade data privacy protection, and cross-jurisdictional legal compliance. These three capabilities are interdependent and indispensable, and together they solve the fundamental contradiction that existing blockchain-based trade platforms cannot simultaneously meet the above three requirements. This overall technical effect cannot be achieved independently by any single technical module. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall layered architecture in an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the internal structure of the two-layer contract proxy module in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the zero-knowledge proof and jurisdictional compliance adapter process in an embodiment of the present invention. Detailed Implementation

[0022] The following is in conjunction with the appendix Figure 1-3 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0023] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0024] I. System Overall Architecture:

[0025] The trade data trusted transaction and management platform proposed in this invention consists of three core modules: a two-layer contract proxy module, a zero-knowledge proof selective disclosure module, and a jurisdictional compliance adapter module. These three modules are deployed together on a blockchain network (supporting Ethereum-compatible chains). Through a unified platform access layer, it provides services to client nodes of trade participants such as buyers, sellers, banks, freight forwarders, and customs. The platform service layer includes three sub-modules: identity authentication service, document management service, and event monitoring service. The off-chain infrastructure layer includes a trusted execution environment cluster, zero-knowledge proof circuit computing nodes, and a decentralized oracle network.

[0026] The layers interact through a unified interface protocol: the user access layer communicates with the platform service layer through the API gateway; the platform service layer interacts with the core smart contract layer through the standard blockchain transaction interface; the compliance function contracts in the on-chain smart contract layer trigger data queries from off-chain oracle nodes through the oracle interface; and the zero-knowledge proof computing nodes in the off-chain trusted execution environment export the proof results and submit them to the on-chain validator contract through a secure channel. The three modules work together through an event-driven mechanism, with the audit ledger contract serving as the globally unique and tamper-proof event storage center, permeating all business processes.

[0027] II. Two-tier contract agency module:

[0028] (I) Architectural Principles:

[0029] The core design principle of the two-layer contract proxy module is the strict separation of contract data state and business rule transformation logic, namely the State-Transition Separation Protocol (STSP). The contract system is divided into two layers: an immutable bottom layer and a controllable and revisable upper layer. This fundamentally solves the problems in the traditional proxy model, such as the possibility of upgrading logic contracts disrupting the storage layout, the untraceability of historical data, and the risk of centralized power.

[0030] The immutable underlying layer is the audit ledger contract, which is never upgraded once deployed. Its sole responsibility is to record the hash digest, timestamp, participant signatures, and complete change record of each compliant revision operation in an append-only manner for every trade event. Each change record includes a globally unique identifier for the revision proposal, the business function contract address before the change, the business function contract address after the change, the aggregated signature value of the multi-party secure computation consensus, and the addressing hash of the reason for the change. The audit ledger contract does not carry any business logic, and its stored data constitutes an undeniable on-chain evidence basis. Any subsequent iteration of business rules will not affect the traceability of historical transactions.

[0031] The controllable and revisable upper layer is the Diamond Proxy Routing Contract, implemented based on the EIP-2535 Diamond Proxy standard. The Diamond Proxy Routing Contract maintains a mapping table from function selectors to business function contract addresses. When a user calls a certain trading function, the Diamond Proxy Routing Contract queries the mapping table and forwards the call to the corresponding business function contract for execution via a delegated call instruction. The status change of the execution result is written to the storage space of the Diamond Proxy Routing Contract. After the delegated call is completed, the corresponding event hash is synchronously submitted to the audit ledger contract and permanently archived in an append-only manner. This architecture ensures that business functions can be replaced independently with fine granularity, and the replacement operation itself is also fully recorded.

[0032] (II) Business Function Contract System:

[0033] This invention designs the following set of standard business function contracts: the payment function contract implements the logic of automatic transfer of letters of credit, escrow of funds and release of payments, and automatically triggers fund transfer when the buyer and seller meet the preset delivery conditions; the logistics function contract receives logistics milestone events uploaded by freight forwarders, drives the contract trade state machine according to the event content, and triggers subsequent payment and acceptance processes; the quality inspection function contract processes quality inspection reports uploaded by quality inspection agencies, and triggers dispute arbitration process when the inspection results are abnormal; the compliance function contract serves as the on-chain entry point of the jurisdictional compliance adapter module, and is responsible for calling the digital identity resolver, attaching jurisdictional legal rules parameters and performing compliance verification; and the dispute resolution function contract realizes the submission of multi-party arbitration proposals, on-chain voting, and automatic execution of the arbitration results.

[0034] (III) Controlled and Revisable Mechanism – Compliance Revision Breakpoint Triggering Process:

[0035] When circumstances arise in trade that require changes to contract terms (such as an extension of payment terms due to force majeure), the system triggers controlled compliance revisions through the following complete process:

[0036] During the revision proposal submission phase: Participants who discover trade anomalies construct revision proposal objects through the platform interface. The data structure of the revision proposal includes a globally unique identifier, a revision type enumeration value (such as changes in payment terms, extensions in delivery dates, etc.), the on-chain address of the old business function contract to be replaced, the on-chain address of the new business function contract that has passed third-party security audits, the original IPFS content addressing hash for revision (storing complete text descriptions and supporting documents), and the timestamp of the proposal submission. The proposal initiator uses its private key to sign the proposal hash, generates a personal signature share, and broadcasts the proposal and signature to the platform to notify other participants.

[0037] Independent review and signing phase by participating parties: Each participating party independently downloads and reviews the complete content of the revision proposal, specifically including: verifying whether the source code of the new business function contract has been endorsed by a third-party security audit report, verifying the consistency between the IPFS file to which the reason for the revision points and the actual business background, confirming that the expected behavior of the new business function contract in the local test network is consistent with the revision intent, and if the review is passed, the participating party uses its private key to generate a signature share and submits it to the platform's multi-party secure computation coordination node;

[0038] Threshold signature aggregation phase: The multi-party secure computation coordination node adopts a threshold signature scheme based on Shamir secret sharing to collect the signature shares of each participant. Let the total number of participants be... The minimum number of signers required for the revision to pass is [threshold value]. ,Require When the number of submitted signatures is not less than When this occurs, signature aggregation calculation based on the BLS (Boneh-Lynn-Shacham) signature scheme is triggered. Let the subset of signature shares selected for aggregation be... ,satisfy Aggregated signature The calculation is defined as follows:

[0039] ;

[0040] in, The aggregated signature result can be verified by an on-chain contract using a single cryptographic operation. Legal authorization from an independent signatory. This is a signature aggregation function based on the BLS signature scheme. For the first Each participant generates a personal signature share. The subset of signature shares selected for aggregation;

[0041] On-chain compliance revision breakpoint triggering phase: The multi-party secure computation coordination node packages the aggregate signature, revision proposal, and new business function contract address, and calls the revision function in the diamond proxy routing contract. The diamond proxy routing contract executes the following on-chain verification logic: First, it calls the BLS signature verification pre-compiled contract to verify the aggregate signature. In relation to the validity of the proposal hash and the public key sets of the participants, the verification equation must hold:

[0042] ;

[0043] in, For the first The BLS public key of each participating party, To revise the hash value of the proposal object, For the BLS signature batch verification function, after successful verification, the Diamond Proxy Routing Contract updates the address pointer corresponding to the old business function contract in the function selector mapping table to the address of the new business function contract. Then, it initiates a call to the audit ledger contract, permanently writing the complete change record, including the unique identifier of the revision proposal, the addresses of the old and new business function contracts, the proposal hash, the aggregate signature, and the change block timestamp, into the underlying audit ledger. After the revision is completed, the Diamond Proxy Routing Contract issues an event notification. Thereafter, all calls to this function will be automatically routed to the new business function contract for execution, and historical transaction records can be fully traced through the audit ledger contract.

[0044] III. Selective Disclosure Module for Zero-Knowledge Proofs:

[0045] (I) General Principles:

[0046] This module adopts an architecture paradigm of off-chain proof generation and on-chain lightweight verification. Trade participants hold the original document data in a local trusted execution environment. Within the trusted execution environment, zero-knowledge proof circuit computing nodes run to solve the circuit constraints on the original data, generating zero-knowledge proofs. The zero-knowledge proofs and public inputs (containing only Boolean statements on whether compliance conditions are met and commitment values ​​for anti-replay) are submitted to the on-chain validator contract. The validator contract performs lightweight elliptic curve pairing operations and outputs the verification results. The verification results are written to the on-chain zero-knowledge proof registry for query by regulatory agencies such as customs and banks. The original business data is never recorded on the chain, fundamentally achieving the coexistence of regulatory verifiability and invisibility by competitors.

[0047] During system deployment, the platform performs a one-time trusted initialization ceremony to generate a set of public reference strings for each type of verification circuit, containing a proof key and a verification key. The verification key is permanently written into the on-chain validator contract, while the proof key is held by each trading participant in their local trusted execution environment.

[0048] (II) Three types of core verification circuits:

[0049] For multimodal trade documents (customs declaration, bill of lading, quality inspection report, letter of credit, etc.), this invention designs three types of core verification circuits;

[0050] Circuit 1: Transaction Amount Compliance Verification Circuit

[0051] This circuit is used to prove to banks or regulatory agencies that the declared amount of a trade is within the compliant range and consistent with the underlying contract, without disclosing the specific amount;

[0052] Set the private input to the actual transaction amount. (Unit: US cents), the public parameter is the lower bound of the compliance amount set by the regulatory authority. and the upper realm and the committed value of the transaction amount The circuit constraints are defined as follows:

[0053] ;

[0054] ;

[0055] in, This is the actual transaction amount (entered privately, not recorded on the blockchain). Use random salt values ​​to prevent misrepresentation of the committed value. To launch a brute-force attack (private input). The Poseidon hash function reduces the number of constraints in a circuit by approximately 8 times compared to SHA-256, making it suitable for zero-knowledge proof circuit scenarios. This is a byte string concatenation operation. The Pedersen commitment for the transaction amount is stored on-chain as a public input. and The lower and upper bounds of the compliance amount are set by the regulatory authorities, and are both public parameters. The circuit prover provides proof that the above constraints are met, and the verifier performs the following relationship to verify and confirm compliance:

[0056] ;

[0057] in, Zero-knowledge proof tuples generated for the transaction amount compliance verification circuit.

[0058] Circuit 2: Goods Origin Compliance Verification Circuit

[0059] This circuit is used to prove to customs that the origin of goods meets the access conditions of free trade agreements without disclosing the specific supplier's identity and supply chain structure.

[0060] Let the private input be the set of supplier identities at each level of the supply chain and their corresponding country codes, and the total number of levels in the supply chain be... The public parameter is the Merkle root hash of the customs-preset compliant country of origin whitelist. The circuit constraints are defined as follows:

[0061] ;

[0062] ;

[0063] in, For the first The ISO3166-1 code of the country or region where the layer supplier is located (enter privately, not on the chain). for Path to proof of membership in the Merkle tree of the compliant country of origin whitelist (private input). Merkle root hash for compliance with origin whitelist (public parameter, publicly released by regulatory agencies and registered on-chain). The Merkle membership verification function, expanded internally within the circuit, is as follows: There are hash constraints, where This represents the total number of countries on the whitelist. Binding commitments for supply chain origin combinations (public input, stored on-chain). The system uses a random salt value (private input) and completes origin compliance verification across the entire supply chain within the circuit using Merkle membership credentials. Supplier identities and supply chain hierarchical structures are kept completely confidential from all external parties.

[0064] Circuit 3: Document Completeness and Authenticity Verification Circuit

[0065] This circuit is used to prove to any verifier that the content of a trade document (such as a bill of lading) is consistent with the original hash registered on the chain and has not been tampered with, without having to upload the original document.

[0066] Assume the private input is the original text of the document. The public parameter is the original hash of the document already registered on the chain. The circuit constraints are defined as follows:

[0067] ;

[0068] ;

[0069] in, This is the original content of the document (private input, containing trade secret fields, not uploaded to the blockchain). For the internal circuit The calculated hash value, The original hash (public parameter) of the document already registered on the chain. The Poseidon hash function is used internally within the circuit.

[0070] (III) Zero-knowledge proof generation and on-chain verification process:

[0071] Private Witness Calculation Phase: Within the isolated area of ​​the Trusted Execution Environment, trade participants load the original document data and select the corresponding circuit (Circuit 1, Circuit 2, or Circuit 3) based on the compliance scenario to be proven. They then substitute the private inputs and public parameters into the circuit, and the constraint solver calculates the complete satisfaction assignment, i.e., the witness vector. ,in Includes all private input. Includes all public inputs and outputs;

[0072] Zero-knowledge proof generation phase: The Groth16 proof algorithm is invoked within the trusted execution environment to prove the key. and witness vector For input, generate a concise proof tuple:

[0073] ;

[0074] in, Elliptic curve Let point A on the curve BN254 be a group element. Elliptic curve The proof point B on the curve BN254 is... Group elements on, Elliptic curve The proof point C on the above is used for pairwise verification. The proof generating function for the Groth16 protocol has a computational complexity of O(n log n). ,in The number of circuit constraints is limited and execution is only performed within an off-chain trusted execution environment.

[0075] On-chain elliptic curve pairing verification phase: The validator contract first verifies the format and value range of each field in the public input vector (e.g., the committed value is a valid elliptic curve point, and the country code is a valid ISO encoding). Then, it calls the EVM pre-compiled contract to execute the BN254 elliptic curve pairing verification. The core pairing equation is as follows:

[0076] ;

[0077] in, It is a bilinear pairing function on the BN254 curve. The public reference string parameters generated for the Groth16 protocol trusted initialization ceremony are pre-stored in the validator contract. For the first A scalar value of public input, In order to be with the first Each public input corresponds to a common reference string base point. The total number of public inputs. If the matching equation is true, the verification passes; otherwise, the verification fails and the transaction is rolled back.

[0078] Verification result on-chain archiving stage: After successful verification, the verifier contract writes the verification record into the zero-knowledge proof registry. This record includes the unique identifier of the trade order, the type of circuit used in this verification, the hash digest of the proof tuple, the public input vector, the timestamp of the block where the verification is completed, and the valid status flag. Regulatory agencies (customs, banks) can obtain compliance confirmation with cryptographic endorsement by querying the verification record in the zero-knowledge proof registry without accessing any original business data.

[0079] IV. Jurisdiction Compliance Adapter Module:

[0080] (I) Module Architecture:

[0081] The jurisdiction compliance adapter module consists of a digital identity resolver, an oracle adapter contract, a jurisdiction rules storage contract, and a decentralized oracle node network. The digital identity resolver follows the W3CDID standard to parse digital identity certificates and is responsible for extracting structured jurisdiction information from the certificates. The oracle adapter contract serves as an interface adaptation layer between the on-chain contract layer and the off-chain oracle network. It is responsible for constructing query requests, verifying the returned results, and writing them into the jurisdiction rules storage contract. The jurisdiction rules storage contract maintains a cache of rule parameters indexed by the jurisdiction combination identifier and supports expiration management. The decentralized oracle node network consists of authoritative data source nodes such as authorized nodes of the International Chamber of Commerce and official nodes of customs in various countries. Each node independently queries authoritative legal databases and ensures data consistency through a threshold signature mechanism.

[0082] (II) Dynamic loading and binding process of jurisdiction rules:

[0083] Digital Identity and Jurisdiction Identification Phase: When a new trade order is created and submitted to the platform, the compliance function contract automatically invokes the digital identity resolver to extract the country code field from the buyer's digital identity certificate and the seller's digital identity certificate, respectively, to obtain the buyer's jurisdiction code. and seller's jurisdiction code Based on the jurisdiction pairs of the transaction entities, generate a jurisdiction combination identifier:

[0084] ;

[0085] in, The ISO 3166-1 Alpha-2 code for the buyer's country or region. The ISO 3166-1 Alpha-2 code for the seller's country or region. For enumerated values ​​of trade types (such as goods imports, service trade, etc.). A unique hash identifier for the jurisdiction combination, used as the key for rule queries;

[0086] Local rules cache check phase: Oracle adapter contract with To index and query the jurisdiction rule cache in the jurisdiction rule storage contract, if the cache exists and the timestamp of the rule data meets the validity period constraint (let's assume a rule cache validity period threshold),... The default is 86400 seconds, or 24 hours, for the current block timestamp. With cache update timestamp The difference satisfies If the condition is met, the rule parameters are loaded directly from the cache; otherwise, the off-chain oracle data retrieval process is triggered. This caching mechanism effectively reduces the frequency and cost of on-chain oracle calls.

[0087] Oracle query request broadcast phase: The oracle adapter contract broadcasts a jurisdiction rule query request to the decentralized oracle node network through the decentralized oracle interface. The request body includes the jurisdiction combination identifier and a list of required rule types, covering parameters such as the maximum penalty rate, force majeure clause code, and cargo risk transfer node parameters. The authoritative data source nodes in the decentralized oracle node network independently query their local authoritative legal databases and return the corresponding rule parameter reports.

[0088] Multi-source rule parameter consensus aggregation phase: Each oracle node uses its BLS private key to sign the report hash, generating a signature share. Let the oracle consensus threshold be... (By default, two-thirds of the total number of nodes, rounded up) When at least When a signature share is reached, BLS aggregation signature is performed to generate an oracle aggregation signature. The median value of the reported values ​​from each node is used as the final adopted rule parameter value. This median value strategy effectively resists data pollution attacks from a few malicious nodes. Even if less than one-third of the nodes submit erroneous data, the median value strategy can still ensure the correctness of the final rule parameter and send the rule parameter and aggregate signature back to the on-chain oracle adapter contract.

[0089] On-chain rule parameter verification and storage phase: The oracle adapter contract verifies the legality of the aggregate signature. After successful verification, it writes the rule parameters into the jurisdiction rule storage contract and generates the jurisdiction rule commitment hash.

[0090] ;

[0091] in, The hash of the jurisdictional rule commitment is used to subsequently prove that the rule parameters have not been tampered with. For the combination of jurisdictions The set of rule parameters, The block timestamp at which the rule was written serves as the starting point for the rule's validity period;

[0092] Rule Parameter Mounting and Legal Effectiveness Declaration Locking Phase: The compliance function contract loads the corresponding rule parameters from the jurisdiction rule storage contract and uses them as the execution parameters for the current trade order. At the same time, the contract writes a legal effectiveness declaration record into the underlying ledger of the audit ledger contract. This record includes the unique identifier of the trade order, the jurisdiction codes of the buyer and seller, the hash of the jurisdiction rule commitment, the ICC rule text version number (such as Incoterms2020), and the block timestamp of the legal effectiveness declaration. Once written into the audit ledger contract, this record cannot be tampered with and constitutes the original on-chain evidence of the applicable law of the contract, which can serve as a credible basis for courts in various jurisdictions to determine the applicable law of the contract.

[0093] V. Alternative Implementation Methods:

[0094] Alternative Implementation Method 1: Consortium Blockchain Implementation Based on the Hyperledger Fabric Platform:

[0095] In strictly regulated financial and trade scenarios, the two-layer contract proxy architecture of this invention can be migrated to the Hyperledger Fabric platform. Specifically, the underlying audit ledger contract is replaced by Fabric's private data set, enabling append-only event hash storage. The business function contract address mapping update mechanism of the diamond proxy routing contract is replaced by Fabric's chaincode lifecycle management interface. Each business rule update must meet a preset endorsement strategy (such as Byzantine fault-tolerant majority organization signature approval, equivalent to the function of multi-party secure computation threshold signature). The new chaincode version can only be submitted and take effect after being endorsed by a majority of organizations. The zero-knowledge proof selective disclosure module and the jurisdiction compliance adapter module can be connected to the off-chain trusted execution environment and oracle network through Fabric's external chaincode interface. This alternative method is subject to the admission control of the Fabric consortium blockchain and has a relatively low degree of decentralization, but it has better applicability in scenarios with strict regulatory compliance requirements.

[0096] Alternative Implementation Method Two: High-throughput Implementation Based on the STARK Proof System and Validium Architecture:

[0097] In large-scale trading platforms with extremely high transaction concurrency requirements (such as daily transaction volume exceeding one million), the Groth16 proof system in the zero-knowledge proof selective disclosure module can be replaced with the STARK (based on hash functions, requiring no trusted initialization ritual) proof system. The Validium architecture is adopted to store both state data and proof data off-chain, submitting only the validity proof to the main chain. In the Validium model, data availability is guaranteed by the data availability committee. Trading participants and regulatory agencies can obtain data endorsed by zero-knowledge proofs from the committee at any time, further reducing on-chain gas costs. At the same time, it eliminates the theoretical security risk of contamination of trusted initialization ritual parameters in the Groth16 scheme. The trade-off is that the size of the STARK proof is much larger than that of the Groth16 proof, and the generation time is longer, requiring stronger off-chain trusted execution environment computing power. In addition, the data availability assumption of Validium needs to be combined with multi-party threshold signatures to carry out decentralized governance of the data availability committee.

[0098] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A trusted trading and management platform for trade data based on smart contracts, characterized in that: This includes a two-layer contract proxy module deployed on a blockchain network, a zero-knowledge proof selective disclosure module, and a jurisdictional compliance adapter module; The two-layer contract proxy module includes an audit ledger contract and a diamond proxy routing contract. The audit ledger contract stores trade event hash digests, participant signatures, and compliance revision change records in an append-only manner. The diamond proxy routing contract maintains a mapping table from function selectors to business function contract addresses and forwards user requests to the corresponding business function contracts for execution through delegated call instructions. The event hashes generated by the execution are synchronously submitted to the audit ledger contract for permanent archiving. The mapping table update of the diamond proxy routing contract is subject to the condition that the consensus signatures of a preset threshold number of participants are verified on-chain. Each mapping table update operation is fully recorded in the audit ledger contract. The zero-knowledge proof selective disclosure module includes an off-chain trusted execution environment, an on-chain validator contract, and a zero-knowledge proof registry. The off-chain trusted execution environment generates zero-knowledge proofs based on trade document data. The on-chain validator contract receives zero-knowledge proofs and public inputs and performs elliptic curve pairing operations to verify them. Records that pass the verification are written to the zero-knowledge proof registry. The original business data is not submitted to the blockchain. The jurisdiction compliance adapter module includes a digital identity resolver, an oracle adapter contract, a jurisdiction rule storage contract, and a decentralized oracle node network. The digital identity resolver extracts the jurisdiction identifier from the digital identity certificate of the transaction subject. The oracle adapter contract broadcasts a jurisdiction rule query request to the decentralized oracle node network. The decentralized oracle node network returns authoritative legal rule parameters through threshold signature aggregation and median value strategy. The jurisdiction rule storage contract stores the rule parameters. After the compliance function contract attaches the rule parameters, it writes the legal validity declaration record into the audit ledger contract.

2. The trusted trading and management platform for trade data based on smart contracts according to claim 1, characterized in that: The two-layer contract proxy module also includes several business function contracts, including payment function contracts, logistics function contracts, quality inspection function contracts, compliance function contracts, and dispute resolution function contracts. The audit ledger contract is not upgraded once deployed. The diamond proxy routing contract is implemented based on the EIP-2535 diamond proxy standard. It forwards user calls to the corresponding business function contracts through delegated call instructions. The state changes generated by business execution are written to the storage space of the diamond proxy routing contract. The audit ledger contract does not carry any business logic.

3. The trusted trading and management platform for trade data based on smart contracts according to claim 1, characterized in that: The mapping table update of the diamond proxy routing contract is triggered by the following mechanism: the revision proposal includes the address of the old business function contract to be replaced, the address of the new business function contract that has passed the third-party security audit, the content addressing hash of the revision reason, and the proposal timestamp. The proposal initiator uses a private key to sign the proposal hash to generate a personal signature share. Each participant independently reviews and submits the signature share to the multi-party secure computation coordination node. When the number of collected signature shares reaches the minimum number of signers required for the revision to pass, the minimum number of signers threshold is not less than two-thirds of the total number of participants, rounded up. The multi-party secure computation coordination node performs signature aggregation based on the BLS signature scheme to generate an aggregate signature. After the on-chain contract verifies the legality of the aggregate signature, it updates the pointer of the old business function contract address in the mapping table to the new business function contract address, and permanently writes the change record containing the old and new addresses, proposal hash, aggregate signature, and block timestamp into the audit ledger contract.

4. The trusted trading and management platform for trade data based on smart contracts according to claim 1, characterized in that: The zero-knowledge proof selective disclosure module is equipped with a transaction amount compliance verification circuit, a goods origin compliance verification circuit, and a document integrity and authenticity verification circuit for multimodal trade documents. The off-chain trusted execution environment receives the proof key generated by a one-time trusted initialization ceremony during system deployment, generates zero-knowledge proofs through the Groth16 proof algorithm, and stores the corresponding verification key during deployment of the on-chain validator contract and calls the BN254 elliptic curve pairing precompiled contract to perform verification operations.

5. The trusted trading and management platform for trade data based on smart contracts according to claim 4, characterized in that: The constraints of the transaction amount compliance verification circuit include: the Poseidon hash value obtained by concatenating the actual transaction amount with the random salt value is equal to the Pedersen commitment value stored on the chain, and the actual transaction amount is within the closed interval between the lower and upper bounds of the compliance amount set by the regulatory authority. The actual transaction amount and the random salt value are used as private inputs and are not recorded on the chain, while the Pedersen commitment value, the lower bound of the compliance amount, and the upper bound of the compliance amount are recorded on the chain as public parameters.

6. The trusted trading and management platform for trade data based on smart contracts according to claim 4, characterized in that: The constraints of the goods origin compliance verification circuit include: the membership proof paths of the country codes of suppliers at each level of the supply chain in the compliance origin whitelist Merkle tree are all verified by Merkle membership, and the Poseidon hash value of all levels of country codes concatenated with random salt values ​​is equal to the origin binding commitment value stored on the chain. The supplier identity, country code and membership proof path are private inputs and are not recorded on the chain. The root hash of the compliance origin whitelist Merkle tree is publicly released by the regulatory agency and registered on the chain, and together with the origin binding commitment value, it serves as a public parameter.

7. The trusted trading and management platform for trade data based on smart contracts according to claim 4, characterized in that: The constraints of the document integrity and authenticity verification circuit include: the Poseidon hash value calculated from the original document content is equal to the original document hash value registered on the chain; the original document content is used as a private input and not recorded on the chain; and the original document hash value registered on the chain is used as a public parameter.

8. The trusted trading and management platform for trade data based on smart contracts according to claim 1, characterized in that: The digital identity resolver extracts the buyer's jurisdiction code and the seller's jurisdiction code from the digital identity book conforming to the W3CDID standard. It generates a jurisdiction combination identifier based on the Poseidon hash value concatenated from the buyer's jurisdiction code, the seller's jurisdiction code, and the trade type enumeration value. The oracle adapter contract uses the jurisdiction combination identifier as an index to check the cache in the jurisdiction rule storage contract. If the cache does not exist, it initiates a rule query request to the decentralized oracle node network. If the cache exists and the difference between the current block timestamp and the cache update timestamp exceeds a preset time-to-live threshold, it also re-initiates a rule query request to the decentralized oracle node network. When storing rule parameters, the jurisdiction rule storage contract synchronously generates a jurisdiction rule commitment hash obtained by concatenating the rule parameters, the jurisdiction combination identifier, and the block timestamp.

9. The trusted trading and management platform for trade data based on smart contracts according to claim 8, characterized in that: In the decentralized oracle node network, each authoritative data source node independently queries the authoritative legal database and uses its own BLS private key to sign the report hash, generating a signature share. When the number of collected signature shares reaches a preset oracle consensus threshold, BLS aggregation signing is executed. The decentralized oracle node network selects the median value of the reported values ​​from each node as the final adopted rule parameter, and sends the rule parameter and aggregation signature back to the oracle adapter contract. After verifying the legality of the aggregation signature, the oracle adapter contract writes the rule parameter into the jurisdiction rule storage contract, and the compliance function contract writes the legally effective statement containing the jurisdiction codes of both the buyer and seller, the jurisdiction rule commitment hash, and the ICC rule text version number into the audit ledger contract.

10. A method for trusted transaction and management of trade data based on smart contracts, characterized in that: The platform, employing a two-tier contract proxy module, a zero-knowledge proof selective disclosure module, and a jurisdictional compliance adapter module, performs the following processes: Trade event recording process: Trade participants call the corresponding business function contract through the diamond proxy routing contract to execute trade operations. The diamond proxy routing contract maintains a mapping table from function selectors to business function contract addresses based on the EIP-2535 diamond proxy standard. The event hash digest, timestamp, and participant signature generated during execution are written to the audit ledger contract in an append-only manner. Compliance Revision Process: The revision proposal is independently reviewed and signed by each participating party to generate a signature share. When the number of signature shares reaches the minimum number of signers (rounded up) of no less than two-thirds of the total number of participating parties, the multi-party secure computation coordination node performs BLS signature aggregation. After the on-chain contract verifies the legality of the aggregated signature, it updates the mapping table address pointer and writes the change record containing the new and old business function contract addresses, proposal hash, and aggregated signature into the audit ledger contract. Selective disclosure process: Trade participants generate zero-knowledge proofs for multimodal trade documents in an off-chain trusted execution environment, submit the zero-knowledge proofs and public inputs to the on-chain validator contract to perform BN254 elliptic curve pairing operation verification, and write the verified records to the zero-knowledge proof registry. Regulatory agencies obtain compliance confirmation with cryptographic endorsement by querying the zero-knowledge proof registry. The original business data is not submitted to the blockchain. Jurisdiction rule loading process: The compliance function contract calls the digital identity resolver to extract the jurisdiction identifier from the digital identity certificate of the transaction subject. The oracle adapter contract broadcasts the jurisdiction rule query request to the decentralized oracle node network. After the decentralized oracle node network determines the rule parameters through threshold signature aggregation and median value strategy, it stores them in the jurisdiction rule storage contract. The compliance function contract attaches the rule parameters, performs compliance verification, and writes the legal validity statement record into the audit ledger contract.

Images