Data processing method, system, device, computer device, and storage medium

Abstract

The application discloses a data processing method, system and device, computer equipment and a storage medium, and belongs to the technical field of blockchains. The method generates a log by a TEE of a node device in a blockchain system, and a REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that the other node devices reach a consensus on the log. Since the TEE is protected by hardware and cannot be malicious, the TEE can be used to protect a consensus process, and a Byzantine error in the blockchain system can be prevented.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a data processing method, system and device, computer equipment and a storage medium. BACKGROUND

[0002] A blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. The blockchain is widely used in fields with high requirements for secure data storage due to its characteristics such as decentralization, trustlessness, collective maintenance and reliable database.

[0003] Consensus nodes in a blockchain system can reach consensus on blocks through a consensus protocol and store the blocks that pass the consensus on the blockchain. Current consensus protocols include crash fault tolerant (CFT) consensus protocols such as the Paxos consensus algorithm and the Raft consensus algorithm. The CFT consensus protocol can solve problems such as node message delay, loss and repetition caused by network failure or node crash, so that the blockchain system can still operate normally even if some nodes have network failure or node crash in the blockchain system using the CFT consensus protocol.

[0004] However, the CFT consensus protocol cannot solve Byzantine faults such as falsifying node messages, tampering with node messages or malicious responses. Byzantine faults can cause consensus errors in the blockchain system and the blockchain system cannot work normally, so there is an urgent need for a data processing method that can reduce Byzantine faults in the blockchain system. SUMMARY

[0005] The embodiments of the present application provide a data processing method, system, device, computer equipment and storage medium, which can reduce Byzantine faults in the blockchain system. The technical solution is as follows:

[0006] In a first aspect, a data processing method is provided, which is executed by a first node device in a blockchain system, and the first node device includes a trusted execution environment (TEE) and a rich execution environment (REE); the method comprises:

[0007] The TEE generates a log of the block based on the block in the REE, sends the log to the REE, and the log refers to the block by an identifier of the block;

[0008] The REE receives the log, sends a first request to a second node device in the blockchain system, the first request carries the log, and the first request instructs the second node device to process the log.

[0009] The log includes the identifier of the block but does not include the block, and the identifier of the block is used to refer to the block, for example, the identifier of the block includes at least one of a hash value of the block and a block number of the block, and of course, the identifier of the log can also be other forms of representation other than the hash value of the block or the block number, and the identifier of the log is not limited herein.

[0010] Since the log in the present application refers to the block by the identifier of the block, the log in the present application does not include the block. The log in the related art does not use the identifier of the block to refer to the log, but directly adds the block in the log, that is, the log in the related art includes the block. Alternatively, it can also be understood that the present application replaces the block in the log in the related art with the identifier of the block. The data amount of the identifier of the block is smaller relative to the entire block, and therefore, compared with the log in the related art, the data amount of the log in the present application is smaller.

[0011] The method generates the log by the TEE of the node device in the blockchain system, the REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that other node devices reach consensus on the log. Since the TEE is protected by hardware and cannot be malicious, the purpose of protecting the consensus process by using the TEE can be achieved, and the Byzantine error in the blockchain system can be prevented. Moreover, the block is referred to by the identifier of the block in the log, and the log does not need to carry the block, thereby reducing the data amount of the log.

[0012] In a possible implementation, the first request also carries the block, and the first request indicates that the second node device processes the log and the block; after the first request is sent to the second node device in the blockchain system, the method further includes:

[0013] The TEE receives a plurality of first responses through the REE, and each first response indicates whether a second node device has agreed to receive the log;

[0014] In a case where the first responses of the second node devices in the blockchain system pass the verification of the TEE, and each first response that passes the verification indicates that a second node device has agreed to receive the log, the TEE notifies the REE to submit the block to the local blockchain ledger of the blockchain system based on the identifier of the block in the log.

[0015] In a possible implementation, before the TEE generates the log based on the block in the REE, the method further includes:

[0016] The TEE sends, through the REE, a second request to second node devices in the blockchain system, the second request indicating a vote on the first node device becoming a leader node in the blockchain system;

[0017] The TEE receives, through the REE, a plurality of second responses, each second response indicating whether a second node device agrees on the first node device becoming a leader node in the blockchain system;

[0018] In a case where the second responses of the second node devices in the blockchain system pass the verification of the TEE, and each of the second responses that passes the verification indicates that a second node device agrees on the first node device becoming a leader node in the blockchain system, the TEE switches the node state of the first node device to a leader state.

[0019] In a possible implementation, after the TEE switches the node state of the first node device to the leader state, the method further includes:

[0020] The TEE generates a notification message, the notification message indicating that the first node device is a leader node in the blockchain system;

[0021] The TEE sends, through the REE, the notification message to the second node devices in the blockchain system.

[0022] In a possible implementation, the notification message can be a heartbeat message or other types of messages.

[0023] In a possible implementation, the method further includes:

[0024] In a case where the first responses of the second node devices in the blockchain system pass the verification of the TEE, and each of the first responses that passes the verification indicates that a second node device has agreed to receive the log, the TEE sends, through the REE, a third request to the second node devices in the blockchain system, the third request indicating that the second node devices commit the block to a local blockchain ledger of the blockchain system.

[0025] In a possible implementation, the third request can be a heartbeat message or other types of messages.

[0026] In a possible implementation, the method further includes:

[0027] The TEE truncates a plurality of logs in the log sequence that have been committed to obtain a snapshot of the log sequence, the snapshot including a first identifier and a second identifier, wherein the first identifier is an identifier of a block corresponding to a starting log in the plurality of logs, and the second identifier is an identifier of a block corresponding to a terminal log in the plurality of logs.

[0028] The TEE sends the snapshot to the REE.

[0029] The REE receives the snapshot, obtains a plurality of blocks corresponding to the plurality of logs from a local blockchain ledger of the blockchain system based on the first identifier and the second identifier in the snapshot, and sends a fourth request to a second node device in the blockchain system, the fourth request carrying the snapshot and the plurality of blocks, the fourth request instructing the second node device to commit the plurality of blocks to the local blockchain ledger based on the snapshot.

[0030] Each log in the log sequence includes an identifier of a block and an index of a log, and the logs in the log sequence are arranged in order of increasing index. Optionally, each log further includes a term of a leader node in the blockchain system.

[0031] In a possible implementation, the fourth request can be a heartbeat message or other types of messages.

[0032] In a second aspect, a data processing method is provided, which is performed by a second node device in a blockchain system, the second node device including a trusted execution environment (TEE) and a rich execution environment (REE), and the method including:

[0033] The REE receives a first request from a first node device in the blockchain system, the first request carrying a log of a block, the log referring to the block by an identifier of the block, and the first request instructing the second node device to process the log.

[0034] The REE sends the log to the TEE.

[0035] In a case where the log passes the verification of the TEE, the TEE stores the log, and sends a first response to the first node device through the REE, the first response indicating that the second node device has agreed to receive the log.

[0036] In a possible implementation, the first request further carries the block, and after the REE receives the first request from the first node device in the blockchain system, the method further includes:

[0037] The REE caches the block;

[0038] After the TEE sends the first response to the first node device through the REE, the method further includes:

[0039] The TEE receives a third request from the first node device through the REE, the third request indicating that the second node device submits the block to a blockchain ledger of the local blockchain system;

[0040] In a case where the third request passes the verification of the TEE, the TEE notifies the REE to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log.

[0041] In a possible implementation, before the REE receives the first request from the first node device in the blockchain system, the method further includes:

[0042] The TEE receives a second request from the first node device through the REE, the second request indicating a vote for the first node device to become a leader node in the blockchain system;

[0043] In a case where the second request passes the verification of the TEE, the TEE sends a second response to the first node device through the REE, the second response indicating whether the second node device agrees that the first node device becomes the leader node in the blockchain system.

[0044] In a possible implementation, after the TEE sends the second response to the first node device through the REE, the method further includes:

[0045] The TEE receives a notification message from the first node device through the REE, the notification message indicating that the first node device becomes the leader node in the blockchain system;

[0046] In a case where the notification message passes the verification of the TEE, the TEE modifies the stored node state of the first node device to a leader state.

[0047] In a possible implementation, the method further includes:

[0048] The REE receives a fourth request from the first node device, the fourth request carrying a snapshot of a log sequence in the first node device and a plurality of blocks, the snapshot including a first identifier and a second identifier, wherein the first identifier is an identifier of a block corresponding to a starting log in a plurality of logs in the log sequence that have been committed, and the second identifier is an identifier of a block corresponding to a terminal log in the plurality of logs, the plurality of logs corresponding to the plurality of blocks;

[0049] The REE caches the plurality of blocks and sends the snapshot to the TEE;

[0050] The TEE receives the snapshot, and in a case where the snapshot passes verification by the TEE, notifies the REE to commit the plurality of blocks to a blockchain ledger of the local blockchain system.

[0051] In a third aspect, a blockchain system for data processing is provided, the blockchain system including a first node device and at least one second node device;

[0052] The first node device is configured to send a first request to a second node device in the blockchain system, the first request carrying a log of a block, the log referring to the block by an identifier of the block, the first request instructing the second node device to process the log;

[0053] Each second node device is configured to receive the first request and, in a case where the log passes verification by the second node device, store the log.

[0054] In a possible implementation, the first node device includes a trusted execution environment (TEE) and a rich execution environment (REE);

[0055] The TEE is configured to generate the log based on the block in the REE, and send the log to the REE;

[0056] The REE is configured to receive the log, and send the first request to a second node device in the blockchain system.

[0057] In a possible implementation, each second node device includes a TEE and a REE;

[0058] The REE of each second node device is configured to receive the first request, and send the log carried by the first request to the TEE of the second node device;

[0059] The TEE of each second node device is configured to receive the first request, store the log if the log passes the verification of the TEE, and send a first response to the first node device through the REE of the second node device, the first response indicating whether one second node device has agreed to receive the log.

[0060] In a possible implementation, the first node device comprises a TEE and an REE.

[0061] The TEE of the first node device is configured to receive the first response of the second node device in the blockchain system through the REE of the first node device, and notify the REE of the first node device to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log if the first response of half or more of the second node devices in the blockchain system passes the verification of the TEE and each of the verified first responses indicates that one second node device has stored the log.

[0062] In a possible implementation, the first request further carries the block.

[0063] The TEE of the first node device is further configured to send a third request to the second node device in the blockchain system through the REE of the node device, the third request indicating that the second node device submits the block to the blockchain ledger of the local blockchain system.

[0064] The REE of each second node device is further configured to cache the block carried by the first request, receive the third request, and send the third request to the TEE of the second node device.

[0065] The TEE of each second node device is further configured to receive the third request, and notify the REE of the second node device to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log if the third request passes the verification of the TEE.

[0066] In a possible implementation, each of the first node device and the at least one second node device comprises a TEE and an REE.

[0067] The TEE of the first node device is configured to send a second request to the second node device in the blockchain system through the TEE of the node device, the second request indicating a vote for the first node device to become a leader node in the blockchain system.

[0068] The TEE of each second node device is configured to receive the second request, and in a case where the second request passes the verification of the TEE, send, by the REE of the node device, a second response to the first node device, each second response indicating whether a second node device agrees that the first node device becomes the leader node in the blockchain system.

[0069] The TEE of the first node device is further configured to receive, by the REE of the node device, second responses of second node devices in the blockchain system to the second request, and in a case where second responses of a majority of the second node devices in the blockchain system pass the verification of the TEE and each of the second responses that passes the verification indicates that a second node device agrees that the first node device becomes the leader node in the blockchain system, switch the node state of the first node device to the leader state.

[0070] In a possible implementation, the TEE of the first node device is further configured to generate a notification message, and send, by the REE of the node device, the notification message to the second node devices in the blockchain system, the notification message indicating that the first node device is the leader node in the blockchain system.

[0071] The TEE of each second node device is further configured to receive, by the REE of the node device, the notification message, and in a case where the notification message passes the verification of the TEE, modify the stored node state of the first node device to the leader state.

[0072] In a possible implementation, the first node device includes a TEE and an REE.

[0073] The TEE is configured to truncate a plurality of logs in a log sequence that have been committed, to obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot including a first identifier and a second identifier, where the first identifier is an identifier of a block corresponding to a starting log in the plurality of logs, and the second identifier is an identifier of a block corresponding to a terminal log in the plurality of logs.

[0074] The REE is configured to receive the snapshot, obtain, based on the first identifier and the second identifier in the snapshot, a plurality of blocks corresponding to the plurality of logs from a local blockchain ledger of the blockchain system, and send, to a second node device in the blockchain system, a fourth request, the snapshot including an identifier of a first block and an identifier of a last block in the blockchain ledger at a current time, the fourth request carrying the snapshot and the plurality of blocks, and the fourth request indicating that the second node device commits the plurality of blocks to the local blockchain ledger.

[0075] In a possible implementation, each second node device comprises a TEE and a REE;

[0076] The REE of each second node device is configured to receive the fourth request from the first node device, cache the plurality of blocks, and send the snapshot to the TEE.

[0077] The TEE of each second node device is configured to receive the snapshot, and notify the REE of the second node device to commit the plurality of blocks to the blockchain ledger of the local blockchain system based on the snapshot if the snapshot passes the verification of the TEE.

[0078] In a fourth aspect, a data processing apparatus is provided for performing the data processing method described above. Specifically, the data processing apparatus comprises functional modules for performing the data processing method provided in the first aspect or any of the optional implementations of the first aspect.

[0079] In a fifth aspect, a data processing apparatus is provided for performing the data processing method described above. Specifically, the data processing apparatus comprises functional modules for performing the data processing method provided in the second aspect or any of the optional implementations of the second aspect.

[0080] In a sixth aspect, a computer device is provided, which comprises a trusted execution environment (TEE). The TEE comprises a processor configured to execute program codes, so that the computer device performs operations as performed in the data processing method described above.

[0081] In a seventh aspect, a computer readable storage medium is provided, which stores at least one program code. The program code is read by a processor in a trusted execution environment (TEE) to make a computer device perform operations as performed in the data processing method described above.

[0082] In an eighth aspect, a computer program product is provided, which comprises program codes stored in a computer readable storage medium. The program codes are read by a processor in a trusted execution environment (TEE) of a computer device. The processor executes the program codes to make the computer device perform the method provided in the first aspect or any of the optional implementations of the first aspect, or perform the method provided in the second aspect or any of the optional implementations of the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0083] Figure 1 is a schematic diagram of a blockchain system provided by an embodiment of the present application;

[0084] Figure 2is a role conversion schematic diagram of a consensus node device in a Raft consensus algorithm provided by an embodiment of the present application;

[0085] Figure 3 is a consensus cluster schematic diagram of a Raft consensus algorithm based on TEE provided by an embodiment of the present application;

[0086] Figure 4 is a consensus node device schematic diagram of a Raft consensus algorithm based on TEE provided by an embodiment of the present application;

[0087] Figure 5 is a flowchart of a leader node election method provided by an embodiment of the present application;

[0088] Figure 6 is a leader node election flow schematic diagram provided by an embodiment of the present application;

[0089] Figure 7 is a flowchart of a data processing method provided by an embodiment of the present application;

[0090] Figure 8 is a data amount comparison schematic diagram of different third messages provided by an embodiment of the present application;

[0091] Figure 9 is a first request and a log replication request in related technologies comparison schematic diagram provided by an embodiment of the present application;

[0092] Figure 10 is a block consensus process schematic diagram provided by an embodiment of the present application;

[0093] Figure 11 is a block storage schematic diagram provided by an embodiment of the present application;

[0094] Figure 12 is a data processing process schematic diagram in a consensus cluster provided by an embodiment of the present application;

[0095] Figure 13 is a flowchart of a log compression method provided by an embodiment of the present application;

[0096] Figure 14 is a flowchart of a snapshot comparison schematic diagram provided by an embodiment of the present application;

[0097] Figure 15 is a structure schematic diagram of a data processing apparatus provided by an embodiment of the present application;

[0098] Figure 16 is a structure schematic diagram of a data processing apparatus provided by an embodiment of the present application;

[0099] Figure 17is a structural schematic diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0100] For the purpose, technical solutions and advantages of the present application to be clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0101] Figure 1 is a schematic diagram of a blockchain system provided by an embodiment of the present application, referring to Figure 1 , the blockchain system 100 includes a plurality of node devices 101, all or part of the node devices in the plurality of node devices 101 are consensus node devices in the blockchain system 100, and a cluster composed of the consensus node devices in the blockchain system 100 can be recorded as a consensus cluster. Among them, the consensus node device has the functions of generating a block and broadcasting the block in the consensus cluster, so that each consensus node device in the consensus cluster performs consensus on the block based on a consensus protocol. If a majority of consensus node devices in the consensus cluster pass the consensus on the block, each consensus node device in the consensus cluster stores the block on the blockchain ledger of the blockchain system 100 locally, so that the blockchain ledgers stored by each consensus node device in the consensus cluster are the same, achieving the purpose of the consensus cluster maintaining the same blockchain ledger. Of course, the consensus cluster can also maintain multiple blockchain ledgers in the manner of maintaining one blockchain ledger.

[0102] Among them, the consensus protocol includes a CFT type consensus protocol, and the CFT type protocol has Paxos algorithm for the first time. Since the Paxos algorithm has poor understandability, many other CFT type protocols have been derived from the Paxos algorithm. Among them, the Raft consensus algorithm is a relatively representative other CFT type protocol, which simplifies the design and optimizes the process of the Paxos algorithm, so that it is easier to understand and implement, and easier to apply in actual systems.

[0103] In the Raft consensus algorithm, the consensus node devices in the consensus cluster can have three roles, namely leader, candidate and follower, wherein the roles of the consensus node devices can also be understood as node states. The three roles can be converted to each other, and in this regard Figure 2 the role conversion schematic diagram of the consensus node device in the Raft consensus algorithm provided by an embodiment of the present application is shown, and the three roles are introduced as follows:

[0104] Leader: There is a consensus node device as a leader in the blockchain system, which is used to generate a block and a log of the block, and broadcast the block and the log in the consensus cluster, so that the non-leader nodes in the consensus cluster can receive the block and the log. It is also used to maintain a heart beat with the non-leader nodes to inform the non-leader nodes that it is the leader in the blockchain system. Among them, the non-leader nodes are consensus node devices in the blockchain system as followers or candidates. For ease of description, the consensus node device in the blockchain system as the leader is recorded as the leader node. The consensus node device in the blockchain system as the candidate is recorded as the candidate node. The consensus node device in the blockchain system as the follower is recorded as the follower node, that is, the candidate node and the follower node are both non-leader nodes.

[0105] Candidate: The candidate is in an intermediate state between the follower and the leader, and the candidate node is used to send a voting request to each non-leader node in the consensus cluster to request each non-leader node to vote for the candidate node to become the leader node. When the candidate node successfully competes for the leader (or the current election is successful), the candidate node is converted from the candidate to the leader.

[0106] Follower: Any consensus node device in the consensus cluster is a follower when it is started. The follower node is used to respond to the leader node to receive the log and the block sent by the leader node, and vote for the candidate node to become the leader.

[0107] In the Raft consensus algorithm, the replica data exists in the form of a log, and the log in the related technology includes a block and some additional information, such as a log index and a term. The leader node in the consensus cluster can generate a log and broadcast the log in the consensus cluster, so that each non-leader node in the consensus cluster can reach a consensus on the log. The consensus cluster reaches a consensus on the log to realize a consensus on the block corresponding to the log. In the scheme described in the present application, the log is improved to cooperate with the implementation of the scheme. Specifically, the log in the scheme proposed in the present application does not include a block, but only indicates the block corresponding to the log with an identifier. It can also be understood that the identifier of the block is used to replace the block itself in the log. Therefore, in the following, it is also described that the identifier of the block in the log refers to the block corresponding to the log.

[0108] The main process of the Raft consensus algorithm includes a leader election process and a log replication process (i.e., a log consensus process). The following describes the leader election process and the log replication process in the related technology. Figure 2 The election mechanism in the leader election process and the log replication mechanism in the log replication process in the related technology are introduced as follows:

[0109] 1. An election mechanism is introduced as follows by taking any consensus node device in a consensus cluster as an example:

[0110] The consensus node device is a follower when it is started, and the consensus node device is a follower node at this time. The follower node sets a term, which corresponds to an election process in the consensus cluster, for example, the term 1 corresponds to the first election process in the consensus cluster, and the term 2 corresponds to the second election process in the consensus cluster. The follower node also sets an election time to start an election to become a leader, and starts a countdown. When the election time reaches or times out, and there is no leader in the consensus cluster within a preset time length, the follower node updates its term (for example, the term is incremented by 1), which corresponds to an election process in the consensus cluster, for example, the term 1 corresponds to the first election process in the consensus cluster, and the term 2 corresponds to the second election process in the consensus cluster. The consensus node device is converted from a follower to a candidate, and the updated term corresponds to the election process (i.e. the current election process) initiated by the candidate node.

[0111] The candidate node initiates an election by sending a voting request to each non-leader node in the consensus cluster except the candidate node, wherein the voting request carries the term (i.e. the updated term) of the candidate node.

[0112] Each non-leader node returns a voting result to the candidate node according to the term of the candidate node in the voting request after receiving the voting request. For example, if the term of the candidate node is higher than the term of a non-leader node, and the non-leader node has not voted for any other candidate node, the non-leader node agrees that the candidate node becomes a leader in the consensus cluster, and returns a voting result representing a vote of approval to the candidate node. If the term of the candidate node is less than or equal to the term of the non-leader node, or the non-leader node has already voted for any other candidate node, the non-leader node opposes the candidate node to become a leader in the consensus cluster, and returns a voting result representing a vote of opposition to the candidate node.

[0113] After the candidate node receives the voting results of multiple non-leader nodes, the number of non-leader nodes (i.e. the number of votes of approval) that vote for the candidate node is counted. If a majority of non-leader nodes (including the candidate node) in the consensus cluster vote for the candidate node, the consensus node device is converted from a candidate to a leader in the consensus cluster, and the consensus node is a leader node at this time. The leader node sends a heartbeat message to each non-leader node in the consensus cluster to inform each non-leader node that it is a leader in the consensus cluster and the term of the leader, so that each non-leader node in the consensus cluster takes the term of the leader as its own term.

[0114] If a minority of non-leader nodes in the consensus cluster cast a yes vote for the candidate node, it means that a majority of non-leader nodes in the consensus cluster have cast a yes vote for another candidate node, and the other candidate node can have become the leader, so the candidate node fails in the current election (i.e., loses the election). During the current election, if the candidate node receives a heartbeat message sent by the leader node in the consensus cluster, it means that another candidate node has become the leader in the consensus cluster, so the candidate node fails in the current election. Once the candidate node fails in the election, the consensus node device switches from a candidate to a follower. Alternatively, if the current election times out and no leader is elected in the consensus cluster, the consensus node device switches from a candidate to a follower.

[0115] 2. Log replication mechanism:

[0116] Each consensus node device in the consensus cluster maintains a log sequence, which includes a plurality of logs arranged in order of increasing index in the logs, forming the log sequence. When the leader node in the consensus cluster generates a new block, the leader node generates a log for the block based on the block and the index of the last log in the local log sequence, and the index in the log is 1 greater than the index of the last log at the current time in the log sequence. The leader node adds the log to the end of the local log sequence and sends a log replication request to each non-leader node in the consensus cluster, and the log replication request carries the log.

[0117] After each non-leader node receives the log replication request, it decides whether to agree to receive the log based on the content of the log carried by the log replication request. If a non-leader node agrees to receive the log, the non-leader node adds the log to the log sequence of the non-leader node and returns a response agreeing to receive the log to the leader node. When a majority of non-leader nodes in the consensus cluster agree to receive the log, the leader node sends a heartbeat message to each non-leader node in the consensus cluster to indicate that a majority of non-leader nodes in the consensus cluster have agreed to receive the log. When each non-leader node receives the heartbeat message, it submits the block carried by the log to the blockchain ledger of the respective blockchain system, at which time the consensus cluster reaches consensus on the log (or block).

[0118] Raft consensus algorithm is a representative of CFT consensus algorithm. Each blockchain underlying technology platform can generally support Raft consensus algorithm. For example, the blockchain underlying technology platform introduces the open source code implementation of Raft consensus algorithm, or slightly modifies the open source code implementation to adapt to the underlying system. Such implementation is a pure software implementation of Raft consensus algorithm, and can tolerate node failure in the consensus cluster. However, the open source code of Raft consensus algorithm generally runs in a rich execution environment (REE) of a node device. Once a node device with a Byzantine error occurs in the consensus cluster, the node device with the Byzantine error can launch an arbitrary attack on the blockchain system, which may cause the consensus cluster to fail to work normally. The Byzantine error includes, but is not limited to, being elected as a leader node by tampering with the timestamp, tampering with the term, tampering with the voting result, or tampering with the content of the message transmitted in the blockchain system. Such a leader node may maliciously modify the block content or the index of the log, causing the consensus cluster to have a consensus error and fail to work normally.

[0119] For example, if the follower node maliciously tampers with the timestamp, it initiates the election in advance before the actual election time comes, so as to become a leader node. For another example, when the election is initiated, the candidate node tampers with its term to be relatively high, so that each non-leader node in the consensus cluster votes for the candidate node, thereby promoting the candidate node to become a leader node in the consensus cluster. For another example, when only a few non-leader nodes in the consensus cluster vote for a candidate node, if the candidate node tampers with the number of votes, for example, increases the number of votes, it will become a leader node in the consensus cluster. For another example, the leader node tampers with the timestamp of the heartbeat message. If the timestamp of the heartbeat message is modified to be small, the leader node will send the heartbeat message in the consensus cluster in advance, which may cause a denial of service (Dos) attack. If the timestamp of the heartbeat message is modified to be large, the leader node will not send the heartbeat message in the consensus cluster for a long time, that is, deliberately does not send the heartbeat message, causing the election time of the follower node to timeout and reinitiating the election.

[0120] For the convenience of description, the node device that appears Byzantine error is recorded as a Byzantine node. And in order to avoid the Byzantine error in the consensus cluster (for example, by tampering with the term election as a leader, or arbitrarily tampering with the log), that is, to avoid the Byzantine node in the consensus cluster, the embodiments of the present application propose a technical solution that a node device implements the Raft consensus algorithm in a trusted execution environment (TEE). For example, the computer program (or program code) for implementing the Raft consensus algorithm is stored in the TEE, and the consensus node device runs the computer program for implementing the Raft consensus algorithm in the TEE, so that the consensus node device implements the algorithm process of the Raft consensus algorithm.

[0121] Among them, the TEE is a security area divided on the main processor of the computing device, which can guarantee the security, confidentiality and integrity of the code and data loaded into the TEE. The execution space provided by the TEE has a higher level of security than the space provided by the common mobile operating system (such as Linux, Android, etc.). The implementation of the TEE includes the TrustZone based on advanced risc machines (ARM), the software guard extensions (SGX) introduced by Intel, etc.

[0122] The TEE is protected by a hardware mechanism, which provides a protected memory and an isolated execution environment, thereby being able to provide reliable security and privacy guarantees. The TEE can only be crashed and cannot appear Byzantine error, therefore, the consensus node device implements the Raft consensus algorithm in the TEE, which can avoid the Byzantine error of the node device, and further avoid the Byzantine error in the blockchain system.

[0123] In the Raft consensus algorithm, each consensus node device reaches consensus through log replication, and each consensus node device stores a log sequence and a blockchain ledger of the blockchain system, which both occupy a certain storage space. Especially after the blockchain system runs for a long time, the logs in the blockchain system and the blocks on the blockchain ledger will become more and more. However, the TEE is a region on the main processor, and its storage resource is limited, and the storage space in the TEE can not bear more and more logs and blocks. Based on this, the present application proposes to finely granularly split the algorithm implementation (such as a computer program for implementing the Raft consensus algorithm) of the Raft consensus algorithm, to protect the core process implementation (such as a computer program for implementing the election mechanism and a computer program for implementing the log replication mechanism) of the Raft consensus algorithm in the TEE, and to perform the input and output (IO) layer of the Raft consensus algorithm on the REE side, so as to guarantee the security of the Raft consensus algorithm, minimize the dependence on the TEE, and guarantee the algorithm efficiency and performance.

[0124] For example Figure 3 The consensus cluster shown in the embodiment of the present application provides a consensus cluster schematic diagram based on the TEE implementation of the Raft consensus algorithm, as shown in Figure 3 . The consensus cluster shown in the embodiment of the present application provides a consensus cluster schematic diagram based on the TEE implementation of the Raft consensus algorithm, as shown in Figure 3 The consensus cluster shown in the embodiment of the present application provides a consensus cluster schematic diagram based on the TEE implementation of the Raft consensus algorithm, as shown in

[0125] To further illustrate the core process of the TEE implementation of the Raft consensus algorithm, the REE implementation of the message IO process, as shown in Figure 4 The consensus node device shown in the embodiment of the present application provides a schematic diagram of a consensus node device based on the TEE implementation of the Raft consensus algorithm, Figure 4The execution environment of each consensus node device in the illustrated consensus cluster includes a TEE and a REE. Each consensus node device implements the core logic of the Raft consensus algorithm in the TEE, which includes legitimate verification logic, timeout detection logic, log sequence maintenance logic, election logic, configuration logic of the consensus cluster, and state maintenance logic of the consensus cluster. Among them, the legitimate verification logic is used to verify whether the message content delivered by other consensus node devices is legitimate, and to verify whether the identity certificate (such as a digital signature) of other consensus node devices is legitimate. The timeout detection logic uses a timer principle to detect whether the latest election time has arrived or timed out, and if so, initiates an election. The log sequence maintenance logic is used to maintain the log sequence. The configuration logic of the consensus cluster is used to maintain the node information of each consensus node device in the consensus cluster, such as the public key, address information, etc. of each consensus node device. The election logic is used to implement the start of the election process or voting for a candidate node. The state maintenance logic of the consensus cluster is used to maintain the node state (or role) of each consensus node device in the consensus cluster in real time. For example, a node tracker is used to maintain the node state of each consensus node device in the blockchain system in real time.

[0126] Each consensus node device implements the IO layer logic of the Raft consensus algorithm in the REE. For example, the REE is provided with a proposer module, a storage module, a message scheduling module, and a communication module, wherein the proposer module is used to generate blocks. The storage module includes a memory and a persistent storage medium, the memory is used to store the blocks generated by the proposer module. The persistent storage medium is used to store the blockchain ledger of the local blockchain system, the snapshot of the log sequence, and the write-ahead logging, etc., wherein the blockchain ledger is also the configured blockchain in the blockchain system. The communication module, which can also be referred to as a network module, is used to communicate with other consensus node devices, such as remote procedure call (RPC) between consensus clusters. The message scheduling module is used to complete the message scheduling between various modules within the consensus node device. In a possible implementation manner, the message scheduling module can follow the Event Loop mechanism to perform the message scheduling within the consensus node device.

[0127] For example, in the Raft consensus algorithm, the proposer module is used to generate a block proposal, and the storage module is used to store the block proposal. The message scheduling module is used to complete the message scheduling between the proposer module and the storage module. Figure 4The client transmits a fifth request to a consensus node device acting as a leader (i.e., a leader node), where the fifth request is used to indicate a transaction between at least two blockchain accounts. A proposal module in the leader node generates a block based on the fifth request, sends the block to a memory in a storage module via a message scheduling module, and sends an identification of the block to a TEE. The TEE then generates a log of the block based on the identification of the block, stores the log in a log sequence, and sends the log to the proposal module via the message scheduling module. The proposal module obtains the block corresponding to the log from the memory, and sends the log and the block to non-leader nodes in the consensus cluster via the message scheduling module and a communication module. The communication module in the non-leader nodes receives the log and the block, sends the log and the block to the message scheduling module, which stores the block in the storage module and sends the log to the TEE of the non-leader nodes. The TEE determines whether to accept the log.

[0128] For further illustration, the process of electing a leader node by a consensus node device in a blockchain system is described with reference to Figure 5 The leader node election method provided by the embodiments of the present application is shown in the flowchart of FIG. 1.

[0129] 501. At startup, the TEE of the first node device initializes node information of each consensus node device in the consensus cluster, a node state of the first node device, an election time of the first node device, and an initial term of the first node device.

[0130] The first node device is any consensus node device in the consensus cluster of the blockchain system. The node information of each consensus node device includes a node identifier of a consensus node device, address information of the consensus node device, and a public key of the consensus node device. The node identifier of each consensus node device is used to uniquely indicate a consensus node device. The address information of each consensus node device can be an Internet protocol (IP) address of each consensus node device.

[0131] The node state of each consensus node device in the consensus cluster includes a follower state, a candidate state, or a leader state. The follower state is used to indicate that the consensus node device is a follower node, the candidate state is used to indicate that the consensus node device is a candidate node, and the leader state is used to indicate that the consensus node device is a leader node. At startup, the node state of the first node device is the follower state, the election time of the first node device is the time when the first node device is elected to become a leader node in the blockchain system (or the consensus cluster). The initial term of the first node device is the initial term of the first node device, which can be 0 or any integer greater than 0.

[0132] In a possible implementation, the TEE is triggered to perform the step 501 by the REE in the first node device. For example, the process shown in steps 5011-5013 below.

[0133] Step 5011, when the node starts, the REE in the first node device generates a sixth request, which indicates the node information of each consensus node device in the consensus cluster, the node state of the first node device, the election time of the first node device, and the initial term of the first node device.

[0134] The sixth request carries the node information of each consensus node device in the consensus cluster.

[0135] In a possible implementation, the REE of the first node device stores a blockchain ledger in the blockchain system, and the REE obtains the node information of each consensus node device in the consensus cluster from the blockchain ledger. For example, the consensus cluster configuration information is obtained from a genesis block in the blockchain ledger, where the genesis block is the first block on the blockchain ledger.

[0136] After obtaining the node information of each consensus node device in the consensus cluster, the REE generates the sixth request based on the node information of each consensus node device in the consensus cluster.

[0137] Step 5012, the REE of the first node device sends the sixth request to the TEE of the first node device.

[0138] In a possible implementation, the REE of the first node device calls an initialization configuration interface between the REE and the TEE, and sends the sixth request to the initialization configuration interface. The initialization configuration interface can be located in a message scheduling module in the REE, and the message scheduling module sends the sixth request to the initialization configuration interface so that the TEE receives the sixth request from the initialization configuration interface.

[0139] Step 5013, the TEE of the first node device receives the sixth request, and initializes the node information of each consensus node device in the consensus cluster, the node state of the first node device, the election time of the first node device, and the initial term of the first node device based on the sixth request.

[0140] In a possible implementation, the TEE of the first node device receives the sixth request from the initialization configuration interface.

[0141] When receiving the sixth request, the TEE of the first node device parses node information of each consensus node device in the consensus cluster from the sixth request, and stores the node information of each consensus node device in the consensus cluster based on the indication of the sixth request, to complete node information configuration.

[0142] The TEE of the first node device initializes a node state of the first node device based on the indication of the sixth request, for example, stores the node state of the first node device as a follower state by the TEE of the first node device.

[0143] In a possible implementation, the TEE of the first node device obtains node identifiers of each consensus node device in the consensus cluster from the node information of each consensus node device in the consensus cluster. The TEE of the first node device creates a state table based on the node identifiers of the consensus node devices. The state table is used to record a correspondence between node states of each consensus node device in the consensus cluster and the node identifiers of each consensus node device. For example, the first node device can store the node identifier of the first node device and an identifier of the follower state in the state table in association, to indicate that the node state of the first node device is the follower state. It should be noted that initially, the first node device does not know the node states of other consensus node devices in the consensus cluster, and the first node device can record the node states of the other consensus node devices as the follower state in the state table.

[0144] The TEE of the first node device generates an election time of the first node device according to a first preset rule based on the indication of the sixth request, and records the election time. The first preset rule can be a random generation rule or other preset rules. In this embodiment of the application, the first preset rule is not limited.

[0145] The TEE of the first node device generates and records an initial term of the first node device based on the indication of the sixth request, for example, takes 0 as the initial term of the first node device.

[0146] In a possible implementation, the TEE of the first node device sends the election time of the first node device to the REE of the first node device, and the REE of the first node device receives and stores the election time.

[0147] It should be noted that each consensus node device in the blockchain system can initialize the node information of each consensus node device in the consensus cluster, the respective node state, the respective election time, and the respective initial term by the step 501 when starting. Each consensus node device can execute the step 501 once when starting, and does not need to be repeatedly executed.

[0148] 502. The TEE of the first node device generates a second request indicating a vote for the first node device to become a leader node in the blockchain system.

[0149] The second request includes a first term of the first node device, where the first term corresponds to a term of the current election process initiated by the first node device.

[0150] In a possible implementation, if a notification message from a leader node in the consensus cluster is not received within a preset time period, it indicates that there is no leader node in the consensus cluster at this time, where the notification message indicates that a node device in the blockchain system is a leader node in the blockchain system.

[0151] Since only one leader node is allowed in the consensus cluster at the same time, if a notification message from a leader node in the consensus cluster is not received within a preset time period, and the election time of the first node device recorded in the TEE of the first node device has arrived or has timed out, the TEE of the first node device generates the second request. Where the election time has arrived means that the current time is the election time recorded in the TEE, and the election time has timed out means that the current time is later than the election time recorded in the TEE.

[0152] In the case where the TEE cannot call the REE, and the REE can call the TEE (for example, in the TrustZone technology based on ARM, the REE calls the TEE, and the TEE cannot call the REE), the action of generating the second request in the TEE of the first node device is triggered by the REE, for example, the process described in steps 5021-5024.

[0153] Step 5021, if the election time of the first node device recorded in the REE of the first node device has arrived or has timed out, the REE of the first node device generates a first message for prompting the TEE to start the election process of the first node device.

[0154] The election process of the first node device refers to the process of electing the first node device to become a leader node in the blockchain system.

[0155] In a possible implementation, when the election time of the first node device sent by the TEE of the first node device is received, the REE of the first node device records the election time of the first node device and starts a countdown. If the election time has arrived or has timed out, and no notification message from a leader node in the consensus cluster is received within a preset time period, the REE of the first node device generates the first message.

[0156] Step 5022, the REE of the first node device sends a first message to the TEE of the first node device.

[0157] For example, the proposal module in the REE of the first node device generates the first message, and sends the first message to the TEE of the first node device through the message scheduling module.

[0158] Step 5023, the TEE of the first node device receives the first message and verifies the first message.

[0159] For example, the TEE of the first node device receives the first message from the message scheduling module.

[0160] When receiving the first message, the TEE of the first node device verifies the first message based on the recorded election time of the first node device. For example, if the recorded election time of the TEE of the first node device has reached or has timed out, the TEE of the first node device verifies the first message as passed.

[0161] If the recorded election time of the TEE of the first node device has not reached, it means that the first node device has tampered with the election time of the first node device in the REE, and a Byzantine error occurs. Therefore, if the recorded election time of the TEE of the first node device has not reached, the TEE of the first node device verifies the first message as failed. If the TEE of the first node device verifies the first message as failed, the subsequent steps are no longer executed.

[0162] Step 5024, in the case where the first message passes the verification of the TEE of the first node device, the TEE of the first node device generates the second request.

[0163] In the case where the first message passes the verification of the TEE of the first node device, the TEE of the first node device increases the recorded term of the first node device by a first preset value to obtain the first term of the first node device. The first preset value is the difference between adjacent terms, and the first preset value can be 1 or other values. The first preset value can be set according to the actual application scenario, and in this embodiment, the first preset value is not limited.

[0164] The TEE of the first node device updates the recorded term of the first node device to the first term, and generates the second request based on the first term, wherein the second request carries the first term.

[0165] In another possible implementation, to avoid the content carried by the second request being tampered with after the second request leaves the TEE of the first node device, the TEE of the first node device signs the second request based on the private key of the first node device to obtain a digital signature of the second request.

[0166] For the process shown in steps 5021-5024, even if the REE of the first node device has a Byzantine error, for example, the timer in the REE is tampered with so that the time recorded by the timer reaches the election time in advance, triggering the REE to send the first message to the TEE. However, since the TEE of the first node device further verifies whether the recorded election time has arrived or has timed out, if the first message fails to pass the verification of the TEE of the first node device, the TEE of the first node device will not generate the second request, thereby avoiding the first node device initiating an election in advance in the consensus cluster.

[0167] It should be noted that when the TEE of the first node device generates the second request and initiates an election, the TEE of the first node device updates the recorded node state of the first node device from the follower state to the candidate state, for example, the TEE of the first node device updates the identifier of the node state corresponding to the first node device in the state table to the identifier of the candidate state.

[0168] 503、the TEE of the first node device sends the second request to the second node device in the blockchain system through the REE of the first node device.

[0169] Among them, the second node device in the blockchain system is each consensus node device in the consensus cluster except the first node device, and the second node device in the blockchain system can be at least one.

[0170] In a possible implementation, the present step 503 is performed by steps 5031-5032 as follows.

[0171] Step 5031, the TEE of the first node device sends the second request to the REE of the first node device.

[0172] In a possible implementation, the TEE of the second node device sends the second request and the digital signature of the second request to the REE of the first node device. For example, the TEE of the first node device sends the second request and the digital signature of the second request to the message scheduling module in the REE of the first node device.

[0173] Step 5032, the REE of the first node device receives the second request and sends the second request to the second node device in the blockchain system.

[0174] In a possible implementation, the REE of the second node device receives the second request and the digital signature of the second request. For example, a message scheduling module in the REE of the first node device receives the second request and the digital signature of the second request, the message scheduling module sends the second request and the digital signature of the second request to a communication module, and the communication module sends the second request and the digital signature of the second request to the second node device in the blockchain system.

[0175] 504、The TEE of the second node device receives the second request through the REE of the second node device.

[0176] In the steps 504-506, the second node device is any second node device in the blockchain system, that is, each second node device in the blockchain system performs the process shown in the steps 504-506.

[0177] In a possible implementation, the step 504 is implemented by the following steps 5041-5043.

[0178] Step 5041, the REE of the second node device receives the second request.

[0179] In a possible implementation, the REE of the second node device receives the second request and the digital signature of the second request. For example, a communication module in the REE of the second node device receives the second request and the digital signature of the second request, and the communication module sends the second request and the digital signature of the second request to a message scheduling module in the REE.

[0180] Step 5042, the REE of the second node device sends the second request to the TEE of the second node device.

[0181] In a possible implementation, the REE of the second node device sends the second request and the digital signature of the second request to the TEE of the second node device. For example, the message scheduling module in the REE of the second node device sends the received second request and the digital signature of the second request to the TEE of the second node device.

[0182] Step 5043, the TEE of the second node device receives the second request.

[0183] In a possible implementation, the TEE of the second node device receives the second request and the digital signature of the second request. For example, the TEE of the second node device receives the second request and the digital signature of the second request from a message scheduling module in the REE of the second node device.

[0184] 505、The TEE of the second node device verifies the second request.

[0185] In a possible implementation, the TEE of the second node device queries the public key of the first node device from the stored node information of the first node device. The TEE of the second node device verifies the second request based on the public key of the first node device. For example, the TEE of the second node device verifies the digital signature of the second request based on the public key of the first node device, and if the verification succeeds, the TEE of the second node device verifies the second request. If the verification fails, it indicates that the content of the second request has been tampered with, and the TEE of the second node device does not verify the second request.

[0186] 506、In a case where the second request passes the verification of the TEE of the second node device, the TEE of the second node device sends, through the REE of the second node device, a second response to the first node device, where the second response indicates whether the second node device agrees that the first node device becomes a leader node in the blockchain system.

[0187] The second response carries a first vote identifier or a second vote identifier. The first vote identifier indicates that the second node device agrees that the first node device becomes a leader node in the blockchain system, and the first vote identifier is a vote of approval. The second vote identifier indicates that the second node device does not agree that the first node device becomes a leader node in the blockchain system, and the second vote identifier is a vote of disapproval.

[0188] Each consensus node device in the consensus cluster has the right to cast a vote of approval once when electing a leader node. In each election, each consensus node device casts a vote of approval for a candidate node with a higher term than itself, or casts a vote of approval for itself.

[0189] In a possible implementation, in a case where the second request passes the verification of the TEE of the second node device, the TEE of the second node device parses the first term of the first node device from the second request. The TEE of the second node device generates the second response based on the term of the second node device and the first term.

[0190] For example, if the first term is greater than the term of the second node device, and the second node device has not cast a vote of approval for a candidate node other than the first node device, the TEE of the second node device generates the second response carrying the first vote identifier, otherwise, the TEE of the second node device generates the second response carrying the second vote identifier.

[0191] Further, in order to avoid the content of the second response being tampered after leaving the TEE of the second node device, the TEE of the second node device signs the second response based on the private key of the second node device to obtain a digital signature of the second response.

[0192] In a possible implementation, the TEE of the second node device sends the second response to the first node device, or sends the second response and the digital signature of the second response, through the REE of the second node device, for example, the process shown in steps 5061-5062.

[0193] Step 5061, the TEE of the second node device sends the second response to the REE of the second node device.

[0194] In a possible implementation, the TEE of the second node device sends the second response and the digital signature of the second response to the REE. For example, the TEE of the second node device sends the second response and the digital signature of the second response to the message scheduling module in the REE of the second node device.

[0195] Step 5062, the REE of the second node device receives the second response and sends the second response to the first node device.

[0196] In a possible implementation, the REE of the second node device receives the second response and the digital signature of the second response, and sends the second response and the digital signature of the second response to the first node device. For example, if the message scheduling module in the REE of the second node device receives the second response and the digital signature of the second response, the message scheduling module sends the second response and the digital signature of the second response to the communication module in the REE, and the communication module sends the second response and the digital signature of the second response to the first node device.

[0197] It should be noted that, in the case that the second request passes the verification of the TEE of the second node device, it is indicated that the first node device is in the candidate state, and the TEE of the second node device updates the recorded node state of the first node device from the follower state to the candidate state.

[0198] 507, the TEE of the first node device receives a plurality of second responses through the REE of the first node device.

[0199] Each of the plurality of second responses is from a second node device in the consensus cluster.

[0200] In a possible implementation, the TEE of the first node device receives each second response and a digital signature of each second response in the plurality of responses via the REE of the first node device. The process shown in step 507 is the same as the process of the TEE of the second node device receiving the second request via the REE of the second node device in step 504, and thus the embodiments of the present application will not repeat the step 507.

[0201] 508. The TEE of the first node device verifies each received second response.

[0202] The step 508 is described as follows by taking the TEE of the first node device verifying the second response of a second node device as an example.

[0203] The TEE of the first node device queries the public key of the second node device from the stored node information of the second node device, and verifies the second response based on the public key of the second node device.

[0204] For example, the TEE of the first node device verifies the digital signature of the second response of the second node device based on the public key of the second node device. If the verification is successful, the TEE of the first node device verifies the second response successfully. If the verification fails, it means that the content of the second response has been tampered with, and the TEE of the first node device does not verify the second response.

[0205] 509. In the case that the second responses of the half or more of the second node devices in the blockchain system pass the verification of the TEE, and each second response that passes the verification indicates that a second node device agrees that the first node device becomes the leader node in the blockchain system, the TEE of the first node device switches the node state of the first node device to the leader state.

[0206] In a possible implementation, in the case that the second responses of the half or more of the second node devices in the blockchain system pass the verification of the TEE, the TEE of the first node device parses the second response of the second node device to obtain the voting identifier carried by the second response.

[0207] The first node device's TEE counts the total number of the first vote identifiers in the second response of the TEE statistical verification pass, where the total number is also the total number of the second node devices in the consensus cluster that cast a yes vote for the first node device to become the leader node. The first node device's TEE determines whether the total number is greater than a first threshold, where the first threshold is the number of half of the second node devices in the consensus cluster. Since the first node device casts a yes vote for the first node device to become the leader node in the blockchain system, it is also the first node device casting a yes vote for the first node device. If the total number counted is greater than or equal to the first threshold, and considering that the first node device casts a yes vote for the first node device to become the leader node, it means that the majority of the consensus node devices in the consensus cluster agree that the first node device becomes the leader node in the blockchain system, and the first node device's TEE switches the node state of the first node device from the candidate state to the leader state.

[0208] For example, the first node device's TEE updates the identifier of the follower state of the first node device recorded in the state table to the identifier of the leader state, at which time the first node device is the leader node in the blockchain system.

[0209] 510. The first node device's TEE generates a notification message, where the notification message indicates that the first node device is the leader node in the blockchain system.

[0210] The notification message is a heartbeat message or a message of another type other than a heartbeat message. The notification message includes the first term of the first node device.

[0211] In a possible implementation, the first node device's TEE generates the notification message based on the first term.

[0212] In a possible implementation, the action of the first node device's TEE generating the notification message is triggered by the first node device's REE, for example, the process shown in steps 5101-5103 below.

[0213] Step 5101. If the target duration recorded in the first node device's REE has reached or has timed out, the first node device's REE generates a second message, where the second message is used to prompt the TEE to send a notification message to the second node device in the blockchain system.

[0214] The target duration is the duration of the periodic sending of the notification message by the leader node in the consensus cluster, that is, the leader node sends a notification message in the consensus cluster once every target duration to inform each consensus node device in the consensus cluster of the existence of the leader node.

[0215] When the first node device becomes the leader node in the blockchain system, the TEE of the first node device notifies the REE of the first node that the first node device has become the leader node in the blockchain system. When the REE of the first node device receives the notification of the TEE, a countdown is started, and if the target time length has reached or has expired, the REE of the first node device sends the second message to the TEE of the first node device.

[0216] Step 5102, the TEE of the first node device receives the second message and verifies the second message.

[0217] When the TEE of the first node device receives the second message, if the target time length recorded in the TEE of the first node device has reached or expired, it indicates that the REE of the first node device has not tampered with the target time length, and the TEE of the first node device verifies the second message successfully. If the target time length recorded in the TEE of the first node device has not reached, it indicates that the REE of the first node device has tampered with the target time length and sent the second message in advance, and the TEE of the first node device verifies the second message unsuccessfully.

[0218] Step 5103, in the case that the second message passes the verification of the TEE of the first node device, the TEE of the first node device generates the notification message.

[0219] For example, in the case that the second message passes the verification of the TEE of the first node device, the TEE of the first node device generates the notification message based on the first term.

[0220] In another possible implementation, in order to avoid the content of the notification message being tampered with after leaving the TEE of the first node device, the TEE of the first node device signs the notification message based on the private key of the first node device to obtain the digital signature of the notification message.

[0221] 511, the TEE of the first node device sends the notification message to the second node device in the blockchain system through the REE of the first node device.

[0222] In a possible implementation, the TEE of the first node device sends the notification message and the digital signature of the notification message to the second node device in the blockchain system through the REE of the first node device.

[0223] The process shown in this step 511 is the same as the process in which the TEE of the first node device sends the second request to the second node device in the blockchain system through the REE of the first node device in step 503, and here, the embodiments of the present application will not repeat the step 511.

[0224] 512. The TEE of the second node device receives the notification message via the REE of the second node device.

[0225] In a possible implementation, the TEE of the second node device receives the notification message and the digital signature of the notification message via the REE of the second node device.

[0226] The second node device in steps 512-514 is any second node device in the blockchain system, i.e., each second node device in the blockchain system performs the process shown in steps 512-514.

[0227] The process shown in this step 512 is the same as the process of the TEE of the second node device receiving the second request via the REE of the second node device in step 504, and thus the embodiments of the present application will not repeat the process of this step 512.

[0228] 513. The TEE of the second node device verifies the notification message.

[0229] In a possible implementation, the TEE of the second node device verifies the notification message based on the public key of the first node device. For example, the TEE of the second node device verifies the digital signature of the notification message based on the public key of the first node device. If the verification is successful, the TEE of the second node device verifies the notification message successfully. If the verification fails, it indicates that the content of the notification message has been tampered with, and the TEE of the second node device fails to verify the notification message.

[0230] 514. In the case where the notification message passes the verification of the TEE of the second node device, the TEE of the second node device modifies the stored node state of the first node device to a leader state.

[0231] For example, the TEE of the second node device modifies the identifier of the follower state corresponding to the first node device in the state table to an identifier of a leader state, and at this time, the leader node in the blockchain system is the first node device for the second node device. The TEE of the second node device can also update the identifiers of the node states of each consensus node device in the state table except the first node device to identifiers of follower states, to indicate that each consensus node device in the consensus cluster except the first node device is a follower node.

[0232] In a possible implementation, in a case where the notification message passes the verification of the TEE of the second node device, the TEE of the second node device parses the first term of the first node device from the notification message. The TEE of the second node device updates the recorded term of the second node device to the first term, so that after the first node device becomes the leader node in the blockchain system, the consensus node devices in the blockchain system take the term of the leader node as the respective latest term.

[0233] The method provided by the embodiments of the present application generates the second request by the TEE of the node device in the blockchain system, and sends the second request to other node devices in the blockchain system to initiate the election. Since the TEE does not have the Byzantine error, the Byzantine error does not occur when the TEE generates the second request, thereby avoiding the malicious initiation of the election by the participating node device and reducing the Byzantine error in the blockchain system. Moreover, after the TEE of the node device triggers the TEE to initiate the election, the TEE further verifies whether the election time is truly reached, thereby avoiding the situation that the election is initiated in advance due to the malicious tampering of the election time in the RRE. Moreover, the TEE of the first node device sends the message (such as the second request, the second response or the notification message) and the digital signature of the message to the second node device, and the second node device verifies the message based on the digital signature of the message, thereby avoiding the tampering of the content of the message after the message leaves the TEE of the first node device.

[0234] To further illustrate Figure 5 the process, refer to Figure 6The embodiment of the application shown provides a schematic diagram of a leader node election process. When each consensus node device in the blockchain system is started, the REE of each consensus node device calls an initialization interface, triggering the TEE of each consensus node device to perform an initialize consensus (initconsensus) configuration (for example, the process shown in steps 5011-5013 described above), and the TEE of each consensus node device also sends an election time to the REE of the consensus node device, so that the REE starts a countdown. When the election time of the first follower node (i.e., the follower node with the closest election time at the initial time) in the blockchain system arrives, the REE of the follower node calls a timeout interface, prompting the TEE of the follower node to initiate an election. The TEE of the follower node further verifies whether the election time is truly arrived or timed out, to ensure the correctness of the timeout mechanism. When the election time is truly arrived or timed out, the follower node becomes a candidate node. The TEE of the candidate node increases the term of the candidate node, and generates a second request according to the increased term. The TEE of the candidate node sends the second request to the REE of the candidate node through an output interface. The REE of the candidate node receives the second request and sends the second request to non-leader nodes in the consensus cluster except the candidate node. The REE of the non-leader node receives the second request and sends the second request to the TEE of the non-leader node by calling an input interface. The TEE of the non-leader node determines whether to vote for the candidate node according to its own term, and sends a second response to the REE of the non-leader node through an output interface. The REE of the non-leader node receives and sends the second response to the candidate node. The REE of the candidate node receives the second response sent by the non-leader node device and sends the received second response to the TEE of the candidate node through an input interface. The TEE of the candidate node counts the number of non-leader nodes in the consensus cluster that vote for the candidate node based on the received second responses, and if a majority of non-leader nodes in the consensus cluster vote, the candidate node becomes the leader node in the blockchain system. The REE of the leader node checks whether the heartbeat duration (such as the target duration) arrives, and if it arrives, prompts the TEE of the leader node to generate heartbeat information (such as a notification message). After receiving the prompt from the REE, the TEE of the leader node first verifies whether the heartbeat duration is truly arrived, and if it is truly arrived, the TEE of the leader node generates the heartbeat information and sends the heartbeat message to the REE of the leader node through an output interface. The REE of the leader node receives and sends the heartbeat message to the non-leader nodes in the consensus cluster.The non-leader node's REE receives the heartbeat message, sends the heartbeat message to the non-leader node's TEE by calling the input interface, and when the non-leader node's TEE receives the heartbeat message, it indicates that a leader node has been generated in the blockchain system, and the non-leader node becomes a follower node, and the non-leader node's TEE records the information of the leader node.

[0235] The leader node in the consensus cluster is used to generate a block, and each consensus node device in the consensus cluster is used to consensus the block. In order to further illustrate the process of block consensus, refer to Figure 7 The flowchart of the data processing method provided by the embodiment of the application is shown.

[0236] 701, if the first node device is a leader node in the blockchain system, the REE of the first node device acquires the fifth request of the terminal.

[0237] The fifth request indicates a transaction between at least two blockchain accounts. The terminal is a user device other than the first node device, or is the first node device.

[0238] The terminal has a client installed therein, and the user issues a transaction instruction of a transaction between at least two blockchain accounts to the client. When the transaction instruction is received, the client generates the fifth request based on the transaction instruction. If the first node device is the terminal, the first node device acquires the fifth request from the client.

[0239] If the first node device is a user device other than the first node device, the terminal acquires the fifth request from the client and sends the fifth request to the first node device, and correspondingly, the REE of the first node device receives the fifth request. Alternatively, the terminal sends the fifth request to any second node device in the blockchain system, and when the REE of the second node device receives the fifth request of the terminal, the TEE of the second node device sends the fifth request to the TEE of the second node device. The TEE of the second node device sends the fifth request to the first node device through the REE of the second node device, and correspondingly, the REE of the first node device receives the fifth request from the second node device.

[0240] 702, the REE of the first node device generates a block based on the fifth request, and caches the block.

[0241] The block is any block generated by the first node device, and the block includes at least one transaction event, and each transaction event indicates that a transaction between at least two blockchain accounts has been completed.

[0242] In a possible implementation, the REE of the first node device performs a transaction between at least two blockchain accounts based on the indication of the fifth request, to obtain a transaction event corresponding to the fifth request. The REE of the first node device packs the transaction event into a block body, or packs the transaction event and at least one transaction event in an event pool into a block body, where the event pool includes a plurality of transaction events to be packed. The REE of the first node device adds a block header on the block body based on each transaction event in the block body, to obtain the block. The block header includes a hash value of the block and a block number of the block, the hash value of the block is obtained based on hash values of each transaction event in the block body, and the block number of the block is 1 greater than a block number of a last block in a local blockchain ledger of the blockchain system. The block number of any block in the blockchain ledger indicates a position of the block in the blockchain ledger, and the block number of any block can also be referred to as a block height of the block.

[0243] In a possible implementation, when the block is generated, the REE of the first node device caches the block in the memory.

[0244] In a possible implementation, the process shown in step 702 is performed by a proposal module in the REE of the first node device.

[0245] 703. The REE of the first node device sends an identifier of the block to the TEE of the first node device.

[0246] The identifier of the block is used to refer to the block. In a possible implementation, the identifier of the block includes at least one of a hash value of the block and a block number of the block.

[0247] In a possible implementation, the REE of the first node device generates a third message indicating that the consensus cluster performs consensus on the block. The third message carries the identifier of the block. The REE of the first node device sends the third message to the TEE of the first node device.

[0248] In a possible implementation, step 703 is performed by a proposal module in the REE of the first node device, for example, the proposal module generates a third message based on the identifier of the block in the block, sends the third message to a message scheduling module in the REE of the first node device, and the message scheduling module sends the third message to the TEE of the first node device.

[0249] 704. The TEE of the first node device receives the identifier of the block, and generates a log of the block based on the identifier of the block, where the log refers to the block by the identifier of the block.

[0250] The log includes an identifier of the block but does not include the block, and the log refers to the block by the identifier of the block but does not include the block. For example, the identifier of the block includes at least one of a hash value of the block and a block number of the block, and of course, the identifier of the log can also be other forms of representation other than the hash value of the block or the block number, and the application does not limit the identifier of the log.

[0251] Since the log in the application refers to the block by the identifier of the block, the log in the application does not include the block. The log in the related art does not refer to the log by the identifier of the block, but directly adds the block in the log, that is, the log in the related art includes the block. Or it can also be understood that the application replaces the block in the log in the related art with the identifier of the block. The data amount of the identifier of the block is smaller than that of the entire block, so compared with the log in the related art, the data amount of the log in the application is smaller.

[0252] In a possible implementation, the log further includes at least one of an index of the log and a term in office of the first node device.

[0253] In a possible implementation, the TEE of the first node device receives the third message, the TEE of the first node device parses the identifier of the block from the third message, and generates the log based on the identifier of the block.

[0254] For example, the TEE of the first node device stores a log sequence of the first node device, the TEE of the first node device generates a target index based on an index of a last log in the log sequence, and the TEE of the first node device generates the log based on the target index and the identifier of the block. The TEE of the first node device adds the log in the log sequence.

[0255] The target index is the index of the log, and the target index is greater than the index of the last log in the log sequence by a second preset value. The second preset value is a difference between indexes of two adjacent logs in the log sequence, and the second preset value can be 1 or other values. The second preset value can be set according to an actual application scenario, and the embodiments of the application do not limit the second preset value.

[0256] In a possible implementation, the TEE of the first node device records a state of the log as an uncommitted state, to indicate that the block corresponding to the log has not been committed to the block chain ledger of the local block chain system.

[0257] It should be noted that the steps 703-704 are one way for the TEE of the first node device to generate the log of the block in the REE of the first node device based on the block.

[0258] In another possible implementation, the TEE of the first node device generates the log of the block in the REE of the first node device based on the block includes that the REE of the first node device sends a third message to the TEE of the first node device, the third message including the block. The TEE of the first node device obtains the identity of the block from the block carried by the third message, and generates the log of the block based on the identity of the block. When the log is generated, the TEE of the first node device discards the block.

[0259] The third message including the identity of the block has much less data than the third message including the block, for example Figure 8 A different third message data amount comparison diagram provided by the embodiments of the present application is shown in FIG. 6, Figure 8 The data amount of the third message including the block in FIG. 6 can reach 2M, and the data amount of the third message including the identity of the block is 200 bytes (bytes). Therefore, the REE sends the identity of the block to the TEE, which can reduce the data amount of the interaction between the TEE and the REE.

[0260] 705、The TEE of the first node device sends the log to the REE of the first node device.

[0261] In a possible implementation, the TEE of the first node device generates a first target message based on the log, the first target message carrying the log, the first target message indicating the second node device in the blockchain system to process the log and the block corresponding to the log, and the TEE of the first node device sends the first target message to the REE of the first node device.

[0262] In another possible implementation, in order to avoid the content of the first target message being tampered with after the first target message leaves the TEE of the first node device, the TEE of the first node device signs the first target message based on the private key of the first node device to obtain the digital signature of the first target message. Correspondingly, the TEE of the first node device sends the first target message and the digital signature of the first target message to the REE of the first node device.

[0263] 706、The REE of the first node device receives the log, sends a first request to the second node device in the blockchain system, the first request carrying the log, and the first request indicating the second node device to process the log.

[0264] In a possible implementation, the REE of the first node device receives a first target message, and queries, based on the log carried by the first target message, a block indicated by the identifier of the block in the log in the memory. The REE of the first node device generates the first request based on the queried block and the first target message, where the first request carries the block and the first target message, and the first request indicates processing of the block and the log of the block.

[0265] If the REE of the first node device further receives a digital signature of the first target message, the REE of the first node device generates the first request based on the queried block, the first target message, and the digital signature of the first target message, where the first request carries the block, the first target message, and the digital signature of the first target message, and the first request indicates processing of the block and the log of the block.

[0266] When the REE of the first node device generates the first request, the first request is sent to a second node device in the blockchain system.

[0267] To further reflect the difference between the first request and the log replication request, refer to FIG. 7, which is a comparison diagram of the first request and the log replication request according to an embodiment of the present application. As shown in FIG. 7, the log replication request carries the log of the block, and the log in the log replication request includes the index of the log and the block. The log in the log replication request is the log in the related art. The first request carries the block and the log of the block, and the log in the first request includes the identifier of the block and the index of the log, but does not include the block. Figure 9 Figure 9 As shown in FIG. 7, the log replication request carries the log of the block, and the log in the log replication request includes the index of the log and the block. The log in the log replication request is the log in the related art. The first request carries the block and the log of the block, and the log in the first request includes the identifier of the block and the index of the log, but does not include the block.

[0268] 707. The REE of the second node device receives the first request.

[0269] In steps 707-712, the second node device is any second node device in the blockchain system, that is, each second node device in the blockchain system performs the process shown in steps 707-712.

[0270] 708. The REE of the second node device caches the block in the first request.

[0271] For example, the REE of the second node device transfers the block carried by the first request to the memory.

[0272] 709. The REE of the second node device sends the log to the TEE of the second node device.

[0273] ​For example, the REE of the second node device sends a first request after the block to the TEE of the second node device, at this time, the first request no longer carries the block.

[0274] 710、The TEE of the second node device receives the log and verifies the log.

[0275] In a possible implementation, the TEE of the second node device receives the first request sent by the REE of the second node device, parses a first target message from the first request, or parses the first target message and a digital signature of the first target message.

[0276] The verification manner of the log by the TEE of the second node device includes any one of the following manners 1 or 2.

[0277] Manner 1, the TEE of the second node device stores a log sequence of the second node device, and verifies the log based on an index of a last log in the log sequence.

[0278] For example, the TEE of the second node device obtains the log from the target message, compares an index of the log with an index of the last log in the log sequence, and if the index of the log is greater than the index of the last log in the log sequence by a second preset value, the TEE of the second node device verifies the log as passed, otherwise, verifies the log as failed.

[0279] Manner 2, the TEE of the second node device verifies the log based on the index of the last log in the log sequence and a public key of the first node device.

[0280] If the first target message and the digital signature of the first target message are parsed from the first request, the TEE of the second node device verifies the first target message based on the public key of the first node device. If the verification succeeds, the TEE of the second node device verifies the first target message as passed. If the verification fails, it indicates that the content of the first target message has been tampered with, and the TEE of the second node device verifies the first target message as failed.

[0281] In a case where the first target message is verified by the TEE of the second node device, the TEE of the second node device acquires the log from the target message, and verifies the log in a case where an index of the log is greater than an index of the last log in the log sequence by a second preset value, or in a case where the index of the log is greater than the index of the last log in the log sequence by the second preset value and a term of the first node device carried by the log is the same as a term of a leader node in the blockchain system recorded by the TEE of the second node device.

[0282] 711. In a case where the log passes the verification by the TEE of the second node device, the TEE of the second node device stores the log.

[0283] In a case where the log passes the verification by the TEE of the second node device, the TEE of the second node device stores the log.

[0284] In a case where the log passes the verification by the TEE of the second node device, the TEE of the second node device stores the log.

[0285] In a case where the log does not pass the verification by the TEE of the second node device, the second node device does not perform the step 711.

[0286] 712. The TEE of the second node device sends, by the REE of the second node device, a first response to the first node device, the first response indicating that the second node device has agreed to receive the log.

[0287] The first response includes a first target identifier or a second target identifier, the first target identifier indicating that the second node device has agreed to receive the log, and the second target identifier indicating that the second node device does not agree to receive the log.

[0288] In a case where the log passes the verification by the TEE of the second node device, the TEE of the second node device generates the first response including the first target identifier, and the first response indicates that the second node device has agreed to receive the log. In a case where the log does not pass the verification by the TEE of the second node device, the TEE of the second node device generates the first response including the second target identifier, and the first response indicates that the second node device does not agree to receive the log.

[0289] Further, in order to avoid the content of the first response being tampered, the TEE of the second node device signs the first response based on the private key of the second node device to obtain a digital signature of the first response. Accordingly, the TEE of the second node device sends the first response and the digital signature of the first response to the first node device through the REE of the second node device.

[0290] The process of the TEE of the second node device sending the first response to the first node device through the REE of the second node device is the same as the process of the TEE of the second node device sending the second response to the first node device through the REE of the second node device in step 506. Here, the embodiments of the present application will not repeat the process of the TEE of the second node device sending the first response to the first node device through the REE of the second node device.

[0291] 713、The TEE of the first node device receives a plurality of first responses through the REE of the first node device.

[0292] Each of the plurality of first responses is from one second node device in the consensus cluster. In a possible implementation, the TEE of the first node device receives the plurality of first responses and the digital signature of each first response through the REE of the first node device.

[0293] The process of the TEE of the first node device receiving the plurality of first responses through the REE of the first node device is the same as the process of the TEE of the first node device receiving the plurality of second responses through the REE of the first node device in step 507. Here, the embodiments of the present application will not repeat the step 713.

[0294] 714、The TEE of the first node device verifies each received first response.

[0295] Taking the TEE of the first node device verifying the first response of one second node device as an example, the step 714 is introduced as follows:

[0296] The TEE of the first node device verifies the digital signature of the first response of the second node device based on the public key of the second node device. If the verification is successful, the TEE of the first node device verifies the first response successfully. If the verification fails, it means that the content of the first response has been tampered, and the TEE of the first node device does not verify the first response.

[0297] 715、In the case that the first responses of the half or more of the second node devices pass the verification of the TEE of the first node device, and each of the first responses that pass the verification indicates that one of the second node devices has agreed to receive the log, the TEE of the first node device instructs the REE to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log.

[0298] The block ledger of the local blockchain system of the first node device is stored in the REE of the first node device.

[0299] In one possible implementation, in the case that the first responses of the half or more of the second node devices pass the verification of the TEE of the first node device, the TEE of the first node device parses the first responses of the second node devices to obtain the target identification (e.g., the first target identification or the second target identification) carried by the first responses. The TEE of the first node device counts the total number of the first target identification in the first responses that pass the verification, where the total number is also the number of the second node devices in the consensus cluster that agree to receive the log. The TEE of the first node device determines whether the total number is greater than a first threshold. Since the TEE of the first node device has added the log to the log sequence of the first node device, the first node device has agreed to receive the log. Then, if the total number is greater than or equal to the first threshold, and considering that the first node device has agreed to receive the log, it indicates that the majority of the consensus node devices in the consensus cluster have agreed to receive the log, that is, the consensus cluster has passed the consensus on the log, that is, the consensus cluster has passed the consensus on the block corresponding to the log. The TEE of the first node device instructs the REE to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log.

[0300] For example, the TEE of the first node device generates a fourth message based on the identification of the block in the log, where the fourth message carries the identification of the block, and the fourth message instructs the REE of the first node device to submit the block to the blockchain ledger of the local blockchain system. The TEE of the first node device sends the fourth message to the REE of the first node device. Then, the REE of the first node device receives the fourth message, and queries the block cached in the memory based on the identification of the block carried by the fourth message, and stores the queried block in the blockchain ledger of the local blockchain system in the persistent storage medium.

[0301] Then, the TEE of the first node device updates the status of the recorded log to a submitted state to indicate that the block corresponding to the log has been submitted to the blockchain ledger of the blockchain system.

[0302] The TEEH of the first node device can also return a transaction success message to the terminal through the REE of the first node device, the transaction success message being used to indicate that the fifth request has been completed.

[0303] 716、The TEE of the first node device sends a third request to a second node device in the blockchain system through the REE of the first node device, the third request instructing the second node device to submit the block to a local blockchain ledger of the blockchain system.

[0304] The third request can be a heartbeat message or a message other than a heartbeat message.

[0305] In a possible implementation, the TEE of the first node device generates the third request based on the index of the log, the third request carrying the index of the log. Optionally, the third request also carries the first term of the first node device.

[0306] In another possible implementation, to avoid the content of the third request being tampered with after the third request leaves the TEE of the first node device, the TEE of the first node device signs the third request based on the private key of the first node device to obtain a digital signature of the third request. Accordingly, the TEE of the first node device sends the third request and the digital signature of the third request to the second node device in the blockchain system through the REE of the first node device.

[0307] The process in which the TEE of the first node device sends the third request to the second node device in the blockchain system through the REE of the first node device is the same as the process in which the TEE of the first node device sends the second request to the second node device in the blockchain system through the REE of the first node device in step 503, and here, the embodiments of the present application will not repeat the process in which the TEE of the first node device sends the third request to the second node device in the blockchain system through the REE of the first node device.

[0308] 717、The TEE of the second node device in the blockchain system receives the third request through the REE of the second node device.

[0309] The second node device in steps 717-719 is any second node device in the blockchain system, that is, each second node device in the blockchain system performs the process shown in steps 717-719.

[0310] In a possible implementation, the TEE of the second node device in the blockchain system receives the third request and the digital signature of the third request through the REE of the second node device.

[0311] The process of this step 717 is the same as the process that the TEE of the second node device receives the second request through the REE of the second node device in step 504, and here, embodiments of the present application will not repeat the step 717.

[0312] 718、The TEE of the second node device verifies the third request.

[0313] In a possible implementation, the TEE of the second node device verifies the digital signature of the third request based on the public key of the first node device. If the verification is successful, the TEE of the second node device verifies the third request. If the verification fails, it means that the content of the third request has been tampered with, and the TEE of the second node device does not verify the third request.

[0314] 719、In the case where the third request passes the verification of the TEE of the second node device, the TEE of the second node device notifies the REE of the second node device to submit the block in the log to the block chain ledger of the local block chain system based on the identification of the block in the log.

[0315] The process that the TEE of the second node device notifies the REE of the second node device to submit the block in the log to the block chain ledger of the local block chain system based on the identification of the block in the log is the same as the process that the TEE of the first node device notifies the REE of the first node device to submit the block in the log to the block chain ledger of the local block chain system based on the identification of the block in the log in step 715, and here, embodiments of the present application will not repeat the step 719.

[0316] In a possible implementation, in the case where the third request passes the verification of the TEE of the second node device, the TEE of the second node device parses the index of the log from the third request. The TEE of the second node device updates the recorded state of the log to a submission state based on the index of the log, to indicate that the block corresponding to the log has been submitted to the block chain ledger in the block chain system.

[0317] It should be noted that, Figure 7The process shown is described by taking the first request carrying the block and the log of the block as an example, and in another possible implementation, the TEE of the first node device can not send the block first when initiating the consensus node devices in the consensus cluster to consensus on the log, and after the log consensus is completed, the block is sent. For example, the first request does not carry the block, and the third request carries the block. For this case, when the second node device in the blockchain system receives the third request, the block in the third request is first transferred to the memory for caching, and then the TEE of the second node device sends the third request. Therefore, when a minority of consensus node devices in the consensus cluster agree to receive the log, the TEE of the first node device does not need to send the third request to the second node device in the blockchain system, thereby avoiding the first node device sending the consensus failed block to the second node device in the blockchain system.

[0318] The method provided by the embodiment of the application generates a log by the TEE of the node device in the blockchain system, and the REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that the other node devices consensus on the log. Since the TEE is protected by hardware and cannot be malicious, the purpose of protecting the consensus process by using the TEE can be achieved, and the Byzantine error in the blockchain system can be prevented. In addition, the block is referred to in the log by the identifier of the block, and the log does not need to carry the block, thereby reducing the data amount of the log, and correspondingly, reducing the storage space occupied by the log sequence. In addition, the first request also carries the digital signature of the log, thereby avoiding the log being tampered with and avoiding the log consensus error. In addition, the first node device sends the first response and the digital signature of the first response to the second node device in the blockchain system, and the TEE of the second node device verifies the first response based on the digital signature of the first response, thereby avoiding the content of the first response being tampered with and avoiding the log consensus error.

[0319] To further illustrate Figure 7 The process shown, see Figure 10The block consensus process provided by the embodiment of the application is shown in the figure. The proposal module of the REE of the leader node generates a block according to the transaction request (such as the fifth request), sends the identifier of the block to the TEE of the leader node to initiate a consensus proposal to the TEE of the leader node. The TEE of the leader node generates a log of the block based on the identifier of the block. The TEE of the leader node adds the log to the log sequence, generates the first request, and sends the first request to the REE of the leader node through the output interface, and the REE of the leader node sends the received first request to each non-leader node in the consensus cluster. The REE of each non-leader node sends the received first request to the TEE of each non-leader node. The TEE of each non-leader node verifies the log carried by the first request, and if the log passes the verification, the log is added to the local log sequence, and if the verification fails, the log is not received. The TEE of each non-leader node generates a log addition result (such as the first response) and sends the log addition result to the REE of each non-leader node through the output interface, and the REE of each non-leader node returns the log addition result to the leader node. The REE of the leader node sends the received each log addition result to the TEE of the leader node by calling the input interface. When more than half of the consensus nodes add the log, the TEE of the leader node notifies the consensus result of the log (such as if more than half of the consensus nodes add the log) through the output interface, at which time the transaction is successful. After that, the REE of the leader node triggers the TEE of the leader node to initiate the heartbeat information (such as the third request) when the heartbeat duration (such as the target duration) is checked to have arrived or timed out. After that, the TEE of the leader node first verifies whether the heartbeat duration has really arrived or timed out, and if so, the TEE of the leader node generates the heartbeat information, at which time the heartbeat message carries the index of the currently submitted log, and the TEE of the leader node sends the heartbeat message to the REE of the leader node through the output interface. The REE of the leader node sends the heartbeat message to each non-leader node in the consensus cluster. The REE of each non-leader node sends the received heartbeat message to the TEE of each non-leader node by calling the input interface. When the TEE of each non-leader node receives the heartbeat message, the TEE of each non-leader node submits the log according to the index carried by the heartbeat message.

[0320] To further illustrate Figure 7 The process is shown in the figure Figure 11An embodiment of the application shown provides a schematic diagram of block storage. The REE of the leader node packages a transaction, generates a block, and caches the block. The REE of the leader node sends an identifier of the block to the TEE of the leader node to instruct the TEE to reach consensus on the identifier of the block. The TEE of the leader node generates a log based on the identifier of the block and signs the log. The TEE of the leader node returns the log and the digital signature of the log to the REE of the leader node. The REE of the leader node obtains the block corresponding to the log from the cached block and synchronizes the block and the log to the follower nodes. For example, the REE of the leader node sends the log, the digital signature of the log, and the block to each follower node. The REE of each follower node caches the block and sends the log and the digital signature of the log to the TEE of the respective follower node. The TEE of each follower node verifies the log based on the digital signature of the log. If the verification is passed, the TEE of each follower node receives the log, otherwise, the TEE of each follower node does not receive the log. The TEE of each follower node sends the log receiving result (such as a target identifier) and the digital signature of the log receiving result to the REE of the respective follower node. The REE of each follower node sends the respective log receiving result (such as a first response) and the digital signature of the log receiving result to the leader node. The REE of the leader node sends each received log receiving result and the digital signature of each log receiving result to the TEE of the leader node. The REE of the leader node verifies each log receiving result based on the digital signature of each log receiving result. If at least half of the consensus node devices in the consensus cluster pass the verification of the log receiving result and the half of the consensus node devices all agree to receive the log, the TEE of the leader node submits the log. For example, the TEE of the leader node notifies the REE of the leader node to flush the block corresponding to the log to the disk, at this time, the transaction is successful. Subsequently, the TEE of the leader node generates a heartbeat message (such as a third request) and signs the heartbeat message, and the TEE of the leader node sends the heartbeat message and the digital signature of the heartbeat message to the REE of the leader node. The REE of the leader node receives and sends the heartbeat message to each follower node in the consensus cluster. The REE of each follower node receives the heartbeat message and the digital signature of the heartbeat message and sends the heartbeat message and the digital signature of the heartbeat message to the TEE of the respective follower node. The TEE of each follower node verifies the heartbeat message based on the digital signature of the heartbeat message. If the heartbeat message passes the verification, the TEE of each follower node submits the log based on the index of the log carried in the heartbeat message. For example, the TEE of each follower node notifies the REE of the respective follower node to flush the block corresponding to the log to the disk.

[0321] To further illustrate Figure 5 and Figure 7 The process shown, see Figure 12The embodiment of the application shown provides a schematic diagram of a data processing process in a consensus cluster. Taking the example of a consensus cluster including follower nodes 1-3, the data processing process is as follows. Figure 12 The following is introduced:

[0322] The TEE of the follower node 3 verifies the timestamp, and if it is determined that the election time has reached or timed out, the leader election is performed. For example, the follower node 3 switches to a candidate node, and the TEE of the candidate node 3 sends a voting request (such as the second request) carrying a digital signature to the follower nodes 1 and 2 respectively. The TEEs of the follower nodes 1 and 2 respectively verify the voting request based on the digital signature carried by the voting request. In the case where the voting request passes the verification, the TEEs of the follower nodes 1 and 2 vote for the candidate node 3 respectively, and return the respective voting results (such as the second response) and the digital signature of the voting result to the candidate node 3 respectively. The TEE of the candidate node 3 processes the voting results and becomes a leader node in the consensus cluster. For example, the TEE of the candidate node 3 verifies the respective voting results based on the digital signature of the respective voting results. If at least one of the two voting results passes the verification and the at least one voting result is a favorable vote, the candidate node 3 switches to a leader node. Then, the TEE of the leader node 3 verifies the timestamp, and if the heartbeat duration reaches or times out, the TEE of the leader node 3 sends a heartbeat message (such as the notification message) carrying a digital signature to the follower nodes 1 and 2 respectively. The TEEs of the follower nodes 1 and 2 respectively verify the heartbeat message based on the digital signature in the heartbeat message. In the case where the heartbeat message passes the verification, the TEEs of the follower nodes 1 and 2 accept the candidate node 3 as a leader node in the consensus cluster. Then, the client sends a transaction request (such as the fifth request) to the leader node 3, and the REE of the leader node 3 packages the transaction to generate a block. The TEE of the leader node 3 generates a log based on the identifier of the block and starts the consensus log. For example, the TEE of the leader node 3 sends the log, the digital signature of the log and the block to the follower nodes 1 and 2 through the REEs respectively. The REEs of the follower nodes 1 and 2 respectively cache the block. The TEEs of the follower nodes 1 and 2 respectively verify the log based on the digital signature of the log. In the case where the log passes the verification, the TEEs of the follower nodes 1 and 2 respectively receive the log, such as adding the log to the log sequence. The follower nodes 1 and 2 respectively return the respective log receiving results (such as the first response) and the digital signature of the log receiving result to the leader node 3. The TEE of the leader node 3 verifies each log receiving result based on the digital signature of each log receiving result. If at least one of the log receiving results of the follower nodes 1 and 2 passes the verification and the at least one log receiving result indicates that the log has been received, the TEE of the leader node 3 commits the log and writes the block corresponding to the log to the disk, at which time the transaction is successful, and the leader node 3 notifies the client of the transaction processing result. Then, the TEE of the leader node 3 performs timestamp checking, and if the heartbeat duration reaches or times out, the TEE of the leader node 3 sends a heartbeat message (such as the third request) and the digital signature of the heartbeat message to the follower nodes 1 and 2 respectively. The TEEs of the follower nodes 1 and 2 respectively verify the heartbeat message based on the digital signature of the heartbeat message.In a case that the heartbeat message is verified, the TEEs of the follower nodes 1 and 2 respectively commit the log based on the index of the log carried by the heartbeat message, for example, the TEEs of the follower nodes 1 and 2 respectively notify the REEs of the respective nodes to flush the block corresponding to the log to the disk.

[0323] As the consensus cluster service time increases, the number of logs in the log sequence of the consensus node device increases, in order to reduce the storage space occupied by the log sequence, the TEE of the consensus node device can compress the log sequence by means of snapshot, in order to further illustrate the process, see Figure 13 The embodiment of the application shown in the flowchart of a log compression method.

[0324] 1301, the TEE of the first node device truncates the plurality of logs in the log sequence to obtain a snapshot of the log sequence.

[0325] At this time, the first node device is a leader node in the consensus cluster. The log sequence is the log sequence of the first node device, and the log sequence is stored in the TEE of the first node device. The committed log means that the block corresponding to the log has been committed to the local blockchain ledger of the blockchain system, or in other words, the block corresponding to the log has been flushed to the disk. The snapshot includes a first identifier and a second identifier, the first identifier is an identifier of a block corresponding to a starting log in the plurality of logs, and the second identifier is an identifier of a block corresponding to a terminal log in the plurality of logs. Wherein, the starting log in the plurality of logs is the first log in the plurality of logs, and the terminal log in the plurality of logs is the last log in the plurality of logs.

[0326] In a possible implementation, in a case that the number of logs in the log sequence is greater than or equal to a number threshold, the TEE of the first node device queries the state of each log in the log sequence, and determines a plurality of logs in a committed state in the log sequence as the plurality of committed logs. Wherein, the number threshold can be set according to the actual implementation scenario, and the number threshold is not limited in the embodiment of the application.

[0327] After determining the plurality of committed logs in the log sequence, the TEE of the first node device generates the snapshot based on the first identifier of the starting log in the plurality of logs and the second identifier of the terminal log in the plurality of logs, and deletes the plurality of snapshots in the log sequence. Wherein, the snapshot includes the first identifier and the second identifier.

[0328] 1302, the TEE of the first node device sends the snapshot to the REE of the first node device.

[0329] In a possible implementation, the TEE of the first node device generates, based on the snapshot, a second target message carrying the snapshot, the second target message indicating that a second node device in the blockchain system submits the plurality of blocks corresponding to the plurality of logs to a local blockchain ledger based on the snapshot. The TEE of the first node device sends the second target message to the REE of the first node device.

[0330] In a possible implementation, to avoid the content of the second target message being tampered after the second target message leaves the TEE of the first node device, the TEE of the first node device signs the second target message based on a private key of the first node device to obtain a digital signature of the second target message. Accordingly, the TEE of the first node device sends the second target message and the digital signature of the second target message to the REE of the first node device.

[0331] It should be noted that the second target message is a heartbeat message or a message of another type other than a heartbeat message. If the second target message is a heartbeat message, the TEE of the first node device verifies whether the target duration arrives, and if the target duration arrives, the TEE of the first node device generates the second target message.

[0332] 1303. The REE of the first node device receives the snapshot, and based on the first identifier and the second identifier in the snapshot, obtains the plurality of blocks corresponding to the plurality of logs from a blockchain ledger of the blockchain system locally.

[0333] In a possible implementation, the REE of the first node device receives the second target message, parses the snapshot from the second target message, and queries, on the blockchain ledger of the blockchain system locally, a first block indicated by the first identifier in the snapshot and a second block indicated by the second identifier in the snapshot. The REE of the first node device obtains the first block, the second block, and each block between the first block and the second block from the blockchain ledger. The first block, the second block, and each block between the first block and the second block are also the plurality of blocks corresponding to the plurality of logs. The first block is the first block in the plurality of blocks, and the second block is the last block in the plurality of blocks.

[0334] 1304. The REE of the first node device sends, to a second node device in the blockchain system, a fourth request carrying the snapshot and the plurality of blocks, the fourth request indicating that the second node device in the blockchain system submits the plurality of blocks corresponding to the plurality of logs to a local blockchain ledger based on the snapshot.

[0335] In a possible implementation, after obtaining the plurality of blocks, the REE of the first node device generates the fourth request based on the second target message and the plurality of blocks, where the fourth request carries the second target message and the plurality of blocks.

[0336] In a possible implementation, if the digital signature of the second target message is received, the REE of the first node device generates the fourth request based on the second target message, the digital signature of the second target message, and the plurality of blocks, where the fourth request carries the second target message, the digital signature of the second target message, and the plurality of blocks.

[0337] After the fourth request is generated, the REE of the first node device sends the fourth request to a second node device in the blockchain system.

[0338] 1305. The REE of the second node device receives the fourth request.

[0339] In the steps 1305-1309, the second node device is any second node device in the blockchain system, that is, each second node device in the blockchain system performs the process shown in steps 1305-1309.

[0340] 1306. The REE of the second node device caches the plurality of blocks.

[0341] For example, the REE of the second node device transfers the plurality of blocks carried by the fourth request to the memory.

[0342] 1307. The REE of the second node device sends the snapshot to the TEE of the second node device.

[0343] For example, the REE of the second node device sends the fourth request after the transfer of the blocks to the TEE of the second node device, where the fourth request no longer carries the plurality of blocks.

[0344] In a possible implementation, the snapshot does not include the identification of the blocks, but includes the state data of each transaction event in the blocks, and the state data of each transaction event indicates the latest state of the data involved in each transaction event. However, the number of bytes occupied by the state data of each transaction event is large, so the data amount of such a snapshot is large. However, the snapshot in the embodiment of the present application includes the identification of the blocks, and if the identification of the blocks is the block number, the first identification and the second identification are two integer values, so the number of snapshots in the embodiment of the present application is small, and accordingly, the transmission rate of the snapshot is high.

[0345] For example Figure 14 The schematic diagram of the snapshot comparison provided by the embodiment of the present application is shown. Referring to Figure 14The related technology shown in the left-middle figure includes log sequence 1, which comprises logs 1-6, each containing blocks 1-6. Logs 1-4 are committed logs, while logs 5-6 are not yet committed. Blocks 1-4 have been committed to the blockchain ledger. The leader node truncates logs 1-4 in log sequence 1, generating snapshot 1 of log sequence 1. Snapshot 1 includes the state data of each transaction event in blocks 1-4.

[0346] Figure 14 The right figure is a schematic diagram of an embodiment of this application. Figure 14 In the right-hand diagram, log sequence 2 is stored in the leader node's TEE. Log sequence 2 includes logs 1-6, where logs 1-4 are committed, logs 5-6 are not yet committed, and blocks 1-4 have been committed to the blockchain ledger. The leader node uses the block hash value as the block identifier to refer to the block in the log. For example, logs 1-6 in block sequence 2 each include hash values ​​1-6 to refer to blocks 1-6 respectively. The leader node's TEE truncates logs 1-4 in log sequence 2 to generate snapshot 2, which includes the block number 1 of the starting block and the block number 4 of the ending block in blocks 1-4. It is evident that snapshot 2 contains less content than snapshot 1, meaning the data size of snapshot 2 is smaller than that of snapshot 1. Furthermore, the leader node's TEE sends snapshot 2 to the leader node's REE. The leader node's REE retrieves blocks 1-4 corresponding to snapshot 2 from its local blockchain ledger and sends snapshot 2 and blocks 1-4 to the non-leader nodes in the consensus cluster.

[0347] 1308. The TEE of the second node device receives the snapshot and verifies it.

[0348] In one possible implementation, the TEE of the second node device receives a fourth request sent by the REE of the second node device, and parses the second target message and the digital signature of the second target message from the fourth request.

[0349] The TEE of the second node device verifies the digital signature of the second target message based on the public key of the first node device. Since the second target message carries a snapshot, if the signature verification is successful, the TEE of the second node device verifies the snapshot. If the signature verification fails, it indicates that the content of the second target message has been tampered with, and the TEE of the second node device fails to verify the snapshot.

[0350] 1309. If the snapshot passes the verification of the TEE of the second node device, the TEE of the second node device notifies the REE of the second node device to submit the multiple blocks to the local blockchain ledger of the blockchain system.

[0351] In a case that the snapshot passes the verification of the TEE of the second node device, the TEE of the second node device parses the snapshot from the second target message, and obtains the first identifier and the second identifier from the snapshot. The TEE of the second node device queries the first log corresponding to the first identifier and the second log corresponding to the second identifier in the log sequence of the second node device, and deletes the first log, the second log and each log between the first log and the second log in the log sequence. The first log, the second log and each log between the first log and the second log are the plurality of logs truncated by the first node device, the first log is a starting log in the plurality of logs, and the second log is a terminal log in the plurality of logs.

[0352] In a possible implementation, the TEE of the second node device notifies the REE of the second node device to submit the plurality of blocks to the blockchain ledger of the local blockchain system by sending a request to the REE of the second node device.

[0353] For example, the TEE of the second node device sends a seventh request to the REE of the second node device, the seventh request carries the snapshot, and the seventh request instructs the REE of the second node device to submit the plurality of blocks corresponding to the snapshot to the blockchain ledger of the local blockchain system. When the REE of the second node device receives the seventh request, the REE of the second node device queries the plurality of blocks corresponding to the snapshot from the cached blocks based on the snapshot carried by the seventh request, and submits the queried plurality of blocks to the blockchain ledger of the local blockchain system. The REE of the second node device can also store the snapshot in the persistent storage medium.

[0354] The method provided by the embodiments of the present application generates a snapshot through the TEE of the node device, and the snapshot carries the identifier of the starting block and the identifier of the terminal block in the submitted plurality of blocks, thereby reducing the data amount of the snapshot, and since the TEE is protected by hardware and cannot be tampered with, the snapshot can be protected by the TEE for the purpose of synchronization, and the Byzantine error in the blockchain system can be prevented. In addition, since the fourth request carries the second target message and the digital signature of the second target message, the content of the second target message is prevented from being tampered with, thereby reducing the Byzantine error in the blockchain system.

[0355] The method of the embodiments of the present application is introduced above, and the apparatus of the embodiments of the present application is introduced below. It should be understood that the apparatus introduced below has any function of any node device in the above method.

[0356] Figure 15 The embodiments of the present application provide a structural diagram of a data processing apparatus, as shown in Figure 15The apparatus 1500 is configured as a first node device in a blockchain system, the first node device comprising a trusted execution environment (TEE) and a rich execution environment (REE), the TEE comprising a processing unit 1501, and the REE comprising a communication unit 1502;

[0357] The processing unit 1501 is configured to generate a log of a block in the REE based on the block, and send the log to the REE, wherein the block is referred to by an identifier of the block in the log;

[0358] The communication unit 1502 is configured to receive the log, and send a first request to a second node device in the blockchain system, wherein the first request carries the log, and the first request instructs the second node device to process the log.

[0359] Optionally, the first request further carries the block, and the first request instructs the second node device to process the log and the block; and the processing unit 1501 is further configured to:

[0360] receive a plurality of first responses via the REE, each first response indicating whether a second node device has agreed to receive the log;

[0361] in a case where first responses of a majority of the second node devices in the blockchain system pass the verification of the TEE, and each of the first responses that passes the verification indicates that a second node device has agreed to receive the log, instruct the REE to commit the block to a blockchain ledger of the blockchain system locally based on the identifier of the block in the log.

[0362] Optionally, the processing unit 1501 is further configured to:

[0363] send a second request to a second node device in the blockchain system via the REE, wherein the second request instructs a vote on whether the first node device becomes a leader node in the blockchain system;

[0364] receive a plurality of second responses via the REE, each second response indicating whether a second node device agrees that the first node device becomes the leader node in the blockchain system;

[0365] in a case where second responses of a majority of the second node devices in the blockchain system pass the verification of the TEE, and each of the second responses that passes the verification indicates that a second node device agrees that the first node device becomes the leader node in the blockchain system, switch a node state of the first node device to a leader state.

[0366] Optionally, the processing unit 1501 is further configured to:

[0367] generating a notification message, the notification message indicating that the first node device is a leader node in the blockchain system;

[0368] sending, by the REE, the notification message to a second node device in the blockchain system.

[0369] Optionally, the processing unit 1501 is further configured to:

[0370] in a case that the first responses of the half or more of the second node devices in the blockchain system pass the verification of the TEE, and each of the first responses that passes the verification indicates that one second node device has agreed to receive the log, sending, by the REE, a third request to the second node device in the blockchain system, the third request indicating the second node device to commit the block to a blockchain ledger of the blockchain system locally.

[0371] Optionally, the processing unit 1501 is further configured to truncate a plurality of logs in a log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot comprising a first identifier and a second identifier, wherein the first identifier is an identifier of a block corresponding to a starting log in the plurality of logs, and the second identifier is an identifier of a block corresponding to a terminal log in the plurality of logs.

[0372] The communication unit 1502 is further configured to receive the snapshot, obtain, based on the first identifier and the second identifier in the snapshot, a plurality of blocks corresponding to the plurality of logs from a blockchain ledger of the blockchain system locally, and send a fourth request to the second node device in the blockchain system, the fourth request carrying the snapshot and the plurality of blocks, the fourth request indicating the second node device to commit the plurality of blocks to the blockchain ledger locally based on the snapshot.

[0373] It should be understood that the apparatus 1500 corresponds to the first node device in the above-described method embodiments, and each module in the apparatus 1500 and the above-described other operations and / or functions are respectively configured to implement various steps and methods implemented by the first node device in the method embodiments, and specific details can be referred to the above-described method embodiments, which will not be described here for brevity.

[0374] It should be understood that the device 1500 is only exemplified by the above division of each functional module when determining the processing data, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device 1500 is divided into different functional modules to complete all or part of the functions described above. In addition, the device 1500 provided by the above embodiment belongs to the same concept as the above method embodiments, and the specific implementation process is described in detail in the above method embodiments, which will not be repeated here.

[0375] Figure 16 The embodiment of the application provides a structural diagram of a data processing device, referring to Figure 16 The device 1600 is configured as a second node device in a blockchain system, and the second node device includes a trusted execution environment TEE and a rich execution environment REE; the TEE includes a processing unit 1601, and the REE includes a communication unit 1602.

[0376] The communication unit 1602 is configured to receive a first request from a first node device in the blockchain system, the first request carrying a log of a block, and send the log to the TEE, wherein the log refers to the block by an identifier of the block, and the first request instructs the second node device to process the log.

[0377] The processing unit 1601 is configured to, in a case where the log passes the verification of the TEE, store the log by the TEE, and send a first response to the first node device by the REE, wherein the first response indicates that the second node device has agreed to receive the log.

[0378] Optionally, the first request further carries the block.

[0379] The communication unit 1602 is further configured to cache the block.

[0380] The processing unit 1601 is further configured to receive a third request from the first node device by the REE, wherein the third request instructs the second node device to submit the block to a blockchain ledger of the blockchain system locally.

[0381] The processing unit 1601 is further configured to, in a case where the third request passes the verification of the TEE, instruct the REE to submit the block to the blockchain ledger of the blockchain system locally based on the identifier of the block in the log.

[0382] Optionally, the processing unit 1601 is further configured to:

[0383] receive, by the REE, a second request from the first node device, the second request indicating a vote for the first node device to become a leader node in the blockchain system;

[0384] in a case where the second request passes the verification of the TEE, send, by the REE, a second response to the first node device, the second response indicating whether the second node device agrees with the first node device to become a leader node in the blockchain system.

[0385] Optionally, the processing unit 1601 is further configured to:

[0386] receive, by the REE, a notification message from the first node device, the notification message indicating that the first node device becomes a leader node in the blockchain system;

[0387] in a case where the notification message passes the verification of the TEE, modify the stored node state of the first node device to a leader state.

[0388] Optionally, the communication unit 1602 is further configured to receive a fourth request from the first node device, the fourth request carrying a snapshot of a log sequence in the first node device and a plurality of blocks, the snapshot comprising a first identifier and a second identifier, wherein the first identifier is an identifier of a block corresponding to a starting log among a plurality of logs in the log sequence that have been committed, and the second identifier is an identifier of a block corresponding to a terminal log among the plurality of logs, the plurality of logs corresponding to the plurality of blocks.

[0389] the communication unit 1602 is further configured to cache the plurality of blocks, and send the snapshot to the TEE;

[0390] the processing unit 1601 is further configured to receive the snapshot, and in a case where the snapshot passes the verification of the TEE, notify the REE to commit the plurality of blocks to a blockchain ledger of the blockchain system locally.

[0391] It should be understood that the apparatus 1600 corresponds to the second node device in the above-described method embodiments, and each module in the apparatus 1600 and the above-described other operations and / or functions are respectively configured to implement various steps and methods implemented by the second node device in the method embodiments, and specific details can be referred to the above-described method embodiments, which will not be described herein again for the sake of brevity.

[0392] It should be understood that the device 1600 is only exemplified by the above division of the functional modules in determining the processing data, and in actual application, the above functions can be distributed by different functional modules according to needs, that is, the internal structure of the device 1600 is divided into different functional modules to complete all or part of the functions described above. In addition, the device 1600 provided by the above embodiment and the above method embodiment belong to the same concept, and the specific implementation process is described in detail in the above method embodiment, which will not be repeated here.

[0393] Figure 17 is a structural schematic diagram of a computer device provided by an embodiment of the present application. The computer device 1700 includes one or more processors 1701 and one or more memories 1702. The one or more processors 1701 and the one or more memories 1702 are located in the TEE of the computer device 1700. The one or more memories 1702 are coupled with the one or more processors 1701, and the one or more memories 1702 are used to store at least one program code including computer instructions. When the one or more processors 1701 execute the computer instructions, the computer device 1700 executes the related method steps described above to implement the data processing method in the above embodiment. The computer device 1700 can be any node device provided by an embodiment of the present application. Of course, the computer device 1700 can also have a wired or wireless network interface, a keyboard, and an input and output interface, and other components for realizing the functions of the device. Here, details are not repeated.

[0394] In an exemplary embodiment, a computer readable storage medium is also provided, for example, a memory including program code. The above program code can be executed by a processor in the TEE of a computer device to complete the data processing method in the above embodiment. For example, the computer readable storage medium is a non-transitory computer readable storage medium, such as a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), a magnetic tape, a floppy disk, and an optical data storage device, etc.

[0395] The embodiment of the present application also provides a computer program product, which includes computer instructions stored in a computer readable storage medium. The processor of the TEE of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above data processing method.

[0396] In addition, the embodiment of the present application further provides a device, which can be a chip, a component or a module. The device can include a processor and a memory connected to each other. The memory is used to store computer-executable instructions. When the device is running, the processor can execute the computer-executable instructions stored in the memory, so that the chip executes the data processing method in the above method embodiments.

[0397] The device, the equipment, the computer readable storage medium, the computer program product or the chip provided in the embodiment can be used to execute the corresponding method provided in the above, and thus the beneficial effects achieved by the device, the equipment, the computer readable storage medium, the computer program product or the chip can refer to the beneficial effects in the corresponding method provided in the above, and will not be described here.

[0398] Through the description of the above embodiments, those skilled in the art can understand that, for the convenience and brevity, only the division of the above functional modules is taken as an example, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the data processing method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process is described in the method embodiments, which will not be described here.

[0399] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0400] The units described as separate components can or can not be physically separate, and the components shown as units can be one physical unit or multiple physical units, that is, can be located in one place or distributed to multiple different places. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0401] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0402] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application essentially or say the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The software product is stored in a storage medium, and includes a number of instructions to make a device (which can be a single-chip microcomputer, a chip, etc.) or a processor execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and various media that can store program codes.

[0403] In the description of the present application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this document is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can mean that A exists alone, A and B exist together, and B exists alone. In addition, "at least one" means one or more, and "multiple" means two or more. "First", "second", etc. do not limit the quantity and execution order, and "first", "second", etc. do not necessarily mean different.

[0404] In the present application, the words "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design scheme described as "exemplary" or "for example" in the present application should not be interpreted as more preferred or advantageous than other embodiments or design schemes. Rather, the use of "exemplary" or "for example" is intended to present relevant concepts in a concrete manner.

[0405] All the optional technical solutions described above can be combined to form optional embodiments of the present disclosure, which will not be described one by one here.

[0406] The above is only an optional embodiment of the present application, and does not limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A data processing method, characterized in that, The method is executed by a first node device in the blockchain system, the first node device including a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE); the method includes: The TEE generates a log of the block based on the block in the REE, and the block is identified by the block identifier in the log; The TEE sends the log to the REE; The REE receives the log and sends a first request to a second node device in the blockchain system. The first request carries the log and instructs the second node device to process the log.

2. The method according to claim 1, characterized in that, The first request also carries the block, and the first request instructs the second node device to process the log and the block; after sending the first request to the second node device in the blockchain system, the method further includes: The TEE receives multiple first responses through the REE, and each first response indicates whether a second node device has agreed to receive the log; If the first response of half or a majority of the second node devices in the blockchain system passes the verification of the TEE, and each verified first response indicates that a second node device has agreed to receive the log, the TEE, based on the identifier of the block in the log, notifies the REE to submit the block to the local blockchain ledger of the blockchain system.

3. The method according to claim 1 or 2, characterized in that, Before the TEE generates logs based on the blocks in the REE, the method further includes: The TEE sends a second request to a second node device in the blockchain system through the REE, the second request instructing the first node device to vote to become the leader node in the blockchain system; The TEE receives multiple second responses through the REE, each second response indicating whether a second node device agrees that the first node device should become the leader node in the blockchain system; If a second response from half or a majority of the second node devices in the blockchain system passes the verification of the TEE, and each verified second response indicates that a second node device agrees that the first node device should become the leader node in the blockchain system, the TEE switches the node state of the first node device to the leader state.

4. The method according to claim 3, characterized in that, After the TEE switches the node state of the first node device to the leader state, the method further includes: The TEE generates a notification message, which indicates that the first node device is the leader node in the blockchain system; The TEE sends the notification message to the second node device in the blockchain system through the REE.

5. The method according to claim 2, characterized in that, The method further includes: If a majority of the first responses from the second node devices in the blockchain system pass the verification of the TEE, and each verified first response indicates that a second node device has agreed to receive the log, the TEE sends a third request to the second node devices in the blockchain system through the REE. The third request instructs the second node devices to submit the block to the local blockchain ledger of the blockchain system.

6. The method according to any one of claims 1, 2, 4 or 5, characterized in that, The method further includes: The TEE truncates multiple committed logs in the log sequence to obtain a snapshot of the log sequence. The snapshot includes a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the starting log in the multiple logs, and the second identifier is the identifier of the block corresponding to the ending log in the multiple logs. The TEE sends the snapshot to the REE; The REE receives the snapshot, and based on the first identifier and the second identifier in the snapshot, retrieves multiple blocks corresponding to the multiple logs from the blockchain ledger of the local blockchain system, and sends a fourth request to the second node device in the blockchain system. The fourth request carries the snapshot and the multiple blocks, and the fourth request instructs the second node device to submit the multiple blocks to the local blockchain ledger based on the snapshot.

7. A data processing method, characterized in that, The method is executed by a second node device in the blockchain system, the second node device including a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE); the method includes: The REE receives a first request from a first node device in the blockchain system. The first request carries a log of a block, in which the block is identified by its identifier. The first request instructs a second node device to process the log. The REE sends the log to the TEE; If the log passes the verification of the TEE, the TEE stores the log and sends a first response to the first node device through the REE. The first response indicates that the second node device has agreed to receive the log.

8. The method according to claim 7, characterized in that, The first request also carries the block. After the REE receives the first request from the first node device in the blockchain system, the method further includes: The REE caches the block; After sending the first response to the first node device via the REE, the method further includes: The TEE receives a third request from the first node device through the REE, the third request instructing the second node device to submit the block to the local blockchain ledger of the blockchain system; If the third request passes the verification of the TEE, the TEE, based on the identifier of the block in the log, notifies the REE to submit the block to the blockchain ledger of the local blockchain system.

9. The method according to claim 7 or 8, characterized in that, Before the REE receives the first request from the first node device in the blockchain system, the method further includes: The TEE receives a second request from the first node device through the REE, the second request indicating that the first node device be voted to become the leader node in the blockchain system; If the second request passes the verification of the TEE, the TEE sends a second response to the first node device through the REE, the second response indicating whether the second node device agrees to the first node device becoming the leader node in the blockchain system.

10. The method according to claim 9, characterized in that, After the TEE sends a second response to the first node device through the REE, the method further includes: The TEE receives a notification message from the first node device through the REE, the notification message indicating that the first node device becomes the leader node in the blockchain system; If the notification message passes the verification of the TEE, the TEE will modify the node state of the first node device stored in the TEE to the leader state.

11. The method according to any one of claims 7, 8, or 10, characterized in that, The method further includes: The REE receives a fourth request from the first node device. The fourth request carries a snapshot of the log sequence in the first node device and multiple blocks. The snapshot includes a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the starting log among the multiple committed logs in the log sequence, and the second identifier is the identifier of the block corresponding to the ending log among the multiple logs. The multiple logs correspond to the multiple blocks. The REE caches the multiple blocks and sends the snapshot to the TEE; The TEE receives the snapshot, and if the snapshot passes the verification of the TEE, it notifies the REE to submit the multiple blocks to the local blockchain ledger of the blockchain system.

12. A blockchain system for data processing, characterized in that, The blockchain system includes a first node device and at least one second node device; the first node device includes a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE). The TEE is used to generate a log of the block based on the block in the REE, and send the log to the REE, wherein the block is identified by the block identifier in the log; The REE is used to receive the log and send a first request to a second node device in the blockchain system. The first request carries the log and instructs the second node device to process the log. Each second node device is configured to receive the first request and, if the log passes the verification of the second node device, store the log.

13. The system according to claim 12, characterized in that, Each second node device includes a TEE and a REE; Each second node device's REE is used to receive the first request and send the log carried in the first request to the TEE of its respective second node device; Each second node device's TEE is used to receive the first request, store the log if the log passes the TEE's verification, and send a first response to the first node device through the REE of the second node device, the first response indicating whether a second node device has agreed to receive the log.

14. The system according to claim 13, characterized in that, The first node device includes a TEE and a REE; The TEE of the first node device is used to receive the first response from the second node device in the blockchain system through the REE of the first node device. If the first responses from half or a majority of the second node devices in the blockchain system pass the verification of the TEE, and each verified first response indicates that a second node device has stored the log, the REE of the first node device is notified to submit the block to the local blockchain ledger of the blockchain system based on the identifier of the block in the log.

15. The system according to claim 14, characterized in that, The first request also carries the block; The TEE of the first node device is also used to send a third request to the second node device in the blockchain system through the REE of the node device to which it belongs. The third request instructs the second node device to submit the block to the local blockchain ledger of the blockchain system. Each second node device's REE is also used to cache the block carried by the first request, receive the third request, and send the third request to the TEE of its respective second node device; Each second node device's TEE is also used to receive the third request, and if the third request passes the TEE's verification, to notify the REE of the second node device to submit the block to the local blockchain ledger of the blockchain system based on the block's identifier in the log.

16. The system according to any one of claims 12-15, characterized in that, Each of the first node device and the at least one second node device includes a TEE and an REE; The first node device's TEE is used to send a second request to the second node device in the blockchain system, the second request indicating that the first node device should vote to become the leader node in the blockchain system; Each second node device's TEE is used to receive the second request. If the second request passes the verification of the TEE, it sends a second response to the first node device through the REE of its own node device. Each second response indicates whether a second node device agrees that the first node device should become the leader node in the blockchain system. The TEE of the first node device is also used to receive a second response from the second node device in the blockchain system to the second request through the REE of the node device to which it belongs. If the second responses of half or a majority of the second node devices in the blockchain system pass the verification of the TEE, and each verified second response indicates that a second node device agrees that the first node device should become the leader node in the blockchain system, the node state of the first node device is switched to the leader state.

17. The system according to claim 16, characterized in that, The TEE of the first node device is also used to generate a notification message and send the notification message to the second node device in the blockchain system through the REE of the node device to which it belongs. The notification message indicates that the first node device is the leader node in the blockchain system. Each second node device's TEE is also used to receive the notification message through the REE of its parent node device, and if the notification message passes the TEE's verification, modify the stored node state of the first node device to the leader state.

18. The system according to any one of claims 12, 13, 14, 15 or 17, characterized in that, The first node device includes a TEE and a REE; The TEE is used to truncate multiple committed logs in the log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE. The snapshot includes a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the starting log in the multiple logs, and the second identifier is the identifier of the block corresponding to the ending log in the multiple logs. The REE is used to receive the snapshot, obtain multiple blocks corresponding to the multiple logs from the blockchain ledger of the local blockchain system based on the first identifier and the second identifier in the snapshot, and send a fourth request to the second node device in the blockchain system. The snapshot includes the identifier of the first block and the identifier of the last block in the blockchain ledger at the current time. The fourth request carries the snapshot and the multiple blocks. The fourth request instructs the second node device to submit the multiple blocks to the local blockchain ledger.

19. The system according to claim 18, characterized in that, Each second node device includes a TEE and a REE; Each second node device's REE is used to receive the fourth request from the first node device, cache the multiple blocks, and send the snapshot to the TEE; Each second node device's TEE is used to receive the snapshot, and if the snapshot passes the TEE's verification, it notifies the REE of the second node device to submit the multiple blocks to the local blockchain ledger of the blockchain system based on the snapshot.

20. A data processing apparatus, characterized in that, The device is configured as a first node device in a blockchain system. The first node device includes a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE). The TEE includes a processing unit, and the REE includes a communication unit. The processing unit is configured to generate a log of the block based on the block in the REE, and send the log to the REE, wherein the block is identified by the block identifier in the log; The communication unit is configured to receive the log and send a first request to a second node device in the blockchain system, the first request carrying the log and instructing the second node device to process the log.

21. The apparatus according to claim 20, characterized in that, The first request also carries the block, and the first request instructs the second node device to process the log and the block; the processing unit is further configured to: The REE receives multiple first responses, each first response indicating whether a second node device has agreed to receive the logs; If, in the blockchain system, a majority of the first responses from the second node devices pass the verification of the TEE, and each verified first response indicates that a second node device has agreed to receive the log, the REE is notified, based on the identifier of the block in the log, to submit the block to the local blockchain ledger of the blockchain system.

22. The apparatus according to claim 20 or 21, characterized in that, The processing unit is also used for: The REE sends a second request to a second node device in the blockchain system, the second request instructing the first node device to vote to become the leader node in the blockchain system; The REE receives multiple second responses, each second response indicating whether a second node device agrees with the first node device becoming the leader node in the blockchain system; If a second response from half or a majority of the second node devices in the blockchain system passes the verification of the TEE, and each verified second response indicates that a second node device agrees that the first node device should become the leader node in the blockchain system, then the node state of the first node device is switched to the leader state.

23. The apparatus according to claim 22, characterized in that, The processing unit is also used for: Generate a notification message indicating that the first node device is the leader node in the blockchain system; The notification message is sent to the second node device in the blockchain system via the REE.

24. The apparatus according to claim 21, characterized in that, The processing unit is also used for: If a majority of the first responses from the second node devices in the blockchain system pass the verification of the TEE, and each verified first response indicates that a second node device has agreed to receive the log, a third request is sent to the second node devices in the blockchain system via the REE. The third request instructs the second node devices to submit the block to the local blockchain ledger of the blockchain system.

25. The apparatus according to any one of claims 20, 21, 23 or 24, characterized in that, The processing unit is further configured to truncate multiple committed logs in the log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE. The snapshot includes a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the starting log in the multiple logs, and the second identifier is the identifier of the block corresponding to the ending log in the multiple logs. The communication unit is further configured to receive the snapshot, obtain multiple blocks corresponding to the multiple logs from the blockchain ledger of the local blockchain system based on the first identifier and the second identifier in the snapshot, and send a fourth request to the second node device in the blockchain system. The fourth request carries the snapshot and the multiple blocks, and the fourth request instructs the second node device to submit the multiple blocks to the local blockchain ledger based on the snapshot.

26. A data processing apparatus, characterized in that, The device is configured as a second node device in a blockchain system, the second node device including a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE); the TEE includes a processing unit, and the REE includes a communication unit. The communication unit is configured to receive a first request from a first node device in the blockchain system. The first request carries a block log and sends the log to the TEE. The log identifies the block using the block's identifier. The first request instructs the second node device to process the log. The processing unit is configured to, if the log passes the verification of the TEE, store the log in the TEE and send a first response to the first node device through the REE, wherein the first response indicates that the second node device has agreed to receive the log.

27. The apparatus according to claim 26, characterized in that, The first request also carries the block; The communication unit is also used to cache the block; The processing unit is further configured to receive a third request from the first node device via the REE, the third request instructing the second node device to submit the block to the local blockchain ledger of the blockchain system; The processing unit is further configured to, if the third request passes the verification of the TEE, notify the REE to submit the block to the local blockchain ledger of the blockchain system based on the identifier of the block in the log.

28. The apparatus according to claim 26 or 27, characterized in that, The processing unit is also used for: The REE receives a second request from the first node device, the second request indicating that the first node device be voted to become the leader node in the blockchain system; If the second request passes the verification of the TEE, a second response is sent to the first node device via the REE. The second response indicates whether the second node device agrees to the first node device becoming the leader node in the blockchain system.

29. The apparatus according to claim 28, characterized in that, The processing unit is also used for: The REE receives a notification message from the first node device, the notification message indicating that the first node device becomes the leader node in the blockchain system; If the notification message passes the verification of the TEE, the node state of the first node device stored in the memory is modified to the leader state.

30. The apparatus according to any one of claims 26, 27 or 29, characterized in that, The communication unit is further configured to receive a fourth request from the first node device, the fourth request carrying a snapshot of the log sequence in the first node device and multiple blocks, the snapshot including a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the starting log among the multiple submitted logs in the log sequence, and the second identifier is the identifier of the block corresponding to the ending log among the multiple logs, and the multiple logs correspond to the multiple blocks; The communication unit is also used to cache the multiple blocks and send the snapshot to the TEE; The processing unit is further configured to receive the snapshot, and, if the snapshot passes the verification of the TEE, notify the REE to submit the multiple blocks to the local blockchain ledger of the blockchain system.

31. A computer device, characterized in that, The computer device includes a Trusted Execution Environment (TEE), the TEE including a processor for executing program code that causes the computer device to perform the method as described in any one of claims 1 to 11.

32. A computer-readable storage medium, characterized in that, The storage medium stores at least one piece of program code, which is read by a processor in a Trusted Execution Environment (TEE) to cause a computer device to perform the method as described in any one of claims 1 to 11.

33. A computer program product, characterized in that, The computer program product includes at least one piece of program code, which is read by a processor in a Trusted Execution Environment (TEE) to cause a computer device to perform the method as described in any one of claims 1 to 11.

Images