Blockchain-based transaction data consensus method and apparatus, electronic device, and medium

Abstract

The application can be used in the technical field of blockchain technology application in finance, and provides a transaction data consensus method and device based on blockchain, an electronic device and a medium. The corresponding method comprises the following steps: in response to the first blockchain network being in a weak network or network interruption state, a second blockchain network is established through a contract initiator node, a plurality of contract verifier nodes and a plurality of cloud service nodes; when the first blockchain network is normal, the contract initiator node and the plurality of contract verifier nodes are located in the first blockchain network; in response to a transaction request of the contract initiator node; and consensus is obtained for a transaction corresponding to the transaction request according to the second blockchain network, a data block and a relationship. The application can improve the credibility of data by executing the contract through multi-party cooperation and obtaining a blockchain consensus result, and can fully exert the computing and storage capabilities of various terminal devices in the distributed network.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology and can be used in the technical field of blockchain application in the financial industry. Specifically, it relates to a blockchain-based transaction data consensus method, device, electronic device and medium. Background Technology

[0002] Blockchain is a distributed database technology whose most significant characteristic is providing decentralized and immutable data storage capabilities. A blockchain consists of a series of data blocks arranged chronologically, each containing a certain number of transaction records. These blocks are linked together using cryptographic methods, and once data is written to the blockchain, it is very difficult to change or delete.

[0003] Current mainstream blockchain products emphasize the equality of consensus nodes within the chain. This means that each node participating in the consensus executes a unified contract script. Once it is determined that all participating nodes execute the same script and achieve the same execution result, a technical consensus is reached. With the widespread application of 5G networks, the types and numbers of smart devices are rapidly increasing. However, due to limitations in their computing and storage capabilities, current smart devices such as mobile phones, tablets, and IoT devices cannot participate in the consensus process of existing blockchain networks and can only exist as client devices.

[0004] Current blockchain networks emphasize equality among nodes, requiring all nodes to execute the same script. However, this approach necessitates that each participating node possess equal computing power. A transaction consensus is only reached when each participating node executes the contract script identically, yielding the same result. This method ignores the differences in computing power among nodes, demanding that each participate in the same computation. For nodes with varying computing and storage capabilities, their computational load varies significantly. This results in nodes with weaker computing power being unable to participate in the blockchain consensus process. Furthermore, devices with low computing power, such as widely used IoT devices, mobile phones, and tablets, cannot participate as consensus nodes. Summary of the Invention

[0005] This invention can be used in the technical field of blockchain technology applications in finance, and can also be used in any field other than finance.

[0006] One objective of this invention is to propose a strategy for executing different parts of a contract on different nodes in a blockchain network. Specifically, each node participating in the consensus process is assigned a different role, and each node role executes a different part of the contract. Through multi-party collaborative contract execution, a blockchain consensus result is obtained. Furthermore, a new data block is proposed to allow multiple parties to store business data, improving data trustworthiness while fully leveraging the computing and storage capabilities of various terminal devices in the distributed network.

[0007] Another object of the present invention is to provide a blockchain-based transaction data consensus device and a blockchain dynamic networking device. A further object of the present invention is to provide an electronic device including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the aforementioned blockchain-based transaction data consensus method and blockchain dynamic networking method. A further object of the present invention is to provide a readable medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned blockchain-based transaction data consensus method and blockchain dynamic networking method.

[0008] To address the technical problems in the background section of this application, the present invention provides the following technical solutions:

[0009] In a first aspect, the present invention provides a blockchain-based transaction data consensus method comprising:

[0010] In response to the first blockchain network being in a weak or offline state, a second blockchain network is constructed by the contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0011] In response to the transaction request from the contract initiating node, a data block is constructed in the second blockchain network;

[0012] Establish the relationship between the data blocks and user transaction data items;

[0013] Consensus is reached on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0014] In some embodiments of the present invention, the construction of the data block includes:

[0015] The data block is constructed based on the network data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block from the second blockchain network.

[0016] In some embodiments of the present invention, the data block is stored on the plurality of cloud service nodes, the corresponding contract initiator node, and the plurality of contract verifier nodes.

[0017] In some embodiments of the present invention, a blockchain-based transaction data consensus method further includes:

[0018] The relationships are stored in a link table, which is used to represent the latest data block of transaction data.

[0019] In some embodiments of the present invention, consensus is reached on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship, including:

[0020] Send the transaction, the historical data of the data block, and the link table to multiple contract verification nodes in the second blockchain network;

[0021] After the transaction is verified by the multiple contract verification nodes, the multiple contract verification nodes sign the data block.

[0022] The signed data block is sent to multiple cloud service nodes, which then perform block creation operations on the transaction.

[0023] In some embodiments of the present invention, before reaching consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship, the method further includes:

[0024] Verify whether the block layer height of the contract initiator node, the block layer height of the multiple contract verifier nodes, and the block layer height of at least one cloud service node are consistent.

[0025] When the block height of the contract initiator node, the block height of the multiple contract verifier nodes, and the block height of at least one cloud service node are inconsistent, the data blocks stored by the contract initiator node, the data blocks stored by the multiple contract verifier nodes, and the data blocks stored by the multiple cloud service nodes are synchronized according to the link table.

[0026] In some embodiments of the present invention, verifying whether the block layer height of the contract initiator node, the block layer height of the plurality of contract verifyer nodes, and the block layer height of at least one cloud service node are consistent includes:

[0027] Determine whether the hash value of the link table stored by the contract initiator node, the hash value of the link table stored by the multiple contract verifier nodes, and the hash value of the link table stored by at least one cloud service node are consistent.

[0028] Secondly, the present invention provides a blockchain-based transaction data consensus device, comprising:

[0029] The blockchain network component module is used to construct a second blockchain network in response to a weak or offline state of the first blockchain network, through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0030] A data block construction module is used to construct data blocks in the second blockchain network in response to transaction requests from the contract initiating node.

[0031] The relationship establishment module is used to establish the relationship between the data block and the user transaction data item;

[0032] The transaction consensus module is used to reach a consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0033] In some embodiments of the present invention, the data block construction module includes:

[0034] The data block construction unit is used to construct the data block based on the network data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block of the second blockchain network.

[0035] In some embodiments of the present invention, the data block is stored on the plurality of cloud service nodes, the corresponding contract initiator node, and the plurality of contract verifier nodes.

[0036] In some embodiments of the present invention, a blockchain-based transaction data consensus device further includes:

[0037] A relation storage module is used to store the relation through a link table, which represents the latest data block of transaction data.

[0038] In some embodiments of the present invention, the transaction consensus module includes:

[0039] A data sending unit is used to send the transaction, the historical data of the data block, and the link table to multiple contract verification nodes in the second blockchain network;

[0040] The data block signing unit is used to sign the data block after the transaction has been verified by the multiple contract verification nodes.

[0041] The transaction block-writing unit is used to send the signed data block to multiple cloud service nodes, which then perform block-writing operations on the transaction.

[0042] In some embodiments of the present invention, a blockchain-based transaction data consensus device further includes:

[0043] The block height verification module is used to verify whether the block height of the contract initiator node, the block height of the multiple contract verifier nodes, and the block height of at least one cloud service node are consistent.

[0044] The data block synchronization module is used to synchronize the data blocks stored by the contract initiator node, the multiple contract verifier nodes, and the multiple cloud service nodes according to the link table when the block layer height of the contract initiator node, the block layer height of the multiple contract verifier nodes, and the block layer height of at least one cloud service node are inconsistent.

[0045] In some embodiments of the present invention, the block height verification module includes:

[0046] The block height verification unit is used to determine whether the hash value of the link table stored by the contract initiator node, the hash value of the link table stored by the multiple contract verifier nodes, and the hash value of the link table stored by at least one cloud service node are consistent.

[0047] Thirdly, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of a blockchain-based transaction data consensus method.

[0048] Fourthly, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a blockchain-based transaction data consensus method.

[0049] Fifthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a blockchain-based transaction data consensus method.

[0050] As described above, embodiments of the present invention provide a blockchain-based transaction data consensus method and apparatus, comprising: in response to a first blockchain network being in a weak or offline state, constructing a second blockchain network through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network; in response to a transaction request from the contract initiator node, constructing a data block in the second blockchain network; establishing a relationship between the data block and user transaction data items; and achieving consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0051] This invention utilizes a collaborative smart contract execution method involving various device nodes. It fully and balancedly leverages the computing and storage capabilities of various device nodes in a distributed network, enabling more terminal devices with varying computing power to act as consensus nodes and participate in the consensus calculation process of the blockchain network. This changes the traditional model where terminal nodes with low computing power can only serve as edge devices. It fully utilizes the computing and storage capabilities of edge devices with low computing power to build a blockchain network. Through the collaborative execution of contracts by edge devices, the consensus process for block data is completed. Attached Figure Description

[0052] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram of a blockchain-based transaction data consensus method in an embodiment of the present invention;

[0054] Figure 2 This is a schematic diagram illustrating the relationship between nodes in a blockchain-based transaction data consensus method according to an embodiment of the present invention.

[0055] Figure 3 This is a flowchart illustrating step 200 of a blockchain-based transaction data consensus method in an embodiment of the present invention.

[0056] Figure 4 This is another flowchart illustrating a blockchain-based transaction data consensus method according to an embodiment of the present invention;

[0057] Figure 5 This is a flowchart illustrating step 400 of a blockchain-based transaction data consensus method in an embodiment of the present invention.

[0058] Figure 6 This is a schematic diagram of a third process of a blockchain-based transaction data consensus method in an embodiment of the present invention;

[0059] Figure 7 This is a flowchart illustrating step 600 of a blockchain-based transaction data consensus method in an embodiment of the present invention.

[0060] Figure 8 This is a schematic diagram of the node structure of a blockchain network in a specific embodiment of the present invention;

[0061] Figure 9 This is a schematic diagram of the bilateral consensus mechanism in a specific embodiment of the present invention;

[0062] Figure 10 This is a schematic diagram of the block message data structure in a specific embodiment of the present invention;

[0063] Figure 11 This is a schematic diagram of the data file structure generated by the cloud-edge in a specific embodiment of the present invention;

[0064] Figure 12 This is a schematic diagram illustrating the link constraint relationship between multiple data blocks in a specific embodiment of the present invention;

[0065] Figure 13 This is a block diagram of a blockchain-based transaction data consensus device in an embodiment of the present invention;

[0066] Figure 14 This is a block diagram of the data block construction module 20 in an embodiment of the present invention;

[0067] Figure 15 This is another block diagram of a blockchain-based transaction data consensus device according to an embodiment of the present invention;

[0068] Figure 16 This is a block diagram of the transaction consensus module 40 in an embodiment of the present invention;

[0069] Figure 17 This is a third block diagram of a blockchain-based transaction data consensus device according to an embodiment of the present invention;

[0070] Figure 18 This is a block diagram of the block height verification module 60 in an embodiment of the present invention;

[0071] Figure 19 This is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0073] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0074] It should be noted that the terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses. Without conflict, the embodiments and features in the embodiments of this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0075] The acquisition, storage, use, and processing of data in this application all comply with relevant laws and regulations. Specifically:

[0076] First, the information collected is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0077] Second, provide users with corresponding operation entry points for them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0078] First, embodiments of the present invention provide a specific implementation of a blockchain-based transaction data consensus method, see [link to relevant documentation]. Figure 1 The method specifically includes the following:

[0079] Step 100: In response to the first blockchain network being in a weak or offline state, a second blockchain network is established by the contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0080] Step 200: In response to the transaction request from the contract initiator node, construct a data block in the second blockchain network;

[0081] Step 300: Establish the relationship between the data block and the user transaction data item;

[0082] Step 400: Reach consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0083] As described above, embodiments of the present invention provide a blockchain-based transaction data consensus method, comprising: in response to a first blockchain network being in a weak or offline state, constructing a second blockchain network through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network; in response to a transaction request from the contract initiator node, constructing a data block in the second blockchain network; establishing a relationship between the data block and user transaction data items; and achieving consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0084] This invention utilizes a collaborative smart contract execution method involving various device nodes. It fully and balancedly leverages the computing and storage capabilities of various device nodes in a distributed network, enabling more terminal devices with varying computing power to act as consensus nodes and participate in the consensus calculation process of the blockchain network. This changes the traditional model where terminal nodes with low computing power can only serve as edge devices. It fully utilizes the computing and storage capabilities of edge devices with low computing power to build a blockchain network. Through the collaborative execution of contracts by edge devices, the consensus process for block data is completed.

[0085] See Figure 2 Regarding step 100, the contract initiator node and multiple contract verifier nodes can be edge nodes, which are relative to cloud nodes and can be composed of different types of terminals, such as: Android devices, iOS devices, PC devices, web pages, Linux virtual machines, smart terminals in cars, etc.

[0086] Specifically, the blockchain network environment in which the contract is executed in this application includes different types of devices, such as low-computing-power network devices like mobile phones, tablets, PCs, and web mini-programs, as well as various server devices with high computing and storage capabilities. These devices act as cloud services within the blockchain network, and the cloud services can use a consortium blockchain as their data storage mechanism. In this invention, all devices, whether low-computing-power mobile devices, IoT devices, or cloud servers, are considered end-device nodes. The contract flows between different end-device nodes. For a single smart contract, each device plays a different role in the blockchain network, and devices with different roles execute different parts of the contract. Each device executes a specific part of the contract according to its role.

[0087] When the first blockchain network is weak or offline, a direct connection is established between the contract initiator node and the contract verifier node. This connection can be established via Bluetooth, QR code communication, or other methods. Each participant in the transaction signs the data block they generate. These signatures are stored in the block and cached. Once the first blockchain network is restored, the data block is submitted to the edge verification nodes and cloud nodes for verification. After verification, the data block is stored on the cloud nodes and by each participating node, thus achieving consensus and acceptance of the transaction data from numerous edge verification nodes and cloud nodes in the blockchain network, even under weak network conditions.

[0088] Regarding step 200, in a wide-area blockchain, transaction data inevitably needs to flow between various nodes. Therefore, it is necessary to ensure that the entire process—from constructing transaction data to transmitting, verifying, and storing data—is reliably transmitted and tamper-proof, and to prevent double-spending. Transaction data must be traceable, and the system must be able to identify the identities of transaction participants to prevent forgery. Furthermore, the system must guarantee that transaction data has a definite ownership.

[0089] Therefore, this application proposes the concept of data blocks to ensure that data is protected against counterfeiting, tampering, double-spending, and is traceable during the generation, transmission, and storage processes.

[0090] In step 300, during the construction, networking, verification, and smart contract execution of transaction data, each party supplements the corresponding data items in the block along with the block. During the generation, circulation, transmission, verification, and storage of the block, the authentication signatures of each party are collected through their operations, irrefutably defining the ownership of the data and authenticating the legality, compliance, and reasonableness of the data block. The blocks are organized in a tree-like chain through mutual association.

[0091] Regarding step 400, in blockchain, the consensus mechanism refers to the process by which different participants (nodes) in the network reach an agreement on a certain data value (such as the validity of a transaction). It ensures the decentralized nature and security of the blockchain. Preferably, Byzantine fault tolerance can be used for transaction consensus, which allows the system to still reach consensus even if a certain number of nodes may fail or act maliciously. This is more suitable for scenarios in private or consortium blockchains where there are high requirements for transaction throughput and latency.

[0092] In some embodiments of the present invention, see Figure 3 Step 200 includes:

[0093] Step 201: Construct the data block based on the network data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block of the second blockchain network.

[0094] Specifically, a data block is a collection of transaction data organized into a single block. In its concrete form, a data block is a JSON-structured text file. This block contains information about the network setup, block creation, transaction data, smart contract ID, data manipulation instructions following contract execution, and private key signatures from all parties involved.

[0095] In some embodiments of the present invention, the data block is stored on the plurality of cloud service nodes, the corresponding contract initiator node, and the plurality of contract verifier nodes.

[0096] Data blocks are stored in real time in the cloud and also on one or more client devices (but a user can only log in to one client device at a time). When a client device needs to conduct a transaction, it must first synchronize its own data blocks with the data blocks in the cloud. Only when the client and cloud data are synchronized, that is, the block height and link table hash values ​​are consistent in the cloud and client devices, can a new transaction process be initiated on the client device to generate a new block. Otherwise, client-cloud synchronization must be completed first.

[0097] Additionally, it's important to note that each client device a user logs into only retains transaction data related to that user's activity. The cloud, however, stores each user's data individually. Therefore, user data is physically isolated from each other, unlike a public blockchain architecture where each participating node needs to store the entire network ledger. This protects user privacy.

[0098] In some embodiments of the present invention, see Figure 4 A blockchain-based transaction data consensus method also includes:

[0099] Step 500: Store the relationship through a link table, which is used to represent the latest data block of transaction data.

[0100] By establishing a link table between data items and blocks, the latest block that each data item points to is confirmed (i.e., the data item was updated by a specific block). Each new block is based on historical transactions, thus creating the concept of historical blocks. Through new blocks and historical blocks, links can be established between blocks. This ensures that every transaction is based on reliable historical data.

[0101] Furthermore, in a blockchain, each block typically contains a series of transactions that record the transfer of assets from one address to another. Each block also contains a reference to the previous block, which is usually the hash value of the previous block. This method of linking blocks by hash values ​​forms a continuously growing chain, or "blockchain," in which each block confirms and perpetuates the validity of the previous block. Specifically, each block has two main parts:

[0102] Block header: The block header contains metadata such as the hash of the previous block (which is the linking part), timestamp, difficulty target, nonce, and Merkle root hash (the root of the data structure containing all transactions).

[0103] Transaction list: This is a list of the actual transactions recorded in the block.

[0104] This hash-linked structure ensures the immutability of the blockchain. If an attacker attempts to change information in a block, this alters the block's hash, rendering the linking of all subsequent blocks invalid, as each block contains the hash of its predecessor. This would be quickly detected by other nodes in the network, as each node maintains a complete copy of the blockchain or a critical portion thereof.

[0105] In some embodiments of the present invention, see Figure 5 Step 400 includes:

[0106] Step 401: Send the transaction, the historical data of the data block, and the link table to multiple contract verification nodes in the second blockchain network;

[0107] Step 402: After the transaction is verified by the multiple contract verification nodes, the multiple contract verification nodes sign the data block;

[0108] Step 403: Send the signed data block to multiple cloud service nodes, and the multiple cloud service nodes perform block writing operations on the transaction.

[0109] Steps 401 to 403 essentially involve the transmission of data blocks within the second blockchain network. This process specifically includes: the transaction initiating node initiating a network request to generate a new data block; filling the new data block with transaction data; and sending the new data block, along with historical data blocks and the link table of data items, to other verification nodes in the dynamic chain. After obtaining multi-party verification from these nodes, the multi-party verification signature is recorded in the data block. The block is then sent to the cloud by the transaction initiating node. The cloud verifies the data, performs a block creation operation, stores the data block in the cloud, and subsequently distributes the data block to the various participants indicated in the data block. Each participant, upon receiving the data block, processes its own data block, further filling in the data block content, and initiates the network verification process again, thus completing the network verification and cloud storage process for the data block generated by its own node. Ultimately, after receiving the cloud-signed data block, each transaction participant updates the node link table and the local user ledger data according to the user ledger update instructions generated in the block.

[0110] In some embodiments of the present invention, see Figure 6 Prior to step 400, a blockchain-based transaction data consensus method further includes:

[0111] Step 600: Verify whether the block layer height of the contract initiator node, the block layer height of the multiple contract verifier nodes, and the block layer height of at least one cloud service node are consistent.

[0112] Step 700: When the block height of the contract initiator node, the block height of the multiple contract verifier nodes, and the block height of at least one cloud service node are inconsistent, synchronize the data blocks stored by the contract initiator node, the multiple contract verifier nodes, and the multiple cloud service nodes according to the link table.

[0113] Understandably, steps 600 and 700 provide a mechanism to prevent tampering and double-spending in blockchain transactions. That is, transaction block processing can only be carried out on the premise that the data between the end and the cloud is synchronized. If the data between the end and the cloud is not synchronized (inconsistent block height, inconsistent hash values ​​of the link table, inconsistent hash values ​​of user ledger data), then the end-to-cloud synchronization process must be completed before transaction block processing can proceed.

[0114] Data blocks rely on historical data for transaction verification. Verification occurs in two directions: one is through the verification nodes in the dynamic blockchain network, which verify the transaction data; the other is in the cloud, where the data block and signatures of all parties are verified. During verification, in addition to providing the current transaction block, historical blocks and a subset of the link table records for the data items required for the current transaction are also provided to the verification nodes or the cloud. Therefore, if a data block has been tampered with, it will fail verification by the verification nodes in the dynamic network. When verifying data blocks in the cloud, the cloud can determine, based on the link table data stored there, whether the current block transaction selected an incorrect historical block, thus preventing double-spending.

[0115] As can be seen from the above data process, any tampering with terminal data will be detected. Furthermore, if incorrect historical blocks are used during terminal transactions, it will be detected by the cloud.

[0116] In some embodiments of the present invention, see Figure 7 Step 600 includes:

[0117] Step 601: Determine whether the hash value of the link table stored by the contract initiator node, the hash value of the link table stored by the multiple contract verifier nodes, and the hash value of the link table stored by at least one cloud service node are consistent.

[0118] To further illustrate the solution, in one specific implementation, the present invention also provides a specific implementation of a blockchain-based transaction data consensus method, which specifically includes the following:

[0119] The devices that run the contract in this application can be a large number of devices with different computing power, such as IoT devices with low computing power, mobile phones, tablets, PCs, and servers. These devices can verify the contract execution results from different business needs by running different parts of the same smart contract, thereby reaching a consensus on contract execution at different nodes in the blockchain network.

[0120] Blockchain network node structure: See Figure 8The blockchain network environment for contract execution includes different types of devices, ranging from low-computing-power network devices such as mobile phones, tablets, PCs, and web mini-programs, to various server devices with high computing and storage capabilities. These serve as cloud services within the blockchain network, and the cloud services can use a consortium blockchain as their data storage mechanism. In this invention, all devices—whether low-computing-power mobile devices, IoT devices, or cloud servers—are considered end-device nodes. Contracts circulate among different end-device nodes. For a single smart contract, each device plays a different role in the blockchain network, executing different parts of the contract according to its role.

[0121] Contract execution roles: Contract execution roles can be categorized into the following types.

[0122] 1) Contract initiating node: also known as the initiator, is responsible for starting contract execution. It is usually the initiator of a blockchain transaction.

[0123] 2) Contract Verifier Node: Abbreviated as Verifier, it verifies the contract execution result executed by the contract initiator.

[0124] 3) Cloud Service Node: Abbreviated as Cloud Service. Verifies the electronic signatures of all parties for contract execution, stores the contract results in a chain according to the execution results, and distributes the contract to the contract recipients as needed for contract execution.

[0125] 4) Contract recipient node: The contract recipient is the party that participates in the execution of the contract.

[0126] Contract-based transaction data organization and transmission: Blockchain transaction data based on cloud-edge-device collaboration technology consists of three parts, namely...

[0127] 1) Data block: Stores transaction information.

[0128] 2) Linked list data (link table): Stores the relationship between user transaction data items and blocks, indicating which block last updated a certain data.

[0129] 3) User ledger data: This data reflects the final status of various user data after the transaction is confirmed by all parties.

[0130] These three types of data are interconnected and linked, with synchronization between the end and the cloud. The generation of new data blocks depends on historical data blocks and chain tag data (link table). Within a data block, the final value of each data item in the user ledger is determined based on the contract execution result and the verification signatures of all parties involved.

[0131] Contract structure: adapted to the generation and circulation process of blocks. This invention provides the following data block structure:

[0132] Each application can leverage cloud-edge-device collaboration to build blockchain data. To share this data, application-layer contracts need to provide functions describing the data structures. A set of related contracts constitutes a contract application. A contract application must provide a `dataInfo` contract to describe the data structures it builds and uses. For example, a wallet contract includes contracts for deposits, withdrawals, and transfers; the wallet contract application must also provide a `dataInfo` contract describing the data structures it builds and uses. This data structure is described in JSON text format.

[0133] Contract execution process: The blockchain node consensus scheme in this application is referred to as a two-sided consensus mechanism, see [link to relevant documentation]. Figure 8 This includes the following:

[0134] Node partitioning:

[0135] Transaction initiating node (e.g.) Figure 9 Node A in the context of transactions: The node that initiates the transaction, responsible for initiating the network setup and transaction consensus process. It executes the logic handled by its business role (based on different business definitions).

[0136] Verification Node (hereinafter referred to as V Node): Verifies the block messages generated in the transaction and is responsible for executing the verification logic of the smart contract in the role of verification.

[0137] Cloud node: Responsible for cloud-based verification and data block processing.

[0138] Counterparty nodes (e.g.) Figure 9 (B node): As a participant in the transaction, it accepts block messages initiated by the transaction node and executes its own logic in the smart contract in the role specified by the transaction initiator.

[0139] Relevant message fields: The relevant fields in the block message are as follows:

[0140] App_Data: Used to pass business parameters in a smart contract to the application layer for execution.

[0141] Role: Smart contract execution role. Each node executes contract logic in a specific role. Each edge script has at least three roles: Business role, which varies depending on the business. For example, in an outbound remittance transaction, there are outbound and receiving roles. Verification role, responsible for executing the verification logic of the verification contract. Cloud role: responsible for verifying the contract and executing block writing based on the contract logic.

[0142] contract_out: This is part of the block message, which is the block data modification instruction generated after the business role executes the smart contract.

[0143] V-node: Verification node. During dynamic networking, it is used to execute the smart contract verification logic on the transaction messages generated by the transaction initiating node.

[0144] Based on the above, the basic logic of the bilateral consensus provided by this invention is as follows: After the transaction initiator completes the edge consensus, it sends the consensus message to the cloud. After the cloud verifies the signature, it distributes the message block to the transaction initiator and the transaction participants. After receiving the cloud-signed block, the transaction initiator updates its own user data. After receiving the cloud-distributed block, the transaction participants process their own data, supplement the block message content, and initiate the edge consensus process again. Finally, the message is sent to the cloud. After the cloud signs it, the transaction participants receive the cloud-signed message and update their local user data. In the following text, A is the transaction initiator and B is the transaction participant. The specific bilateral consensus steps are as follows:

[0145] A-side consensus process: Node A executes the `exec` function in the smart contract according to the role defined in `App_Data`. Node A initiates a network formation request and sends block messages to each V-node. In the block message constructed by Node A, the `trans_parts` section specifies the `part_item` information of each participant in the transaction, and Node A writes its own `contract_out` output; the `contract_out` for other `part_items` is left blank. Node A signs the constructed block message data and then sends it to each validator node.

[0146] Side A Consensus Verification: The verifying node receives the block message from node A and performs verification. The verifying node executes the verify function in the smart contract as the verify role. (Modify the role value in App_Data)

[0147] The verification node returns a verification signature to the A node. The A node then adds the signature data from each V node to the `verification_nodes` structure of the block message. After signing the constructed block message data, the A node sends it to the cloud node.

[0148] Cloud-based verification and distribution: The cloud node verifies all signatures in the message submitted by node A and then performs a cloud-based signature. The cloud node returns the signed message to node A. The cloud node performs block processing on node A's message. After receiving the signature from the cloud node, node A updates its local data according to the `contract_out` instruction in the node. The cloud node distributes the message to other nodes in the transaction except node A. The cloud-based distribution message is based on the content of the message submitted to node A, sets the `Contract_out` of node A and all other nodes except the target distribution node to NULL, then re-signs it and distributes it to the other participating nodes in the transaction except node A.

[0149] Node B supplements message information: During heartbeat synchronization with the cloud, Node B receives block messages distributed by the cloud for processing. Node B executes the `exec` function in the smart contract using the identity specified in the message. It fills in the `contract_out` information of the corresponding node in `trans_parts`. Node B changes the `role` in the `App_Data` role in the message to its already defined role. Node B initiates a network consensus request and sends the supplemented message to the validator nodes.

[0150] B-side consensus: Verifying nodes receive the block message from B nodes and verify it. The verifying node, acting as the verify role, executes the verify function in the smart contract (modifying the role value in App_Data). The verifying node returns a verification signature to the B node. The B node supplements the block message's verification_nodes structure with the signature data from each V node. After signing the constructed block message data, the B node sends it to the cloud node.

[0151] Cloud-based verification and distribution: The cloud node verifies all signatures in the message submitted by node B and then performs a cloud-based signature. The cloud node returns the signed message to node B. The cloud node performs block processing on node B's message. After receiving the signature from the cloud node, node B updates its local data according to the `contract_out` instruction in the node.

[0152] Edge-to-cloud data synchronization mechanism: Users can utilize the wide-area blockchain functionality provided by the edge SDK through various endpoints. However, at any given time, only one method allows user operation. If a user logs into an endpoint, data synchronization is required when that user moves to another endpoint to ensure data synchronization between endpoint nodes and cloud nodes.

[0153] When a node synchronizes block data, if the block has already been processed by a user, it only updates the local data file according to the data update instructions in the block's message. If it has not been processed, it performs the corresponding business logic processing according to the assigned role, then generates the corresponding smart contract processing message, initiates the network verification process, and after completing the message verification, submits the cloud verification signature, and then synchronizes back to the local machine for data update.

[0154] See Figure 10 In a specific embodiment of the present invention, the data block result includes: the block message is composed of multiple message segments, forming a multi-layered data structure. The block message mainly includes the following block information, contract execution parameters, contract block nesting relationship, transaction information, user ledger data update instructions, edge-submitted verification information, and various signature information.

[0155] The data file structure generated by the cloud edge is as follows Figure 11 As shown, the block message flows through different nodes on the cloud, edge, and terminal, undergoing transaction processing, verification, and block creation. After the cloud completes the signing, each node updates its own user ledger data based on the block message content. The block message ultimately forms the following file:

[0156] The user.dat file contains user ledger data, primarily storing data generated from each user's transactions. It uses the user's DID as the core identifier to build and accumulate transaction data related to the user's participation, similar to the world state table in a consortium blockchain. The user.dat file is mainly used for query operations. Its value displays the final state of the user's transaction data. User data queries are typically obtained by accessing this data file.

[0157] The link.dat file primarily stores the association between data items and blocks. It indicates which transaction generated a particular data item. When subsequent transactions use this data item, the block pointed to by that data item is used as the historical block data for that transaction and provided to validating nodes for multi-party verification to reach consensus.

[0158] The block.dat file: block.dat is stored in the cloud in the data storage space of each user, and in the user data ledger at the edge.

[0159] Additionally, see Figure 12The linking constraints between blocks include: constraints between blocks; a new transaction block is based on data from historical blocks. User data is organized in a tree structure and stored in the user.dat file. Each data item is associated with a transaction block, and this association is stored in the link.dat file. Information about each transaction block is stored in the block.dat file. When a validator node or cloud node verifies a transaction, the transaction initiating node must send historical block information and the link relationships between data items and blocks to the validator node or cloud for verification. A transaction is considered complete only after the cloud signs a block and it is received and stored by the initiating terminal. The block also stores the link relationships between blocks; each block has data items indicating that it is based on data from a previous historical block. When a terminal receives a block signed by the cloud, it updates its local data files according to the data update instructions in the block.

[0160] As can be seen from the above description, the specific embodiments of the present invention provide a blockchain-based transaction data consensus method, which has the following beneficial effects:

[0161] Firstly, it offers beneficial effects in terms of technology, such as separation of computation and verification, edge-cloud synchronization, bilateral consensus, and data ledger:

[0162] 1. Separation of calculation and verification

[0163] Blockchain based on cloud-edge-device collaboration technology integrates the computing resources of wide-area networks, pushing the computation and consensus process of smart contracts to the edge consensus network. The cloud only needs to verify transactions and process blocks, unlike existing blockchains (public or consortium blockchains), where the computation and consensus processes for contract execution must occur across all consensus nodes in the chain. In this cloud-edge-device technology system, edge nodes and the cloud each perform their respective functions, enabling computation and verification to be carried out on different nodes, thus optimizing the load balancing in the entire blockchain operation. This constitutes a key technical feature of this solution: the separation of blockchain computation and verification, or simply computation-verification separation.

[0164] 2. End-to-cloud synchronization

[0165] Traditional blockchain technology requires all nodes participating in consensus to store all transaction data and strictly maintain consistent block heights across nodes; otherwise, data forks will occur, resulting in significant data redundancy and consuming substantial storage space. The cloud-edge-device collaborative technology system differs. Each user's device only retains the transaction block data it participated in, without needing to store data from other users, thus saving considerable storage space. Furthermore, the cloud uses distributed technology to store the ledger data of all users and ensures the integrity of user ledger data by storing Merkle (MKL) calculations of related blocks in the cloud. Through edge-cloud synchronization and data verification, the transaction process is protected against data tampering and double-spending. In the event of data loss on the device itself, data can be recovered from the cloud, improving user data security. Edge-cloud synchronization reduces the space required for data storage while ensuring secure and reliable data storage.

[0166] 3. Bilateral consensus

[0167] The cloud-edge-device collaboration adopts a bilateral consensus model, where each transaction participant independently processes its own block data to complete dynamic network consensus. This transaction model is asynchronous and will not cause transaction blocking. Furthermore, the cloud can have multiple servers running concurrently, capable of handling transaction verification requests and data block processing from different users. Therefore, by deploying servers in the cloud, unlimited business capacity can be provided to business systems.

[0168] 4. Data Ledger

[0169] The cloud-edge-device technology system constructs a mesh-like data chain with strong synchronization between the cloud and the endpoints. This protects data from tampering, double-spending, and ensures traceability, while also enabling data recovery after endpoint data corruption. These capabilities provide robust data layer services for the application layer. Each application layer service can share and utilize user data ledger data with user authorization. All user-related application data is centrally stored in the user's data ledger, establishing user data ownership relationships and providing a technological foundation for establishing user data control and monetizing user data.

[0170] Furthermore, this invention also brings business benefits in the following aspects:

[0171] 1. Achieve trusted and secure data on the terminal.

[0172] Terminal device data has been subject to interference from various factors, leading to serious doubts about its trustworthiness. Wide-area blockchain technology, through the comprehensive application of technologies such as multi-point collaboration between cloud, edge, and terminal devices, witness consensus verification, and storage of transaction data via block linkage, will inevitably detect illegal data tampering on the terminal device upon final transaction completion. This renders data tampering meaningless, and users who tamper with data will be blacklisted, losing the opportunity to participate in future transactions. This achieves secure and trustworthy terminal device data.

[0173] 2. Enhanced privacy protection capabilities

[0174] Unlike public blockchain architectures, which use a globally synchronized ledger to prevent data tampering, cloud-edge-device collaborative technology also differs from consortium blockchain architectures, where all transaction nodes reside in the cloud blockchain, requiring data isolation methods such as channels to protect user privacy. In a wide-area blockchain based on cloud-edge-device collaborative technology, each node establishes an independent user data ledger locally, storing not only its own transaction data but also data from other users or unrelated transactions. By establishing an independent user data ledger for each user in the cloud and storing their ledger data separately, data is naturally separated among users, thus achieving secure protection of user privacy.

[0175] 3. User data ownership capabilities

[0176] Cloud-edge-device collaboration technology constructs data around the user's DID (Distributed ID), and smart contracts operate based on this user ledger data. User ledger data is stored both in the cloud and locally on the user's device. Users can query their transaction data offline, and if their device is damaged, they can recover data from the cloud. Building upon this technology, a data subscription mechanism provides users with control over data ownership. Users can control the scope, method, and extent of data usage by which contracts or application layers access their transactions, thereby further enhancing the technical capabilities for monetizing user-owned data.

[0177] 4. Built-in digital asset transfer capability

[0178] A blockchain architecture based on cloud-edge-device collaboration technology enables a built-in economic system similar to that of a public blockchain. Supported by this technology, it allows for peer-to-peer digital asset transfers between devices, providing the necessary technical means for decentralized financial transactions that operate outside of centralized accounting systems. This cloud-edge-device collaboration technology, based on the premise of cloud trust, maintains the connection with traditional centralized systems through the cloud, enabling far broader transaction capabilities than public blockchain architectures. Compared to traditional consortium blockchain architectures, it extends business reach to each smart device, directly providing blockchain data processing capabilities on the device itself, significantly reducing cloud pressure. This separation of computation and verification ensures that the cloud no longer becomes a bottleneck for the system.

[0179] Based on the same inventive concept, this application also provides a blockchain-based transaction data consensus device, which can be used to implement the methods described in the above embodiments, as shown in the following embodiments. Since the principle of the blockchain-based transaction data consensus device in solving the problem is similar to that of the blockchain-based transaction data consensus method, and the principle of the blockchain dynamic networking device in solving the problem is similar to that of the blockchain dynamic networking method, the implementation of the blockchain-based transaction data consensus device can refer to the implementation of the blockchain-based transaction data consensus method, and the implementation of the blockchain dynamic networking device can refer to the implementation of the blockchain dynamic networking method; repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0180] This invention provides a specific implementation of a blockchain-based transaction data consensus device capable of implementing a blockchain-based transaction data consensus method. See [link to relevant documentation]. Figure 13 A blockchain-based transaction data consensus device specifically includes the following components:

[0181] The blockchain network component module 10 is used to construct a second blockchain network in response to the first blockchain network being in a weak or offline state, through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0182] The data block construction module 20 is used to construct data blocks in the second blockchain network in response to the transaction request of the contract initiator node.

[0183] Relationship establishment module 30 is used to establish the relationship between the data block and the user transaction data item;

[0184] The transaction consensus module 40 is used to reach a consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0185] In some embodiments of the present invention, see Figure 14 The data block construction module 20 includes:

[0186] The data block construction unit 201 is used to construct the data block based on the network data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block of the second blockchain network.

[0187] In some embodiments of the present invention, the data block is stored on the plurality of cloud service nodes, the corresponding contract initiator node, and the plurality of contract verifier nodes.

[0188] In some embodiments of the present invention, see Figure 15 A blockchain-based transaction data consensus device also includes:

[0189] The relationship storage module 50 is used to store the relationship through a link table, which is used to represent the latest data block of transaction data.

[0190] In some embodiments of the present invention, see Figure 16 The transaction consensus module 40 includes:

[0191] The data sending unit 401 is used to send the transaction, the historical data of the data block, and the link table to multiple contract verification nodes in the second blockchain network.

[0192] The data block signing unit 402 is used to sign the data block by the multiple contract verification nodes after the transaction has been verified by the multiple contract verification nodes.

[0193] The transaction block placement unit 403 is used to send the signed data block to multiple cloud service nodes, and the multiple cloud service nodes perform block placement operations on the transaction.

[0194] In some embodiments of the present invention, see Figure 17 A blockchain-based transaction data consensus device also includes:

[0195] The block height verification module 60 is used to verify whether the block height of the contract initiator node, the block height of the multiple contract verifier nodes, and the block height of at least one cloud service node are consistent.

[0196] The data block synchronization module 70 is used to synchronize the data blocks stored by the contract initiator node, the multiple contract verifier nodes, and the multiple cloud service nodes according to the link table when the block layer height of the contract initiator node, the block layer height of the multiple contract verifier nodes, and the block layer height of at least one cloud service node are inconsistent.

[0197] In some embodiments of the present invention, see Figure 18 The block height verification module 60 includes:

[0198] The block height verification unit 601 is used to determine whether the hash value of the link table stored by the contract initiator node, the hash value of the link table stored by the multiple contract verifier nodes, and the hash value of the link table stored by at least one cloud service node are consistent.

[0199] As described above, embodiments of the present invention provide a blockchain-based transaction data consensus device, comprising: a blockchain network component module, used to construct a second blockchain network through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes in response to a first blockchain network being in a weak or offline state; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network; a data block construction module, used to construct data blocks in the second blockchain network in response to transaction requests from contract initiator nodes; a relationship establishment module, used to establish relationships between data blocks and user transaction data items; and a transaction consensus module, used to reach consensus on the transaction corresponding to the transaction request based on the second blockchain network, data blocks, and relationships.

[0200] This invention utilizes a collaborative smart contract execution method involving various device nodes. It fully and balancedly leverages the computing and storage capabilities of various device nodes in a distributed network, enabling more terminal devices with varying computing power to act as consensus nodes and participate in the consensus calculation process of the blockchain network. This changes the traditional model where terminal nodes with low computing power can only serve as edge devices. It fully utilizes the computing and storage capabilities of edge devices with low computing power to build a blockchain network. Through the collaborative execution of contracts by edge devices, the consensus process for block data is completed.

[0201] The embodiments of this application also provide a specific implementation of an electronic device capable of implementing a blockchain-based transaction data consensus method and all steps of the blockchain-based transaction data consensus method described in the above embodiments. See [link to relevant documentation]. Figure 19 The electronic devices specifically include the following:

[0202] Processor 1201, memory 1202, communications interface 1203, and bus 1204;

[0203] The processor 1201, memory 1202, and communication interface 1203 communicate with each other via bus 1204; the communication interface 1203 is used to realize information transmission between server-side devices and user-side devices and other related devices.

[0204] The processor 1201 is used to call the computer program stored in the memory 1202. When the processor executes the computer program, it implements a blockchain-based transaction data consensus method and all the steps in the blockchain-based transaction data consensus method described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0205] Step 100: In response to the first blockchain network being in a weak or offline state, a second blockchain network is established by the contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0206] Step 200: In response to the transaction request from the contract initiator node, construct a data block in the second blockchain network;

[0207] Step 300: Establish the relationship between the data block and the user transaction data item;

[0208] Step 400: Reach consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0209] Embodiments of this application also provide a computer-readable storage medium capable of implementing the blockchain-based transaction data consensus method and all steps of the blockchain-based transaction data consensus method described in the above embodiments. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the blockchain-based transaction data consensus method and all steps of the blockchain-based transaction data consensus method described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0210] Step 100: In response to the first blockchain network being in a weak or offline state, a second blockchain network is established by the contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network.

[0211] Step 200: In response to the transaction request from the contract initiator node, construct a data block in the second blockchain network;

[0212] Step 300: Establish the relationship between the data block and the user transaction data item;

[0213] Step 400: Reach consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

[0214] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.

[0215] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0216] While this application provides method operation steps as shown in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or user terminal product execution, the method can be executed in the order shown in the embodiments or drawings or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0217] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; 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, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0218] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0219] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0220] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0221] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments in this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0222] The above description is merely an embodiment of the present specification and is not intended to limit the embodiments of the present specification. For those skilled in the art, various modifications and variations can be made to the embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present specification should be included within the scope of the claims of the embodiments of the present specification.

Claims

1. A blockchain-based transaction data consensus method, characterized in that, include: In response to the first blockchain network being in a weak or offline state, a second blockchain network is constructed by the contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network. In response to a transaction request from the contract initiator node, a data block is constructed in the second blockchain network; wherein, constructing the data block includes: constructing the data block based on the network topology data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block; the data block is stored on the multiple cloud service nodes, the corresponding contract initiator node, and the multiple contract verification nodes; Establish the relationship between the data blocks and user transaction data items; Consensus is reached on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

2. The transaction data consensus method according to claim 1, characterized in that, Also includes: The relationships are stored in a link table, which is used to represent the latest data block of transaction data.

3. The transaction data consensus method according to claim 2, characterized in that, Consensus is reached on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship, including: Send the transaction, the historical data of the data block, and the link table to multiple contract verification nodes in the second blockchain network; After the transaction is verified by the multiple contract verification nodes, the multiple contract verification nodes sign the data block. The signed data block is sent to multiple cloud service nodes, which then perform block creation operations on the transaction.

4. The transaction data consensus method according to any one of claims 2 or 3, characterized in that, Before reaching consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship, the process further includes: Verify whether the block layer height of the contract initiator node, the block layer height of the multiple contract verifier nodes, and the block layer height of at least one cloud service node are consistent. When the block height of the contract initiator node, the block height of the multiple contract verifier nodes, and the block height of at least one cloud service node are inconsistent, the data blocks stored by the contract initiator node, the data blocks stored by the multiple contract verifier nodes, and the data blocks stored by the multiple cloud service nodes are synchronized according to the link table.

5. The transaction data consensus method according to claim 4, characterized in that, Verifying whether the block layer height of the contract initiator node, the block layer height of the multiple contract verifyer nodes, and the block layer height of at least one cloud service node are consistent includes: Determine whether the hash value of the link table stored by the contract initiator node, the hash value of the link table stored by the multiple contract verifier nodes, and the hash value of the link table stored by at least one cloud service node are consistent.

6. A blockchain-based transaction data consensus device, characterized in that, include: The blockchain network component module is used to construct a second blockchain network in response to a weak or offline state of the first blockchain network, through a contract initiator node, multiple contract verifier nodes, and multiple cloud service nodes; when the first blockchain network is normal, the contract initiator node and multiple contract verifier nodes are located in the first blockchain network. A data block construction module is used to construct a data block in the second blockchain network in response to a transaction request from the contract initiator node. The construction of the data block includes: constructing the data block based on the network topology data, block production data, transaction data, contract ID, data operation instructions after contract execution, and the private key signature of the data block; the data block is stored on the multiple cloud service nodes, the corresponding contract initiator node, and the multiple contract verification nodes. The relationship establishment module is used to establish the relationship between the data block and the user transaction data item; The transaction consensus module is used to reach a consensus on the transaction corresponding to the transaction request based on the second blockchain network, the data block, and the relationship.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the blockchain-based transaction data consensus method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the blockchain-based transaction data consensus method according to any one of claims 1 to 5.

Images