A consensus method and device for a blockchain transaction

Abstract

A consensus method and device of a blockchain transaction, the blockchain comprising a plurality of nodes participating in consensus, the plurality of nodes comprising a consensus proposal node and a first non-proposal node, the method being performed by the first non-proposal node, the method comprising: receiving a first transaction, encrypting the first transaction to obtain first transaction ciphertext; sending the first transaction ciphertext to the consensus proposal node; receiving a consensus pre-proposal from the consensus proposal node; when the first transaction ciphertext is included in the consensus pre-proposal, submitting a first decryption key of the first transaction ciphertext to an auxiliary blockchain for decrypting the first transaction ciphertext; and sending a first address of the first decryption key saved in the auxiliary blockchain to the consensus proposal node.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a consensus method and apparatus for blockchain transactions. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and has been widely applied in numerous fields. Summary of the Invention

[0003] The purpose of this invention is to provide a consensus method and apparatus for blockchain transactions, thereby preventing consensus nodes from abusing their transaction ordering rights to cause malicious behavior during the consensus process and improving the security and fairness of the consensus process.

[0004] This specification provides a consensus method for blockchain transactions in its first aspect. The blockchain includes multiple nodes participating in the consensus process, including a consensus-proposing node and a first non-proposing node. The method is executed by the first non-proposing node and includes:

[0005] Receive the first transaction, encrypt the first transaction, and obtain the ciphertext of the first transaction;

[0006] Send the first transaction ciphertext to the consensus proposal node;

[0007] Receive consensus pre-proposals from the consensus proposal node;

[0008] When the consensus pre-proposal includes the first transaction ciphertext, a first decryption key of the first transaction ciphertext is submitted to the auxiliary blockchain for decryption of the first transaction ciphertext; the first address of the first decryption key stored in the auxiliary blockchain is sent to the consensus proposal node.

[0009] A second aspect of this specification provides a consensus method for blockchain transactions, wherein the blockchain includes multiple nodes participating in the consensus, the multiple nodes including a consensus proposal node and several non-proposal nodes, the method being executed by the consensus proposal node, and the method comprising:

[0010] Receive multiple ciphertexts corresponding to multiple transactions;

[0011] Generate a consensus pre-proposal, wherein the consensus proposal includes the plurality of transaction ciphertexts;

[0012] The consensus pre-proposal is sent to each non-proposal node.

[0013] A third aspect of this specification provides a consensus device for blockchain transactions, wherein the blockchain includes multiple nodes participating in consensus, the multiple nodes include a consensus proposal node and a first non-proposal node, the device is deployed at the first non-proposal node, and the device includes:

[0014] The transaction receiving unit is configured to receive a first transaction, encrypt the first transaction, and obtain the first transaction ciphertext.

[0015] The encrypted sending unit is configured to send the first transaction encrypted message to the consensus proposal node;

[0016] The consensus pre-proposal receiving unit is configured to receive consensus pre-proposals from the consensus proposal node;

[0017] The key submission unit is configured to, when the consensus pre-proposal includes the first transaction ciphertext, submit a first decryption key of the first transaction ciphertext to the auxiliary blockchain for decrypting the first transaction ciphertext; and send the first address of the first decryption key stored in the auxiliary blockchain to the consensus proposal node.

[0018] This specification provides a consensus device for blockchain transactions in a fourth aspect. The blockchain includes multiple nodes participating in consensus, including a consensus proposal node and several non-proposal nodes. The device is deployed at the consensus proposal node and includes:

[0019] The transaction ciphertext receiving unit is configured to receive multiple transaction ciphertexts corresponding to multiple transactions.

[0020] A consensus pre-proposal generation unit is configured to generate a consensus pre-proposal, wherein the consensus proposal includes the plurality of transaction ciphertexts;

[0021] The consensus pre-proposal sending unit is configured to send the consensus pre-proposal to each non-proposal node.

[0022] Fifthly, a computer-readable storage medium is provided having a computer program or instructions stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0023] A sixth aspect provides a computing device including a memory and a processor, wherein the memory stores a computer program or instructions, and the processor, when executing the computer program or instructions, implements the method described in the first aspect. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A blockchain architecture diagram is shown in one embodiment;

[0026] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm;

[0027] Figure 3 This is a schematic diagram of a transaction consensus method;

[0028] Figure 4 This is a schematic diagram of a scenario illustrating the consensus method for blockchain transactions in one embodiment of this specification;

[0029] Figure 5 This is a flowchart of a consensus method for blockchain transactions in one embodiment of this specification;

[0030] Figure 6 This is a flowchart of a consensus method for blockchain transactions in another embodiment of this specification;

[0031] Figure 7 This is an architectural diagram of a consensus device for blockchain transactions in one embodiment of this specification;

[0032] Figure 8 This is an architectural diagram of a consensus device for blockchain transactions in another embodiment of this specification. Detailed Implementation

[0033] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0034] Figure 1 A blockchain architecture diagram is shown in one embodiment. Figure 1As shown, a blockchain 100, for example, contains 6 nodes. The connections between nodes schematically represent P2P (Peer-to-Peer) connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain produces the same state by executing the same transactions, and each node stores the same state database. This can be understood as... Figure 1 Although the example shows a blockchain with 6 nodes, the embodiments in this specification are not limited to this and may include other numbers of nodes.

[0035] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0036] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a network-wide consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT) algorithms. In various consensus algorithms, consensus on a consensus proposal is typically determined after a predetermined number of nodes reach agreement on the proposed data. Specifically, in the PBFT algorithm, for N ≥ 3f+1 consensus nodes, f malicious nodes can be tolerated. That is, when 2f+1 out of N consensus nodes reach agreement, consensus is considered successful.

[0037] Figure 2 This is a schematic diagram of the consensus process in the PBFT consensus algorithm. Figure 2As shown, according to the PBFT consensus algorithm, the consensus process can be divided into four phases: Request, Pre-Prepare, Prepare, and Commit. Assume a blockchain includes four consensus nodes: n1 to n4. Node n1 is, for example, the master node, and nodes n2 to n4 are, for example, slave nodes. According to the PBFT algorithm, f=1 malicious nodes can be tolerated among nodes n1 to n4. Specifically, in the Request phase, blockchain users can send requests to node n1 through their user devices. These requests can be, for example, in the form of blockchain transactions. In the Pre-Prepare phase, after receiving multiple transactions from one or more user devices, node n1 can package these transactions into a consensus proposal and send the consensus proposal, along with its signature, to other consensus nodes (i.e., nodes n2 to n4) for block generation. The consensus proposal may include information such as the transaction bodies and the submission order of the transactions. In the Prepare phase, each slave node can sign the consensus proposal and send it to the other nodes. Assuming node n4 is a malicious node, after nodes n1, n2, and n3 receive signatures of the consensus proposal from 2f = 2 other consensus nodes, they can determine that the preparation phase is complete and can proceed to the commit phase. For example, if... Figure 2 As shown, after receiving the signatures from nodes n2 and n3, node n1 verifies that both signatures are correct for the consensus proposal, thus determining that the preparation phase is complete. Similarly, after receiving and verifying the signatures from node n3 and node n1 (from the preparation phase), node n2 determines that the preparation phase is complete. In the commit phase, each consensus node signs the consensus proposal and sends it to the other consensus nodes. Each consensus node, after receiving the commit phase signatures from 2f = 2 other consensus nodes, determines that the commit phase is complete and consensus is successful. For example, after receiving and verifying the commit phase signatures from nodes n2 and n3, node n1 determines that the commit phase is complete. Therefore, node n1 can execute the multiple transactions according to the consensus proposal, generate and store a block (e.g., block B1) including the multiple transactions, update the world state based on the execution results of the multiple transactions, and return the execution results of the multiple transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the multiple transactions, generate and store block B1, and update the world state based on the execution results of the multiple transactions. Through the above process, storage consistency is achieved among nodes n1, n2, and n3. In other words, even with the presence of a malicious node, nodes n1 through n4 can still achieve successful consensus on the consensus proposal and complete the execution of the block.

[0038] Therefore, existing blockchain transaction consensus schemes typically involve consensus-proposing nodes sending transaction consensus proposals to other non-proposing nodes participating in the consensus process, and other non-proposing nodes responding to the consensus proposals to reach a transaction consensus. The consensus proposals constructed by the consensus-proposing nodes include the execution order of the transactions. Figure 3 This is a schematic diagram of a transaction consensus method. (Example) Figure 3 As shown, a consensus proposal node (e.g., node 1) sends a consensus proposal to each non-proposal node (e.g., node 2, node 3, etc.). The proposal contains multiple transactions with the same execution order (e.g., transaction 3, transaction 2, transaction 1, transaction 5, etc.). Each non-proposal node, based on the consensus proposal it receives, and according to the consensus protocol, determines whether it receives the same set of transactions and whether the order of the transactions in the set is the same, and then determines whether to reach a consensus on, for example, all or some of the transactions, and executes them. However, existing blockchain transaction consensus schemes also have the following problems: because the proposal node can control "which transactions are included in a block" and "the order in which the transactions in the block should be executed," malicious proposal nodes can use the block formation and ordering rights of transactions to allow transactions initiated by some users to run before those of other users. In particular, when different transactions are in competition, such as when the number of tokens required for a transaction is insufficient, malicious control of the transaction order by the proposal node can further affect which transactions will succeed and which will fail, thus affecting the fairness of transaction execution.

[0039] To address the aforementioned technical problems, this specification provides a consensus method for blockchain transactions. The core idea of ​​this method is that non-proposal nodes receive each transaction request, encrypt each transaction upon receipt, and forward the encrypted transaction to the consensus proposal node. A unique decryption key corresponding to each transaction is recorded in another auxiliary blockchain. The consensus proposal node, based on the received encrypted transaction data, sends a consensus pre-proposal containing a set of encrypted transactions to be executed to each non-proposal node. Each non-proposal node determines whether the consensus pre-proposal contains the transaction it forwarded to the proposal node. If it does, the node stores the decryption key of that transaction in the pre-proposal in the auxiliary blockchain. The consensus proposal is sent in the response information and a pre-proposal response message is sent. The consensus proposal node generates a consensus proposal based on the received pre-proposal response message and sends the consensus proposal to each non-proposal node. The consensus proposal includes several ciphertexts of transactions and the storage address of the decryption key of each ciphertext in the auxiliary blockchain. After receiving the consensus proposal, each non-proposal node obtains the corresponding key of each ciphertext from the auxiliary blockchain according to the storage address of the corresponding key of each ciphertext. When executing each transaction, it decrypts each ciphertext according to the obtained decryption key and then executes it. Transactions that have not obtained a decryption key are rejected. Figure 4 This is a schematic diagram illustrating a scenario of a consensus method for blockchain transactions in one embodiment of this specification. For example... Figure 4 As shown, non-proposal nodes (e.g., node 2, node 3) can receive transactions (transaction 2, transaction 3, etc.) from the blockchain client or user terminal. After receiving the request, each node encrypts the received transaction and forwards the ciphertext (e.g., ciphertext of transaction 2, ciphertext of transaction 3) to the consensus proposal node (e.g., node 1). The node also stores the decryption keys (e.g., key for transaction 2, key for transaction 3) corresponding to the forwarded transactions in the auxiliary blockchain. The consensus proposal node (e.g., node 1) then sends a consensus pre-proposal to each non-proposal node, containing a set of ciphertexts of transactions to be executed (e.g., ciphertext of transaction 3, ciphertext of transaction 2, ciphertext of transaction 1, ciphertext of transaction 5, etc.). Upon receiving a consensus pre-proposal, each non-proposal node, for example, if node 2 determines that the consensus pre-proposal includes the ciphertext of transaction 2 that it forwarded to the consensus proposal node, will send the address where the decryption key (transaction 2 key) of the ciphertext 2 is stored (in the auxiliary blockchain) as a pre-proposal response message to the consensus proposal node. Similarly, if node 3 determines that the consensus pre-proposal includes the ciphertext of transaction 3 that it forwarded to the consensus proposal node, it will send the address where the decryption key (transaction 3 key) of the ciphertext 3 is stored to the consensus proposal node. Subsequently, the consensus proposal node can generate a consensus proposal based on the received pre-proposal response messages from each non-proposal node and send the consensus proposal, which includes multiple ciphertexts and the addresses where their decryption keys are stored in the auxiliary blockchain, to each non-proposal node. Upon receiving the consensus proposal, each non-proposal node (e.g., node 2, node 3) can obtain the corresponding key for each ciphertext from the auxiliary blockchain based on the address where the corresponding key is stored for each ciphertext, decrypt each ciphertext using the aforementioned decryption key, obtain the plaintext transaction, and then execute it. Transactions for which no decryption key has been obtained will be rejected.

[0040] The consensus scheme for blockchain transactions provided in the embodiments of this specification has the following advantages: On the one hand, since the consensus proposal node can only receive the ciphertext of the transaction forwarded by the non-proposal nodes, but does not know the specific content and source of the transaction, the consensus proposal node cannot unfairly order transactions based on their specific content and source. For example, the consensus proposal node cannot prioritize some transactions or transactions sent by some users over others based on their specific content and source, thus preventing the consensus proposal node from using its transaction ordering power to maliciously order transactions and affect the fairness of transaction execution. On the other hand, non-proposal nodes can only store the decryption key of the ciphertext in the auxiliary blockchain and send the key address to the consensus proposal node, which then sends it to other non-proposal nodes through the consensus proposal. This ensures the uniqueness of the key for the same transaction during the consensus process. This avoids the problem that any non-proposal node providing different keys for the same transaction to different nodes would result in different keys being obtained by different nodes, leading to different results on different nodes in whether the transaction can be successfully executed.

[0041] The following section further elaborates on the detailed process of this method.

[0042] Figure 5 This is a flowchart of a consensus method for blockchain transactions in one embodiment of this specification. The blockchain includes multiple nodes participating in the consensus process, including a consensus proposal node and a first non-proposal node. The method is executed by the first non-proposal node, as follows: Figure 5 As shown, the method includes the following steps S51-S57. These will be described in detail below. Figure 5 The steps shown.

[0043] First, in step S51, the first transaction is received and encrypted to obtain the ciphertext of the first transaction.

[0044] A consensus proposal node, typically referred to as a node in a blockchain system, is responsible for issuing a consensus proposal containing a set of transactions to be executed to other participating nodes. A non-proposal node, typically referred to as a node in a blockchain system, receives the consensus proposal from the consensus proposal node and responds according to the consensus protocol. A blockchain may include at least one non-proposal node, and a first non-proposal node may be any one of the at least one non-proposal node. Depending on the implementation, the transaction received by the first non-proposal node in this step (e.g., the first transaction) may be of different types, and this specification does not limit this.

[0045] Depending on the implementation method, different encryption algorithms can be used to encrypt the first transaction to obtain the ciphertext of the first transaction. For example, in one implementation, a symmetric encryption algorithm can be used to encrypt the first transaction. In another implementation, an asymmetric encryption algorithm can be used to encrypt the first transaction.

[0046] Step S53: Send the first transaction ciphertext to the consensus proposal node.

[0047] In this step, the non-proposal node sends the first ciphertext of the transaction obtained in step S51 to the consensus proposal node. Depending on the implementation, the non-proposal node may also send both the ciphertext and its signature to the consensus proposal node after signing the first ciphertext. Therefore, according to one specific implementation, the first ciphertext of the transaction, along with a first signature generated using the node's private key, can be sent to the consensus proposal node.

[0048] Step S55: Receive a consensus pre-proposal from the consensus proposal node.

[0049] In this step, the consensus-proposing node can send a consensus pre-proposal to other nodes participating in the consensus. In this step, the first non-proposing node receives the consensus pre-proposal sent by the consensus node. In one implementation, the consensus pre-proposal may contain a set of transactions to be executed, such as a first transaction set, which may include the ciphertext of several transactions to be executed.

[0050] Step S57: When the consensus pre-proposal includes the first transaction ciphertext, submit the first decryption key of the first transaction ciphertext to the auxiliary blockchain for decrypting the first transaction ciphertext; send the first address of the first decryption key stored in the auxiliary blockchain to the consensus proposal node.

[0051] The auxiliary blockchain is a blockchain other than the blockchain to which the first non-proposal node belongs. In this step, if the set of transactions to be executed (e.g., the first transaction set) included in the consensus pre-proposal obtained by the first non-proposal node in step S55 includes the first transaction ciphertext, then the first non-proposal node submits a decryption key (e.g., the first decryption key) for the first transaction ciphertext to the auxiliary blockchain. That is, the first non-proposal node saves the first decryption key on a blockchain other than its own blockchain. In a specific implementation, saving the key on the auxiliary blockchain can be done by calling a smart contract. Therefore, according to one implementation, a first contract preset on the auxiliary blockchain can be called to submit the hash value of the first transaction ciphertext and the first decryption key to the auxiliary blockchain. According to one implementation, the first non-proposal node can also submit the hash value of the first transaction ciphertext and the first decryption key to the auxiliary blockchain. According to another implementation, the first non-proposal node can also submit the hash value of the first transaction ciphertext, a first signature for the first transaction ciphertext generated using the node's private key, and the first decryption key to the auxiliary blockchain. In one example, when other non-proposal nodes subsequently obtain the first decryption key from the auxiliary blockchain, they can determine whether the node that submitted the key to the auxiliary blockchain is a consensus proposal node based on the first signature. If the result is yes, then the node is refused to use the key to decrypt the corresponding transaction ciphertext.

[0052] Furthermore, the first non-proposal node can send the first address of the first decryption key stored in the auxiliary blockchain to the consensus proposal node. Depending on the implementation, the first address can have different specific forms, and this specification does not limit this. For example, in one implementation, the first address may include the block number of the block in the auxiliary blockchain used to store the first decryption key, and the hash value of the transaction tx in that block, which stores the first decryption key in its transaction body. Subsequently, the first decryption key can be obtained from the auxiliary blockchain based on the block number and the hash value of the transaction tx.

[0053] After receiving the first address, the consensus proposal node can include the first address in the consensus proposal and send the consensus proposal to all non-proposal nodes. The consensus proposal may include a set of ciphertexts consisting of several transaction ciphertexts, and the storage address of the decryption key of each transaction ciphertext in the auxiliary blockchain. Depending on the implementation method, the set of ciphertexts included in the consensus proposal may be exactly the same as or not exactly the same as the set of transactions to be executed in the consensus pre-proposal, and this specification does not impose any restrictions on this.

[0054] The first address in the consensus proposal can be used by other non-proposal nodes to obtain the first decryption key corresponding to the first transaction ciphertext from the auxiliary blockchain, decrypt the first transaction ciphertext included in the received consensus proposal to obtain the plaintext of the first transaction, and execute the first transaction. Similarly, after receiving the consensus proposal, the first non-proposal node can also obtain the decryption key corresponding to other transaction ciphertexts (e.g., transaction ciphertexts forwarded to the consensus proposal node by other non-proposal nodes) from the auxiliary blockchain based on the address of the decryption key of other transaction ciphertexts in the consensus proposal, decrypt the other transaction ciphertexts to obtain the plaintext of the other transactions, and execute the other transactions. Therefore, according to one implementation, the plurality of nodes may further include a second non-proposal node. After sending the first address to the consensus proposal node, the first non-proposal node also receives a consensus proposal from the consensus proposal node; the consensus proposal includes a second address, the second address pointing to a second decryption key corresponding to the second transaction ciphertext stored in the auxiliary blockchain, the second decryption key being submitted to the auxiliary blockchain by the second non-proposal node in response to the consensus proposal; the second transaction ciphertext is decrypted using the second decryption key to obtain the second transaction; and the second transaction is executed. According to one specific implementation, before decrypting the second transaction ciphertext using the second decryption key, the second decryption key can be obtained from the auxiliary blockchain based on the second address. According to another specific implementation, the second decryption key can be obtained from the auxiliary blockchain based on the consensus certificate corresponding to the consensus proposal and the second address. In one example, for instance, a pre-set second contract on the auxiliary blockchain can be invoked based on the consensus certificate corresponding to the consensus proposal and the second address to obtain the second decryption key from the auxiliary blockchain.

[0055] If the consensus proposal includes ciphertext of a transaction but does not include the decryption key address for that transaction, the first non-proposal node may not execute the transaction. Therefore, according to another implementation, the consensus proposal may also include a third ciphertext of a transaction; if the consensus proposal does not include the decryption key address corresponding to the third ciphertext, the first non-proposal node will not execute the transaction corresponding to the third ciphertext.

[0056] According to another embodiment, a consensus method for blockchain transactions is also provided. Figure 6 This is a flowchart of a consensus method for blockchain transactions in one embodiment of this specification. The blockchain includes multiple nodes participating in the consensus process, including a consensus proposal node and several non-proposal nodes. The method is executed by the consensus proposal node, as follows: Figure 6 As shown, the method includes the following steps S61-S65. These will be described in detail below. Figure 6 The steps shown.

[0057] Step S61: Receive multiple transaction ciphertexts corresponding to multiple transactions.

[0058] According to one implementation, multiple transaction ciphertexts corresponding to multiple transactions and multiple node signatures corresponding to the multiple transaction ciphertexts can be received.

[0059] Step S63: Generate a consensus pre-proposal, wherein the consensus proposal includes the plurality of transaction ciphertexts.

[0060] In the above-described implementation of receiving transaction ciphertexts, i.e., their signatures, a consensus proposal can be generated for the plurality of transactions. The consensus proposal includes the plurality of transaction ciphertexts and the plurality of node signatures corresponding to the plurality of transaction ciphertexts respectively.

[0061] Step S65: Send the consensus pre-proposal to each non-proposal node.

[0062] After sending a consensus pre-proposal, according to one implementation, the system may also receive pre-proposal response information from each non-proposal node in response to the consensus pre-proposal, the pre-proposal response information including the storage address in the auxiliary blockchain of the decryption key of the transaction forwarded by the non-proposal node to the consensus proposal node in the plurality of ciphertexts; generate a consensus proposal, the consensus proposal including the plurality of ciphertexts and the storage address in the auxiliary blockchain of the decryption key of each of the plurality of ciphertexts; and send the consensus proposal to each non-proposal node.

[0063] The following examples illustrate the role of the blockchain transaction consensus scheme provided in the embodiments of this specification through several specific application scenarios. In one scenario, if an attacker controls the consensus proposal node, they directly send a transaction request intended for priority execution to the proposal node. The proposal node then places the transaction directly into the consensus pre-proposal. Since this transaction is not forwarded by any non-proposal node other than the consensus proposal node, no non-proposal node will provide its decryption key address upon receiving the consensus pre-proposal. In other words, the non-proposal nodes will not save the decryption key of this transaction to the auxiliary blockchain. Consequently, the proposal node cannot simultaneously provide the key address of the transaction in the consensus proposal, and the non-proposal nodes will not execute this transaction. In another scenario, if an attacker controls the consensus proposal node and sends a transaction request intended for priority execution to both the consensus proposal node and a non-proposal node, the non-proposal node forwards the encrypted ciphertext of the transaction to the consensus proposal node (the decryption key of which is determined by the non-proposal node). Therefore, the proposal node finds it difficult to determine which transaction from the non-proposal node should be treated differently based on the transactions it receives, thus making it difficult to achieve unfairness between transactions. In another application scenario, what if an attacker gains control of a non-proposal node? The attacker directly sends transaction requests intended for priority execution to the non-proposal node they control. This non-proposal node guarantees the attacker's priority in transaction forwarding by waiting for the attacker's transaction requests for a predetermined period and refusing to forward transaction requests from other users to the proposal node. However, in this scenario, because the attacker cannot control other non-proposal nodes (i.e., cannot control the transactions forwarded by other non-proposal nodes) nor the proposal node responsible for transaction ordering, the attacker still cannot control the order of the transactions they send in the final executed transactions.

[0064] According to another embodiment, a consensus device for blockchain transactions is also provided. Figure 7 This is an architectural diagram of a consensus device for blockchain transactions according to one embodiment of this specification. The blockchain includes multiple nodes participating in the consensus process, including a consensus proposal node and a first non-proposal node, such as... Figure 7 As shown, the device 700 is deployed on the first non-proposal node, and the device 700 includes:

[0065] The transaction receiving unit 71 is configured to receive a first transaction, encrypt the first transaction, and obtain the first transaction ciphertext.

[0066] The ciphertext sending unit 72 is configured to send the first transaction ciphertext to the consensus proposal node;

[0067] The consensus pre-proposal receiving unit is configured to receive consensus pre-proposals from the consensus proposal node;

[0068] The key sending unit 74 is configured to, when the consensus pre-proposal includes the first transaction ciphertext, submit a first decryption key of the first transaction ciphertext to the auxiliary blockchain for decrypting the first transaction ciphertext; and send the first address of the first decryption key stored in the auxiliary blockchain to the consensus proposal node.

[0069] According to another embodiment, a consensus device for blockchain transactions is also provided. Figure 8 This is an architectural diagram of a consensus device for blockchain transactions according to another embodiment of this specification. The blockchain includes multiple nodes participating in the consensus process, including a consensus proposal node and several non-proposal nodes, such as... Figure 8 As shown, the device 800 is deployed on the consensus proposal node, and the device 800 includes:

[0070] The transaction ciphertext receiving unit 81 is configured to receive multiple transaction ciphertexts corresponding to multiple transactions;

[0071] A consensus pre-proposal generation unit is configured to generate a consensus pre-proposal, wherein the consensus proposal includes the plurality of transaction ciphertexts;

[0072] The consensus pre-proposal sending unit is configured to send the consensus pre-proposal to each non-proposal node.

[0073] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0074] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements any of the methods described above.

[0075] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0076] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0077] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0078] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0079] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, 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, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0080] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0081] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0082] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0084] 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.

[0085] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0086] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented 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.

[0087] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0088] 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 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.

[0089] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A consensus method for blockchain transactions, wherein the blockchain includes multiple nodes participating in consensus, the multiple nodes including a consensus proposal node and a first non-proposal node, the method being executed by the first non-proposal node, the method comprising: Receive the first transaction, encrypt the first transaction, and obtain the ciphertext of the first transaction; Send the first transaction ciphertext to the consensus proposal node; Receive consensus pre-proposals from the consensus proposal node; When the consensus pre-proposal includes the first transaction ciphertext, a first decryption key for the first transaction ciphertext is submitted to the auxiliary blockchain for decryption of the first transaction ciphertext. The first address of the first decryption key stored in the auxiliary blockchain is sent to the consensus proposal node to generate a consensus proposal.

2. The method according to claim 1, wherein, Submitting the first decryption key of the first transaction ciphertext to the auxiliary blockchain includes: invoking a pre-defined first contract on the auxiliary blockchain and submitting the hash value of the first transaction ciphertext and the first decryption key to the auxiliary blockchain.

3. The method according to claim 1, wherein, Submitting the first decryption key of the first transaction ciphertext to the auxiliary blockchain includes submitting the hash value of the first transaction ciphertext and the first decryption key to the auxiliary blockchain.

4. The method according to claim 1, wherein, Submitting the first decryption key to the first ciphertext of the first transaction to the auxiliary blockchain includes: submitting the hash value of the first ciphertext of the first transaction to the auxiliary blockchain, a first signature of the first ciphertext of the first transaction generated using the node's private key, and the first decryption key.

5. The method according to claim 1, wherein, The plurality of nodes also includes a second non-proposal node, and the method further includes: Receive a consensus proposal from a consensus proposal node; the consensus proposal includes a second address, which points to a second decryption key corresponding to the second transaction ciphertext stored in the auxiliary blockchain, and the second decryption key is submitted to the auxiliary blockchain by a second non-proposal node in response to the consensus pre-proposal; The second transaction ciphertext is decrypted using the second decryption key to obtain the second transaction; Execute the second transaction.

6. The method according to claim 5, wherein, The consensus proposal also includes a third transaction ciphertext; The method further includes: If the consensus proposal does not include the decryption key address corresponding to the third transaction ciphertext, the transaction corresponding to the third transaction ciphertext will not be executed.

7. The method according to claim 5, wherein, Before using the second decryption key to decrypt the second transaction ciphertext, the process also includes, The second decryption key is obtained from the auxiliary blockchain based on the second address.

8. The method according to claim 7, wherein, Based on the second address, obtain the second decryption key from the auxiliary blockchain, including: Based on the consensus credential corresponding to the consensus proposal and the second address, the second decryption key is obtained from the auxiliary blockchain.

9. A consensus method for blockchain transactions, wherein the blockchain includes multiple nodes participating in consensus, the multiple nodes including a consensus proposal node and several non-proposal nodes, the method being executed by the consensus proposal node, the method comprising: Receive multiple ciphertexts corresponding to multiple transactions; Generate a consensus pre-proposal, wherein the consensus pre-proposal includes the plurality of transaction ciphertexts; Send the consensus pre-proposal to each non-proposal node; Receive pre-proposal response information sent by each non-proposal node in response to the consensus pre-proposal, wherein the pre-proposal response information includes the storage address in the auxiliary blockchain of the decryption key of the transaction forwarded by the non-proposal node to the consensus proposal node in the plurality of transaction ciphertexts; Generate a consensus proposal, which includes the plurality of ciphertexts of transactions and the storage address of the decryption key of each of the plurality of ciphertexts in the auxiliary blockchain; The consensus proposal is sent to each non-proposal node.

10. A consensus device for blockchain transactions, wherein the blockchain includes multiple nodes participating in consensus, the multiple nodes including a consensus proposal node and a first non-proposal node, the device being deployed on the first non-proposal node, the device comprising: The transaction receiving unit is configured to receive a first transaction, encrypt the first transaction, and obtain the first transaction ciphertext. The encrypted sending unit is configured to send the first transaction encrypted message to the consensus proposal node; The consensus pre-proposal receiving unit is configured to receive consensus pre-proposals from the consensus proposal node; The key submission unit is configured to submit a first decryption key of the first transaction ciphertext to the auxiliary blockchain when the consensus pre-proposal includes the first transaction ciphertext, for use in decrypting the first transaction ciphertext; The first address of the first decryption key stored in the auxiliary blockchain is sent to the consensus proposal node to generate a consensus proposal.

11. A consensus device for blockchain transactions, wherein the blockchain includes multiple nodes participating in consensus, the multiple nodes include a consensus proposal node and several non-proposal nodes, the device being deployed at the consensus proposal node, the device comprising: The transaction ciphertext receiving unit is configured to receive multiple transaction ciphertexts corresponding to multiple transactions. A consensus pre-proposal generation unit is configured to generate a consensus pre-proposal, wherein the consensus pre-proposal includes the plurality of transaction ciphertexts; The consensus pre-proposal sending unit is configured to send the consensus pre-proposal to each non-proposal node; The consensus pre-proposal sending unit is further configured to receive pre-proposal response information from each non-proposal node in response to the consensus pre-proposal sending, wherein the pre-proposal response information includes the storage address in the auxiliary blockchain of the decryption key of the transaction forwarded by the non-proposal node to the consensus proposal node in the plurality of transaction ciphertexts; Generate a consensus proposal, which includes the plurality of ciphertexts of transactions and the storage address of the decryption key of each of the plurality of ciphertexts in the auxiliary blockchain; The consensus proposal is sent to each non-proposal node.

12. A computer-readable storage medium having a computer program or instructions stored thereon, which, when executed in a computer, cause the computer to perform the method of any one of claims 1-9.

13. A computing device comprising a memory and a processor, wherein the memory stores a computer program or instructions, and the processor, when executing the computer program or instructions, implements the method of any one of claims 1-9.

Images