CN112187866A - Novel block chain consensus method based on shared storage - Google Patents
Novel block chain consensus method based on shared storage Download PDFInfo
- Publication number
- CN112187866A CN112187866A CN202010912929.7A CN202010912929A CN112187866A CN 112187866 A CN112187866 A CN 112187866A CN 202010912929 A CN202010912929 A CN 202010912929A CN 112187866 A CN112187866 A CN 112187866A
- Authority
- CN
- China
- Prior art keywords
- nodes
- node
- block
- validator
- leader
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
Abstract
The invention discloses a novel block chain consensus method based on shared storage, which comprises the following steps: s1, leader election stage: selecting a unique leader node from the validator nodes through mutual exclusion based on shared storage; s2, block generation: generating a corresponding new block by the leader node generated in the election stage, and informing other validators to carry out verification and viewing the result generated in the verification stage by the leader node; s3, block verification stage: verifying the new block by a validator node in the system; s4, block chain updating stage: the leger node and the validator node in the system access the verification information to determine whether to update the local block chain, so as to achieve consensus. The method has the advantages that the shared storage mode replaces the traditional P2P communication mode, the unique leger node is selected through the mutual exclusion algorithm, the number of information transmission times can be reduced, resource waste caused by selection of the master node of the block chain is avoided, and the whole block chain network is identified at low cost.
Description
Technical Field
The invention belongs to the field of block chain consensus, and particularly relates to a consensus method in a block chain introducing a shared storage mode.
Background
Currently, the mainstream consensus algorithms applied in block chains include Proof of workload (Proof of Work), Proof of rights and interests (Proof of stamp), Proof of authorized rights and interests (relieved Proof of stamp), and Practical Byzantine Fault-tolerant algorithm (Practical Byzantine Fault Tolerance).
The workload certification mechanism (PoW) is a consensus algorithm used in bitcoin networks, which is proposed by the Chinese smarter, and the idea can be summarized as the effort used to certify the effort by working to obtain a specified effort. The consensus process is that the node searches for a random number meeting the requirement by virtue of the Hash calculation capacity of the node, once the Nonce meeting the requirement is found, the node broadcasts the result to the network, other nodes verify whether the received random number meets the difficulty requirement, if yes, the broadcast node is proved to have done a proper amount of work, namely Hash operation, other nodes stop competing the accounting right of the block, and then the node continues to perform Hash operation to continue competing the accounting right of the next block. But the method has the defects of serious waste of resources such as electric power and the like, dependence on professional mining hardware resources, centralized calculation among a plurality of mines, centralized risk, low efficiency and small transaction throughput.
The equity proving algorithm (PoS) was proposed on the basis of summarizing the deficiencies of the workload proving algorithm, of which the Casper protocol led by Vlad and vitarik to make internal disorder or usurp is a representative equity proving mechanism. The right certificate is used for determining who the next block in the block chain is constructed according to the right owned by the user, and the probability of generating one block by the user is positively correlated with the right owned by the user in the block chain. Rather than requiring the investment in a chain of computing power extension blocks, the mechanism relies on their interest in the system. The consensus process of the block chain is considered to be similar to the process of election by a leader, and the equity proving algorithm fundamentally replaces the equity of calculation power owned by nodes in most workload proving by the equity of system token tokens, so that a large amount of calculation power resource waste is avoided, but the problem of 'no harm relation' exists, and the system stability is not facilitated.
The authorization rights attestation algorithm (DPoS) was proposed by Bitshares in an attempt to solve the problems with PoW and PoS, similar to the voting mechanism of board of directors. The witness concept is introduced, and the main difference with the rights-proving algorithm is that the witness is not created by the process of consensus on all the persons who have the rights to the system, but instead all the nodes who have the rights to choose the first N nodes (N is usually 101) as witnesses. Therefore, its advantages can be summarized as improving the consensus efficiency by reducing the number of nodes participating in the core consensus process, but at the same time, the realization of decentralization is controversial due to the reduction of the number of core nodes.
Practical Byzantine fault tolerant algorithms (PBFT) were proposed by Miguel Castro (Carlsterol) and Barbara Liskov (Rickov) in 1999. Currently, the Byzantine protocol can be embedded into widely used distributed storage systems such as HDFS, Zookeeper and the like. The algorithm orders the requests through the master node, the slave nodes respond to the requests, and the response results of a plurality of nodes finally reach consensus. The PBFT algorithm has the advantages of high consistency and accuracy of consensus results, and has the defects of high algorithm complexity, large communication traffic and low operation efficiency when the number of nodes is excessive.
At present, the mainstream block chains all adopt a point-to-point information transmission model. Point-to-point transmission is also called "peer-to-peer network". Conventional centralized network systems require the center to provide powerful, stable servers and sufficient bandwidth to support client node usage. Through the P2P network, the blockchain system can achieve the purposes of quickly synchronizing data and realizing the consistency of a consensus mechanism without a central server. However, the current P2P network model has the problem of complicated information interaction, which is not favorable for the development of system extensibility.
In summary, the current research work on the blockchain consensus algorithm has advanced to some extent. Researches find that the block chain consensus algorithm can realize consistency under the decentralized condition, but the block chain consensus algorithm has the characteristics of high throughput, short consensus time and good fault-tolerant performance. Therefore, how to optimize or design a novel consensus algorithm has become the key of the blockchain consensus research.
Disclosure of Invention
In order to solve the technical problems, the invention provides a novel block chain consensus method based on shared storage, which realizes consensus through a shared storage communication model and a mutual exclusion mechanism, increases the fault tolerance of a system, reduces the frequency of system information exchange, improves the consensus efficiency and reduces the consensus cost.
In order to achieve the purpose, the technical scheme of the invention is as follows:
a novel block chain consensus method based on shared storage comprises the following steps:
s1, leader election stage: selecting a unique leader node from the validator nodes through mutual exclusion based on shared storage;
s2, block generation: generating a corresponding new block by the leader node generated in the election stage, and informing other validators to carry out verification and viewing the result generated in the verification stage by the leader node;
s3, block verification stage: verifying the new block by a validator node in the system;
s4, block chain updating stage: the leger node and the validator node in the system access the verification information to determine whether to update the local block chain, so as to achieve consensus.
In the above scheme, the step S1 specifically includes the following steps:
s11, if the jiionList in the id corresponding to the validator node is true, the validator node is shown to participate in competition with the leader node, and if the jiionList is not met, the validator node does not participate in the competition, and no processing is performed;
s12, if the competition-participating validator nodes find that the variable K is different from the id of the nodes, setting the mutexList corresponding to the id of the nodes as false, wherein if the validator nodes with the id being equal to K do not have the competition intention, i.e. the joinlist [ K ] ═ false, the validator nodes assign the id of the nodes to the K;
s13, if the competition-participating validator nodes find that the variable K is the same as the id of the nodes, setting the mutex List corresponding to the id of the nodes as the tube, and finishing the circulation when only the nodes serving as the only validator nodes with the mutex List value as the tube in the system are waited, namely in the leader election stage, the validator nodes become leader nodes and the selection of the leader nodes is finished.
In a further technical scheme, the step S2 specifically includes the following steps:
s21, a trander node in the system sends transaction data to a transaction pool, and a leader node collects the transaction data and packs blocks;
s22, writing the packaged block to a shared area of the block;
and S23, after the blocks are packed, the leader node sends information of block creation completion to all validator nodes and leger nodes and informs other nodes of access to the shared area.
In a further technical scheme, the step S3 specifically includes the following steps:
s31, after receiving a block creation success message sent by a leader node in the current round, a validator node in the system accesses a generated block and verifies whether the block generated by the leader node in the current round is correct, if the block generated in the current round is correct, validatlist [ id ] is set as tube, and if not, the valid is set as false;
and S32, after receiving the block creation success message sent by the leader node in the current round, the hedgehog node in the system accesses the shared area of the block to prepare for the block chain updating stage.
In a further technical solution, the step S4 specifically includes the following steps:
s41, for the leger node and the validator node, accessing a joinList array for recording participation of the validator node in the current round of competition and a validatreList array for a block verification result, if more than half of data recorded by approved leader nodes exist in the validator node participating in the current round, updating a local account book, otherwise, the data is invalid and is not updated;
s42, for the validator nodes meeting the condition that id is K, namely leader nodes, mutually exclusive variables mutexList and participatory variables joinList are required to be released additionally, and conditions are provided for selection of a new round of leader nodes;
s43, releasing the validateList arrays corresponding to all the ids, namely assigning null to the corresponding validateList, and providing conditions for the verification of the next round of blocks.
Further, the number of validators nodes is in a linear relation with the information interaction quantity.
Advantageous effects
Through the technical scheme, compared with the prior art, the novel block chain consensus method based on shared storage provided by the invention has the following technical characteristics and effects:
(1) the invention considers the problem of complex information interaction of the traditional P2P network model, and is not beneficial to the development of the expandability of the system. By applying a shared storage message passing mode to replace the traditional P2P mode, the conversion of the information interaction quantity from a square level to a linear level is realized, namely O (n)2) Transition to O (n).
(2) The invention selects the only leader miner node by mutual exclusion, thereby ensuring the uniqueness of the account book in the block chain network, avoiding the branching of the link, and introducing mutual exclusion competition to avoid the problem of resource waste caused by the traditional competition such as PoW and PoS.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below.
Fig. 1 is a schematic diagram illustrating a phase of a novel block chain consensus method based on shared memory according to an embodiment of the present invention;
fig. 2 is a schematic specific flowchart of a novel block chain consensus method based on shared storage according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a P2P network model four-node interaction;
fig. 4 is a schematic diagram of a four-node interaction in the present application.
Detailed Description
The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.
The invention provides a novel block chain consensus method based on shared storage, as shown in fig. 1, the method introduces a shared storage message transmission mode and a mutual exclusion competition mechanism, has the characteristics of large throughput, short consensus time and good fault tolerance, provides a new idea for the node consensus problem in a block chain network, and avoids the bifurcation problem and the resource waste problem in the block chain network to a certain extent.
As shown in fig. 2, the specific embodiment is as follows:
a novel block chain consensus method based on shared storage comprises the following steps:
s1, leader election stage:
s11, if the jiionList in the id corresponding to the validator node is true, the validator node is shown to participate in competition with the leader node, and if the jiionList is not met, the validator node does not participate in the competition, and no processing is performed;
s12, if the competition-participating validator nodes find that the variable K is different from the id of the nodes, setting the mutexList corresponding to the id of the nodes as false, wherein if the validator nodes with the id being equal to K do not have the competition intention, i.e. the joinlist [ K ] ═ false, the validator nodes assign the id of the nodes to the K;
s13, if the competition-participating validator nodes find that the variable K is the same as the id of the nodes, setting the mutex List corresponding to the id of the nodes as the tube, and finishing the circulation when only the nodes serving as the only validator nodes with the mutex List value as the tube in the system are waited, namely in the leader election stage, the validator nodes become leader nodes and the selection of the leader nodes is finished.
S2, block proposing stage:
s21, a trander node in the system sends transaction data to a transaction pool, and a leader node collects the transaction data and packs blocks;
s22, writing the packaged block to a shared area of the block;
and S23, after the blocks are packed, the leader node sends information of block creation completion to all validator nodes and leger nodes and informs other nodes of access to the shared area.
S3, block verification stage:
s31, after receiving a block creation success message sent by a leader node in the current round, a validator node in the system accesses a generated block and verifies whether the block generated by the leader node in the current round is correct, if the block generated in the current round is correct, validatlist [ id ] is set as tube, and if not, the valid is set as false;
and S32, after receiving the block creation success message sent by the leader node in the current round, the hedgehog node in the system accesses the shared area of the block to prepare for the block chain updating stage.
S4, block chain updating stage:
s41, for the leger node and the validator node, accessing a joinList array for recording participation of the validator node in the current round of competition and a validatreList array for a block verification result, if more than half of nodes in the validator node participating in the competition in the current round approve data recorded by the leader node, updating a local account book, otherwise, the data is invalid and is not updated;
s42, for the validator nodes meeting the condition that id is K, namely leader nodes, mutually exclusive variables mutexList and participatory variables joinList are required to be released additionally, and conditions are provided for selection of a new round of leader nodes;
s43, releasing the validateList arrays corresponding to all the ids, namely assigning null to the corresponding validateList, and providing conditions for the verification of the next round of blocks.
The following compares the number of information interactions when the number of validators changes with the conventional P2P network model data as shown in table 1:
table 1 comparison of the present application with conventional P2P network model data
As can be seen from Table 1, the number of validators and the information interaction amount are in a linear relation, the number of validators is the same as the information interaction amount, the interaction times are far less than that of a P2P network model along with the increase of the number of nodes, and the aging is effectively improved.
Referring to fig. 3-4, taking four validator nodes abcd as an example, the fault tolerance rate of the peer-to-peer transmission model is 1/3 in the presence of byzantine nodes, while the fault tolerance rate of the peer-to-peer transmission model is 1/2 in the presence of byzantine nodes based on the shared storage transmission model. The nodes in the model access the information interaction model of the public storage area only when needing information of other nodes, so that unnecessary information transmission is reduced, and the behavior of messy messages sent to other nodes in the Byzantine node is limited (the verification information in the verification stage is that the same version is seen by each node in real time), and the fault tolerance is improved.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (7)
1. A novel block chain consensus method based on shared storage is characterized by comprising the following steps:
s1, leader election stage: selecting a unique leader node from the validator nodes through mutual exclusion based on shared storage;
s2, block generation: generating a corresponding new block by the leader node generated in the election stage, and informing other validators to carry out verification and viewing the result generated in the verification stage by the leader node;
s3, block verification stage: verifying the new block by a validator node in the system;
s4, block chain updating stage: the leger node and the validator node in the system access the verification information to determine whether to update the local block chain, so as to achieve consensus.
2. The method as claimed in claim 1, wherein in step S1, if the jiionlist in the id corresponding to the validator node is true, it indicates that the validator node participates in the competition of the leader node in the round, and if the condition is not met, the validator node does not participate in the competition in the round, and the validator node does not perform any processing;
3. the method according to claim 2, wherein the step S1 is as follows:
s11, if the competition-participating validator nodes find that the variable K is different from the id of the nodes, setting the mutexList corresponding to the id of the nodes as false, wherein if the validator nodes with the id being equal to K have no competition intention, namely, the joinlist [ K ] being equal to false, the validator nodes assign the id of the nodes to the K;
s12, if the competition-participating validator nodes find that the variable K is the same as the id of the nodes, setting the mutex List corresponding to the id of the nodes as the tube, and finishing the circulation when only the nodes serving as the only validator nodes with the mutex List value as the tube in the system are waited, namely in the leader election stage, the validator nodes become leader nodes and the selection of the leader nodes is finished.
4. The method according to claim 1, wherein the step S2 is as follows:
s21, a trander node in the system sends transaction data to a transaction pool, and a leader node collects the transaction data and packs blocks;
s22, writing the packaged block into a sharing area of the block consensus system;
and S23, after the blocks are packed, the leader node sends information of block creation completion to all validator nodes and leger nodes and informs other nodes of access to the shared area.
5. The method according to claim 1, wherein the step S3 is as follows:
s31, after receiving a block creation success message sent by a leader node in the current round, a validator node in the system accesses a generated block and verifies whether the block generated by the leader node in the current round is correct, if the block generated in the current round is correct, setting validatlist [ id ] as tube, and if not, setting the validator node as false;
and S32, after receiving the block creation success message sent by the leader node in the current round, the hedgehog node in the system accesses the shared area of the block to prepare for the block chain updating stage.
6. The method according to claim 1, wherein the step S4 is as follows:
s41, accessing and recording a joinList array of the competition of the local competition participation nodes and a validateList array of the block verification result, if more than half of the data recorded by approved leader nodes exist in the competition participation nodes, updating a local account book, otherwise, the data is invalid and is not updated;
s42, for the validator nodes meeting the condition that id is K, namely leader nodes, mutually exclusive variables mutexList and participatory variables joinList are required to be released additionally, and conditions are provided for selection of a new round of leader nodes;
s43, releasing the validateList arrays corresponding to all the ids, namely assigning null to the corresponding validateList, and providing conditions for the verification of the next round of blocks.
7. The method of claim 1, wherein the number of validators is linear to the amount of information interaction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010912929.7A CN112187866B (en) | 2020-09-03 | 2020-09-03 | Novel block chain consensus method based on shared storage |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010912929.7A CN112187866B (en) | 2020-09-03 | 2020-09-03 | Novel block chain consensus method based on shared storage |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112187866A true CN112187866A (en) | 2021-01-05 |
| CN112187866B CN112187866B (en) | 2021-10-15 |
Family
ID=73924676
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010912929.7A Active CN112187866B (en) | 2020-09-03 | 2020-09-03 | Novel block chain consensus method based on shared storage |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112187866B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112822013A (en) * | 2021-04-16 | 2021-05-18 | 卓尔智联(武汉)研究院有限公司 | Block chain consensus method, device and storage medium |
| CN112860807A (en) * | 2021-04-08 | 2021-05-28 | 山东大学 | Fault-tolerant consensus method suitable for wireless block chain network |
| CN112988891A (en) * | 2021-03-11 | 2021-06-18 | 重庆文理学院 | Method and device for storing block chain account book, electronic equipment and storage medium |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107181599A (en) * | 2017-07-18 | 2017-09-19 | 天津理工大学 | The storage of route location data confidentiality and sharing method based on block chain |
| US20170323392A1 (en) * | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
| CN108390891A (en) * | 2018-03-28 | 2018-08-10 | 电子科技大学天府协同创新中心 | Information protecting method based on privately owned block chain |
| CN109525636A (en) * | 2018-10-12 | 2019-03-26 | 上海保险交易所股份有限公司 | Block chain common recognition method based on Raft algorithm |
| US20190182047A1 (en) * | 2017-12-07 | 2019-06-13 | NEC Laboratories Europe GmbH | Method and system for securely sharing validation information using blockchain technology |
| WO2019179540A2 (en) * | 2019-07-11 | 2019-09-26 | Alibaba Group Holding Limited | Shared blockchain data storage |
| CN110321074A (en) * | 2019-05-20 | 2019-10-11 | 西安电子科技大学 | The common recognition method proved based on the secure storage of block chain and distributed memory system |
| CN110913501A (en) * | 2019-11-08 | 2020-03-24 | 山东大学 | Consensus method suitable for wireless block chain network |
| CN110928951A (en) * | 2019-11-26 | 2020-03-27 | 天津理工大学 | Data sharing and arbitration method based on block chain |
| CN111108478A (en) * | 2019-07-11 | 2020-05-05 | 阿里巴巴集团控股有限公司 | Shared blockchain data storage |
| WO2020118007A1 (en) * | 2018-12-05 | 2020-06-11 | Akamai Technologies, Inc. | High performance distributed system of record with secure interoperability to external systems |
| CN111402058A (en) * | 2020-05-29 | 2020-07-10 | 支付宝(杭州)信息技术有限公司 | Data processing method, device, equipment and medium |
-
2020
- 2020-09-03 CN CN202010912929.7A patent/CN112187866B/en active Active
Patent Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170323392A1 (en) * | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
| CN107181599A (en) * | 2017-07-18 | 2017-09-19 | 天津理工大学 | The storage of route location data confidentiality and sharing method based on block chain |
| US20190182047A1 (en) * | 2017-12-07 | 2019-06-13 | NEC Laboratories Europe GmbH | Method and system for securely sharing validation information using blockchain technology |
| CN108390891A (en) * | 2018-03-28 | 2018-08-10 | 电子科技大学天府协同创新中心 | Information protecting method based on privately owned block chain |
| CN109525636A (en) * | 2018-10-12 | 2019-03-26 | 上海保险交易所股份有限公司 | Block chain common recognition method based on Raft algorithm |
| WO2020118007A1 (en) * | 2018-12-05 | 2020-06-11 | Akamai Technologies, Inc. | High performance distributed system of record with secure interoperability to external systems |
| CN110321074A (en) * | 2019-05-20 | 2019-10-11 | 西安电子科技大学 | The common recognition method proved based on the secure storage of block chain and distributed memory system |
| CN111108478A (en) * | 2019-07-11 | 2020-05-05 | 阿里巴巴集团控股有限公司 | Shared blockchain data storage |
| WO2019179540A2 (en) * | 2019-07-11 | 2019-09-26 | Alibaba Group Holding Limited | Shared blockchain data storage |
| CN111448781A (en) * | 2019-07-11 | 2020-07-24 | 阿里巴巴集团控股有限公司 | Shared blockchain data storage |
| CN110913501A (en) * | 2019-11-08 | 2020-03-24 | 山东大学 | Consensus method suitable for wireless block chain network |
| CN110928951A (en) * | 2019-11-26 | 2020-03-27 | 天津理工大学 | Data sharing and arbitration method based on block chain |
| CN111402058A (en) * | 2020-05-29 | 2020-07-10 | 支付宝(杭州)信息技术有限公司 | Data processing method, device, equipment and medium |
Non-Patent Citations (2)
| Title |
|---|
| ZHIQIN ZHU等: ""Blockchain based consensus checking in decentralized cloud storage"", 《SIMULATION MODELLING PRACTICE AND THEORY》 * |
| 薛腾飞等: ""基于区块链的医疗数据共享模型研究"", 《自动化学报》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112988891A (en) * | 2021-03-11 | 2021-06-18 | 重庆文理学院 | Method and device for storing block chain account book, electronic equipment and storage medium |
| CN112860807A (en) * | 2021-04-08 | 2021-05-28 | 山东大学 | Fault-tolerant consensus method suitable for wireless block chain network |
| CN112860807B (en) * | 2021-04-08 | 2022-04-12 | 山东大学 | Fault-tolerant consensus method suitable for wireless block chain network |
| CN112822013A (en) * | 2021-04-16 | 2021-05-18 | 卓尔智联(武汉)研究院有限公司 | Block chain consensus method, device and storage medium |
| CN112822013B (en) * | 2021-04-16 | 2021-07-23 | 卓尔智联(武汉)研究院有限公司 | Block chain consensus method, device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112187866B (en) | 2021-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108717630B (en) | Block output method and implementation system thereof | |
| EP3635607B1 (en) | Computer-implemented system and method for managing transactions over a blockchain network | |
| CN112187866B (en) | Novel block chain consensus method based on shared storage | |
| CN110868440B (en) | Block chain male chain | |
| EP3659086B1 (en) | Computer-implemented system and method for managing a large distributed memory pool in a blockchain network | |
| US20230316273A1 (en) | Data processing method and apparatus, computer device, and storage medium | |
| CN108737375A (en) | A kind of block chain common recognition method and system | |
| US20200052996A1 (en) | Consensus incentive method for blockchain | |
| US20230299984A1 (en) | Blockchain-based data processing method, apparatus and device, and storage medium | |
| CN112907252A (en) | Block chain transaction method and system based on multi-person down-chain channel | |
| US20230017790A1 (en) | Graphic-blockchain-orientated hybrid consensus implementation apparatus and implementation method thereof | |
| Wang et al. | Byzantine fault tolerant algorithm based on vote | |
| CN111798234A (en) | Lightweight block chain system and construction method | |
| Huang et al. | Workload-based randomization byzantine fault tolerance consensus protocol | |
| Grybniak et al. | Waterfall: a scalable distributed ledger technology | |
| Al-Musharaf et al. | Improving blockchain consensus mechanism via network clusters | |
| Huang et al. | Consensus of whom? A spectrum of blockchain consensus protocols and new directions | |
| Luo et al. | MPC-DPOS: An efficient consensus algorithm based on secure multi-party computation | |
| WO2021185905A1 (en) | Apparatus and method to produce notarized append-only memory | |
| Yuan et al. | Improvement of practical byzantine fault tolerant consensus algorithm for blockchain | |
| Wu et al. | Blockchain consensus mechanism for distributed energy transactions | |
| Niu et al. | NFT Cross-Chain Transfer Method Under the Notary Group Scheme | |
| JP2021533708A (en) | Methods and systems for proof of election on the blockchain | |
| Nezhadsistani et al. | Blockchain consensus algorithms: Past, present, and future trends | |
| WO2023082883A1 (en) | Cross-blockchain transaction processing method and apparatus, and computer device, computer storage medium and computer program product |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |