WO2023024821A1

WO2023024821A1 - Data processing method, system and apparatus, computer device, and storage medium

Info

Publication number: WO2023024821A1
Application number: PCT/CN2022/108710
Authority: WO
Inventors: 张明阳; 程烁; 刘勋
Original assignee: 华为技术有限公司
Priority date: 2021-08-26
Filing date: 2022-07-28
Publication date: 2023-03-02
Also published as: CN115719272A

Abstract

The present application belongs to the technical field of blockchains, and discloses a data processing method, system and apparatus, a computer device and a storage medium. In the present method, a log is generated by means of a TEE of a node device in a blockchain system, and an REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that the other node devices reach a consensus on the log. Since the TEE is protected by hardware and will do no harm, the purpose of using TEE to protect a consensus process can be achieved, and Byzantine faults can be prevented from occurring in the blockchain system.

Description

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

This application claims the priority of the Chinese patent application with the application number 202110989279.0 and the invention title "data processing method, system, device, computer equipment and storage medium" filed on August 26, 2021, the entire contents of which are incorporated by reference in In this application.

technical field

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

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. Blockchain is widely used in data security due to its characteristics of decentralization, trustlessness, collective maintenance, and reliable database. Areas with high storage requirements.

The consensus nodes in the blockchain system can agree on the blocks through the consensus protocol, and store the blocks passed by the consensus on the blockchain. Current consensus protocols include crash fault tolerant (crash fault tolerant, CFT) consensus protocols, such as the Paxos consensus algorithm and the Raft consensus algorithm. The CFT consensus protocol can solve the problems of node message delay, loss and repetition caused by network failure or node crash. Therefore, in the blockchain system using the CFT consensus protocol, even if some nodes experience network failure or node crash , can still guarantee the normal operation of the blockchain system.

However, CFT consensus protocols cannot solve Byzantine faults, such as false behaviors such as falsifying node messages, tampering with node messages, or malicious responses. Byzantine errors may cause consensus errors in the blockchain system, and the blockchain system cannot work normally. Therefore, there is an urgent need for a data processing method that can reduce Byzantine errors in the blockchain system.

Contents of the invention

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

In a first aspect, a data processing method is provided, the method is executed by a first node device in a blockchain system, and the first node device includes a Trusted Execution Environment TEE and a Rich Execution Environment REE; the method includes :

The TEE generates a log of the block based on the block in the REE, and sends the log to the REE, wherein the block is referred to by the block identifier in the log;

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

Wherein, the log includes the identification of the block, but does not include the block, and refers to the block with the identification of the block, for example, the identification of the block includes the identification of the block At least one of the hash value and the block number of the block. Of course, the logo of the log can also be expressed in other ways than the hash value of the block or the block number. Herein, the application for the log The logo of is not limited.

Since the log in the present application refers to the block with the identifier of the block, the log in the present application does not include the block. However, the log in the related art does not use the identifier of the block to refer to the log, but directly adds the block to the log, that is, the log in the related art includes the block. Or it can also be understood that the present application replaces the blocks in the log in the related art with block identifiers. Compared with the whole block, the identification of the block will have a smaller data volume. Therefore, compared with the log in the related art, the data volume of the log in the present application is smaller.

This method generates a log through the TEE of the node device in the blockchain system, and the REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that other node devices can reach a consensus on the log. Since TEE is protected by hardware and will not do evil, it can achieve the purpose of using TEE to protect the consensus process and prevent Byzantine errors in the blockchain system. Moreover, the block is referred to by the block identifier in the log, and the log does not need to carry the block, thereby reducing the data volume of the log.

In a possible implementation manner, the first request also carries the block, and the first request instructs the second node device to process the log and the block; After the second node device in the chain system sends the first request, the method further includes:

The TEE receives 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 blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , the TEE notifies the REE to submit the block to the local blockchain ledger of the blockchain system based on the identification of the block in the log.

In a possible implementation, the TEE is based on blocks in the REE, and before generating a log, the method further includes:

The TEE sends a second request to the second node device in the blockchain system through the REE, and the second request indicates that the first node device becomes the leader node in the blockchain system. vote;

The TEE receives a plurality of second responses through the REE, and each second response indicates whether a second node device agrees with the first node device to become the leader node in the blockchain system;

In the blockchain system, half or most of the second responses of the second node devices have passed the verification of the TEE, and each of the verified second responses indicates that a second node device agrees with the first node When the device becomes the leader node in the blockchain system, the TEE switches the node status of the first node device to the leader status.

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

The TEE generates a notification message, and the notification message indicates that the first node device is a leader node in the blockchain system;

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

In a possible implementation manner, the notification message may be a heartbeat message or other types of messages.

In a possible implementation, the method further includes:

In the blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , the TEE sends a third request to the second node device in the blockchain system through the REE, and the third request instructs the second node device to submit the block to the local The blockchain ledger of the blockchain system.

In a possible implementation manner, the third request may be a heartbeat message or other types of messages.

In a possible implementation, the method further includes:

The TEE truncates multiple logs submitted in the log sequence to obtain a snapshot of the log sequence, and the snapshot includes a first identifier and a second identifier, wherein the first identifier is the An identifier of the block corresponding to the start log, the second identifier being the identifier of the block corresponding to the termination log in the plurality of logs;

the TEE sends the snapshot to the REE;

The REE receives the snapshot, and based on the first identifier and the second identifier in the snapshot, obtains the corresponding logs from the local blockchain ledger of the blockchain system. A plurality of blocks, sending a fourth request to the second node device in the blockchain system, the fourth request carries the snapshot and the plurality of blocks, the fourth request indicates that the second The node device submits the multiple blocks to the local blockchain ledger based on the snapshot.

Wherein, each log in the log sequence includes an identifier of a block and an index of a log, and the logs in the log sequence are arranged in descending order of the index. Optionally, each log also includes the tenure of the leader node in the blockchain system.

In a possible implementation manner, the fourth request may be a heartbeat message or other types of messages.

In a second aspect, a data processing method is provided, the method is executed by a second node device in a blockchain system, and the second node device includes a trusted execution environment TEE and a rich execution environment REE; the method includes :

The REE receives a first request from a first node device in the blockchain system, the first request carries a log of a block, and the block is referred to by the identifier of the block in the log, The first request instructs the second node device to process the log;

the REE sends the log to the TEE;

If the log has passed the verification of the TEE, the TEE stores the log, and sends a first response to the first node device through the REE, and the first response indicates that the second node The device has agreed to receive said logs.

In a possible implementation, the first request also 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 through the REE, the method further includes:

The TEE receives a third request from the first node device through the REE, and the third request instructs the second node device to submit the block to the block of the local block chain system Chain ledger;

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

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

The TEE receives a second request from the first node device through the REE, and the second request indicates to vote for the first node device to become the leader node in the blockchain system;

If the second request is verified by the TEE, the TEE sends a second response to the first node device through the REE, and the second response indicates whether the second node device agrees to The first node device becomes a leader node in the blockchain system.

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

The TEE receives a notification message from the first node device through the REE, and the notification message instructs the first node device to become a leader node in the blockchain system;

If the notification message passes the verification of the TEE, the TEE modifies the stored node status of the first node device to a leader status.

In a possible implementation, the method further includes:

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

The REE caches the plurality of blocks, and sends the snapshot to the TEE;

The TEE receives the snapshot, and if the snapshot passes the verification of the TEE, notifies the REE to submit the multiple blocks to the local blockchain ledger of the blockchain system.

In a third aspect, a blockchain system for data processing is provided, the blockchain system includes 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, the first request carries a log of a block, and the log is indicated by the identifier of the block On behalf of the block, 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 is verified by the second node device.

In a possible implementation manner, the first node device includes a Trusted Execution Environment TEE and a Rich Execution Environment REE;

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

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

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

The REE of each second node device is configured to receive the first request, and send the log carried in the first request to the TEE of the second node device to which it belongs;

The TEE of each second node device is configured to receive the first request, store the log when the log has passed the verification of the TEE, and send the log to the second node device through the REE of the second node device. A node device sends a first response, the first response indicating whether a second node device has agreed to receive the log.

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

The TEE of the first node device is used to receive the first response of the second node device in the blockchain system through the REE of the first node device, and half or a majority of them in the blockchain system If the first response of the second node device has passed the verification of the TEE, and each of the first responses passed the verification indicates that a second node device has stored the log, based on the area in the log block identification, and notify the REE of the first node device to submit the block to the local blockchain ledger of the blockchain system.

In a possible implementation manner, the first request also carries the block;

The TEE of the first node device is also used to send a third request to the second node device in the blockchain system through the REE of the node device to which it belongs, and the third request instructs the second node device to send the Submit the block to the local block chain ledger of the block chain system;

The REE of each second node device is also used to cache the block carried in the first request, receive the third request, and send the third request to the TEE of the second node device;

The TEE of each second node device is also used to receive the third request, and if the third request passes the verification of the TEE, based on the identifier of the block in the log, notify the owner The REE of the second node device submits the block to the local blockchain ledger of the blockchain system.

In a possible implementation manner, each node device in 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 is used for the TEE of the node device to which it belongs to send a second request to the second node device in the blockchain system, and the second request indicates that the first node device becomes the The leader nodes in the blockchain system vote;

The TEE of each second node device is configured to receive the second request, and when the second request passes the verification of the TEE, send the second request to the first node device through the REE of the associated node device. Two responses, each second response indicates whether a second node device agrees with the first node device to become the leader node in the blockchain system;

The TEE of the first node device is also used to receive the second response of the second node device in the blockchain system to the second request through the REE of the node device to which it belongs. In the blockchain system, half of the Or the second response of most of the second node devices has passed the verification of the TEE, and each of the second responses that pass the verification indicates that a second node device agrees that the first node device becomes a member of the block chain system. In the case of the leader node, switch the node state of the first node device to the leader state.

In a possible implementation manner, the TEE of the first node device is also used to generate a notification message, and send the notification message to the second node device in the blockchain system through the REE of the node device to which it belongs, The notification message indicates that the first node device is a leader node in the blockchain system;

The TEE of each second node device is also used to receive the notification message through the REE of the node device to which it belongs, and when the notification message passes the verification of the TEE, the stored first node device The node status is changed to leader status.

The TEE is configured to truncate multiple logs submitted in the log sequence, obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot includes a first identifier and a second identifier, wherein, The first identification is the identification of the block corresponding to the start log in the plurality of logs, and the second identification is the identification of the block corresponding to the termination log in the plurality of logs;

The REE is configured to receive the snapshot, and based on the first identifier and the second identifier in the snapshot, obtain the plurality of logs from the local blockchain ledger of the blockchain system For multiple corresponding blocks, send a fourth request to the second node device in the blockchain system, and the snapshot includes the identification of the first block in the blockchain account book at the current moment and the last block block identification, 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 .

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

The TEE of each second node device is used to receive the snapshot, and when the snapshot passes the verification of the TEE, notify the REE of the second node device to transfer the multiple blocks based on the snapshot Submit to the blockchain ledger of the local blockchain system.

In a fourth aspect, a data processing device is provided, configured to execute the above data processing method. Specifically, the data processing apparatus includes a functional module configured to execute the data processing method provided in the above first aspect or any optional manner of the above first aspect.

In a fifth aspect, a data processing device is provided, configured to execute the above data processing method. Specifically, the data processing apparatus includes a functional module for executing the data processing method provided in the second aspect above or in any optional manner of the second aspect above.

According to a sixth aspect, there is provided a computer device, the computer device includes a trusted execution environment TEE, and the TEE includes a processor, the processor is used to execute program codes, so that the computer device executes to realize the operations performed by the above-mentioned data processing method .

In a seventh aspect, a computer-readable storage medium is provided, in which at least one piece of program code is stored, and the program code is read by a processor in the trusted execution environment TEE so that the computer device executes the above-mentioned data processing method. The action to perform.

In an eighth aspect, a computer program product is provided, the computer program product includes program code, the program code is stored in a computer-readable storage medium, and the processor in the trusted execution environment TEE of the computer device reads the program code from the computer-readable storage medium The program code is read, and the processor executes the program code, so that the computer device executes the method provided in the above-mentioned first aspect or various optional implementation manners of the first aspect, or the computer device executes the above-mentioned second aspect or the second aspect. Methods provided in various alternative implementations of the aspect.

Description of drawings

Fig. 1 is a schematic diagram of a block chain system provided by the embodiment of the present application;

FIG. 2 is a schematic diagram of role switching of consensus node devices in a Raft consensus algorithm provided by an embodiment of the present application;

FIG. 3 is a schematic diagram of a consensus cluster that implements the Raft consensus algorithm based on TEE provided by the embodiment of the present application;

Fig. 4 is a schematic diagram of a consensus node device implementing the Raft consensus algorithm based on TEE provided by the embodiment of the present application;

FIG. 5 is a flow chart of a method for electing a leader node provided in an embodiment of the present application;

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

FIG. 7 is a flow chart of a data processing method provided by an embodiment of the present application;

Fig. 8 is a schematic diagram of a data volume comparison of a different third message provided by the embodiment of the present application;

FIG. 9 is a schematic diagram of a comparison between a first request provided by an embodiment of the present application and a log copy request in the related art;

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

Fig. 11 is a schematic diagram of a block storage provided by an embodiment of the present application;

FIG. 12 is a schematic diagram of a data processing process in a consensus cluster provided by an embodiment of the present application;

FIG. 13 is a flow chart of a log compression method provided by an embodiment of the present application;

Fig. 14 is a flowchart of a schematic diagram of snapshot comparison provided by the embodiment of the present application;

Fig. 15 is a schematic structural diagram of a data processing device provided by an embodiment of the present application;

FIG. 16 is a schematic structural diagram of a data processing device provided by an embodiment of the present application;

Fig. 17 is a schematic structural diagram of a computer device provided by an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solution and advantages of the present application clearer, the implementation manners of the present application will be further described in detail below in conjunction with the accompanying drawings.

Fig. 1 is a schematic diagram of a block chain system provided by the embodiment of the present application. Referring to Fig. 1, the block chain system 100 includes a plurality of node devices 101, and all or part of the node devices in the plurality of node devices 101 are The consensus node devices in the block chain system 100, and the clusters formed by the consensus node devices in the block chain system 100 can be recorded as consensus clusters. Among them, the consensus node device has the function of generating a block (Block) and broadcasting the block in the consensus cluster, so that each consensus node device in the consensus cluster can agree on the block based on the consensus protocol. If most of the consensus node devices in the consensus cluster pass the consensus on the block, each consensus node device in the consensus cluster will store the block on the blockchain (Blockchain) ledger of the local blockchain system 100, thereby Each consensus node device in the consensus cluster stores the same blockchain ledger, achieving the purpose of the consensus cluster maintaining the same blockchain ledger. Of course, the consensus cluster can also maintain multiple blockchain ledgers at the same time in the same way as maintaining one blockchain ledger.

Among them, the consensus protocol includes the CFT consensus protocol, and the CFT protocol first has the Paxos algorithm. Due to the poor comprehensibility of the Paxos algorithm, many other CFT protocols were subsequently derived from the Paxos algorithm. Among them, other representative CFT protocols such as the Raft consensus algorithm, the Raft consensus algorithm simplifies the design and process optimization of the Paxos algorithm, making it easier to understand and implement, and easier to apply in actual systems.

In the Raft consensus algorithm, the consensus node device in the consensus cluster can have three roles, namely leader, candidate (candidate), and follower (follower). Among them, the role of the consensus node device can also be understood as Node status. These three roles can be converted to each other. In combination with the schematic diagram of the role conversion of the consensus node device in a Raft consensus algorithm provided by the embodiment of the present application shown in FIG. 2, the three roles are introduced as follows:

Leader: In the blockchain system, there is a consensus node device as the leader, which is used to generate blocks and block logs, and broadcast blocks and logs in the consensus cluster so that non-leader nodes in the consensus cluster can receive block blocks and logs. It is also used to maintain a heartbeat with non-leader nodes to notify non-leader nodes that they are the leader in the blockchain system. Among them, the non-leader node is a consensus node device as a follower or candidate in the blockchain system. For ease of description, the consensus node device that is the leader in the blockchain system is recorded as the leader node. Record the consensus node device as a candidate in the blockchain system as a candidate node. The consensus node device as a follower in the blockchain system is recorded as a follower node, that is, both the candidate node and the follower node are non-leader nodes.

Candidate: A candidate is an intermediate state between the follower and the leader. The candidate node is used to send a voting request to each non-leader node in the consensus cluster to request each non-leader node to vote for the candidate node to become the leader node . When the candidate node succeeds in running for the leader (or in other words, the election is successful), the candidate node is converted from a follower candidate to a leader.

Follower: Any consensus node device in the consensus cluster is a follower at startup. The follower node is used to respond to the leader node to receive the logs and blocks sent by the leader node, and to vote for the candidate node to become the leader.

In the Raft consensus algorithm, replica data exists in the form of logs. The logs in related technologies include blocks and some additional information, such as log index (Log index) and term (Term). The leader node in the consensus cluster can generate a log and broadcast the log in the consensus cluster, so that each non-leader node in the consensus cluster can agree on the log. The consensus cluster realizes the block corresponding to the log by consensus on the log. Make a consensus. However, in the solution described in this application, the log is improved to match the realization of the solution. Specifically, the log in the scheme proposed in this application does not include blocks, and only uses a logo to indicate the block corresponding to the log. It can also be understood that the block logo is used to replace the block in the log. The block itself, therefore, hereinafter, is also expressed as, in the log, the block identifier refers to the block corresponding to the log.

The main process of the Raft consensus algorithm includes the leader node election process and the log replication process (that is, the log consensus process). The following describes the election mechanism in the leader node election process and the log replication mechanism in the log replication process in related technologies in conjunction with Figure 2. :

1. Election mechanism, taking any consensus node device in the consensus cluster as an example, the election mechanism is introduced as follows:

The consensus node device is a follower at startup, and at this time the consensus node device is a follower node. Follow the node to set a term, which corresponds to an election process in the consensus cluster. For example, a term of 1 corresponds to the first election process in the consensus cluster, and a term of 2 corresponds to the second election process in the consensus cluster. The follower node also sets an election time to start electing itself to become the leader, and starts the countdown. When the election time reaches or times out, and there is no leader in the consensus cluster within the preset time period, the follower node updates its own term (such as term plus 1), which corresponds to an election process in the consensus cluster, for example, the term is 1 Corresponding to the first election process in the consensus cluster, the term of 2 corresponds to the second election process in the consensus cluster. The consensus node device is converted from a follower to a candidate. At this time, any consensus node device is a candidate node, and the updated term corresponds to the election process that the candidate node will initiate (ie, this election process).

A candidate node initiates an election by sending a voting request to each non-leader node except the candidate node in the consensus cluster, wherein the voting request carries the term of the candidate node (ie, the updated term).

After receiving the voting request, each non-leader node returns the voting result to the candidate node according to the term of office of the candidate node in the voting request. For example, if the tenure of the candidate node is higher than that of a non-leader node, and the non-leader node has not voted for other candidate nodes, then the non-leader node agrees to become the leader in the consensus cluster of the candidate node, and submits to the Candidate nodes return voting results representing yes votes. And if the tenure of the candidate node is less than or equal to the tenure of the non-leader node, or the non-leader node has voted for other candidate nodes, the non-leader node opposes the candidate node becoming the leader in the consensus cluster. The candidate leader node returns the voting result representing the negative vote.

After the candidate node receives the voting results of multiple non-leader nodes, count the number of non-leader nodes (that is, the number of yes votes) that voted for the candidate node. If most of the non-leader nodes (including the candidate node) in the consensus cluster vote for the candidate node, the consensus node device will be converted from the candidate to the leader in the consensus cluster. At this time, the consensus node is the leader node. The leader node sends a heartbeat message to each non-leader node in the consensus cluster to inform each non-leader node that it is the leader in the consensus cluster and the term of the leader, so that each non-leader node in the consensus cluster takes the term of the leader as respective terms of office.

If a small number of non-leader nodes in the consensus cluster vote for the candidate node, it means that the majority of the non-leader nodes in the consensus cluster have voted for another candidate node, and another candidate node may have become the leader, then The candidate node fails this election (that is, loses the election). During this election, if the candidate node receives the heartbeat message sent by the leader node in the consensus cluster, it means that a candidate node has become the leader in the consensus cluster, and the candidate node fails this election. Once the candidate node election fails, the consensus node device switches from a candidate to a follower. Or, if the election times out and a leader has not been elected in the consensus cluster, the consensus node device switches from a candidate to a follower.

2. Log replication mechanism:

Each consensus node device in the consensus cluster maintains a log sequence, which includes multiple logs, and the multiple logs are arranged in order according to the index in the log from small to large to form a log sequence. When the leader node in the consensus cluster generates a new block, the leader node generates the log of the block based on the block and the index of the last log in the local log sequence. The index in the log is higher than the current moment in the log sequence The index of the last log is 1 greater. The leader node adds the log to the end of the local log sequence, and sends a log copy request to each non-leader node in the consensus cluster, and the log copy request carries the log.

After receiving the log copy request, each non-leader node decides whether to agree to receive the log according to the content of the log carried in the log copy request. If a non-leader node agrees to receive the log, the non-leader node adds the log to the log sequence of the non-leader node, and returns a response of agreeing to receive the log to the leader node. When most non-leader nodes in the consensus cluster agree to receive the log, the leader node indicates that most non-leader nodes in the consensus cluster have agreed to receive the log by sending a heartbeat message to each non-leader node in the consensus cluster. When each non-leadership node receives the heartbeat message, it submits the block carried by the log to the blockchain ledger of the respective blockchain system. Reach a consensus.

The Raft consensus algorithm is a representative of the CFT consensus algorithm. Each blockchain underlying technology platform can generally support the Raft consensus algorithm. For example, the blockchain underlying technology platform introduces the open source code implementation of the Raft consensus algorithm, or slightly changes the open source code implementation. To adapt to the underlying system, such implementations are pure soft implementations of the Raft consensus algorithm, which can tolerate node failures in the consensus cluster. However, the open source code of the Raft consensus algorithm generally runs in the rich execution environment (REE) of the node device. Once a node device with a Byzantine error occurs in the consensus cluster, the node device with a Byzantine error can initiate an attack on the blockchain system. Arbitrary attacks may cause the consensus cluster to fail to work properly. Among them, Byzantine errors include but are not limited to being elected as the leader node by tampering with timestamps, tenure, voting results, etc., or tampering with the content of messages transmitted in the blockchain system. This kind of leader node may maliciously modify the block. The index of the content or the log will cause a consensus error in the consensus cluster, resulting in the failure of the consensus cluster to work normally.

For example, if the follower node maliciously tampers with the timestamp, before the actual election time comes, an election is initiated in advance so that it can become the leader node. For another example, when initiating an election, the candidate node tampers with its own tenure 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 vote for a candidate node, if the candidate node tampers with the number of votes, such as increasing the number of votes, it becomes the leader node in the consensus cluster. For another example, the leader node tampers with the time stamp of sending the heartbeat message. If the time stamp of the heartbeat message is modified to be smaller, the leader node will send the heartbeat message in the consensus cluster in advance, which may lead to a denial of service (Dos) attack. If the time stamp of the heartbeat message is changed to a larger value, the leader node will not send heartbeat messages in the consensus cluster for a long time, that is, deliberately not sending heartbeat messages, causing the election time of the following nodes to time out and re-initiating the election.

For the convenience of expression, the node device with Byzantine error is recorded as Byzantine node. And in order to avoid Byzantine errors in the consensus cluster (such as being elected as the leader by tampering with the term of office, or arbitrarily tampering with the log), that is, in order to avoid Byzantine nodes in the consensus cluster, the embodiment of this application proposes a node device in a trusted execution environment. (Trusted Execution Environment, TEE) is a technical solution for implementing the Raft consensus algorithm. For example, the computer program (or program code) used to implement the Raft consensus algorithm is stored in the TEE, and the consensus node device runs the computer program used to implement the Raft consensus algorithm in the TEE, so that the consensus node device implements the algorithm of the Raft consensus algorithm process.

Among them, the TEE defines a security area on the main processor of the computing device, which can guarantee the security, confidentiality and integrity of the codes and data loaded into the TEE. The execution space provided by TEE has a higher level of security than that provided by common mobile operating systems (such as Linux, Android, etc.). The implementation of TEE includes the trust zone (TrustZone) based on advanced risc machines (ARM), the instruction set extensions (software guard extensions, SGX) introduced by Intel (Intel), etc.

TEE is protected by hardware mechanism, which provides the isolation of protected memory and execution environment, so as to provide reliable security and privacy guarantee. TEE can only crash without Byzantine errors. Therefore, the consensus node device implements the Raft consensus algorithm in TEE, which can avoid Byzantine errors in the node device, thereby avoiding Byzantine errors in the blockchain system.

In the Raft consensus algorithm, each consensus node device performs consensus through log replication, and each consensus node device stores the log sequence and the blockchain ledger of the blockchain system. The log sequence and the blockchain ledger need to occupy a certain amount of storage. space. Especially after the blockchain system has been running for a long time, there will be more and more logs in the blockchain system and blocks on the blockchain ledger. However, the TEE is an area on the main processor, and its storage resources are limited. The storage space inside the TEE may not be able to withstand more and more logs and blocks. Based on this, this application proposes fine-grained module splitting of the algorithm implementation of the Raft consensus algorithm (such as the computer program used to realize the Raft consensus algorithm), and realizes the core process of the Raft consensus algorithm (such as the computer program for implementing the election mechanism and The computer program that implements the log replication mechanism) is placed in the TEE for protection, and the input and output (IO) layer of the Raft consensus algorithm is performed on the REE side, which not only ensures the security of the Raft consensus algorithm, but also minimizes the dependence on the TEE to ensure algorithm efficiency and performance.

For example, FIG. 3 shows a schematic diagram of a consensus cluster implementing the Raft consensus algorithm based on TEE provided by the embodiment of the present application, see FIG. 3 . The consensus cluster shown in FIG. 3 includes consensus node devices 1-3, wherein consensus node device 1 is a leader node, and consensus node devices 1 and 2 are follower nodes. Each consensus node device among consensus node devices 1-3 includes REE and TEE, and REE is used to realize the IO process of messages. For example, the REE of the consensus node device is responsible for forwarding messages from the TEE of this node to other consensus node devices, or forwarding messages from other consensus node devices to the TEE of this node, and the blockchain ledger of the blockchain system And a snapshot (snapshot) of the log sequence can be stored in the REE. TEE is used to implement the core process of the Raft consensus algorithm, such as the consensus process (that is, the log replication process) and the election process.

In order to further illustrate the core process of the TEE implementing the Raft consensus algorithm and the IO process of the REE implementing the message, refer to the schematic diagram of a consensus node device based on the TEE implementing the Raft consensus algorithm provided by the embodiment of the application shown in Figure 4, as shown in Figure 4 The execution environment of each consensus node device in the consensus cluster includes TEE and REE. Each consensus node device implements the core logic of the Raft consensus algorithm in the TEE, which includes legal verification logic, timeout detection logic, log sequence maintenance logic, election logic, and consensus cluster configuration logic And the state maintenance logic of the consensus cluster. Among them, the legal verification logic is used to verify whether the content of the message transmitted by other consensus node devices is legal, and whether the identity certificate (such as a digital signature) of other consensus node devices is legal. The timeout detection logic uses the principle of a timer to detect whether the latest election time is reached or timed out, and if the latest election time is reached or timed out, an election is initiated. Log sequence maintenance logic is used to maintain log sequences. The configuration logic of the consensus cluster is used to maintain the node information of each consensus node device in the consensus cluster, such as the public key and address information of each consensus node device. Election logic is used to start the election process or vote for candidate nodes. The state maintenance logic of the consensus cluster is used to maintain the node state (or role) of each consensus node device in the consensus cluster in real time. For example, a node tracker is used to maintain the node status of each consensus node device in the blockchain system in real time.

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

For example, in Fig. 4, the client (client) sends (transmit, TX) the fifth request to the consensus node device as the leader (that is, the leader node), wherein the fifth request is used to indicate that in at least two blockchains Transactions between accounts. The proposal module in the leader node generates a block based on the fifth request, transfers the block to the module through a message, sends the block to the memory in the storage module, and sends the identification of the block to the TEE. Afterwards, TEE generates a log of the block based on the identification of the block, stores the log in the log sequence, and sends the log to the proposal module through the message scheduling module, and the proposal module obtains the block corresponding to the log from the memory, and Send the log and the block to the non-leader node in the consensus cluster through the message scheduling module and the communication module, and the communication module in the non-leader node receives the log and the block, and sends the log and the block to the message scheduling module block, the message scheduling module stores the block in the storage module, and sends the log to the TEE of the non-leader node, and the TEE decides whether to accept the log.

For further explanation, the process of the consensus node device in the blockchain system electing the leader node based on the TEE, please refer to the flowchart of a leader node election method provided by the embodiment of the present application shown in FIG. 5 .

501. At startup, the TEE of the first node device initializes the node information of each consensus node device in the consensus cluster, the node status of the first node device, the election time of the first node device, and the initial tenure of the first node device.

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

The node state of each consensus node device in the consensus cluster includes follower state, candidate state or leader state, wherein the follower state is used to indicate that the consensus node device is a follower node, the candidate state is used to indicate that the consensus node device is a candidate node, and the leader state It is used to indicate that the consensus node device is the leader node. At startup, the node state of the first node device is a follower state, and the election time of the first node device is the time when the election of the first node device becomes the leader node in the blockchain system (or consensus cluster). The initial term of the first node device is the initial term of the first node device, and the initial term may be 0 or any integer greater than 0.

In a possible implementation manner, the REE in the first node device triggers the TEE to execute step 501 . For example, the process shown in the following steps 5011-5013.

Step 5011, when the node starts, the REE in the first node device generates a sixth request, and the sixth request instructs the TEE to initialize the node information of each consensus node device in the consensus cluster, the node status of the first node device, the first node The election time of the device and the initial term of the first node device.

Wherein, the sixth request carries node information of each consensus node device in the consensus cluster.

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

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

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 invokes 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 located in the message scheduling module of the REE, and the message scheduling module sends 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 based on the sixth request, initializes the node information of each consensus node device in the consensus cluster, the node status of the first node device, and the election time of the first node device and the initial tenure of the first node device.

In a possible implementation manner, 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 out the node information of each consensus node device in the consensus cluster from the sixth request, and stores the information in the consensus cluster based on the instruction of the sixth request. Node information of each consensus node device, complete node information configuration.

The TEE of the first node device initializes the node state of the first node device based on the indication of the sixth request, for example, the TEE of the first node device stores the node state of the first node device as a follow state.

In a possible implementation manner, the TEE of the first node device obtains the node identifier of each consensus node device in the consensus cluster from the node information of each consensus node device in the consensus cluster. The TEE of the first node device creates a state table based on the node identifier of the consensus node device. Wherein, the state table is used to record the corresponding relationship between the node status of each consensus node device in the consensus cluster and the node identifier of each consensus node device. For example, the first node device may associate and store the node identifier of the first node device and the identifier of the following state in the state table, so as 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 status of other consensus node devices in the consensus cluster, so the first node device can record the node status of other consensus node devices in the status table as following state.

Based on the indication of the sixth request, the TEE of the first node device generates the election time of the first node device according to the first preset rule, and records the election time. Wherein, the first preset rule may be a random generation rule, or other preset rules. Here, the embodiment of the present application does not limit the first preset rule.

Based on the indication of the sixth request, the TEE of the first node device generates and records the initial term of the first node device, for example, takes 0 as the initial term of the first node device.

In a possible implementation manner, 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 each consensus node device in the blockchain system can initialize the node information, respective node status, respective election time and respective initial term of office. And each consensus node device only needs to execute this step 501 once when it is started, and there is no need to execute it repeatedly.

502. The TEE of the first node device generates a second request, and the second request indicates to vote for the first node device to become the leader node in the blockchain system.

Wherein, the second request includes the first term of the first node device, wherein the first term is the term corresponding to the current election process initiated by the first node device.

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

Since one 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 period, and the first node device recorded in the TEE of the first node device The election time has reached or expired, then the TEE of the first node device generates the second request. Wherein, the election time has arrived means that the current time is the election time recorded in the TEE, and the election time has expired means that the current time is later than the election time recorded in the TEE.

In the case that the TEE cannot call the REE, and the REE can call the TEE (for example, in the ARM-based TrustZone technology, the REE calls the TEE, and the TEE cannot call the REE), the TEE of the first node device generates the action of the second request, It is triggered by 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 has reached or expired, the REE of the first node device generates a first message, and the first message is used to prompt the TEE to start the first node device. The election process of a node device.

Wherein, the election process of the first node device refers to the process of electing the first node device to become the leading node in the blockchain 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. If the election time has arrived or has timed out, and no notification message is received from the leader node in the consensus cluster within the preset time period, the REE of the first node device 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, the proposal module in the REE of the first node device generates the first message, and sends the first message to the TEE of the first node device through the message scheduling module.

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 the 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 expired, the TEE of the first node device passes the verification of the first message.

If the election time recorded in the TEE of the first node device has not been reached, it means that the first node device has tampered with the election time of the first node device in the REE, and a Byzantine error occurs. Therefore, if the election time recorded by the TEE of the first node device has not arrived, the TEE of the first node device fails to verify the first message. If the TEE of the first node device fails to verify the first message, the subsequent steps are not performed.

Step 5024, if the first message is verified by the TEE of the first node device, the TEE of the first node device generates the second request.

In the case that the first message has passed the verification of the TEE of the first node device, the TEE of the first node device will increase the recorded term of the first node device by a first preset value to obtain the The first term. The first preset value is the difference between adjacent tenures, and the first preset value may be 1 or other values. The first preset value may be set according to an actual application scenario. Here, the embodiment of the present application does not limit the first preset value.

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

In another possible implementation, in order to prevent the content carried in the second request from being tampered with after the second request leaves the TEE of the first node device, the TEE of the first node device is based on the private key to sign the second request to obtain the 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, such as tampering with the timer in the REE, so that the time recorded by the timer reaches the election time in advance, the REE is triggered to send the first message to the TEE. However, since the TEE of the first node device further verifies whether the recorded election time has reached or expired, if the first message does not pass the verification of the TEE of the first node device, the TEE of the first node device will not generate the second message. request, thereby preventing the first node device from initiating an election in advance in the consensus cluster.

It should be noted that, after the TEE of the first node device generates the second request, and the TEE of the first node device wants to initiate an election, the TEE of the first node device will record the node state of the first node device by Following the update of the 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 the second node device in the blockchain system through the first node device REE.

Wherein, the second node device in the blockchain system is each consensus node device in the consensus cluster except the first node device, and there may be at least one second node device in the blockchain system.

In a possible implementation manner, this step 503 is performed by the following steps 5031-5032.

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

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

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 a possible implementation manner, the REE of the second node device receives the second request and the 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 second request and the digital signature of the second request are sent by the communication module 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.

Wherein, the second node device in steps 504-506 is any second node device in the blockchain system, that is, each second node device in the blockchain system executes steps 504-506 the process of.

In a possible implementation manner, this step 504 is implemented by the following steps 5041-5043.

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

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

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

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

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

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

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

In a possible implementation manner, the TEE of the second node device queries the public key of the first node device from 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 pass. If the signature verification fails, it means that the content of the second request has been tampered with, and the TEE of the second node device fails to verify the second request.

506. When the second request passes the 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, and the The second response indicates whether the second node device agrees with the first node device to become the leader node in the blockchain system.

Wherein, the second response carries a first voting ID or a second voting ID, the first voting ID indicates that the second node device agrees that the first node device becomes the leader node in the blockchain system, and the first voting ID That is a yes vote. The second voting identifier indicates that the second node device does not agree with the first node device becoming the leading node in the blockchain system, and the second voting identifier is also a negative vote.

Each consensus node device in the consensus cluster has the right to vote once when electing a leader node. And in each election, each consensus node device votes for a candidate node whose tenure is higher than its own, or votes for itself.

In a possible implementation, when the second request passes the verification of the TEE of the second node device, the TEE of the second node device parses out the first node device from the second request of the first term. The TEE of the second node device generates the second response based on recording the term of the second node device and the first term.

For example, if the first term is greater than the term of the second node device, and the second node device has not voted for candidate nodes other than the first node device, then the TEE generated by the second node device carries the A second response with a voting ID; otherwise, the TEE of the second node device generates a second response carrying the second voting ID.

Further, in order to prevent the content of the second response from being tampered with after the second response leaves the TEE of the second node device, the TEE of the second node device is based on the private key of the second node device, and the second The response is signed to obtain a digital signature of the second response.

In a possible implementation manner, the TEE of the second node device sends the second response to the first node device through the REE of the second node device, or sends the second response and the number of the second response Signature, such as the process shown in the following steps 5061-5062.

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

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

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

In a possible implementation manner, 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, and sends the second response and the digital signature of the second response to the communication module in the REE, And the communication module sends the second response and the digital signature of the second response to the first node device.

It should be noted that, if the second request passes the verification of the TEE of the second node device, it means that the first node device is in the candidate state, then the TEE of the second node device will record the first node The node state of the device is updated from follow state to candidate state.

507. The TEE of the first node device receives multiple second responses through the REE of the first node device.

Wherein, each of the multiple second responses is from a second node device in the consensus cluster.

In a possible implementation manner, the TEE of the first node device receives each second response and the digital signature of each second response in the multiple responses through the REE of the first node device. The process shown in this 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 the above step 504, and this embodiment of the present application does not repeat this step 507 here.

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

Taking the TEE of the first node device to verify the second response of a second node device as an example, this step 508 is introduced as follows:

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. If the signature verification is successful, the TEE of the first node device passes the verification of the second response. If the signature verification fails, it means that the content of the second response has been tampered with, and the first node device TEE fails to verify the second response.

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

In a possible implementation, when half or most of the second response of the second node device in the blockchain system passes the verification of the TEE, the TEE of the first node device will The second response is parsed to obtain the voting identifier carried in the second response.

The TEE statistical verification of the first node device is the total number of the first voting identifier in the second response, where the total number is the number of votes for the first node device to become the leader node in the consensus cluster. The total number of two-node devices. The TEE of the first node device judges whether the total number is greater than a first threshold, where the first threshold is half the number of second node devices in the consensus cluster. Because the first node device agrees that the first node device becomes the leader node in the blockchain system, it is also the first node device that votes for the first node device. If the total number of statistics is greater than or equal to the first threshold, and considering that the first node agrees that the first node device becomes the leader node, it means that most of the consensus node devices in the consensus cluster agree that the first node device becomes the blockchain The leader node in the system, the TEE of the first node device switches the node status of the first node device from the candidate status to the leader status.

For example, the TEE of the first node device updates the identification of the following state of the first node device recorded in the state table to the identification 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, and the notification message indicates that the first node device is a leader node in the blockchain system.

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

In a possible implementation manner, the TEE of the first node device generates the notification message based on the first term.

In a possible implementation manner, the action of the TEE of the first node device to generate the notification message is triggered by the REE of the first node device, for example, the process shown in the following steps 5101-5103.

Step 5101: If the target duration of the record in the REE of the first node device has been reached or has timed out, the REE of the first node device generates a second message, which is used to prompt the TEE to send data to the blockchain system The second node device sends a notification message.

Among them, the target duration is the duration for the leader node to periodically send notification messages in the consensus cluster, that is, the leader node sends a notification message in the consensus cluster every time a target duration passes to inform each consensus node device leader in the consensus cluster the presence of nodes.

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. After receiving the notification from the TEE, the REE of the first node device starts the countdown, and if the target duration has been reached or expired, the REE of the first node device sends the second message to the TEE of the first node device.

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 expired, it means that the REE of the first node device has not tampered with the target duration, then the second The TEE of a node device passes the verification of the second message. If the target duration recorded in the TEE of the first node device has not been reached, it means that the REE of the first node device has tampered with the target duration and sent the second message in advance, then the TEE of the first node device will Message verification failed.

Step 5103, if the second message is verified by the TEE of the first node device, the TEE of the first node device generates the notification message.

For example, if 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 term.

In another possible implementation manner, in order to prevent the content of the notification message from being tampered with after the notification message leaves the TEE of the first node device, the TEE of the first node device is based on the private key of the first node device. The notification message is signed to obtain the 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 a possible implementation manner, 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.

Wherein, the process shown in this step 511 is the same as the process in which the TEE of the first node device sends the second request to the second node device in the blockchain system through the first node device REE in the above step 503, Here, step 511 is not described in detail 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 a possible implementation manner, 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.

Wherein, the second node device in steps 512-514 is any second node device in the block chain system, that is, each second node device in the block chain system executes steps 512-514 the process of.

The process shown in this step 512 is the same as the process of receiving the second request through the TEE of the second node device in the above step 504 through the REE of the second node device. repeat.

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

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

514. If 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 status of the first node device to the leader status.

For example, the TEE of the second node device modifies the identification of the following state corresponding to the first node device in the state table to the identification of the leader state. At this time, for the second node device, the leader in the blockchain system The node is a first node device. The TEE of the second node device can also update the node status identification of each consensus node device in the state table except the first node device to the identification of the following state, to indicate that in the consensus cluster other than the first node device Each consensus node device is a follower node.

In a possible implementation manner, when the notification message passes the verification of the TEE of the second node device, the TEE of the second node device parses out the one term. The TEE of the second node device updates the recorded term of the second node device to the first term, so that after the first node device becomes the leader node in the blockchain system, the Consensus node devices take the term of the leader node as their latest term.

In the method provided by the embodiment of the present application, the TEE of the node device in the blockchain system generates a second request, and sends the second request to other node devices in the blockchain system to initiate an election. Since the TEE does not have a Byzantine error, there will be no Byzantine error when the TEE generates the second request, thereby avoiding the malicious initiation of elections by participating node devices and reducing the Byzantine error in the blockchain system. In addition, after the REE of the node device triggers the TEE to initiate an election, the TEE will also verify whether the election time has actually arrived, so as to avoid the situation that the election time in the REE is maliciously tampered with and the election is initiated in advance. 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 together, and the digital signature based on the message is sent by the second node device, The message is verified, so as to prevent the content of the message from being tampered with after the message leaves the TEE of the first node device.

To further illustrate the process in FIG. 5 , refer to FIG. 6 , which is a schematic diagram of a leader node election process provided by an embodiment of the present application. When each consensus node device in the blockchain system is started, the REE of each consensus node device calls the initialization interface, triggering the TEE of each consensus node device to initialize consensus (initialize consensus, initconsensus) configuration (such as the above steps 5011- 5013), the TEE of each consensus node device will also send the election time to the REE of the consensus node device, so that the REE starts the countdown. When the election time of the first follower node in the blockchain system (that is, the follower node with the closest initial election time) arrives, the REE of the follower node invokes the timeout interface to prompt the TEE of the follower node to initiate an election. The TEE of the following node further verifies whether the election time has actually arrived or expired, so as to ensure the correctness of the timeout mechanism. When the election time is actually reached or timed out, the follower node becomes a candidate node. The TEE of the candidate node increases the term of the candidate node, and generates a second request according to the increased term. The TEE of the candidate node sends the second request to the REE of the candidate node through an output (output) interface. The REE of the candidate node receives and sends the second request to non-leader nodes in the consensus cluster except the candidate node. The REE of the non-leader node receives the second request, and sends the second request to the TEE of the non-leader node by calling an input (input) interface. The TEE of the non-leader node determines whether to vote for the candidate node according to its term of office, and the TEE of the non-leader node sends a second response to the REE of the non-leader node through the output interface. The REE of the non-leader node receives and sends the second response to the candidate node. The REE of the candidate node receives the second response sent by the non-leader node device, and sends the received second response to the TEE of the candidate node through an input interface. The TEE of the candidate node is counted as the number of non-leader nodes that voted for the candidate node in the consensus cluster based on receiving each second response. If the majority of non-leader nodes in the consensus cluster voted for the candidate node, the candidate node Become a leader node in the blockchain system. The REE of the leader node checks whether the heartbeat duration (such as the target duration) has arrived, and if it arrives, it prompts the TEE of the leader node to generate heartbeat information (such as a notification message). After receiving the prompt from REE, the TEE of the leader node first verifies whether the heartbeat duration has really arrived. If it does arrive, the TEE of the leader node generates a heartbeat message and sends a heartbeat message to the REE of the leader node through the output interface. The REE of the leader node receives and sends this heartbeat message to the non-leader nodes in the consensus cluster. After the REE of the non-leadership node receives the heartbeat message, it sends the heartbeat message to the TEE of the non-leadership node by calling the input interface. When the TEE of the non-leadership node receives the heartbeat message, it indicates that a leader has been generated in the blockchain system. node, the non-leader node becomes a follower node, and the TEE of the non-leader node records the information of the leader node.

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

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

Wherein, the fifth request indicates to perform transactions between at least two blockchain accounts. The terminal is user equipment other than the first node device, or the first node device.

A client is installed in the terminal, and the user issues a transaction instruction to the client to conduct transactions between at least two blockchain accounts. After receiving the transaction instruction, the client generates the fifth transaction instruction based on the transaction instruction. ask. If the first node device is the terminal, the first node device obtains 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, correspondingly, the REE of the first node device The fifth request is received. Or, the terminal sends the fifth request to any second node device in the blockchain system, and when the REE of the second node device receives the fifth request of the terminal, it sends the fifth request to the TEE of the second node device The fifth request. 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 caches the block.

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

In a possible implementation manner, the REE of the first node device conducts transactions 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 body, or packages the transaction event and at least one transaction event in the event pool into a block body, wherein the event pool includes multiple transaction events to be packaged . The REE of the first node device adds a block header to the block body based on each transaction event in the block body to obtain the block. Wherein, the block header includes the hash value of the block and the 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 body, and the block number of the block It is 1 larger than the block number of the last block on the blockchain ledger of the local blockchain system. Wherein, the block number of any block on the blockchain ledger indicates the position of any block on the blockchain ledger, and the block number of any block may also be referred to as the block height of any block.

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

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

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

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

In a possible implementation manner, the REE of the first node device generates a third message, and the third message instructs the consensus cluster to perform consensus on the block. 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, step 703 is performed by the 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, and sends the first The message scheduling module in the REE of the node device sends the third message, and the message scheduling module sends the third message to the TEE of the first node device.

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

Wherein, the log includes the identifier of the block, but does not include the block, and refers to the block with the identifier of the block, but the log does not include the block. For example, the identification of the block includes at least one of the hash value of the block and the block number of the block. Of course, the identification of the log can also be the hash value of the block or the block number There are other representation methods other than the number, and this application does not limit the logo of the log.

In a possible implementation manner, the log further includes at least one of an index of the log and a tenure of the first node device.

In a possible implementation, the TEE of the first node device receives the third message, and the TEE of the first node device parses out the identity of the block from the third message, and based on the identity of the block , to generate the log.

For example, the log sequence of the first node device is stored in the TEE of the first node device, and the TEE of the first node device generates a target index based on the index of the last log in the log sequence, and the TEE of the first node device The log is generated based on the target index and the identity of the block. The TEE of the first node device adds the log in the log sequence.

Wherein, the target index is the index of the log, and the target index is greater than the index of the last log in the log sequence by a second preset value. The second preset value is the difference between the indexes of two adjacent logs in the log sequence. The second preset value can be 1 or other values. The second preset value can be set according to the actual application scenario. Therefore, the embodiment of the present application does not limit the second preset value.

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

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 is based on a block in the REE of the first node device, and generating the log of the block includes: sending the REE of the first node device to the block of the first node device The TEE sends a third message, which includes the block. The TEE of the first node device obtains the identifier of the block from the block carried in the third message, and generates a log of the block based on the identifier of the block. After the log is generated, the TEE of the first node device discards the block.

Compared with the third message including the block, the data amount of the third message including the identification of the block is much smaller, for example, the data amount comparison diagram of a different third message provided by the embodiment of the present application shown in FIG. 8 , the data volume of the third message including the block in FIG. 8 can reach 2M, and the data volume of the third message including the identification of the block is 200 bytes (bytes). Therefore, the REE sends the block identifier to the TEE, which can reduce the amount of data exchanged between the TEE and the REE.

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

In a possible implementation, the TEE of the first node device generates a first target message based on the log, the first target message carries the log, and the first target message indicates that the second node in the blockchain system The device processes the log and the block corresponding to the log, and the TEE of the first node device sends the first target message to the REE of the first node device.

In another possible implementation manner, in order to prevent the content of the first target message from being tampered with after the first target message leaves the TEE of the first node device, the TEE of the first node device is based on the The private key of the device signs the first target message to obtain the digital signature of the first target message. Correspondingly, the TEE of the first node device sends the first target message and the digital signature of the first target message to the REE of the first node device.

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

In a possible implementation manner, the REE of the first node device receives the first target message, and based on the log carried by the first target message, queries the block indicated by the block identifier in the log in the memory . The REE of the first node device generates the first request based on the queried block and the first target message. At this time, the first request carries the block and the first target message. At this time, the first request Indicates processing of the block and the log for that block.

If the REE of the first node device also receives the digital signature of the first target message, then the REE of the first node device is based on the queried block, the first target message, and the digital signature of the first target message, generating the first request, at this time, 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 that the log of the block and the block should be deal with.

After the REE of the first node device generates the first request, it sends the first request to the second node device in the blockchain system.

In order to further reflect the difference between the first request and the log copy request, see FIG. 9 , which is a schematic diagram showing a comparison between a first request provided by an embodiment of the present application and a log copy request in the related art. As shown in FIG. 9 , the log copy request carries the log of the block, and the log in the log copy request includes the index of the log and the block, and the log in the log copy request is a log in the related art. However, what the first request carries is a block and a log of the block, and the log in the first request includes the identification of the block and the index of the log, but does not include the block.

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

Wherein, the second node device in steps 707-712 is any second node device in the blockchain system, that is, each second node device in the blockchain system executes steps 707-712 the process of.

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 in the first request to 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 a 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, the TEE of the second node device receives the first request sent by the REE of the second node device, and parses out the first target message from the first request, or parses out the first target message and the digital signature of the first target message.

A manner in which the TEE of the second node device verifies the log includes any of the following manners 1 or 2.

Mode 1. The log sequence of the second node device is stored in the TEE 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 higher than the index of the last log in the log sequence If the index of is greater than the second preset value, then the TEE of the second node device passes the verification of the log, otherwise the verification of the log fails.

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 pair public key of the first node device.

If the first target message and the digital signature of the first target message are parsed from the first request, the TEE of the second node device verifies the signature of the first target message based on the public key of the first node device . If the signature verification is successful, the TEE of the second node device passes the verification of the first target message. If the signature verification fails, it means that the content of the first target message has been tampered with, and the TEE of the second node device fails to verify the first target message.

In the case that the TEE of the second node device passes the verification of the first target message, the TEE of the second node device obtains the log from the target message, if the index of the log is greater than the last log in the log sequence If the index of is greater than the second preset value, then the TEE of the second node device passes the verification of the log, otherwise the verification of the log fails. 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 that of the second node device TEE record leader in the blockchain system If the tenure of the nodes is the same, the TEE of the second node device passes the verification of the log; otherwise, the verification of the log fails.

711. If the log passes the verification of the TEE of the second node device, the TEE of the second node device stores the log.

If the TEE of the second node device passes the verification of the log, the TEE of the second node device adds the log to the log sequence of the second node device, and at this time, the log is the last log in the log sequence.

In a possible implementation, when the log has passed the verification of the TEE of the second node device, the TEE of the second node device records the status of the log as uncommitted to indicate that the log corresponds to The blocks of have not yet been submitted to the blockchain ledger of the local blockchain system.

If the log does not pass the verification of the TEE of the second node device, the second node device does not perform step 711 .

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

Wherein, the first response includes a first target identifier or a second target identifier, the first target identifier indicates that the second node device has agreed to receive the log, and the second target identifier indicates that the second node device does not agree to receive the log.

In a possible implementation, when 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, and the first response Indicates that the second node device has agreed to receive the log. In the case 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 the second target identifier, and at this time, the first response indicates that the second node device does not agree to receive the log.

Further, in order to prevent the content of the first response from being tampered with, the TEE of the second node device signs the first response based on the private key of the second node device to obtain a digital signature of the first response. Correspondingly, 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 that the TEE of the second node device sends the first response to the first node device through the REE of the second node device is the same as that in step 506, the TEE of the second node device sends the first response to the first node device through the REE of the second node device The process of sending the second response by a node device is the same. Here, the embodiment of the present application uses the TEE of the second node device to send the first response to the first node device through the REE of the second node device. .

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

Wherein, each of the multiple first responses is from a second node device in the consensus cluster. In a possible implementation manner, the TEE of the first node device receives multiple first responses and a digital signature of each first response through the REE of the first node device.

The process for the TEE of the first node device to receive multiple first responses through the REE of the first node device is the same as the process for the TEE of the first node device to receive multiple second responses through the REE of the first node device in step 507 Here, step 713 is not described in detail in this embodiment of the present application.

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

Taking the TEE of the first node device verifying the first response of a second node device as an example, this step 714 is introduced as follows:

The TEE of the first node device verifies the digital signature of the first response of the second node device based on the public key of the second node device. If the signature verification is successful, the TEE of the first node device passes the verification of the first response. If the signature verification fails, it means that the content of the first response has been tampered with, and the TEE of the first node device fails to verify the first response.

715. In the blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE of the first node device, and each first response that has passed the verification indicates that a second node device has agreed to receive the TEE In the case of a 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 identification of the block in the log.

Wherein, the block ledger of the local blockchain system of the first node device is stored in the REE of the first node device.

In a possible implementation, when half or most of the first responses of the second node devices in the blockchain system pass the verification of the TEE of the first node device, the TEE of the first node device The first response of the second node device is parsed to obtain the target identifier (such as the first target identifier or the second target identifier) carried in the first response. The total number of first target identifiers in the first response whose TEE statistical verification of the node device in the first section passes, wherein, the total number is also the number of second node devices in the consensus cluster that agree to receive the log. The first node device TEE judges whether the total number is greater than a first threshold. Since the TEE of the first node device has added the log to the log sequence of the first node device, the first node device has agreed to receive the log. Then if the total number is greater than or equal to the first threshold, and considering that the first node device has agreed to receive the log, it means that most of the consensus node devices in the consensus cluster have agreed to receive the log, that is, the consensus cluster has agreed to receive the log. Passed, that is, the consensus cluster passed the consensus of the block corresponding to the log. Then, based on the identification of the block in 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.

For example, the TEE of the first node device generates a fourth message based on the identifier of the block in the log, the fourth message carries the identifier of the block, and the fourth message instructs the REE of the first node device to take the block The blockchain ledger submitted to the local blockchain system. The TEE of the first node device sends the fourth message to the REE of the first node device. Afterwards, the REE of the first node device receives the fourth message, and based on the identification of the block carried in the fourth message, queries the block cached in the memory, and stores the queried block in the persistent storage medium On the blockchain ledger of the blockchain system.

Afterwards, the TEE of the first node device updates the recorded state of the log to the submitted state, to indicate that the block corresponding to the log has been submitted to the ledger on the block chain of the block chain 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 the second node device in the blockchain system through the REE of the first node device, and the third request instructs the second node device to submit the block To the blockchain ledger of the local blockchain system.

Wherein, the third request may be a heartbeat message or other types of messages except the 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, where the third request carries the index of the log. Optionally, the third request also carries the first term of the first node device.

In another possible implementation, in order to prevent the content of the third request from being tampered with after the third request leaves the TEE of the first node device, the TEE of the first node device is based on the first node device's private key to sign the third request to obtain the digital signature of the third request. Correspondingly, the TEE of the first node device sends the third request and the digital signature of the third request to the second node device in the blockchain system through the REE of the first node device.

Wherein, the TEE of the first node device sends the third request to the second node device in the blockchain system through the REE of the first node device, which is the same as the process of sending the third request to the second node device in the block chain system through the TEE of the first node device in step 503 above. A node device REE, the process of sending the second request to the second node device in the blockchain system is the same. Here, in this embodiment of the application, the TEE of the first node device is passed through the REE , the process of sending the third request to the second node device in the blockchain system will not be repeated here.

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

Wherein, the second node device in steps 717-719 is any second node device in the blockchain system, that is, each second node device in the blockchain system executes steps 717-719 the process of.

In a possible implementation manner, 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 described in this step 717 is the same as the process of receiving the second request through the TEE of the second node device in the above step 504 through the REE of the second node device. Here, this embodiment of the present application will not repeat this step 717. .

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

In a possible implementation manner, the TEE of the second node device verifies the digital signature of the third request based on the public key of the first node device. If the signature verification is successful, the TEE of the second node device passes the verification of the third request. If the signature verification fails, it means that the content of the third request has been tampered with, and the TEE of the second node device fails to 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 based on the identification of the block in the log The block is submitted to the blockchain ledger of the local blockchain system.

Wherein, the TEE of the second node device notifies the REE of the second node device to submit the block to the blockchain ledger of the local blockchain system based on the identification of the block in the log and step 715 Based on the identification of the block in the log, the TEE of the first node device notifies the REE of the first node device to submit the block to the blockchain account book of the local blockchain system. Here, step 719 is not described in detail in this embodiment of the present application.

In a possible implementation manner, when the third request passes the verification of the TEE of the second node device, the TEE of the second node device parses out the index of the log from the third request. Based on the index of the log, the TEE of the second node device updates the recorded state of the log to the submitted state, to indicate that the block corresponding to the log has been submitted to the ledger on the block chain in the block chain system.

It should be noted that the process shown in Figure 7 is illustrated by taking the first request to carry the block and the log of the block as an example. In another possible implementation, the TEE of the first node device initiates the consensus cluster When the consensus node device in the log agrees on the log, it can not send the block first, and then send the block after the consensus on the log is completed. For example, the first request does not carry a block, but the third request carries a block. In this case, when the REE of the second node device in the blockchain system receives the third request, it first sends the third request The blocks in the block are transferred to the in-memory cache, and then the TEE of the second node device sends three requests. Therefore, when a small number of consensus node devices in the consensus cluster agree to receive the log, the TEE of the first node device does not need to send a third request to the second node device in the blockchain system, thereby preventing the first node device from failing the consensus. The block is sent to the second node device in the blockchain system.

In the method provided by the embodiment of this application, the log is generated by the TEE of the node device in the blockchain system, and the REE of the node device sends the log generated by the TEE to other node devices in the blockchain system, so that other node devices can compare the log Make a consensus. Since TEE is protected by hardware and will not do evil, it can achieve the purpose of using TEE to protect the consensus process and prevent Byzantine errors in the blockchain system. Moreover, the block is referred to by the block identifier in the log, and the log does not need to carry the block, thereby reducing the data volume of the log, and correspondingly reducing the storage space occupied by the log sequence. In addition, the first request also carries the digital signature of the log, so as to prevent the log from being tampered with and to avoid errors in the log consensus. 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 is based on the digital signature of the first response to the first response Verification is performed to prevent the content of the first response from being tampered with and to avoid log consensus errors.

In order to further illustrate the process shown in FIG. 7 , refer to the schematic diagram of a block consensus process provided by the embodiment of the present application shown in FIG. 10 . The proposal module transaction request (such as the fifth request) of the REE of the leader node generates a block, and sends the 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 block based on the identification of the block. The TEE of the leader node adds the log to the log sequence, generates the first request, and sends the first request through the output interface REE of the 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. The TEE of each non-leadership node verifies the log carried by the first request. If the log passes the verification, the log is added to the local log sequence, and if the verification fails, the log is not received. The TEE of each non-leader node generates a log addition result (such as the first response), and sends the log addition result to the respective REE through the output interface, and each non-leader node REE returns the log addition result to the leader node. The REE of the leader node sends each log addition result received to the TEE of the leader node by calling the input interface. When more than half of the consensus nodes have added the log, the TEE of the leader node will notify the consensus result of the log through the output interface (if more than half of the consensus nodes have added the log), the transaction is successful. Afterwards, the REE of the leader node will trigger the TEE of the leader node to initiate a heartbeat message (such as the third request) after verifying that the heartbeat duration (such as the target duration) has reached or expired. Afterwards, the TEE of the leader node first verifies whether the heartbeat duration has actually arrived or timed out. If it has actually arrived or timed out, the TEE of the leader node will generate a heartbeat message. At this time, the heartbeat message carries the index of the currently submitted log, and the TEE of the leader node passes the output The interface sends a heartbeat message to the REE of the leader node. The REE of the leader node sends the heartbeat message to each non-leader node in the consensus cluster. REEs of each non-leader node send received heartbeat messages to their respective TEEs by calling the input interface. After the TEE of each non-leader node receives the heartbeat message, it submits the log according to the index carried in the heartbeat message.

To further illustrate the process shown in FIG. 7 , refer to FIG. 11 , which is a schematic diagram of a block storage provided by an embodiment of the present application. The REE of the leader node packs transactions, generates blocks, and caches blocks. The REE of the leader node sends the identity of the block to the TEE of the leader node to instruct the TEE to agree on the identity of the block. The TEE of the leader node generates a log based on the identity of the block and signs the log. The leader node's TEE returns the log and the log's digital signature (sign) to the leader node's REE. The REE of the leader node obtains the block corresponding to the log from the cached block, and synchronizes the block and the log to the follower node. For example, the REE of the leader node sends the log, the digital signature of the log, and the block to each follower node. Each REE following the node caches the block and sends the log and the digital signature of the log to the respective TEE. The TEE of each following node verifies the log based on the digital signature of the log. If the verification is passed, the TEE of each following node receives the log, otherwise it does not receive the log. Each TEE that follows a node sends the log reception result (such as the target ID) and the digital signature of the log reception result to its respective REE. Each REE following the node sends its own log receiving result (such as the first response) and the digital signature of the log receiving result to the leader node. The REE of the leader node sends each received log reception result and the digital signature of each log reception result to the TEE of the leader node. The REE of the leader node verifies each log receiving result based on the digital signature of each log receiving result. If the log reception results of at least half of the consensus node devices in the consensus cluster pass the verification, and these half of the consensus node devices agree to receive the log, then 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 place the block corresponding to the log, and the transaction is successful at this time. Afterwards, the TEE of the leader node generates a heartbeat message (such as the third request), and signs the heartbeat message, and the TEE of the leader node sends the heartbeat message and the digital signature of the heartbeat message to the REE of the leader node. The REE of the leader node receives and sends the heartbeat message to each follower node in the consensus cluster. Each REE following the 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 its respective TEE. The TEE of each following node verifies the heartbeat message based on the digital signature of the heartbeat message. If the heartbeat message passes the verification, the TEE of each following node submits the log based on the index of the log carried in the heartbeat message. For example, each TEE that follows a node notifies its respective REE to place the block corresponding to the log on disk.

In order to further illustrate the process shown in FIG. 5 and FIG. 7 , refer to the schematic diagram of the data processing process in a consensus cluster provided by the embodiment of the present application shown in FIG. 12 . Taking the consensus cluster including follower nodes 1-3 as an example, the introduction to Figure 12 is as follows:

Following the TEE verification timestamp of node 3, if it is determined that the election time has reached or timed out, the master election will be timed out. For example, following node 3 is switched to be a candidate node, and the TEE of candidate node 3 sends voting requests (such as the second request) carrying digital signatures to following nodes 1 and 2 respectively. The TEEs following nodes 1 and 2 verify the voting requests based on the digital signatures carried in the voting requests. When the voting request is verified, the TEEs following nodes 1 and 2 vote for candidate node 3 respectively, and return respective voting results (such as the second response) and digital signatures of the voting results to candidate node 3 respectively. The TEE of candidate node 3 processes the voting results and becomes the 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. If at least one of the two voting results passes the verification, and the at least one voting result is an affirmative vote, then the candidate node 3 is switched to be the leader node. Afterwards, the TEE of the leader node 3 verifies the time stamp. If the heartbeat duration is reached or times out, the TEE of the leader node 3 sends a heartbeat message (such as a notification message) carrying a digital signature to the follower nodes 1 and 2 respectively. The TEEs following nodes 1 and 2 verify the heartbeat message based on the digital signature in the heartbeat message respectively. In the case that the heartbeat message is verified, the TEE following nodes 1 and 2 accepts candidate node 3 to become the leader node in the consensus cluster. After that, the client sends a transaction request (such as the fifth request) to the leader node 3, and the REE of the leader node 3 packages the transaction to generate a block. The TEE of the leader node 3 generates a log based on the identification 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 block to the follower nodes 1 and 2 respectively through the REE. REEs following nodes 1 and 2 cache blocks separately. The TEEs following nodes 1 and 2 verify the log based on the digital signature of the log respectively. In the case that the log is verified, the TEEs following nodes 1 and 2 receive the log respectively, such as adding the log to the log sequence. Follower nodes 1 and 2 respectively return their respective log receiving results (such as the first response) and digital signatures of the log receiving results to the leader node 3 . The TEE of the leader node 3 verifies each log receiving result based on the digital signature of each log receiving result. If at least one log reception result of following nodes 1 and 2 passes the verification, and at least one log reception result indicates that the log has been received, then the TEE of the leader node 3 submits the log, and puts the block corresponding to the log to the disk. At this time, the transaction Success, and notify the client of the transaction processing result. Afterwards, the TEE of the leader node 3 performs timestamp verification. If the heartbeat duration is reached or times out, the TEE of the leader node 3 sends a heartbeat message (such as the third request) and a digital signature of the heartbeat message to follower nodes 1 and 2 respectively. The TEEs following nodes 1 and 2 verify the heartbeat message based on the digital signature of the heartbeat message respectively. When the heartbeat message passes the verification, the TEEs following nodes 1 and 2 submit the log based on the index of the log carried in the heartbeat message, for example, the TEEs following nodes 1 and 2 notify their respective REEs to correspond to the log of blocks placed on the disk.

As the service duration of the consensus cluster increases, more and more logs are included in the log sequence of the consensus node device. In order to reduce the storage space occupied by the log sequence, the TEE of the consensus node device can compress the log sequence through a snapshot , to further illustrate this process, refer to the flowchart of a log compression method provided by the embodiment of the present application shown in FIG. 13 .

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

At this time, the first node device is the leader node in the consensus cluster. The log sequence is the log sequence of the first node device, and the log sequence is stored in the TEE of the first node device. The submitted log means that the block corresponding to the log has been submitted to the blockchain ledger of the local blockchain system, or the block corresponding to the log has been placed on the disk. The snapshot includes a first identifier and a second identifier, the first identifier is the identifier of the block corresponding to the start log in the multiple logs, and the second identifier is the block corresponding to the end log in the multiple logs logo. Wherein, the start log of the multiple logs is the first log of the multiple logs, and the end log of the multiple logs is the last log of the multiple logs.

In a possible implementation, 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 status of each log in the log sequence, and sets the status of each log in the log sequence to Multiple logs of commit status, multiple logs determined to be committed. Wherein, the number threshold may be set according to an actual implementation scenario, and this embodiment of the present application does not limit the number threshold.

After determining the submitted multiple logs in the log sequence, the TEE of the first node device generates the snapshot based on the first identifier of the start log in the multiple logs and the second identifier of the terminated log in the multiple logs , and delete multiple snapshots in that log sequence. Wherein, the snapshot includes the first identifier and the second identifier.

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

In a possible implementation, the TEE of the first node device generates a second target message based on the snapshot, the second target message carries the snapshot, and the second target message indicates that the second node in the blockchain system The device submits multiple blocks corresponding to the multiple logs to the local blockchain ledger based on the snapshot. The TEE of the first node device sends the second target message to the REE of the first node device.

In a possible implementation manner, in order to prevent the content of the second target message from being tampered with after the second target message leaves the TEE of the first node device, the TEE of the first node device is based on the private key to sign the second target message to obtain the digital signature of the second target message. Correspondingly, 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 other types of messages other than the heartbeat message. If the second target message is a heartbeat message, the TEE of the first node device verifies whether the target duration is reached, and if the target duration is reached, the TEE of the first node device generates the second target message.

1303. The REE of the first node device receives the snapshot, and based on the first identifier and the second identifier in the snapshot, obtains the corresponding logs from the blockchain ledger of the local blockchain system. multiple blocks.

In a possible implementation, the REE of the first node device receives the second target message, parses the snapshot from the second target message, and stores the snapshot on the blockchain account book of the local blockchain system , query the first block indicated by the first identifier in the snapshot and the second block indicated by the second identifier in the snapshot. The REE of the first node device obtains the first block, the second block, and each block between the first block and the second block from the blockchain ledger. Wherein, the first block, the second block, and each block between the first block and the second block are the multiple blocks corresponding to the multiple logs. The first block is the first block among the multiple blocks, and the second block is the last block among the multiple blocks.

1304. The REE of the first node device sends a fourth request to the second node device in the blockchain system, the fourth request carries the snapshot and the multiple blocks, and the fourth request indicates that in the blockchain system The second node device submits multiple blocks corresponding to the multiple logs to the local blockchain ledger based on the snapshot.

In a possible implementation manner, after obtaining the multiple blocks, the REE of the first node device generates the fourth request based on the second target message and the multiple blocks. At this time, the first The fourth request carries the second target message and the plurality of blocks.

In a possible implementation, if the digital signature of the second target message is received, the REE of the first node device is based on the second target message, the digital signature of the second target message, and the plurality of blocks, The fourth request is generated. At this time, the fourth request carries the second target message, the digital signature of the second target message, and the multiple blocks.

After generating the fourth request, 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.

Wherein, the second node device in steps 1305-1309 is any second node device in the blockchain system, that is, each second node device in the blockchain system executes steps 1305-1309 the process of.

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

For example, the REE of the second node device transfers the multiple blocks carried in the fourth request to 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 a possible implementation manner, the snapshot does not include the identification of the block, but includes the state data of each transaction event in the block, and the state data of each transaction event indicates the latest state of the data involved in each transaction event. However, the state data of each transaction event occupies a large number of bytes, so the data volume of this snapshot is relatively large. However, the snapshot in the embodiment of the present application includes the identifier of the block. If the identifier of the block is the block number, the first identifier and the second identifier are two integer values. Therefore, the snapshot in the embodiment of the present application The number of snapshots is small, and accordingly, the snapshot transfer rate is high.

For example, FIG. 14 is a schematic diagram of snapshot comparison provided by the embodiment of the present application. Referring to the related technology shown in the left figure in FIG. 14, the log sequence 1 includes logs 1-6, and the logs 1-6 include blocks 1-6 respectively, wherein, logs 1-4 are submitted logs, and logs 5-6 are still Not submitted, blocks 1-4 have been submitted to the blockchain ledger of the blockchain system. The leader node truncates the logs 1-4 in the log sequence 1 to generate a snapshot 1 of the log sequence 1, which includes the state data of each transaction event in the blocks 1-4.

The right figure of FIG. 14 is a schematic diagram of the embodiment of the present application. In the right diagram of Figure 14, log sequence 2 is stored in the TEE of the leader node. Log sequence 2 includes logs 1-6, wherein logs 1-4 are submitted logs, logs 5-6 have not yet been submitted, and blocks 1-4 have been submitted to the blockchain ledger of the blockchain system. The leader node uses the block hash value as the identification of the block, and refers to 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 the logs 1-4 in the log sequence 2 to generate a snapshot 2 of the log sequence 2, which includes the block number 1 of the start block and the block number of the end block in blocks 1-4. Block number 4. It can be seen that the content of the snapshot 2 is less than that of the snapshot 1, and the data volume of the snapshot 2 is smaller than the data volume of the snapshot 1. And, the TEE of the leader node sends the snapshot 2 to the REE of the leader node, and the REE of the leader node obtains the blocks 1-4 corresponding to the snapshot 2 in the local blockchain ledger, and sends the snapshot 2 to the non-leader nodes in the consensus cluster and blocks 1-4.

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

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

The TEE of the second node device verifies the digital signature of the second target message based on the public key of the first node device. Because the second target message carries a snapshot. If the signature verification is successful, the TEE of the second node device passes the verification of the snapshot. If the signature verification fails, it means that the content of the second target message has been tampered with, and the TEE of the second node device fails to pass the verification of the snapshot.

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

If the snapshot passes the verification of the TEE of the second node device, the TEE of the second node device parses the snapshot from the second target message, and obtains the first identifier and the second identifier from the snapshot . In the log sequence of the second node device, the TEE of the second node device queries the first log corresponding to the first identifier and the second log corresponding to the second identifier in the log sequence, and the second node device deletes the The first log, the second log, and each log between the first log and the second log in the log sequence. Wherein, the first log, the second log, and each log between the first log and the second log are multiple logs truncated by the first node device, and the first log is the starting point of the multiple logs. The start log, the second log is the termination log of the plurality of logs.

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

For example, the TEE of the second node device sends a seventh request to the REE of the second node device, the seventh request carries the snapshot, and the seventh request indicates that the REE of the second node device corresponds to a plurality of blocks The blockchain ledger submitted to the local blockchain system. When the REE of the second node device receives the seventh request, based on the snapshot carried by the seventh request, it queries the cached blocks for the multiple blocks corresponding to the snapshot, and sends the queried multiple blocks The blockchain ledger submitted to the local blockchain system. The REE of the second node device may also store the snapshot in a persistent storage medium.

In the method provided by the embodiment of the present application, a snapshot is generated through the TEE of the node device, and the snapshot carries the identification of the starting block and the identification of the ending block in the submitted multiple blocks, which reduces the data volume of the snapshot, and because the TEE It is protected by hardware and will not do evil. Therefore, it can achieve the purpose of using TEE to protect snapshot synchronization and prevent Byzantine errors in the blockchain system. Moreover, since the fourth request carries the second target message and the digital signature of the second target message, the content of the second target message is prevented from being tampered with, reducing the occurrence of Byzantine errors in the blockchain system.

The method of the embodiment of the present application is described above, and the device of the embodiment of the present application is introduced below. It should be understood that the apparatus described below has any function of any node device in the above methods.

Figure 15 The embodiment of this application provides a schematic structural diagram of a data processing device, see Figure 15, the device 1500 is configured as a first node device in a blockchain system, and the first node device includes a trusted execution environment TEE and Rich Execution Environment REE, 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 the block based on the block in the REE, and send the log to the REE, and the block identifier in the log refers to the area piece;

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

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

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 blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , based on the identification of the block in the log, notify the REE to submit the block to the local blockchain ledger of the blockchain system.

Optionally, the processing unit 1501 is further configured to:

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

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

In the blockchain system, half or most of the second responses of the second node devices have passed the verification of the TEE, and each of the verified second responses indicates that a second node device agrees with the first node When the device becomes the leader node in the blockchain system, the node status of the first node device is switched to the leader status.

Optionally, the processing unit 1501 is further configured to:

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

Sending the notification message to the second node device in the blockchain system through the REE.

Optionally, the processing unit 1501 is further configured to:

In the blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , send a third request to the second node device in the blockchain system through the REE, and the third request instructs the second node device to submit the block to the local zone The blockchain ledger of the blockchain system.

Optionally, the processing unit 1501 is further configured to truncate multiple logs submitted in the log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot including the first identifier And the second identification, wherein the first identification is the identification of the block corresponding to the start log in the plurality of logs, and the second identification is the identification of the block corresponding to the termination log in the plurality of logs logo;

The communication unit 1502 is further configured to receive the snapshot, and based on the first identifier and the second identifier in the snapshot, obtain the local blockchain ledger of the blockchain system. Multiple blocks corresponding to multiple logs, sending a fourth request to the second node device in the blockchain system, the fourth request carrying the snapshot and the multiple blocks, the fourth The 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 above method embodiment, and each module in the apparatus 1500 and other operations and/or functions mentioned above are respectively to realize various steps and functions implemented by the first node device in the method embodiment. For the method, specific details may refer to the foregoing method embodiments, and for the sake of brevity, details are not repeated here.

It should be understood that when the device 1500 determines the data to be processed, it only uses the division of the above-mentioned functional modules as an example for illustration. Different functional modules to complete all or part of the functions described above. In addition, the device 1500 provided in the above embodiment is based on the same idea as the above method embodiment, and its specific implementation process is detailed in the above method embodiment, and will not be repeated here.

Figure 16 The embodiment of this application provides a schematic structural diagram of a data processing device, see Figure 16, the device 1600 is configured as a second node device in the blockchain system, and the second node device includes a trusted execution environment TEE and Rich Execution Environment REE; the TEE includes a processing unit 1601, and the REE includes a communication unit 1602;

The communication unit 1602 is configured to receive a first request from a first node device in the blockchain system, the first request carries a block log, and send the log to the TEE, and the log includes referring to the block with the identifier of the block, and the first request instructs the second node device to process the log;

The processing unit 1601 is configured to store the log in the TEE when the log has passed the verification of the TEE, and send a first response to the first node device through the REE, and the second A response indicates that the second node device has agreed to receive the log.

Optionally, the first request also carries the block;

The communication unit 1602 is also configured to cache the block;

The processing unit 1601 is further configured to receive a third request from the first node device through the REE, and the third request instructs the second node device to submit the block to the local zone The blockchain ledger of the blockchain system;

The processing unit 1601 is further configured to notify the REE to submit the block to the local on the blockchain ledger of the blockchain system.

Optionally, the processing unit 1601 is further configured to:

receiving a second request from the first node device through the REE, the second request indicating to vote for the first node device to become the leader node in the blockchain system;

If the second request passes the verification of the TEE, send a second response to the first node device through the REE, and the second response indicates whether the second node device agrees with the first node device A node device becomes the leader node in the blockchain system.

Optionally, the processing unit 1601 is further configured to:

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

If the notification message passes the verification of the TEE, modify the stored node status of the first node device to be the leader status.

Optionally, the communication unit 1602 is further configured to receive a fourth request from the first node device, the fourth request carrying a snapshot of the log sequence in the first node device and a plurality of blocks, the The snapshot includes a first identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the start log among the multiple logs submitted in the log sequence, and the second identifier is the an identifier of a block corresponding to a termination log in a plurality of logs, the plurality of logs corresponding to the plurality of blocks;

The communication unit 1602 is further configured to cache the multiple blocks, and send the snapshot to the TEE;

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

It should be understood that the apparatus 1600 corresponds to the second node device in the above method embodiment, and each module in the apparatus 1600 and the above-mentioned other operations and/or functions are to realize various steps and functions implemented by the second node device in the method embodiment respectively. For the method, specific details may refer to the foregoing method embodiments, and for the sake of brevity, details are not repeated here.

It should be understood that when the device 1600 determines the data to be processed, it only uses the division of the above-mentioned functional modules as an example for illustration. Different functional modules to complete all or part of the functions described above. In addition, the device 1600 provided in the above embodiment is based on the same idea as the above method embodiment, and its specific implementation process is detailed in the above method embodiment, and will not be repeated here.

FIG. 17 is a schematic structural diagram of a computer device provided by an embodiment of the present application. The computer device 1700 includes one or more processors 1701 and one or more memories 1702 . 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 with the one or more processors 1701, and the one or more memories 1702 are used to store at least one piece of program code, which includes computer instructions, and when the one or more processors 1701 execute the computer instructions , so that the computer device 1700 executes the above related method steps to implement the data processing method in the above embodiment. The computer device 1700 may be any node device provided in this embodiment of the present application. Of course, the computer device 1700 may also have components such as wired or wireless network interfaces, keyboards, and input/output interfaces for input and output. The computer device 17200 may also include other components for implementing device functions, which will not be repeated here.

In an exemplary embodiment, there is also provided a computer-readable storage medium, such as a memory including program codes, which can be executed by a processor in a TEE of a computer device to implement the data processing method in the above-mentioned embodiments. For example, the computer readable storage medium is a non-transitory computer readable storage medium, such as read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), read-only optical disc (compact disc read-only memory, CD-ROM), tapes, floppy disks and optical data storage devices, etc.

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

In addition, an embodiment of the present application also provides a device, which may specifically be a chip, a component or a module, and the device may include a connected processor and a memory; wherein the memory is used to store computer-executable instructions, and when the device is running, The processor can execute the computer-executable instructions stored in the memory, so that the chip executes the data processing methods in the above method embodiments.

Wherein, the device, equipment, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding method provided above, therefore, the beneficial effects it can achieve can refer to the above-mentioned provided The beneficial effects of the corresponding method will not be repeated here.

Through the description of the above embodiments, those skilled in the art can understand that for the convenience and brevity of the description, only the division of the above functional modules is used as an example for illustration. In practical applications, the above functions can be assigned by different Completion of functional modules means that the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the data processing method embodiments provided in the above embodiments belong to the same idea, and the specific implementation process thereof is detailed in the method embodiments, and will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed devices and methods may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be Incorporation or may be integrated into another device, or some features may be omitted, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

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

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the software product is stored in a storage medium Among them, several instructions are included to make a device (which may be a single-chip microcomputer, a chip, etc.) or a processor (processor) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: various media capable of storing program codes such as U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk.

In the description of the present application, unless otherwise specified, "/" means "or", for example, A/B may mean A or B. The "and/or" in this article is just an association relationship describing associated objects, which means that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist at the same time, and B exists alone These three situations. In addition, "at least one" means one or more, and "plurality" means two or more. Words such as "first" and "second" do not limit the number and order of execution, and words such as "first" and "second" do not necessarily limit the difference.

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

All the above optional technical solutions may be combined in any way to form optional embodiments of the present disclosure, which will not be repeated here.

The above are only optional embodiments of the application, and are not intended to limit the application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the application shall be included in the protection of the application. within range.

Claims

A data processing method, characterized in that the method is executed by a first node device in a block chain system, and the first node device includes a trusted execution environment TEE and a rich execution environment REE; the method includes:

The TEE generates a log of the block based on the block in the REE, and the block is referred to by the block identifier in the log;

the TEE sends the log to the REE;

The REE receives the log, sends a first request to the second node device in the blockchain system, the first request carries the log, and the first request instructs the second node device to process the log.
The method according to claim 1, wherein the first request also carries the block, and the first request instructs the second node device to process the log and the block; After the second node device in the blockchain system sends the first request, the method further includes:

The TEE receives 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 blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , the TEE notifies the REE to submit the block to the local blockchain ledger of the blockchain system based on the identification of the block in the log.
The method according to claim 1 or 2, wherein the TEE is based on blocks in the REE, and before generating a log, the method further comprises:

The TEE sends a second request to the second node device in the blockchain system through the REE, and the second request indicates that the first node device becomes the leader node in the blockchain system. vote;

The TEE receives a plurality of second responses through the REE, and each second response indicates whether a second node device agrees with the first node device to become the leader node in the blockchain system;

In the blockchain system, half or most of the second responses of the second node devices have passed the verification of the TEE, and each of the verified second responses indicates that a second node device agrees with the first node When the device becomes the leader node in the blockchain system, the TEE switches the node status of the first node device to the leader status.
The method according to claim 3, wherein after the TEE switches the node state of the first node device to the leader state, the method further comprises:

The TEE generates a notification message, and the notification message indicates that the first node device is a leader node in the blockchain system;

The TEE sends the notification message to the second node device in the blockchain system through the REE.
The method according to claim 2, further comprising:

In the blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , the TEE sends a third request to the second node device in the blockchain system through the REE, and the third request instructs the second node device to submit the block to the local The blockchain ledger of the blockchain system.
The method according to any one of claims 1-5, wherein the method further comprises:

The TEE truncates multiple logs submitted in the log sequence to obtain a snapshot of the log sequence, and the snapshot includes a first identifier and a second identifier, wherein the first identifier is the An identifier of the block corresponding to the start log, the second identifier being the identifier of the block corresponding to the termination log in the plurality of logs;

the TEE sends the snapshot to the REE;

The REE receives the snapshot, and based on the first identifier and the second identifier in the snapshot, obtains the corresponding logs from the local blockchain ledger of the blockchain system. A plurality of blocks, sending a fourth request to the second node device in the blockchain system, the fourth request carries the snapshot and the plurality of blocks, the fourth request indicates that the second The node device submits the multiple blocks to the local blockchain ledger based on the snapshot.
A data processing method, characterized in that the method is executed by a second node device in a blockchain system, the second node device includes a trusted execution environment TEE and a rich execution environment REE; the method includes:

The REE receives a first request from a first node device in the blockchain system, the first request carries a log of a block, and the block is referred to by the identifier of the block in the log, The first request instructs the second node device to process the log;

the REE sends the log to the TEE;

If the log has passed the verification of the TEE, the TEE stores the log, and sends a first response to the first node device through the REE, and the first response indicates that the second node The device has agreed to receive said logs.
The method according to claim 7, wherein the first request also carries the block, and after the REE receives the first request from the first node device in the blockchain system, the method Also includes:

the REE caches the block;

After sending the first response to the first node device through the REE, the method further includes:

The TEE receives a third request from the first node device through the REE, and the third request instructs the second node device to submit the block to the block of the local block chain system Chain ledger;

In the case that the third request passes the verification of the TEE, the TEE notifies the REE to submit the block to the local blockchain based on the identification of the block in the log on the blockchain ledger of the system.
The method according to 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:

The TEE receives a second request from the first node device through the REE, and the second request indicates to vote for the first node device to become the leader node in the blockchain system;

If the second request is verified by the TEE, the TEE sends a second response to the first node device through the REE, and the second response indicates whether the second node device agrees to The first node device becomes a leader node in the blockchain system.
The method according to claim 9, wherein after the TEE sends a second response to the first node device through the REE, the method further comprises:

The TEE receives a notification message from the first node device through the REE, and the notification message instructs the first node device to become a leader node in the blockchain system;

If the notification message passes the verification of the TEE, the TEE modifies the stored node status of the first node device to a leader status.
The method according to any one of claims 7-10, further comprising:

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

The REE caches the plurality of blocks, and sends the snapshot to the TEE;

The TEE receives the snapshot, and if the snapshot passes the verification of the TEE, notifies the REE to submit the multiple blocks to the local blockchain ledger of the blockchain system.
A blockchain system for data processing, characterized in that the blockchain system includes a first node device and at least one second node device;

The first node device is configured to send a first request to a second node device in the blockchain system, the first request carries a log of a block, and the log is indicated by the identifier of the block On behalf of the block, 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 is verified by the second node device.
The system according to claim 12, wherein the first node device includes a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE);

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

The REE is configured to receive the log, and send the first request to the second node device in the blockchain system.
The system according to claim 12 or 13, wherein each second node device includes a TEE and a REE;

The REE of each second node device is configured to receive the first request, and send the log carried in the first request to the TEE of the second node device to which it belongs;

The TEE of each second node device is configured to receive the first request, store the log when the log has passed the verification of the TEE, and send the log to the second node device through the REE of the second node device. A node device sends a first response, the first response indicating whether a second node device has agreed to receive the log.
The system according to claim 14, wherein the first node device comprises a TEE and a REE;

The TEE of the first node device is used to receive the first response of the second node device in the blockchain system through the REE of the first node device, and half or a majority of them in the blockchain system If the first response of the second node device has passed the verification of the TEE, and each of the first responses passed the verification indicates that a second node device has stored the log, based on the area in the log block identification, and notify the REE of the first node device to submit the block to the local blockchain ledger of the blockchain system.
The system according to claim 15, wherein the first request also carries the block;

The TEE of the first node device is also used to send a third request to the second node device in the blockchain system through the REE of the node device to which it belongs, and the third request instructs the second node device to send the Submit the block to the local block chain ledger of the block chain system;

The REE of each second node device is also used to cache the block carried in the first request, receive the third request, and send the third request to the TEE of the second node device;

The TEE of each second node device is also used to receive the third request, and if the third request passes the verification of the TEE, based on the identifier of the block in the log, notify the owner The REE of the second node device submits the block to the local blockchain ledger of the blockchain system.
The system according to any one of claims 12-16, wherein each node device in 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 is used for the TEE of the node device to which it belongs to send a second request to the second node device in the blockchain system, and the second request indicates that the first node device becomes the The leader nodes in the blockchain system vote;

The TEE of each second node device is configured to receive the second request, and when the second request passes the verification of the TEE, send the second request to the first node device through the REE of the associated node device. Two responses, each second response indicates whether a second node device agrees with the first node device to become the leader node in the blockchain system;

The TEE of the first node device is also used to receive the second response of the second node device in the blockchain system to the second request through the REE of the node device to which it belongs. In the blockchain system, half of the Or the second response of most of the second node devices has passed the verification of the TEE, and each of the second responses that pass the verification indicates that a second node device agrees that the first node device becomes a member of the block chain system. In the case of the leader node, switch the node state of the first node device to the leader state.
The system of claim 17, wherein

The TEE of the first node device is also used to generate a notification message, and send the notification message to the second node device in the blockchain system through the REE of the node device to which it belongs, and the notification message indicates that the first The node device is the leader node in the blockchain system;

The TEE of each second node device is also used to receive the notification message through the REE of the node device to which it belongs, and when the notification message passes the verification of the TEE, the stored first node device The node status is changed to leader status.
The system according to any one of claims 12-17, wherein the first node device includes TEE and REE;

The TEE is configured to truncate multiple logs submitted in the log sequence, obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot includes a first identifier and a second identifier, wherein, The first identification is the identification of the block corresponding to the start log in the plurality of logs, and the second identification is the identification of the block corresponding to the termination log in the plurality of logs;

The REE is configured to receive the snapshot, and based on the first identifier and the second identifier in the snapshot, obtain the plurality of logs from the local blockchain ledger of the blockchain system For multiple corresponding blocks, send a fourth request to the second node device in the blockchain system, and the snapshot includes the identification of the first block in the blockchain account book at the current moment and the last block block identification, 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 .
The system according to claim 19, wherein each second node device includes a TEE and a REE;

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

The TEE of each second node device is used to receive the snapshot, and when the snapshot passes the verification of the TEE, notify the REE of the second node device to transfer the multiple blocks based on the snapshot Submit to the blockchain ledger of the local blockchain system.
A data processing device, characterized in that the device is configured as a first node device in a blockchain system, the first node device includes a Trusted Execution Environment TEE and a Rich Execution Environment REE, and the TEE includes processing a unit, the REE comprising a communication unit;

The processing unit is configured to generate a log of the block based on the block in the REE, and send the log to the REE, where the block is referred to by the identifier of the block in the log ;

The communication unit is configured to receive the log, and send a first request to the second node device in the blockchain system, the first request carries the log, and the first request indicates that the second The node device processes the log.
The apparatus according to claim 21, wherein the first request also carries the block, and the first request instructs the second node device to process the log and the block; the processing Units are also used for:

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 blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , based on the identification of the block in the log, notify the REE to submit the block to the local blockchain ledger of the blockchain system.
The device according to claim 21 or 22, wherein the processing unit is further used for:

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

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

In the blockchain system, half or most of the second responses of the second node devices have passed the verification of the TEE, and each of the verified second responses indicates that a second node device agrees with the first node When the device becomes the leader node in the blockchain system, the node status of the first node device is switched to the leader status.
The device according to claim 23, wherein the processing unit is further used for:

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

Sending the notification message to the second node device in the blockchain system through the REE.
The device according to claim 22, wherein the processing unit is further used for:

In the blockchain system, half or most of the first responses of the second node devices have passed the verification of the TEE, and each of the verified first responses indicates that a second node device has agreed to receive the log In the case of , send a third request to the second node device in the blockchain system through the REE, and the third request instructs the second node device to submit the block to the local zone The blockchain ledger of the blockchain system.
The device according to any one of claims 21-25, characterized in that,

The processing unit is further configured to truncate a plurality of submitted logs in the log sequence to obtain a snapshot of the log sequence, and send the snapshot to the REE, the snapshot includes a first identifier and a second identifier, Wherein, the first identification is the identification of the block corresponding to the start log in the plurality of logs, and the second identification is the identification of the block corresponding to the termination log in the plurality of logs;

The communication unit is further configured to receive the snapshot, and based on the first identifier and the second identifier in the snapshot, obtain the multiple from the local blockchain ledger of the blockchain system. a plurality of blocks corresponding to a log, and send a fourth request to the second node device in the blockchain system, the fourth request carries the snapshot and the plurality of blocks, and the fourth request carries the snapshot and the plurality of blocks, the fourth request Instructing the second node device to submit the multiple blocks to the local blockchain ledger based on the snapshot.
A data processing device, characterized in that the device is configured as a second node device in a blockchain system, and the second node device includes a Trusted Execution Environment TEE and a Rich Execution Environment REE; the TEE includes processing a unit, the REE comprising a communication unit;

The communication unit is configured to receive a first request from a first node device in the blockchain system, the first request carries a log of a block, and send the log to the TEE, and the log is in the form of The identifier of the block refers to the block, and the first request instructs the second node device to process the log;

The processing unit is configured to store the log in the TEE when the log has passed the verification of the TEE, and send a first response to the first node device through the REE, and the first The response indicates that the second node device has agreed to receive the log.
The device according to claim 27, wherein the first request also carries the block;

The communication unit is also used to cache the blocks;

The processing unit is further configured to receive a third request from the first node device through the REE, and the third request instructs the second node device to submit the block to the local block The blockchain ledger of the chain system;

The processing unit is further configured to notify the REE to submit the block to a local On the blockchain ledger of the blockchain system.
The device according to claim 27 or 28, wherein the processing unit is further used for:

receiving a second request from the first node device through the REE, the second request indicating to vote for the first node device to become the leader node in the blockchain system;

If the second request passes the verification of the TEE, send a second response to the first node device through the REE, and the second response indicates whether the second node device agrees with the first node device A node device becomes the leader node in the blockchain system.
The device according to claim 29, wherein the processing unit is further used for:

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

If the notification message passes the verification of the TEE, modify the stored node status of the first node device to be the leader status.
Apparatus according to any one of claims 27-30, characterized in that,

The communication unit is further configured to receive a fourth request from the first node device, the fourth request carries a snapshot of the log sequence in the first node device and a plurality of blocks, and the snapshot includes the first An identifier and a second identifier, wherein the first identifier is the identifier of the block corresponding to the start log in the multiple logs that have been submitted in the log sequence, and the second identifier is the termination log of the multiple logs an identifier of a block corresponding to the log, and the multiple logs correspond to the multiple 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 when the snapshot passes the verification of the TEE, notify the REE to submit the plurality of blocks to the local blockchain system Blockchain ledger.
A computer device, characterized in that the computer device includes a Trusted Execution Environment (TEE), the TEE includes a processor, and the processor is used to execute program codes, so that the computer device performs the tasks of claim 1 to claim 11. any one of the methods described.
A computer-readable storage medium, characterized in that at least one program code is stored in the storage medium, and the at least one program code is read by a processor in a trusted execution environment (TEE) to enable a computer device to execute 1 to the method described in any one of claims 11.
A computer program product, characterized in that the computer program product includes at least one piece of program code, and the at least one piece of program code is read by a processor in the Trusted Execution Environment (TEE) to enable the computer device to execute the The method according to any one of claim 11.