A blockchain-based decentralized data atomicity transaction method and system

Abstract

This invention discloses a decentralized data atomicity transaction method and system based on blockchain, belonging to the field of blockchain and data element circulation technology. The system architecture includes access connectors, business nodes, regional functional nodes, and a blockchain network. The method includes: the data provider blocks the original database table, encrypts it with layered keys, constructs a Merkle tree of the original and encrypted data, and casts NFTs using data fingerprints on regional nodes; the two parties in the transaction establish an off-chain state channel to lock funds, the provider streams the encrypted data, and the buyer optimistically verifies and signs the channel status; a two-stage verification process of sampling challenge-key release is used to ensure atomicity; when data is inconsistent, an off-chain interactive binary search locates the error, and only the minimum evidence is submitted for arbitration. This invention combines state channels and Merkle trees to solve the problems of high cost and difficulty in fair exchange of large amounts of data on the blockchain, ensuring data is usable but invisible, realizing atomic transfer of funds and ownership, and ensuring security and traceability.

Description

Technical Field

[0001] This invention relates to the field of blockchain and data market technology, and in particular to a decentralized data atomic transaction method and system based on blockchain. Background Technology

[0002] With the booming development of the digital economy, data has become the fifth major factor of production after land, labor, capital, and technology. To promote the efficient circulation and value release of data, the "National Data Infrastructure Standard" proposes building a secure, reliable, and inclusive data circulation environment. Against this backdrop, building a data trading market based on blockchain has become an industry consensus, utilizing the immutability and traceability of blockchain to solve the problems of data ownership confirmation and transaction trust.

[0003] However, existing blockchain data transaction solutions still face the following challenges in practical applications: 1) In decentralized data transactions, due to the lack of a trustworthy third-party intermediary, buyers and sellers often get caught in a trust game: if the buyer pays first, the seller may refuse to send data or send fake data; if the seller sends data first, the buyer may refuse to pay after receiving the data. Although existing smart contracts can lock up funds, they are difficult to directly perceive the transmission status and content correctness of off-chain data, making it difficult to guarantee the atomicity of the exchange between payment and delivery.

[0004] 2) Blockchain networks suffer from expensive storage and limited computing power. Existing solutions typically only upload data hashes to the blockchain, while transferring the raw data via cloud storage or FTP. This fragmented model of on-chain storage and off-chain transmission poses security risks: the off-chain data transmission process lacks effective oversight mechanisms, and in the event of data quality disputes (such as data tampering or partial loss), smart contracts cannot verify and adjudicate massive amounts of data at low cost. If full on-chain verification is required, the gas fees (transaction fees) will far exceed the value of the data itself.

[0005] 3) In data transaction scenarios, data providers want to keep the data plaintext (usable but not visible) until the buyer makes full payment, while buyers want to verify the authenticity and integrity of the data before payment. Existing zero-knowledge proof or homomorphic encryption schemes can solve privacy issues, but their computational complexity is extremely high, making it difficult to support high-frequency, large-scale data transactions.

[0006] 4) Traditional blockchain data transaction systems often adopt a direct connection model, where all transactions interact directly with the chain, leading to blockchain network congestion. There is a lack of a layered, decoupled architecture (such as connectors responsible for privacy, business nodes responsible for matching, and functional nodes responsible for oversight) to balance privacy and security with transaction efficiency.

[0007] The existing patent with publication number CN112636930A provides an asset trading method and system based on atomic swaps. It adopts a cross-chain protocol that supports heterogeneous blockchains, combines sidechain relay technology and distributed hash tables, and conducts entrusted transactions through cross-chain contracts. It uses zero-knowledge proof technology of sidechains to hide the information of the transacting parties. The system is designed with a five-layer structure, including a user access terminal, an interface layer, an asset chain smart contract layer, a sidechain, and an asset blockchain. It realizes cross-chain asset mapping and anonymous transactions, and solves the problems of existing blockchain cross-chain technology not being able to fully support heterogeneous blockchains, the need to lock funds for a long time when the transaction channel is opened, which increases the risk of hacking, the loss or delayed broadcast of transaction data which may lead to theft of funds, and insufficient transaction privacy and serious leakage of personal information.

[0008] The existing patent with publication number CN109636610A provides a decentralized data trading system and method. It completes data on-chain registration and automatic settlement by deploying smart contracts such as data registration / mapping / list query / transaction / payment on the data trading blockchain, and realizes data storage and retrieval by combining a distributed database, thus achieving distributed data trading without the participation of third parties. This solution solves the problems of privacy and high transaction costs in the traditional third-party platform model, but focuses on achieving decentralized and traceable and reliable execution of data transactions through on-chain identity and signature verification, on-chain contract-based registration / mapping / query / transaction / payment closure, and off-chain distributed storage.

[0009] In summary, a new data transaction architecture and methodology are needed that, while being compatible with national data infrastructure standards, enables low-cost transmission and atomicity of large volumes of data through state channels, ensures the reliability of data verification through cryptographic commitment mechanisms, and designs an efficient dispute arbitration mechanism to ensure the atomicity and fairness of transactions. Summary of the Invention

[0010] This invention aims to address the technical problems existing in current data transactions, such as the difficulty in guaranteeing transaction atomicity, the high cost of on-chain verification for large amounts of data, and the insecurity of privacy data transmission. It proposes a decentralized data atomicity transaction method and system based on blockchain. Based on the national data infrastructure standard architecture, it utilizes state channels and Merkle tree proof mechanisms. This invention achieves secure transmission and fair exchange of large-scale database tables by constructing a four-layer decoupled architecture of connectors, business nodes, and regional functional nodes, combined with off-chain state channels and Merkle tree cryptographic proofs.

[0011] To achieve the above objectives, in a first aspect, the present invention provides a decentralized data atomicity transaction method based on blockchain, comprising the following steps: S1, the data provider extracts the metadata and fingerprint information of the data source through the access connector and sends it to the regional functional node through the business node; the regional functional node mints data asset NFTs containing the data Merkle root on the blockchain; S2, the data buyer calls the transaction smart contract on the blockchain to deposit the budget, and an off-chain state channel is established between the data provider and the data buyer; S3, the data provider generates a random master key and derives multiple subkeys through a key derivation function. The data provider divides the complete data into multiple data blocks and encrypts the divided data blocks separately using the subkeys to obtain ciphertext blocks. The data provider constructs a ciphertext Merkle tree and a subkey Merkle tree, and sends the data root hash, master key commitment, and subkey root hash to the data purchaser for signature confirmation through a status channel. S4, the data provider sends encrypted data blocks sequentially in the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status as proof of acceptance. S5: The data buyer initiates a random sampling challenge; the data provider sends the subkey and Merkel path corresponding to the sampled data block in the off-chain state channel; the data buyer decrypts and verifies the data consistency, and after successful verification, both parties sign to enter the next stage; S6: The data provider sends an encrypted master key; the data buyer decrypts the master key to obtain the master key and verifies the full amount of data. After successful verification, both parties sign to close the off-chain state channel, and the smart contract completes the reward settlement based on the final state.

[0012] Furthermore, each enterprise deploys one of the aforementioned access connectors to store privacy data and perform data encryption; multiple access connectors connect to the same business node, which is used to perform data transaction matching and ownership registration; all business nodes connect to a single regional functional node, which is used to uniformly connect to the blockchain network, synchronize data registration information across the entire network, and manage distributed digital identities.

[0013] Furthermore, the data provider divides the complete dataset D into n data blocks m1, m2, ..., m n Generate a random master key K, and calculate the subkey K based on the key derivation function f. i =f(K,i); using subkey K i Encrypt corresponding data block m i Obtain ciphertext block C i Construct encrypted Merkle trees R for the data respectively. C Master key hash commitment H K and subkey Merkle tree R Ki The data provider will RC R Ki And the hash commitment H of the master key K It is sent to the data buyer, who then signs it as proof of acceptance.

[0014] Furthermore, the data provider sequentially sends encrypted data blocks within the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status, including: For each ciphertext block received, the data buyer pays according to the promised ciphertext Merkle tree R. C Verify the integrity of the ciphertext block; After successful verification, the off-chain state channel updates the current state, recording the accumulated reward obtained by the data provider as S. (k / n), where S is the total budget, n is the total number of data blocks, and k is the number of data blocks that have been transmitted and verified; Both parties to the data transaction use off-chain ECDSA private keys to digitally sign the updated state data. In the event of a unilateral breach of contract or forced closure of the channel, either party submits the latest state with the other party's ECDSA signature to the blockchain smart contract. The smart contract verifies the signature validity through the ecrecover function and allocates the budget based on the state of the last valid signature.

[0015] Furthermore, if the data purchaser discovers discrepancies between the sample data and the description, or if the Merkel path verification fails, a dispute resolution process is triggered, including: If the sample content is inconsistent, it will be submitted to a trusted off-chain third party or a smart contract for adjudication. If the Merkel path verification is incorrect, the disputed evidence is submitted to the blockchain smart contract, which then makes a judgment based on the original data Merkel root stored on the chain.

[0016] Furthermore, in S6, if a key error dispute is triggered, the specific handling includes: When the master key K obtained by the data purchaser cannot decrypt the data, or when the hash value of the master key K is inconsistent with the master key commitment submitted by the data provider in S3; The data purchaser submits the received master key K to the blockchain smart contract; The smart contract calculates the hash value Hash(K) of the submission key and compares it with the initial commitment H stored on-chain. K 'Compare;' If the two are inconsistent, the smart contract determines that the data provider is in breach of contract and will refund the pledged budget S in full to the data buyer.

[0017] Furthermore, in S6, if a data error dispute is triggered, the specific handling process includes: Once the master key verification is successful, the data purchaser decrypts the data using the master key and derived subkeys. The decrypted data blocks are then compared with the original data Merkle tree R. D In the event of a mismatch, both parties initiate interactive dispute verification within the off-chain state channel; Both sides used a binary search algorithm to interactively compare the hash values ​​of the left and right child nodes, starting from the root node of the Merkle tree, until they located the first leaf node with inconsistent hash values. The data buyer submits the ciphertext of the data block corresponding to a leaf node with an inconsistent hash value, the corresponding subkey, and the Merkel proof path as evidence of fraud to the blockchain smart contract. Smart contract execution on-chain computation: Decrypting the ciphertext using the submitted subkey, calculating the hash value of the decrypted data, and verifying whether it belongs to the original Merkle tree R. D ; If the on-chain verification result indicates that the data block is invalid, the smart contract determines that the data provider has provided false data and executes the penalty mechanism.

[0018] Furthermore, the data provider sequentially sends encrypted data blocks within the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status, including: The data provider uses the data purchaser's public key to encrypt and transmit the master key K; The data purchaser uses the private key to decrypt and obtain the master key K, and then attempts to derive all subkeys from K to decrypt the data. If decryption is successful, the data purchaser signs the final status to close the channel; If decryption fails, the data purchaser initiates on-chain arbitration, and the smart contract calculates whether the hash value of the master key K matches the promise H in step S3. K 'Consistent'.

[0019] Secondly, the present invention provides a decentralized data atomic transaction system based on blockchain, including an access connector layer, a business node layer, a regional functional node layer, and a blockchain and smart contract layer. At the access connector layer, data providers and data buyers deploy access connectors internally. The access connectors are used for data source access, data segmentation, encryption, key derivation, data transmission, and communication with business nodes. In the business node layer, business nodes are deployed on the operator's local server or cloud server environment to aggregate connector requests and perform data product listing, browsing, and transaction matching. The regional functional node layer deploys regional-level data infrastructure core nodes, which are used to connect to the blockchain network and perform identity authentication and NFT minting of data assets. The status channel module is used to establish an off-chain communication link between the data provider and the data buyer, and to perform encrypted transmission, signature interaction and sampling verification. The blockchain and smart contract layer contains trading market contracts used to store data asset certificates, lock trading budgets, verify disputed evidence, and execute final settlement.

[0020] Thirdly, the present invention provides a computer program that executes the above-described decentralized data atomic transaction method based on blockchain when the computer is run.

[0021] Compared with the prior art, the present invention has at least the following beneficial effects: This invention combines smart contract staking with off-chain key distribution to construct a strict atomic swap protocol. Funds are only released to the provider after the buyer successfully verifies the validity of the master key off-chain and signs the final state. Conversely, if the provider refuses to deliver the key or the key is invalid, the smart contract automatically refunds the funds. This mechanism of key-based delivery and delivery-based settlement enables cash-on-delivery transactions in a decentralized environment. It addresses the trust game often encountered in transactions without centralized intermediaries: if the buyer pays first, the seller may refuse to deliver; if the seller delivers first, the buyer may refuse to pay. Existing Hash Time Locked Contracts (HTLCs) are difficult to directly apply to the delivery and verification of large volumes of data.

[0022] Traditional blockchain data transactions only hash the data on-chain, proving that the data has not been tampered with, but not whether the data content matches the product description at the time of sale. This invention introduces a sampling challenge phase after encrypted transmission and before key release. Before paying the full amount, the buyer has the right to randomly select a portion of the data blocks for decryption and verification. This probabilistic verification mechanism forces the data provider to guarantee the authenticity of all data; otherwise, they face a very high risk of being discovered. This effectively bridges the trust gap between on-chain hashes and off-chain semantics, preventing fraudulent activities where the item does not match the description.

[0023] Enterprise-level database tables are typically enormous (GB / TB level). Existing solutions, which transmit data as a single block, require retransmission in case of network interruption, resulting in extremely low efficiency; furthermore, it is difficult to perform fine-grained value measurement of the data. This invention employs a data block-based encrypted streaming transmission strategy. Data is divided into tiny granular segments, and combined with the incremental signature mechanism of the state channel, the fund allocation status within the channel is updated by both parties after each successful transmission of a data block. This not only naturally supports resuming interrupted transmission, improving transmission robustness, but also enables streaming payments, making the transaction process more flexible and efficient.

[0024] Public blockchains (such as Ethereum) have limited TPS and high gas fees. If every data transmission confirmation record were submitted on-chain, the transaction cost would far exceed the value of the data itself, and the confirmation delay would be unacceptable for business needs. This invention moves 99% of the interaction process (encrypted transmission, integrity verification, and balance updates) off-chain, requiring only the exchange of ECDSA digital signatures between the parties. On-chain smart contracts only intervene when a channel is opened, closed, or in case of a dispute. This design increases transaction throughput to a level limited only by physical bandwidth and reduces the marginal cost of a single data block interaction to near zero, making high-frequency, fine-grained data transactions an economically viable solution.

[0025] When errors occur in off-chain data, the simplest approach is to submit the entire dataset to on-chain arbitration, but this is unacceptable in terms of storage and computational costs. This invention utilizes the structural characteristics of Merkle trees to design an off-chain interactive binary search algorithm. When a dispute arises, both the buyer and seller quickly locate the first leaf node with the hash collision off-chain. They then only need to submit this single data block and its Merkle proof path (the data size is only in the KB range) to the smart contract. This hybrid mode of off-chain investigation and on-chain judgment reduces the computational complexity of on-chain arbitration from O(log(n)) to O(1) (relative to the total data volume), significantly saving gas fees.

[0026] A fully decentralized approach struggles to meet data compliance requirements, while a fully centralized approach poses privacy risks. This invention proposes a four-layer architecture: access connector – business node – regional functional node. This architecture physically ensures that raw data never leaves the enterprise intranet before encryption (connector layer), logically isolates transaction matching from data content (business node layer), and implements trusted management and traceability of network-wide identities at the top level (functional node layer). It aligns with the National Data Infrastructure Standards, achieving a perfect balance between data usability and invisibility, and controllability and measurability. Attached Figure Description

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

[0028] Figure 1 This is an overall architecture diagram of the decentralized data atomic transaction system provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the overall process of the data atomicity transaction method provided in the embodiments of the present invention; Figure 3This is a schematic diagram illustrating the principles of data preprocessing, key derivation, and Merkle tree construction in this embodiment of the invention. Figure 4 This is a timing interaction diagram of encrypted transmission and two-stage verification based on state channels in an embodiment of the present invention; Figure 5 This is an interactive binary search verification flowchart for data error disputes in an embodiment of the present invention. Detailed Implementation

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

[0030] Example 1: System Architecture and Deployment like Figure 1 As shown, the present invention provides a decentralized data atomicity transaction system based on blockchain, whose overall architecture conforms to the "National Data Infrastructure Standard" and is physically and logically divided into four layers: Access Connector Layer: Access connectors are deployed on the internal private servers or private cloud environments of the data provider (DO) and data buyer (DB). Users can directly pull the Docker image of the access connector for installation. The access connector directly interfaces with the enterprise's production database (such as MySQL or Oracle) or file system through an internal interface. The access connector in this layer is the sole exit point for data leaving the domain, responsible for locally performing data segmentation, encryption, and hash calculations to ensure that the original plaintext data never leaves the enterprise's intranet environment.

[0031] Business Node Layer: In the business node layer, business nodes are deployed on the operator's local server or cloud server environment, using the same deployment method as the access connectors. Multiple access connectors with adjacent physical locations or similar business attributes may register with the same business node. The business node provides a data product listing and display interface, order management functions, and assistance in establishing status channels. The business node does not store any plaintext or encrypted data; it only processes metadata and transaction instructions.

[0032] Regional Functional Node Layer: Serving as core nodes of regional (e.g., provincial or municipal) data infrastructure, these nodes connect to public or consortium blockchain networks. They act as the sole regulatory and registration center across the network, maintaining the distributed digital identity (DID) registry to ensure the legitimacy of every access connector and business node. Simultaneously, regional functional nodes serve as the sole bridge between off-chain systems and on-chain smart contracts, responsible for minting the data fingerprints and metadata submitted by business nodes into NFTs (Non-Fungible Tokens).

[0033] Blockchain and Smart Contract Layer: The blockchain and smart contract layer is built on Chang'an Chain and deploys ERC721 data asset contracts to store ownership certificates of data and corresponding Merkle root information. It also deploys a trading market contract, which implements the logic of locking, updating, settling funds, and verifying fraud proofs for state channels.

[0034] Example 2: Data Preprocessing and Registration Method Before a data transaction occurs, the data provider (DO) preprocesses the target database tables through an access connector. For example... Figure 3 As shown, it includes the following steps: Data cleaning and chunking: The access connector exports data tables from the source database, serializes the data tables, and divides them into ordered data block sequences m1, m2, ..., m according to a fixed size (e.g., 1MB per block). n .

[0035] Constructing the original Merkle tree for the data: For each data block m i Calculate the hash value h(m) i The pairs are recursively combined and calculated until the root hash R of the Merkle tree of the original data is generated. D The data provider will R D The metadata (data description, number of rows, size) is submitted to the regional functional node through the business node, and NFTs are minted on the chain to complete the data registration.

[0036] Hierarchical Key Generation: The access connector internally generates a 256-bit random number as the master key K; using a key derivation function (for example, HKDF-SHA256), the subkey K is calculated with the master key K and data block index i as input. i =HKDF(K,i), Encryption and Commitment Construction: Using Subkey K i For data block m i Perform symmetric encryption to generate ciphertext block C. i Based on ciphertext block C i Construct a ciphertext Merkle tree and compute the root hash R C Based on subkey Ki Construct the key Merkle tree and compute the root hash R Ki Calculate the master key commitment H K As an example, the hash function could be Keccak-256. The data provider will (R C , R Ki H K The package is prepared as a transaction commitment set and awaits delivery to the buyer.

[0037] Example 3: Atomic Transaction Process Based on State Channels like Figure 2 and Figure 4 As shown, when a data buyer decides to purchase data, the following process is executed by both parties: Step S1: Channel Establishment and Fund Pledge The data buyer calls the interface of the smart contract of the trading market to deposit the trading budget S. The contract locks the trading budget and records the initial state of the off-chain channel: {nonce:0,balance_DO:0,balance_DB:S}.

[0038] Step S2: Commitment Exchange and Encrypted Transmission DO sends a set of transaction commitments (R) to DB off-chain via a state channel. C , R Ki H K Upon receiving the data, DB will sign to confirm its acceptance of the verification benchmark for that batch of data.

[0039] DO begins streaming ciphertext blocks C1, C2, ...

[0040] Each time DB receives a ciphertext block C i Immediately calculate its hash value and utilize R C The Merkel path verifies the integrity of the ciphertext block.

[0041] After each successfully verified ciphertext block, both parties sign a new state form off-chain. For example, after verifying the k-th block, the new state is {nonce:k, balance_DO:S}. (k / n), balance_DB:S (1-k / n)}. Both parties generate their own private and public keys to sign the new state using ECDSA (Elliptic Curve Digital Signature Algorithm). This mechanism ensures that even if transmission is interrupted, the DO can still retrieve the funds corresponding to the sent data from the smart contract based on the last signed state.

[0042] Step S3: Sampling Challenge After the ciphertext transmission is complete, the DB generates a random challenge index set Idx={x,y,z} locally. As an example, 1% of the ciphertext blocks can be randomly selected.

[0043] DO responds to the challenge by sending the subkey {K} corresponding to the index set. x ,K y ,K z} and subkeys in key tree R Ki Merkel's proof path in the text.

[0044] DB Validation: 1) Validate K x Does it belong to R? Ki 2) Using K x Decrypting C x Get m x '. 3) Check m x Does the content format match the product description?

[0045] If the verification is successful, DB signs the pre-verification status, the channel enters the locking phase, and preparations are made for the transfer of the master key.

[0046] Step S4: Phase Two, Key Release and Final Settlement DO sends the master key K to DB using DB's public key in asymmetric encryption.

[0047] DB decrypts the master key to obtain K, and verifies whether Keccak-256(K) matches the on-chain commitment H. K 'equal.

[0048] The database (DB) runs the derived function HKDF-SHA256 locally to generate all subkeys, decrypt all ciphertexts, and calculates whether the root hash of the decrypted data is equal to the R registered on the chain. D .

[0049] If everything matches, DB signs the final settlement status {balance_DO:S,balance_DB:0,status:CLOSED}. DO submits this signature to the smart contract and withdraws the full amount of funds corresponding to the transaction budget S.

[0050] Example 4: Dispute Resolution Mechanism In step S4 of Example 3, if the DB detects a problem with the data, it will trigger the dispute resolution process, such as... Figure 5 As shown: Scenario 1: Master key error If the hash value of the master key K' sent by DO is not equal to the commitment value H KIf K' cannot derive the subkey verified in step S3, DB calls the challengeKey interface of the smart contract and submits the received K'. The smart contract calculates Keccak-256(K'). If it is not equal to the stored H... K The court determined that DO had committed wrongdoing, returned the funds S to DB, and forfeited DO's margin.

[0051] Scenario 2: Data Content Fraud If the master key K is correct, but a certain data block m is decrypted... i With the original data fingerprint R registered on the chain D Mismatch, meaning that DO swapped the data during encryption, even though the ciphertext tree R... C Verification passed, but the decrypted data was not the original. Both parties used an interactive binary search to identify the erroneous data block off-chain, and then submitted it for on-chain arbitration. 1) Both parties establish a temporary dispute session in the off-chain state channel.

[0052] 2) When both parties compare the root hash of their respective original Merkle trees, they will inevitably be different.

[0053] 3) Both sides exchange the hashes of the left and right child nodes of the root node. If the hashes of the left child nodes match, the error is in the right subtree; if they do not match, the error is in the left subtree.

[0054] 4) Repeat the above process log 2(n) This continues until the specific leaf node index target is located. idx .

[0055] 5) DB calls the smart contract's proveFraud interface to submit the ciphertext C of the disputed data block. target The corresponding subkey K target And the data block in the original data tree R D The node hash value H in c .

[0056] 6) The execution logic of smart contracts includes: a Ciphertext Decryption: m real =Decrypt(C target ,K target ).

[0057] b hash verification: h real =Keccak-256(m real ).

[0058] 7) If the calculated hash value h real With the submitted node hash value H c The difference indicates that the decrypted data is indeed not in the original promised R.D In the case, DO was determined to be fraudulent.

[0059] Since both parties confirmed the erroneous data block and its hash value through interactive binary search in the off-chain state channel, and both parties signed to confirm it, the smart contract only needs to verify whether the hash value of the erroneous node is correct. This avoids the process of comparing the hash values ​​of Merkle tree nodes level by level, which has a time complexity of O(log(n)). Therefore, the time complexity of the smart contract to verify the correctness of the data is optimized from O(log(n)) to O(1).

[0060] Through the above embodiments, the present invention realizes a system that can both protect data privacy and complete large-scale atomic data transactions with extremely low on-chain costs (minimizing computation only in the event of disputes).

[0061] In summary, this invention provides a decentralized data atomicity transaction method based on blockchain. The data provider uses an access connector to segment the original database table, generate hierarchical keys, and encrypt them, constructing both the original data Merkle tree and the encrypted Merkle tree. The data fingerprint is then minted as an NFT on a regional functional node. The two parties establish an off-chain state channel and lock funds. The data provider streams the encrypted data, and the data buyer performs optimistic verification based on a commitment and signs the channel state. The transaction employs a two-stage verification mechanism of sampling challenge and key release to ensure atomicity. When data inconsistency occurs, both parties initiate an interactive binary search off-chain to locate the erroneous node and submit minimal evidence to the smart contract for arbitration. This invention, by combining state channel technology and Merkle tree proof mechanism, solves the problems of high transaction costs and difficulty in fair exchange of large-scale data on the blockchain. While ensuring data usability without visibility, it achieves atomic transfer of transaction funds and data ownership, ensuring the security and traceability of data circulation.

[0062] In addition, the present invention also provides a computer program in which the method of the present invention can also be implemented. When the computer program runs in a computer, it executes the steps of the blockchain-based decentralized data atomic transaction method described in the present invention.

[0063] The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solution based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A decentralized data atomicity transaction method based on blockchain, characterized in that, Includes the following steps: S1, the data provider extracts the metadata and fingerprint information of the data source through the access connector and sends it to the regional functional node through the business node; the regional functional node mints data asset NFTs containing the data Merkle root on the blockchain; S2, the data buyer calls the transaction smart contract on the blockchain to deposit the budget, and an off-chain state channel is established between the data provider and the data buyer; S3, the data provider generates a random master key and derives multiple subkeys through a key derivation function. The data provider divides the complete data into multiple data blocks and uses the subkeys to encrypt the divided data blocks to obtain ciphertext blocks. The data provider constructs a ciphertext Merkle tree and a subkey Merkle tree, and sends the data root hash, master key commitment, and subkey root hash to the data purchaser for signature confirmation via a status channel. S4, the data provider sends encrypted data blocks sequentially in the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status as proof of acceptance. S5: The data buyer initiates a random sampling challenge; the data provider sends the subkey and Merkel path corresponding to the sampled data block in the off-chain state channel; the data buyer decrypts and verifies the data consistency, and after successful verification, both parties sign to enter the next stage; S6, the data provider sends the encrypted master key; The data buyer decrypts the data to obtain the master key and verifies all the data. After successful verification, both parties sign to close the off-chain state channel, and the smart contract completes the reward settlement based on the final state.

2. The blockchain-based decentralized data atomic transaction method according to claim 1, characterized in that, Each enterprise deploys one of the aforementioned access connectors for storing privacy data and performing data encryption; multiple access connectors connect to the same business node, which is used to perform data transaction matching and ownership registration. All business nodes are connected to the single regional functional node, which is used to uniformly connect to the blockchain network, synchronize data registration information across the entire network, and manage distributed digital identities.

3. The blockchain-based decentralized data atomic transaction method according to claim 1, characterized in that, The data provider divides the complete dataset D into n data blocks m1, m2, ..., m n Generate a random master key K, and calculate the subkey K based on the key derivation function f. i =f(K,i); using subkey K i Encrypt corresponding data block m i Obtain ciphertext block C i Construct encrypted Merkle trees R for the data respectively. C Master key hash commitment H K and subkey Merkle tree R Ki The data provider will R C R Ki And the hash commitment H of the master key K It is sent to the data buyer, who then signs it as proof of acceptance.

4. The blockchain-based decentralized data atomicity transaction method according to claim 1, characterized in that, The data provider sequentially sends encrypted data blocks within the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status, including: For each ciphertext block received, the data buyer pays according to the promised ciphertext Merkle tree R. C Verify the integrity of the ciphertext block; After successful verification, the off-chain state channel updates the current state, recording the accumulated reward obtained by the data provider as S. (k / n), where S is the total budget, n is the total number of data blocks, and k is the number of data blocks that have been transmitted and verified; Both parties to the data transaction use off-chain ECDSA private keys to digitally sign the updated state data. In the event of a unilateral breach of contract or forced closure of the channel, either party submits the latest state with the other party's ECDSA signature to the blockchain smart contract. The smart contract verifies the signature validity through the ecrecover function and allocates the budget based on the state of the last valid signature.

5. The blockchain-based decentralized data atomicity transaction method according to claim 1, characterized in that, If the data purchaser verifies that the sample data does not match the description or the Merkel path verification fails, a dispute resolution process is triggered, including: If the sample content is inconsistent, it will be submitted to a trusted off-chain third party or a smart contract for adjudication. If the Merkel path verification is incorrect, the disputed evidence is submitted to the blockchain smart contract, which then makes a judgment based on the original data Merkel root stored on the chain.

6. The blockchain-based decentralized data atomicity transaction method according to claim 5, characterized in that, In S6, if a key error dispute is triggered, the specific handling includes: If the master key K obtained by the data purchaser cannot decrypt the data, or if the hash value of the master key K does not match the master key commitment H submitted by the data provider in S3... K When inconsistent; The data purchaser submits the received master key K to the blockchain smart contract; The smart contract calculates the hash value Hash(K) of the submission key and compares it with the initial commitment H stored on-chain. K 'Compare;' If the two are inconsistent, the smart contract determines that the data provider is in breach of contract and will refund the pledged budget S in full to the data buyer.

7. The blockchain-based decentralized data atomicity transaction method according to claim 5, characterized in that, In S6, if a data error dispute is triggered, the specific handling process includes: Once the master key verification is successful, the data purchaser decrypts the data using the master key and derived subkeys. The decrypted data blocks are then compared with the original data Merkle tree R. D In the event of a mismatch, both parties initiate interactive dispute verification within the off-chain state channel; Both sides used a binary search algorithm to interactively compare the hash values ​​of the left and right child nodes, starting from the root node of the Merkle tree, until they located the first leaf node with inconsistent hash values. The data buyer submits the ciphertext of the data block corresponding to a leaf node with an inconsistent hash value, the corresponding subkey, and the Merkel proof path as evidence of fraud to the blockchain smart contract. Smart contract execution on-chain computation: Decrypting the ciphertext using the submitted subkey, calculating the hash value of the decrypted data, and verifying whether it belongs to the original Merkle tree R. D ; If the on-chain verification result indicates that the data block is invalid, the smart contract determines that the data provider has provided false data and executes the penalty mechanism.

8. The blockchain-based decentralized data atomicity transaction method according to claim 1, characterized in that, The data provider sequentially sends encrypted data blocks within the off-chain state channel. After the data buyer verifies that the encrypted blocks are correct, both parties sign the updated off-chain state channel reward distribution status, including: The data provider uses the data purchaser's public key to encrypt and transmit the master key K; The data purchaser uses the private key to decrypt and obtain the master key K, and then attempts to derive all subkeys from K to decrypt the data. If decryption is successful, the data purchaser signs the final status to close the channel; If decryption fails, the data purchaser initiates on-chain arbitration, and the smart contract calculates whether the hash value of the master key K matches the promise H in step S3. K Consistent.

9. A computer program, characterized in that, The computer program executes the blockchain-based decentralized data atomic transaction method as described in any one of claims 1 to 8 when it runs in a computer.

10. A decentralized data atomicity transaction system based on blockchain, characterized in that, This includes the access connector layer, business node layer, regional functional node layer, and blockchain and smart contract layer; At the access connector layer, data providers and data buyers deploy access connectors internally. The access connectors are used for data source access, data segmentation, encryption, key derivation, data transmission, and communication with business nodes. In the business node layer, business nodes are deployed on the operator's local server or cloud server environment to aggregate connector requests and perform data product listing, browsing, and transaction matching. The regional functional node layer deploys regional-level data infrastructure core nodes, which are used to connect to the blockchain network and perform identity authentication and NFT minting of data assets. The status channel module is used to establish an off-chain communication link between the data provider and the data buyer, and to perform encrypted transmission, signature interaction and sampling verification. The blockchain and smart contract layer contains trading market contracts used to store data asset certificates, lock trading budgets, verify disputed evidence, and execute final settlement.

Images