A blockchain-based decentralized trusted data transaction method and system

Abstract

The application belongs to the technical field of blockchain and data security, and relates to a decentralized trusted data transaction method and system based on a blockchain, which comprises the following steps: running an intelligent contract on the blockchain; a data holder generates a symmetric key and encrypts data assets, uploads the data assets to a star file system and registers on the chain; a data buyer initiates a transaction and locks a corresponding number of stable coins at a fixed price; the data holder encrypts the symmetric key by using a public key of the buyer and submits the symmetric key; the data buyer decrypts the symmetric key by using a private key, downloads the encrypted data assets and decrypts the data assets; if a dispute request is initiated, on-chain arbitration is performed, and the stable coins are determined according to the arbitration result. The technical scheme of the application realizes full-process decentralized management of data assets by running an intelligent contract on the blockchain, and can meet the needs of strong binding of funds and data, real and verifiable key delivery and automatic dispute processing in the data transaction process.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and data security technology, and specifically relates to a decentralized trusted data transaction method and system based on blockchain. Background Technology

[0002] In existing technologies, data transactions typically rely on centralized third-party institutions to provide data hosting, payment settlement, and delivery management, establishing a unified platform to meet the matching and execution needs of data transactions. However, the existing centralized architecture has some obvious shortcomings. Since both data and funds are centrally managed by the platform, if the platform experiences system failures or operational risks, it is highly susceptible to single points of failure or even absconding with funds, seriously threatening the rights and interests of both parties in the transaction.

[0003] Meanwhile, existing technologies lack effective key delivery and verification mechanisms during data delivery. When data holders transfer keys, they often rely on off-chain methods or platform intermediaries. Data buyers find it difficult to verify the integrity and authenticity of the keys they acquire, posing a risk of tampering or misuse. This not only affects the reliable delivery of data assets but also creates hidden dangers for transaction security.

[0004] Secondly, in terms of fund settlement, traditional methods often rely directly on transfers or platform escrow, making it difficult to achieve synchronous control of fund and data delivery. Even though some blockchain projects support token-based payments, they have not been able to solve the problem of strong binding between fund custody and data delivery. This means that even if one party fulfills its obligations in a transaction, the other party may still default, making it difficult to form a closed loop between fund and data delivery and reducing transaction efficiency and credibility.

[0005] Furthermore, in the event of a transaction dispute, existing technologies generally lack on-chain arbitration and automatic adjudication mechanisms, and dispute resolution still relies on manual coordination, lacking transparency, traceability, and automatic execution guarantees.

[0006] This demonstrates that existing technologies often suffer from unreliable and insecure fund custody and key delivery mechanisms during data transactions. This is a shortcoming of existing technologies.

[0007] In view of this, it is very necessary to provide a decentralized trusted data transaction method and system based on blockchain to solve the above-mentioned defects in the prior art. Summary of the Invention

[0008] The purpose of this invention is to address the shortcomings of existing technologies in data transaction processes, such as unreliable fund custody and key delivery mechanisms that are difficult to guarantee security, by providing a decentralized and trusted data transaction method and system based on blockchain to solve the aforementioned technical problems.

[0009] To achieve the above objectives, the present invention provides the following technical solution: A decentralized, trusted data transaction method based on blockchain includes the following steps: Running smart contracts on the blockchain, including data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts; The data holder generates a symmetric encryption key for the data asset and encrypts the data asset. The encrypted data asset is then uploaded to the InterPlanetary File System, and the data registration contract is invoked to register the metadata of the data asset on the blockchain. The metadata includes the pricing of the data asset in stablecoins. The data buyer initiates a transaction, invokes the fund custody contract, locks the corresponding amount of stablecoins, and the fund custody contract generates a transaction identifier. The data holder invokes the key exchange contract to obtain and use the public key registered on the chain by the data buyer to encrypt the symmetric encryption key, and submits the encrypted symmetric encryption key to the key exchange contract and binds it to the transaction identifier; The data buyer obtains the encrypted symmetric encryption key based on the transaction identifier, decrypts it using the private key corresponding to the public key, obtains the symmetric encryption key, and downloads and decrypts the encrypted data asset from the InterPlanetary File System to obtain the data asset; If the data purchaser initiates a dispute request during the designated dispute complaint period, the arbitration contract will be invoked to execute on-chain arbitration, and the destination of the stablecoins will be determined based on the arbitration result. If no dispute request is initiated during the dispute complaint period, or if the arbitration contract rules that delivery has been completed, the fund custody contract will release the stablecoins to the data holder. If the arbitration contract rules that delivery has not been completed, the fund custody contract will release the stablecoins to the data purchaser.

[0010] By adopting the above technical solution, and by running smart contracts containing data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts on the blockchain, decentralized management of data assets throughout the entire process is achieved. This ensures the security and traceability of data delivery and fund settlement in transactions, and meets the needs of strong binding between funds and data, verifiable key delivery, and automated dispute resolution in the data transaction process.

[0011] The solution comprises several key elements: a data registration contract, which allows data holders to register their data asset metadata on the blockchain, ensuring the metadata's immutability and enhancing the credibility of the data source; a fund custody contract, which allows data buyers to hold their funds in custody before payment, mitigating pre-delivery financial risks and providing a traceable fund mapping after transaction identification; a key exchange contract, which ensures the security of symmetric encryption keys delivered on-chain after encryption, preventing tampering or hijacking issues common in traditional off-chain transmission; an arbitration contract, which enables on-chain arbitration in case of disputes, avoiding subjective uncertainties caused by human intervention and automating and automating dispute resolution; and a dispute complaint period, which provides data buyers with a window for review and feedback before fund release, enhancing fairness and non-repudiation. This comprehensive solution creates a trusted transaction loop with strong data-fund binding, resolving the issue of asynchronous fund and data delivery in existing technologies while improving transaction efficiency and building trust between the parties.

[0012] Preferably, the data holder generates a symmetric encryption key for the data and encrypts the data, including: The data holder calculates the hash value of the data asset and generates a unique symmetric encryption key; The data assets are compressed, and the compressed data assets are then encrypted using a symmetric encryption key.

[0013] This technical solution achieves the following technical effects by calculating hash values ​​and generating unique symmetric encryption keys before data encryption, combined with compression processing: First, by calculating the hash value of data assets and combining it with the generated unique symmetric encryption key, each data asset corresponds to an independent identifier and key, and different transactions do not affect each other, thereby avoiding potential security risks caused by key reuse, and also facilitating the rapid comparison of hash values ​​on the blockchain to verify the integrity and authenticity of the data. Secondly, by compressing data assets, the volume of the original data can be significantly reduced, the computational pressure of the encryption process can be reduced, and the encryption operation can be made more efficient. At the same time, the amount of data uploaded to the InterPlanetary File System is reduced, the amount of data transmitted on and off the chain is reduced, which not only shortens the storage time, but also reduces the burden on storage nodes and significantly reduces bandwidth usage, thereby improving transaction efficiency and overall system scalability. Third, by combining compression with symmetric encryption, data can be transmitted and stored more efficiently while maintaining confidentiality. This dual optimization enables the system to achieve higher performance while ensuring security. Fourth, the overall mechanism enables data holders to perform security and performance optimization on their data before it is put on the blockchain, ensuring that the data entering the blockchain ecosystem is both trustworthy and highly manageable, thus providing a solid data foundation for subsequent fund custody and arbitration processes.

[0014] Preferably, metadata also includes the identifier and hash value of the data asset, the content addressing identifier of the InterPlanetary File System, and the address of the data holder.

[0015] This technical solution achieves the following technical effects by introducing multi-dimensional information into the metadata: First, the introduction of data asset identifiers provides the system with a globally unique index, and each piece of data can be directly located through the identifier, avoiding the management chaos caused by multiple similar data, and also facilitating the formation of a one-to-one transaction mapping relationship on the chain. Second, recording data hash values ​​enables the system to perform rapid verification. Any tampering will result in hash inconsistencies, thereby ensuring data integrity and providing objective technical evidence for arbitration disputes. Third, the registration of content addressing identifiers enables the system to use the InterPlanetary File System for decentralized storage and access, ensuring the traceability and verifiability of data, reducing the risk of relying on a single storage node, and improving the availability of data across nodes. Fourth, the introduction of the data holder's address clarifies the identity of the transaction entity, making it easier to determine the attribution of rights and responsibilities in the event of a dispute, and enabling auditable transaction behavior through the binding of the address with the transaction record; Fifth, through the design of multi-dimensional metadata, the data has the characteristics of being identifiable, verifiable, and traceable throughout the entire transaction chain, which improves the overall credibility of the system and provides strong support for fund custody and arbitration.

[0016] As a preferred approach, when generating a transaction identifier, the fund custody contract associates the transaction identifier, the identifier of the data asset, the address of the data purchaser, and the corresponding amount of stablecoins.

[0017] This technical solution achieves the following technical effects by associating the transaction identifier with multiple pieces of information during the generation process: First, the binding of transaction identifiers and data asset identifiers ensures that each fund custody points to a unique data asset, thereby avoiding the problem of multiple transactions using the same funds or the whereabouts of funds being unknown, and enhancing the transparency of custody funds. Second, by introducing the buyer's address into the transaction identifier, the fund custody is directly linked to the specific buyer's account, which can effectively avoid the risk of third parties impersonating the payment, and at the same time provide a clear responsible party for the transaction record; Third, the binding of the amount of funds corresponding to the pricing with the transaction identifier ensures that the escrow amount is completely consistent with the pricing of the data assets, avoiding problems such as inaccurate fund freezing or mismatch between the payment amount and the data value, thus guaranteeing the fairness of the transaction and the rigor of fund management. Fourth, the aforementioned relationships are written into the blockchain ledger, making the fund custody process open, transparent, and tamper-proof. This not only enhances the credibility of the system but also provides solid on-chain evidence for subsequent arbitration and dispute resolution. It ensures that fund custody is not an isolated act but is closely coupled with the entire data transaction process, thus forming a complete custody mechanism that binds funds and data and is traceable.

[0018] Preferably, the data purchaser signs the public key registration request message using the account's private key and submits the signature to the key exchange contract. The key exchange contract recovers the account address based on the signature and determines whether the account address matches the data purchaser's address. If they match, the data holder is allowed to submit the encrypted symmetric encryption key.

[0019] This technical solution achieves the following technical effects by using the buyer's signature, the key exchange contract to restore the account address, and verify consistency: First, the signature generated by the account's private key is unique and cannot be forged, ensuring that the public key registration request is indeed initiated by the purchaser, effectively eliminating the possibility of submitting a request with a forged identity. Second, the key exchange contract verifies the signature and restores the account address, thus forming a strong binding relationship between the public key submitted off-chain and the account on-chain, thereby ensuring the authenticity and validity of the public key and preventing third parties from replacing or tampering with it. Third, this scheme ensures that the system only allows the data holder to submit the encryption key after the verification is successful, thus guaranteeing the security and uniqueness of the key delivery process and blocking the channel for attackers to intercept or replace the key. Fourth, the entire verification process is executed on-chain, avoiding the inefficiency and lack of transparency caused by off-chain manual verification, and improving the automation and credibility of the verification process. Fifth, by creating a record in the blockchain ledger that verifies the consistency between the signature and the account address, the system can provide tamper-proof evidence in subsequent dispute arbitration, further enhancing the traceability and non-repudiation of the key delivery process.

[0020] As a preferred embodiment, when the key exchange contract receives the encrypted symmetric encryption key, it binds the transaction identifier, the encrypted symmetric encryption key, and the address of the data holder, and triggers a key delivery event to notify the data purchaser to obtain the encrypted symmetric encryption key.

[0021] This technical solution achieves the following technical effects by binding the symmetric encryption key with the transaction identifier and the data holder's address and triggering a delivery event: First, the binding of transaction identifiers and encryption keys ensures a unique correspondence in key delivery. Each encryption key has a clear transaction context, avoiding key mixing or misuse. Second, by introducing the data holder's address during the binding process, the key delivery is directly linked to the holder's identity, ensuring that the key source is clear and enhancing the transparency and traceability of key management; Third, triggering a key delivery event notifies the buyer, enabling them to obtain the delivery status in real time through the blockchain event system, reducing disputes caused by information delays and improving delivery efficiency and user experience; Fourth, the key exchange contract combines evidence-based binding with event notifications, making the key delivery process not only verifiable but also automated, further enhancing the system's intelligence in the delivery phase. Fifth, the scheme forms a complete chain of evidence on the blockchain, making the key delivery result tamper-proof and providing solid on-chain proof for transaction security and arbitration.

[0022] As a preferred approach, when the arbitration contract receives a dispute request, it generates an arbitration transaction identifier, verifies the dispute request, organizes on-chain arbitration nodes to vote on the delivery status corresponding to the transaction identifier, records the voting results and associates them with the transaction identifier, and the fund custody contract determines the destination of the stablecoins based on the voting results.

[0023] This technical solution achieves the following technical effects by generating an arbitration transaction identifier, verifying the request, organizing arbitration node voting, and storing the results upon receiving a dispute request: First, the generation of the arbitration matter identifier provides a unique number for each dispute, enabling the arbitration process to be effectively tracked and distinguished, and avoiding confusion between different disputes; Second, verifying disputed requests can effectively filter out malicious or invalid requests, reduce the waste of arbitration node resources, and improve the fairness and efficiency of the arbitration mechanism. Third, organizing arbitration nodes to vote on the decision ensures the openness and transparency of the arbitration process, avoids the injustice caused by unilateral decision-making, and enhances the credibility of the arbitration results. Fourth, the voting results are bound to the transaction identifier and recorded in the blockchain ledger, making the adjudication process traceable. At the same time, the adjudication results directly drive the fund custody contract to execute release or return operations, thereby automating the fund disposal. Fifth, the on-chain arbitration mechanism significantly improves the efficiency of dispute resolution, reduces the uncertainty of human intervention, and provides an open, fair and efficient dispute resolution channel for the entire transaction system.

[0024] Furthermore, this invention also provides a blockchain-based decentralized trusted data transaction system, comprising: The data encryption module is used to generate symmetric encryption keys for the data holder's data assets and encrypt the data assets. The decentralized storage module is used to store encrypted data assets and return content addressing identifiers; The data registration module, deployed on the blockchain, is used to register the metadata of data assets on the blockchain. The metadata includes the pricing of the data assets in stablecoins. The fund custody module, deployed on the blockchain, is used to receive and lock the amount of stablecoins corresponding to the price paid by the data buyer, and generate a transaction identifier. The key exchange module, deployed on the blockchain, is used to receive and store the encrypted symmetric encryption key submitted by the data holder, and bind it to the transaction identifier to trigger the key delivery event. The arbitration module, deployed on the blockchain, is used to execute the arbitration process upon receiving a dispute request and associate the award with the transaction identifier; The tracking and management module is used to record the correspondence between transaction identifiers and fund status, key status, and arbitration status in the blockchain ledger.

[0025] By adopting the above technical solution, and by setting up data encryption module, decentralized storage module, data registration module, fund custody module, key exchange module, arbitration module, and tracking management module in the system, the secure storage, trusted registration, fund custody, key delivery, and dispute adjudication of data assets are realized throughout the entire process. This forms a well-structured and fully functional decentralized data trading system that meets the needs of secure data asset transfer in a trusted environment.

[0026] The system comprises several key components: a data encryption module that ensures data holders can perform symmetric encryption on their data assets before they are uploaded to the blockchain, avoiding the risk of directly exposing the original data; a decentralized storage module that combines content-addressed identifiers with encrypted data storage to ensure data integrity and tamper-proofness at the storage level; a data registration module deployed on the blockchain that can register and store metadata information of data assets, providing a reliable index for transactions; a fund custody module that provides a blockchain-based stablecoin custody and transaction identifier generation mechanism, making fund status transparent and traceable; a key exchange module that can store encrypted keys and bind transaction identifiers during data delivery, achieving a secure key transfer path; an arbitration module that ensures automated adjudication and fund release control in transaction dispute scenarios, improving fairness and reliability; and a tracking management module that implements unified mapping and on-chain recording of transaction identifiers, fund status, key status, and arbitration status, making the entire system transparent and traceable.

[0027] As a preferred option, the fund custody module is used to associate the transaction identifier, the identifier of the data asset, the address of the data buyer, and the corresponding amount of stablecoins when generating the transaction identifier, and record it in the blockchain ledger.

[0028] This fund custody module achieves the following technical effects by associating and recording the transaction identifier with the data asset identifier, the buyer's address, and the amount of stablecoins on the blockchain during transaction generation: First, the binding of fund custody and data asset identification forms a one-to-one correspondence, which prevents the custody funds from being misappropriated or mixed across transactions, fundamentally improving the exclusivity of the custody funds. Second, by writing the buyer's address as an important related element of fund custody into the blockchain ledger, the source of funds payment is clearly traceable, which helps in subsequent responsibility determination and compliance review. Third, the direct correspondence between the amount of escrowed funds and the pricing ensures that the frozen amount is fully matched with the transaction demand, avoiding underpayment or overpayment, and enhancing the accuracy and rigor of fund management. Fourth, the blockchain ledger records complete related information, making the fund custody process transparent and open, and all relevant parties can verify it, thereby improving the trust and non-repudiation of the transaction; Fifth, the scheme forms a complete chain of evidence for fund custody by fully binding funds with data identifiers, accounts, and amounts, providing strong protection for the system's fund security.

[0029] Preferably, the key exchange module is used to recover the account address based on the signature after receiving the signature submitted by the data purchaser, and to determine whether the account address is consistent with the address of the data purchaser. If they are consistent, the data holder is allowed to submit the encrypted symmetric encryption key.

[0030] This key exchange module achieves the following technical effects by recovering the account address based on the received signature and performing a consistency check: First, by recovering the account address through signature, it is ensured that the verification process relies on the underlying cryptographic algorithm, which is unforgeable and highly reliable, providing a solid security foundation for transactions; Second, consistency verification ensures that the identity of the user submitting the request corresponds to the real account on the chain, avoiding the possibility of forging signatures or impersonating others to carry out illegal operations; Third, the system only allows the data holder to submit the encryption key after the verification is passed, which ensures from a systemic perspective that the key will not be delivered to the wrong recipient, and enhances the accuracy and reliability of the key delivery process. Fourth, this mechanism is executed on the blockchain, without relying on external systems, which improves the automation of the verification process and avoids potential security vulnerabilities caused by off-chain verification. Fifth, the scheme creates a record in the blockchain ledger that corresponds to the signature verification and the account address. All verification actions are traceable and auditable, providing strong evidence for subsequent arbitration and compliance, and significantly improving the system's level of security and verifiability.

[0031] The beneficial effects of this invention are that by running smart contracts on the blockchain, including data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts, it achieves decentralized management of the entire data asset process, which can ensure the security and traceability of data delivery and fund settlement in transactions, and meet the needs of strong binding of funds and data, verifiable key delivery, and automated dispute resolution in the data transaction process.

[0032] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects.

[0033] Therefore, it is evident that the present invention has outstanding substantive features and significant progress compared with the prior art, and the beneficial effects of its implementation are also obvious. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0035] Figure 1 This is a flowchart of a decentralized trusted data transaction method based on blockchain provided by the present invention; Figure 2 This is a schematic diagram of a decentralized and trusted data trading system based on blockchain provided by the present invention.

[0036] The modules include: 1. Data encryption module; 2. Decentralized storage module; 3. Data registration module; 4. Fund custody module; 5. Key exchange module; 6. Arbitration module; and 7. Tracking and management module. Detailed Implementation

[0037] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following implementation methods.

[0038] Example 1: like Figure 1 As shown in the figure, this embodiment provides a decentralized trusted data transaction method based on blockchain, which includes the following steps: A decentralized, trusted data transaction method based on blockchain includes the following steps: Step S1: Run smart contracts on the blockchain. Smart contracts include data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts. Step S2: The data holder generates a symmetric encryption key for the data asset and encrypts the data asset. The encrypted data asset is then uploaded to the InterPlanetary File System, and the data registration contract is invoked to register the metadata of the data asset on the blockchain. The metadata includes the pricing of the data asset in stablecoins. Step S3: The data buyer initiates a transaction, calls the fund custody contract, locks the corresponding amount of stablecoins, and the fund custody contract generates a transaction identifier; Step S4: The data holder calls the key exchange contract to obtain and use the public key registered on the chain by the data buyer to encrypt the symmetric encryption key, and submits the encrypted symmetric encryption key to the key exchange contract and binds it to the transaction identifier. Step S5: The data buyer obtains the encrypted symmetric encryption key based on the transaction identifier, decrypts it using the private key corresponding to the public key, obtains the symmetric encryption key, and downloads and decrypts the encrypted data asset from the InterPlanetary File System to obtain the data asset; Step S6: If the data purchaser initiates a dispute request within the set dispute complaint period, the arbitration contract will be invoked to execute on-chain arbitration, and the destination of the stablecoins will be determined according to the arbitration result. If no dispute request is initiated within the dispute complaint period, or if the arbitration contract rules that the delivery has been completed, the fund custody contract will release the stablecoins to the data holder. If the arbitration contract rules that the delivery has not been completed, the fund custody contract will release the stablecoins to the data purchaser.

[0039] By adopting the above technical solution, and by running smart contracts containing data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts on the blockchain, decentralized management of data assets throughout the entire process is achieved. This ensures the security and traceability of data delivery and fund settlement in transactions, and meets the needs of strong binding between funds and data, verifiable key delivery, and automated dispute resolution in the data transaction process.

[0040] Specifically, the data registration contract enables data holders to register the metadata of their data assets on the blockchain, ensuring that the metadata cannot be tampered with after registration and enhancing the credibility of the data source. The introduction of the fund custody contract allows the funds of the data buyer to enter a custody state before payment, avoiding financial risks before data delivery, and providing a traceable fund mapping relationship after the transaction identifier is generated. The operation of the key exchange contract ensures the security of the symmetric encryption key delivered on the blockchain after encryption, avoiding the tampering or hijacking problems of traditional off-chain transmission. The arbitration contract enables on-chain arbitration in the event of a transaction dispute, avoiding the subjective uncertainty of relying on human intervention and realizing the automation and transparency of dispute resolution. By setting a dispute complaint period, the system can give the data buyer a time window for inspection and feedback before the funds are released, enhancing the fairness and non-repudiation of the transaction.

[0041] This method achieves a trusted transaction loop with strong data and funds binding, solving the problem of asynchronous fund and data delivery in existing technologies, while improving transaction efficiency and the foundation of trust between the two parties.

[0042] Hereinafter, steps S1 to S6 will be specifically described according to embodiments of this application.

[0043] It should be noted in advance that in this embodiment, IPFS (InterPlanetary File System) is used as a decentralized content-addressable storage infrastructure. Its core is to uniquely correspond to the storage object through CID (ContentIdentifier) ​​to ensure the global uniqueness and verifiability of the content. The design of IPFS integrates a variety of distributed technologies, such as P2P (Peer-to-Peer), DHT (Distributed Hash Table), Merkle-DAG (Merkle Directed Acyclic Graph), the versioning concept of Git (Global Information Tracker), the fragmentation and exchange mechanism of BitTorrent, the self-certified naming mechanism, and IPNS (InterPlanetary Naming System), thereby providing support for data distribution, location, integrity verification, and naming updates. At the same time, the system enables fixed policies in the node configuration to prevent block loss caused by garbage collection, and can deploy gateways and private bootstrap nodes as needed to improve availability. To facilitate on-chain referencing and cross-node verification, multi-hash encoding and CID v1 representation can be used; for large files, fragmentation and Merkle-DAG structure can be enabled to reduce the pressure of single-block transmission.

[0044] It should be emphasized that in this embodiment of the application, only metadata such as CID is registered and referenced on the chain, the file body is stored in IPFS, and the objects stored in the transaction scenario are encrypted data files. Plaintext content is not stored on the chain, nor does it rely on a centralized file server, thereby realizing verifiable location and retrieval capabilities at the system level, while avoiding single point of failure and the risk of arbitrary deletion.

[0045] Secondly, the term "data asset" in this application refers to digital data resources that have been legally registered and possess the characteristics of value exchange. These resources include not only structured or unstructured text data, image data, and video data, but also real-time data streams collected by the Internet of Things or sensors, and sample datasets that can be used to train artificial intelligence models. The difference between data assets and ordinary data lies in their ownership, scarcity, and tradability; they can be priced and exchanged in the market through digital currencies such as stablecoins.

[0046] Furthermore, the term "stablecoin" in this application refers to a cryptocurrency pegged to fiat currencies (such as the US dollar, the euro, etc.) and circulating through on-chain tokens, such as USDT (Tether USD) and USDC (USD Coin). Stablecoins are used for fund custody and settlement in this application's embodiments. Their value is relatively stable, avoiding the trading risks associated with excessive volatility in ordinary cryptocurrencies. Simultaneously, all fund-related operations in this application's embodiments are priced and settled in stablecoins and do not involve non-stablecoin cryptocurrencies.

[0047] In step S1, a data registration contract, a fund custody contract, a key exchange contract, and an arbitration contract are run on the blockchain. Each contract is deployed at an independent address and invoked through a fixed interface agreement. For example, a chain environment compatible with the Ethereum Virtual Machine (EVM) can be used to facilitate interface reuse and security auditing.

[0048] Specifically, in this embodiment, the data registration contract is responsible for persisting on-chain metadata. Its storage structure includes at least a state mapping for fields representing data asset hash values, IPFS content addressing identifiers, data holder addresses, and pricing denominated in stablecoins. To reduce lookup complexity, bytes32 can be used as the primary key index (which can be derived from hashing or other deterministic algorithms). The contract exposes a read-only query interface for external retrieval and publishes registration entries through an event log. The event topic includes a summary of the primary key and key fields to facilitate reverse retrieval by off-chain indexing services. To avoid permission violations, registration writes only accept transactions from data holder addresses. For duplicate registrations with the same primary key, the contract performs idempotent or versioning processing, with the version number incrementing with each update and reflected in the event.

[0049] The fund custody contract is responsible for interacting with the stablecoin contract and recording the custody status. During deployment, the stablecoin contract address is written to an immutable or administrator-updatable storage slot, and reentrancy protection and limit verification mechanisms are enabled. The custody document is indexed by the transaction identifier txId, and internally stores elements such as the buyer's address, data asset identifier, and the amount of stablecoins corresponding to the pricing, while exposing read-only status queries and event logs. At the same time, the precision of the custody amount is consistent with the precision of the stablecoin, and the amount comparison is performed directly using unsigned integers to avoid decimal errors.

[0050] The key exchange contract is responsible for receiving, binding, and verifying the on-chain key payload. During the deployment phase, the contract completes address binding with the fund custody contract and data registration contract, and establishes a minimum authorization whitelist to restrict the source of cross-contract callbacks. The contract storage indexes key record entries with transaction identifiers. Each entry includes the key submitter's address, a digest (e.g., hash) of the key payload, and its on-chain storage location identifier. To improve traceability, the contract generates an event for each write, with the event subject containing the transaction identifier and the submitter's address. To support account-level signature verification and address consistency checks, the contract has built-in signature recovery tool methods (such as a wrapper around ecrecover) and fixes the field separation parameters required for verification (such as chainId, contract name, and version number) in storage so that message digests are generated off-chain according to the same field.

[0051] The arbitration contract is used to store necessary parameters and arbitration results records within the dispute domain. During deployment, system default values ​​and adjustable boundaries for the dispute complaint period are set, and the set of arbitration nodes related to the vote or their source contract addresses are recorded. To ensure compliance of modifications, parameter adjustments are only allowed through a preset governance entry point, and the hash digests of the old and new parameters and the effective block height are publicly disclosed in the event. The storage structure of the arbitration contract uses the transaction identifier as the primary key, storing the arbitration transaction identifier, status code, and result digest. All state transitions are solidified on-chain using a finite state machine and broadcast externally via events for use by external indexing and auditing tools.

[0052] To improve overall maintainability and security, each contract can use explicit error codes and self-explanatory rollback reasons, and add assertions and input field validation before and after critical external calls; to reduce the risks introduced by upgrades, contracts can use a transparent proxy mode, and upgrade permissions are restricted by multi-signature or time locks; log events are uniformly arranged in a fixed topic order, and the field order, type and storage structure are aligned to facilitate off-chain parsing.

[0053] Furthermore, in this embodiment, to ensure consistency across contract references, a registry of contracts is written on the chain after deployment, recording the on-chain addresses, version numbers, and interface hashes of the data registration contract, fund custody contract, key exchange contract, and arbitration contract. Business calls only accept mutual call requests from addresses listed in this registry, thereby preventing the infiltration of forged contract addresses. Simultaneously, to ensure consistency in stablecoin accounting, a unique stablecoin contract address (e.g., a token contract address conforming to the ERC-20 smart contract protocol standard on the Ethereum blockchain) and its precision parameters are set during the deployment phase, and recorded uniformly in the custody logic using the smallest unit of measurement. On-chain time uniformly adopts block timestamps; the chain identifier, chainId, is fixed in contract storage for signature domain isolation.

[0054] Through the above deployment and operation arrangements, step S1 completed the basic environment construction on the chain involving four core capabilities: metadata, fund custody, key exchange and arbitration, and provided consistent interface agreements and auditable state records to the outside world, providing a reliable, verifiable and traceable operating foundation for the execution of subsequent processes.

[0055] In step S2, the data holder needs to encrypt the data assets to be traded and complete on-chain registration. This includes four technical steps: key generation, data compression and encryption, IPFS upload, and metadata registration. This ensures that the data assets can be securely stored in encrypted form and that verifiable metadata information is formed on the blockchain.

[0056] First, in the key generation stage, the data holder calculates the hash value of the data asset to be traded, for example, using the SHA-256 algorithm to obtain a 32-byte digest. This hash value is not only used for subsequent data integrity verification but also serves as a seed for generating a unique symmetric encryption key. Key generation can utilize a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) combined with the data hash input, thereby avoiding security vulnerabilities associated with fixed or low-entropy keys. For example, the generated symmetric encryption key can be 128 bits or 256 bits long to balance security strength and encryption / decryption efficiency.

[0057] Secondly, in the data compression and encryption stage, the data holder first compresses the original data assets to reduce data volume and improve storage and transmission efficiency. After compression, the compressed result is encrypted using the generated symmetric encryption key. The encrypted output is a ciphertext data file that cannot be deciphered without the correct key. For example, the compression algorithm can be a lossless algorithm such as Deflate, LZ4, or Zstandard; the encryption algorithm can be AES (Advanced Encryption Standard), using GCM mode (Galois / Counter Mode) or CTR mode (Counter Mode) to ensure performance advantages in parallel computing and integrity verification.

[0058] This step, by calculating the hash value and generating a unique symmetric encryption key before data encryption, combined with compression processing, achieves the following technical effects: First, by calculating the hash value of data assets and combining it with the generated unique symmetric encryption key, each data asset corresponds to an independent identifier and key, and different transactions do not affect each other, thereby avoiding potential security risks caused by key reuse, and also facilitating the rapid comparison of hash values ​​on the blockchain to verify the integrity and authenticity of the data. Secondly, by compressing data assets, the volume of the original data can be significantly reduced, the computational pressure of the encryption process can be reduced, and the encryption operation can be made more efficient. At the same time, the amount of data uploaded to the InterPlanetary File System is reduced, the amount of data transmitted on and off the chain is reduced, which not only shortens the storage time, but also reduces the burden on storage nodes and significantly reduces bandwidth usage, thereby improving transaction efficiency and overall system scalability. Third, by combining compression with symmetric encryption, data can be transmitted and stored more efficiently while maintaining confidentiality. This dual optimization enables the system to achieve higher performance while ensuring security. Fourth, the overall mechanism enables data holders to perform security and performance optimization on their data before it is put on the blockchain, ensuring that the data entering the blockchain ecosystem is both trustworthy and highly manageable, thus providing a solid data foundation for subsequent fund custody and arbitration processes.

[0059] Then, in the storage phase, the data holder uploads the encrypted data asset to IPFS. During the upload process, the IPFS node will split the file into fragments, each fragment being 256KB in size by default and organized using a Merkle-DAG structure. The CID generated by the system is the globally unique index of the data asset in IPFS. At the same time, the data holder needs to perform a pinning operation on the local node to ensure that the data fragments are not deleted due to the garbage collection mechanism. If necessary, availability can be improved through multi-node backup and IPFS private network deployment.

[0060] Finally, in the metadata registration phase, the data holder invokes the data registration contract deployed and running on the blockchain to write the aforementioned key information into on-chain storage.

[0061] In some embodiments of this application, the metadata fields include at least the identifier of the data asset (which may be a UUID or a bytes32 value derived by the system), the hash value (corresponding to the data before compression, depending on the implementation design), the IPFS CID, the data holder's account address, and the stablecoin pricing of the data asset.

[0062] In some other embodiments of this application, the metadata field may also include creation time, data status, etc.

[0063] To ensure consistency in registration, the contract uses a struct to record the aforementioned metadata and uses a mapping to index the data asset identifier. After the transaction is completed, the data registration contract will trigger an event log, which contains the data asset identifier and CID, facilitating off-chain service subscription and retrieval.

[0064] By introducing multi-dimensional information into the metadata, this step achieves the following technical effects: First, the introduction of data asset identifiers provides the system with a globally unique index, and each piece of data can be directly located through the identifier, avoiding the management chaos caused by multiple similar data, and also facilitating the formation of a one-to-one transaction mapping relationship on the chain. Second, recording data hash values ​​enables the system to perform rapid verification. Any tampering will result in hash inconsistencies, thereby ensuring data integrity and providing objective technical evidence for arbitration disputes. Third, the registration of content addressing identifiers enables the system to use the InterPlanetary File System for decentralized storage and access, ensuring the traceability and verifiability of data, reducing the risk of relying on a single storage node, and improving the availability of data across nodes. Fourth, the introduction of the data holder's address clarifies the identity of the transaction entity, making it easier to determine the attribution of rights and responsibilities in the event of a dispute, and enabling auditable transaction behavior through the binding of the address with the transaction record; Fifth, through the design of multi-dimensional metadata, the data has the characteristics of being identifiable, verifiable, and traceable throughout the entire transaction chain, which improves the overall credibility of the system and provides strong support for fund custody and arbitration.

[0065] Through step S2, data assets complete secure encryption, decentralized storage, and on-chain registration of metadata before entering the transaction. This ensures the confidentiality and integrity of data during storage and transmission, and provides a reliable on-chain reference basis for subsequent fund custody, key exchange, and arbitration processes.

[0066] In step S3, the data buyer needs to lock stablecoins through a fund custody contract and generate a transaction identifier unique to this transaction. The key to this step is to ensure the atomicity and verifiability of the fund freezing operation, while establishing a one-to-one correspondence between the transaction identifier and the data assets, the buyer's account, and the escrow amount.

[0067] Specifically, firstly, the data buyer initiates a transaction request in a client or wallet application, invoking the on-chain escrow contract. The transaction request must include authorization for the required stablecoin amount, meaning the escrow contract is authorized in advance to transfer a specified amount of stablecoins via the `approve` method of the ERC-20 token contract. For example, the entry point can be `purchase(dataId)` or an equivalent interface, where `dataId` corresponds to the data asset identifier registered in step S2.

[0068] Within the fund custody contract, the execution logic first calls the stablecoin contract's transferFrom interface to transfer the corresponding amount of stablecoins from the data purchaser's account address to the fund custody contract's own account. During execution, the contract checks if the transfer was successful; if the amount is insufficient or the authorized limit is not met, a rollback is triggered. This operation ensures that funds are locked before the transaction identifier is generated, thus avoiding the situation of "transactions without funds."

[0069] Next, the fund custody contract generates a transaction identifier to uniquely identify a specific data transaction. This identifier is obtained by hashing parameters such as the data asset identifier, the data buyer's address, and the block timestamp. The transaction identifier is not only unique on the blockchain but also serves as a core index field in subsequent key delivery and arbitration processes. For example, the transaction identifier can be a globally unique byte32 value, calculated using the keccak256(dataId, buyer, block.timestamp) method, ensuring it is not duplicated across the entire network.

[0070] In some embodiments of this application, the fund custody contract establishes a relationship in its storage structure simultaneously with the generation of the transaction identifier. Specifically, the following elements are mapped and stored using the transaction identifier as the primary key: the corresponding data asset identifier, the account address of the data purchaser, and the amount of locked stablecoins. Once this relationship is written, any node can verify it by calling the contract's query interface or listening to the event log. For example, the event PurchaseEvent(dataId, buyer, txId) is broadcast on the blockchain, where txId is the transaction identifier generated in this step.

[0071] This step, by associating the transaction identifier with multiple pieces of information during generation, achieves the following technical effects: First, the binding of transaction identifiers and data asset identifiers ensures that each fund custody points to a unique data asset, thereby avoiding the problem of multiple transactions using the same funds or the whereabouts of funds being unknown, and enhancing the transparency of custody funds. Second, by introducing the buyer's address into the transaction identifier, the fund custody is directly linked to the specific buyer's account, which can effectively avoid the risk of third parties impersonating the payment, and at the same time provide a clear responsible party for the transaction record; Third, the binding of the amount of funds corresponding to the pricing with the transaction identifier ensures that the escrow amount is completely consistent with the pricing of the data assets, avoiding problems such as inaccurate fund freezing or mismatch between the payment amount and the data value, thus guaranteeing the fairness of the transaction and the rigor of fund management. Fourth, the aforementioned relationships are written into the blockchain ledger, making the fund custody process open, transparent, and tamper-proof. This not only enhances the credibility of the system but also provides solid on-chain evidence for subsequent arbitration and dispute resolution. It ensures that fund custody is not an isolated act but is closely coupled with the entire data transaction process, thus forming a complete custody mechanism that binds funds and data and is traceable.

[0072] Furthermore, to enhance transaction transparency, the fund custody contract will permanently record this operation in the blockchain ledger. All transaction participants can query the correspondence between transaction identifiers and fund status through block explorers or off-chain services. This not only clarifies the current fund status for both parties but also provides traceable on-chain evidence for any potential arbitration in the future.

[0073] Through the above design, step S3 ensures the security and transparency of the fund custody process, avoiding the problem of funds and data transactions becoming disconnected. The fund custody contract is linked to the asset identifier, the buyer's account, and the frozen funds upon generating the transaction identifier, forming a complete on-chain evidence chain and laying a reliable foundation for subsequent key delivery and dispute resolution.

[0074] In step S4, the data holder needs to securely submit the symmetric encryption key used to decrypt the data asset, encrypted with the data buyer's public key, to the key exchange contract and complete the binding with the transaction identifier. This step is crucial for ensuring the security and tamper-proof nature of key delivery, involving four technical aspects: on-chain public key registration and verification, key encryption, on-chain notarization, and event triggering.

[0075] First, the data purchaser needs to complete public key registration. Specifically, to ensure the authenticity and ownership of the submitted public key, the purchaser signs the "Public Key Registration Request Message" using their account private key and submits the signature to the key exchange contract. The contract uses a built-in signature recovery function (such as ecrecover in EVM) to recover the account address from the signature and compares it with the data purchaser's account address in the transaction context. If the verification matches, it confirms that the public key is indeed controlled by the purchaser, and only then is the data holder allowed to subsequently submit encrypted symmetric encryption keys. If the verification fails, the transaction immediately rolls back, and the data holder is not allowed to use the public key.

[0076] It should be noted that the "signature" referred to in this application embodiment does not mean that the message itself is encrypted.

[0077] This step, through the buyer's signature, restores the account address and verifies consistency via the key exchange contract, achieving the following technical effects: First, the signature generated by the account's private key is unique and cannot be forged, ensuring that the public key registration request is indeed initiated by the purchaser, effectively eliminating the possibility of submitting a request with a forged identity. Second, the key exchange contract verifies the signature and restores the account address, thus forming a strong binding relationship between the public key submitted off-chain and the account on-chain, thereby ensuring the authenticity and validity of the public key and preventing third parties from replacing or tampering with it. Third, this scheme ensures that the data holder can only submit the encryption key after the verification is successful, thus ensuring the security and uniqueness of the key delivery process. It blocks the channel for attackers to intercept or replace the key, ensuring that attackers cannot forge or replace the purchaser's public key, thereby avoiding "man-in-the-middle attacks" from the source. Fourth, the entire verification process is executed on-chain, avoiding the inefficiency and lack of transparency caused by off-chain manual verification, and improving the automation and credibility of the verification process. Fifth, by creating a record in the blockchain ledger that verifies the consistency between the signature and the account address, the system can provide tamper-proof evidence in subsequent dispute arbitration, further enhancing the traceability and non-repudiation of the key delivery process.

[0078] Secondly, the data holder obtains the verified public key locally and uses it to perform asymmetric encryption on the generated symmetric encryption key. The encrypted output is key ciphertext, which can only be decrypted by the buyer holding the corresponding private key to obtain the original symmetric key. In this way, the data holder does not directly expose the symmetric key, ensuring confidentiality during on-chain and off-chain transmission. For example, an elliptic curve cryptography algorithm can be used, which has high computational efficiency while ensuring security.

[0079] Then, the data holder can call the key exchange contract's submission interface, such as `submitEncryptedKey(txId, encryptedKey)`, to submit the encrypted symmetric key onto the blockchain. During submission, a transaction identifier (txId) needs to be specified to establish a binding relationship between the key and the corresponding fund custody and data registration information.

[0080] In some embodiments of this application, the contract records the encrypted key payload and the on-chain address of the submitter (i.e., the data holder) in the storage structure using the transaction identifier as the primary key, and then stores this information in the blockchain ledger. Because the blockchain is immutable, this notarization process ensures the authenticity and traceability of key delivery.

[0081] Finally, after successful key storage, the key exchange contract triggers an event, such as KeyDeliveredEvent(txId, owner), to notify the data buyer that a new encryption key has been submitted. The event can include the transaction identifier and the submitter's address. The buyer's client can automatically obtain the delivery status by subscribing to the event listener. This allows the buyer to know the key delivery progress immediately, avoiding delays or omissions caused by relying on off-chain communication.

[0082] This step, by binding the symmetric encryption key with the transaction identifier and the data holder's address and triggering the delivery event, achieves the following technical effects: First, the binding of transaction identifiers and encryption keys ensures a unique correspondence in key delivery. Each encryption key has a clear transaction context, avoiding key mixing or misuse. Second, by introducing the data holder's address during the binding process, the key delivery is directly linked to the holder's identity, ensuring that the key source is clear and enhancing the transparency and traceability of key management; Third, triggering a key delivery event notifies the buyer, enabling them to obtain the delivery status in real time through the blockchain event system, reducing disputes caused by information delays and improving delivery efficiency and user experience; Fourth, the key exchange contract combines evidence-based binding with event notifications, making the key delivery process not only verifiable but also automated, further enhancing the system's intelligence in the delivery phase. Fifth, the scheme forms a complete chain of evidence on the blockchain, making the key delivery result tamper-proof and providing solid on-chain proof for transaction security and arbitration.

[0083] Through the above process, step S4 achieves the following key technical effects: First, it ensures the authenticity of the public key, preventing forgery and replacement; second, it ensures that the symmetric key is only visible to the legitimate purchaser, enhancing the confidentiality and security of the key delivery process; third, it binds the delivery result to the transaction identifier and stores it on the blockchain, providing verifiable on-chain evidence; and fourth, it promptly notifies the purchaser through an event mechanism, improving delivery efficiency and user experience. The entire mechanism combines the advantages of asymmetric encryption and blockchain notarization, making the key exchange process transparent, verifiable, and tamper-proof, providing security for the subsequent key decryption and data acquisition by the data purchaser.

[0084] In step S5, the data buyer needs to obtain the encrypted symmetric encryption key submitted on-chain based on the transaction identifier, and then decrypt it using their own account private key to recover the symmetric key. Subsequently, the buyer uses the symmetric key to download and decrypt the encrypted data asset from IPFS, thereby obtaining the usable data asset. This step covers two main technical aspects: on-chain key retrieval and decryption, and off-chain data acquisition and decryption.

[0085] First, the data buyer obtains the corresponding encrypted symmetric key by calling the query interface of the key exchange contract (e.g., getKey(txId)) on the client side, passing in the transaction identifier txId. Since the key exchange contract has already bound the encrypted symmetric key with the transaction identifier and the data holder's address and stored it on the blockchain in step S4, accurate retrieval based on the identifier can be achieved here. At the same time, the immutability of the blockchain ensures that the encrypted key obtained by the buyer is indeed submitted by the data holder, avoiding the risk of it being replaced midway.

[0086] Subsequently, the data purchaser uses the private key corresponding to their on-chain registered public key to decrypt the obtained ciphertext, obtaining the original symmetric encryption key. This key, previously generated by the data holder, ensures uniqueness and randomness; only the legitimate purchaser's private key can recover it, ensuring the confidentiality and exclusivity of the key transmission. For example, the decryption process can employ an asymmetric decryption algorithm matching the S4 encryption step, such as an elliptic curve cryptography scheme based on the secp256k1 curve.

[0087] After recovering the symmetric encryption key, the buyer needs to retrieve the encrypted data assets from IPFS. The buyer's client initiates a retrieval request to the IPFS network using the CID registered in step S2. Because IPFS is based on a content addressing mechanism, only data fragments with completely identical hashes can satisfy the request. Therefore, the downloaded data is guaranteed to be consistent with the data holder's original upload and will not change due to node differences.

[0088] After the data download is complete, the buyer uses the recovered symmetric encryption key to decrypt the file. The decryption process must employ the same algorithm and mode as the S2 encryption stage. Furthermore, if the data asset was compressed during the S2 stage, the buyer must further decompress it after decryption to recover the original data file. The entire process can be automated through the client application to ensure that the user can successfully obtain the final usable plaintext data asset.

[0089] Through step S5, the data buyer completes the entire process of key acquisition, decryption, and data recovery. This process has the following technical advantages: First, the transaction identifier, as the core index, ensures the uniqueness of the delivered object; second, the asymmetric decryption mechanism ensures that only the legitimate buyer can recover the symmetric key, thereby preventing third-party theft; third, IPFS content addressing ensures the integrity and tamper-proof nature of the data download process; fourth, decryption and decompression restore the original data, ensuring the correctness and usability of the delivered result. Through this mechanism, the system realizes a closed loop from key delivery to data asset acquisition, ensuring the security and trustworthiness of the transaction.

[0090] In step S6, the system enters the fund and data delivery confirmation stage during the dispute complaint period.

[0091] In this application implementation, in order to prevent situations such as inconsistent data quality, undecryptable data, or incomplete delivery from undermining the fairness of transactions, an on-chain arbitration mechanism is set up, and the dispute resolution and fund destination are automated through the synergistic effect of the arbitration contract and the fund custody contract.

[0092] First, the fund custody contract includes the start time and end block height of the dispute complaint period when the transaction identifier is generated. For example, if the complaint period is set to 7 days, the contract stores the value of "transaction initiation block height + 7 days of block count" as the expiration condition. During the complaint period, the system keeps the funds locked and will not release them prematurely.

[0093] When the data purchaser disagrees with the delivery results, they can initiate a dispute request on the client side. This request must include a transaction identifier, a summary of the reason for the dispute, and the purchaser's account signature to prevent unrelated parties from submitting malicious requests. After receiving the dispute request, the arbitration contract first generates a unique arbitration transaction identifier, which can be obtained by calculating the hash value of "transaction identifier + timestamp + submitter's address". The arbitration transaction identifier is used to distinguish different transactions and their dispute events to avoid duplication or overwriting.

[0094] The arbitration contract then verifies the dispute request, which mainly includes: checking whether the party submitting the dispute is the registered buyer, checking whether the dispute was submitted within the complaint period, and checking whether the transaction identifier is valid. If the verification fails, the contract directly rejects the request and returns an error event; if the verification passes, the arbitration contract enters the voting stage.

[0095] During the voting phase, the arbitration contract invokes a pre-defined set of arbitration nodes or references the arbitration node addresses registered in the governance contract. Arbitration nodes submit their voting opinions, such as "delivery completed" or "delivery incomplete," through an on-chain voting interface. After collecting the votes, the arbitration contract tallies the results according to pre-defined rules (such as majority rule or weighted voting mechanism) and writes the final results into a storage structure, binding them to the transaction identifier. The event log broadcasts the voting results, allowing off-chain services and transaction parties to be promptly informed of the arbitration status. For example, voting criteria may include: whether the data file is decryptable, whether the data is consistent with the registered metadata, and whether the data falls within the agreed-upon range corresponding to the transaction pricing.

[0096] After arbitration, the escrow contract executes the fund release logic according to the arbitration result. If the result is "delivery completed," the escrow contract releases the frozen stablecoins to the data holder's account address; if the result is "delivery incomplete," the escrow contract returns the stablecoins to the data purchaser's account address. All release operations can be executed through the stablecoin contract's transfer interface, and the on-chain ledger will synchronously generate fund transfer records.

[0097] This step, by generating an arbitration transaction identifier, verifying the request, organizing arbitration node voting, and storing the results upon receiving a dispute request, achieves the following technical effects: First, the generation of the arbitration matter identifier provides a unique number for each dispute, enabling the arbitration process to be effectively tracked and distinguished, and avoiding confusion between different disputes; Second, verifying disputed requests can effectively filter out malicious or invalid requests, reduce the waste of arbitration node resources, and improve the fairness and efficiency of the arbitration mechanism. Third, organizing arbitration nodes to vote on the decision ensures the openness and transparency of the arbitration process, avoids the injustice caused by unilateral decision-making, and enhances the credibility of the arbitration results. Fourth, the voting results are bound to the transaction identifier and recorded in the blockchain ledger, making the adjudication process traceable. At the same time, the adjudication results directly drive the fund custody contract to execute release or return operations, thereby automating the fund disposal. Fifth, the on-chain arbitration mechanism significantly improves the efficiency of dispute resolution, reduces the uncertainty of human intervention, and provides an open, fair and efficient dispute resolution channel for the entire transaction system.

[0098] If the data purchaser does not initiate any dispute request during the dispute complaint period, the fund custody contract will automatically release the stablecoins to the data holder upon the expiration of the complaint period. This process is triggered by blockchain timestamps and transaction status determination, requiring no additional manual intervention and ensuring the automatic execution of the transaction loop.

[0099] Through the aforementioned mechanism, step S6 technically achieves the following core points: First, fund locking is tied to the dispute period, preventing premature release; second, the generation and storage of arbitration transaction identifiers ensure the uniqueness and traceability of dispute resolution; third, the on-chain arbitration node voting mechanism enables multi-party participation in adjudication, reducing centralized unfairness; fourth, the arbitration result directly drives the release operation of the fund custody contract, ensuring consistency between the fund destination and the adjudication result; fifth, if there is no dispute, the system automatically releases funds, ensuring the smooth completion of the transaction. This mechanism balances fairness, transparency, and automation, completely resolving the problem of fund and data disconnection caused by delivery disputes in traditional data transactions.

[0100] In summary, this method constructs a complete closed loop encompassing data encryption, storage, fund custody, key delivery, and dispute resolution through the coordinated operation of data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts. During the transaction process, the data holder encrypts the data assets and uploads them to the InterPlanetary File System (IPS), with metadata registered on-chain to ensure authenticity and traceability. The fund custody contract securely freezes stablecoins and generates transaction identifiers; the key exchange contract guarantees the secure transfer of symmetric keys; and the arbitration contract provides on-chain adjudication and drives fund flow during the dispute period. This method ensures a strong bond between data and funds while achieving fairness, impartiality, and transparency in transactions. It solves the problems of unreliable fund custody and key delivery mechanisms in traditional data transactions, which are difficult to guarantee security. It achieves decentralized management of data assets throughout the entire process, ensuring the security and traceability of data delivery and fund settlement during transactions, and meeting the needs of strong bond between funds and data, verifiable key delivery, and automated dispute resolution in data transactions.

[0101] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S1 to S6 are described sequentially, but this does not mean that steps S1 to S6 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S1 to S6 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S1 to S6 can be appropriately adjusted according to actual needs.

[0102] Example 2: like Figure 2 As shown in the figure, this embodiment provides a decentralized trusted data transaction system based on blockchain, including: Data encryption module 1 is used to generate a symmetric encryption key for the data holder's data assets and encrypt the data assets; Decentralized storage module 2 is used to store encrypted data assets and return content addressing identifiers; Data registration module 3, deployed on the blockchain, is used to register the metadata of data assets on the blockchain. The metadata includes the pricing of the data assets in stablecoins. The fund custody module 4, deployed on the blockchain, is used to receive and lock the amount of stablecoins corresponding to the pricing paid by the data buyer, and generate a transaction identifier; Key exchange module 5, deployed on the blockchain, is used to receive and store the encrypted symmetric encryption key submitted by the data holder, and bind it with the transaction identifier to trigger the key delivery event; Arbitration module 6, deployed on the blockchain, is used to execute the arbitration process upon receiving a dispute request and associate the award with the transaction identifier; The tracking and management module 7 is used to record the correspondence between transaction identifiers and fund status, key status, and arbitration status in the blockchain ledger.

[0103] By adopting the above technical solution, and by setting up a data encryption module 1, a decentralized storage module 2, a data registration module 3, a fund custody module 4, a key exchange module 5, an arbitration module 6, and a tracking management module 7 in the system, the secure storage, trusted registration, fund custody, key delivery, and dispute resolution of data assets are realized throughout the entire process. This forms a decentralized data trading system with a clear structure and complete functions, meeting the needs of secure transfer of data assets in a trusted environment.

[0104] Specifically, the data encryption module 1 ensures that the data holder can perform symmetric encryption on the data asset before it is uploaded to the blockchain, avoiding the risk of directly exposing the original data; the decentralized storage module 2 combines content addressing identifiers to store the encrypted data, ensuring the integrity and tamper-proof nature of the data at the storage level; the data registration module 3, deployed on the blockchain, can register and store the metadata information of the data asset, providing a reliable index for the transaction process; the fund custody module 4 provides a blockchain-based stablecoin custody and transaction identifier generation mechanism, making the fund status transparent and traceable; the key exchange module 5 can store the encrypted key and bind the transaction identifier when the data is delivered, realizing a secure key transmission path; the arbitration module 6 ensures automated adjudication and fund release control in transaction dispute scenarios, improving fairness and reliability; and the tracking management module 7 realizes unified mapping and on-chain recording of transaction identifiers, fund status, key status, and arbitration status, making the entire system transparent and traceable.

[0105] In some embodiments of this application, the fund custody module 4 is used to associate the transaction identifier, the identifier of the data asset, the address of the data buyer, and the amount of stablecoins corresponding to the pricing when generating the transaction identifier, and record it in the blockchain ledger.

[0106] In the fund custody module 4, by associating the transaction identifier with the data asset identifier, the buyer's address, and the amount of stablecoins when generating the transaction identifier and recording it on the blockchain, the following technical effects can be achieved: First, the binding of fund custody and data asset identification forms a one-to-one correspondence, which prevents the custody funds from being misappropriated or mixed across transactions, fundamentally improving the exclusivity of the custody funds. Second, by writing the buyer's address as an important related element of fund custody into the blockchain ledger, the source of funds payment is clearly traceable, which helps in subsequent responsibility determination and compliance review. Third, the direct correspondence between the amount of escrowed funds and the pricing ensures that the frozen amount is fully matched with the transaction demand, avoiding underpayment or overpayment, and enhancing the accuracy and rigor of fund management. Fourth, the blockchain ledger records complete related information, making the fund custody process transparent and open, and all relevant parties can verify it, thereby improving the trust and non-repudiation of the transaction; Fifth, the scheme forms a complete chain of evidence for fund custody by fully binding funds with data identifiers, accounts, and amounts, providing strong protection for the system's fund security.

[0107] In some embodiments of this application, the key exchange module 5 is used to recover the account address based on the signature after receiving the signature submitted by the data purchaser, and to determine whether the account address is consistent with the address of the data purchaser. If they are consistent, the data holder is allowed to submit the encrypted symmetric encryption key.

[0108] The key exchange module 5 achieves the following technical effects by recovering the account address based on the received signature and performing consistency verification: First, by recovering the account address through signature, it is ensured that the verification process relies on the underlying cryptographic algorithm, which is unforgeable and highly reliable, providing a solid security foundation for transactions; Second, consistency verification ensures that the identity of the user submitting the request corresponds to the real account on the chain, avoiding the possibility of forging signatures or impersonating others to carry out illegal operations; Third, the system only allows the data holder to submit the encryption key after the verification is passed, which ensures from a systemic perspective that the key will not be delivered to the wrong recipient, and enhances the accuracy and reliability of the key delivery process. Fourth, this mechanism is executed on the blockchain, without relying on external systems, which improves the automation of the verification process and avoids potential security vulnerabilities caused by off-chain verification. Fifth, the scheme creates a record in the blockchain ledger that corresponds to the signature verification and the account address. All verification actions are traceable and auditable, providing strong evidence for subsequent arbitration and compliance, and significantly improving the system's level of security and verifiability.

[0109] In summary, this system consists of a data encryption module 1, a decentralized storage module 2, a data registration module 3, a fund custody module 4, a key exchange module 5, an arbitration module 6, and a tracking and management module 7, forming a complete system covering data on-chaining, fund freezing, key delivery, and dispute resolution. The overall solution achieves strong binding between data and funds through modular division of labor, ensuring that the entire transaction process is open, transparent, trustworthy, and auditable, effectively solving the custody risks and delivery disputes in traditional data transactions.

[0110] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The methods disclosed in the embodiments are described simply because they correspond to the systems disclosed in the embodiments; relevant details can be found in the method section.

[0111] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0112] In the embodiments provided by this invention, it should be understood that the disclosed systems, methods, and approaches can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0113] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit.

[0115] Similarly, in the various embodiments of the present invention, each processing unit can be integrated into a functional module, or each processing unit can exist physically, or two or more processing units can be integrated into a functional module.

[0116] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

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

[0118] The above-disclosed embodiments are merely preferred embodiments of the present invention, but the present invention is not limited thereto. Any non-creative variations that can be conceived by those skilled in the art, as well as any improvements and modifications made without departing from the principles of the present invention, should fall within the protection scope of the present invention.

Claims

1. A decentralized and trusted data transaction method based on blockchain, characterized in that, Includes the following steps: Running smart contracts on the blockchain, including data registration contracts, fund custody contracts, key exchange contracts, and arbitration contracts; The data holder generates a symmetric encryption key for the data asset and encrypts the data asset. The encrypted data asset is then uploaded to the InterPlanetary File System, and the data registration contract is invoked to register the metadata of the data asset on the blockchain. The metadata includes the pricing of the data asset in stablecoins. The data buyer initiates a transaction, invokes the fund custody contract, locks the amount of stablecoins corresponding to the pricing, and the fund custody contract generates a transaction identifier. The data holder invokes the key exchange contract to obtain and use the public key registered on the chain by the data buyer to encrypt the symmetric encryption key, and submits the encrypted symmetric encryption key to the key exchange contract and binds it to the transaction identifier; The data buyer obtains the encrypted symmetric encryption key based on the transaction identifier, decrypts it using the private key corresponding to the public key, obtains the symmetric encryption key, and downloads and decrypts the encrypted data asset from the InterPlanetary File System to obtain the data asset; If the data purchaser initiates a dispute request during the designated dispute complaint period, the arbitration contract will be invoked to execute on-chain arbitration, and the destination of the stablecoin will be determined based on the arbitration result. If no dispute request is initiated during the dispute complaint period, or if the arbitration contract rules that delivery has been completed, the fund custody contract will release the stablecoin to the data holder. If the arbitration contract rules that delivery has not been completed, the fund custody contract will release the stablecoin to the data purchaser.

2. The decentralized trusted data transaction method based on blockchain as described in claim 1, characterized in that, The data holder generates a symmetric encryption key for the data and encrypts the data, including: The data holder calculates the hash value of the data asset and generates a unique symmetric encryption key; The data assets are compressed, and the compressed data assets are encrypted using the symmetric encryption key.

3. The decentralized trusted data transaction method based on blockchain as described in claim 1, characterized in that, The metadata also includes the identifier and hash value of the data asset, the content addressing identifier of the InterPlanetary File System, and the address of the data holder.

4. The decentralized trusted data transaction method based on blockchain as described in claim 3, characterized in that, When generating the transaction identifier, the fund custody contract associates the transaction identifier, the identifier of the data asset, the address of the data purchaser, and the amount of stablecoins corresponding to the pricing.

5. The decentralized trusted data transaction method based on blockchain as described in claim 4, characterized in that, The data purchaser signs the public key registration request message using its private key and submits the signature to the key exchange contract. The key exchange contract recovers the account address based on the signature and determines whether the account address matches the data purchaser's address. If they match, the data holder is allowed to submit the encrypted symmetric encryption key.

6. The decentralized trusted data transaction method based on blockchain as described in claim 5, characterized in that, When the key exchange contract receives the encrypted symmetric encryption key, it binds the transaction identifier, the encrypted symmetric encryption key, and the address of the data holder, and triggers a key delivery event to notify the data buyer to obtain the encrypted symmetric encryption key.

7. The decentralized trusted data transaction method based on blockchain as described in claim 1, characterized in that, Upon receiving the dispute request, the arbitration contract generates an arbitration transaction identifier, verifies the dispute request, organizes on-chain arbitration nodes to vote on the delivery status corresponding to the transaction identifier, records the voting results and associates them with the transaction identifier, and the fund custody contract determines the destination of the stablecoin based on the voting results.

8. A decentralized, trusted data trading system based on blockchain, characterized in that, include: The data encryption module is used to generate a symmetric encryption key for the data assets of the data holder and to encrypt the data assets. A decentralized storage module is used to store the encrypted data assets and return a content addressing identifier; A data registration module, deployed on a blockchain, is used to register the metadata of the data asset on the blockchain, the metadata including the pricing of the data asset in stablecoins; The fund custody module, deployed on the blockchain, is used to receive and lock the amount of stablecoins corresponding to the pricing paid by the data buyer, and generate a transaction identifier; The key exchange module, deployed on the blockchain, is used to receive and store the encrypted symmetric encryption key submitted by the data holder, and bind it to the transaction identifier to trigger a key delivery event; An arbitration module, deployed on the blockchain, is used to execute the arbitration process upon receiving a dispute request and associate the arbitration result with the transaction identifier; The tracking and management module is used to record the correspondence between the transaction identifier and the fund status, key status, and arbitration status in the blockchain ledger.

9. A decentralized and trusted data transaction system based on blockchain as described in claim 8, characterized in that, The fund custody module is used to associate the transaction identifier, the identifier of the data asset, the address of the data buyer, and the amount of stablecoins corresponding to the pricing when generating the transaction identifier, and record it in the blockchain ledger.

10. A decentralized trusted data transaction system based on blockchain as described in claim 8, characterized in that, The key exchange module is used to recover the account address based on the signature after receiving the signature submitted by the data purchaser, and to determine whether the account address is consistent with the address of the data purchaser. If they are consistent, the data holder is allowed to submit the encrypted symmetric encryption key.

Images