CN117221332A - High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus - Google Patents
High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus Download PDFInfo
- Publication number
- CN117221332A CN117221332A CN202310680084.7A CN202310680084A CN117221332A CN 117221332 A CN117221332 A CN 117221332A CN 202310680084 A CN202310680084 A CN 202310680084A CN 117221332 A CN117221332 A CN 117221332A
- Authority
- CN
- China
- Prior art keywords
- transaction
- leader
- node
- leaders
- ring
- 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
- 238000004806 packaging method and process Methods 0.000 title claims abstract description 31
- 238000000034 method Methods 0.000 title claims abstract description 25
- 238000012856 packing Methods 0.000 claims abstract description 42
- 238000013461 design Methods 0.000 claims abstract description 30
- 230000009471 action Effects 0.000 claims abstract description 5
- 238000012795 verification Methods 0.000 claims abstract description 3
- 230000006399 behavior Effects 0.000 claims description 44
- 230000007246 mechanism Effects 0.000 claims description 7
- 241001609030 Brosme brosme Species 0.000 claims description 5
- 230000001186 cumulative effect Effects 0.000 claims description 3
- 238000001514 detection method Methods 0.000 claims description 3
- 238000007599 discharging Methods 0.000 claims description 3
- 238000011084 recovery Methods 0.000 claims description 3
- 238000012552 review Methods 0.000 claims description 3
- 239000002699 waste material Substances 0.000 abstract description 2
- 238000012790 confirmation Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241000219495 Betulaceae Species 0.000 description 1
- 241000282344 Mellivora capensis Species 0.000 description 1
- 210000001015 abdomen Anatomy 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001747 exhibiting effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Abstract
The invention discloses a high-robustness transaction packaging method based on multi-leader Bayesian fault tolerance consensus, belonging to the technical field of block chains; the invention comprises the following contents: s1, transaction division design: dividing the space into a plurality of barrels according to the hash value of the transaction, wherein the number of barrels is the same as that of the known leaders; distributing each transaction generated by the client into a bucket according to the hash value; s2, leader packaging strategy design: the method comprises the steps of constructing a ring with a leader-barrel phase, wherein each leader has packing authority for two adjacent barrels on the ring, and each barrel is controlled by the two adjacent leaders; s3, block verification design: after receiving the message, the node detects whether the corresponding node carries out the packing action of the transaction according to the specified rule, if so, normal consensus is carried out, otherwise, the node is taken as a bad evidence to be checked. The invention effectively reduces resource waste and greatly improves the robustness of the consensus system under the situation that the leader is bad.
Description
Technical Field
The invention relates to the technical field of blockchains, in particular to a high-robustness transaction packaging method based on multi-leader Bayesian fault tolerance consensus.
Background
Blockchains are described as a data structure that uses asymmetric encryption algorithms and hash functions to ensure that data is not likely to be tampered with and counterfeited. The data blocks in the blockchain represent chronological transfer transactions between users. In cryptocurrency, a blockchain is a decentralized, distributed ledger that enables free transfer of digital assets end-to-end without involving any central roles or third parties. Because of its fundamental features, such as decentralization, tamper resistance, and traceability, blockchains can also act as a distributed network protocol, allowing trust relationships to be established between different participants without them knowing about each other. Through the development of more than ten years, the blockchain technology is not only applied to the field of cryptocurrency, but also increasingly applied to other fields such as the internet of things, medical treatment, education and the like. Providing a variety of scenarios in which blockchain techniques may be applied, current research focus is on designing more efficient and secure blockchain systems.
The BFT protocol is applied to blockchain systems as a protocol that can tolerate the misbehavior of some nodes of the state machine replication system. The need for increased performance of blockchain systems has led to extensive research in the bayer fault-tolerance protocol in recent years. Researchers have created work on reducing the complexity of communication of consensus messages, which have all been directed to reducing the complexity of messages based on the BFT protocol of a single leader, but have been limited by the limitations of a single leader, making the leader a processing bottleneck for the system. Thus, other studies have attempted to design multi-leader parallel BFT protocols that allow one leader set to independently and in parallel offer a transaction set, sharing the load across multiple leaders, exhibiting strong performance and scalability. The transition from single-leaded to multi-leaded presents a challenge for transaction repetition, where the same transaction may be packaged by multiple leaders. These repeated packaging actions can result in wasted storage, bandwidth, CPU, etc. resources, and in the worst case, can result in the repetition of a single request O (n), thereby losing the advantage of using multiple leaders.
Some multi-leader concurrent block consensus related works such as honeybadger, dumbo, VABA, BEAT, red Belly, etc. do not put strict constraints on the packing strategy of transactions, but merely let each leader randomly fetch transactions from a waiting list of transactions to get a nearly disjoint set of transactions. In fact, in cases where the system transaction is not deeply saturated, there is still a large number of repeat transactions.
MIR-BFT, ISS, ALDER et al work uses a hash-based transaction deduplication technique, the basic idea of which is to divide transactions into disjoint sets of transactions, called buckets, based on hash values. Each leader is responsible for a portion of the bucket(s) and ensures that none of the buckets are simultaneously responsible for multiple leaders. This technique, while eliminating duplication of transactions, increases the delay of transactions linearly, as seen by Red Belly authors, with low difficulty in the endeavor of the leader.
The distributed perfect random coin can obtain unpredictable global unified random information in a distributed system, and can be used for an asynchronous consensus system to non-deterministically advance consensus. It can be built from an adaptive security threshold signature scheme, and key set can be done in a completely asynchronous case.
Based on the above, the invention provides a high-robustness transaction packing method based on the multi-leader Bayesian-busy-family fault-tolerant consensus so as to solve the above problems.
Disclosure of Invention
1. Technical problem to be solved by the invention
The invention aims to provide a high-robustness transaction packaging method based on multi-leader BJT fault-tolerant consensus so as to solve the problems provided in the background art.
2. Technical proposal
In order to achieve the above purpose, the present invention provides the following technical solutions:
the high-robustness transaction packaging method based on the multi-leader Bayesian-busy-family fault-tolerant consensus is designed based on a Tusk consensus protocol, and a packaging strategy control module is added in the Tusk consensus protocol to control the transaction packaging behavior of the leader, and the method is specifically implemented as follows:
s1, transaction division design: dividing the space into a plurality of barrels according to the hash value of the transaction, wherein the number of barrels is the same as that of the known leaders; distributing each transaction generated by the client into a bucket according to the hash value;
s2, leader packaging strategy design: the method comprises the steps of ring reconstruction design and collaboration mechanism design, wherein a leader-barrel alternate ring is constructed based on the content of S1, each leader has packing authority for two adjacent barrels on the ring, and each barrel is controlled by the two adjacent leaders;
s3, block verification design: after receiving the message, the node detects whether the corresponding node carries out the packing action of the transaction according to the specified rule, if so, normal consensus is carried out, otherwise, the node is taken as a bad evidence to be checked.
Preferably, assuming that the number of the leader and the bucket is n, the numbers of the leader and the bucket are {1,2, … n }, the loop reconstruction design in S2 specifically includes the following:
a1, setting an arrangement p= {1,2, …, n } with the length of n, and enabling p to circularly move right each time a policy ring needs to be reconstructed;
a2, setting an arrangement q= {1,2, …, n } with the length of n, and randomly arranging q through distributed perfect random coins;
a3, for the leader with the number i, connecting the leader i with the barrels with the numbers pi, pi and pi to form a plurality of multi-ring; the edge connection operation is carried out by adopting parallel checking;
a4, traversing all leaders, judging whether the leaders are in the same ring with the No. 1 leaders, if the leaders i and the No. 1 leaders are not in the same ring, randomly selecting one leader x from the ring where the No. 1 leaders are located, randomly selecting one leader y from the ring where the No. i leaders are located, exchanging values of q [ x ] and q [ y ], and merging the two rings;
and A5, after traversing, connecting the leader i with the barrel with the numbers of pi and pi again to obtain a ring for connecting all the leaders and the barrels.
Preferably, the collaborative mechanism design in S2 specifically includes the following:
b1, language packaging behavior design: for one barrel, setting the expected packing amount of the node as size, taking out 2 x size transactions from a transaction pool for packing, and preferentially taking out transactions without hitting a filter to cooperate with the cooperative node to avoid repeated packing; the node packs half of the fetched transactions in the current round, packs the other half of the fetched transactions in the next round as a prediction, and generates a corresponding bloom filter for the part of the transactions and broadcasts the bloom filter along with the blocks of the current round; recording the predicted filter information received by the node to the cooperative node in the local;
b2, predicting implementation behavior design: directly publishing the predicted block generated by the node in B1 on the last round of the barrel; if the size of the predicted block is smaller than the set size, the node takes out the transaction from the corresponding barrel in the transaction pool to fill the transaction until the transaction amount reaches the set size or no transaction in the barrel can be taken out; the rule of taking out the transaction is the same as the predicted packing behavior;
b3, node behavior: the first packing of the node i after the ring reconstruction adopts predictive packing behavior for the controlled pi number bucket and predictive realization behavior for the q number bucket; then repeatedly alternating in the follow-up block discharging behaviors, wherein each packing behavior is opposite to the last behavior;
b4, overlapping detection and recovery: when the current behavior mode detected by the node i is the same as that of the cooperative node (namely, the cooperative barrels are simultaneously subjected to predictive packaging or predictive implementation), selecting whether to avoid according to the type of the control barrel: if the coordinated bucket is a bucket generated by right shift of a cycle with the number p [ i ], avoiding behavior is carried out, and the self behavior mode is changed (the implementation is changed into predictive implementation if predictive implementation is prepared currently, and the packaging is changed into predictive packaging if predictive implementation is prepared currently);
b5, transaction proportion adjustment: node i dynamically changes the transaction duty cycle in the final package block based on the cumulative number of transactions in buckets p [ i ] and q [ i ] in the local transaction pool to mitigate load imbalance due to the Bayesian node review.
3. Advantageous effects
The invention analyzes the application scene of the current multi-leader consensus blockchain, combines the actual requirements, and provides a transaction packaging method based on multi-leader Bayesian fault-tolerant consensus, which can still have high robustness under the condition of more bad nodes, and has the following specific beneficial effects:
(1) Compared with the schemes of MIR and other works, the invention greatly increases the difficulty of the beginner leader to examine the transaction, improves the robustness of the system under the condition that the leader is bad, and reduces the confirmation time delay caused by the bad leader;
(2) The invention adds the bloom filter of future information in the block and staggers the action of the cooperative nodes to further reduce repeated transaction and reduce the waste of resources.
Drawings
FIG. 1 is a schematic diagram of a system model according to embodiment 1 of the present invention;
FIG. 2 is a schematic view of the ring reconstruction mentioned in example 1 of the present invention;
fig. 3 is a schematic diagram of a collaboration mechanism mentioned in embodiment 1 of the present invention.
Detailed Description
In order that the above-recited objects, features and advantages of the present invention will become more readily apparent, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways other than those described herein, and persons skilled in the art will readily appreciate that the present invention is not limited to the specific embodiments disclosed below.
Further, reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic can be included in at least one implementation of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments.
Example 1:
the invention provides a high-robustness transaction packing method based on multi-leader Bayesian-busy-family fault-tolerant consensus, which is based on the method to construct a transaction packing system model corresponding to the method, wherein a system model schematic diagram is shown in fig. 1, and the working mode of the constructed packing system is further described below with reference to the accompanying drawings:
client behavior:
step 1-1: the client sends transaction information to at least f+1 nodes and waits for the consensus module to send confirmation information of the transaction, as shown in fig. 1.
Packaging policy control module behavior:
first, the packing strategy design will be described:
the packing strategy comprises a ring reconstruction design and a collaboration mechanism design, and aims at constructing a ring with leader-barrel intervals, wherein each leader has packing authority on two adjacent barrels on the ring, each barrel is controlled by the two adjacent leaders, the number of the leaders and the barrels is assumed to be n, and the numbers of the leaders and the barrels are {1,2, … n };
referring to fig. 2, the loop reconstruction design specifically includes the following:
a1, setting an arrangement p= {1,2, …, n } with the length of n, and enabling p to circularly move right each time a policy ring needs to be reconstructed;
a2, setting an arrangement q= {1,2, …, n } with the length of n, and randomly arranging q through distributed perfect random coins;
a3, for the leader with the number i, connecting the leader i with the barrels with the numbers pi, pi and pi to form a plurality of multi-ring; the edge connection operation is carried out by adopting parallel checking;
a4, traversing all leaders, judging whether the leaders are in the same ring with the No. 1 leaders, if the leaders i and the No. 1 leaders are not in the same ring, randomly selecting one leader x from the ring where the No. 1 leaders are located, randomly selecting one leader y from the ring where the No. i leaders are located, exchanging values of q [ x ] and q [ y ], and merging the two rings;
and A5, after traversing, connecting the leader i with the barrel with the numbers of pi and pi again to obtain a ring for connecting all the leaders and the barrels.
Referring to fig. 3, the collaboration mechanism design specifically includes the following:
b1, language packaging behavior design: for one barrel, setting the expected packing amount of the node as size, taking out 2 x size transactions from a transaction pool for packing, and preferentially taking out transactions without hitting a filter to cooperate with the cooperative node to avoid repeated packing; the node packs half of the fetched transactions in the current round, packs the other half of the fetched transactions in the next round as a prediction, and generates a corresponding bloom filter for the part of the transactions and broadcasts the bloom filter along with the blocks of the current round; recording the predicted filter information received by the node to the cooperative node in the local;
b2, predicting implementation behavior design: directly publishing the predicted block generated by the node in B1 on the last round of the barrel; if the size of the predicted block is smaller than the set size, the node takes out the transaction from the corresponding barrel in the transaction pool to fill the transaction until the transaction amount reaches the set size or no transaction in the barrel can be taken out; the rule of taking out the transaction is the same as the predicted packing behavior;
b3, node behavior: the first packing of the node i after the ring reconstruction adopts predictive packing behavior for the controlled pi number bucket and predictive realization behavior for the q number bucket; then repeatedly alternating in the follow-up block discharging behaviors, wherein each packing behavior is opposite to the last behavior;
b4, overlapping detection and recovery: when the current behavior mode detected by the node i is the same as that of the cooperative node (namely, the cooperative barrels are simultaneously subjected to predictive packaging or predictive implementation), selecting whether to avoid according to the type of the control barrel: if the coordinated bucket is a bucket generated by right shift of a cycle with the number p [ i ], avoiding behavior is carried out, and the self behavior mode is changed (the implementation is changed into predictive implementation if predictive implementation is prepared currently, and the packaging is changed into predictive packaging if predictive implementation is prepared currently);
b5, transaction proportion adjustment: node i dynamically changes the transaction duty cycle in the final package block based on the cumulative number of transactions in buckets p [ i ] and q [ i ] in the local transaction pool to mitigate load imbalance due to the Bayesian node review.
Based on the above, the packaging policy control module acts specifically include:
step 2-1: after the transaction pool receives the transaction from the client, the transaction pool is distributed to different transaction barrels according to the hash value of the transaction.
Step 2-2: the node decides the current packing behavior according to the current packing context (ring state, last packing behavior and cooperative node behavior), packs the transaction in the barrel according to the packing details described above, transmits the transaction to the consensus module, and broadcasts the transaction in the system after adding the consensus information, as shown in fig. 1. The cooperative packing of the entire reconstruction period is shown in fig. 3.
Step 2-3: after receiving the block from the cooperative node, the node updates the latest state of the cooperative node to assist in the determination of step 2-2, and extracts bloom filters associated with the cooperative bucket for reducing duplicate transactions, as shown in fig. 3.
Step 2-4: when the consensus module judges that the transaction strategy reconstruction is needed (periodically reconstructing the guarantee activity, detecting the malicious activity and reconstructing the countermeasures), the reconstruction design is adopted to reconstruct the local loop view, and meanwhile, the bloom filter and other temporary information are updated.
Consensus module behavior:
the consensus module is an example of a multi-leader Bayesian fault tolerant consensus protocol, which may be a Tusk, DAG-riter, mir-BFT, ISS, etc. consensus, requiring removal of their internal original transaction packaging policies (if any) when in use. The method can achieve distributed linear consistency for transmitted transactions, and has different implementation details based on different consensus protocol examples, and the method specifically comprises the following steps:
step 3-1: after receiving the blocks from the packing strategy control module, exchanging information between nodes for consensus;
step 3-2: when a block is confirmed, the consensus module sends confirmation information to all clients corresponding to all transactions therein, as shown in fig. 1.
In summary, the invention realizes a high-robustness transaction packaging method based on multi-leader Bayesian-busy-court fault-tolerant consensus, and a corresponding packaging system model can be constructed and designed according to the proposed scheme.
The foregoing is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art, who is within the scope of the present invention, should make equivalent substitutions or modifications according to the technical solution and the modified concept thereof, within the scope of the present invention.
Claims (3)
1. The high-robustness transaction packaging method based on the multi-leader Bayesian-busy-family fault-tolerant consensus is characterized by comprising the following steps of designing based on a Tusk consensus protocol, adding a packaging strategy control module in the Tusk consensus protocol to control transaction packaging behaviors of a leader, and specifically realizing the method:
s1, transaction division design: dividing the space into a plurality of barrels according to the hash value of the transaction, wherein the number of barrels is the same as that of the known leaders; distributing each transaction generated by the client into a bucket according to the hash value;
s2, leader packaging strategy design: the method comprises the steps of ring reconstruction design and collaboration mechanism design, wherein a leader-barrel alternate ring is constructed based on the content of S1, each leader has packing authority for two adjacent barrels on the ring, and each barrel is controlled by the two adjacent leaders;
s3, block verification design: after receiving the message, the node detects whether the corresponding node carries out the packing action of the transaction according to the specified rule, if so, normal consensus is carried out, otherwise, the node is taken as a bad evidence to be checked.
2. The method for packaging high robustness traffic based on multi-leader bayer and horrible fault-tolerant consensus according to claim 1, wherein the ring reconstruction design in S2 specifically comprises the following, assuming that the number of leaders and buckets is n, the numbers of both leaders and buckets are {1,2, … n }:
a1, setting an arrangement p= {1,2, …, n } with the length of n, and enabling p to circularly move right each time a policy ring needs to be reconstructed;
a2, setting an arrangement q= {1,2, …, n } with the length of n, and randomly arranging q through distributed perfect random coins;
a3, for the leader with the number i, connecting the leader i with the barrels with the numbers pi, pi and pi to form a plurality of multi-ring; the edge connection operation is carried out by adopting parallel checking;
a4, traversing all leaders, judging whether the leaders are in the same ring with the No. 1 leaders, if the leaders i and the No. 1 leaders are not in the same ring, randomly selecting one leader x from the ring where the No. 1 leaders are located, randomly selecting one leader y from the ring where the No. i leaders are located, exchanging values of q [ x ] and q [ y ], and merging the two rings;
and A5, after traversing, connecting the leader i with the barrel with the numbers of pi and pi again to obtain a ring for connecting all the leaders and the barrels.
3. The high-robustness transaction packing method based on the multi-leader bayer and horrible fault-tolerant consensus according to claim 2, wherein the collaborative mechanism design in S2 specifically comprises the following contents:
b1, language packaging behavior design: for one barrel, setting the expected packing amount of the node as size, taking out 2 x size transactions from a transaction pool for packing, and preferentially taking out transactions without hitting a filter to cooperate with the cooperative node to avoid repeated packing; the node packs half of the fetched transactions in the current round, packs the other half of the fetched transactions in the next round as a prediction, and generates a corresponding bloom filter for the part of the transactions and broadcasts the bloom filter along with the blocks of the current round; recording the predicted filter information received by the node to the cooperative node in the local;
b2, predicting implementation behavior design: directly publishing the predicted block generated by the node in B1 on the last round of the barrel; if the size of the predicted block is smaller than the set size, the node takes out the transaction from the corresponding barrel in the transaction pool to fill the transaction until the transaction amount reaches the set size or no transaction in the barrel can be taken out; the rule of taking out the transaction is the same as the predicted packing behavior;
b3, node behavior: the first packing of the node i after the ring reconstruction adopts predictive packing behavior for the controlled pi number bucket and predictive realization behavior for the q number bucket; then repeatedly alternating in the follow-up block discharging behaviors, wherein each packing behavior is opposite to the last behavior;
b4, overlapping detection and recovery: when the current behavior mode detected by the node i is the same as that of the cooperative node, selecting whether to avoid according to the type of the control barrel: if the coordinated barrel is a barrel generated by the right shift of the circulation with the number of pi, carrying out avoidance behavior and changing the behavior mode of the barrel;
b5, transaction proportion adjustment: node i dynamically changes the transaction duty cycle in the final package block based on the cumulative number of transactions in buckets p [ i ] and q [ i ] in the local transaction pool to mitigate load imbalance due to the Bayesian node review.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310680084.7A CN117221332B (en) | 2023-06-08 | 2023-06-08 | High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310680084.7A CN117221332B (en) | 2023-06-08 | 2023-06-08 | High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117221332A true CN117221332A (en) | 2023-12-12 |
| CN117221332B CN117221332B (en) | 2024-04-12 |
Family
ID=89037706
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310680084.7A Active CN117221332B (en) | 2023-06-08 | 2023-06-08 | High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117221332B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108737375A (en) * | 2018-04-13 | 2018-11-02 | 中山大学 | A kind of block chain common recognition method and system |
| CN109246194A (en) * | 2018-08-13 | 2019-01-18 | 佛山市顺德区中山大学研究院 | Practical Byzantine failure tolerance block chain common recognition method and system based on more leader nodes |
| US20200162264A1 (en) * | 2017-05-22 | 2020-05-21 | Visa International Service Association | Network for improved verification speed with tamper resistant data |
| KR20200062889A (en) * | 2018-11-27 | 2020-06-04 | 한국전자통신연구원 | Method and Apparatus for performing block agreement in block chain system |
| CN114499874A (en) * | 2021-12-29 | 2022-05-13 | 重庆邮电大学 | Byzantine fault-tolerant consensus optimization method applied to industrial internet |
| US20220239496A1 (en) * | 2019-06-26 | 2022-07-28 | Jingdong Technology Holding Co., Ltd. | Blockchain consensus method, device and system |
| CN115549931A (en) * | 2022-12-02 | 2022-12-30 | 佛山赛思禅科技有限公司 | Byzantine fault-tolerant implementation method and system based on mimicry defense |
-
2023
- 2023-06-08 CN CN202310680084.7A patent/CN117221332B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200162264A1 (en) * | 2017-05-22 | 2020-05-21 | Visa International Service Association | Network for improved verification speed with tamper resistant data |
| CN108737375A (en) * | 2018-04-13 | 2018-11-02 | 中山大学 | A kind of block chain common recognition method and system |
| CN109246194A (en) * | 2018-08-13 | 2019-01-18 | 佛山市顺德区中山大学研究院 | Practical Byzantine failure tolerance block chain common recognition method and system based on more leader nodes |
| KR20200062889A (en) * | 2018-11-27 | 2020-06-04 | 한국전자통신연구원 | Method and Apparatus for performing block agreement in block chain system |
| US20220239496A1 (en) * | 2019-06-26 | 2022-07-28 | Jingdong Technology Holding Co., Ltd. | Blockchain consensus method, device and system |
| CN114499874A (en) * | 2021-12-29 | 2022-05-13 | 重庆邮电大学 | Byzantine fault-tolerant consensus optimization method applied to industrial internet |
| CN115549931A (en) * | 2022-12-02 | 2022-12-30 | 佛山赛思禅科技有限公司 | Byzantine fault-tolerant implementation method and system based on mimicry defense |
Non-Patent Citations (1)
| Title |
|---|
| 赵守月;葛洪伟;: "MEPaxos:低延迟的共识算法", 计算机科学与探索, no. 05, 26 June 2018 (2018-06-26), pages 150 - 158 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117221332B (en) | 2024-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Baird | The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tolerance | |
| US20200143366A1 (en) | Methods for decentralized digital asset transfer and smart contract state transition | |
| US20210097538A1 (en) | Systems and methods for managing data generation, storage, and verification in a distributed system having a committee of validator nodes | |
| US11157487B2 (en) | Trusted storage method and system based on directed acyclic graph structure | |
| CN111598566A (en) | Network payment system based on mixed cross-chain | |
| Boichat et al. | Deconstructing paxos | |
| Lampson | The ABCD's of Paxos | |
| CN111131209B (en) | Improved efficient consensus method, system, computer device and storage medium | |
| Keidar et al. | On the cost of fault-tolerant consensus when there are no faults: preliminary version | |
| Fu et al. | An improved blockchain consensus algorithm based on raft | |
| Malkhi et al. | Maximal extractable value (mev) protection on a dag | |
| TWI749488B (en) | Computer-implemented method, system, and non-transitory computer-readable storage medium for detecting disabling replay attacks | |
| Danezis et al. | Blockmania: from block dags to consensus | |
| Yu et al. | Improved blockchain consensus mechanism based on PBFT algorithm | |
| Ben-Or et al. | Fast self-stabilizing byzantine tolerant digital clock synchronization | |
| Buchnik et al. | Fireledger: A high throughput blockchain consensus protocol | |
| He et al. | Chameleon: A scalable and adaptive permissioned blockchain architecture | |
| Fu et al. | Teegraph: A Blockchain consensus algorithm based on TEE and DAG for data sharing in IoT | |
| Cason et al. | Gossip consensus | |
| CN117221332B (en) | High-robustness exchange packaging method based on multi-leader Bayesian-busy-family fault-tolerant consensus | |
| Roth et al. | Do not overpay for fault tolerance! | |
| Wels | Guaranteed-TX: The exploration of a guaranteed cross-shard transaction execution protocol for Ethereum 2.0. | |
| Wang | Sok: understanding BFT consensus in the age of blockchains | |
| Nikolaou et al. | Turtle consensus: Moving target defense for consensus | |
| Tang et al. | Excellent practical byzantine fault tolerance |
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 |