Transaction broadcasting method in blockchain system and blockchain node

Abstract

The specification provides a transaction broadcast method in a blockchain system and a blockchain node, the blockchain system comprising a first node and a plurality of second nodes; the method comprising: the first node receiving a first transaction, encrypting the first transaction by using a preset symmetric key to obtain ciphertext data; the first node broadcasting transaction data to the plurality of second nodes; the transaction data comprising the ciphertext data and not comprising authentication data generated by the first node for the first transaction; each of the second nodes storing the symmetric key; each of the second nodes decrypting the ciphertext data by using the symmetric key to obtain the first transaction.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of blockchain, and in particular, to a transaction broadcasting method in a blockchain system and a blockchain node. BACKGROUND

[0002] Blockchain is a new application mode of distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain, data blocks are combined into a chain-like data structure in a time sequence, and the data blocks are guaranteed to be unalterable and unforgeable by means of cryptography. Due to the characteristics of decentralization, information unalterability, and autonomy, the blockchain has attracted more and more attention and application.

[0003] At present, an efficient transaction broadcasting method is needed. SUMMARY

[0004] One or more embodiments of the present specification provide a transaction broadcasting method in a blockchain system and a blockchain node.

[0005] According to a first aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method comprising:

[0006] The first node receives a first transaction, encrypts the first transaction by using a preset symmetric key, and obtains ciphertext data;

[0007] The first node broadcasts transaction data to the plurality of second nodes; the transaction data comprises the ciphertext data and does not comprise authentication data generated by the first node for the first transaction; each of the second nodes stores the symmetric key;

[0008] Each of the second nodes decrypts the ciphertext data by using the symmetric key, and obtains the first transaction.

[0009] According to a second aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method is executed by the first node; the method comprising:

[0010] Receiving a first transaction, encrypting the first transaction by using a preset symmetric key, and obtaining ciphertext data;

[0011] Broadcasting transaction data to the plurality of second nodes, the transaction data comprising the ciphertext data and not comprising authentication data generated by the first node for the first transaction.

[0012] According to a third aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method is performed by a second node; the method comprises:

[0013] receiving transaction data broadcasted by the first node, the transaction data comprising ciphertext data and not comprising authentication data generated by the first node for the first transaction; the ciphertext data being obtained by encrypting the first transaction with a preset symmetric key; the second node storing the symmetric key;

[0014] decrypting the ciphertext data using the symmetric key to obtain the first transaction.

[0015] According to a fourth aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method comprises:

[0016] the first node receiving a first transaction;

[0017] the first node broadcasting transaction data to the plurality of second nodes; the transaction data comprising plaintext data of the first transaction and not comprising authentication data generated by the first node for the first transaction.

[0018] According to a fifth aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method is performed by the first node; the method comprises:

[0019] receiving a first transaction;

[0020] broadcasting transaction data to the plurality of second nodes; the transaction data comprising plaintext data of the first transaction and not comprising authentication data generated by the first node for the first transaction;

[0021] broadcasting a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes; the consensus proposal comprising a hash value corresponding to the first transaction.

[0022] According to a sixth aspect, a transaction broadcasting method in a blockchain system is provided, the blockchain system comprising a first node and a plurality of second nodes; the method is performed by a second node; the method comprises:

[0023] receiving transaction data broadcasted by the first node; the transaction data comprising plaintext data of a first transaction and not comprising authentication data generated by the first node for the first transaction;

[0024] receive a consensus proposal broadcasted by the first node and authentication data corresponding to the consensus proposal; the consensus proposal comprises a hash value corresponding to the first transaction;

[0025] verify the authentication data corresponding to the consensus proposal to verify the consensus proposal.

[0026] According to a seventh aspect, a blockchain node is provided, the blockchain node being a first node comprised in a blockchain system, the blockchain system further comprising a plurality of second nodes; the first node comprises:

[0027] a receiving module, configured to receive a first transaction and encrypt the first transaction by using a preset symmetric key to obtain ciphertext data;

[0028] a broadcasting module, configured to broadcast transaction data to the plurality of second nodes, the transaction data comprising the ciphertext data and not comprising authentication data generated by the first node for the first transaction.

[0029] According to an eighth aspect, a blockchain node is provided, the blockchain node being a second node comprised in a blockchain system, the blockchain system further comprising a first node; the second node comprises:

[0030] a receiving module, configured to receive transaction data broadcasted by the first node, the transaction data comprising ciphertext data and not comprising authentication data generated by the first node for the first transaction; the ciphertext data being obtained by encrypting the first transaction by using a preset symmetric key; the second node storing the symmetric key;

[0031] a decrypting module, configured to decrypt the ciphertext data by using the symmetric key to obtain the first transaction.

[0032] According to a ninth aspect, a blockchain node is provided, the blockchain node being a first node comprised in a blockchain system, the blockchain system further comprising a plurality of second nodes; the first node comprises:

[0033] a receiving module, configured to receive a first transaction;

[0034] a first broadcasting module, configured to broadcast transaction data to the plurality of second nodes; the transaction data comprising plaintext data of the first transaction and not comprising authentication data generated by the first node for the first transaction;

[0035] a second broadcasting module, configured to broadcast a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes; the consensus proposal comprising a hash value corresponding to the first transaction.

[0036] According to a tenth aspect, a blockchain node is provided, the blockchain node being a second node comprised in a blockchain system, the blockchain system further comprising a first node; the second node comprising:

[0037] a first receiving module configured to receive transaction data broadcasted by the first node; the transaction data comprising plaintext data of a first transaction and not comprising authentication data generated by the first node for the first transaction;

[0038] a second receiving module configured to receive a consensus proposal broadcasted by the first node and authentication data corresponding to the consensus proposal; the consensus proposal comprising a hash value corresponding to the first transaction;

[0039] a verifying module configured to verify the authentication data corresponding to the consensus proposal to verify the consensus proposal.

[0040] According to an eleventh aspect, a computer readable storage medium is provided, the storage medium storing a computer program, the computer program being executed by a processor to implement the method of any one of the first aspect.

[0041] According to a twelfth aspect, a computing device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor implementing the method of any one of the first aspect when executing the program.

[0042] The technical solutions provided by the embodiments of the present specification can include the following beneficial effects:

[0043] The transaction broadcasting method and the blockchain node provided by the embodiments of the present specification can broadcast transaction data corresponding to a transaction to other blockchain nodes after receiving the transaction, and the transaction data does not comprise authentication data generated by a first node for the transaction. Therefore, other blockchain nodes do not need to authenticate the received transaction, effectively reducing the consumption of computing resources and time overhead, thereby improving the performance of the blockchain system.

[0044] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings required in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0046] Figure 1 is a block chain architecture diagram to which embodiments of the present specification apply;

[0047] Figure 2 is a consensus process schematic diagram of a PBFT consensus algorithm in the related art;

[0048] Figure 3 is a process schematic diagram of transaction broadcasting in a block chain according to an exemplary embodiment;

[0049] Figure 4 is an interaction flow diagram of a transaction broadcasting method in a block chain system according to an exemplary embodiment;

[0050] Figure 5 is a device block diagram of a block chain node according to an exemplary embodiment of the present specification;

[0051] Figure 6 is another device block diagram of a block chain node according to an exemplary embodiment of the present specification;

[0052] Figure 7 is another device block diagram of a block chain node according to an exemplary embodiment of the present specification;

[0053] Figure 8 is another device block diagram of a block chain node according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0054] In order to make the technical personnel in the art better understand the technical solutions in the present specification, the technical solutions in the present specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the present specification. Obviously, the described embodiments are only part of the embodiments of the present specification, not all embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the present specification.

[0055] Blockchain is generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and consortium chain (Consortium Blockchain). In addition, there are various combinations, such as private chain + consortium chain, consortium chain + public chain, and different combination forms. Among them, the highest degree of decentralization is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the right to account for new blocks through consensus. In the private chain, the write permission of the network is controlled by an organization or institution, and the data reading permission is subject to organizational regulations. Consortium chain is a blockchain between public chain and private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; participants join the network by authorization and form an interest-related consortium to jointly maintain the operation of the blockchain.

[0056] As shown in Figure 1 , it is a blockchain architecture diagram to which the embodiments of the present specification apply.

[0057] In Figure 1 the blockchain architecture diagram, the blockchain includes, for example, 8 nodes including node 1 to node 8. The connection between the nodes schematically represents a P2P (Peer to Peer) connection. The nodes can store the full amount of the ledger, that is, store all blocks and the state of all accounts. Among them, each node in the blockchain can produce the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database. Any node can receive a transaction from a client and initiate a consensus proposal to other nodes, which includes, for example, multiple transactions in a block to be chunked (such as block B1) and the submission order of each transaction and other information. After the nodes in the blockchain reach a consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.

[0058] It can be understood that Figure 1 although the blockchain includes 8 nodes, the embodiments of the present specification are not limited thereto, but can include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as that there can be Byzantine nodes inside the blockchain, and the blockchain does not embody Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes (i.e. malicious nodes), for example, Practical Byzantine Fault Tolerance (PBFT).

[0059] A transaction in the field of blockchain can refer to a unit of task performed in and recorded in a blockchain. A transaction usually includes a sending field (From), a receiving field (To) and a data field (Data). Among them, in the case of a transaction being a transfer transaction, the From field represents the account address that initiates the transaction (i.e. initiates the task of transferring funds to another account), the To field represents the account address that receives the transaction (i.e. receives the transfer), and the Data field includes the amount of the transfer. In the case of a transaction calling a smart contract in the blockchain, the From field represents the account address that initiates the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the input parameters of the function, etc., for obtaining the code of the function from the blockchain and executing the code of the function when the transaction is executed.

[0060] One of the decentralized features that distinguishes blockchain technology from traditional technology is that accounting is performed on each node, or distributed accounting, rather than traditional centralized accounting. In order for a blockchain system to become a decentralized honest and trustworthy system that is difficult to attack, public and tamper-proof data record, it needs to achieve secure, clear and irreversible distributed data record in the shortest possible time. In different types of blockchain networks, in order to maintain consistency of the ledger among the nodes that record the ledger, a consensus algorithm is usually used to ensure it, i.e. the aforementioned consensus mechanism.

[0061] For example, a block granularity consensus mechanism can be implemented between blockchain nodes, such as when a node (e.g. a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism can be implemented between blockchain nodes, such as when a node (e.g. a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction can add the blockchain transaction to the latest block it maintains, and ultimately ensure that the same latest block is generated by each node. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the network, which can ensure that the latest block is accurately added to the blockchain.

[0062] The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among various consensus algorithms, the consensus is usually determined to be successful after a preset number of nodes agree on the data to be consensus (i.e. consensus proposal). Specifically, in the PBFT algorithm, for N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f+1 nodes among the N consensus nodes agree, the consensus is determined to be successful.

[0063] Figure 2 A schematic diagram of a consensus process of a PBFT consensus algorithm in the related art.

[0064] As shown in Figure 2 According to the PBFT consensus algorithm, the complete consensus process can be divided into four stages: Request, Pre-Prepare, Prepare and Commit. Assuming that a blockchain includes four consensus nodes: node n1-node n4, according to the PBFT algorithm, f=1 malicious node can be tolerated in node n1-node n4.

[0065] Specifically, in the request stage, a user of the blockchain can send a request to node n1 through his user device, and the request is in the form of a blockchain transaction for example. Node n1 can receive multiple transactions from one or more user devices, and store the received transactions in a transaction queue. In the pre-preparation stage, node n1 can take multiple transactions belonging to a block from the transaction queue, and generate a consensus proposal for the multiple transactions, and broadcast the consensus proposal and the authentication data (such as digital signature, etc.) generated by node n1 for the consensus proposal to other consensus nodes (i.e. node n2-node n4), so that the consensus nodes continue to consensus on the block. The consensus proposal may, for example, include information such as the transaction body of the multiple transactions and the execution order of the multiple transactions.

[0066] In the preparation stage, each slave node can generate authentication data for the consensus proposal and send it to other nodes. Assuming that node n4 is a malicious node, after node n1, node n2 and node n3 respectively receive 2f=2 authentication data of other consensus nodes for the consensus proposal, they can determine that the preparation stage is complete, and can enter the commit stage. For example, as shown in Figure 2As shown in FIG. 1, after receiving the authentication data of node n2 and node n3, node n1 verifies that the authentication data of node n2 and node n3 are both correct, and determines that the preparation phase is completed. After receiving the authentication data of node n3 and the authentication data of node n1 in the preparation phase and verifying that the authentication data are correct, node n2 determines that the preparation phase is completed.

[0067] In the submission phase, each consensus node generates authentication data of the submission phase for the consensus proposal and sends the authentication data to other consensus nodes. After receiving the authentication data of the submission phase from 2f = 2 other consensus nodes, each consensus node can determine that the submission phase is completed and the consensus is successful. For example, after receiving the authentication data of the submission phase of node n2 and node n3 and verifying the authentication data, node n1 determines that the submission phase is completed. Thus, node n1 can update the world state according to the execution result of the plurality of transactions, generate and store a block (for example, block B1) including the plurality of transactions, and return the execution result of the plurality of transactions to the user device. Similarly, after determining that the submission phase is completed, node n2 and node n3 execute the plurality of transactions, generate and store block B1, and update the world state according to the execution result of the plurality of transactions.

[0068] Through the above process, the storage consistency of node n1, node n2 and node n3 is achieved. That is, node n1-n4 can still achieve consensus success of the consensus proposal and complete execution of the block in the presence of one malicious node.

[0069] It should be noted that in the above consensus process, information needs to be transmitted between nodes, and the transmitted information needs to be authenticated, that is, the authentication data is generated by the information sender, and the authentication data is verified by the information receiver. Specifically, the authentication method can include but is not limited to digital signature authentication, TLS authentication, symmetric message authentication, etc.

[0070] The process of digital signature authentication can include that the information sender uses its own private key to digitally sign the hash digest of the transmitted information, and sends the transmitted information and the digital signature to the information receiver. The information receiver verifies the digital signature using the public key of the information sender.

[0071] The process of TLS authentication can include that the information sender establishes a TLS connection with each information receiver, and pre-negotiates a corresponding symmetric key with each information receiver (the symmetric keys corresponding to different information receivers are also different). The information sender encrypts the transmitted information using the corresponding symmetric key for each information receiver, and transmits the encrypted data to the corresponding information receiver. The information receiver decrypts the received information using the symmetric key to complete the authentication.

[0072] The process of symmetric message authentication can involve the sender and each receiver pre-negotiating a symmetric key (different receivers use different symmetric keys). For each receiver, the sender uses the corresponding symmetric key to encrypt the hash digest of the transmitted message, obtaining an authentication code for that receiver, thus generating an authentication vector. The sender broadcasts the transmitted message and the authentication vector to all receivers. Each receiver retrieves its corresponding authentication code from the authentication vector and uses it to verify the hash digest of the transmitted message.

[0073] Therefore, in the aforementioned related technologies, the consensus proposal includes information such as the transaction bodies of multiple transactions. Since the data volume of the transaction bodies of multiple transactions is huge, regardless of which authentication method is used, the authentication process of the consensus proposal will consume a large amount of computing resources and generate a huge time overhead.

[0074] This specification provides an embodiment of... Figure 1 The scheme of broadcasting transactions in the blockchain shown can improve the performance of the blockchain system by allowing nodes to directly broadcast transactions to other nodes after receiving them from users. This effectively reduces the consumption of computing resources and time overhead.

[0075] Figure 3 This is a schematic diagram illustrating a transaction broadcasting process in a blockchain according to an exemplary embodiment.

[0076] like Figure 3 As shown, suppose a blockchain includes four consensus nodes, n1 to n4, and can tolerate f = 1 malicious nodes among nodes n1 to n4. Specifically, a user of the blockchain can send a request, for example, in the form of a blockchain transaction, to node n1 through their user device. After receiving transaction Tx1 from the user device, node n1, in addition to storing transaction Tx1 in the transaction queue, can encrypt transaction Tx1 using a symmetric key K if confidentiality is required, obtaining ciphertext data. Then, node n1 broadcasts the transaction data carrying the ciphertext data to the other consensus nodes (i.e., nodes n2 to n4). If there is no confidentiality requirement, node n1 can directly broadcast the transaction data carrying transaction Tx1 to the other consensus nodes. It should be noted that the transaction data broadcast by node n1 to the other consensus nodes does not include authentication data. After receiving the transaction data, the other consensus nodes do not need to authenticate the received transaction data.

[0077] After receiving transaction data, each node can decrypt the ciphertext data using the symmetric key K if the transaction data carries ciphertext data, thus obtaining transaction Tx1. Alternatively, if the transaction data includes transaction Tx1, it can be directly retrieved. Each node stores transaction Tx1 and its hash value in a transaction queue, associating them.

[0078] During the consensus phase, node n1 can select multiple transactions belonging to a block from the transaction queue, such as transaction Tx1, and generate a consensus proposal corresponding to these transactions. This proposal can include the execution order of the transactions and a list of their hash values. Then, node n1 broadcasts the consensus proposal and the authentication data (e.g., digital signatures) generated for it to nodes n2-n4, enabling them to vote on the block. It's important to note that because node n1 has already broadcast these transactions to other consensus nodes after receiving them, the consensus proposal does not include the transaction bodies (e.g., the transaction body of transaction Tx1). After nodes n2-n4 verify the authentication data of the consensus proposal, they can further conduct consensus voting. After the consensus voting is complete, the transactions including transaction Tx1 are sequentially retrieved from the pre-stored transaction queue and executed according to the execution order and hash value list included in the consensus proposal, generating the corresponding block.

[0079] Assuming node n4 is a malicious node, it impersonates node n1 and broadcasts transaction TXF to other nodes. While other nodes can receive the transaction TXF and store it in their transaction queues, they also need to authenticate the consensus proposal broadcast by node n1. Therefore, node n4 cannot impersonate node n1 to broadcast a consensus proposal including the hash value of the transaction TXF, nor can it tamper with the consensus proposal already broadcast by node n1. Other nodes will not execute the transaction TXF, so the malicious node cannot interfere with the normal operation of the blockchain system.

[0080] In this embodiment, after receiving a transaction, a blockchain node broadcasts the corresponding transaction data to other blockchain nodes, and this transaction data does not include the authentication data corresponding to the transaction. Therefore, other blockchain nodes do not need to authenticate the received transaction, effectively reducing the consumption of computing resources and time overhead, thereby improving the performance of the blockchain system.

[0081] The solutions provided in this specification will be described in detail below with reference to specific embodiments.

[0082] like Figure 4 As shown, Figure 4is an interaction flow chart of a transaction broadcasting method in a blockchain system according to an exemplary embodiment. The blockchain system includes a node A and a plurality of nodes B. Any node in the blockchain system can be implemented as any device, platform, server or device cluster with computing and processing capability. The method includes the following steps:

[0083] In step 401, the user device sends a transaction Txa to the node A, in step 403, the node A broadcasts transaction data corresponding to the transaction Txa to the nodes B, and in step 405, the nodes B obtain the transaction Txa based on the transaction data and store the transaction Txa in a transaction queue.

[0084] In one case, the nodes in the blockchain system can pre-negotiate a same symmetric key K. It is worth noting that all nodes can share the same symmetric key K, and the symmetric key K is stored in each node in the blockchain system. After receiving the transaction Txa sent by the user device, the node A can encrypt the transaction Txa using the symmetric key K to obtain ciphertext data. Then, the node A broadcasts transaction data corresponding to the transaction Txa to the nodes B, the transaction data includes the ciphertext data and does not include authentication data corresponding to the transaction Txa. Since each node B stores the symmetric key K, each node B can decrypt the ciphertext data using the symmetric key K to obtain the transaction Txa, and store the transaction Txa in the transaction queue, and does not need to authenticate the transaction Txa.

[0085] In another case, after receiving the transaction Txa sent by the user device, the node A can directly broadcast transaction data corresponding to the transaction Txa to the nodes B, the transaction data includes plaintext data of the transaction Txa and does not include authentication data corresponding to the transaction Txa. Each node B can directly store the transaction Txa in the transaction queue without authenticating the transaction Txa.

[0086] It should be noted that the authentication data corresponding to the transaction Txa can include but is not limited to digital signature, authentication code, etc.

[0087] In step 407, the node A broadcasts a consensus proposal and authentication data corresponding to the consensus proposal to the nodes B.

[0088] In this embodiment, after accumulating a plurality of transactions, in the consensus stage, the node A first selects a plurality of transactions from the transaction queue, the plurality of transactions including the transaction Txa. A consensus proposal corresponding to the plurality of transactions is generated, the consensus proposal including a hash value corresponding to each transaction in the plurality of transactions and an execution order of the plurality of transactions. Then, the node A generates authentication data corresponding to the consensus proposal, and broadcasts the consensus proposal and its authentication data to the nodes B.

[0089] In step 409, the node B verifies the authentication data corresponding to the consensus proposal to verify the consensus proposal, and in step 411, the node A and the node B obtain the transaction Txa based on the hash value of the transaction Txa after the consensus of the consensus proposal is successful, and execute the transaction Txa.

[0090] In the embodiment, the node B verifies the authentication data first, thereby authenticating and performing consensus on the consensus proposal. After the consensus of the consensus proposal is successful, the node A and the node B obtain the transaction Txa based on the hash value of the transaction Txa, and execute the transaction Txa according to the execution order of the plurality of transactions.

[0091] The above embodiments of the present specification provide a transaction broadcasting method in a blockchain system. After receiving a transaction, a blockchain node broadcasts transaction data corresponding to the transaction to other blockchain nodes, and the transaction data does not include authentication data corresponding to the transaction. Therefore, other blockchain nodes do not need to authenticate the received transaction, effectively reducing the consumption of computing resources and time overhead, thereby improving the performance of the blockchain system.

[0092] It should be noted that although the operations of the methods of the embodiments of the present specification are described in a specific order in the above embodiments, this does not require or imply that the operations must be performed in this specific order, or that all of the illustrated operations must be performed to achieve the desired result. On the contrary, the steps depicted in the flowcharts can change the order of execution. Additionally or alternatively, certain steps can be omitted, a plurality of steps can be combined into one step, and / or one step can be divided into a plurality of steps.

[0093] Corresponding to the foregoing transaction broadcasting method embodiment in the blockchain system, the present specification also provides an embodiment of a transaction broadcasting device in the blockchain system.

[0094] As shown in Figure 5 , Figure 5 is a device block diagram of a blockchain node according to an exemplary embodiment of the present specification. The blockchain node is a first node included in a blockchain system, and the blockchain system further includes a plurality of second nodes. The first node can include a receiving module 501 and a broadcasting module 502.

[0095] The receiving module 501 is configured to receive a first transaction and encrypt the first transaction using a preset symmetric key to obtain ciphertext data.

[0096] The broadcasting module 502 is configured to broadcast transaction data to the plurality of second nodes. The transaction data includes the ciphertext data and does not include authentication data corresponding to the first transaction.

[0097] As shown in Figure 6 ,Figure 6 is a device block diagram of a blockchain node according to an example embodiment, the blockchain node being a second node included in a blockchain system, the blockchain system further including a first node, the second node can include: a receiving module 601 and a broadcasting module 602.

[0098] The receiving module 601 is configured to receive transaction data broadcast by the first node, the transaction data including ciphertext data and not including authentication data corresponding to the first transaction. The ciphertext data is obtained by encrypting the first transaction by using a preset symmetric key, and the second node stores the symmetric key.

[0099] The decryption module 602 is configured to decrypt the ciphertext data by using the symmetric key to obtain the first transaction.

[0100] As shown in Figure 7 , Figure 7 is a device block diagram of a blockchain node according to an example embodiment, the blockchain node being a first node included in a blockchain system, the blockchain system further including a plurality of second nodes, the first node can include: a receiving module 701, a first broadcasting module 702 and a second broadcasting module 703.

[0101] The receiving module 701 is configured to receive the first transaction.

[0102] The first broadcasting module 702 is configured to broadcast transaction data to the plurality of second nodes, the transaction data including plaintext data of the first transaction and not including authentication data corresponding to the first transaction.

[0103] The second broadcasting module 703 is configured to broadcast a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes, the consensus proposal including a hash value corresponding to the first transaction.

[0104] As shown in Figure 8 , Figure 8 is a device block diagram of a blockchain node according to an example embodiment, the blockchain node being a second node included in a blockchain system, the blockchain system further including a first node, the second node can include: a first receiving module 801, a second receiving module 802 and a verification module 803.

[0105] The first receiving module 801 is configured to receive transaction data broadcast by the first node, the transaction data including plaintext data of the first transaction and not including authentication data corresponding to the first transaction.

[0106] The second receiving module 802 is configured to receive a consensus proposal and authentication data corresponding to the consensus proposal broadcast by the first node, the consensus proposal including a hash value corresponding to the first transaction.

[0107] The verification module 803 is configured to verify the authentication data corresponding to the consensus proposal to verify the consensus proposal.

[0108] For the apparatus embodiment, since it basically corresponds to the method embodiment, the relevant part can be seen from the part of the method embodiment. The apparatus embodiment described above is only schematic, and the units shown as separate units can or can not be physically separate, and the units shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of one or more embodiments of the present specification. Those skilled in the art can understand and implement it without creative labor.

[0109] One or more embodiments of the present specification also provide a computer readable storage medium, which stores a computer program, and the computer program can be used to execute the above Figure 4 The embodiment provides a transaction broadcast method in a blockchain system.

[0110] One or more embodiments of the present specification also provide a computing device, which comprises a memory and a processor, the memory stores executable code, and the processor executes the executable code to realize the above Figure 4 The embodiment provides a transaction broadcast method in a blockchain system.

[0111] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, 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, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0112] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that, in addition to being implemented in pure computer readable program code form, the controller can perfectly well be implemented to perform the same functions in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. by means of logical programming of the method steps. Such a controller can thus be considered a hardware component, and the means comprised therein for performing the various functions can also be considered structures within the hardware component. Alternatively, or even, the means for performing the various functions can be considered both software modules implementing the method and structures within the hardware component.

[0113] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not rule out that with the development of future computer technology, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0114] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above description of the embodiments of the present specification is provided as an example only and is not intended to be limiting. For example, the steps recited in the examples or flow charts can include more, fewer, or different steps than those described. The order in which the steps are presented is merely one example and is not intended to be limiting. The steps can be performed in an order different than presented, or performed in parallel, or in a different order, for example in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment. The terms "comprise", "comprising", or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Exclusion of such elements is only present if it is expressly stated that these elements are excluded. For example, use of the terms "first", "second", or the like does not denote any order or importance, but rather the terms are used to distinguish one element from another.

[0115] For ease of description, the above apparatuses are described in various modules with different functions. Of course, when implementing one or more of the present specification, the functions of the modules can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiments are only illustrative, for example, the division of the units is only a logical function division, and in actual implementation, another division mode can be used, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0116] The present application is described with reference to flowcharts and / or block diagrams of methods, apparatus (system) and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one or more flows and / or blocks. Figure 1 The apparatus for implementing the functions specified in one or more flows and / or blocks.

[0117] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0118] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

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

[0120] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory, etc. The memory is an example of computer readable media.

[0121] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0122] Those skilled in the art will appreciate that one or more embodiments of the specification can be provided as methods, systems or computer program products. Accordingly, one or more embodiments of the specification can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the specification can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

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

[0124] Each embodiment in the specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the part of the description of the method embodiments. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the specification. In the specification, the above-mentioned terms are not necessarily used to refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.

[0125] The description of the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the specification. In the specification, the above-mentioned terms are not necessarily used to refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.

[0126] The above-mentioned terms are not necessarily used to refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.

[0127] 0The above-mentioned terms are not necessarily used to refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.

[0128] or more embodiments. Various changes and modifications can be made to one or more embodiments described in the specification within the scope of the claims. Any modifications, equivalent substitutions, improvements, etc. not described in the specification are intended to be included in the scope of the claims.

Claims

1. A method for transaction broadcasting in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; the method comprising: receiving, by the first node, a first transaction, and encrypting the first transaction using a preset symmetric key to obtain ciphertext data, before a consensus phase; broadcasting, by the first node, transaction data to the plurality of second nodes; the transaction data comprising the ciphertext data and not comprising authentication data generated by the first node for the first transaction; each of the second nodes storing the symmetric key; decrypting, by each of the second nodes, the ciphertext data using the symmetric key to obtain the first transaction; wherein the method further comprises: broadcasting, by the first node, a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes during the consensus phase; the consensus proposal comprising a first hash value of the first transaction calculated by the first node; verifying, by the second nodes, the authentication data corresponding to the consensus proposal to verify the consensus proposal.

2. The method of claim 1, wherein, The authentication data comprises a digital signature or a symmetric message authentication code.

3. The method of claim 1, wherein, The method further comprises: after the consensus of the consensus proposal is successful, obtaining, by the first node and the plurality of second nodes, the first transaction based on the first hash value, and executing the first transaction.

4. The method of claim 3, wherein, The method further comprises: calculating, by the second nodes, hash values of transactions received from the first node, wherein the first hash value is included; wherein obtaining, by the second nodes, the first transaction based on the hash value of the first transaction and executing the first transaction comprises determining, by the second nodes, whether the calculated hash values of the transactions include the first hash value, and executing the first transaction in a case where the second hash value is equal to the first hash value.

5. A transaction broadcasting method in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; The method is performed by the first node; the method comprising: receiving a first transaction, and encrypting the first transaction using a preset symmetric key to obtain ciphertext data, before a consensus phase; broadcasting transaction data to the plurality of second nodes; the transaction data comprising the ciphertext data and not comprising authentication data generated by the first node for the first transaction broadcasting, by the first node, a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes during the consensus phase; the consensus proposal comprising a first hash value of the first transaction calculated by the first node, and causing the second nodes to verify the authentication data corresponding to the consensus proposal to verify the consensus proposal.

6. A transaction broadcasting method in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; The method is performed by the second nodes; the method comprising: receiving, by the second nodes, transaction data broadcasted by the first node before a consensus phase; the transaction data comprising ciphertext data, the ciphertext data being obtained by the first node encrypting a first transaction using a preset symmetric key; the ciphertext data not comprising authentication data generated by the first node for the first transaction; the second nodes storing the symmetric key; decrypting, by the second nodes, the ciphertext data using the symmetric key to obtain the first transaction; and In the consensus phase, receiving a consensus proposal broadcast by the first node and authentication data corresponding to the consensus proposal; the consensus proposal comprising a first hash value of the first transaction calculated by the first node; Verifying the authentication data corresponding to the consensus proposal to verify the consensus proposal. 7.A method for broadcasting a transaction in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; the method comprising: Before the consensus phase, the first node receiving a first transaction; The first node broadcasting transaction data to the plurality of second nodes; The transaction data comprising plaintext data of the first transaction and not comprising authentication data generated by the first node for the first transaction; The method further comprising: In the consensus phase, the first node broadcasting a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes; the consensus proposal comprising a first hash value of the first transaction calculated by the first node; The second node verifying the authentication data corresponding to the consensus proposal to verify the consensus proposal.

8. The method of claim 7, wherein, The authentication data comprising a digital signature or a symmetric message authentication code.

9. The method of claim 7, wherein, The method further comprising: After the consensus of the consensus proposal is successful, the first node and the plurality of second nodes obtaining the first transaction based on the first hash value and executing the first transaction.

10. The method of claim 9, wherein, The method further comprising: The second node calculating hash values of respective transactions received from the first node, wherein the second hash value of the first transaction is calculated; The second node obtaining the first transaction based on the hash value of the first transaction and executing the first transaction comprises: the second node determining whether the calculated hash values of the respective transactions comprise the first hash value, and executing the first transaction in a case where the second hash value is equal to the first hash value.

11. A transaction broadcasting method in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; The method is performed by the first node; the method comprising: Before the consensus phase, receiving a first transaction; Before the consensus phase, broadcasting transaction data to the plurality of second nodes; the transaction data comprising plaintext data of the first transaction and not comprising authentication data generated by the first node for the first transaction; In the consensus phase, broadcasting a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes; the consensus proposal comprising a hash value corresponding to the first transaction, so that the second node verifies the authentication data corresponding to the consensus proposal to verify the consensus proposal.

12. A transaction broadcasting method in a blockchain system, the blockchain system comprising a first node and a plurality of second nodes; The method is performed by the second node; the method comprising: Before the consensus phase, receiving transaction data broadcast by the first node; the transaction data comprising plaintext data of a first transaction and not comprising authentication data generated by the first node for the first transaction; In the consensus phase, receiving a consensus proposal broadcast by the first node and authentication data corresponding to the consensus proposal; the consensus proposal comprising a hash value corresponding to the first transaction; Verifying the authentication data corresponding to the consensus proposal to verify the consensus proposal. 13.A blockchain node, the blockchain node being a first node included in a blockchain system, the blockchain system further including a plurality of second nodes; the first node comprising: a receiving module, configured to receive a first transaction before a consensus phase, and encrypt the first transaction by using a preset symmetric key to obtain ciphertext data; a broadcasting module, configured to broadcast transaction data to the plurality of second nodes before the consensus phase, the transaction data including the ciphertext data and excluding authentication data generated by the first node for the first transaction; in the consensus phase, broadcast a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes; the consensus proposal including a first hash value of the first transaction calculated by the first node, so that the second nodes verify the authentication data corresponding to the consensus proposal to verify the consensus proposal. 14.A blockchain node, the blockchain node being a second node included in a blockchain system, the blockchain system further including a first node; the second node comprising: a receiving module, configured to receive transaction data broadcast by the first node before a consensus phase, the transaction data including ciphertext data, the ciphertext data being obtained by encrypting a first transaction by using a preset symmetric key by the first node; the ciphertext data excluding authentication data generated by the first node for the first transaction; the second node storing the symmetric key; in the consensus phase, receive a consensus proposal and authentication data corresponding to the consensus proposal broadcast by the first node; the consensus proposal including a first hash value of the first transaction calculated by the first node; a decryption module, configured to decrypt the ciphertext data by using the symmetric key to obtain the first transaction; a verification module, configured to verify the authentication data corresponding to the consensus proposal to verify the consensus proposal. 15.A blockchain node, the blockchain node being a first node included in a blockchain system, the blockchain system further including a plurality of second nodes; the first node comprising: a receiving module, configured to receive a first transaction before a consensus phase; a first broadcasting module, configured to broadcast transaction data to the plurality of second nodes before the consensus phase; the transaction data including plaintext data of the first transaction and excluding authentication data generated by the first node for the first transaction; a second broadcasting module, configured to broadcast a consensus proposal and authentication data corresponding to the consensus proposal to the plurality of second nodes in the consensus phase; the consensus proposal including a hash value corresponding to the first transaction, so that the second nodes verify the authentication data corresponding to the consensus proposal to verify the consensus proposal. 16.A blockchain node, the blockchain node being a second node included in a blockchain system, the blockchain system further including a first node; the second node comprising: a first receiving module, configured to receive transaction data broadcast by the first node before a consensus phase; the transaction data including plaintext data of a first transaction and excluding authentication data generated by the first node for the first transaction; a second receiving module, configured to receive, in a consensus stage, a consensus proposal broadcast by the first node and authentication data corresponding to the consensus proposal; the consensus proposal comprising a hash value corresponding to the first transaction; a verifying module, configured to verify the authentication data corresponding to the consensus proposal, so as to verify the consensus proposal. 17.A computer readable storage medium, having stored thereon a computer program, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-12. 18.A computing device, comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-12.

Images