A consensus method, device and trusted blockchain system for trusted blockchain

Abstract

One or more embodiments of this specification disclose a consensus method, device and trusted blockchain system for a trusted blockchain, which includes: a block generation node receives a pre-signed block sent by a participating node, and verifies the pre-signed block based on the blockchain account parameters published by the participating node; after the verification is passed, a consensus calculation is performed with a set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target; the random number is added to the pre-signed block, and signed with its own blockchain account parameters to construct a complete signature block. The consensus on the block is achieved based on the pre-signature and the complete signature through the PoW mechanism, and the complete signature of the block is achieved in the TEE to ensure the legitimacy of the block. At the same time, the blockchain account of the block generation node is generated in the TEE, and the computing power cannot be expanded by modifying the TEE program, avoiding illegal increase in computing power, ensuring the security and reliability of the consensus of the trusted blockchain, and reducing resource waste.

Description

Technical Field

[0001] This document relates to the field of blockchain technology, and in particular to a consensus method, device and trusted blockchain system for a trusted blockchain. Background Art

[0002] Blockchain is a decentralized and innovative solution that uses distributed ledger technology to solve multi-party trust issues. It is a cutting-edge technology in today's society.

[0003] There are three main types of blockchains: public chain, consortium chain, and private chain. Among them, the consortium chain is only for members of a specific group and limited third parties. It specifies multiple pre-selected nodes as bookkeepers. The generation of each block is jointly determined by all pre-selected nodes. Other access nodes can participate in transactions, but do not ask about the bookkeeping process. Other third parties can conduct limited queries through the open API of the blockchain.

[0004] Enterprise applications generally use alliance chain systems. Current alliance chain systems generally use consensus mechanisms such as Raft and PBFT. These consensus mechanisms are insufficient in terms of security, resulting in insufficient overall security and credibility of the alliance chain system itself. Summary of the invention

[0005] The purpose of one or more embodiments of this specification is to provide a consensus method, device and trusted blockchain system for a trusted blockchain, so as to ensure the security and reliability of the consensus of the trusted blockchain and reduce resource waste through a consensus solution implemented through legitimacy verification in a TEE environment.

[0006] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0007] In the first aspect, a consensus method of a trusted blockchain is proposed, which is applied to a trusted execution environment TEE that generates a block node. The method includes:

[0008] Receiving a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions;

[0009] Verifying the pre-signed block based on the blockchain account parameters issued by the participating node;

[0010] After verification, consensus calculation is performed with the set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target;

[0011] The random number is added to the pre-signed block and signed using its own blockchain account parameters to construct a complete signature block.

[0012] In the second aspect, a consensus device of a trusted blockchain is proposed, which is applied to a trusted execution environment TEE that generates a block node, and the device includes:

[0013] A receiving module, configured to receive a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions;

[0014] A verification module, configured to verify the pre-signed block based on the blockchain account parameters issued by the participating node;

[0015] A consensus module, which is used to perform consensus calculations with a set computing power according to the difficulty target recorded in the pre-signed block after verification, to obtain a random number that meets the difficulty target;

[0016] The signature module is used to add the random number to the pre-signed block and sign it using its own blockchain account parameters to construct a complete signature block.

[0017] In a third aspect, a trusted blockchain system is proposed, including: a client, a participating node, and a block generating node; wherein the trusted execution environment TEE of the block generating node is deployed with the consensus device of the trusted blockchain described in the second aspect;

[0018] The block generating node receives the pre-signed block sent by the participating node, wherein the pre-signed block is constructed and signed by part of the transactions or all the transactions selected by the participating node from the cached legal transactions; based on the blockchain account parameters released by the participating node, the pre-signed block is verified; after the verification is passed, according to the difficulty target recorded in the pre-signed block, a consensus calculation is performed with the set computing power to obtain a random number that meets the difficulty target; the random number is added to the pre-signed block, and signed with its own blockchain account parameters to construct a complete signature block.

[0019] In a fourth aspect, an electronic device is provided, comprising:

[0020] Processor; and

[0021] A memory arranged to store computer executable instructions, wherein when the executable instructions are executed, the processor executes the consensus method of the trusted blockchain described in the first aspect.

[0022] In a fourth aspect, a computer-readable storage medium is proposed, which stores one or more programs. When the one or more programs are executed by an electronic device including multiple applications, the electronic device executes the consensus method of the trusted blockchain described in the first aspect.

[0023] It can be seen from the technical solutions provided by one or more embodiments of the present specification that consensus calculation is performed on the trusted blockchain through the PoW mechanism. At the same time, the consensus calculation is deployed in the TEE of the block node, and the computing power is pre-set for the consensus calculation in the TEE. Thus, a secure and isolated consensus computing environment is provided through the TEE, and by designing a fixed computing power, malicious 51% attacks are reduced or avoided; the consensus of the trusted blockchain is guaranteed to be secure and reliable, and resource waste is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate one or more embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the description of one or more embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0025] Figure 1 It is a schematic diagram of the overall technical architecture of the trusted blockchain system provided in the embodiments of this specification.

[0026] Figure 2 This is a schematic diagram of the steps of a consensus method for a trusted blockchain provided in an embodiment of this specification.

[0027] Figure 3 It is a structural diagram of a consensus device of a trusted blockchain provided in an embodiment of this specification.

[0028] Figure 4 It is a schematic diagram of the structure of an electronic device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below in conjunction with the drawings in one or more embodiments of this specification. Obviously, the one or more embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on one or more embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this document.

[0030] Considering that the current alliance chain system generally adopts consensus mechanisms such as Raft and PBFT, these consensus mechanisms are insufficient in terms of security. Therefore, the embodiment of this specification proposes a consensus solution based on the Proof of Work (PoW) mechanism.

[0031] Given that PoW is the most secure consensus mechanism in the blockchain system, that is, it has both high fault tolerance (such as downtime of the node generating the block, etc.) and high resistance to malicious attacks (such as dishonest generation of blocks, etc.); the security of other consensus mechanisms such as PoS, Raft, PBFT, etc. is not as good as PoW, and some consensus mechanisms are completely incapable of resisting malicious attacks, such as Raft. Therefore, the consensus mechanism in the embodiments of this specification uses the PoW mechanism with higher security, and uses the characteristics of the PoW mechanism that is difficult to calculate and easy to verify to perform consensus calculations on blocks.

[0032] The core of the PoW mechanism is that the hash value of a legal block should be less than the random value converted by setting a difficulty target through a certain mechanism. The hash algorithm is a one-way cryptographic algorithm that can only calculate its hash value based on the original data, and cannot reversely calculate the original data through the hash value. Therefore, under the PoW mechanism, to obtain a legal block, you can try to calculate the block hash value by continuously adjusting the block itself, and then determine whether it meets the difficulty target. The usual practice is to continuously jump to a random number in the block data structure until a random number is found that makes the hash value of the entire block meet the difficulty target.

[0033] From the above working principle of PoW, we can know that if we want to generate blocks faster, we must have a faster hash algorithm operation speed, that is, computing power. Therefore, the competition for block generation between block generation nodes has fundamentally become a competition for their computing power. If the computing power of a certain block generation node occupies the vast majority of the total computing power in the blockchain system, the probability of the block generation node successfully generating a block is much greater than that of other block generation nodes. At the same time, this block generation node can control the transactions contained in the block and even recalculate the historical block. Therefore, there is a risk of 51% attack in the PoW mechanism. At the same time, since computing power fundamentally consumes electricity, computing power competition will also bring about the problem of resource waste.

[0034] Since the public chain system is larger, its total computing power is also greater, and the computing power cost of a 51% attack is relatively much higher. However, the alliance chain system is small in scale, and its total computing power is generally very small. If the PoW consensus mechanism is directly adopted without enhancing the credibility and security, it is very vulnerable to a 51% attack.

[0035] To this end, the embodiments of this specification, while introducing the PoW mechanism to perform consensus calculations on the trusted blockchain, further deploy the consensus calculations in the TEE that generates the block node, and pre-set the computing power for the consensus calculations in the TEE, thereby providing a secure and isolated consensus computing environment through the TEE, and reducing or avoiding malicious 51% attacks by designing a fixed computing power.

[0036] First, refer to Figure 1 As shown, the overall technical architecture of the trusted blockchain system provided by the embodiments of this specification is introduced. The trusted blockchain system may include multiple subjects, which can be divided into three types according to functional deployment: participating nodes, block generation nodes, and clients. It should be understood that as the functions that can be realized increase or subdivided, the trusted blockchain system can define or divide more functional types of subjects, and the embodiments of this specification are not limited to this.

[0037] The following is a brief introduction to the functions of each subject in the embodiments of this specification.

[0038] Participating nodes: They are the core nodes that constitute the blockchain network. They are mainly used to receive transactions generated by clients or forwarded by other participating nodes, and cache or forward transactions to other participating nodes after verification. At the same time, they can build pre-signed blocks and send them to the block-generating nodes, receive complete blocks processed and signed by the block-generating nodes, or complete blocks forwarded by other participating nodes, and store or forward complete blocks to other participating nodes after verification. Furthermore, they provide clients with various interfaces for accessing the blockchain network, such as read-type interfaces, write-type interfaces, etc.

[0039] Block generating node: It is also the core node of the blockchain network. It is mainly used to receive and verify the pre-signed blocks sent by the participating nodes. At the same time, it performs consensus calculations on the verified pre-signed blocks, constructs complete blocks and signs them. After that, it returns the complete blocks to the participating nodes.

[0040] Client: Mainly used to generate and sign transactions; send signed transactions to participating nodes; call the blockchain access interface provided by participating nodes according to business needs to achieve the required business capabilities.

[0041] In the trusted blockchain system involved in the embodiments of this specification, system-level smart contracts and business-level smart contracts may be included; wherein, the system-level smart contract refers to the smart contract built into the genesis block or in the node, rather than the smart contract deployed by the client. System-level smart contracts are mainly used for the management of trusted blockchain systems. From the perspective of management scope, they can be divided into at least three types: account management, cryptographic parameter management, and alliance management. Therefore, system-level smart contracts can also be subdivided into: system-level account management smart contracts, system-level cryptographic parameter management smart contracts, and system-level alliance management smart contracts. Business-level smart contracts are smart contracts deployed by the client, mainly involving contract parameters related to business transactions.

[0042] In general, one or more allowed behaviors can be configured for each subject through the system-level account management smart contract. In the embodiment of this specification, for the participating nodes, the "read" behavior permission can be configured to facilitate access to the blockchain network; in fact, the "generate block" behavior permission can also be configured for the participating nodes, so that the participating nodes also have the above-mentioned function of the block generating node, and the blocks generated by them can be verified as legal blocks. For the block generating node, the "generate block" behavior permission can be configured, otherwise, the blocks generated by it are verified as illegal blocks. For the client, the "read", "call", "deploy", "manage" and other behavior permissions can be configured according to the needs, among which the "read" behavior permission is necessary, and the "call", "deploy" and "manage" behavior permissions can be flexibly configured for the client according to user needs. For example, for the client used by the management user, the "call", "deploy" and "manage" behavior permissions can be configured, which can realize the deployment and access of the business-level smart contract, and can also realize the access of the system-level smart contract. For the client used by ordinary users, the "call" and "deploy" behavior permissions can be configured, thereby realizing the deployment and access of the business-level smart contract.

[0043] It should be understood that the above configuration process can be completed by calling the write type interface of the system-level smart contract through the management client with management behavior permission. When reading or verifying whether the subject has the allowed behavior, it can be realized by calling the read type interface of the system-level smart contract.

[0044] The consensus scheme of the trusted blockchain to be introduced in the embodiments of this specification can be applied to various types of trusted blockchains, such as public chains, private chains, alliance chains, permission chains, etc. It is particularly suitable for alliance chains to solve the defects of alliance chains being low in security and vulnerable to malicious attacks.

[0045] Embodiment 1

[0046] Reference Figure 2 As shown, it is a schematic diagram of the steps of a consensus method of a trusted blockchain provided by an embodiment of this specification, which is applied to Figure 1 In the Trusted Execution Environment TEE of the block node shown in Figure 1, Figure 1 In the trusted blockchain system shown, the block generation node is deployed on a computing device with TEE, and the block generation program of the block generation node is installed in TEE. Since TEE is a secure area in the processor, it can provide a secure and isolated operating environment for the block generation program and its running code and business data, ensuring that the code and data running therein are not illegally obtained or tampered with by external software (including operating system, BIOS, etc.) or hardware (other areas of the processor), ensuring data integrity and confidentiality.

[0047] Figure 2The execution subject of the consensus method can be a block generation node, which can execute Figure 2 The hardware device or software device of the consensus method shown is, for example, a server, a computer, an application client, etc. The consensus method may include the following steps:

[0048] Step 202: Receive a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a portion of transactions or all transactions selected by the participating node from cached legitimate transactions.

[0049] Step 204: Verify the pre-signed block based on the blockchain account parameters published by the participating node.

[0050] Step 206: After verification, consensus calculation is performed with the set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target.

[0051] Step 208: Add the random number to the pre-signed block and sign it using its own blockchain account parameters to construct a complete signed block.

[0052] It should be understood that the legal transactions cached by the participating nodes are the transactions received from the client. The participating nodes can cache one or more legal transactions to form a transaction pool.

[0053] Generally speaking, a block is generated on one node; however, in the embodiments of this specification, blocks are generated on participating nodes and generating block nodes respectively, and the specific process can be divided into two stages: 1) the participating node generates a pre-signed block and sends it to the generating block node; 2) the generating block node completes the calculation of the generated block based on the pre-signed block to obtain the random number Nonce, and returns it to the participating node after completing the complete block signature.

[0054] Before generating a block, the participating nodes and the block generating nodes can generate their own blockchain accounts respectively, and configure the corresponding behavior permissions in the system-level account management smart contract respectively. Since this solution only improves the consensus solution of the block generating node, it does not care about the relevant configuration of the participating nodes. All participating nodes that can cooperate with the block generating node in the embodiment of this specification to generate blocks, verify and reach consensus belong to the protection scope of this application.

[0055] A feasible solution is that before receiving the pre-signed block sent by the participating node, a blockchain account can be generated for the block generating node based on the block generating program, and a block generating behavior permission can be configured for the blockchain account in the system-level account management smart contract; the block generating behavior permission is used to provide a verification basis for the participating node to verify the legitimacy of the complete signed block.

[0056] Furthermore, a set of blockchain account addresses of participating nodes with legal block associations with the block generating node can be set in the TEE environment where the block generating node is located; and / or, a read behavior permission can be configured for the blockchain account corresponding to the block generating node in the system-level account management smart contract. These configurations can provide a basis for legitimacy verification when the block generating node verifies the pre-signed block in the subsequent process.

[0057] It should be understood that the participating node having a legal block association relationship with the block generating node may refer to a participating node that can generate and send a pre-signed block to the block generating node and has permission to generate a block; or, it may be a participating node that is configured with other parameters specifically used to mark the association relationship in the system-level account management smart contract. In the embodiments of this specification, the former is mainly used as an example for explanation, that is, the participating node has permission to generate a block.

[0058] A feasible solution is that the trusted blockchain includes multiple sub-chains; the transaction sent to the participating nodes can include an alliance identifier, that is, an alliance ID; and the alliance identifiers of the transactions included in the pre-signed block are the same.

[0059] In the embodiments of this specification, the participating nodes can publish their own blockchain account parameters in the blockchain in advance. It should be understood that the blockchain account parameters here can be a public-private key pair generated by the participating nodes according to random numbers, wherein the published blockchain account is the public key in the public-private key pair, and the private key is reserved. In this way, the block generation node that receives the pre-signed block can verify the pre-signed block based on the blockchain account parameters.

[0060] Optionally, in step 204, when verifying the pre-signed block based on the blockchain account parameters issued by the participating node:

[0061] The pre-signed block can be parsed based on the blockchain account parameters published by the participating nodes to verify whether the signature of the pre-signed block is correct. If the signature verification is successful, it means that the pre-signed block is legal, otherwise, the pre-signed block is illegal; or,

[0062] The pre-signed block can also be parsed based on the blockchain account parameters published by the participating node to verify whether the signature of the pre-signed block is correct. After verifying that the signature is correct, the legality of the pre-signed block can be verified based on the blockchain account address of the participating node obtained from the pre-signed block.

[0063] Furthermore, any of the following methods may be selected according to the pre-configured information to verify whether the pre-signed block is legitimate through the blockchain account address of the participating node:

[0064] Method 1: When the blockchain account address set is stored in the TEE environment where the block generating node is located, it is determined whether the blockchain account address of the participating node is included in the locally stored blockchain account address set; if so, the pre-signed block is verified to be legal; otherwise, the pre-signed block is verified to be illegal.

[0065] Method 2: When the block generation node has read behavior permission, the system-level account management smart contract is read, and based on the reading result, it is determined whether the participating node has a legal block association relationship with the block generation node; if so, the pre-signed block is verified to be legal, otherwise, the pre-signed block is verified to be illegal.

[0066] It can be seen that in the embodiments of this specification, the generation of a complete block goes through two processes, and these two processes are performed at different nodes: the pre-signed block is generated at the participating node, and the complete signed block is generated at the block generating node. The following briefly describes these two generation processes.

[0067] Pre-signed block generation process:

[0068] a1. Participating nodes select some or all transactions from the cached legitimate transactions.

[0069] In fact, when targeting the alliance chain, you can select some or all transactions with the same alliance Chain ID from the cached legitimate transactions, and then obtain the Chain ID (alliance ID) and Transactions (transaction data) of the transaction to be constructed.

[0070] a2. Participating nodes obtain the Parent Block ID from the previous block.

[0071] a3. Participating nodes calculate the Difficulty Target according to the predetermined protocol.

[0072] For consortium chains, each subchain can be set up with an independent predetermined protocol to calculate the difficulty target.

[0073] a4. The participating nodes use the Node Para (blockchain account parameters) corresponding to their own blockchain accounts to digitally sign the Chain ID, Parent Block ID, Difficulty Target, Transactions, and Node Para to obtain PreSignature.

[0074] a5. Participating nodes assemble Chain ID, Parent Block ID, Difficulty Target, Transactions, Node Para, and PreSignature to complete the generation of pre-signed blocks.

[0075] a6. The participating nodes send the pre-signed blocks to the block generating nodes.

[0076] Thus, a pre-signed block is generated at the participating nodes and sent by the participating nodes to the block generating nodes to construct a complete signed block.

[0077] Complete signature block generation process:

[0078] b1. The block generating node verifies PreSignature using NodePara (blockchain account parameters). If the verification passes, execute step b2. Otherwise, directly return a failure message to the node without performing the following process.

[0079] b2. The block generating node obtains the blockchain account ID of the participating node (its generating node) through the pre-signed block, and determines whether the participating node has the "generate block" permission.

[0080] In fact, when verifying the legitimacy of the block generated by the participating nodes, you can choose which verification method to use based on the pre-configured information. a) If the TEE block generation program records the blockchain account address set of the participating nodes with permission to generate blocks, then select method 1 to determine whether the node that generated the pre-signed block is in the recorded blockchain account address set; b) If the node that generates the block is also a legitimate "client", then select method 2 to read the system-level account management smart contract to determine whether the node that generated the pre-signed block has permission to "generate blocks".

[0081] If any of the above determination results a) or b) is yes, continue with the following step b3, otherwise, no processing is performed.

[0082] b3. The block generation program in the block generation node performs PoW calculation at a fixed hash rate (i.e., set computing power) according to the "difficulty target" in the pre-signed block, and obtains the calculation result Nonce that meets the "difficulty target".

[0083] b4. The block generating node uses the blockchain account parameter MinerPara corresponding to its own blockchain account to digitally sign Chain ID, ParentBlock ID, Difficulty Target, Transactions, Node Para, PreSignature, Nonce, and Miner Para to obtain FinalSignature.

[0084] In specific implementation, it can be assembled and signed in the order of Chain ID, ParentBlock ID, Difficulty Target, Transactions, Node Para, PreSignature, Nonce, and Miner Para to obtain FinalSignature.

[0085] b5. The block generation node assembles Chain ID, ParentBlock ID, Difficulty Target, Transactions, Node Para, PreSignature, Nonce, Miner Para, and FinalSignature to complete the generation of a complete signature block;

[0086] b6. The block generating node returns the complete signature block to the participating nodes.

[0087] The participating nodes here should be the participating nodes that send pre-signed blocks to the block generating nodes.

[0088] b7. Participating nodes determine the legitimacy of the complete signature block, discard illegal blocks, store and record legal blocks, and forward legal blocks to other nodes that have established network connections.

[0089] At this point, the above processes a1-a6 and b1-b7 have jointly completed the generation of the complete signature block. Therefore, the blocks can be signed through the two processes of pre-signature and complete signature to ensure the legitimacy of the complete signature block. In addition, the participating nodes and the block generation nodes are also configured in the system-level account management smart contract to further ensure that the output complete signature block is legal. At the same time, the block generation node is deployed with a TEE environment, and the blockchain account of the block generation node is generated in the TEE environment. The private key is only visible and usable in the TEE, and the public key or address can be exported from the TEE to configure permissions for the block generation node in the system-level account management smart contract. The private key is only visible and usable in the TEE to ensure the security of the computing power. In other words: on the one hand, the computing power in the TEE is limited by the TEE block generation program. The TEE program itself has a tamper-proof security mechanism to ensure that the computing power cannot be expanded by modifying the TEE program. On the other hand, the private key of the block generation node cannot be moved to other machines for use, which avoids illegal increase in computing power. In this way, the original PoW resource waste problem and 51% attack problem are solved.

[0090] Embodiment 2

[0091] Reference Figure 3 As shown, a consensus device 300 of a trusted blockchain provided by an embodiment of this specification is applied to a trusted execution environment TEE for generating a block node, and the device 300 includes:

[0092] The receiving module 302 is used to receive a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions;

[0093] A verification module 304, configured to verify the pre-signed block based on the blockchain account parameters issued by the participating node;

[0094] The consensus module 306 is used to perform consensus calculation with a set computing power according to the difficulty target recorded in the pre-signed block after the verification is passed, and obtain a random number that meets the difficulty target;

[0095] The signature module 308 is used to add the random number to the pre-signed block and sign it using its own blockchain account parameters to construct a complete signature block.

[0096] Optionally, as an embodiment, the device further includes: a configuration module, used to generate a blockchain account for the block generating node before the receiving module 302 receives the pre-signed block sent by the participating node, and configure the block generating behavior permission for the blockchain account in the system-level account management smart contract; wherein the block generating behavior permission is used to provide a verification basis for the participating node to verify the legitimacy of the complete signed block.

[0097] In a specific implementation of the embodiments of this specification, when the verification module 304 verifies the pre-signed block based on the blockchain account parameters published by the participating node, it is specifically used to parse the pre-signed block based on the blockchain account parameters published by the participating node to verify whether the signature of the pre-signed block is correct; after verifying that the signature is correct, verify whether the pre-signed block is legal according to the blockchain account address of the participating node obtained from the pre-signed block.

[0098] In another specific implementation of the embodiments of this specification, a set of blockchain account addresses of participating nodes that have a legal block association relationship with the block generating node is stored in the TEE environment where the block generating node is located; and / or, the blockchain account corresponding to the block generating node is configured with a read behavior permission in the system-level account management smart contract.

[0099] In another specific implementation of the embodiments of the present specification, when the verification module 304 verifies whether the pre-signed block is legal based on the blockchain account address of the participating node obtained from the pre-signed block, it is specifically used to determine whether the blockchain account address set of the participating node is in the locally stored blockchain account address set when the blockchain account address set is stored in the TEE environment where the generating block node is located; if so, verify that the pre-signed block is legal, otherwise, verify that the pre-signed block is illegal; or, when the generating block node has read behavior permission, read the system-level account management smart contract and determine whether the participating node has a legal block association relationship with the generating block node; if so, verify that the pre-signed block is legal, otherwise, verify that the pre-signed block is illegal.

[0100] In another specific implementation of the embodiments of this specification, the participating node that has a legal block association relationship with the block generating node refers to a participating node that can generate and send a pre-signed block to the block generating node and has permission to generate block behavior.

[0101] In another specific implementation of the embodiments of this specification, the trusted blockchain includes multiple sub-chains; then the alliance identifiers of the transactions included in the pre-signed blocks are the same.

[0102] This specification also provides a trusted blockchain system. Figure 1 As shown, it includes: a client, a participating node and a block generation node; wherein the number of the client, the participating node and the block generation node is not limited. The consensus device of the above-mentioned trusted blockchain is deployed in the trusted execution environment TEE of the block generation node; the block generation node receives the pre-signed block sent by the participating node, wherein the pre-signed block is constructed and signed by the participating node from part of the transactions or all transactions selected from the cached legal transactions; based on the blockchain account parameters published by the participating node, the pre-signed block is verified; after the verification is passed, according to the difficulty target recorded in the pre-signed block, the consensus calculation is performed with the set computing power to obtain a random number that meets the difficulty target; the random number is added to the pre-signed block, and signed with its own blockchain account parameters to construct a complete signature block.

[0103] It should be understood that the consensus device of the trusted blockchain and the trusted blockchain system can also execute Figure 2 The method and the corresponding device are implemented in Figure 2 The functions of the illustrated embodiments will not be described in detail in the embodiments of this specification.

[0104] Embodiment 3

[0105] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0106] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0107] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0108] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a consensus device of the trusted blockchain at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0109] Receiving a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions;

[0110] Verifying the pre-signed block based on the blockchain account parameters issued by the participating node;

[0111] After verification, consensus calculation is performed with the set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target;

[0112] The random number is added to the pre-signed block and signed using its own blockchain account parameters to construct a complete signature block.

[0113] The above is as in this manual Figure 2The method executed by the device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in one or more embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in one or more embodiments of this specification can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0114] The electronic device may also perform Figure 2 The method and the corresponding device are implemented in Figure 2 The functions of the illustrated embodiments will not be described in detail in the embodiments of this specification.

[0115] Of course, in addition to software implementation, the electronic device of the embodiments of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0116] Embodiment 4

[0117] The embodiment of the present specification also provides a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 2 The method of the embodiment shown is specifically used to perform the following method:

[0118] Receiving a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions;

[0119] Verifying the pre-signed block based on the blockchain account parameters issued by the participating node;

[0120] After verification, consensus calculation is performed with the set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target;

[0121] The random number is added to the pre-signed block and signed using its own blockchain account parameters to construct a complete signature block.

[0122] While the embodiments of this specification perform consensus calculations on a trusted blockchain through a PoW mechanism, they further deploy the consensus calculations in the TEE that generates the block node, and pre-set computing power for the consensus calculations in the TEE. Thus, a secure and isolated consensus computing environment is provided through the TEE, and by designing a fixed computing power, malicious 51% attacks are reduced or avoided.

[0123] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the protection scope of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

[0124] The systems, devices, modules or units described in one or more of the above embodiments may be implemented by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0125] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0126] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0127] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0128] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A consensus method for a trusted blockchain, characterized in that: Applied to generating a trusted execution environment TEE of a block node, the method includes: Receiving a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions; Verifying the pre-signed block based on the blockchain account parameters issued by the participating node; After verification, consensus calculation is performed with the set computing power according to the difficulty target recorded in the pre-signed block to obtain a random number that meets the difficulty target; Add the random number to the pre-signed block and sign it using its own blockchain account parameters to construct a complete signed block; Wherein, based on the blockchain account parameters published by the participating node, the pre-signed block is verified, including: based on the blockchain account parameters published by the participating node, parsing the pre-signed block to verify whether the signature of the pre-signed block is correct; after verifying that the signature is correct, when the blockchain account address set is stored in the TEE environment where the block generation node is located, it is determined whether there is a blockchain account address of the participating node in the locally stored blockchain account address set; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; or, when the block generation node has a read behavior permission, the system-level account management smart contract is read, and it is determined whether the participating node has a legal block association relationship with the block generation node; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; wherein, the TEE environment where the block generation node is located stores a blockchain account address set of participating nodes having a legal block association relationship with the block generation node; and / or, the blockchain account corresponding to the block generation node in the system-level account management smart contract is configured with a read behavior permission.

2. The consensus method of a trusted blockchain as claimed in claim 1, characterized in that: Before receiving the pre-signed block sent by the participating node, the method further includes: A blockchain account is generated for the block generation node, and a block generation behavior permission is configured for the blockchain account in the system-level account management smart contract; wherein the block generation behavior permission is used to provide a verification basis for the participating node to verify the legitimacy of the complete signature block.

3. The consensus method of a trusted blockchain as claimed in claim 1, characterized in that: The participating node having a legal block association relationship with the block generating node refers to a participating node that can generate and send a pre-signed block to the block generating node and has permission to generate block behavior.

4. The consensus method of a trusted blockchain as claimed in claim 1, characterized in that: The trusted blockchain includes multiple sub-chains; then the alliance identifiers of the transactions included in the pre-signed blocks are the same.

5. A consensus device for a trusted blockchain, characterized in that: Applied in a trusted execution environment TEE for generating a block node, the device comprises: A receiving module, used to receive a pre-signed block sent by a participating node, wherein the pre-signed block is constructed and signed by a part of or all transactions selected by the participating node from cached legitimate transactions; A verification module, for parsing the pre-signed block to verify whether the signature of the pre-signed block is correct based on the blockchain account parameters published by the participating node; after verifying that the signature is correct, when the blockchain account address set is stored in the TEE environment where the block generation node is located, it is determined whether there is a blockchain account address of the participating node in the locally stored blockchain account address set; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; or, when the block generation node has a read behavior permission, the system-level account management smart contract is read, and it is determined whether the participating node has a legal block association relationship with the block generation node; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; wherein, the TEE environment where the block generation node is located stores a blockchain account address set of participating nodes having a legal block association relationship with the block generation node; and / or, the blockchain account corresponding to the block generation node in the system-level account management smart contract is configured with a read behavior permission; A consensus module, which is used to perform consensus calculations with a set computing power according to the difficulty target recorded in the pre-signed block after verification, to obtain a random number that meets the difficulty target; The signature module is used to add the random number to the pre-signed block and sign it using its own blockchain account parameters to construct a complete signature block.

6. A trusted blockchain system, characterized in that: include: A client, a participating node and a block generating node; wherein the trusted execution environment TEE of the block generating node is deployed with the consensus device of the trusted blockchain as claimed in claim 5; The block generating node receives the pre-signed block sent by the participating node, wherein the pre-signed block is constructed and signed by some or all transactions selected by the participating node from the cached legal transactions; the pre-signed block is verified based on the blockchain account parameters published by the participating node; after the verification is passed, according to the difficulty target recorded in the pre-signed block, consensus calculation is performed with the set computing power to obtain a random number that meets the difficulty target; the random number is added to the pre-signed block, and signed with its own blockchain account parameters to construct a complete signature block; Wherein, based on the blockchain account parameters published by the participating node, the pre-signed block is verified, including: based on the blockchain account parameters published by the participating node, parsing the pre-signed block to verify whether the signature of the pre-signed block is correct; after verifying that the signature is correct, when the blockchain account address set is stored in the TEE environment where the block generation node is located, it is determined whether there is a blockchain account address of the participating node in the locally stored blockchain account address set; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; or, when the block generation node has a read behavior permission, the system-level account management smart contract is read, and it is determined whether the participating node has a legal block association relationship with the block generation node; if so, the pre-signed block is legal, otherwise, the pre-signed block is illegal; wherein, the TEE environment where the block generation node is located stores a blockchain account address set of participating nodes having a legal block association relationship with the block generation node; and / or, the blockchain account corresponding to the block generation node in the system-level account management smart contract is configured with a read behavior permission.

7. An electronic device, characterized in that: include: processor; as well as A memory arranged to store computer executable instructions, which, when executed, cause the processor to perform the consensus method for the trusted blockchain as described in any one of claims 1 to 4.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple application programs, enable the electronic device to execute the consensus method of the trusted blockchain described in any one of claims 1-4.

Images