System and method for quickly terminating block based on consensus algorithm

Abstract

The invention aims to provide a system and a method for quickly terminating a block based on a consensus algorithm. The system provided by the invention comprises a storage provider, a node, a list service and a final module, wherein the storage provider is used for registering to a node through an rpc interface; the nodes are used for synchronizing a block chain network, acquiring blocks and message information on a chain, and providing corresponding interfaces for a storage provider and a final module; the list service is used for providing configuration information of a block chain network for a final module; the final module comprises an integrated consensus algorithm and a terminator, and is used for calculating a block set between a chain head and a terminated block based on the blocks on the chain, the message information and the configuration information, and proposing a block in the block set as a terminated block; and the storage provider votes to select a termination block. The block can be quickly terminated, the processing efficiency is improved, and a non-rollback target is achieved.

Description

Technical Field

[0001] The present application relates to the field of blockchain, and in particular to a system and method for quickly terminating blocks based on a consensus algorithm. Background Art

[0002] As a decentralized storage system, the Filecoin network uses a consensus protocol to verify and confirm the validity of blocks on its blockchain. The current Filecoin network uses verification mechanisms such as proof of replication and proof of space-time, relying on the computing and storage capabilities of nodes to determine the validity of blocks. In the Filecoin mainnet, a height is 30 seconds, and there are multiple blocks at a height. Blocks with the same parent block at the same height form a block set (tipset). A tipset is considered final after 900 heights, which corresponds to about 7.5 hours. Such a long final time greatly hinders user experience. It limits applications on Filecoin built with FVM and IPC. A long confirmation period is required for data transactions, and cross-chain bridges are also affected by the long waiting time for asset transfers. Summary of the invention

[0003] One purpose of the present application is to provide a system and method for quickly finalizing blocks based on a consensus algorithm, so as to solve the problems in the prior art of long time required to determine the final block and long data transaction confirmation period.

[0004] According to one aspect of the present application, a system for quickly finalizing blocks based on a consensus algorithm is provided, the system comprising: a storage provider, a node, a list service, and a finality module; wherein:

[0005] The storage provider is used to register with the node through the rpc interface;

[0006] The node is used to synchronize the blockchain network, obtain block and message information on the chain, and provide corresponding interfaces to storage providers and finality modules;

[0007] The inventory service is used to provide the finality module with configuration information of the blockchain network;

[0008] The finality module includes an integrated consensus algorithm and a terminator, which is used to calculate the block set between the chain head and the terminated block based on the block and message information on the chain and the configuration information, and propose the block in the block set as the final block; the storage provider votes to select the final block.

[0009] Optionally, the node is used to receive and broadcast relevant information of the finality module, wherein the relevant information includes message information and finalized blocks, and the message information includes messages in the pre-proposal phase, messages in the submission phase, and messages in the finalization phase.

[0010] Optionally, the storage provider is used to provide signature information and participate in the voting proposed by the finality module to determine the final block.

[0011] Optionally, the finality module is used to implement the Gossip PBFT consensus algorithm and supports receiving and publishing messages using Gossip.

[0012] Optionally, the finality module is used to implement the Gossip PBFT consensus algorithm, including repeating the following stages at each height where the block is located: a pre-proposal stage, a gathering stage, a preparation stage, a submission stage, and a finalization stage.

[0013] Optionally, the pre-proposal phase is used to propose a target block in a block set as a block set at the current height, and after broadcasting, if it meets the voting requirements, it enters the aggregation phase;

[0014] The aggregation phase is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation phase;

[0015] The preparation phase is used to broadcast again after the timeout. If more than two-thirds of the storage providers in the entire network vote, the final phase will begin;

[0016] The final stage is used to determine the final block at the current height based on the proportion of storage providers' votes for the target block, thus ending this round of voting.

[0017] According to another aspect of the present application, a method for quickly finalizing a block based on a consensus algorithm is also provided, the method comprising:

[0018] The storage provider registers with the node through the RPC interface, and the node synchronizes the blockchain network and obtains the block and message information on the chain;

[0019] Obtaining configuration information of the blockchain network from the inventory service through a finality module, calculating a block set between the chain head and the finalized block based on the block and message information on the chain and the configuration information, and proposing a target block in the block set as a finalized block, wherein the finality module integrates a consensus algorithm;

[0020] Storage providers vote to select the final block.

[0021] Optionally, a target block in the proposed block set is used as the final block, including:

[0022] Repeat the steps of the target phase at each height where the block is located, propose the target block in the block set, and determine the final block. The target phase includes the pre-proposal phase, the aggregation phase, the preparation phase, the submission phase, and the final phase.

[0023] Optionally, repeat the steps of the target phase at each height where the block is located, propose a target block in the block set, and determine the final block, including:

[0024] Pre-proposal phase steps: propose a target block in the block set as the block set at the current height, and enter the aggregation phase if it meets the voting requirements after broadcasting;

[0025] Aggregation phase steps: The aggregation phase is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation phase;

[0026] Preparation phase steps: After the timeout and rebroadcast, if more than two-thirds of the storage providers in the entire network vote, the final phase will begin;

[0027] Final stage steps: Determine the final block at the current height based on the proportion of storage providers’ votes for the target block, ending this round of voting.

[0028] According to another aspect of the present application, a computer-readable medium is provided, on which computer-readable instructions are stored. The computer-readable instructions can be executed by a processor to implement the method described above.

[0029] Compared with the prior art, the system provided by the present application includes: a storage provider, a node, a list service and a finality module; wherein the storage provider is used to register with the node through the rpc interface; the node is used to synchronize the blockchain network, obtain the block and message information on the chain, and provide the corresponding interface to the storage provider and the finality module; the list service is used to provide the configuration information of the blockchain network to the finality module; the finality module includes an integrated consensus algorithm and a terminator, which is used to calculate the block set between the chain head and the terminated block based on the block and message information on the chain and the configuration information, and propose the block in the block set as the final block; the storage provider votes to select the final block. It can quickly terminate the block, improve the processing efficiency, and achieve the goal of non-rollback. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0031] Figure 1 A schematic diagram showing the structure of a system for quickly finalizing blocks based on a consensus algorithm according to one aspect of the present application is shown;

[0032] Figure 2 A schematic diagram of a system framework for quickly finalizing blocks based on the Gossip PBFT consensus algorithm in one embodiment of the present application is shown;

[0033] Figure 3 A schematic flow chart of a method for quickly finalizing blocks based on a consensus algorithm according to another aspect of the present application is shown.

[0034] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0035] The present application is described in further detail below in conjunction with the accompanying drawings.

[0036] In a typical configuration of the present application, the terminal, the device of the service network and the trusted party all include one or more processors (eg, a central processing unit (CPU)), an input / output interface, a network interface and a memory.

[0037] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0038] Computer readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, Phase-Change RAM (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of random access memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disk (DVD) or other optical storage, magnetic cassettes, tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. According to the definition in this article, computer-readable media does not include non-transitory media such as modulated data signals and carrier waves.

[0039] Figure 1 A structural schematic diagram of a system for quickly terminating blocks based on a consensus algorithm provided according to one aspect of the present application is shown, the system comprising: a storage provider 100, a node 200, a list service 300 and a finality module 400; wherein the storage provider 100 is used to register with the node 200 through an rpc interface; the node 200 is used to synchronize the blockchain network, obtain the block and message information on the chain, and provide a corresponding interface to the storage provider 100 and the finality module 400; the list service 300 is used to provide the configuration information of the blockchain network to the finality module 400; the finality module 400 includes an integrated consensus algorithm and a terminator, which is used to calculate the block set between the chain head and the terminated block based on the block and message information on the chain and the configuration information, and propose the block in the block set as the final block; the storage provider 100 votes to select the final block.

[0040] Storage providers refer to nodes that provide storage space for Filecoin. The final block set (tipset) is selected through the voting of storage providers. In the Filecoin network, the same height can contain multiple blocks. All blocks with the same parent block form a set called tipset. Storage providers register to the nodes deployed by the storage provider themselves through the rpc interface and act as participants in the finality module. The node will synchronize the blockchain network, obtain block and message information, that is, synchronize the on-chain status, and provide relevant interfaces to storage providers and finality modules; the finality module is the fast finality module (F3 module), which uses the Gossip PBFT consensus algorithm to obtain the configuration information of the current blockchain network from the manifest service, where the configuration information includes the network name, protocol version, request timeout, and retry interval, etc., which can be obtained from the manifest service (manifest server) through libp2p, and then use the obtained on-chain status information and configuration information to calculate the block set tipset between the chain head and the terminated block, select a block, propose the block as the final block, and then let the storage provider vote. When more than two-thirds of the storage computing power votes in favor, the final block is determined.

[0041] In some embodiments of the present application, the node is used to receive and broadcast relevant information of the finality module, wherein the relevant information includes message information and terminated blocks, and the message information includes messages in the pre-proposal phase, messages in the submission phase, and messages in the finalization phase. Here, the node is also used to receive and broadcast F3 related information, which includes messages and terminated blocks, and the messages include messages in the pre-proposal phase, messages in the submission phase, and messages in the finalization phase in the F3 module.

[0042] In some embodiments of the present application, the storage provider is used to provide signature information and participate in the voting proposed by the finality module to determine the final block. Here, the storage provider also provides signature information, which is used to prevent forgery of voting messages, and the storage provider participates in the voting proposed by the F3 module to determine the final block.

[0043] In some embodiments of the present application, the finality module is used to implement the Gossip PBFT consensus algorithm and supports the use of Gossip to receive and publish messages. Here, Gossip PBFT is a Byzantine fault-tolerant consensus protocol that provides typical properties of protocol, validity and termination. It is simple and leaderless, and it can resist more powerful attacks and opponents through gossip information transmission between nodes. In the traditional PBFT consensus, nodes need to exchange information with other nodes in the entire network, and each exchange will increase the delay. While Gossip PBFT uses the gossip protocol, nodes do not need to immediately pass the information to every node in the entire network, but start to spread through local information exchange with adjacent nodes (directly connected nodes). These adjacent nodes will pass on the information to other nodes after receiving it. Through this local propagation, information can be rapidly expanded in the network in a short time. The end of block confirmation refers to the block being widely verified and consensus reached in the network, marking that the block has become an irreversible historical record. Using Gossip PBFT will speed up this process. When the majority of storage providers vote to confirm the block through the gossip protocol, the system will quickly complete the termination. In the embodiment of the present application, the Gossip PBFT consensus algorithm is implemented in the F3 module, and messages are sent to the network through nodes. Gossip is used to accelerate the exchange of information between nodes. The broadcasting of messages between nodes will significantly increase the use of bandwidth, and the block will be quickly terminated after more than two-thirds of the storage providers vote.

[0044] Continuing with the above embodiment, the finality module is used to implement the Gossip PBFT consensus algorithm, including repeating the following stages at each height where the block is located: pre-proposal stage, aggregation stage, preparation stage, submission stage, and finalization stage. Here, the Gossip PBFT consensus algorithm is integrated into the F3 module, and the F3 finalization block process is implemented through five stages, and each height will repeat the five stages, where the height is the current height of the current block.

[0045] Specifically, the five stages are: the pre-proposal stage is used to propose the target block in the block set as the block set of the current height, and enter the aggregation stage if it meets the voting requirements after broadcasting; the aggregation stage is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation stage; the preparation stage is used to broadcast again after the timeout, and if more than two-thirds of the storage providers in the entire network vote, it enters the termination stage; the termination stage is used to determine the final block of the current height according to the proportion of the number of votes of the storage providers for the target block, and end this round of voting.

[0046] Here, the F3 module obtains configuration information from the manifest server, creates a new instance, and enters the pre-proposal phase; in the pre-proposal phase: propose a tipset as the block set at the current height of the block on the current chain, and the storage provider signs the tipset-related information and broadcasts it to the network by the node. The tipset-related information includes one or more block information, and the block contains block ID, height, parent block ID, message ID, etc. The F3 module receives and verifies the received message. If it times out or more than two-thirds of the storage providers vote, it enters the aggregation phase. Aggregation phase: adjust the stage information, the storage provider signs and broadcasts it to the network by the node. Receive and verify the received message. If the waiting times out, select the tipset as the final block set at the height according to the rules and enter the preparation phase. Preparation phase: adjust the stage information, the storage provider signs and broadcasts it to the network by the node. Receive and verify the received message. If it times out, broadcast it again. If more than two-thirds of the storage providers vote, it enters the submission phase. Submission phase: adjust the stage information, the storage provider signs and broadcasts it to the network by the node. Receive and verify the received message. If it times out, broadcast it again. If more than two-thirds of the storage providers in the entire network vote, it enters the final stage. Final stage: adjust the stage information, the storage provider signs and broadcasts it to the network by the node. Receive and verify the received message. If more than two-thirds of the storage providers in the entire network vote, the block contained in the tipset is used as the final block of the height, ending this round of voting and moving on to the next round.

[0047] This application integrates the Gossip PBFT algorithm into the F3 module and uses the libp2p2 communication protocol to interact with the Filecoin network. At each block height, a final tipset is proposed. This tipset must be voted on and confirmed by storage providers with more than two-thirds of the computing power in the Filecoin network before it can be considered a finalized tipset and officially received into the network. For example, Figure 2A schematic diagram of a system framework for quickly terminating blocks based on the Gossip PBFT consensus algorithm in an embodiment of the present application is shown, wherein the storage provider registers with the node through the rpc interface, the node synchronizes the block, broadcasts the block and the message; the F3 module obtains configuration information from the manifest server, F3 starts and loads the terminated block, obtains the chain head from the node, calculates the block between the chain head and the terminated block, and proposes the calculated block as the terminated block; and starts the 5-stage steps of F3 terminating the block. For example, the block heights corresponding to a to d are 1 to 4. Through the chain head d and the terminated blocks, it can be calculated which blocks can be proposed as the terminated blocks; propose c as the terminated block: assuming that a and b are terminated blocks, the chain head is d, and the chain head is not stable yet and cannot be proposed as the terminated block. It is calculated that block c is the block between the chain head d and block b, so c is proposed as the terminated block. c is determined as the terminated block after the five stages of F3 terminating the block.

[0048] Figure 3 A schematic flow chart of a method for quickly finalizing blocks based on a consensus algorithm according to another aspect of the present application is shown, the method comprising: steps S11 to S13, wherein:

[0049] Step S11, the storage provider registers with the node through the rpc interface, the node synchronizes the blockchain network and obtains the block and message information on the chain; here, the storage provider registers with the node deployed by the storage provider itself through the rpc interface and acts as a participant in the finality module; the node will synchronize the blockchain network, obtain block and message information, that is, synchronize the on-chain status, and provide relevant interfaces to the storage provider and the finality module.

[0050] Step S12, obtain the configuration information of the blockchain network from the manifest service through the finality module, calculate the block set between the chain head and the terminated block based on the block and message information on the chain and the configuration information, and propose the block in the block set as the final block, wherein the finality module integrates the consensus algorithm; Step S13, the storage provider votes to select the final block. Here, the finality module is a fast finality module (F3 module), which uses the GossipPBFT consensus algorithm to obtain the configuration information of the current blockchain network from the manifest service, wherein the configuration information includes the network name, protocol version, request timeout, and retry interval, etc., which can be obtained from the manifest service (manifestserver) through libp2p, and then use the obtained chain status information and configuration information to calculate the block set tipset between the chain head and the terminated block, select a block, propose the block as the final block, and then let the storage provider vote, and finally determine the final block when more than two-thirds of the storage computing power votes in favor.

[0051] In some embodiments of the present application, in step S12, the steps of the target stage are repeated at each height where the block is located, and the target block in the block set is proposed and the final block is determined, wherein the target stage includes a pre-proposal stage, a gathering stage, a preparation stage, a submission stage, and a final stage. Here, the Gossip PBFT consensus algorithm is integrated into the F3 module, and the F3 final block process is implemented through the steps of five stages, and each height will repeat the five stages, wherein the height is the current height where the current block is located. For example, the block heights corresponding to a to d are 1 to 4, and which blocks can be proposed as final blocks can be calculated through the chain head d and the terminated blocks. For example, assuming that a and b are already terminated blocks, and the chain head is d, then it is calculated that block c is the block between the chain head d and block b, so the target block c is proposed as the final block, and the steps of the five stages are used to vote on c and other processes to determine that block c is the final final block.

[0052] Continuing with the above embodiment, specifically, the pre-proposal stage steps: propose a target block in the block set as the block set of the current height, and enter the gathering stage if it meets the voting requirements after broadcasting; the gathering stage steps: the gathering stage is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation stage; the preparation stage steps: after the timeout and broadcast again, if more than two-thirds of the storage providers in the entire network vote, then enter the final stage; the final stage steps: determine the final block of the current height according to the proportion of the number of votes of the storage provider for the target block, and end this round of voting. Here, the F3 module obtains configuration information from the manifest server, creates a new instance, and enters the pre-proposal stage; the pre-proposal stage: propose a tipset as the block set of the current height where the block on the current chain is located, and the storage provider signs the tipset related information and broadcasts it to the network by the node, wherein the tipset related information includes one or more block information, and the block contains block ID, height, parent block ID, message ID, etc. The F3 module receives and verifies the received message. If it times out or more than two-thirds of the storage providers vote, it enters the gathering stage. Aggregation phase: Adjust the phase information, the storage provider signs and the node broadcasts it to the network. Receive and verify the received message. If the waiting timeouts, select the tipset as the final block set of the height according to the rules and enter the preparation phase. Preparation phase: Adjust the phase information, the storage provider signs and the node broadcasts it to the network. Receive and verify the received message. If it times out, broadcast it again. If more than two-thirds of the storage providers in the entire network vote, enter the submission phase. Submission phase: Adjust the phase information, the storage provider signs and the node broadcasts it to the network. Receive and verify the received message. If it times out, broadcast it again. If more than two-thirds of the storage providers in the entire network vote, enter the final phase. Final phase: Adjust the phase information, the storage provider signs and the node broadcasts it to the network. Receive and verify the received message. If more than two-thirds of the storage providers in the entire network vote, the block contained in the tipset is used as the final block of the height, ending this round of voting and moving on to the next round.

[0053] In addition, an embodiment of the present application also provides a computer-readable medium on which computer-readable instructions are stored, and the computer-readable instructions can be executed by a processor to implement the aforementioned method of quickly finalizing blocks based on a consensus algorithm.

[0054] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

[0055] It should be noted that the present application can be implemented in software and / or a combination of software and hardware, for example, can be implemented using an application specific integrated circuit (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software program of the present application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of the present application (including relevant data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the present application can be implemented using hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0056] In addition, a part of the present application may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present application through the operation of the computer. The program instruction for calling the method of the present application may be stored in a fixed or removable recording medium, and / or transmitted through a data stream in a broadcast or other signal-bearing medium, and / or stored in a working memory of a computer device that runs according to the program instruction. Here, according to an embodiment of the present application, a device is included, the device including a memory for storing computer program instructions and a processor for executing program instructions, wherein, when the computer program instruction is executed by the processor, the device is triggered to run the method and / or technical solution based on the aforementioned multiple embodiments according to the present application.

[0057] It is obvious to those skilled in the art that the present application is not limited to the details of the above exemplary embodiments, and that the present application can be implemented in other specific forms without departing from the spirit or basic features of the present application. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-restrictive, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims are included in the present application. Any figure mark in the claims should not be regarded as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

Claims

1. A system for quickly finalizing blocks based on a consensus algorithm, characterized in that: The system includes: a storage provider, a node, a list service and a finality module; wherein, The storage provider is used to register with the node through the rpc interface; The node is used to synchronize the blockchain network, obtain block and message information on the chain, and provide corresponding interfaces to storage providers and finality modules; The inventory service is used to provide the finality module with configuration information of the blockchain network; The finality module includes an integrated consensus algorithm and a terminator, which is used to calculate the block set between the chain head and the terminated block based on the block and message information on the chain and the configuration information, and propose the block in the block set as the final block; the storage provider votes to select the final block.

2. The system according to claim 1, characterized in that The node is used to receive and broadcast relevant information of the finality module, wherein the relevant information includes message information and finalized blocks, and the message information includes messages in the pre-proposal phase, messages in the submission phase, and messages in the finalization phase.

3. The system according to claim 1, characterized in that The storage provider is used to provide signature information and participate in the voting of the finality module proposal to determine the final block.

4. The system according to claim 1, characterized in that The finality module is used to implement the Gossip PBFT consensus algorithm and supports the use of Gossip to receive and publish messages.

5. The system according to claim 4, characterized in that The finality module is used to implement the Gossip PBFT consensus algorithm, including repeating the following stages at each height where the block is located: pre-proposal stage, aggregation stage, preparation stage, submission stage and finalization stage.

6. The system according to claim 5, characterized in that The pre-proposal phase is used to propose a target block in a block set as a block set at the current height. After broadcasting, if it meets the voting requirements, it enters the aggregation phase; The aggregation phase is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation phase; The preparation phase is used to broadcast again after the timeout. If more than two-thirds of the storage providers in the entire network vote, the final phase will begin; The final stage is used to determine the final block at the current height based on the proportion of storage providers' votes for the target block, thus ending this round of voting.

7. A method for quickly finalizing blocks based on a consensus algorithm, characterized in that: The method comprises: The storage provider registers with the node through the RPC interface, and the node synchronizes the blockchain network and obtains the block and message information on the chain; Obtaining configuration information of the blockchain network from the inventory service through a finality module, calculating a block set between the chain head and the finalized block based on the block and message information on the chain and the configuration information, and proposing a block in the block set as a finalized block, wherein the finality module integrates a consensus algorithm; Storage providers vote to select the final block.

8. The method according to claim 7, characterized in that The blocks in the proposed block set are used as final blocks, including: Repeat the steps of the target phase at each height where the block is located, propose the target block in the block set, and determine the final block. The target phase includes the pre-proposal phase, the aggregation phase, the preparation phase, the submission phase, and the final phase.

9. The method according to claim 8, characterized in that Repeat the steps of the target phase at each block height, propose the target block in the block set, and determine the final block, including: Pre-proposal phase steps: propose the target block in the block set as the block set at the current height, and enter the aggregation phase if it meets the voting requirements after broadcasting; Aggregation phase steps: The aggregation phase is used to select the target block as the final block set of the current height after the broadcast timeout, and enter the preparation phase; Preparation phase steps: After the timeout and rebroadcast, if more than two-thirds of the storage providers in the entire network vote, the final phase will begin; Final stage steps: Determine the final block at the current height based on the proportion of storage providers’ votes for the target block, ending this round of voting.

10. A computer-readable medium having computer-readable instructions stored thereon, wherein the computer-readable instructions can be executed by a processor to implement the method according to any one of claims 7 to 9.

Images