CN115719272A

CN115719272A - Data processing method, system, device, computer equipment and storage medium

Info

Publication number: CN115719272A
Application number: CN202110989279.0A
Authority: CN
Inventors: 张明阳; 程烁; 刘勋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-08-26
Filing date: 2021-08-26
Publication date: 2023-02-28
Also published as: WO2023024821A1

Abstract

The application discloses a data processing method, a system, a device, computer equipment and a storage medium, and belongs to the technical field of block chains. According to the method, the logs are generated through the TEE of the node equipment in the blockchain system, and the REE of the node equipment sends the logs generated by the TEE to other node equipment in the blockchain system, so that other node equipment can identify the logs. Because the TEE is protected by hardware and cannot be badly done, the purpose of using the TEE to protect the consensus process can be realized, and the Byzantine error in the block chain system can be prevented.

Description

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

Technical Field

The present application relates to the field of block chain technologies, and in particular, to a data processing method, system, apparatus, computer device, and storage medium.

Background

The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm, and is widely applied to the field with high requirements on data safe storage by means of characteristics such as decentralization, trust removal, collective maintenance and a reliable database.

The consensus node in the blockchain system can perform consensus on the blocks through the consensus protocol and store the blocks passing the consensus on the blockchain. Current consensus protocols include crash fault tolerance protocol (CFT) type consensus protocols such as Paxos consensus algorithm and Raft consensus algorithm. The CFT type consensus protocol can solve the problems of node message delay, loss, repetition and the like caused by network failure or node breakdown, so that in the block chain system adopting the CFT type consensus protocol, even if part of nodes have network failure or node breakdown, the normal operation of the block chain system can be still ensured.

However, the CFT-like consensus protocol cannot solve Byzantine faults (Byzantine faults), such as false behavior of forging a node message, tampering a node message, or malicious response. The byzantine error may cause a situation that the blockchain system has a consensus error and the blockchain system cannot work normally, and therefore, a data processing method capable of reducing the byzantine error of the blockchain system is needed.

Disclosure of Invention

The embodiment of the application provides a data processing method, a system, a device, a computer device and a storage medium, which can reduce Byzantine errors in a block chain system. The technical scheme is as follows:

in a first aspect, a data processing method is provided, the method being performed by 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 method comprises the following steps:

the TEE generates a log of the blocks based on the blocks in the REE, and sends the log to the REE, wherein the blocks are referred to by the identification of the blocks in the log;

and the REE receives the log and sends a first request to second node equipment in the block chain system, wherein the first request carries the log, and the first request indicates the second node equipment to process the log.

The log includes the identifier of the block, but does not include the block, and the identifier of the block refers 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 may be represented by other means besides the hash value of the block or the block number, and the identifier of the log is not limited in this application.

Since the journal in the present application refers to the block as the identifier of the block, the journal in the present application does not include the block. The log in the related art does not refer to the log by using the identification of the block, but the block is directly added in the log, that is, the log in the related art includes the block. Or it can be understood that the present application replaces the block in the log in the related art with the identification of the block. The identification of the block is smaller in data amount relative to the whole block, so that the data amount of the log in the application is smaller compared with the log in the related art.

According to the method, a log is generated through the TEE of the node equipment in the blockchain system, and the REE of the node equipment sends the log generated by the TEE to other node equipment in the blockchain system, so that other node equipment can identify the log. Because the TEE is protected by hardware and cannot be badly done, the purpose of using the TEE to protect the consensus process can be realized, and the Byzantine error in the block chain system can be prevented. In addition, the blocks are referred to as the identification of the blocks in the log, and the log does not need to carry the blocks, so that the data volume of the log is reduced.

In a possible implementation manner, the first request further carries the block, and the first request instructs the second node device to process the log and the block; after the sending the first request to the second node device in the blockchain system, the method further comprises:

the TEE receiving a plurality of first responses through the REE, each first response indicating whether a second node device has agreed to receive the log;

in the event that first responses of half or most of the second node devices in the blockchain system pass the validation of the TEE, and each of the first responses that pass the validation indicates that one second node device has agreed to receive the log, the TEE notifies the REE to submit the block to a local blockchain ledger of the blockchain system based on the identity of the block in the log.

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

the TEE sending, by the REE, a second request to a second node device in the blockchain system, the second request indicating a vote for the first node device to become a leader node in the blockchain system;

the TEE receiving a plurality of second responses through the REE, each second response indicating whether a second node device agrees to the first node device to become a leader node in the blockchain system;

the TEE switches the node state of the first node device to a leader state if second responses of half or most of the second node devices in the blockchain system pass the validation of the TEE, and each of the second responses that pass the validation indicates one second node device agrees to the first node device to become the leader in the blockchain system.

In one possible implementation, after the TEE switches the node state of the first node device to the leader state, the method further includes:

the TEE generating a notification message indicating that the first node device is a leader node in the blockchain system;

the TEE sends the notification message to a second node device in the blockchain system through the REE.

In one possible implementation, the notification message may be a heartbeat message or other type of message.

In one possible implementation, the method further includes:

in the event that first responses of half or a plurality of second node devices in the blockchain system pass validation of the TEE, and each of the first responses that pass validation indicates that one 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 instructing the second node devices to submit the blocks to a local blockchain ledger of the blockchain system.

In one possible implementation, the third request may be a heartbeat message or other type of message.

In one possible implementation, the method further includes:

the TEE truncates a plurality of submitted logs in a log sequence to obtain a snapshot of the log sequence, wherein the snapshot comprises a first identifier and a second identifier, the first identifier is an identifier of a block corresponding to a starting log in the logs, and the second identifier is an identifier of a block corresponding to an ending log in the logs;

the TEE sends the snapshot to the REE;

the REE receives the snapshot, acquires a plurality of blocks corresponding to the plurality of logs from a local blockchain account book 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, where the fourth request carries the snapshot and the plurality of blocks, and the fourth request instructs the second node device to submit the plurality of blocks to the local blockchain account book based on the snapshot.

Each log in the log sequence comprises an identification of a block and an index of the log, and all logs in the log sequence are sequentially arranged from small to large according to the index. Optionally, each log further comprises an tenure of the leader node in the blockchain system.

In one possible implementation, the fourth request may be a heartbeat message or other type of message.

In a second aspect, a data processing method is provided, the method being performed by a second node device in a blockchain system, the second node device comprising a trusted execution environment TEE and a rich execution environment REE; the method comprises the following steps:

the REE receives a first request from a first node device in the blockchain system, wherein the first request carries a log of blocks, the blocks are referred to by the identification of the blocks in the log, and the first request indicates the second node device to process the log;

the REE sends the log to the TEE;

in the event that the log passes the authentication of the TEE, the TEE stores the log, sends a first response to the first node device via the REE, the first response indicating that the second node device has agreed to receive the log.

In a possible implementation manner, 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:

the REE caches the blocks;

after sending the first response to the first node device via the REE, the method further comprises:

the TEE receiving, by the REE, a third request from the first node device, the third request instructing the second node device to submit the block to a blockchain ledger of the blockchain system that is local;

in the event that the third request passes the TEE's validation, the TEE notifies the REE to submit the block to a local blockchain ledger of the blockchain system based on the identity of the block in the log.

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

the TEE receiving, 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;

in an instance in which the second request passes authentication 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 to be a leader node in the block chain system.

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

the TEE receiving, by the REE, a notification message from the first node device, the notification message instructing the first node device to become a leader node in the blockchain system;

in the event that 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.

In one possible implementation, the method further includes:

the REE receives a fourth request from the first node device, wherein the fourth request carries a snapshot of a log sequence in the first node device and a plurality of blocks, the snapshot comprises a first identifier and a second identifier, the first identifier is an identifier of a block corresponding to a start log in a plurality of submitted logs in the log sequence, the second identifier is an identifier of a block corresponding to an end log in the plurality of logs, and the plurality of logs correspond to the plurality of blocks;

the REE caches the blocks and sends the snapshot to the TEE;

the TEE receives the snapshot, and if the snapshot passes the validation of the TEE, the REE is notified to submit the plurality of blocks to a local blockchain ledger of the blockchain system.

In a third aspect, there is provided a blockchain system for data processing, the blockchain system comprising a first node device and at least one second node device;

the first node device is configured to send a first request to a second node device in the blockchain system, where the first request carries a log of a block, the block is referred to by an identifier of the block in the log, and the first request instructs the second node device to process the log;

each second node device is configured to receive the first request, and store the log if the log passes the verification of the second node device.

In one possible implementation, the first node device includes a trusted execution environment TEE and a rich execution environment REE;

the TEE is used for generating the log based on the blocks in the REE and sending the log to the REE;

the REE is used for receiving the log and sending the first request to a second node device in the blockchain system.

In one possible implementation, each second node device includes a TEE and a REE;

the REE of each second node device is used for receiving the first request and sending the log carried by the first request to the TEE of the second node device;

the TEE of each second node device is used for receiving the first request, storing the log when the log passes the verification of the TEE, and sending a first response to the first node device through the REE of the second node device, wherein the first response indicates whether one second node device agrees to receive the log.

In one possible implementation, the first node device includes a TEE and a REE;

the TEE of the first node device is used for receiving the first responses of second node devices in the blockchain system through the REE of the first node device, and when the first responses of half or most of the second node devices in the blockchain system pass the verification of the TEE and each verified first response indicates that one second node device already stores the log, the TEE of the first node device is informed to submit the block to a local blockchain account book of the blockchain system based on the identification of the block in the log.

In a possible implementation, the first request further carries the block;

the TEE of the first node device is further used for sending a third request to a second node device in the blockchain system through the REE of the node device, wherein the third request instructs the second node device to submit the block to a local blockchain account book of the blockchain system;

the REE of each second node device is also used for caching the block carried by the first request, receiving the third request and sending the third request to the TEE of the second node device;

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 a local blockchain ledger of the blockchain system based on the identification of the block in the log if the third request passes the verification of the TEE.

In one possible implementation, each of the first node device and the at least one second node device includes a TEE and a REE;

the TEE of the first node device, configured to send a second request to a second node device in the blockchain system by the TEE of the subordinate node device, the second request indicating a vote for the first node device to become a leader node in the blockchain system;

a TEE of each second node device, configured to receive the second request, and send a second response to the first node device through a REE of the node device to which the TEE passes verification, where each second response indicates whether one second node device agrees to the first node device as a leader node in the block chain system;

the TEE of the first peer device, further configured to receive, by the REE of the peer device, a second response to the second request by a second peer device in the block chain system, and switch the peer state of the first peer device to the leader state if the second responses of half or most of the second peer devices in the block chain system pass verification by the TEE and each of the second responses that pass verification indicates that one second peer device agrees to become the leader node in the block chain system.

In a possible implementation manner, the TEE of the first node device is further configured to generate a notification message, and send the notification message to a second node device in the blockchain system through the REE of the node device, where the notification message indicates that the first node device is a leader node in the blockchain system;

the TEE of each second node device is further used for receiving the notification message through the REE of the corresponding node device, and modifying the stored node state of the first node device into a leader state when the notification message passes the verification of the TEE.

In one possible implementation, the first node device includes a TEE and a REE;

the TEE is configured to truncate multiple submitted logs in a log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE, where the snapshot includes a first identifier and a second identifier, the first identifier is an identifier of a block corresponding to a start log in the multiple logs, and the second identifier is an identifier of a block corresponding to an end log in the multiple logs;

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 blockchain ledger of the local blockchain system, and send a fourth request to a second node device in the blockchain system, where the snapshot includes an identifier of a first block and an identifier of a last block in the blockchain ledger at a current time, the fourth request carries the snapshot and the plurality of blocks, and the fourth request indicates that the second node device submits the plurality of blocks to the local blockchain ledger.

the REE of each second node device is used for receiving the fourth request from the first node device, caching the plurality of blocks and sending the snapshot to the TEE;

the TEE of each second node device is used for receiving the snapshot, and notifying the REE of the second node device to submit the blocks to a local block chain account book of the block chain system based on the snapshot when the snapshot passes the verification of the TEE.

In a fourth aspect, a data processing apparatus is provided for performing the above data processing method. Specifically, the data processing apparatus includes functional modules configured to execute the data processing method provided in the first aspect or any one of the optional manners of the first aspect.

In a fifth aspect, a data processing apparatus is provided for performing the above data processing method. In particular, the data processing apparatus comprises functional modules for performing the data processing method provided by the second aspect or any one of the alternatives of the second aspect.

In a sixth aspect, a computer device is provided, the computer device comprising a trusted execution environment, TEE, comprising a processor for executing program code to cause the computer device to execute to carry out operations performed by the data processing method as described above.

In a seventh aspect, a computer-readable storage medium is provided, in which at least one program code is stored, which is read by a processor in the trusted execution environment TEE to cause a computer device to perform operations as performed by the above-mentioned data processing method.

In an eighth aspect, a computer program product is provided, which comprises program code stored in a computer-readable storage medium, which program code is read by a processor in a trusted execution environment TEE of a computer device from the computer-readable storage medium, which program code is executed by the processor, such that the computer device performs the method provided in the first aspect or the various alternative implementations of the first aspect, or the computer device performs the method provided in the second aspect or the various alternative implementations of the second aspect.

Drawings

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment of the present disclosure;

fig. 2 is a schematic diagram of role switching of an identity node device in a Raft consensus algorithm provided in an embodiment of the present application;

fig. 3 is a schematic diagram of a consensus cluster for implementing a Raft consensus algorithm based on TEE according to an embodiment of the present application;

fig. 4 is a schematic diagram of a consensus node device for implementing a Raft consensus algorithm based on TEE according to an embodiment of the present application;

FIG. 5 is a flowchart of a leader node election method provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of a leader node election process according to an embodiment of the present application;

fig. 7 is a flowchart of a data processing method provided in an embodiment of the present application;

fig. 8 is a diagram illustrating comparison of data amounts of different third messages according to an embodiment of the present application;

FIG. 9 is a schematic diagram illustrating a comparison between a first request and a log replication request in the related art according to an embodiment of the present application;

fig. 10 is a schematic diagram of a block consensus process provided by an embodiment of the present application;

FIG. 11 is a block diagram of a block memory according to an embodiment of the present disclosure;

fig. 12 is a schematic diagram of a data processing procedure in a consensus cluster according to an embodiment of the present application;

fig. 13 is a flowchart of a log compression method provided in an embodiment of the present application;

FIG. 14 is a flow chart of a snapshot comparison schematic provided by an embodiment of the present application;

fig. 15 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application;

fig. 17 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment of the present disclosure, and referring to fig. 1, a blockchain system 100 includes a plurality of node devices 101, all or some of the node devices in the plurality of node devices 101 are common node devices in the blockchain system 100, and a cluster formed by the common node devices in the blockchain system 100 may be denoted as a common cluster. The common node device has a function of generating a Block (Block) and broadcasting the Block in the common cluster, so that each common node device in the common cluster can share the Block based on a common protocol. If the plurality of common identification node devices in the common identification cluster pass the common identification of the block, each common identification node device in the common identification cluster stores the block to a local block chain (Blockchain) account book of the block chain system 100, so that the block chain account books stored by each common identification node device in the common identification cluster are the same, and the purpose of maintaining the same block chain account book by the common identification cluster is achieved. Of course, the consensus cluster may also maintain a plurality of block chain accounts at the same time according to a manner of maintaining one block chain account.

The consensus protocol comprises a CFT type consensus protocol, and the CFT type protocol has a Paxos algorithm at the earliest. Due to the poor intelligibility of Paxos algorithms, many other CFT-like protocols were subsequently derived from Paxos algorithms. Wherein, compared with other representative CFT protocols such as a Raft consensus algorithm, the Raft consensus algorithm simplifies the design and flow optimization of the Paxos algorithm, so that the Paxos algorithm is easier to understand and realize and easier to apply in an actual system.

In the Raft consensus algorithm, the consensus node devices in the consensus cluster may have three roles, namely, a leader (leader), a candidate (candidate), and a follower (follower), wherein the roles of the consensus node devices may also be understood as node states. The 3 roles can be mutually switched, and in combination with a role switching diagram of the consensus node device in the Raft consensus algorithm provided by the embodiment of the present application shown in fig. 2, the 3 roles are introduced as follows:

the leader: in the blockchain system, a common node device is used as a leader to generate blocks and logs of the blocks, and the blocks and the logs are broadcasted in a common cluster so that a non-leader node in the common cluster can receive the blocks and the logs. And also to keep a heartbeat (heart beat) with the non-leader node to inform the non-leader node that it is the leader in the blockchain system. The non-leader node is a consensus node device which is a follower or a candidate in the blockchain system. For convenience of description, a consensus node device as a leader in the blockchain system is denoted as a leader node. And recording the consensus node device serving as a candidate in the block chain system as a candidate node. And recording the consensus node equipment serving as a follower in the block chain system as a follower node, namely, the candidate node and the follower node are non-leader nodes.

Candidates: the candidate is in an intermediate state between the follower and the leader, and the candidate node is configured 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 succeeds in election for the leader (or the election is successful), the candidate node is converted from the candidate to the leader.

Following the person: any one of the consensus node devices in the consensus cluster is a follower when started. And the following node is used for responding to the log and the block sent by the leader node and receiving the log and the block, and voting for the candidate node to become the leader.

In the Raft consensus algorithm, the duplicate data exists in the form of a Log, and the Log in the related art includes blocks and some additional information, such as the index (Log index) and the expiration (Term) of the Log. The leader node in the consensus cluster can generate a log and broadcast the log in the consensus cluster so that all non-leader nodes in the consensus cluster can perform consensus on the log, and the consensus cluster performs consensus on the log to realize the consensus on the blocks corresponding to the log. In the scheme described in the application, the log is improved to match the implementation of the scheme. Specifically, the journal in the solution proposed in the present application does not include a block, and only a block corresponding to the journal is indicated by one identifier, but it can also be understood that the block itself is replaced in the journal by the identifier of the block, and therefore, it is also expressed hereinafter that the block corresponding to the journal is referred to by the identifier of the block in the journal.

The main flow of the Raft consensus algorithm includes a leader node election flow and a log replication flow (i.e., a log consensus flow), and the election mechanism in the leader node election flow and the log replication mechanism in the log replication flow in the related art are introduced as follows with reference to fig. 2:

1. taking any one of the consensus node devices in the consensus cluster as an example, the election mechanism is introduced as follows:

the consensus node device is a follower when started, and the consensus node device is a follower node at the moment. The following node sets an optional period corresponding to one election process in the common recognition cluster, for example, the optional period is 1 corresponding to the first election process in the common recognition cluster, and the optional period is 2 corresponding to the second election process in the common recognition cluster. The following node also sets an election time for starting election to become a leader and starts countdown. When the election time reaches or is overtime and no leader exists in the consensus cluster within the preset time period, the following node updates its own optional period (such as the optional period plus 1), where the optional period corresponds to one election process in the consensus cluster, for example, the optional period is 1 corresponding to the first election process in the consensus cluster and the optional period is 2 corresponding to the second election process in the consensus cluster. The consensus node device is converted into a candidate from a follower, any consensus node device is a candidate node at this time, and the updated due period corresponds to the candidate node, namely, the election process will be initiated (namely, the election process at this time).

The candidate node initiates the 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 tenure of the candidate node (i.e., the tenure after updating).

And after each non-leader node receives the voting request, returning a voting result to the candidate node according to the tenure of the candidate node in the voting request. For example, if the candidate node has a higher tenure than a non-leader node and the non-leader node has not voted for other candidate nodes, the non-leader node agrees to the candidate node to become the leader in the cluster and returns a vote result representing the votes agreed for to the candidate node. And if the tenure of the candidate node is less than or equal to that of the non-leader node or the non-leader node has voted for other candidate nodes, the non-leader node objecting to the candidate node becoming a leader in the consensus cluster and returning a vote result representing the objection to the vote to the candidate leader node.

After the candidate node receives the voting results of the multiple non-leader nodes, counting the number of the non-leader nodes casting a vote for the candidate node (namely the number of the vote). If most of the non-leader nodes (including the candidate node) in the consensus cluster vote for the candidate node, the consensus node device switches from the candidate to the leader in the consensus cluster, wherein the consensus node is the leader node, and the leader node sends a heartbeat message to each of the non-leader nodes in the consensus cluster to inform each of the non-leader nodes that the non-leader nodes are the leader in the consensus cluster and the tenure of the leader, so that each of the non-leader nodes in the consensus cluster takes the tenure of the leader as the respective tenure.

If a few non-leader nodes in the consensus cluster approve the vote for the candidate node, the fact that the majority of non-leader nodes in the consensus cluster approve the vote for another candidate node is shown, and the other candidate node possibly becomes a leader, and the candidate node fails in the current election (namely, election drop). During the election, if the candidate node receives a heartbeat message sent by the leader node in the consensus cluster, it indicates that one candidate node becomes the leader in the consensus cluster, and the candidate node fails in the election. Once the candidate node election fails, the consensus node device switches from candidate to follower. Or if the election is overtime, the leader is not elected in the consensus cluster, and the consensus node device is switched from the candidate to the follower.

2. The log replication mechanism:

each piece of common-identification node equipment in the common-identification cluster maintains a log sequence, wherein the log sequence comprises a plurality of logs, and the plurality of logs are sequentially arranged according to the sequence from small indexes to large indexes in the logs to form the log sequence. When a leader node in the consensus cluster generates a new block, the leader node generates a log of the block based on the block and the index of the last log in the local log sequence, wherein the index in the log is 1 greater than the index of the last log at the current moment in the log sequence. And 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, wherein the log replication request carries the log.

And after each non-leader node receives the log replication request, determining whether to accept to receive the log according to the content of the log carried by the log replication request. If a certain 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 of agreeing to receive the log to the leader node. After the majority of non-leader nodes in the consensus cluster agree to receive the log, the leader node indicates that the majority of non-leader nodes in the consensus cluster have agreed to receive the log by sending a heartbeat message to each of the non-leader nodes in the consensus cluster. When each non-leader node receives the heartbeat message, the block carried by the log is submitted to the block chain account book of the block chain system, and the common identification cluster achieves common identification on the log (or the block).

The method is characterized in that a random consensus algorithm is taken as a representative of CFT (computational fluid dynamics) type consensus algorithm, each block chain bottom layer technology platform can generally support the random consensus algorithm, for example, the block chain bottom layer technology platform introduces an open source code implementation of the random consensus algorithm, or the open source code implementation is slightly modified to adapt to a bottom layer system, the implementation is a pure soft implementation of the random consensus algorithm, and node faults of the consensus cluster can be tolerated. However, the open source code of the Raft consensus algorithm generally runs in a Rich Execution Environment (REE) of the node device, and once the node device with the byzantine error occurs in the consensus cluster, the node device with the byzantine error may initiate any attack on the block chain system, which may cause the consensus cluster to fail to work normally. The byzantine error includes, but is not limited to, electing a leader node by means of tampering a timestamp, tampering an tenure period, tampering a voting result, and the like, or tampering the content of a message transmitted in a block chain system, and the leader node may maliciously modify the block content or the index of a log, so that a consensus error occurs in a consensus cluster, and the consensus cluster cannot normally work.

For example, if the following node maliciously tampers with the timestamp, the election is initiated in advance before the actual election time comes, so that the following node becomes the leader node. For another example, when election is initiated, the candidate node compares the relative ratio of its own tenuous tampering so that each non-leader node in the consensus cluster votes for the candidate node, thereby promoting the candidate node to become the leader node in the consensus cluster. For another example, when only a few non-leader nodes in the consensus cluster approve the votes for a certain candidate node, if the candidate node tampers with the number of votes approved, for example, the number of votes approved is increased, so that the candidate node becomes the leader node in the consensus cluster. For another example, if the leader node tampers the timestamp of sending the heartbeat message, and if the timestamp of the heartbeat message is slightly modified, the leader node will send the heartbeat message in the consensus cluster in advance, which may result in a denial of service (Dos) attack. If the timestamp of the heartbeat message is greatly modified, the leader node does not send the heartbeat message in the consensus cluster for a long time, namely the leader node intentionally does not send the heartbeat message, so that the election time of the follower node is overtime, and the election is initiated again.

For convenience of description, a node device in which a byzantine error occurs is referred to as a byzantine node. In order to avoid a byzantine error (for example, through tampering with a task period and being selected as a leader, or tampering with a log at will) in the consensus cluster, that is, to avoid a byzantine node in the consensus cluster, an embodiment of the present application provides a technical solution for a node device to implement a Raft consensus algorithm in a Trusted Execution Environment (TEE). For example, a 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 flow of the Raft consensus algorithm.

The TEE marks out a security area on a main processor of the computing device, and can ensure the security, confidentiality and integrity of codes and data loaded into the TEE. The execution space provided by the TEE has a higher level of security than the space provided by common mobile operating systems (e.g., linux, android, etc.). Implementations of TEE include TrustZone based advanced risc Architectures (ARM), intel (Intel) derived instruction set extensions (SGX), and the like.

The TEE is protected by a hardware mechanism, and isolation of a protected memory and an execution environment is provided, so that reliable security and privacy guarantee can be provided. The TEE can only break down and no Byzantine error occurs, therefore, the common identification node equipment realizes the Raft common identification algorithm in the TEE, the node equipment can be prevented from having the Byzantine error, and the Byzantine error in a block chain system is further avoided.

In the method for common identification by means of the raw common identification algorithm, each common identification node device performs common identification by log replication, each common identification node device stores a log sequence and a block chain account book of a block chain system, and the log sequence and the block chain account book both need to occupy a certain storage space. Especially after the blockchain system runs for a long time, more and more blocks are generated on the logs and the blockchain account book in the blockchain system. However, the TEE is an area on the host processor with limited storage resources, and the storage space inside the TEE may not be able to withstand more and more logs and blocks. Based on this, the method and the device provide that fine-grained module splitting is performed on the algorithm implementation of the Raft consensus algorithm (such as a computer program for implementing the Raft consensus algorithm), core flow implementation of the Raft consensus algorithm (such as a computer program for implementing an election mechanism and a computer program for implementing a log replication mechanism) is placed in the TEE for protection, and an input/output (IO) layer of the Raft consensus algorithm is performed on the REE side, so that the safety of the Raft consensus algorithm is guaranteed, dependence on the TEE is minimized, and the efficiency and performance of the algorithm are guaranteed.

For example, fig. 3 shows a schematic diagram of a consensus cluster for implementing a Raft consensus algorithm based on TEE according to an embodiment of the present application, which is shown in fig. 3. The consensus cluster shown in fig. 3 comprises consensus node devices 1-3, wherein the consensus node device 1 is a leader node and the

consensus node devices

1 and 2 are follower nodes. Each of the consensus node devices 1-3 comprises an REE and a TEE, the REE being used to implement an IO procedure of a message. For example, the REE of the consensus node device is responsible for forwarding the message from the TEE of the node to other consensus node devices, or the message from other consensus node devices is forwarded to the TEE of the node, a block chain ledger (leader) of a block chain system, a snapshot (snapshot) of a log sequence, and the like may be stored in the REE. The TEE is used for implementing core processes of the Raft consensus algorithm, such as consensus (consensus) processes (i.e., log copy processes) and election processes.

For further explaining a core flow of the TEE for implementing the Raft consensus algorithm and an IO process of the REE for implementing the message, referring to fig. 4, which is a schematic diagram of a consensus node device for implementing the Raft consensus algorithm based on the TEE according to the embodiment of the present application, an execution environment of each consensus node device in the consensus cluster shown in fig. 4 includes the TEE and the REE. Each consensus node device implements core logic of a Raft consensus algorithm in the TEE, and the core logic comprises legal verification logic, timeout detection logic, log (Log) sequence maintenance logic, election (election) logic, configuration (configuration) logic of the consensus cluster, and state maintenance logic of the consensus cluster. The legal verification logic is used for verifying whether message contents transmitted by other common node devices are legal or not and verifying whether identity certificates (such as digital signatures) of the other common node devices are legal or not. The timeout detection logic adopts a timer principle to detect whether the latest election time reaches or exceeds the time, and if the latest election time reaches or exceeds the time, the election is initiated. Log sequence maintenance logic is to maintain a log sequence. The configuration logic of the consensus cluster is configured to maintain node information of each consensus node device in the consensus cluster, for example, a public key, address information, and the like of each consensus node device. Election (election) logic is used to implement either the open election process or to vote for candidate nodes. The state maintenance logic of the consensus cluster is used for maintaining the node state (or the role) of each consensus node device in the consensus cluster in real time. And maintaining the node state of each piece of commonly-identified node equipment in the blockchain system in real time by adopting a node tracker (node tracker), for example.

And each consensus node device realizes IO layer logic of a Raft consensus algorithm in the REE. For example, a proposal (promoter) module, a storage (storage) module, a message scheduling module, and a communication module are disposed in the REE, where the proposal (promoter) module is used to generate a block. The storage module includes a memory (memory) and a persistent storage medium, and the memory is used for storing the blocks generated by the proposal module. The persistent storage medium is used to store a local blockchain ledger (leader), a snapshot (snapshot) of a log sequence, a write-ahead log (write-ahead loading), and the like of the blockchain system, where the blockchain ledger is a blockchain configured in the blockchain system. The communication module may also be referred to as a network (network) module, and is configured to communicate with other co-aware node devices, such as Remote Procedure Calls (RPCs) between co-aware clusters. And the message scheduling module is used for completing message scheduling among all modules in the consensus node equipment. In one possible implementation, the message scheduling module may perform message scheduling inside the consensus node device according to an Event Loop (Event Loop) mechanism.

For example, in fig. 4, a client (client) sends (transmit, TX) a fifth request to a consensus node device (i.e., leader) as a leader, wherein the fifth request is used to indicate that a transaction is to be conducted between at least two blockchain accounts. And the proposal module in the leader node generates a block based on the fifth request, transfers the block to a module through a message, sends the block to a memory in the storage module, and sends the identification of the block to the TEE. And then, the TEE 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 a proposal module through a message scheduling module, the proposal module acquires the block corresponding to the log from a memory, sends the log and the block to a non-leader node in a consensus cluster through the message scheduling module and a communication module, receives the log and the block through the communication module in the non-leader node, sends the log and the block to the message scheduling module, the message scheduling module stores the block in a storage module, sends the log to the TEE of the non-leader node, and determines whether to accept the log or not through the TEE.

For further explanation, referring to a flowchart of a leader node election method provided by an embodiment of the present application and shown in fig. 5, a process of a consensus node device in a blockchain system electing a leader node based on a TEE is described.

501. When the node equipment is started, the TEE of the first node equipment initializes the node information of each piece of common node equipment in the common node equipment, the node state of the first node equipment, the election time of the first node equipment and the initial tenure of the first node equipment.

The first node device is any one of the common node devices in the common cluster in the block chain system. The node information of each consensus node device comprises a node identifier, address information and a public key of one consensus node device. The node identifier of each piece of common node equipment is used to uniquely indicate one piece of common node equipment, and the address information of each piece of common node equipment may be an Internet Protocol (IP) address of each piece of common node equipment.

The node state of each consensus node device in the consensus cluster comprises a following state, a candidate state or a leader state, wherein the following state is used for indicating that the consensus node device is a following node, the candidate state is used for indicating that the consensus node device is a candidate node, and the leader state is used for indicating that the consensus node device is a leader node. At startup, the node state of the first node device is a following state, and the election time of the first node device is the time for starting the election of the first node device to become a leader node in the blockchain system (or the consensus cluster). The initial tenure of the first node device is the initial tenure of the first node device, and the initial tenure may be 0 or any integer greater than 0.

In one possible implementation, the TEE is triggered by the REE in the first node device to perform this step 501. Such as the procedures shown in steps 5011-5013, described below.

Step 5011, when the node is started, the REE in the first node device generates a sixth request, where the sixth request indicates the node information of each piece of common node device in the TEE initialized common cluster, the node state of the first node device, the election time of the first node device, and the initial expiration date of the first node device.

And the sixth request carries node information of all the common node equipment in the common cluster.

In a possible implementation manner, a block chain account in the block chain system is stored in the REE of the first node device, and the REE acquires node information of each piece of consensus node device in the consensus cluster from the block chain account. For example, the common identification cluster configuration information is obtained from a created block in the blockchain ledger, where the created block is a first block on the blockchain ledger.

And after the node information of each piece of common node equipment in the common cluster is obtained, the REE generates the sixth request based on the node information of each piece of common node equipment in the common cluster.

At step 5012, the REE of the first node device sends a sixth request to the TEE of the first node device.

In a possible implementation manner, the first node device REE calls an initialization configuration interface between the REE and the TEE, and sends a sixth request to the initialization configuration interface. Wherein the initialization configuration interface may be a message scheduling module located in the REE, the message scheduling module sending a sixth request to the initialization configuration interface, so that the TEE receives the sixth request from the initialization configuration interface.

Step 5013, the TEE of the first node device receives the sixth request, and initializes node information of each piece of common node device in the common node cluster, a node state of the first node device, election time of the first node device, and an initial expiration date of the first node device based on the sixth request.

In one possible implementation, the TEE of the first node device receives the sixth request from the initialization configuration interface.

After receiving the sixth request, the TEE of the first node device parses the node information of each piece of common node device in the common node cluster from the sixth request, and stores the node information of each piece of common node device in the common node cluster based on the indication of the sixth request, thereby completing the node information configuration.

The TEE of the first node device initializes a node state of the first node device based on the indication of the sixth request, e.g., the TEE of the first node device stores the node state of the first node device as a following state.

In a possible implementation manner, the TEE of the first node device obtains node identifiers of the respective common node devices in the common cluster from the node information of the respective common node devices in the common cluster. The TEE of the first node device creates a state table based on the node identification of the consensus node device. The state table is used for recording the corresponding relation between the node state of each piece of common node equipment in the common cluster and the node identification of each piece of common node equipment. For example, the first node device may store a node identification of the first node device in association with an identification of a following state in the state table to indicate that the node state of the first node device is the following state. It should be noted that, initially, the first node device does not know the node states of other common node devices in the common cluster, and then the first node device may record the node states of the other common node devices in the state table as a following state.

And the TEE of the first node equipment generates election time of the first node equipment according to a first preset rule and the indication of the sixth request, and records the election time. The first preset rule may be a randomly generated rule, or other preset rules. Here, the first preset rule is not limited in the embodiment of the present application.

The TEE of the first node device generates and records an initial tenure of the first node device based on the indication of the sixth request, for example, 0 is used as the initial tenure of the first node device.

In one 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.

It should be noted that, when each of the common node devices in the blockchain system is started, the node information, the respective node state, the respective election time, and the respective initial deadline of each of the common node devices in the common cluster can be initialized through this step 501. And each piece of common node equipment executes the step 501 once when being started without repeated execution.

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.

The second request includes a first tenure of the first node device, where the first tenure is a tenure corresponding to the election process initiated by the first node device.

In a possible implementation manner, if a notification message from a leader node in a consensus cluster is not received within a preset time period, it indicates that the leader node does not exist in the consensus cluster, where the notification message indicates that one node device in the blockchain system is the leader node in the blockchain system.

Since a leader node is allowed to exist in the consensus cluster at the same time, if the notification message from the leader node in the consensus cluster is not received within the preset time length and the election time of the first node device recorded in the TEE of the first node device has reached or exceeded, the TEE of the first node device generates the second request. Wherein, the election time is reached: the current time is the election time recorded in the TEE, and the overtime election time means that the current time is later than the election time recorded in the TEE.

In the case where the TEE is not able to invoke the REE and the REE is able to invoke the TEE (e.g., the TEE invokes the TEE in ARM-based TrustZone technology, the TEE is not able to invoke 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 below.

Step 5021, if the election time of the first node device recorded in the REE of the first node device reaches or is overtime, the REE of the first node device generates a first message, and the first message is used for prompting the TEE to start the election process of the first node device.

The election process of the first node device refers to a process of electing the first node device to become a leader node in the block chain system.

In a possible implementation manner, after receiving the election time of the first node device sent by the first node device TEE, the REE of the first node device records the election time of the first node device and starts a countdown. And if the election time reaches or is overtime and the notification message from the leader node in the consensus cluster is not received within a preset time length, the REE of the first node equipment generates the first message.

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

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

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

For example, the TEE of the first node device receives the first message from a message scheduling module.

After receiving the first message, the TEE of the first node device verifies the first message based on recording the election time of the first node device. For example, if the election time recorded by the TEE of the first node device has reached or timed out, the TEE of the first node device verifies the first message.

And if the election time recorded by the TEE of the first node equipment is not reached, the first node equipment is indicated to tamper the election time of the first node equipment in the REE, and a byzantine error occurs. Therefore, if the election time recorded by the TEE of the first node device is not reached, the TEE of the first node device does not verify the first message. If the TEE of the first node device does not verify the first message, the subsequent steps are not executed.

Step 5024, under the condition that 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.

And under the condition that the first message passes the verification of the TEE of the first node equipment, the TEE of the first node equipment increases the recorded tenure of the first node equipment by a first preset value to obtain the first tenure of the first node equipment. The first predetermined value is a difference between adjacent random periods, and the first predetermined value may be 1 or other values. The first preset value may be set according to an actual application scenario, and the first preset value is not limited in this application embodiment.

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

In another possible implementation manner, to avoid tampering with the content carried by the second request 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, and obtains a digital signature of the second request.

For the process shown in steps 5021-5024, even if the REE of the first node device has a Byzantine error, for example, a timer in the REE is tampered, so that the time recorded by the timer is advanced to reach the election time, and the REE is triggered to send a first message to the TEE. However, since the TEE of the first node device further verifies whether the recorded election time has been reached or has timed out, if the first message does not pass the verification of the TEE of the first node device, the TEE of the first node device does not generate the second request, thereby preventing the first node device from initiating election in the consensus cluster in advance.

It should be noted that, after the TEE of the first node device generates the second request, the TEE of the first node device initiates election, and the TEE of the first node device updates the recorded node state of the first node device from the following 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.

503. The TEE of the first node device sends the second request to a second node device in the block chain system through a first node device REE.

The second node devices in the blockchain system are all the common node devices in the common cluster except the first node device, and there may be at least one second node device in the blockchain system.

In one possible implementation, this step 503 is performed by steps 5031-5032 described below.

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

In one possible implementation, the TEE of the second node device sends the second request and a 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 a digital signature of the second request to a message scheduling module in the REE of the first node device.

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.

In one possible implementation, the REE of the second node device receives the second request and a digital signature of the second request. For example, the 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 the 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.

504. The TEE of the second node device receives the second request through the REE of the second node device.

The second node device in steps 504-506 performs the processes shown in steps 504-506 for any one of the second node devices in the blockchain system, that is, for each second node device in the blockchain system.

In one possible implementation, this step 504 is implemented by steps 5041-5043 described below.

At step 5041, the REE of the second node device receives the second request.

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

At step 5042, the REE of the second node device sends the second request to the TEE of the second node device.

In one possible implementation, the REE of the second node device sends the second request and a 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 a digital signature of the second request to the TEE of the second node device.

At step 5043, the TEE of the second node device receives the second request.

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

505. The TEE of the second node device verifies the second request.

In one possible implementation manner, 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 is successful, the TEE of the second node device verifies the second request. If the check-in fails, it indicates that the content of the second request has been tampered, and the TEE of the second node device does not verify the second request.

506. In an instance in which the second request passes verification of the TEE of the second node device, the TEE of the second node device sends a second response to the first node device through the REE of the second node device, the second response indicating whether the second node device agrees with the first node device to be the leader node in the block chain system.

The second response carries a first voting identifier or a second voting identifier, the first voting identifier indicates that the second node device approves the first node device to become a leader node in the blockchain system, and the first voting identifier is an approval vote. The second vote indication indicates that the second node device disagrees with the first node device to become the leader node in the blockchain system, i.e., is an objection vote.

Each consensus node device in the consensus cluster has the right to vote once when electing the leader node. And each piece of consensus node equipment approves tickets for candidate nodes higher than the self-appointed period or approves tickets for the self-appointed period in each election.

In a possible implementation manner, in a case that the second request passes the verification of the TEE of the second node device, the TEE of the second node device parses the first tenure of the first node device from the second request. The TEE of the second node device generates the second response based on recording the tenure of the second node device and the first tenure.

For example, if the first tenure is greater than the tenure of the second node device and the second node device does not vote in favor of the candidate nodes other than the first node device, the TEE of the second node device generates a second response carrying the first voting identifier, otherwise, the TEE of the second node device generates a second response carrying the second voting identifier.

Further, in order to avoid tampering with the content of the second response after the second response leaves 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, and obtains a digital signature of the second response.

In one possible implementation, the TEE of the second node device sends the second response, or sends the second response and a digital signature of the second response, to the first node device via the REE of the second node device, such as the process shown in steps 5061-5062 below.

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

In one possible implementation, the TEE of the second node device sends the second response and a digital signature of the second response to the REE. For example, the TEE of the second node device sends the second response and a digital signature of the second response to an information-scheduling module in the REE of the second node device.

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

In one 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 second response and the digital signature of the second response are sent 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.

It should be noted that, when the second request passes the verification of the TEE of the second node device, it indicates 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 following state to the candidate state.

507. The TEE of the first node device receives a plurality of second responses via the REE of the first node device.

Wherein each of the plurality of second responses is from a respective one of the second node devices in the consensus cluster.

In one possible implementation, the TEE of the first node device receives each second response of the plurality of responses and a digital signature of each second response via the REE of the first node device. The process shown in step 507 is the same as the process in which the TEE of the second node device receives the second request through the REE of the second node device in step 504, and here, the embodiment of the present application does not describe this step 507 again.

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

Taking the example that the TEE of the first node device verifies the second response of the second node device, the following description is given to step 508:

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.

For example, the first node device TEE verifies the digital signature of the second response of the second node device based on the public key of the second node device. And if the signature verification is successful, the TEE of the first node equipment passes the verification of the second response. If the signature verification fails, it indicates that the content of the second response has been tampered, and the first node device TEE does not verify the second response.

509. The TEE of the first node device switches the node state of the first node device to the leader state in a case where second responses of half or a plurality of second node devices in the blockchain system pass the verification of the TEE, and each second response that passes the verification indicates that one second node device agrees to the first node device to become the leader node in the blockchain system.

In a possible implementation manner, when the second responses of half or most of the second node devices in the block chain system pass the verification of the TEE, the TEE of the first node device analyzes the second responses of the second node devices to obtain the voting identifiers carried by the second responses.

And the TEE of the first node device counts the total number of the first voting identifiers in the second response passing the verification, wherein the total number is the total number of the second node devices in the consensus cluster which vote for the first node device to become the leader node. The TEE of the first node device determines whether the total number is greater than a first threshold, wherein the first threshold is the number of half of second node devices of the common identification cluster. The first node device also votes for the first node device because the first node device agrees to become the leader node in the blockchain system. If the counted total number is greater than or equal to the first threshold, considering that the first node approves the first node device to become the leader node, it indicates that most of the common node devices in the common cluster approve the first node device to become the leader node in the blockchain system, and the TEE of the first node device switches the node state of the first node device from the candidate state to the leader state.

For example, the TEE of the first node device updates the identifier of the following state of the first node device recorded in the state table to the identifier of the leader state, and at this time, the first node device is the leader node in the blockchain system.

510. The TEE of the first node device generates a notification message indicating that the first node device is a leader node in the block chain system.

Wherein the notification message is a heartbeat message or other types of messages except for the heartbeat message. The notification message includes a first tenure of the first node device.

In one possible implementation, the TEE of the first node device generates the notification message based on the first epoch.

In one possible implementation, the action of the TEE of the first node device generating the notification message is triggered by the REE of the first node device, such as the process shown in steps 5101-5103 below.

Step 5101, if the target duration recorded in the REE of the first node device has reached or has timed out, the REE of the first node device generates a second message, and the second message is used for prompting the TEE to send a notification message to a second node device in the blockchain system.

The target time length is a time length for the leader node to periodically send the notification message in the consensus cluster, that is, the leader node sends the notification message in the consensus cluster once after one target time length, so as to notify the existence of each consensus node device leader node in the consensus cluster.

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. And when the REE of the first node equipment receives the notification of the TEE, starting countdown, and if the target duration reaches or is overtime, the REE of the first node equipment sends the second message to the TEE of the first node equipment.

In step 5102, the TEE of the first node device receives the second message and verifies the second message.

After the TEE of the first node device receives the second message, if the target duration recorded in the TEE of the first node device has reached or exceeded time, it indicates that the REE of the first node device does not tamper with the target duration, and the TEE of the first node device verifies the second message. If the target duration recorded in the TEE of the first node device has not been reached, it indicates that the REE of the first node device tampers with the target duration, and sends a second message in advance, and the TEE of the first node device does not verify the second message.

In step 5103, when the second message passes the TEE verification of the first node device, the TEE of the first node device generates the notification message.

For example, in a case that the second message passes the TEE verification of the first node device, the TEE of the first node device generates a notification message based on the first tenure.

In another possible implementation manner, in order to avoid that the content of the notification message is tampered after the notification message leaves 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, and obtains a digital signature of the notification message.

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.

In one 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.

The process shown in this step 511 is similar to the process in which the TEE of the first node device sends the second request to the second node device in the block chain system through the first node device REE in the step 503, and this step 511 is not described again in this embodiment of the present application.

512. The TEE of the second node device receives the notification message through the REE of the second node device.

In one possible implementation, the TEE of the second node device receives the notification message and the digital signature of the notification message through the REE of the second node device.

The second node device in steps 512-514 performs the processes shown in steps 512-514 for any second node device in the blockchain system, that is, for each second node device in the blockchain system.

The process shown in step 512 is the same as the process in which the TEE of the second node device receives the second request through the REE of the second node device in step 504, and here, the description of step 512 is omitted in this embodiment of the present application.

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

In one 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. And if the signature verification is successful, the TEE of the second node equipment verifies the notification message. If the signature verification fails, it indicates that the content of the notification message has been tampered, and the TEE of the second node device does not verify the notification message.

514. In the event that 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.

For example, the TEE of the second node device modifies the identifier of the following state corresponding to the first node device in the state table to an identifier of the leading state, where for the second node device, the leading node in the blockchain system is the first node device. The TEE of the second node device may further update the node status identifiers of the common node devices in the status table, except for the first node device, to be the following status identifiers, so as to indicate that the common node devices in the common node cluster, except for the first node device, are the following nodes.

In a possible implementation manner, in a case that the notification message passes the verification of the TEE of the second node device, the TEE of the second node device parses the first tenure of the first node device from the notification message. The TEE of the second node device updates the recorded tenure of the second node device to the first tenure, 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 tenure of the leader node as the respective latest tenure.

In the method provided by the embodiment of the present application, the second request is generated by the TEE of the node device in the blockchain system, and the second request is sent to other node devices in the blockchain system to initiate election. Because the TEE does not have a Byzantine error, the TEE does not have the Byzantine error when generating the second request, thereby avoiding the participation node equipment from maliciously initiating election and reducing the Byzantine error in the block chain system. And after the REE of the node equipment triggers the TEE to initiate election, the TEE can verify whether the election time really reaches or not, so that the situation that the election time in the REE is maliciously tampered and the election is initiated in advance can be avoided. And 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, so that the content of the message is prevented from being tampered after the message leaves the TEE of the first node device.

For further explanation of the process in fig. 5, reference is made to a schematic diagram of a leader node election process provided in the embodiment of the present application shown in fig. 6. When each piece of consensus node equipment in the block chain system is started, the REE of each piece of consensus node equipment calls an initialization interface to trigger the TEE of each piece of consensus node equipment to perform initialization consensus (initialization consensus) configuration (for example, the processes shown in the steps 5011 to 5013), and the TEE of each piece of consensus node equipment also sends election time to the REE of the corresponding piece of consensus node equipment, so that the REE starts countdown. When the election time of the first following node (namely the following node with the nearest election time at the beginning) in the blockchain system arrives, the REE of the following node calls a timeout interface to prompt the TEE of the following node to initiate election. The TEE of the follower node further verifies whether the election time is actually reached or timed out to ensure the correctness of the timeout mechanism. When the election time does actually arrive or times out, the follower node becomes a candidate node. The TEE of the candidate node increases the tenure of the candidate node and generates a second request according to the increased tenure. 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 and sends the second request to non-leader nodes in the consensus cluster other than 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. And the TEE of the non-leader node determines whether to vote for the candidate node according to the tenure of the TEE, and the TEE of the non-leader node 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 the input interface. And counting the number of the non-leader nodes which approve the ticket for the candidate node in the consensus cluster based on the reception of each second response by the TEE of the candidate node, wherein if the majority of the non-leader nodes in the consensus cluster approve the ticket, the candidate node becomes the leader node in the block chain system. The REE of the leader node checks whether the heartbeat time (such as the target time) arrives, and if so, the TEE of the leader node is prompted to generate heartbeat information (such as a notification message). After receiving the prompt of the REE, the TEE of the leader node verifies whether the heartbeat duration really reaches, if the heartbeat duration really reaches, the TEE of the leader node generates heartbeat information and sends a 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. And after receiving the heartbeat message, the REE of the non-leader node sends the heartbeat message to the TEE of the non-leader node by calling the input interface, and when the TEE of the non-leader node receives the heartbeat message and indicates that the leader node is generated in the block chain system, the non-leader node becomes a follower node, and the TEE of the non-leader node records the information of the leader node.

For further explaining the process of block consensus, refer to a flowchart of a data processing method provided by an embodiment of the present application shown in fig. 7.

701. If the first node device is a leader node in the blockchain system, the REE of the first node device acquires a fifth request of the terminal.

Wherein the fifth request indicates that a transaction is to be conducted between at least two blockchain accounts. The terminal is a user equipment except the first node equipment, or the first node equipment.

The terminal is internally provided with a client, a user issues a trading instruction for trading between at least two blockchain accounts to the client, and the client generates the fifth request based on the trading instruction after receiving the trading instruction. And if the first node device is the terminal, the first node device acquires the fifth request from the client.

If the first node device is a user device other than the first node device, the terminal obtains the fifth request from the client, and sends the fifth request to the first node device, and accordingly, the REE of the first node device receives the fifth request. Or, the terminal sends the fifth request to any second node device in the blockchain system, and after the REE of the second node device receives the fifth request of the terminal, the REE 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.

702. The REE of the first node device generates a block based on the fifth request and buffers the block.

Wherein the block is any block generated by the first node device, the block including at least one transaction event, each transaction event indicating that a transaction between at least two blockchain accounts has been completed.

In a possible implementation manner, the REE of the first node device performs a transaction between at least two blockchain accounts based on the indication of the fifth request, and obtains a transaction event corresponding to the fifth request. The REE of the first node device packages the transaction event into a block, or packages the transaction event and at least one transaction event in an event pool into a block, wherein the event pool comprises a plurality of transaction events to be packaged. And adding a block header to the block body by the REE of the first node device based on each transaction event in the block body to obtain the block. The block header comprises a hash value of the block and a block number of the block, the hash value of the block is obtained based on the hash value of each transaction event in the block, and the block number of the block is 1 greater than the block number of the last block on a local blockchain account of the blockchain system. The block number of any block in the block chain ledger indicates the position of the block on the block chain ledger, and the block number of any block may also be referred to as the block height of the block.

In one possible implementation, the REE of the first node device caches the block in the memory after the block is generated.

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

703. The REE of the first node device sends the identification of the block to the TEE of the first node device.

Wherein the identification of the block is used to refer to the block. In one possible implementation, the identification of the block includes at least one of a hash value of the block and a block number of the block.

In one possible implementation, the REE of the first node device generates a third message, where the third message indicates that the block is commonly recognized by the common recognition cluster. Wherein 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.

In a possible implementation manner, this 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.

704. The TEE of the first node equipment receives the identification of the block and generates a log of the block based on the identification of the block, wherein the block is referred to by the identification of the block in the log.

Wherein the log includes the identity of the block but not the block, and refers to the block with the identity of the block but not the block. For example, the identifier of the chunk includes at least one of a hash value of the chunk and a chunk number of the chunk, and of course, the identifier of the log may be represented by other means than a hash value of the chunk or a chunk number, and the application does not limit the identifier of the log.

In one possible implementation, the log further includes at least one of an index of the log and an expiration date of the first node device.

In a possible implementation manner, 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.

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 the 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.

The target index is an index of the log, and the target index is larger 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, the second preset value may be 1 or other values, and the second preset value may be set according to an actual application scenario, where the second preset value is not limited in the embodiment of the present application.

In one possible implementation, the TEE of the first node device records the status of the log as an uncommitted status to indicate that the block corresponding to the log has not been committed to a local blockchain ledger of the blockchain system.

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

In another possible implementation manner, the TEE of the first node device generating the log of the block based on the block in the REE of the first node device includes: 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 identifier of the block from the block carried by the third message, and generates a log of the block based on the identifier of the block. When the log is generated, the TEE of the first node device discards the block.

The data size of the third message including the identification of the block is much smaller than that of the third message including the block, for example, the data size of the third message including the block in fig. 8 can reach 2M compared with the data size of a different third message provided by the embodiment of the present application shown in fig. 8, and the data size of the third message including the identification of the block has 200 bytes (bytes). Therefore, the REE sends the block identification to the TEE, and the data volume of interaction between the TEE and the REE can be reduced.

705. The TEE of the first node device sends the log to the REE of the first node device.

In a possible implementation manner, the TEE of the first node device generates a first target message based on the log, where the first target message carries the log, the first target message indicates a second node device in the blockchain system to process the log and a 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.

In another possible implementation manner, in order to avoid tampering with the content of the first target message 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, and obtains a digital signature of the first target message. Accordingly, 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.

706. The REE of the first node device receives the log and sends a first request to a second node device in the blockchain system, wherein the first request carries the log, and the first request indicates the second node device to process the log.

In a possible implementation manner, the REE of the first node device receives a first target message, and queries, in the memory, a block indicated by an identifier of a block in the log based on the log carried by the first target message. 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 where the first request indicates to process the block and the log of the block.

If the REE of the first node device further receives the 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 at this time, the first request indicates to process the block and the log of the block.

And after the REE of the first node equipment generates the first request, sending the first request to second node equipment in the block chain system.

To further illustrate the difference between the first request and the log replication request, refer to a schematic diagram of a comparison between the first request and the log replication request in the related art provided by the embodiment of the present application shown in fig. 9. As shown in fig. 9, the log replication request carries a log of the block, and the log in the log replication request includes an index of the log and the block, and the log in the log replication request is a log in the related art. The first request carries the block and the log of the block, and the log in the first request comprises the identification of the block and the index of the log, but does not comprise the block.

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

The second node device in steps 707-712 performs the processes shown in steps 707-712 for any second node device in the blockchain system, i.e., for each second node device in the blockchain system.

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

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

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

For example, the REE of the second node device sends the first request after transferring the block to the TEE of the second node device, and at this time, the first request no longer carries the block.

710. The TEE of the second node device receives the log and verifies the log.

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

The way in which the TEE of the second node device verifies the log includes any one of the following

ways

1 or 2.

In the mode 1, the TEE of the second node device stores the log sequence of the second node device, and the TEE of the second node device verifies the log based on the index of the last log in the log sequence.

For example, the TEE of the second node device obtains the log from the target message, compares the index of the log with the 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, otherwise, the TEE of the second node device does not verify the log.

Mode 2, the TEE of the second node device verifies the log based on the index of the last log in the log sequence and the public key pair of the first node device.

If the first target message and the digital signature of the first target message are analyzed 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. And if the signature verification is successful, the TEE of the second node equipment passes the verification of the first target message. And if the signature verification fails, the content of the first target message is tampered, and the TEE of the second node device does not verify the first target message.

And if the index of the log is larger than the index of the last log in the log sequence by a second preset value, the TEE of the second node equipment passes the log verification, otherwise, the TEE of the second node equipment does not pass the log verification. Or, if the index of the log is greater than the index of the last log in the log sequence by a second preset value, and the tenure of the first node device carried by the log is the same as the tenure of the leader node in the TEE recording block chain system of the second node device, the TEE of the second node device passes the log verification, otherwise, the log verification fails.

711. In the event that the log passes the verification of the TEE of the second node device, the TEE of the second node device stores the log.

And if the TEE of the second node equipment passes the log verification, the TEE of the second node equipment adds the log in the log sequence of the second node equipment, and at the moment, the log is the last log in the log sequence.

In a possible implementation manner, in a case that the log passes the verification of the TEE of the second node device, the TEE of the second node device records the state of the log as an uncommitted state to indicate that the block corresponding to the log is not yet committed to the local blockchain ledger of the blockchain system.

In case the log does not pass the authentication of the TEE of the second node device, then the second node device does not perform this step 711.

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

Wherein the first response comprises a first target identity indicating that the second node device has agreed to receive the log or a second target identity indicating that the second node device does not agree to receive the log.

In one possible implementation, in a case that the log passes the verification of the TEE of the second node device, the TEE of the second node device generates a first response including the first target identifier, when the first response indicates that the second node device has agreed to receive the log. In the event that the log does not pass the verification of the TEE of the second node device, the TEE of the second node device generates a first response including a second target identification, at which time the first response indicates that the second node device does not agree to receive the log.

Further, to avoid tampering with the content of the first response, the TEE of the second node device signs the first response based on the private key of the second node device, resulting in 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.

The process of sending the first response to the first node device by the TEE of the second node device through the REE of the second node device is the same as the process of sending the second response to the first node device by the TEE of the second node device through the REE of the second node device in step 506.

713. The TEE of the first node device receives a plurality of first responses through the REE of the first node device.

Wherein each first response of the plurality of first responses is from one second node device in the common cluster. In one possible implementation, the TEE of the first node device receives, via the REE of the first node device, the plurality of first responses and the digital signature of each first response.

The process that the TEE of the first node device receives the plurality of first responses through the REE of the first node device is the same as the process that the TEE of the first node device receives the plurality of second responses through the REE of the first node device in step 507, and herein, this step 713 is not described again in this embodiment of the present application.

714. The TEE of the first node device verifies each first response received.

Taking the example that the TEE of the first node device verifies the first response of a second node device, the following description is given to the step 714:

and 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. And if the signature verification is successful, the TEE of the first node equipment passes the verification of the first response. If the signature verification fails, it indicates that the content of the first response has been tampered, and the TEE of the first node device does not verify the first response.

715. In the case where the first responses of half or most of the second node devices in the blockchain system pass the verification of the TEE of the first node device, and each first response passing the verification indicates that one second node device has agreed to receive the log, the TEE of the first node device notifies the REE to submit the block to the local blockchain ledger of the blockchain system based on the identity of the block in the log.

The local block account of the blockchain system of the first node device is stored in the REE of the first node device.

In a possible implementation manner, when the first response of half or most of the second node devices in the block chain system passes the verification of the TEE of the first node device, the TEE of the first node device parses the first response of the second node device to obtain a target identifier (such as a first target identifier or a second target identifier) carried by the first response. And the TEE of the first node device counts the total number of the first target identifiers in the first response passing the verification, wherein the total number is the number of the second node devices which agree to receive the log in the consensus cluster. The first node equipment TEE 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. If the total number is greater than or equal to the first threshold, considering that the first node device has agreed to receive the log, it indicates that most of the common node devices in the common node cluster have agreed to receive the log, that is, the common node cluster passes through the block corresponding to the log. The TEE of the first node device notifies the REE to submit the block to a local blockchain ledger of the blockchain system based on the identity of the block in the log.

For example, the TEE of the first node device generates a fourth message based on the identifier of the block in the log, where the fourth message carries the identifier of the block, and the fourth message instructs the REE of the first node device to submit the block to a local blockchain ledger of the 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, queries the block cached in the memory based on the identifier of the block carried in the fourth message, and stores the queried block in a block chain ledger of the block chain system in a persistent storage medium.

Then, the TEE of the first node device updates the recorded status of the log to a commit status to indicate that the block corresponding to the log has been committed to an account on a blockchain of the blockchain system.

The TEEH of the first node device may also return a transaction success message to the terminal through the REE of the first node device, where the transaction success message is used to indicate that the fifth request has been completed.

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, wherein the third request instructs the second node device to submit the block to a local blockchain account book of the blockchain system.

Wherein the third request may be a heartbeat message or other type of message other than a heartbeat message.

In a possible implementation manner, the TEE of the first node device generates the third request based on the index of the log, and the third request carries the index of the log. Optionally, the third request further carries a first tenure of the first node device.

In another possible implementation manner, to avoid tampering with the content of the third request 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 first node device private key, and obtains a digital signature of the third request. Accordingly, the TEE of the first node device sends a third request and a digital signature of the third request to a second node device in the blockchain system through the REE of the first node device.

Here, the process of sending the third request to the second node device in the blockchain system by the TEE of the first node device through the REE of the first node device in the embodiment of the present application is the same as the process of sending the second request to the second node device in the blockchain system by the TEE of the first node device through the REE of the first node device in step 503.

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

The second node device in steps 717-719 performs the process shown in steps 717-719 for any one of the second node devices in the blockchain system, i.e., for each second node device in the blockchain system.

In one 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.

The process in step 717 is similar to the process in which the TEE of the second node device receives the second request through the REE of the second node device in step 504, and here, the description of step 717 is omitted in this embodiment.

718. The TEE of the second node device verifies the third request.

In one 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. And if the signature verification is successful, the TEE of the second node equipment passes the verification of the third request. If the signature verification fails, it indicates that the content of the third request has been tampered, and the TEE of the second node device does not verify the third request.

719. In the case that 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 to a local blockchain ledger of the blockchain system based on the identification of the block in the log.

The process of notifying the REE of the second node device to submit the block to the local blockchain account book of the blockchain system by the TEE of the second node device based on the identifier of the block in the log is the same as the process of notifying the REE of the first node device to submit the block to the local blockchain account book of the blockchain system by the TEE of the first node device based on the identifier of the block in the log in step 715, and here, this step 719 is not described in detail in this embodiment of the present application.

In one possible implementation, in a case that 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. And updating the recorded state of the log into a submission state by the TEE of the second node device based on the index of the log so as to indicate that the block corresponding to the log is submitted to a block chain account book in the block chain system.

It should be noted that the process shown in fig. 7 is described by taking the first request carrying the block and the log of the block as an example, but in another possible implementation manner, when the TEE of the first node device initiates the consensus node device in the consensus cluster to perform consensus on the log, the TEE may not send the block first, and after the completion of the consensus on the log, send the block again. For example, when the REE of the second node device in the blockchain system receives the third request, the block in the third request is transferred to the in-memory cache, and then the TEE of the second node device sends the three requests. Therefore, when a few common node devices in the common cluster agree to receive the log, the TEE of the first node device does not need to send a third request to the second node device in the blockchain system, and therefore the first node device is prevented from sending the block with the failure in common identification to the second node device in the blockchain system.

In the method provided by the embodiment of the present application, a log is generated by a TEE of a node device in a 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 can identify the log. Because the TEE is protected by hardware and cannot be badly done, the purpose of using the TEE to protect the consensus process can be realized, and the Byzantine error in the block chain system can be prevented. In addition, the block is referred to as the identification of the block in the log, and the log does not need to carry the block, so that the data volume of the log is reduced, and correspondingly, the storage space occupied by the log sequence is reduced. And the first request also carries the digital signature of the log, so that the log is prevented from being tampered, and the log consensus error is avoided. 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, so that the content of the first response is prevented from being tampered, and log consensus errors are avoided.

To further illustrate the process shown in fig. 7, refer to a schematic diagram of a block consensus process provided by the embodiment of the present application shown in fig. 10. The proposal module of the REE of the leader node transacts the request (e.g., the fifth request), generates a block, sends an identification 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 blocks based on the identification of the blocks. The TEE of the leader node adds the log to a log sequence, generates a first request, and sends the first request through the REE of the output interface leader node, 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 respective TEE. And the TEE of each non-leader node verifies the log carried by the first request, if the log passes the verification, the log is added into a local log sequence, and if the log does not pass the verification, the log is not received. The TEE of each non-leader node generates a log addition result (e.g., a first response) and sends the log addition result to the respective REE 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 each received 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 informs the consensus result of the log through the output interface (for example, more than half of the consensus nodes add the log), and the transaction is successful. Then, when the REE of the leader node checks that the heartbeat duration (such as the target duration) has been reached or is overtime, the TEE of the leader node is triggered to initiate heartbeat information (such as a third request). And then, the TEE of the leader node verifies whether the heartbeat time really reaches or is overtime, if the heartbeat time really reaches or is overtime, the TEE of the leader node generates heartbeat information, the heartbeat information carries the index of the currently submitted log, and the TEE of the leader node sends the heartbeat information to the REE of the leader node through an output interface. The REE of the leader node sends the heartbeat message to each non-leader node in the consensus cluster. The REEs of each non-leader node send the received heartbeat messages to the respective TEE by calling the input interface. And after the TEE of each non-leader node receives the heartbeat message, submitting the log according to the index carried by the heartbeat message.

To further illustrate the process shown in fig. 7, refer to a schematic diagram of a block storage provided in the embodiment of the present application shown in fig. 11. And the REE of the leader node packages the transaction, generates a block and caches the block. The REE of the leader node sends the identification of the block to the TEE of the leader node to instruct the TEE to consensus the identification of the block. The TEE of the leader node generates a log based on the identity of the block and signs the log. The TEE of the leader node returns the log and a digital signature (sign) of the log to the REE of the leader node. And the REE of the leader node acquires the block corresponding to the log from the cached block, and synchronizes the block and the log to the follower node. For example, the REE of the leader node sends the log, the digital signature of the log, and the block to each of the following nodes. The REE of each following node caches the block and sends the log and the log's digital signature to the respective TEE. And the TEE of each following node verifies the log based on the digital signature of the log, and if the log passes the verification, the TEE of each following node receives the log, otherwise, the log is not received. The TEE of each follower node sends the log receipt (e.g., target identification) and a digital signature of the log receipt to the respective REE. The REE of each follower node sends a respective log receipt (e.g., a first response) and a digital signature of the log receipt to the leader node. The REE of the leader node sends each received log reception result and a digital signature of each log reception result to the TEE of the leader node. And the REE of the leader node verifies the receiving result of each log based on the digital signature of the receiving result of each log. And if the log receiving results of at least half of the common node devices in the common cluster are verified, and the half of the common node devices 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 take the block corresponding to the log to the disk, and the transaction is successful. Thereafter, the TEE of the leader node generates and signs a heartbeat message (e.g., a third request), which the TEE of the leader node sends to the REE of the leader node. The REE of the leader node receives and sends the heartbeat message to each of the follower nodes in the consensus cluster. The REE of each following 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 respective TEE. And verifying the heartbeat message based on the digital signature of the heartbeat message by the TEE of each following node, and submitting the log based on the index of the log carried by the heartbeat message by the TEE of each following node if the heartbeat message passes the verification. For example, the TEE of each following node notifies the respective REE to take the block corresponding to the log to the disk.

For further explanation of the processes shown in fig. 5 and fig. 7, reference is made to a schematic diagram of a data processing process in a consensus cluster provided in an embodiment of the present application shown in fig. 12. Taking the example that the consensus cluster includes the follower nodes 1-3, the following description is made with respect to fig. 12:

and (4) verifying the time stamp by the TEE of the following node 3, and if the election time is up to or overtime, performing overtime election. For example, the follower node 3 switches to a candidate node, and the TEE of the candidate node 3 sends voting requests (e.g., second requests) carrying digital signatures to the

follower nodes

1 and 2, respectively. The TEE of the following

nodes

1 and 2 respectively verifies the voting request based on the digital signature carried by the voting request. In the case that the voting request is verified, the TEEs of the following

nodes

1 and 2 vote for the candidate node 3, respectively, and return respective voting results (such as a second response) and a digital signature of the voting results to the candidate node 3, respectively. The TEE of the candidate node 3 processes the voting results to become a leader node in the consensus cluster. For example, the TEE of the candidate node 3 verifies each voting result based on the digital signature of each voting result, respectively. If at least one of the 2 voting results passes the verification and the at least one voting result is the vote of approval, the candidate node 3 is switched to be the leader node. Then, the TEE of the leader node 3 verifies the timestamp, and if the heartbeat duration reaches or is overtime, the TEE of the leader node 3 sends heartbeat messages (such as notification messages) carrying digital signatures to the

follower nodes

1 and 2 respectively. The TEEs of the following

nodes

1 and 2 verify the heartbeat messages based on the digital signatures in the heartbeat messages, respectively. In the event that the heartbeat message is validated, the TEE acceptance candidate 3 of the following

nodes

1 and 2 becomes the leader node in the consensus cluster. Thereafter, the client sends a transaction request (e.g., a fifth request) to the leader node 3, and the REE of the leader node 3 packages the transaction, generating a block. The TEE of the leader node 3 generates a log based on the identity of the block and starts a consensus log. For example, the TEE of the leader node 3 sends the log, the digital signature of the log, and the chunk to the

follower nodes

1 and 2, respectively, through REE.

REEs following nodes

1 and 2, respectively, cache blocks. The TEEs of the

follower nodes

1 and 2 verify the logs based on their digital signatures, respectively. In the case that the logs are verified, the TEEs of the following

nodes

1 and 2 receive the logs respectively, such as adding the logs to the log sequence. The following

nodes

1 and 2 return respective log reception results (e.g., first responses) and digital signatures of the log reception results to the leader node 3, respectively. The TEE of the leader node 3 verifies each log reception result based on the digital signature of each log reception result. If at least one log receiving result of the following

nodes

1 and 2 passes the verification and at least one log receiving result refers to that the log has been received, the TEE of the leader node 3 submits the log, a block corresponding to the log is landed, at this moment, the transaction is successful, and the client is informed of the transaction processing result. And then, the TEE of the leader node 3 performs timestamp verification, and if the heartbeat duration reaches or is overtime, the TEE of the leader node 3 sends heartbeat messages (such as a third request) and digital signatures of the heartbeat messages to the

follower nodes

1 and 2 respectively. The TEEs of the

follower nodes

1 and 2 verify the heartbeat messages, respectively, based on the digital signature of the heartbeat message. When the heartbeat message passes the verification, the TEEs of the following

nodes

1 and 2 submit logs based on the index of the log carried by the heartbeat message, for example, the TEEs of the following

nodes

1 and 2 notify respective REEs to take the block corresponding to the log.

With the increase of the duration of the consensus cluster service, more and more logs in the log sequence of the consensus node device are available, in order to reduce the storage space occupied by the log sequence, the TEE of the consensus node device may compress the log sequence in a snapshot manner, and for further explaining the process, refer to a flowchart of a log compression method provided in this embodiment of the present application shown in fig. 13.

1301. The TEE of the first node device truncates a plurality of submitted logs in the log sequence to obtain a snapshot of the log sequence.

At this time, the first node device is a leader node in the consensus cluster. The log sequence is a log sequence of the first node device, the log sequence being stored in a TEE of the first node device. The submitted log means that the block corresponding to the log has been submitted to a local blockchain account book of the blockchain system, or the block corresponding to the log has been landed. The snapshot includes a first identifier and a second identifier, the first identifier is an identifier of a block corresponding to a start log in the plurality of logs, and the second identifier is an identifier of a block corresponding to an end log in the plurality of logs. Wherein, the initial log in the plurality of logs is the first log in the plurality of logs, and the termination log in the plurality of logs is the last log in the plurality of logs.

In a possible implementation manner, if the number of logs in the log sequence is greater than or equal to the 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 the commit state in the log sequence as a plurality of submitted logs. The number threshold may be set according to an actual implementation scenario, and the number threshold is not limited in this embodiment of the present application.

When the submitted logs in the log sequence are determined, the TEE of the first node device generates the snapshot based on a first identifier of a start log in the logs and a second identifier of an end log in the logs, and deletes the snapshots in the log sequence. Wherein the snapshot includes the first identification and the second identification.

1302. The TEE of the first node device sends the snapshot to the REE of the first node device.

In a possible implementation manner, the TEE of the first node device generates a second target message based on the snapshot, where the second target message carries the snapshot, and the second target message instructs the second node device in the blockchain system to submit the multiple blocks corresponding to the multiple logs to a local blockchain account book based on the snapshot. The TEE of the first node device sends the second targeted message to the REE of the first node device.

In a possible implementation manner, to avoid tampering with the content of the second target message 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 the private key of the first node device, so as 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.

It should be noted that the second target message is a heartbeat message or another type of message other than a heartbeat message. If the second target message is a heartbeat message, the TEE of the first node equipment verifies whether the target time length arrives, and if the target time length arrives, the TEE of the first node equipment generates the second target message.

1303. The REE of the first node device receives the snapshot, and acquires a plurality of blocks corresponding to the plurality of logs from a local blockchain account book of the blockchain system based on the first identifier and the second identifier in the snapshot.

In a possible implementation manner, the REE of the first node device receives the second target message, parses the snapshot from the second target message, and queries, on a local blockchain ledger of the blockchain system, 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 block chain book. Wherein, the first block, the second block and each block between the first block and the second block are also a plurality of blocks corresponding to the plurality of logs. The first block is a first block of the plurality of blocks, and the second block is a last block of the plurality of blocks.

1304. The REE of the first node device sends a fourth request to the second node device in the blockchain system, where the fourth request carries the snapshot and the multiple blocks, and the fourth request instructs the second node device in the blockchain system to submit the multiple blocks corresponding to the multiple logs to a local blockchain account book based on the snapshot.

In a possible implementation manner, after the multiple blocks are obtained, the REE of the first node device generates the fourth request based on the second target message and the multiple blocks, where the fourth request carries the second target message and the multiple blocks.

In a possible implementation manner, 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, and at this time, the fourth request carries the second target message, the digital signature of the second target message, and the plurality of blocks.

When the fourth request is generated, the REE of the first node device sends the fourth request to the second node device in the blockchain system.

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

The second node devices in steps 1305 to 1309 execute the processes shown in steps 1305 to 1309 for any second node device in the blockchain system, that is, each second node device in the blockchain system.

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

For example, the REE of the second node device transfers the blocks carried by the fourth request to a memory.

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

For example, the REE of the second node device sends a fourth request after transferring blocks to the TEE of the second node device, and at this time, the fourth request no longer carries the plurality of blocks.

In one possible implementation, the snapshot does not include an identification of the block, but rather includes state data for the individual transaction events in the block, the state data for each transaction event indicating the most recent state of the data to which each transaction event relates. However, the state data of each transaction event occupies a large number of bytes, and therefore, the data size of the snapshot is large. However, the snapshot in the embodiment of the present application includes the identifier of the block, and if the identifier of the block is a block number, the first identifier and the second identifier are also two integer values, so that the number of snapshots in the embodiment of the present application is small, and accordingly, the snapshot transmission rate is high.

For example, fig. 14 is a schematic diagram of a snapshot comparison provided by the embodiment of the present application. Referring to the related art shown in the left diagram of fig. 14, log sequence 1 includes logs 1-6, and logs 1-6 include blocks 1-6, respectively, where logs 1-4 are committed logs, logs 5-6 are not yet committed, and blocks 1-4 are already committed to the blockchain ledger of the blockchain system. The leader node truncates the logs 1-4 in the log sequence 1, and generates a snapshot 1 of the log sequence 1, wherein the snapshot 1 comprises state data of each transaction event in the blocks 1-4.

The right drawing of fig. 14 is a schematic view of an embodiment of the present application. In the right diagram of fig. 14, the log sequence 2 is stored in the TEE of the leader node. Log sequence 2 includes logs 1-6, where logs 1-4 are committed logs, logs 5-6 have not yet been committed, and blocks 1-4 have been committed to the blockchain ledger for the blockchain system. And the leader node takes the block hash value as the mark of the block and indicates the block in the log. For example, logs 1-6 in block sequence 2 include hash values 1-6, respectively, to refer to blocks 1-6, respectively. The TEE of the leader node truncates logs 1-4 in log sequence 2, generating snapshot 2 of log sequence 2, where snapshot 2 includes block number 1 of the starting block and block number 4 of the ending block in blocks 1-4. It can be seen that the content of snapshot 2 is less than that of snapshot 1, and the data size of snapshot 2 is less than that of snapshot 1. And the TEE of the leader node sends a snapshot 2 to the REE of the leader node, the REE of the leader node is in a local block chain account book, blocks 1-4 corresponding to the snapshot 2 are obtained, and the snapshot 2 and the blocks 1-4 are sent to the non-leader nodes in the consensus cluster.

1308. The TEE of the second node device receives the snapshot and verifies the snapshot.

In a possible implementation manner, 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.

And the TEE of the second node device verifies and signs the digital signature of the second target message based on the public key of the first node device. Since the second target message carries the snapshot. And if the signature verification is successful, the TEE of the second node equipment verifies the snapshot to be passed. If the signature verification fails, it indicates that the content of the second target message has been tampered, and the TEE of the second node device fails to verify the snapshot.

1309. In the event that the snapshot passes the validation 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 plurality of blocks to a local blockchain ledger of the blockchain system.

And under the condition that the snapshot passes the verification of the TEE of the second node equipment, the TEE of the second node equipment analyzes the snapshot from the second target message, and acquires the first identifier and the second identifier from the snapshot. The TEE of the second node device queries a first log corresponding to the first identifier and a second log corresponding to the second identifier in a log sequence of the second node device, and the second node device 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 is a start log of the plurality of logs, and the second log is an end log of the plurality of logs.

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

For example, the TEE of the second node device sends a seventh request to the REE of the second node device, where the seventh request carries the snapshot, and the seventh request indicates that a plurality of blocks corresponding to the snapshot of the REE of the second node device are submitted to a local block chain ledger of the block chain system. After the REE of the second node device receives the seventh request, based on the snapshot carried by the seventh request, a plurality of blocks corresponding to the snapshot are queried from the cached blocks, and the queried blocks are submitted to a local block chain account book of the block chain system. The REE of the second node device may also store the snapshot in a persistent storage medium.

According to the method provided by the embodiment of the application, the snapshot is generated through the TEE of the node equipment, the snapshot carries the identification of the initial block and the identification of the termination block in the submitted multiple blocks, the data volume of the snapshot is reduced, and the TEE is protected by hardware and cannot be malicious, so that the purpose of protecting snapshot synchronization by using the TEE can be achieved, and a byzantine error in a block chain system can be prevented. And the fourth request carries the second target message and the digital signature of the second target message, so that the content of the second target message is prevented from being tampered, and the Byzantine error in the block chain system is reduced.

The method of the embodiments of the present application is described above, and the apparatus of the embodiments of the present application is described below. It is to be understood that the apparatus described below has any of the functions of any of the node devices in the above-described methods.

Fig. 15 is a schematic structural diagram of a data processing apparatus, where, referring to fig. 15, the apparatus 1500 is configured as a first node device in a blockchain system, where the first node device includes a trusted execution environment TEE and a rich execution environment REE, where the TEE includes a processing unit 1501 and the REE includes a communication unit 1502;

the processing unit 1501 is configured to generate a log of blocks in the REE, and send the log to the REE, where the blocks are referred to by the identifiers of the blocks in the log;

the communication unit 1502 is configured to receive the log, and send a first request to a second node device in the blockchain system, where the first request carries the log, and the first request indicates that the second node device processes the log.

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

receiving, by the REE, a plurality of first responses, each first response indicating whether a second node device has agreed to receive the log;

in the event that first responses of half or most of the second node devices in the blockchain system pass the validation of the TEE, and each of the first responses that pass the validation indicates that one second node device has agreed to receive the log, notifying the REE to submit the block to a local blockchain ledger of the blockchain system based on the identity of the block in the log.

Optionally, the processing unit 1501 is further configured to:

sending, by the REE, a second request to a second node device in the blockchain system, the second request indicating a vote for the first node device to become a leader node in the blockchain system;

receiving, by the REE, a plurality of second responses, each second response indicating whether a second node device agrees to the first node device to become a leader node in the blockchain system;

switching the node state of the first node device to a leader state if second responses of half or most of the second node devices in the blockchain system pass the verification of the TEE, and each of the second responses that pass the verification indicates one second node device agrees to the first node device to become the leader node in the blockchain system.

Optionally, the processing unit 1501 is further configured to:

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

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

Optionally, the processing unit 1501 is further configured to:

sending, by the REE, a third request to a second node device in the blockchain system, the third request instructing the second node device to submit the block to a blockchain ledger of the blockchain system locally, in a case where first responses of half or a plurality of second node devices in the blockchain system pass verification of the TEE, and each of the first responses that pass verification indicates that one second node device has agreed to receive the log.

Optionally, the processing unit 1501 is further configured to truncate multiple submitted logs in a log sequence, obtain a snapshot of the log sequence, and send the snapshot to the REE, where the snapshot includes a first identifier and a second identifier, where the first identifier is an identifier of a block corresponding to a start log in the multiple logs, and the second identifier is an identifier of a block corresponding to an end log in the multiple logs;

the communication unit 1502 is further configured to receive the snapshot, obtain, based on the first identifier and the second identifier in the snapshot, multiple blocks corresponding to the multiple logs from a local blockchain ledger of the blockchain system, and send a fourth request to a second node device in the blockchain system, where 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.

It should be understood that the apparatus 1500 corresponds to the first node device in the foregoing method embodiment, and each module and the foregoing other operations and/or functions in the apparatus 1500 are respectively for implementing various steps and methods implemented by the first node device in the method embodiment, and for details, reference may be made to the foregoing method embodiment, and details are not described herein again for the sake of brevity.

It should be understood that the apparatus 1500 is only illustrated by the above-mentioned division of the functional modules when determining to process data, and in practical applications, the above-mentioned function distribution may be performed by different functional modules as needed, that is, the internal structure of the apparatus 1500 is divided into different functional modules to perform all or part of the above-mentioned functions. In addition, the apparatus 1500 provided in the above embodiment is the same as the above method embodiment, and the specific implementation process thereof is described in the above method embodiment, which is not described herein again.

Fig. 16 is a schematic block diagram of a data processing apparatus, and referring to fig. 16, the apparatus 1600 is configured as a second node device in a blockchain system, where the second node device includes a trusted execution environment TEE and a rich execution environment REE; the TEE includes a processing unit 1601, the REE includes a communication unit 1602;

the communication unit 1602, configured to receive a first request from a first node device in the blockchain system, where the first request carries a log of a block, and send the log to the TEE, where the block is referred to by an identifier of the block in the log, and the first request instructs the second node device to process the log;

the processing unit 1601 is configured to, if the log passes the verification of the TEE, the TEE stores the log, and send a first response to the first node device through the REE, where the first response indicates that the second node device has agreed to receive the log.

Optionally, the first request further carries the block;

the communication unit 1602 is further configured to buffer the blocks;

the processing unit 1601, further configured to receive, by the REE, a third request from 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;

the processing unit 1601 is further configured to, if the third request passes verification of the TEE, notify the REE to submit the block to a local blockchain ledger of the blockchain system based on an identifier of the block in the log.

Optionally, the processing unit 1601 is further configured to:

receiving, 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;

sending, by the REE, a second response to the first node device indicating whether the second node device agrees to become a leader node in the block chain system if the second request passes authentication of the TEE.

Optionally, the processing unit 1601 is further configured to:

receiving, by the REE, a notification message from the first node device, the notification message instructing the first node device to become a leader node in the blockchain system;

modifying the stored node state of the first node device to a leader state if the notification message passes verification of the TEE.

Optionally, the communication unit 1602 is further configured to receive a fourth request from the first node device, where the fourth request carries a snapshot of a log sequence in the first node device and a plurality of blocks, where the snapshot includes a first identifier and a second identifier, where the first identifier is an identifier of a block corresponding to a start log in a plurality of logs submitted in the log sequence, the second identifier is an identifier of a block corresponding to an end log in the plurality of logs, and the plurality of logs correspond to the plurality of blocks;

the communication unit 1602, configured to cache the plurality of blocks, and send the snapshot to the TEE;

the processing unit 1601 is further configured to receive the snapshot, and notify the REE to submit the plurality of blocks to a local blockchain ledger of the blockchain system if the snapshot passes the verification of the TEE.

It should be understood that the apparatus 1600 corresponds to the second node device in the foregoing method embodiment, and each module and the foregoing other operations and/or functions in the apparatus 1600 are respectively for implementing various steps and methods implemented by the second node device in the method embodiment, and specific details may be referred to the foregoing method embodiment and are not described herein again for brevity.

It should be understood that, when determining to process data, the apparatus 1600 is merely illustrated by dividing the functional modules, and in practical applications, the above function allocation may be performed by different functional modules according to needs, that is, the internal structure of the apparatus 1600 is divided into different functional modules to perform all or part of the functions described above. In addition, the apparatus 1600 provided by the above embodiment belongs to the same concept as the above method embodiment, and the specific implementation process thereof is described in the above method embodiment, which is not described herein again.

Fig. 17 is a schematic structural diagram of a computer device provided in an embodiment of the present application, where the computer device 1700 includes one or more processors 1701 and one or more memories 1702. One or more processors 1701 and one or more memories 1702 are located in the TEE of the computer device 1700. The one or more memories 1702 are coupled to the one or more processors 1701, the one or more memories 1702 being configured to store at least one program code comprising computer instructions that, when executed by the one or more processors 1701, cause the computer device 1700 to perform the associated method steps described above to implement the data processing method in the embodiments described above. Computer device 1700 may be any node device provided by embodiments of the present application. Certainly, the computer device 1700 may further have a wired or wireless network interface, a keyboard, an input/output interface, and other components to facilitate input and output, and the computer device 17200 may further include other components for implementing device functions, which are not described herein again.

In an exemplary embodiment, a computer readable storage medium, such as a memory including program code, which is executable by a processor in a TEE of a computer device to perform the data processing method in the above embodiments, is also provided. 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, an optical data storage device, and the like.

The embodiment of the present application further provides a computer program product, where the computer program product includes computer instructions, the computer instructions are stored in a computer-readable storage medium, a processor of a TEE of a 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 data processing method.

In addition, embodiments of the present application also provide an apparatus, which may be specifically a chip, a component or a module, and may include a processor and a memory connected to each other; the memory is used for storing computer execution instructions, and when the device runs, the processor can execute the computer execution instructions stored by the memory, so that the chip can execute the data processing method in the above method embodiments.

The apparatus, the device, the computer-readable storage medium, the computer program product, or the chip provided in this embodiment are all configured to execute the corresponding method provided above, and therefore, the beneficial effects that can be achieved by the apparatus, the device, the computer-readable storage medium, the computer program product, or the chip may refer to the beneficial effects in the corresponding method provided above, which are not described herein again.

Through the description of the above embodiments, those skilled in the art will understand that, for convenience and simplicity of description, only the division of the above functional modules is used as an example, and in practical applications, the above function distribution may be completed by different functional modules as needed, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions. In addition, the data processing method embodiment provided by the above embodiment belongs to the same concept, and the specific implementation process thereof is described in the method embodiment, which is not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical functional division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another device, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may be one physical unit or multiple physical units, that is, may be located in one place, or may be distributed in multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially or partially contributed to by the prior art, or all or part of the technical solutions may be embodied in the form of a software product, where the software product is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a U disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

In the description of this application, "/" means "or" unless otherwise stated, for example, A/B may mean A or B. "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. Further, "at least one" means one or more, "a plurality" means two or more. The terms "first," "second," and the like do not denote any order or importance, but rather the terms "first," "second," and the like do not denote any order or importance.

In this application, the words "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.

All the above optional technical solutions may be combined arbitrarily to form the optional embodiments of the present disclosure, and are not described herein again.

The above description is only exemplary of the present application and should not be taken as limiting, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A data processing method, performed by 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 method comprises the following steps:

the TEE generating a log of blocks in the REE based on the blocks, the blocks being referred to in the log by their identities;

the TEE sends the log to the REE;

and the REE receives the log and sends a first request to second node equipment in the blockchain system, wherein the first request carries the log, and the first request indicates the second node equipment to process the log.

2. The method of claim 1, wherein the first request further carries the block, and wherein the first request instructs the second node device to process the log and the block; after the sending the first request to the second node device in the blockchain system, the method further comprises:

3. The method according to claim 1 or 2, wherein before the TEE generates a log based on the block in the REE, the method further comprises:

the TEE receiving, by the REE, a plurality of second responses, each second response indicating whether a second node device agrees to the first node device to be a leader node in the blockchain system;

4. The method of claim 3, wherein after the TEE switches the node state of the first node device to the leader state, the method further comprises:

5. The method of claim 2, further comprising:

6. The method according to any one of claims 1-5, further comprising:

the TEE sends the snapshot to the REE;

7. A data processing method, performed by a second node device in a blockchain system, the second node device comprising a trusted execution environment TEE and a rich execution environment REE; the method comprises the following steps:

the REE receives a first request from a first node device in the block chain system, the first request carries a log of blocks, the blocks are referred to by the identification of the blocks in the log, and the first request instructs the second node device to process the log;

the REE sends the log to the TEE;

8. The method of claim 7, wherein the first request further carries the block, and wherein after the REE receives the first request from the first node device in the blockchain system, the method further comprises:

the REE caches the block;

the TEE receiving, by the REE, a third request from the first node device, the third request instructing the second node device to submit the block to a blockchain ledger of the blockchain system locally;

9. The method as claimed in claim 7 or 8, wherein before the REE receives the first request from the first node device in the blockchain system, the method further comprises:

in an instance in which the second request passes authentication 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 to be a leader node in the blockchain system.

10. The method of claim 9, wherein after the TEE sends a second response to the first node device via the REE, the method further comprises:

11. The method according to any one of claims 7-10, further comprising:

the REE caches the blocks and sends the snapshot to the TEE;

the TEE receives the snapshot and, if the snapshot passes the TEE's validation, notifies the REE to submit the plurality of blocks to a local blockchain ledger of the blockchain system.

12. A blockchain system for data processing, the blockchain system comprising a first node device and at least one second node device;

the first node device is configured to send a first request to a second node device in the blockchain system, where the first request carries a log of a block, the block is referred to by an identifier of the block in the log, and the first request indicates that the second node device processes the log;

13. The system of claim 12, wherein the first node device comprises a trusted execution environment TEE and a rich execution environment REE;

14. The system of claim 12 or 13, wherein each second node device comprises a TEE and a REE;

15. The system of claim 14, wherein the first node device comprises a TEE and a REE;

the TEE of the first node device is used for receiving the first responses of second node devices in the blockchain system through the REE of the first node device, and informing the REE of the first node device to submit the block to a local blockchain book of the blockchain system based on the identification of the block in the log when the first responses of half or most of the second node devices in the blockchain system pass the verification of the TEE and each verified first response indicates that one second node device already stores the log.

16. The system of claim 15, wherein the first request further carries the block;

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

17. The system according to any one of claims 12-16, wherein each of the first node device and the at least one second node device comprises a TEE and a REE;

the TEE of the first node device, configured to send a second request to a second node device in the blockchain system by the TEE of the node device to which the TEE belongs, the second request indicating that the first node device becomes a leader node in the blockchain system to vote for;

the TEE of the first node device is further configured to receive, by the REE of the node device, a second response to the second request from a second node device in the blockchain system, and switch the node state of the first node device to the leader state if the second responses of half or most of the second node devices in the blockchain system pass the verification of the TEE and each of the second responses that pass the verification indicates that one second node device agrees to the first node device to become the leader node in the blockchain system.

18. The system of claim 17,

the TEE of the first node device is further configured to generate a notification message, and send the notification message to a second node device in the blockchain system through the REE of the node device, where the notification message indicates that the first node device is a leader node in the blockchain system;

the TEE of each second node device is further configured to receive the notification message through the REE of the corresponding node device, and modify the stored node state of the first node device into a leader state if the notification message passes the verification of the TEE.

19. The system according to any of claims 12-17, wherein the first node device comprises a TEE and a REE;

20. The system of claim 19, wherein each second node device comprises a TEE and a REE;

21. A data processing apparatus, characterized in that the apparatus is configured as a first node device in a blockchain system, the first node device comprising a trusted execution environment, TEE, comprising a processing unit and a rich execution environment, REE, comprising a communication unit;

the processing unit is used for generating a log of the blocks based on the blocks in the REE, and sending the log to the REE, wherein the blocks are referred to by the marks of the blocks 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, where the first request carries the log, and the first request indicates the second node device to process the log.

22. The apparatus of claim 21, wherein the first request further carries the block, and wherein the first request instructs the second node device to process the log and the block; the processing unit is further to:

receiving a plurality of first responses by said REE, each first response indicating whether a second node device has agreed to receive said log;

23. The apparatus according to claim 21 or 22, wherein the processing unit is further configured to:

receiving, by the REE, a plurality of second responses, each second response indicating whether a second node device agrees to the first node device to be a leader node in the blockchain system;

24. The apparatus of claim 23, wherein the processing unit is further configured to:

25. The apparatus of claim 22, wherein the processing unit is further configured to:

26. The apparatus of any one of claims 21-25,

the processing unit is further configured to truncate multiple submitted logs in a log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE, where the snapshot includes a first identifier and a second identifier, where the first identifier is an identifier of a block corresponding to a start log in the multiple logs, and the second identifier is an identifier of a block corresponding to an end log in the multiple logs;

the communication unit 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 local blockchain system, and send a fourth request to a second node device in the blockchain system, where the fourth request carries the snapshot and the plurality of blocks, and the fourth request instructs the second node device to submit the plurality of blocks to the local blockchain ledger based on the snapshot.

27. A data processing apparatus, characterized in that the apparatus is configured as a second node device in a blockchain system, the second node device comprising a trusted execution environment TEE and a rich execution environment REE; the TEE includes a processing unit, 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, where the first request carries a log of a block, and send the log to the TEE, where the block is referred to by an identifier of the block in the log, and the first request indicates the second node device to process the log;

the processing unit is configured to, if the log passes the authentication of the TEE, the TEE stores the log, and sends a first response to the first node device through the REE, where the first response indicates that the second node device has agreed to receive the log.

28. The apparatus of claim 27, wherein the first request further carries the block;

the communication unit is further used for caching the block;

the processing unit is further configured to receive, by the REE, a third request from the first node device, the third request instructing the second node device to submit the block to a blockchain ledger of the local 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 a blockchain ledger of the local blockchain system based on the identification of the block in the log.

29. The apparatus according to claim 27 or 28, wherein the processing unit is further configured to:

sending, by the REE, a second response to the first node device indicating whether the second node device agrees to the first node device to be a leader node in the blockchain system if the second request passes authentication of the TEE.

30. The apparatus of claim 29, wherein the processing unit is further configured to:

31. The apparatus of any one of claims 27-30,

the communication unit is further configured to receive a fourth request from the first node device, where the fourth request carries a snapshot of a log sequence in the first node device and a plurality of blocks, and the snapshot includes a first identifier and a second identifier, where the first identifier is an identifier of a block corresponding to a start log in a plurality of logs submitted in the log sequence, the second identifier is an identifier of a block corresponding to an end log in the plurality of logs, and the plurality of logs correspond to the plurality of blocks;

the communication unit is further configured to cache the plurality of blocks and send the snapshot to the TEE;

the processing unit is further configured to receive the snapshot, and notify the REE to submit the plurality of blocks to a local blockchain ledger of the blockchain system if the snapshot passes the verification of the TEE.

32. A computer device, characterized in that the computer device comprises a trusted execution environment, TEE, comprising a processor for executing program code to cause the computer device to perform the method of any of claims 1 to 11.

33. A computer-readable storage medium, characterized in that the storage medium has stored therein at least one program code, which is read by a processor in a trusted execution environment, TEE, to cause a computer device to execute the method of any one of claims 1 to 11.

34. A computer program product, characterized in that the computer program product comprises at least one program code which is read by a processor in a trusted execution environment, TEE, to cause a computer device to execute the method according to any one of claims 1 to 11.