A lightweight operating method and apparatus for the Raft consensus algorithm in blockchain

Abstract

This specification discloses a lightweight operation method and apparatus for the Raft consensus algorithm in blockchain. The method involves a blockchain node's consensus module supporting the Raft consensus algorithm, where the node's Raft state machine records transaction consensus state data with the blockchain. The method includes: a leader node receiving a transaction consensus request and generating an operation log, and distributing the operation log to follower nodes; when more than half of the follower nodes confirm the operation log, the leader node executes the transaction consensus request and produces a block; the leader node's Raft state machine records the transaction consensus state data and performs log compression on block operation logs shorter than the current block height; when a new node joins the blockchain, the leader node generates a snapshot of the current Raft state machine and sends the snapshot to the new node. This invention effectively reduces the overhead of using the Raft consensus algorithm in the blockchain by utilizing Raft log compression and snapshot synchronization mechanisms, enabling rapid synchronization of consensus state data.

Description

Technical Field

[0001] This specification relates to the field of computer software technology, and in particular to a lightweight operation method, apparatus, electronic device and storage medium for the Raft consensus algorithm used in blockchain. Background Technology

[0002] Raft consensus algorithm is a commonly used fault-tolerant algorithm in distributed systems, widely used in various distributed systems due to its reliability, security, and ease of understanding. For blockchain systems, especially in consortium blockchain applications, based on strong trust assumptions, Raft consensus algorithm can well meet the needs of consortium blockchain systems, and most consortium blockchain implementations support Raft consensus algorithm. In general Raft applications, nodes save historical logs and replicate them to other nodes when needed to maintain data consistency between nodes. If the log data volume is too large, the state machine is snapshotted and outdated logs are discarded. However, in blockchain applications, Raft only needs to act as a consensus module to continuously reach consensus on new blocks among nodes. The blockchain has its own data synchronization mechanism to ensure data consistency between nodes. In this case, Raft saving historical logs is not only unnecessary but also affects system performance: First, saving historical logs increases runtime memory overhead, and recovery is required after restart, so continuous persistence is also necessary, increasing disk I / O overhead; second, restarted or newly added nodes need to synchronize all historical logs to work properly. When the data volume is large or the network conditions are poor, this process is lengthy, affecting system availability. Therefore, when the Raft consensus algorithm is used in blockchain applications, how to reduce log storage overhead while achieving fast synchronization of node state logs is a technical problem that urgently needs to be solved. Summary of the Invention

[0003] The purpose of the embodiments in this specification is to address the above-mentioned problems by providing a lightweight operating device, apparatus, electronic device, and storage medium for the Raft consensus algorithm in blockchain.

[0004] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows:

[0005] Firstly, a lightweight operation method for the Raft consensus algorithm in blockchain is proposed. The consensus module of the blockchain node supports the Raft consensus algorithm, and the Raft state machine of the node is used to record transaction consensus state data with the blockchain. The method includes:

[0006] The leader node receives transaction consensus requests, generates operation logs, and distributes the operation logs to the follower nodes;

[0007] When more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes the block production.

[0008] The Leader node's Raft state machine records the transaction consensus state data and performs log compression operations on block operation logs that are smaller than the current block height.

[0009] When a new node joins the blockchain and / or an existing node in the blockchain restarts, the Leader node generates a snapshot of the current Raft state machine and sends the snapshot to the node.

[0010] Furthermore, the transaction consensus status data includes the current consensus node list and / or Raft running status.

[0011] Furthermore, the Raft running state includes the current state data of the Raft state machine and the information of the Leader node and the Follower node participating in this Raft consensus.

[0012] Furthermore, it also includes: after receiving and restoring a snapshot of the Raft state machine, the node obtains the current transaction consensus state data, and completes a state synchronization operation based on the current transaction consensus state data.

[0013] Secondly, a lightweight operating device for the Raft consensus algorithm in blockchain is proposed. The consensus module of the blockchain node supports the Raft consensus algorithm, and the Raft state machine of the node is used to record state data related to blockchain consensus. The device includes:

[0014] The first module is used for the Leader node to receive transaction consensus requests and generate operation logs, and to distribute the operation logs to the Follower nodes;

[0015] The second module is used so that when more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes block production.

[0016] The third module is used for the Leader node's Raft state machine to record the transaction consensus state data and to perform log compression operations on block operation logs that are smaller than the current block height.

[0017] The fourth module is used to generate a snapshot of the current Raft state machine by the Leader node when a new node joins the blockchain and / or an existing node of the blockchain restarts, and to send the snapshot to the node.

[0018] Furthermore, the transaction consensus status data includes the current consensus node list and / or Raft running status.

[0019] Furthermore, the Raft running state includes the current state data of the Raft state machine and the information of the Leader node and the Follower node participating in this Raft consensus.

[0020] Furthermore, it also includes:

[0021] The fifth module is used to obtain the current transaction consensus state data after the node receives and restores the snapshot of the Raft state machine, and to complete the state synchronization operation based on the current transaction consensus state data.

[0022] Thirdly, an electronic device is proposed, characterized in that it comprises:

[0023] Processor; and

[0024] A memory is configured to store computer-executable instructions, which, when executed, cause the processor to perform the lightweight operation method of the Raft consensus algorithm for blockchain as described in the first aspect.

[0025] Fourthly, a computer-readable storage medium is proposed, characterized in that the computer-readable storage medium stores one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform the lightweight operation method of the Raft consensus algorithm for blockchain described in the first aspect.

[0026] This manual can achieve at least the following technical effects:

[0027] The present invention utilizes Raft log compression and snapshot synchronization mechanisms to effectively reduce the memory and disk I / O overhead of the blockchain when using the Raft consensus algorithm, and enables new nodes to join the blockchain or existing blockchain nodes to quickly complete consensus state data synchronization after restarting. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is one of the schematic diagrams illustrating a lightweight operation method for the Raft consensus algorithm used in blockchain, provided in the embodiments of this specification.

[0030] Figure 2 This is the second schematic diagram of a lightweight operation method for the Raft consensus algorithm used in blockchain, provided in the embodiments of this specification.

[0031] Figure 3 This is the third schematic diagram of a lightweight operation method for the Raft consensus algorithm used in blockchain, provided in the embodiments of this specification.

[0032] Figure 4 This is one of the schematic diagrams of a lightweight operating device for the Raft consensus algorithm for blockchain provided in the embodiments of this specification.

[0033] Figure 5 This is the second schematic diagram of a lightweight operating device for the Raft consensus algorithm used in blockchain, provided as an embodiment of this specification.

[0034] Figure 6 This is a schematic diagram of the structure of an electronic device provided as an embodiment of this specification. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0036] Key terms

[0037] Raft consensus algorithm: A widely used distributed consensus algorithm characterized by strong consistency, decentralization, and high availability. This means that even with node failures, network latency, or network segmentation, multiple nodes can reach a consensus on a given issue. The Raft protocol is a leader-based consensus algorithm, and its core consists of three sub-problems: leader election, log replication, and safety. These three parts together implement Raft's core consensus and fault tolerance mechanisms. In the election process, the leader node is elected by the community. Each leader node works for a period, and then a new leader node is elected to continue the leadership. This is similar to elections in a democratic society, where each new term of office is called a term. Therefore, the Raft protocol strongly relies on the leader node to ensure cluster data consistency; data sent from clients always reaches the leader node first.

[0038] Raft Log Compression Mechanism: Raft cannot save historical logs indefinitely. When the log data volume reaches a certain size, it can be cleaned up through log compression, i.e., the log compression mechanism. A snapshot of the current state machine data and some Raft metadata is written and persisted for use during restart and recovery. Logs already applied to the state machine are discarded, and new logs are recorded. In typical applications, the amount of state machine data can be very large, and taking snapshots can consume significant time and resources. Therefore, the log compression mechanism should be used judiciously. If snapshots are created too frequently, a large amount of disk bandwidth and other resources will be wasted; if snapshots are created too infrequently, there is a risk of exhausting storage capacity, and the time required to rebuild from the logs is also increased.

[0039] Raft Synchronization Mechanism: Raft is a consensus algorithm based on a replicated state machine. This means that as long as all nodes have the same initial state and apply the same logs in the same order, the final state consistency of all nodes can be guaranteed. When a restarted or newly added node joins the cluster, the cluster leader performs a consistency check on it, finds the last log entry that matches the leader's, and copies any lagging log entries to it. This successfully completes synchronization and allows the node to function normally; this method is called log synchronization. However, due to log compression, the logs needed by the new node may have already been compressed. In this case, the leader generates a snapshot of the current state and sends it to the new node; this is different from log synchronization and is called snapshot synchronization. Raft will use log synchronization as much as possible, and will only use snapshot synchronization if and only if the logs needed by the new node have been compressed. This is because, typically, the amount of state data in the state machine is much larger than the amount of log entries.

[0040] The following section provides a detailed example of a lightweight implementation scheme for the Raft consensus algorithm used in blockchain, as described in this specification.

[0041] This invention focuses on how to solve the problem of reducing log storage overhead while achieving fast synchronization of node state logs when using the Raft consensus algorithm in blockchain applications. Raft, a commonly used fault-tolerant algorithm in distributed systems, evolved from the Paxos consensus algorithm. It can handle non-Byzantine faults such as the failure of up to half of the nodes in the cluster or network latency. Its reliability, security, and ease of understanding have led to its widespread application in various distributed systems. Since blockchain is also a type of distributed system, and a blockchain system built by multiple nodes whose identities are known to each other is called a consortium blockchain, unlike public blockchains which are accessible to everyone, consortium blockchains are generally only open to members within the consortium. Therefore, this application scenario naturally involves strong trust assumptions, allowing for the assumption that Byzantine faults will not occur in the system. In this case, the Raft consensus algorithm can well meet the needs of consortium blockchain systems; in fact, most consortium blockchain implementations support the Raft consensus algorithm. The operating principle of Raft is as follows: the client initiates a write operation to the server leader; the leader adds the operation to the log and replicates it to all followers; when more than half of the nodes confirm, the operation can be applied to the state machine. In typical Raft applications, nodes store historical logs, which are copied to other nodes as needed to maintain data consistency. If the log volume becomes too large, a snapshot of the state machine is taken, and outdated logs are discarded. However, in blockchain applications, Raft only needs to act as a consensus module to continuously reach consensus on new blocks among nodes. The blockchain has its own data synchronization mechanism to ensure data consistency among nodes. In this case, Raft's storage of historical logs is not only unnecessary but also affects system performance: First, storing historical logs increases runtime memory overhead, and recovery is required after a restart, thus requiring continuous persistence, which increases disk I / O overhead. Second, restarted or newly added nodes need to synchronize all historical logs to function properly. When the data volume is large or network conditions are poor, this process will take a long time, thus affecting system availability.

[0042] Example 1

[0043] The technical approach of the lightweight Raft consensus algorithm operation scheme for blockchain in this invention embodiment is as follows: Considering that in blockchain applications, the Raft state machine typically only stores data related to the consensus state, such as the current consensus node list, this data is usually quite lightweight, even smaller than the data size of an empty block. In this case, the overhead of snapshot synchronization is much smaller than the overhead of log synchronization. By fully utilizing this characteristic of the blockchain system and the log synchronization mechanism, the log synchronization process can be bypassed. For example, by performing log compression once after each block is produced and promptly cleaning up historical logs, new nodes will use snapshot synchronization when joining. Specifically, under the premise that the data of the Raft state machine is only related to the blockchain consensus state, each time a new block is produced, the log compression mechanism is used to compress the previous blocks. This ensures that the logs required by new nodes are always compressed logs, and they will use snapshot synchronization when synchronizing data, thereby achieving a faster and lighter synchronization process compared to traditional log synchronization.

[0044] Therefore, such as Figure 1 The diagram illustrates a lightweight operation method for the Raft consensus algorithm in blockchain according to an embodiment of the present invention. First, the consensus module of the blockchain node must support the Raft consensus algorithm; simultaneously, the node's Raft state machine is used to record transaction consensus state data related to the blockchain, rather than recording data unrelated to consensus, otherwise the state machine data volume would be excessive. The method includes:

[0045] S1: The Leader node receives the transaction consensus request, generates an operation log, and distributes the operation log to the Follower nodes.

[0046] Optionally, the transaction consensus status data includes the current list of consensus nodes and / or the Raft running status.

[0047] Optionally, the Raft running state includes the current state data of the Raft state machine and the information of the Leader node and the Follower node participating in this Raft consensus.

[0048] S2: When more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes the block production.

[0049] S3: The Raft state machine of the Leader node records the transaction consensus state data and performs log compression operation on block operation logs that are smaller than the current block height.

[0050] S4: When a new node joins the blockchain and / or an existing node in the blockchain restarts, the Leader node generates a snapshot of the current Raft state machine and sends the snapshot to the node.

[0051] like Figure 2 The diagram illustrates another implementation of the lightweight Raft consensus algorithm for blockchain according to an embodiment of the present invention. The method further includes:

[0052] S5: After receiving and restoring the snapshot of the Raft state machine, the node obtains the current transaction consensus state data and completes the state synchronization operation based on the current transaction consensus state data.

[0053] For example Figure 3 The application scenarios shown will be explained in detail. Figure 3 In this blockchain system, when an existing node restarts and intends to rejoin, it needs to synchronize its consensus state with the existing nodes currently running in the blockchain system. Taking the Leader node as the synchronization node as an example, since the scheme of this embodiment compresses the consensus state logs of existing blocks below the block height every time a new block is produced, the latest block of the current Leader node is Block 1014, while the logs of Block 1013 and earlier blocks have already been compressed. For the restarted node, its current block before restarting is Block 112. If a log synchronization mechanism is used at this time, the restarted node cannot obtain the consensus logs of Block 1013 because the logs of Block 1013 have already been compressed, and therefore cannot perform log synchronization. At this point, a snapshot operation is performed on the Leader node's Raft state machine. Since the Raft state machine records the necessary information for consensus, including the consensus node list, Raft running status, including the current state data of the Raft state machine and the information of the Leader and Follower nodes participating in this Raft consensus, the restarted node can quickly achieve consensus state synchronization by obtaining and restoring the Leader node's state machine snapshot, thereby enabling the node to rejoin the blockchain and participate in transaction consensus.

[0054] This embodiment effectively reduces the memory and disk I / O overhead of the blockchain when using the Raft consensus algorithm by introducing Raft log compression and snapshot synchronization mechanisms. It also allows new nodes to join the blockchain or existing nodes to restart and bypass the traditional log synchronization process to quickly complete consensus state data synchronization.

[0055] Example 2

[0056] Figure 4This is a schematic diagram of a lightweight operating device 400 for the Raft consensus algorithm in blockchain, provided as an embodiment of this specification. Please refer to... Figure 4 In one embodiment, a lightweight operating device 400 for the Raft consensus algorithm in blockchain includes a consensus module for blockchain nodes that supports the Raft consensus algorithm. The Raft state machine of the node is used to record state data related to blockchain consensus. The device includes:

[0057] The first module 401 is used for the Leader node to receive transaction consensus requests and generate operation logs, and to distribute the operation logs to the Follower nodes.

[0058] The second module 402 is used to enable the Leader node to execute a transaction consensus request and complete block production when more than half of the Follower nodes confirm the operation log.

[0059] The third module 403 is used for the Leader node's Raft state machine to record the transaction consensus state data and to perform log compression operations on block operation logs that are smaller than the current block height.

[0060] The fourth module 404 is used to generate a snapshot of the current Raft state machine by the Leader node and send the snapshot to the node when a new node joins the blockchain and / or an existing node of the blockchain restarts.

[0061] like Figure 5 As shown, another implementation of the lightweight Raft consensus algorithm runtime device 400 for blockchain according to an embodiment of the present invention further includes:

[0062] The fifth module 405 is used to obtain the current transaction consensus state data after the node receives and restores the snapshot of the Raft state machine, and to complete the state synchronization operation based on the current transaction consensus state data.

[0063] It should be understood that the lightweight operating device 400 for the Raft consensus algorithm in blockchain embodiments of this specification can also execute... Figures 1 to 3 A method for executing a lightweight operating device (or device) for the Raft consensus algorithm in blockchain, and implementation of the lightweight operating device (or device) for the Raft consensus algorithm in blockchain. Figures 1 to 3 The functionality of the example shown will not be elaborated upon here.

[0064] Example 3

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

[0066] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0067] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0068] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming a shared resource access control mechanism at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0069] The consensus module of the blockchain node supports the Raft consensus algorithm, and the node's Raft state machine is used to record transaction consensus state data with the blockchain; including:

[0070] The leader node receives transaction consensus requests, generates operation logs, and distributes the operation logs to the follower nodes;

[0071] When more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes the block production.

[0072] The Leader node's Raft state machine records the transaction consensus state data and performs log compression operations on block operation logs that are smaller than the current block height.

[0073] When a new node joins the blockchain and / or an existing node in the blockchain restarts, the Leader node generates a snapshot of the current Raft state machine and sends the snapshot to the node.

[0074] The above is as described in this instruction manual. Figures 1 to 3 The lightweight operation method for the Raft consensus algorithm in blockchain disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this specification can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

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

[0076] Example 4

[0077] This specification also provides an embodiment of a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figures 1 to 3The illustrated embodiment provides a lightweight method for running the Raft consensus algorithm in blockchain, specifically for executing the following methods:

[0078] The consensus module of the blockchain node supports the Raft consensus algorithm, and the node's Raft state machine is used to record transaction consensus state data with the blockchain; including:

[0079] The leader node receives transaction consensus requests, generates operation logs, and distributes the operation logs to the follower nodes;

[0080] When more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes the block production.

[0081] The Leader node's Raft state machine records the transaction consensus state data and performs log compression operations on block operation logs that are smaller than the current block height.

[0082] When a new node joins the blockchain and / or an existing node in the blockchain restarts, the Leader node generates a snapshot of the current Raft state machine and sends the snapshot to the node.

[0083] In summary, the above description is merely a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

[0084] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0085] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0086] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A method for lightweight running of Raft consensus algorithm for blockchain, characterized in that, The consensus module of the blockchain node supports a Raft consensus algorithm, and a Raft state machine of the blockchain node is configured to record transaction consensus state data of the blockchain; the method comprises: The Leader node receives a transaction consensus request and generates an operation log, and distributes the operation log to Follower nodes; When more than half of the Follower nodes confirm the operation log, the Leader node executes the transaction consensus request and completes block generation; The Raft state machine of the Leader node records the transaction consensus state data, and performs a log compression operation on block operation logs smaller than a current block height; When a new node joins the blockchain and / or an existing node of the blockchain is restarted, the Leader node generates a snapshot of the current Raft state machine and sends the snapshot to the new node that joins the blockchain or the restarted existing node of the blockchain; After the node receives and restores the snapshot of the Raft state machine, the node acquires current transaction consensus state data and performs a state synchronization operation according to the current transaction consensus state data.

2. The method for lightweight running of Raft consensus algorithm for blockchain according to claim 1, characterized in that, The transaction consensus state data comprises a current consensus node list and / or a Raft running state.

3. The method for lightweight running of Raft consensus algorithm for blockchain of claim 2, characterized in that, The Raft running state comprises current state data of a Raft state machine and information of the Leader node and the Follower nodes participating in the Raft consensus. 4.A device for lightweight running of a Raft consensus algorithm for a blockchain, characterized in that, The consensus module of the blockchain node supports a Raft consensus algorithm, and a Raft state machine of the blockchain node is configured to record transaction consensus state data of the blockchain; the apparatus comprises: A first module configured to cause a Leader node to receive a transaction consensus request and generate an operation log, and distribute the operation log to Follower nodes; A second module configured to cause the Leader node to execute the transaction consensus request and complete block generation when more than half of the Follower nodes confirm the operation log; A third module configured to cause the Raft state machine of the Leader node to record the transaction consensus state data and perform a log compression operation on block operation logs smaller than a current block height; A fourth module configured to cause the Leader node to generate a snapshot of the current Raft state machine and send the snapshot to a new node that joins the blockchain or a restarted existing node of the blockchain when a new node joins the blockchain and / or an existing node of the blockchain is restarted; A fifth module configured to cause the node to acquire current transaction consensus state data and perform a state synchronization operation according to the current transaction consensus state data after the node receives and restores the snapshot of the Raft state machine. 5.The apparatus for lightweight running of Raft consensus algorithm for blockchain of claim 4, wherein, The transaction consensus state data comprises a current consensus node list and / or a Raft running state.

6. The apparatus for lightweight running of Raft consensus algorithm for blockchain of claim 5, wherein, The Raft running state comprises current state data of a Raft state machine and information of the Leader node and the Follower nodes participating in the Raft consensus.

7. An electronic device, comprising: comprises: a processor; and ​ A memory arranged to store computer-executable instructions that, when executed, cause the processor to perform the method for lightweight running of Raft consensus algorithm for blockchain of any one of claims 1 to 3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which when executed by an electronic device including a plurality of applications, cause the electronic device to perform the method for lightweight running of Raft consensus algorithm for blockchain of any one of claims 1 to 3.

Images