CN111404928B - Block chain link point consensus method suitable for real-time transaction scene - Google Patents
Block chain link point consensus method suitable for real-time transaction scene Download PDFInfo
- Publication number
- CN111404928B CN111404928B CN202010175157.3A CN202010175157A CN111404928B CN 111404928 B CN111404928 B CN 111404928B CN 202010175157 A CN202010175157 A CN 202010175157A CN 111404928 B CN111404928 B CN 111404928B
- Authority
- CN
- China
- Prior art keywords
- node
- primary
- nodes
- block chain
- attribute
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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
-
- 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
-
- 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/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a block chain link point consensus method suitable for a real-time transaction scene, which is characterized in that a set of multivariate node reliability quantification methods considering weight are set by analyzing and quantifying the attributes of each node device in a block chain in a network, quantification values are obtained by a vector and matrix method, and Primary main nodes are elected according to the quantification values, so that the probability of failure of the Primary main nodes in the block chain is reduced, the frequency of view change is effectively reduced, the delay is reduced, and the block chain link point consensus method has higher stability and higher transaction throughput; a plurality of broadcasting and responding mechanisms are set in the mutual communication and response process of each node, and the number of invalid or malicious nodes which can be tolerated by a block chain system of normal nodes is guaranteed in a plurality of links, so that the overall safety, real-time performance and stability of the system are all suitable for severe scenes such as finance.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to a block chain link point consensus method suitable for a real-time transaction scene.
Background
The block chain is originated from bitcoin, is essentially a distributed decentralized database, can be visually compared with a shared account book, and has the characteristics of decentralized, non-falsification, whole-course trace retention, traceability, collective maintenance and public transparency. The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. Generally, a blockchain system consists of an application layer, a contract layer, a consensus layer, a network layer, and a data layer.
The block chain consensus layer mainly encapsulates various consensus algorithms of network nodes, and how to efficiently achieve consensus in a distributed system is an important research problem in the field of distributed computing. One of the core advantages of the blockchain technique is to enable nodes to efficiently agree on the validity of block data in a de-centralized system with highly distributed decision weights. Early bitcoin blockchains employed a highly node-computing-dependent Proof of work (PoW) mechanism to ensure consistency of bitcoin network distributed accounting.
However, the PoW consensus mechanism requires difficult problem certification and is not suitable for the scenes such as finance and the like requiring real-time transaction; while the traditional Practical Byzantine Fault-tolerant algorithm (PBFT) can be used as a substitute for PoW, the problem that it is not negligible still exists: when the master node is selected, the master node is selected in a polling mode, and the conditions that the selected node is unstable, dishonest and the like exist, and the problem that frequent view change is triggered subsequently exists.
Disclosure of Invention
Aiming at the defects in the prior art, the block chain link point consensus method suitable for the real-time transaction scene provided by the invention solves the problem that the existing block chain link point consensus mechanism including the traditional PBFT algorithm is not suitable for the scenes needing real-time transaction, such as finance and the like.
In order to achieve the purpose of the invention, the invention adopts the technical scheme that: a block link point consensus method suitable for a real-time transaction scene comprises the following steps:
s1, electing a Primary host node;
s2, initiating an m request to a Primary master node through the Client side, and receiving the m request through the Primary master node;
s3, distributing a sequence number n to the m request through the Primary master node to form a Pre-prepare message, broadcasting the Pre-prepare message to all follower nodes in the block chain, and storing the Pre-prepare message in a log of the Primary master node;
s4, checking the Pre-prepare message through all follower nodes;
s5, respectively storing the checked Pre-Prepare messages in log logs of all follower nodes, and respectively broadcasting the Prepare messages through all follower nodes;
s6, checking the Prepare message received by each node, and adjusting the working state of the checked node to be a Prepared state;
s7, broadcasting Commit information through the node reaching the Prepared state, and verifying the Commit information receiving and executing condition, realizing the Client end transaction confirmation.
Further, the step S1 includes the following steps:
s11, establishing a multi-element model according to the block chain network characteristics and the financial mathematical characteristics to obtain an attribute vector x ═ x of each node1，x2… xN }, where x is1，x2，…xNThe attribute of the node is N, the total number of the attributes is N, and the value of N is an integer not less than 1;
s12, evaluating the attribute vector x of each node by the membership degree evaluation algorithm, where x is { x }1，x2，…，xNQuantizing the credibility of each attribute to obtain a credibility matrix R of each node;
s13, establishing attribute weight vector w of each node according to importance degree of each attribute of the block chain node1，w2，…，wN}；
S14, calculating a credibility vector v of each node according to the credibility matrix R and the attribute weight vector w of each node;
s15, dividing each node of the block chain into a trusted node, a general node and an untrusted node according to the credibility vector v of each node, and adding the trusted node into a Primary master node alternative set;
and S16, taking M consensus of each block chain as a period, and in one period, switching the view to replace the Primary node to poll and select the Primary node in the Primary node alternative set.
Further, the reliability matrix of each node in the step S12
Is an Nx 3 matrix, and in the ith row element: r isi1Representing the node attribute vector x ═ x1，x2，…，xNIn xiCredible membership of the attribute; r isi2Representing the node attribute vector x ═ x1，x2，…，xNIn xiGeneral credibility membership of the attribute; r isi3Representing the node attribute vector x ═ x1，x2，…，xNIn xiUntrusted membership of an attribute, i ∈ [1, N ]]。
Further, the calculation expression of step S14 is:
wherein v is1Is the credible membership, v, of the node2Is the general credible membership, v, of the node3Is the untrusted membership of the node.
Further, the step S4 includes: performing signature verification on the Pre-prefix message; verifying whether the Pre-prepare message is a message of a view where the follower node of the current follower is located; verifying whether the current follower node receives a message except the sequence number n under the current view; it is verified whether the Pre-prepare message is within the current reception window.
Further, the step S6 includes: verifying whether a Pre-prefix message exists in a log of a current node; and verifying whether the current node receives 2f Prepare messages from other nodes, wherein f is the number of invalid or malicious nodes which can be tolerated by the block chain system.
Further, the step S7 includes the following steps:
s71, broadcasting Commit information through the nodes reaching the Prepared state;
s72, executing the Commit message through the node which has received the Commit message sent by 2+1 nodes and has broadcast the Commit message, and sending feedback to the Client;
s73, judging whether the feedback number received by the Client side in the effective time is larger than f, if so, ending, otherwise, jumping to the step S74;
s74, broadcasting the m request to all nodes through the Client;
s75, forwarding an m request of the Client to a Primary node through a non-Primary node which receives the m request, wherein the non-Primary node is a node except the Primary node in the block chain;
s76, judging whether the non-Primary node which has forwarded the m request to the Primary node receives the response of the Primary node within the valid time, if yes, jumping to the step S3, and if not, jumping to the step S77;
s77, polling and selecting the next node as the Primary node in the Primary node alternative set, switching view views, and retransmitting the request m by the Client side under the current view.
The invention has the beneficial effects that: by analyzing and quantizing the attributes of each node device in the block chain in the network, a set of multivariate node reliability quantization methods considering weight is set, a quantization value is obtained by a vector method and a matrix method, and Primary nodes are selected according to the method, so that the probability of failure of the Primary nodes in the block chain is reduced, the frequency of view change is effectively reduced, the delay is reduced, and the method has high stability and high transaction throughput; a plurality of broadcasting and responding mechanisms are set in the mutual communication and response process of each node, and the number of invalid or malicious nodes which can be tolerated by a block chain system of normal nodes is guaranteed in a plurality of links, so that the overall safety, real-time performance and stability of the system are all suitable for severe scenes such as finance.
Drawings
Fig. 1 is a schematic flow chart of a block link point consensus method suitable for a real-time transaction scenario.
Detailed Description
The following description of the embodiments of the present invention is provided to facilitate the understanding of the present invention by those skilled in the art, but it should be understood that the present invention is not limited to the scope of the embodiments, and it will be apparent to those skilled in the art that various changes may be made without departing from the spirit and scope of the invention as defined and defined in the appended claims, and all matters produced by the invention using the inventive concept are protected.
As shown in fig. 1, in an embodiment of the present invention, a block link point consensus method suitable for a real-time transaction scenario includes the following steps:
and S1, selecting a Primary host node. The method comprises the following specific steps:
s11, establishing a multi-element model according to the block chain network characteristics and the financial mathematical characteristics to obtain an attribute vector x ═ x of each node1，x2，…xNIn which x1，x2，…xNAnd N is the total number of the attributes of the node, and the value of N is an integer not less than 1.
The block chain system of this embodiment has 7 nodes in total, and according to the network attribute and the application environment where the node is located, the node attribute vector in the established model includes 3 attributes: effective bandwidth, the number of reliable nodes connected by the node, and the transaction conditions completed by the node.
S12, evaluating the attribute vector x of each node by the membership degree evaluation algorithm, where x is { x }1，x2，…，xNAll of them belong toAnd quantizing the credibility to obtain a credibility matrix R of each node. Confidence matrix of each node
Is an Nx 3 matrix, and in the ith row element: r isi1Representing the node attribute vector x ═ x1，x2，…，xNIn xiCredible membership of the attribute; r isi2Representing the node attribute vector x ═ x1，x2，…，xNIn xiGeneral credibility membership of the attribute; r isi3Representing the node attribute vector x ═ x1，x2，…，xNIn xiUntrusted membership of an attribute, i ∈ [1, N ]]。
S13, establishing attribute weight vector w of each node according to importance degree of each attribute of the block chain node1，w2，…，wN}。
And S14, calculating the credibility vector v of each node according to the credibility matrix R and the attribute weight vector w of each node. The calculation expression is:
wherein v is1Is the credible membership, v, of the node2Is the general credible membership, v, of the node3Is the untrusted membership of the node.
After calculation, the reliability vectors of the 7 nodes in this embodiment are obtained as follows:
and the node 1: (1, 0, 0);
and (3) the node 2: (0.4211, 0.4566, 0.1223);
and (3) the node: (0.1835, 0.5000, 0.3165);
and the node 4: (0.2770, 0.4566, 0.2664);
and the node 5: (0.4812, 0.4130, 0.1057);
and the node 6: (0.1686, 0.3856, 0.4559);
and the node 7: (0.0949,0.1771,0.7280).
And S15, dividing each node of the block chain into a trusted node, a general node and an untrusted node according to the credibility vector v of each node, and adding the trusted node into a Primary master node alternative set. The trust conditions of 7 nodes are respectively:
trusted nodes (node 1, node 5);
general trusted nodes (node 2, node 3, node 4);
untrusted nodes (node 6, node 7).
And S16, taking M consensus of each block chain as a period, and in one period, switching the view to replace the Primary node to poll and select the Primary node in the Primary node alternative set.
And selecting the node 1 and the node 5 as a Primary master node alternative node set, and polling and selecting a Primary master node from the set.
S2, initiating an m request to the Primary master node through the Client and receiving the m request through the Primary master node.
S3, allocating a sequence number n to the m request through the Primary master node to form a Pre-prepare message, broadcasting the Pre-prepare message to all follower nodes in the block chain, and storing the Pre-prepare message in a log of the Primary master node.
S4, check the Pre-prepare message through all follower nodes. The verification content comprises the following steps: performing signature verification on the Pre-prefix message; verifying whether the Pre-prepare message is a message of a view where the follower node of the current follower is located; verifying whether the current follower node receives a message except the sequence number n under the current view; it is verified whether the Pre-prepare message is within the current reception window.
S5, storing the checked Pre-Prepare message in log logs of all follower nodes respectively, and broadcasting the Prepare message through all follower nodes respectively.
S6, checking the Prepare message received by each node, and adjusting the working state of the checked node to be Prepared state, wherein the checking content includes: verifying whether a Pre-prefix message exists in a log of a current node; and verifying whether the current node receives 2 Prepare messages from other nodes, wherein f is the number of invalid or malicious nodes which can be tolerated by the block chain system.
S7, broadcasting Commit information through the node reaching the Prepared state, and verifying the Commit information receiving and executing condition, realizing the Client end transaction confirmation. The method specifically comprises the following steps:
s71, broadcasting Commit information through the nodes reaching the Prepared state;
s72, executing the Commit message through the node which has received the Commit message sent by 2+1 nodes and has broadcast the Commit message, and sending feedback to the Client;
s73, judging whether the feedback number received by the Client side in the effective time is larger than f, if so, ending, otherwise, jumping to the step S74;
s74, broadcasting the m request to all nodes through the Client;
s75, forwarding an m request of the Client to a Primary node through a non-Primary node which receives the m request, wherein the non-Primary node is a node except the Primary node in the block chain;
s76, judging whether the non-Primary node which has forwarded the m request to the Primary node receives the response of the Primary node within the valid time, if yes, jumping to the step S3, and if not, jumping to the step S77;
s77, polling and selecting the next node as the Primary node in the Primary node alternative set, switching view views, and retransmitting the request m by the Client side under the current view.
According to the method, a set of multivariate node reliability quantification methods considering weight is set by analyzing and quantifying the attributes of each node device in a block chain in a network, quantification values are obtained by a vector and matrix method, and Primary nodes are selected according to the quantification values, so that the probability of failure of the Primary nodes in the block chain is reduced, the frequency of view change is effectively reduced, the delay is reduced, and the method has high stability and high transaction throughput; a plurality of broadcasting and responding mechanisms are set in the mutual communication and response process of each node, and the number of invalid or malicious nodes which can be tolerated by a block chain system of normal nodes is guaranteed in a plurality of links, so that the overall safety, real-time performance and stability of the system are all suitable for severe scenes such as finance.
Claims (5)
1. A block link point consensus method suitable for a real-time transaction scene is characterized by comprising the following steps:
s1, electing a Primary host node;
s2, initiating an m request to a Primary master node through the Client side, and receiving the m request through the Primary master node;
s3, distributing a sequence number n to the m request through the Primary master node to form a Pre-prepare message, broadcasting the Pre-prepare message to all follower nodes in the block chain, and storing the Pre-prepare message in a log of the Primary master node;
s4, checking the Pre-prepare message through all follower nodes;
s5, respectively storing the checked Pre-Prepare messages in log logs of all follower nodes, and respectively broadcasting the Prepare messages through all follower nodes;
s6, checking the Prepare message received by each node, and adjusting the working state of the checked node to be a Prepared state;
s7, broadcasting Commit information through the node reaching the Prepared state, and verifying the Commit information receiving and executing condition, realizing the Client end transaction confirmation;
step S1 includes the following steps:
s11, establishing a multi-element model according to the block chain network characteristics and the financial application environment to obtain an attribute vector x ═ x of each node1，x2，…xNIn which x1，x2，…xNThe attribute of the node is N, the total number of the attributes is N, and the value of N is an integer not less than 1;
s12, evaluating the attribute vector x of each node through membership degree＝{x1，x2，…，xNQuantizing the credibility of each attribute to obtain a credibility matrix R of each node;
s13, establishing attribute weight vector w of each node according to importance degree of each attribute of the block chain node1，w2，…，wN}；
S14, calculating a credibility vector v of each node according to the credibility matrix R and the attribute weight vector w of each node;
s15, dividing each node of the block chain into a trusted node, a general node and an untrusted node according to the credibility vector v of each node, and adding the trusted node into a Primary master node alternative set;
s16, taking M consensus of each block chain as a period, and in one period, switching views to replace Primary master nodes to poll and select the Primary master nodes in a Primary master node alternative set;
confidence matrix of each node in step S12
Is an Nx 3 matrix, and in the ith row element: r isi1Representing the node attribute vector x ═ x1，x2，…，xNIn xiCredible membership of the attribute; r isi2Representing the node attribute vector x ═ x1，x2，…，xNIn xiGeneral credibility membership of the attribute; r isi3Representing the node attribute vector x ═ x1，x2，…，xNIn xiUntrusted membership of an attribute, i ∈ [1, N ]]。
2. The method for block link point consensus in real-time transaction scenario according to claim 1, wherein the step S14 is performed by the following steps:
v＝{v1，v2，v3}＝w·R (1)
wherein v is1Is the credible membership, v, of the node2Is the general credible membership of the node，v3Is the untrusted membership of the node.
3. The method for block link point consensus in real-time transaction scenario according to claim 1, wherein said step S4 comprises: performing signature verification on the Pre-prefix message; verifying whether the Pre-prepare message is a message of a view where the follower node of the current follower is located; verifying whether the current follower node receives a message except the sequence number n under the current view; it is verified whether the Pre-prepare message is within the current reception window.
4. The method for block link point consensus in real-time transaction scenario according to claim 3, wherein said checking operation of step S6 comprises: verifying whether a Pre-prefix message exists in a log of a current node; and verifying whether the current node receives 2f Prepare messages from other nodes, wherein f is the number of invalid or malicious nodes which can be tolerated by the block chain system.
5. The block link point consensus method of claim 3, wherein said step S7 further comprises the steps of:
s71, broadcasting Commit information through the nodes reaching the Prepared state;
s72, executing the Commit message through the node which has received the Commit message sent by 2f +1 nodes and has broadcast the Commit message, and sending feedback to the Client;
s73, judging whether the feedback number received by the Client side in the effective time is larger than f, if so, ending, otherwise, jumping to the step S74;
s74, broadcasting the m request to all nodes through the Client;
s75, forwarding an m request of the Client to a Primary node through a non-Primary node which receives the m request, wherein the non-Primary node is a node except the Primary node in the block chain;
s76, judging whether the non-Primary node which has forwarded the m request to the Primary node receives the response of the Primary node within the valid time, if yes, jumping to the step S3, and if not, jumping to the step S77;
s77, polling and selecting the next node as the Primary node in the Primary node alternative set, switching view views, and retransmitting the request m by the Client side under the current view.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010175157.3A CN111404928B (en) | 2020-03-13 | 2020-03-13 | Block chain link point consensus method suitable for real-time transaction scene |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010175157.3A CN111404928B (en) | 2020-03-13 | 2020-03-13 | Block chain link point consensus method suitable for real-time transaction scene |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111404928A CN111404928A (en) | 2020-07-10 |
| CN111404928B true CN111404928B (en) | 2021-07-06 |
Family
ID=71430860
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010175157.3A Active CN111404928B (en) | 2020-03-13 | 2020-03-13 | Block chain link point consensus method suitable for real-time transaction scene |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111404928B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107103098A (en) * | 2017-05-12 | 2017-08-29 | 曾建伟 | A kind of block chain net type database comprising intelligent contract and method of work |
| CN110460536A (en) * | 2019-08-26 | 2019-11-15 | 中国工商银行股份有限公司 | For the data processing method and device of block chain, medium and electronic equipment |
| CN110727731A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for adding node in block chain network and block chain system |
| CN110730204A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for deleting nodes in block chain network and block chain system |
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10225273B2 (en) * | 2017-01-27 | 2019-03-05 | International Business Machines Corporation | Secured event monitoring leveraging blockchain |
| CN109819022A (en) * | 2019-01-11 | 2019-05-28 | 华侨大学 | A kind of block chain common recognition method based on credit appraisal |
-
2020
- 2020-03-13 CN CN202010175157.3A patent/CN111404928B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107103098A (en) * | 2017-05-12 | 2017-08-29 | 曾建伟 | A kind of block chain net type database comprising intelligent contract and method of work |
| CN110460536A (en) * | 2019-08-26 | 2019-11-15 | 中国工商银行股份有限公司 | For the data processing method and device of block chain, medium and electronic equipment |
| CN110727731A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for adding node in block chain network and block chain system |
| CN110730204A (en) * | 2019-09-05 | 2020-01-24 | 阿里巴巴集团控股有限公司 | Method for deleting nodes in block chain network and block chain system |
| CN110796547A (en) * | 2019-10-30 | 2020-02-14 | 桂林电子科技大学 | Improved practical Byzantine fault-tolerant system based on alliance block chain |
Non-Patent Citations (4)
| Title |
|---|
| 《SBAC: A secure blockchain-based access control framework for information-centric networking》;Qiuyun Lyu,et.al;《Journal of Network and Computer Applications》;20200131;全文 * |
| 《Trust-PBFT: a PeerTrust-based Practical Byzantine Consensus Algorithm》;Wei Tong,et.al;《2019 International Conference on Networking and Network Applications (NaNA)》;20191231;第I-V节 * |
| 《区块链共识算法的比较研究》;陈玎乐;《计算机电子与软件》;20191231;全文 * |
| 《基于SBAC共享拜占庭自动提交协议的研究》;贺新征等;《河南广播电视大学学报》;20200131;第一至五节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111404928A (en) | 2020-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2021244211A1 (en) | Blockchain message processing method and apparatus, computer and readable storage medium | |
| US20160057201A1 (en) | File Uploading Method, Client, and Application Server in Cloud Storage, and Cloud Storage System | |
| WO2023050556A1 (en) | Smart contract consensus algorithm | |
| CN112860482B (en) | Block chain consensus performance optimization method | |
| Klaokliang et al. | A novel IoT authorization architecture on hyperledger fabric with optimal consensus using genetic algorithm | |
| CN113568577B (en) | Distributed grouping storage method based on alliance block chain | |
| WO2022105550A1 (en) | Eclipse attack detection method and apparatus for blockchain | |
| CN112395113B (en) | Practical Bayesian fault-tolerant consensus method and device and readable storage medium | |
| CN102025783A (en) | Cluster system, message processing method thereof and protocol forward gateway | |
| WO2023020242A1 (en) | Blockchain-based data processing method and apparatus, computer device, computer-readable storage medium, and computer program product | |
| CN114745140B (en) | Urban planning field block chain consensus verification method and system based on aggregation encryption | |
| KR20220074971A (en) | Blockchain-based data processing method, apparatus and device, and readable storage medium | |
| CN114663104A (en) | PBFT based on block chain product supply chain tracing | |
| CN116366673A (en) | Data analysis and sharing method oriented to management of power grid information machine room | |
| CN115022022A (en) | Method for improving Raft consensus mechanism based on node past behavior analysis | |
| CN111404928B (en) | Block chain link point consensus method suitable for real-time transaction scene | |
| Xie et al. | Trust model based on feedback evaluation in cloud manufacturing environment | |
| CN108462737B (en) | Batch processing and pipeline-based hierarchical data consistency protocol optimization method | |
| WO2022141024A1 (en) | Blockchain technology-based business transaction method and system, and storage medium | |
| CN115829731A (en) | Transaction information processing method and device | |
| CN111422078B (en) | Electric vehicle charging data allocation monitoring method based on block chain | |
| Li et al. | A framework to support survivable web services | |
| Lei et al. | Improved Method of Blockchain Cross-Chain Consensus Algorithm Based on Weighted PBFT | |
| Yuejuan et al. | Task scheduling algorithm based on reliability perception in cloud computing | |
| Ren et al. | Improved PBFT consensus algorithm based on node role division |
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 |