CN113836232A - Consensus method and system in alliance chain - Google Patents
Consensus method and system in alliance chain Download PDFInfo
- Publication number
- CN113836232A CN113836232A CN202111122765.9A CN202111122765A CN113836232A CN 113836232 A CN113836232 A CN 113836232A CN 202111122765 A CN202111122765 A CN 202111122765A CN 113836232 A CN113836232 A CN 113836232A
- Authority
- CN
- China
- Prior art keywords
- node
- checkpoint
- common
- alliance chain
- consensus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 59
- 230000002159 abnormal effect Effects 0.000 claims abstract description 19
- 230000000977 initiatory effect Effects 0.000 claims description 10
- 230000008569 process Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 9
- 230000008859 change Effects 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 3
- 238000004140 cleaning Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Multimedia (AREA)
- Data Mining & Analysis (AREA)
- Retry When Errors Occur (AREA)
Abstract
The specification discloses a consensus method and a system in a alliance chain, wherein the method comprises the following steps: when a first common node in a federation chain generates a specified number of blocks, broadcasting a checkpoint message in the federation chain, wherein the checkpoint message is used for indicating that the first common node has generated the specified number of blocks; a second common identification node in the alliance chain receives a checkpoint message sent by the first common identification node; if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within a preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime; and the second common identification node initiates view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second common identification node, wherein f is the maximum number of abnormal common identification nodes allowed in the alliance chain.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and a system for consensus in a federation chain.
Background
Currently, the Practical Byzantine Fault tolerant algorithm (PBFT) mainly includes two parts, namely, a Normal Case Phase and a View Change Phase. The Normal Case Phase part includes several stages, namely request, pre-prepare, commit, and reply, to accomplish consensus. The request and the reply respectively correspond to a transaction request initiated by a client (client) and a transaction execution result returned to the client.
In the prior art, a timer is usually started after a consensus node receives a request sent by a client, and if the client does not receive f +1 requests for the request sent by the client within a preset time period, the view switching operation may be triggered. However, since the request is sent by the client and is a behavior of the client, if the client sends a large number of requests to the consensus node in a short time, the consensus node cannot complete the consensus operation on the request within a preset time period, and thus the view switching operation is triggered.
Disclosure of Invention
The embodiment of the specification provides a consensus method and a consensus system in a alliance chain, which are used for solving the problem that in the existing alliance chain, if a client sends a large number of requests to a consensus node in a short time, the consensus node cannot complete the consensus operation on the requests within a preset time period, and then the view switching operation is triggered.
In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:
in a first aspect, a consensus method in a federation chain is provided, including:
when a first common node in a federation chain generates a specified number of blocks, broadcasting a checkpoint message in the federation chain, wherein the checkpoint message is used for indicating that the first common node has generated the specified number of blocks;
a second common identification node in the alliance chain receives a checkpoint message sent by the first common identification node;
if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within a preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime;
and the second common identification node initiates view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second common identification node, wherein f is the maximum number of abnormal common identification nodes allowed in the alliance chain.
In a second aspect, an alliance chain system is provided, comprising:
the first common node broadcasts a checkpoint message in the alliance chain when generating the specified number of blocks, wherein the checkpoint message is used for indicating that the first common node has generated the specified number of blocks;
the second common identification node receives the checkpoint message sent by the first common identification node, and if the checkpoint message sent by other 2f common identification nodes in the alliance chain is not received within a preset time period, the stable checkpoint state of the second common identification node is determined to be overtime; and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
In a third aspect, a consensus node in a federation chain is provided, including:
the broadcasting module is used for broadcasting a checkpoint message in a alliance chain when generating the blocks with the specified number, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
the receiving module is used for receiving the checkpoint message sent by other common nodes in the alliance chain;
the state determining module is used for determining that the stable checkpoint state is overtime if checkpoint messages sent by other 2f consensus nodes in the alliance chain are not received within a preset time period;
and the view switching module initiates view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum abnormal consensus node number allowed in the alliance chain.
In a fourth aspect, an electronic device is provided, including:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
In a fifth aspect, a computer-readable storage medium is presented, the computer-readable storage medium storing one or more programs that, when executed by an electronic device comprising a plurality of application programs, cause the electronic device to:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
The embodiment of the specification can achieve at least the following technical effects by adopting the technical scheme:
by adopting the consensus method provided by the embodiment of the description, when a first consensus node in a federation chain generates a specified number of blocks, a checkpoint message is broadcasted in the federation chain, and the checkpoint message is used for indicating that the first consensus node has generated the specified number of blocks; a second common identification node in the alliance chain receives a checkpoint message sent by a first common identification node; if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within the preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime; and the second consensus node initiates view switching operation in the alliance chain based on the state checkpoint state overtime of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain. The consensus node counts that checkpoint messages received from other consensus nodes in the alliance chain can be independently used by one thread, so that great pressure on the consensus node at a certain moment can be avoided, and the consensus node can trigger view switching operation in the alliance chain more accurately.
Drawings
The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:
fig. 1 is a schematic flow chart illustrating an implementation of a consensus method in a federation chain according to an embodiment of the present specification.
Fig. 2 is a schematic flow chart of an implementation of an application of the consensus method in a federation chain according to an embodiment of the present specification.
Fig. 3 is a schematic structural diagram of an alliance chain system according to an embodiment of the present disclosure.
Fig. 4 is a schematic structural diagram of a consensus node in a federation chain according to an embodiment of the present specification.
Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.
Detailed Description
In order to make the purpose, technical solutions and advantages of this document more clear, the technical solutions of this specification will be clearly and completely described below with reference to specific embodiments of this specification and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of this document, and not all embodiments. All other embodiments obtained by a person skilled in the art without making any inventive step based on the embodiments in this description belong to the protection scope of this document.
The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.
In the process of consensus by using the PBFT algorithm in the federation chain, each Replica (duplicate, that is, all consensus nodes participating in consensus in the federation chain) records in a Message Log (Message Log) in the memory of the consensus node when sending a Message or receiving messages (including pre-preamble, and commit messages) sent by other consensus nodes. With the continuous progress of the consensus operation in the federation chain, the Message Log of each consensus node in the federation chain occupies a larger and larger memory space, and therefore, in order to save the memory space of each consensus node in the federation chain, garbage collection is required, that is, when each consensus node completes a process (proposal), the Message Log of each consensus node is emptied, and the memory space of each consensus node is released.
A garbage collection method is that each time a certain consensus node in a federation chain executes a process (i.e., each time a block is generated), a broadcast may be sent to other consensus nodes in the federation chain, and for a Message Log that can remove the consensus node, the Message Log may reach a consensus on the whole network, and after receiving the broadcast, each consensus node in the federation chain may also send a broadcast to other consensus nodes in the federation chain, or for a Message Log that can remove the consensus node, the Message Log may reach a consensus on the whole network. If the consensus nodes in the federation chain receive the confirmation of different quantities of the uniform (2f +1) consensus nodes, the consensus nodes can delete the Message records corresponding to 1 prompt (i.e. the newly generated 1 block) in the Message Log of the consensus node.
Another way of garbage disposal is that each time a certain consensus node in the federation chain executes k deals (i.e., each time k blocks are newly generated), a broadcast may be sent to other consensus nodes in the federation chain, and for a Message Log that can remove the consensus node, a broadcast may also be sent to other consensus nodes in the federation chain after each consensus node in the federation chain receives the broadcast, or for a Message Log that can remove the consensus node, a network agreement may be reached. If the consensus nodes in the federation chain receive the confirmation of different quantities of the uniform (2f +1) consensus nodes, the consensus nodes can delete the Message records corresponding to k disposes (namely k newly generated blocks) in the Message Log of the consensus node.
Where k is a Message record corresponding to k proximity messages (i.e., k newly generated blocks) that are indicated by the CHECKPOINT Message in the embodiment of the present specification, and the Message Log on which the consensus node is cleared is the CHECKPOINT Message in the embodiment of the present specification, and the format is < CHECKPOINT, n, d, i >, where n is a sequence number of a minimum block that the consensus node desires to currently retain, d is a Message digest that the consensus node desires to retain, and i is a number of the consensus node that sends the CHECKPOINT Message.
The summary of the checkpoint Message broadcast and sent by the consensus node in the federation chain and the summary of the received checkpoint Message are both recorded in the Message Log of the consensus node. If a common identification node i in a federation chain receives Quorum-1 legal checkpoint messages sent by other different common identification nodes and adds checkpoint messages sent by the common identification node i, the common identification node i reaches the number of Quorum (2f +1) for checkpoint messages of < n, d >, and at this time, the common identification node i can clear Message records (including pre-prefix, commit messages and checkpoint messages corresponding to blocks of which the block numbers are n before) corresponding to all blocks of a Message Log of the common identification node.
The block number n is a current stable checkpoint of the consensus node i, which indicates that the consensus node i has achieved consensus on the execution result of the block before the block number n, and the Message record corresponding to the block with the block number n is further retained in the Message Log of the consensus node i. Because the processing of each consensus node in the alliance chain system is asynchronous, the consensus node with fast consensus message processing may gradually pull the distance from the consensus node with slow consensus message processing, and the speed of message processing may be limited by setting high and low water levels: h + L, where H is a high level, L is a low level, H is a set value, and H generally takes the n value of stable checkpoint. Therefore, the processing speed of the consensus node which is processed quickly can be controlled, and the consensus node waits until stable checkpoint is changed after the n value of the consensus message processed by the consensus node reaches the high water level H.
Therefore, if stable checkpoint is not changed all the time, each consensus node in the federation chain cannot process the next negotiation, and the high and low water levels limiting the speed of message processing do not change any more, which may cause each consensus node in the federation chain to be stalled.
In order to solve the problem, in an embodiment of the present specification, when a first common node in a federation chain generates a specified number of blocks, a checkpoint message is broadcast in the federation chain, where the checkpoint message is used to indicate that the first common node has generated the specified number of blocks; a second common identification node in the alliance chain receives a checkpoint message sent by a first common identification node; if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within the preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime; and the second consensus node initiates view switching operation in the alliance chain based on the state checkpoint state overtime of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain. The common knowledge node in the alliance chain can trigger view switching operation in time after the stable checkpoint state is overtime so as to replace the common knowledge host node in the alliance chain and restart the common knowledge operation, and therefore the situation that all the common knowledge nodes in the alliance chain are not in a stop state is avoided.
In addition, if any request sent by the client to the consensus node in the federation chain can successfully achieve the consensus, the consensus is finally achieved in the federation chain, and the commit message is broadcasted in the whole network, and after the consensus node achieves the consensus for a certain request in the federation chain, the checkpoint message is sent to other nodes, so that garbage collection operation is performed after 2f +1 nodes in the federation chain achieve the consensus for the same request, and the status of the consensus node is changed to be stable checkpoint status.
Based on this, in the embodiment of the present specification, it is considered that each common node in the federation chain can independently serve as a thread to process a checkpoint message, and a stable checkpoint state timeout based on the common node is proposed to trigger a view switching operation in the federation chain.
Specifically, one or more embodiments of the present specification provide an implementation flow diagram of a consensus method in a federation chain, which is shown in fig. 1, and includes:
When the first consensus node generates a specified number of blocks, the purpose of broadcasting the checkpoint Message in the federation chain is to reach an agreement whether the Message Log can be cleared in the whole network.
Optionally, to facilitate determining which blocks in the Message Log correspond to the Message records, the first social node broadcasts a checkpoint Message in the federation chain, including:
and the first common identification node broadcasts a checkpoint message in the alliance chain based on the block number n of the block with the largest sequence number in the blocks with the specified number, wherein the checkpoint message carries the block number n of the block with the largest sequence number in the blocks with the specified number.
The purpose of carrying the block number n of the block with the largest sequence number in the specified number of blocks in the checkpoint Message is to achieve agreement in the whole network on whether the Message record corresponding to the block before the block number n in the Message Log can be cleared.
It should be understood that if the joint identification node receives the Quorum-1 legal checkpoint messages sent by different nodes and adds the checkpoint Message sent by the joint identification node, it indicates that the joint identification node collects checkpoint messages of the Quorum number, and thus can achieve stable checkpoint, and further can perform garbage cleaning on the Message record corresponding to the block before the block number n in the Message Log. Specifically, after the first common node broadcasts the checkpoint message in the federation chain, the method provided in the embodiment of this specification further includes:
when the second common identification node generates the blocks with the designated number, the second common identification node broadcasts a checkpoint message carrying the block number n of the block with the largest sequence number in the blocks with the designated number in the alliance chain, wherein the checkpoint message broadcast by the second common identification node is used for indicating that the second common identification node generates the blocks with the designated number;
the first consensus node receives a checkpoint message sent by the second consensus node;
when the first common node receives checkpoint messages of 2f common nodes in the alliance chain within a preset time period, the first common node clears message records corresponding to blocks before the block with the largest sequence number in the blocks with the specified number in the first common node;
and the first common identification node modifies the state of the first common identification node into stable checkpoint based on the block number n of the block with the largest sequence number in the blocks with the specified number.
Alternatively, the above specified number is a positive integer greater than or equal to 1.
Optionally, a manner of triggering view switching operation provided in this specification embodiment is that, when the specified number is 1, after the first common node modifies the state of the first common node to stable checkpoint, the method provided in this specification embodiment further includes:
the first common identification node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n +1 of other 2f common identification nodes in the alliance chain within a preset time period after the timer is started, the first common identification node determines that the stable checkpoint state of the first common identification node is overtime;
and the first common identification node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common identification node.
When a first common node in the federation chain executes a prompt (that is, when a block is generated), a checkpoint Message can be broadcast to other common nodes in the federation chain, and a checkpoint Message can be broadcast to other common nodes in the federation chain after the checkpoint Message is received by other common nodes in the federation chain, or a checkpoint Message can be broadcast to other common nodes in the federation chain after the checkpoint Message is received by other common nodes in the federation chain. If the first common node in the federation chain receives the confirmation of the different common nodes with the quantity of Quorum (2f +1) in the preset time period, the first common node can modify the state of the common node into stable checkpoint. At this time, the first common node in the federation chain may restart the timer, and if the first common node does not receive a checkpoint message carrying an area block number n +1 from other 2f common nodes in the federation chain within a preset time period after the timer is started, the first common node determines that its stable checkpoint state is overtime, and may trigger a view switching operation in the federation chain based on the state checkpoint state being overtime.
Optionally, another manner of triggering view switching operation provided in this embodiment of the present specification is that, when the specified number is a positive integer k greater than 1, after the first common node modifies the state of the first common node to stable checkpoint, the method further includes:
the first common identification node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n + k from other 2f common identification nodes in the alliance chain within a preset time period after the timer is started, the first common identification node determines that the stable checkpoint state of the first common identification node is overtime;
and the first common identification node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common identification node.
When a first common node in the federation chain executes k points (that is, when k blocks are generated), a checkpoint Message can be broadcast to other common nodes in the federation chain, and a Message Log for clearing the common node can be agreed in the whole network, and after receiving the checkpoint Message, other common nodes in the federation chain can also broadcast the checkpoint Message to other common nodes in the federation chain, or the Message Log for clearing the common node can be agreed in the whole network. If the first common node in the federation chain receives the confirmation of the different common nodes with the quantity of Quorum (2f +1) in the preset time period, the first common node can modify the state of the common node into stable checkpoint. At this time, the first common node in the federation chain may restart the timer, and if the first common node does not receive a checkpoint message carrying an n + k block number from other 2f common nodes in the federation chain within a preset time period after the timer is started, the first common node determines that its stable checkpoint state is overtime, and may trigger a view switching operation in the federation chain based on the state checkpoint state being overtime.
When the second common node in the federation chain generates the specified number of blocks, a checkpoint message may also be broadcast in the federation chain, where the checkpoint message is used to indicate that the second common node has generated the specified number of blocks. The second common identification node broadcasts the checkpoint message in the federation chain, and meanwhile receives checkpoint messages sent by other common identification nodes in the federation chain, such as the first common identification node.
And the duration of the preset time period is the overtime duration triggered by a timer locally set by the second consensus node. If the second consensus node does not receive checkpoint messages sent by other 2f consensus nodes in the alliance chain within a preset time period, the second consensus node cannot collect checkpoint messages with the quantity of the Quorum, and thus stable checkpoint cannot be achieved, and further garbage cleaning operation cannot be performed on the Message Log in the consensus node. In the embodiment of the present specification, a state in which the consensus node cannot achieve stable checkpoint is referred to as a stable checkpoint state timeout.
When the state of the stable checkpoint of the second common node is overtime, that is, it indicates that the stable checkpoint of the second common node cannot be updated, that is, it indicates that the second common node cannot continue to perform a common checkpoint operation on a proxy, at this time, in order to change such a situation, the second common node may initiate a view switching operation in the federation chain based on the overtime of its local state, so as to try to change the common checkpoint node in the federation chain.
It should be noted that the consensus algorithm in the embodiment of the present specification may be applicable to a RAFT algorithm, a consensus algorithm capable of distinguishing a consensus primary node from a consensus backup node, and the like, in addition to the PBFT algorithm. The embodiment of the present specification does not specifically limit the employed consensus algorithm, as long as the employed consensus algorithm has a consensus master node.
The consensus method provided by the embodiments of the present specification is described in detail below with a schematic process diagram of fig. 2, which illustrates a consensus operation performed by using a PBFT algorithm. In fig. 2, C is a client, the consensus node 0 is a consensus master node in the process of the consensus operation, and the consensus nodes 1 to 3 are consensus backup nodes in the process of the consensus operation. The schematic diagram shown in fig. 2 includes the following cases:
in the first case, the consensus node 0 is a rogue node, and the consensus node 0 spoofs the consensus node 1 and the consensus node 2 to perform a consensus operation on the message m requesting consensus from the client (solid line portion shown in fig. 2), while the consensus node 0 itself and the consensus node 3 do not perform the consensus operation on the message m requesting consensus from the client (dotted line portion shown in fig. 2). Even if the consensus node 0 continuously acts badly, as the message m is continuously processed, on one hand, the consensus node 3 does not execute any consensus operation, and a local timer thereof is overtime after a set time period, so that the view switching operation is triggered in the federation chain; on the other hand, although the common node 1 and the common node 2 perform the common operation on m, the common node 1 and the common node 2 reach checkpoint after performing the common operation on m, so that checkpoint messages are broadcast in the federation chain, but since the common node 0 and the common node 3 do not perform the common operation on m, checkpoint cannot be reached, and checkpoint messages are not broadcast in the federation chain, so that the common node 1 and the common node 2 cannot collect checkpoint messages in quantities equal to qurum, and thus stable checkpoint cannot be reached, further, the common node 1 and the common node 2 do not continue to perform after reaching a high level, and local timers of the common node 1 and the common node 2 also timeout after a set time period, thereby triggering view switching operation.
In the second case, if the consensus node 0 continues to act badly as in the first case, the timer local to the consensus node 3 will also time out, thereby initiating a view switching operation in the federation chain; meanwhile, in the first situation, the common node 1 and the common node 2 cannot achieve stable checkpoint, that is, the state of the stable checkpoint is overtime, so that the common node 1 and the common node 2 can also trigger view switching operation in a federation chain, and further can achieve view switching operation of the number of qualum, thereby completing owner switching.
In the third case, in the alliance-link network, each time a certain consensus node generates a block, a blocked message can be broadcast to other consensus nodes through the P2P protocol, and the consensus node receiving the broadcast blocked message, such as the consensus node 3 in fig. 2, finds that the block height in the block message is higher than the highest block height of its own local part, and synchronizes the latest block from the consensus node 1 or the consensus node 2 (the block already has 2f +1 signatures, and can be pushed or pulled from the consensus node 1 or the consensus node 2, regardless of the block height of the consensus node 0), so as to keep synchronization with the consensus node 1 or the consensus node 2.
By adopting the consensus method provided by the embodiment of the description, when a first consensus node in a federation chain generates a specified number of blocks, a checkpoint message is broadcasted in the federation chain, and the checkpoint message is used for indicating that the first consensus node has generated the specified number of blocks; a second common identification node in the alliance chain receives a checkpoint message sent by a first common identification node; if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within the preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime; and the second consensus node initiates view switching operation in the alliance chain based on the state checkpoint state overtime of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain. The consensus node counts that checkpoint messages received from other consensus nodes in the alliance chain can be independently used by one thread, so that great pressure on the consensus node at a certain moment can be avoided, and the consensus node can trigger view switching operation in the alliance chain more accurately.
Fig. 3 is a schematic structural diagram of a federation chain system 300 provided in an embodiment of the present specification. Referring to fig. 3, in one software implementation, a federation chain system 300 may include a first consensus node 310 and a second consensus node 320, wherein:
a first common node 310, which broadcasts a checkpoint message in the federation chain when a specified number of blocks are generated, where the checkpoint message is used to indicate that the first common node has generated the specified number of blocks;
the second common node 320 receives the checkpoint message sent by the first common node, and determines that the stable checkpoint state of the second common node is overtime if the checkpoint message sent by other 2f common nodes in the federation chain is not received within a preset time period; and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
Optionally, in an embodiment, the first common node 310 is configured to:
and broadcasting a checkpoint message in the alliance chain based on the block number n of the block with the largest sequence number in the specified number of blocks, wherein the checkpoint message carries the block number n of the block with the largest sequence number in the specified number of blocks.
Optionally, in an embodiment, after the first common node broadcasts a checkpoint message in the federation chain,
when the second common identification node generates the specified number of blocks, the second common identification node broadcasts a checkpoint message carrying a block number n of a block with a largest sequence number in the specified number of blocks in the federation chain, and the checkpoint message broadcast by the second common identification node is used for indicating that the second common identification node has generated the specified number of blocks;
the first common identification node receives a checkpoint message sent by the second common identification node;
when the first common node receives checkpoint messages of 2f common nodes in the alliance chain within the preset time period, the first common node clears message records corresponding to blocks before the block with the largest sequence number in the specified number of blocks in the first common node;
and the first common node modifies the state of the first common node into stable checkpoint based on the block number n of the block with the largest sequence number in the specified number of blocks.
Optionally, in one embodiment, the specified number is a positive integer greater than or equal to 1.
Optionally, in an implementation manner, when the specified number is 1, after the first common node modifies the state of the first common node to stable checkpoint, the method further includes:
the first common node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n +1 from other 2f common identification nodes in the alliance chain within the preset time period after the timer is started, the first common identification node determines that a stable checkpoint state of the first common identification node is overtime;
and the first common node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common node.
Optionally, in an implementation manner, when the specified number is a positive integer k greater than 1, after the first common node modifies the state of the first common node to stable checkpoint, the method further includes:
the first common node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n + k from other 2f common identification nodes in the alliance chain within the preset time period after the timer is started, the first common identification node determines that a stable checkpoint state of the first common identification node is overtime;
and the first common node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common node.
Optionally, in an embodiment, the first common node is any one common node in the federation chain;
the second consensus node is any one of the consensus nodes in the alliance chain.
The federation chain system 300 can implement the method of the embodiment of the method in fig. 1 to fig. 2, and specifically refer to the consensus method in the federation chain of the embodiment shown in fig. 1 to fig. 2, which is not described again.
Fig. 4 is a schematic structural diagram of a consensus node 400 in a federation chain according to an embodiment of the present specification, including:
a broadcasting module 410, configured to broadcast a checkpoint message in a federation chain when a specified number of blocks are generated, where the checkpoint message is used to indicate that the specified number of blocks have been generated;
a receiving module 420, configured to receive a checkpoint message sent by another node in the federation chain;
the state determining module 430 determines that a stable checkpoint state is overtime if checkpoint messages sent by other 2f consensus nodes in the federation chain are not received within a preset time period;
and the view switching module 440 initiates a view switching operation in the federation chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the federation chain.
Optionally, in an embodiment, the broadcasting module 410 is configured to:
and broadcasting a checkpoint message in the alliance chain based on the block number n of the block with the largest sequence number in the specified number of blocks, wherein the checkpoint message carries the block number n of the block with the largest sequence number in the specified number of blocks.
Optionally, in an embodiment, the state determining module 430 is further configured to:
when checkpoint messages of 2f common identification nodes in the alliance chain are received in the preset time period, message records corresponding to blocks before the block with the largest sequence number in the specified number of blocks in the common identification nodes are cleared;
and modifying the state of the common node into stable checkpoint based on the block number n of the block with the largest sequence number in the specified number of blocks.
Optionally, in one embodiment, the specified number is a positive integer greater than or equal to 1.
Optionally, in an implementation manner, when the specified number is 1, after the state determining module 430 modifies the state of the common node to stable checkpoint, the view switching module 440 is further configured to:
starting a timer;
if the checkpoint message carrying the block number n +1 of other 2f common identification nodes in the alliance chain is not received within the preset time period after the timer is started, determining that the stable checkpoint state of the common identification node is overtime;
and triggering view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the common node.
Optionally, in an embodiment, when the specified number is a positive integer k greater than 1, after the state determining module 430 modifies the state of the present consensus node to be stable checkpoint, the view switching module 440 is further configured to:
starting a timer;
if the checkpoint message carrying the block number n + k of other 2f common identification nodes in the alliance chain is not received within the preset time period after the timer is started, determining that the stable checkpoint state of the common identification node is overtime;
and triggering view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the common node.
Optionally, in an embodiment, the consensus node 400 in the federation chain is any one of the consensus nodes in the federation chain.
The consensus node 400 in the federation chain can implement the method in the embodiment of the method in fig. 1, which may specifically refer to the consensus method in the federation chain in the embodiment shown in fig. 1 and is not described again.
Fig. 5 is a schematic structural diagram of an electronic device provided in an embodiment of the present specification. Referring to fig. 5, at a hardware level, the electronic device includes a processor, and optionally further includes an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory, such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, the network interface, and the memory may be connected to each other via an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 5, but this does not indicate only one bus or one type of bus.
And the memory is used for storing programs. In particular, the program may include program code comprising computer operating instructions. The memory may include both memory and non-volatile storage and provides instructions and data to the processor.
The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to form a block chain system deployed by a common node in the alliance chain on a logic level. The processor is used for executing the program stored in the memory and is specifically used for executing the following operations:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
The above-described consensus method in the federation chain as disclosed in the embodiment shown in FIG. 1 of this specification can be applied to or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in one or more embodiments of the present specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with one or more embodiments of the present disclosure may be embodied directly in hardware, in a software module executed by a hardware decoding processor, or in a combination of the hardware and software modules executed by a hardware decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.
The electronic device may also perform the consensus method in the federation chain of fig. 1, which is not described herein again.
Of course, besides the software implementation, the electronic device in this specification does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
This specification embodiment also proposes a computer-readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a portable electronic device comprising a plurality of application programs, are capable of causing the portable electronic device to perform the method of the embodiment shown in fig. 5, and in particular to perform the following operations:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
In short, the above description is only a preferred embodiment of the present disclosure, and is not intended to limit the scope of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of the present disclosure should be included in the scope of protection of one or more embodiments of the present disclosure.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
Claims (11)
1. A method of consensus in a federation chain, comprising:
when a first common node in a federation chain generates a specified number of blocks, broadcasting a checkpoint message in the federation chain, wherein the checkpoint message is used for indicating that the first common node has generated the specified number of blocks;
a second common identification node in the alliance chain receives a checkpoint message sent by the first common identification node;
if the second common identification node does not receive the checkpoint message sent by other 2f common identification nodes in the alliance chain within a preset time period, the second common identification node determines that the stable checkpoint state of the second common identification node is overtime;
and the second common identification node initiates view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the second common identification node, wherein f is the maximum number of abnormal common identification nodes allowed in the alliance chain.
2. The method of claim 1, wherein the first common node broadcasts a checkpoint message in the federation chain, comprising:
and the first common node broadcasts a checkpoint message in the alliance chain based on the block number n of the block with the largest sequence number in the specified number of blocks, wherein the checkpoint message carries the block number n of the block with the largest sequence number in the specified number of blocks.
3. The method of claim 2, after the first common identity node broadcasts a checkpoint message in the federation chain, the method further comprising:
when the second common identification node generates the specified number of blocks, the second common identification node broadcasts a checkpoint message carrying a block number n of a block with a largest sequence number in the specified number of blocks in the federation chain, and the checkpoint message broadcast by the second common identification node is used for indicating that the second common identification node has generated the specified number of blocks;
the first common identification node receives a checkpoint message sent by the second common identification node;
when the first common node receives checkpoint messages of 2f common nodes in the alliance chain within the preset time period, the first common node clears message records corresponding to blocks before the block with the largest sequence number in the specified number of blocks in the first common node;
and the first common node modifies the state of the first common node into stable checkpoint based on the block number n of the block with the largest sequence number in the specified number of blocks.
4. The method of claim 3, wherein the specified number is a positive integer greater than or equal to 1.
5. The method according to claim 4, when the specified number is 1, after the first common node modifies the state of the first common node to stable checkpoint, the method further comprising:
the first common node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n +1 from other 2f common identification nodes in the alliance chain within the preset time period after the timer is started, the first common identification node determines that a stable checkpoint state of the first common identification node is overtime;
and the first common node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common node.
6. The method according to claim 4, when the specified number is a positive integer k greater than 1, after the first common node modifies the state of the first common node to stable checkpoint, the method further comprising:
the first common node starts a timer;
if the first common identification node does not receive a checkpoint message carrying a block number n + k from other 2f common identification nodes in the alliance chain within the preset time period after the timer is started, the first common identification node determines that a stable checkpoint state of the first common identification node is overtime;
and the first common node triggers view switching operation in the alliance chain based on the timeout of the stable checkpoint state of the first common node.
7. The method according to claim 1 to 6,
the first consensus node is any one of the consensus nodes in the alliance chain;
the second consensus node is any one of the consensus nodes in the alliance chain.
8. An alliance chain system comprising:
the first common node broadcasts a checkpoint message in the alliance chain when generating the specified number of blocks, wherein the checkpoint message is used for indicating that the first common node has generated the specified number of blocks;
the second common identification node receives the checkpoint message sent by the first common identification node, and if the checkpoint message sent by other 2f common identification nodes in the alliance chain is not received within a preset time period, the stable checkpoint state of the second common identification node is determined to be overtime; and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint of the second consensus node, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
9. A consensus node in a federation chain, comprising:
the broadcasting module is used for broadcasting a checkpoint message in a alliance chain when generating the blocks with the specified number, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
the receiving module is used for receiving the checkpoint message sent by other common nodes in the alliance chain;
the state determining module is used for determining that the stable checkpoint state is overtime if checkpoint messages sent by other 2f consensus nodes in the alliance chain are not received within a preset time period;
and the view switching module initiates view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum abnormal consensus node number allowed in the alliance chain.
10. An electronic device, comprising:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
11. A computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to:
when generating the blocks with the specified number, broadcasting a checkpoint message in a federation chain, wherein the checkpoint message is used for indicating that the blocks with the specified number are generated;
receiving a checkpoint message sent by other consensus nodes in the alliance chain;
if the checkpoint message sent by other 2f consensus nodes in the alliance chain is not received within a preset time period, determining that a stable checkpoint state is overtime;
and initiating view switching operation in the alliance chain based on the state timeout of the stable checkpoint, wherein f is the maximum number of abnormal consensus nodes allowed in the alliance chain.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111122765.9A CN113836232A (en) | 2021-09-24 | 2021-09-24 | Consensus method and system in alliance chain |
| PCT/CN2022/109829 WO2023045574A1 (en) | 2021-09-24 | 2022-08-03 | Consensus in consortium blockchain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111122765.9A CN113836232A (en) | 2021-09-24 | 2021-09-24 | Consensus method and system in alliance chain |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113836232A true CN113836232A (en) | 2021-12-24 |
Family
ID=78970015
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111122765.9A Pending CN113836232A (en) | 2021-09-24 | 2021-09-24 | Consensus method and system in alliance chain |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113836232A (en) |
| WO (1) | WO2023045574A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023045574A1 (en) * | 2021-09-24 | 2023-03-30 | 蚂蚁区块链科技(上海)有限公司 | Consensus in consortium blockchain |
| WO2023160086A1 (en) * | 2022-02-24 | 2023-08-31 | 蚂蚁区块链科技(上海)有限公司 | Transaction processing method of blockchain, blockchain node, and electronic device |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN111526216A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in alliance chain |
| CN111865608A (en) * | 2020-07-02 | 2020-10-30 | 南京邮电大学 | Consensus mechanism operation method applied to alliance chain |
| CN112929186A (en) * | 2021-02-22 | 2021-06-08 | 北京航空航天大学 | Alliance chain consensus optimization method based on communication mode structure |
| CN112988470A (en) * | 2021-04-27 | 2021-06-18 | 支付宝(杭州)信息技术有限公司 | Consensus method, consensus node and system in alliance chain |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10523421B2 (en) * | 2016-11-30 | 2019-12-31 | International Business Machines Corporation | Checkpoints for permissionless blockchains |
| CN111555858B (en) * | 2020-03-20 | 2021-11-26 | 北京邮电大学 | Practical Byzantine fault-tolerant consensus method based on block chain type storage |
| CN111612455A (en) * | 2020-04-21 | 2020-09-01 | 国网江苏省电力有限公司电力科学研究院 | Power consumption information protection-oriented Byzantine fault-tolerant alliance chain consensus method, system and storage medium |
| CN113360567A (en) * | 2021-04-29 | 2021-09-07 | 广西电网有限责任公司 | Safe storage method and application of electric power transaction distributed account book based on block chain |
| CN113836232A (en) * | 2021-09-24 | 2021-12-24 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in alliance chain |
-
2021
- 2021-09-24 CN CN202111122765.9A patent/CN113836232A/en active Pending
-
2022
- 2022-08-03 WO PCT/CN2022/109829 patent/WO2023045574A1/en unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN111865608A (en) * | 2020-07-02 | 2020-10-30 | 南京邮电大学 | Consensus mechanism operation method applied to alliance chain |
| CN111526216A (en) * | 2020-07-03 | 2020-08-11 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in alliance chain |
| CN112929186A (en) * | 2021-02-22 | 2021-06-08 | 北京航空航天大学 | Alliance chain consensus optimization method based on communication mode structure |
| CN112988470A (en) * | 2021-04-27 | 2021-06-18 | 支付宝(杭州)信息技术有限公司 | Consensus method, consensus node and system in alliance chain |
Non-Patent Citations (4)
| Title |
|---|
| 包振山;王凯旋;张文博;: "基于树形拓扑网络的实用拜占庭容错共识算法", 应用科学学报, no. 01, 30 January 2020 (2020-01-30) * |
| 王群;李馥娟;王振力;梁广俊;徐杰;: "区块链原理及关键技术", 计算机科学与探索, no. 10, 21 July 2020 (2020-07-21) * |
| 韩镇阳;宫宁生;任珈民;: "一种区块链实用拜占庭容错算法的改进", 计算机应用与软件, no. 02, 12 February 2020 (2020-02-12) * |
| 黄秋波;安庆文;苏厚勤;: "一种改进PBFT算法作为以太坊共识机制的研究与实现", 计算机应用与软件, no. 10, 15 October 2017 (2017-10-15) * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023045574A1 (en) * | 2021-09-24 | 2023-03-30 | 蚂蚁区块链科技(上海)有限公司 | Consensus in consortium blockchain |
| WO2023160086A1 (en) * | 2022-02-24 | 2023-08-31 | 蚂蚁区块链科技(上海)有限公司 | Transaction processing method of blockchain, blockchain node, and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023045574A1 (en) | 2023-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107391320B (en) | Consensus method and device | |
| EP3547648B1 (en) | Service processing and consensus method and device | |
| CN108648078B (en) | Transaction preprocessing method and device and electronic equipment | |
| CN110659988B (en) | Parallel processing method and device for block chain consensus and execution and electronic equipment | |
| CN113836232A (en) | Consensus method and system in alliance chain | |
| CN109474682B (en) | Block chain network transmission method and device and electronic equipment | |
| CN110020859B (en) | Parallel execution block chain consensus method and device and electronic equipment | |
| CN111104664B (en) | Risk identification method of electronic equipment and server | |
| CN110708163B (en) | Block chain consensus method, device and system and electronic equipment | |
| CN107040576B (en) | Information pushing method and device and communication system | |
| EP3934163A1 (en) | Methods and consensus nodes for block generation | |
| CN112988470B (en) | Consensus method, consensus node and system in alliance chain | |
| CN112463318B (en) | Timing task processing method, device and system | |
| CN116170870A (en) | Network registration method and device, storage medium and electronic equipment | |
| CN112887436B (en) | Consensus method, consensus node and block chain system of pipeline mode | |
| CN108829498B (en) | Service data access method and device | |
| CN114564450A (en) | Processing method, device, system, medium and equipment of distributed file system | |
| CN111190709A (en) | Method and device for processing request, electronic equipment and readable storage medium | |
| CN110675148A (en) | Synchronization method and system for verification node set and electronic equipment | |
| CN112991067B (en) | Block chain consensus method, device and system | |
| CN110321384B (en) | Block chain-based data recording method and device and electronic equipment | |
| CN111708780B (en) | Distributed form system, partition master selection method, device, server and medium | |
| CN112988469B (en) | State backup method and device in alliance chain and electronic equipment | |
| CN110599139B (en) | Block output method and device in block chain consensus algorithm | |
| CN110535785B (en) | Control method and device for sending frequency and distributed system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |