CN109964446B - Consensus method based on voting - Google Patents

Abstract

The invention is suitable for the field of internet technology improvement, and provides a consensus method based on voting, which comprises the following steps: s1, selecting a housekeeper on duty, and judging whether the block to be generated is a special block by the housekeeper on duty; s2, the attendant sends the generated Pre-Block to all committee nodes and waits for the signatures of the committee, and whether the number of the signature verification of the committee nodes received by the attendant is more than half of the signature of the committee is judged; s3, judging whether the effective block is overtime; s4, determine whether the valid block is a special block. In the aspect of compliance supervision, the alliance node is allowed to comprehensively manage generation and confirmation of transaction data, and compared with a public chain algorithm, the system has the controllable effect that data on a chain can be maintained and required data can be provided for an auditor only by more than half of committees.

Description

Consensus method based on voting

Technical Field

The invention belongs to the field of internet technology improvement, and particularly relates to a novel consensus mechanism method facing a alliance chain based on voting.

Background

2008, the inventor published a paper about Biken at P2P Foundation website^[1]The prototype of the peer-to-peer electronic money system described in the paper without third party intervention was implemented in the second year. The first of the blockchain technologies to become from this bitcoin is also the most widely used blockchain system that has been developed to the largest scale at a later time. The bitcoin system establishes trust in an untrusted network in a completely decentralized manner, value transfer which cannot be realized by the traditional internet is realized on the internet, and a blockchain technology is considered to be a bottom comprehensive technology which is extremely likely to subvert the financial industry as a bottom technology derived from the bitcoin system, as shown in fig. 1.

The blockchain can attract such strong attention because in the era of 'information internet', information on the network is public and transparent, but can be freely tampered to become untrustworthy, and a third party organization is required to provide trust guarantee. The biggest drawback to internet commerce is that once a third party platform offering a trust guarantee closes, the trust it provides is a foam. BlockThe chain technology is based on the principle of cryptography rather than credit, and is the basic technology for constructing bitcoin network and encrypting and transmitting transaction information^[1]. It enables any agreed upon parties to directly generate a transaction^[34]No third party intermediary is required to participate. More importantly, there is almost no single point of failure in the blockchain, and the data on the chain is stored in countless machine nodes around the world, so that the data is 'stable', 'trusted' and 'untampered', which gives the data on the internet a new value that can be trusted. It is therefore believed that blockchains will likely drive the implementation of the "information internet" to "value internet" transition.

Just because the blockchain can realize value exchange of the internet, and in addition to the advantages of Distributed type (Distributed), mediated removal (Distributed), non-falsifiable (Immutable) and Concealment (concessional), the blockchain can make up the defects of centralized management of the traditional financial institution, greatly reduce the operation cost, improve the stability and reduce the risk of single-point faults. The Spanish Santanda bank issues a report that if the block chain technology is used in the global banking system, 200 hundred million dollars can be saved each year by 2020, so that a plurality of financial institutions successively add in the financial market application research line and row of the block chain technology ^[4]. In 2012, france first acknowledged "Bitcoin legitimacy adjudication", the money bank indicated that "virtual currency will become mainstream within three or five years"; in 2013, bitcot ATM was first introduced in san diego in the united states, and germany also publicly recognized the value of bitcot currency; in 2014, Bitcoin was acknowledged by large enterprises such as Daire, Microsoft, Expedia, PayPal and the like; in 2015, the united states approved the use of bitcion blockchains to issue stocks at stock exchanges; in 2016, the federation of super ledger (hyper) projects united by top-level banks in the world was hundreds; in 2017, a block chain technology is formally introduced into the australian stock exchange for stock exchange, and the national people bank (PBoC) publishes a digital currency institute which establishes a special research block chain and digital currency^[58](ii) a In 2018, zero knowledge proof technology derived from block chains is selected from Ma province science and technology review (Ten major breakthroughs in the world) "^[75]. More and more blockchain hot spots are largeThe occurrence of events and the affirmation and introduction of blockchain technologies by the central rows of various countries show the broad prospect of hiding the spotlighted blockchain technologies in the aspects of finance, insurance, banking and other businesses.

In addition to financial applications, the use of blockchain technology has now extended from asset transactions, bank settlements to the internet of things (ADEPT) ^[60]Electronic commerce (OpenBazaar)^[61]、Skuchain^[62]、Purse^[63]) Supply chain management (Vechain)^[64]) Factom (Factom) anti-counterfeiting^[65]、Blockai^[66]) And file storage (MaidSafe)^[67]) Operating system (also known as the cloud)^[68]) And the like. The multi-point backup storage and non-falsification characteristics of the block chain technology can solve the pain point difficulties in finance, public welfare, supervision, counterfeiting and other aspects, so that the block chain technology is rapidly spread, and evolves to seek innovative opportunities and challenges for various industries.

However, The blockchain is still in The new exploration and development stage at present, and The mature application experience except bitcoin is lacked, especially The DAO attack event appearing in recent years^[40]And Ethernet congestion events caused by' encrypted cat^[58]And a great question mark is marked on the technical maturity of the block chain from the aspects of safety and performance. Therefore, to advance the development of this emerging technology with revolutionary and subversive potential, one needs to "cool" in the extreme heat of application to avoid deliberate frying and blind pursuits. The development of the blockchain needs to study more core technologies from the technology itself, such as innovation and improvement of consensus mechanisms, etc., improvement of application architecture of the blockchain, etc. The emerging technology can gradually change the defects of a centralized management mode which is a cause of scaling in the traditional industry in the innovation of one step of one footprint, and injects new blood and power for the development and progress of human beings.

The blockchain is derived from a unique way of encrypting currency storage data such as bitcoin, and can store all past historical data, transaction records and other related information in a self-referenced blockchain mode on a data storage structure. The generated mass data is distributed and stored in a P2P network, and is packaged into a string of data blocks by using a cryptographic method, each data block comprises key identification information (hash) of the previous data block in a chain structure, so that all the blocks are connected in a chain manner according to the time sequence to form a global distributed log record. If one wants to tamper with a certain data in a certain block, the block and all the following block information need to be recalculated. Bitcoin introduces a consensus mechanism for blockchain technology, making the act of hacking data computationally almost impossible to implement. The block chain is a composite technology which is integrated by technologies such as distributed storage, cryptography, a consensus mechanism, point-to-point transmission and the like, and the core breakthrough of the block chain is that spontaneous consensus which takes the benefits of maintenance groups as the core is achieved in a decentralized environment.

What is a consensus problem? In the typical application of blockchains, digital currency, a series of related security and management issues are faced, e.g., how does the precedence of transmission of blockdata to various distributed nodes control? How to deal with the problem of data loss during transmission? How does a node handle erroneous or forged information? How to ensure consistency in information updates and synchronization between nodes? The solution of these problems can be traced back to the byzantine fault tolerance problem, but how to study the block chain-specific consensus mechanism on this basis becomes the problem of the first consideration for each block chain application.

The consensus mechanism is a mathematical algorithm for implementing fault-tolerant communication between P2P nodes on a distributed consistency basis in a blockchain system. By means of cryptography and smart distributed algorithms, blockchains enable participants to agree in a distributed system without the intervention of a third-party centre.

Currently, blockchains can be classified into public, federation, and private chains. The block chain technology is good at public chain, but in practical application, the public chain is limited by the inconsistent reaction of each country because of the characteristics of complete disclosure and transparency, untraceability of private information and uncontrolled supervision. The alliance chain is a compromise choice between private chain and public chain scenarios, and is rather suitable for realizing 'partially decentralized' alliance ecology among a part of existing commercial institutions, so that operation among alliances is more efficient and fair. From the fact that all large international finance huge successively participates in the R3 CEV blockchain project [58], financial institutions are more suitable for forming financial groups and constructing an application scene of a alliance chain. Research into the proprietary consensus mechanism of the federation chain has become non-negligible.

However, the public link consensus mechanism represented by PoW consensus of bitcoin severely limits the applicable scenes of alliance links due to the characteristics of high energy consumption and low performance, and thus various novel consensus mechanisms are endless, but few studies are made on the trend of deep analysis and summary of the existing consensus mechanisms and searching for consensus development from the existing consensus mechanisms. The subject is to develop research work under the background, research the development trend of consensus by analyzing and summarizing the characteristic characteristics of the existing consensus mechanism and integrate the advantages of various consensus, and provide a novel high-performance special consensus mechanism for the alliance chain.

The consensus mechanism plays a critical role in blockchain applications, directly affecting the security and performance of blockchain products. The common recognition mechanism has no good or bad points, and different common recognition mechanisms have different products and application scenes suitable for the common recognition mechanisms, so that different common recognition mechanisms are proposed and researched since the birth of a block chain. The nature of the consensus mechanism in blockchains dates back to the distributed consensus algorithm that was studied since the last century, but blockchain consensus mechanisms incorporating incentive mechanisms were discussed and studied step by step for an emerging direction after 2008, as shown in fig. 2.

PoW: proof of Work, Proof of workload^[1]. The PoW consensus mechanism is the most widely used consensus mechanism in existing block chains. As a Nakamoto consensus of blockchain meta-aging, the design concept of proof of work (PoW) has become a classical idea of blockchain consensus. Bitcoin uses PoW based hash functions, which are common knowledge nodes-miners need to find a random value so that when the random value is hashed with additional chunk parameters (e.g., Merkle hash, previous chunk hash), the hash result must be less than the current target value. When such a random number is found, the miners The block may be encapsulated and forwarded to nodes connected thereto in the peer-to-peer network. Other peers in the network may compute a hash of the block and quickly verify whether this random number is valid by checking whether its result value meets a condition less than the current target value. In the design of this clever, PoW is the pillar that ensures mining and bitcontour safety, as shown in fig. 3.

PoW is known as Nakamoto consensus, where participants accept the longest chain of proof of workload (PoW) as historical transactional data for the system and attempt to contribute blocks to the longest chain by expanding it. Accordingly, the historical transaction data of cryptocurrency is also referred to as distributed ledger or blockchain data. While achieving great success, PoW also has some drawbacks. The most serious drawback is its limited throughput and long transaction validation time. For example, currently on average one tile may be added every ten minutes [7 ]]And it is recommended to wait for the yield of six subsequent blocks to ensure the data security of the block, which means that the transaction data of the block is about one hour of validation time. In addition, current bitcoin has a block size of about 2MB after the isolation witness activation, and each block may contain about 1500 transactions. This results in a throughput of about 2.5 transactions per second. Meanwhile, the waste of power resources by the PoW is very serious, and the electric energy consumed by the PoW mining by the Czech is close to 45 percent of the electric energy of the current ground ^[6]. In addition, PoW presents a "51% computational attack"^[8]When the attacker's hash computation power exceeds 51%, it may cause double payment and loss of security.

PoS: proof of rights^[3]. In 2011, a digital currency enthusiast named Quantum mechanics proposed the PoS mechanism in the Bitcointalk Forum. PoS was originally proposed as an idea, and a supplementary solution is proposed to solve the problem of great energy waste of PoW. PoS uses entitlement proofs in place of workload proofs in part, and this mechanism proves to be viable after being fully discussed. The coin age (coin age) concept discussed therein is considered to be another viable design beyond the PoW design, with coin age (coin days) representing the time a particular token is up to date on a network transactionThe number of currency days is increasing in those hands that are held for long periods of time and that do not use currency. The number of currency days can therefore be considered as representative of the rights of the nodes in the network, with the proof of rights being achieved by the number of currency days destroyed per transaction (coin days). When the coins are used for generating transactions, corresponding coin days are destroyed, which means that the whole network randomly elects the leader according to the distribution of the coins and the fluctuation of coin ages, and the coin days in the hands of the nodes of the leader which is not elected for a long time can be continuously accumulated to improve the probability of next elected leader, and the randomness and the safety of the election of the system leader are increased. This approach can replace most of the guarantees currently provided by workload verification pows, and the best blocks in a PoS are measured by the total number of days to destroy coins, not exactly by the total workload.

The PoS solves two pain points of energy waste and concentrated calculation power of the PoW at a time, theoretically can shorten consensus delay and improve performance, but the PoS is easy to diverge and needs more block confirmation to ensure safety. Although some details of security are optimized in the process of developing into pos2.0 and pos3.0 later, and different currencies except for the similar currency as the point currency, the black currency and the like are also created in the process of evolution, the security and the fault tolerance of the currency are not strictly demonstrated by mathematics.

DPoS: delegate Proof of title^[2]. The Larimer team proposed DPoS white paper in 3 months 2014, the first of which was bitwise stock (Bitshares)^[36]. The bitcoin system using PoW has also emerged as its computing power has become more and more focused due to the advent of mine pools and ASIC mining machines, and there has been some public opinion that PoW has deviated from the "one CPU ticket" decentralization "initiative. The Larimer team believes that decentralization of PoS may rely on a certain number of representatives, rather than all of the stakeholders, who have the voting right. The DPoS mechanism expects to relegate billing rights to those people who hold digital currency, letting each person who holds a BTS (bitburst currency) vote on the nodes of the election representatives in the entire system resource. The 101 nodes that get the most votes get the right to perform the encapsulation calculation for the block, In a random, unpredictable order. DPoS is expected to solve the problem of PoW power concentration, with the rights being evenly distributed among 101 CPUs, with each CPU having exactly the same rights as the other. These representative nodes, which can be accounted and verified, are voted out by the bearer of the entire network. DPoS is similar to the american conference system, except that election can occur at any time. Therefore, the accounting and verification nodes of the DPoS are reduced from the nodes of the whole network to a certain number of nodes, and the delay of a second level can be declared. However, DPoS still depends on token operation, and to achieve a high number of block acknowledgements required for certain security, 51% of the 100 blocks after a transaction is written into a block are produced, and the transaction can be considered secure on the backbone.

Ripple Consensus: rayleigh consensus mechanism^[4]. Ripple was born in the US silicon valley and developed by the Ripplelabs Ribo laboratory. The regen consensus mechanism has created the first open clearing payment network in the world that can be used for payments, transfers, exchanges, and clearing in any currency, including rmb, dollars, euros, yen, and even bity. The consensus of the Rayleigh consensus mechanism is mainly achieved among verification nodes (validating nodes), a tracking node (tracking node) is mainly responsible for distributing transaction information and an account book request of a user client, and the authorization of voting for the transaction is limited by configuring a trusted white list among the verification nodes. Meanwhile, the verification node is a node which has permission to write new account book instance data in the protocol, and all functions of the tracking node are also included. In a Ripple network, after a client (user) initiates a transaction, a verification node and a tracking node spontaneously forward and verify the transaction, and collect the legal transaction into a transaction candidate set which is sent to other verification nodes as a proposal; the verification node receiving the proposal compares whether the transaction is verified by the verification node and the node from the white list to decide whether to vote for the transaction; after multiple rounds of voting, the transaction confirmed by the 80% white list node is formally written into the distributed Ledger to become a Closed Ledger (Last Closed Ledger). In the Rayleigh consensus algorithm, the high efficiency brought by the node identity disclosure can ensure that the transaction reaches the second-level confirmation, which also determines the consensus The algorithm is only suitable for application scenes with permission, and the security of the algorithm can tolerate the Byzantine errors of 20 percent of nodes in the whole network.

Casper: betting consensus^[5]. Vitalik Buterin was proposed by the Etheng founder in 2015 12 months, and a brand-new concept is introduced to the field of consensus by combining open economics as the basis of the subsequent consensus development of the Etheng: and (6) betting consensus. The betting consensus is proposed to solve the serious security problem caused by 'innocent relations' in PoS, and a new process is implemented on the basis of PoS to punish the malicious attack behavior. Etherhouses originally used the consensus mechanism of PoW + PoS, but their founders have been working on translating the consensus mechanism completely towards PoS due to a large waste of computing power. Casper's proposal solves the maximum security problem of PoS, where verifiers in the network bet on the newly emerging blocks they approve for verification, in proportion to their own ethernet currency as a margin. If the block successfully links, the verifier of the wagering will be rewarded; conversely, any off-line consensus node or verifier attempting to do a "no interest" event (such as betting on a block that is not behind the longest chain) will be penalized, with all its benefits cancelled out. The Casper can enable the Ethern to completely get rid of the defects of high energy consumption and easiness in network congestion caused by PoW, the consensus efficiency and the network throughput are greatly improved, and the Ethern is expected to be upgraded to the Casper consensus on a large scale in 2018.

PBFT: practical Byzantine Fault Tolerance, a Practical Byzantine Fault tolerant^[6]. The algorithm has been proposed by Castro as early as 1999, and the problem that the original Byzantine fault-tolerant algorithm is low in efficiency is solved. The method reduces the complexity of the algorithm from exponential level to polynomial level, so that the Byzantine fault-tolerant algorithm becomes feasible in the application of a practical system. The method belongs to a state machine Byzantine protocol, is one of consensus algorithms realized and recommended by IBM HyperLedger, and the fabric item in the HyperLedger also realizes the state consistency of a code execution result by using a PBFT-based self-using consensus protocol and introduces a code execution result signature for verification. All nodes in the PBFT protocol maintain a state and adoptAnd performing consistency, checkpoint and view change protocols. The consistency protocol distinguishes different states and is configured into a view, and a server in the view consists of a master node and other slave nodes, wherein only one master node is provided. In one view, the client needs to go through 5 stages of request, pre-prepare, commit and reply, and the master node broadcasts the consistency request and finally summarizes all responses, and if a certain number of responses are received, it is proved that the slave node is in a committed state, and the response is the final result of the consistency operation. If the master node fails to work due to downtime, the slave nodes drive all the nodes to enter a view changing state by the broadcast message. After the view changes of all nodes are agreed, the new master node will open a new view state. The PBFT can achieve the second-level consensus delay, basically meets the requirement of commercial real-time processing, can realize the characteristic of disengaging tokens while improving the throughput, and has the fault tolerance shown as tolerating malicious node attacks which do not exceed 1/3. General PBFT is applied in private chain and federation chain scenarios where strong consistency is required.

dFT: delayed BFT, authorized Byzantine Fault tolerance^[7]. In 9 months in 2015, after a termite project is formally established for one year, Onchain issues a white paper of a termite consensus algorithm, and an improved Byzantine fault-tolerant algorithm is provided as a consensus mechanism module applicable to a block chain system. The dBFT sets the system nodes into two roles: a general node and a billing node. The accounting node is an important node in the consensus process and is responsible for collecting and serializing transaction messages in the network and recording the transaction messages into a distributed account book maintained by the whole network; the common node does not participate in the consensus process and is only responsible for sending and forwarding the transaction message. The dBFT is formed after improvement on the basis of the PBFT, the response mode of the C/S architecture is modified into a P2P mode suitable for a peer-to-peer network, and dynamic joining and exiting of nodes can be realized; the system works in a time synchronization state, each round of consensus generates a block within a certain time interval, and each block may be generated through different views; one node acts as the chairman (leader) and the other nodes are the agenda (followers) in one view, when the chairman gets over a certain numberWith the block certification support of the agenda, a new block consensus can be achieved. The dBFT is applicable to a alliance chain and a private chain, and the problem of authentication of the identity of a common node is solved by introducing a digital certificate. The white paper of dBFT does not demonstrate an improvement in performance level, but it shows that malicious node attacks of no more than 1/3 can be tolerated in terms of fault tolerance.

Paxos^[9,50-52]Is a consistency algorithm based on message passing and having high fault-tolerant characteristics proposed by Leslie Lamport in 1990. Paxos divides system nodes into three virtual roles of promoser, Acceptor and Learner, and one node can play multiple roles in actual operation. Paxos behaves as a three-phase protocol: the method comprises the steps that a prepaser sends a Prepare request to an Acceptor, after the response of half of the Acceptor is received, a Learner of each node is informed to realize final consistency, and otherwise, a three-stage process is repeated to carry out a new round of consistency. Paxos is essentially a consensus mechanism based on leader elections, where leader nodes possess absolute authority and allow strong supervising nodes to participate. The method has the advantages of high performance, low resource consumption, strict demonstration on the correctness and reliability of the algorithm, very high position in the traditional distributed consistency algorithm and wide application. The design of Paxos only considers the change of one value to reach the consistency, and as the Paxos protocol does not allow the wrong node with malicious attack in the system, the Paxos protocol has no fault tolerance and can provide consistency service as long as n/2+1 nodes are ensured not to be down. The Paxos is designed without considering the application in the block chain, but mainly considered to be applied in a distributed storage system, and all nodes generally adopt an admission mechanism under a wired network, so as to be used as a consistency protocol with extremely high robustness, and the Paxos can be modified and applied in a private chain scene.

Raft^[10]Also a traditional distributed consistency algorithm, which is an improved Paxos. Doctor's Diego onggaro, stanford university, has worked on the Paxos protocol as its own doctor topic. In autumn 2014, the doctor formally published the doctor paper consenssus: briting THEORY AND PRACTICE, and presented an implementation algorithm of the distributed consistency protocol, which simplifies the Paxos protocol, namely Raft. In Raft, a node can pose at any timePerforming one role of three roles, namely Leader, Follower and Candidate, and realizing a consistency process in two stages; the first stage is an election process, any node can send election requests to all nodes by the identity of Candidate, and becomes a Leader after receiving more than half votes; in the second stage, the Leader sends a consistency instruction to all nodes, namely a follow, so as to realize log replication, and log replication operation is performed through periodic heartbeat messages to ensure strict consistency of all nodes. And only when the Leader is down and cannot work, entering the next round of Leader election process. Raft greatly simplifies Paxos, and the characteristic of easy realization and comprehensibility of Raft enables most consistent scenes to realize Raft, and the method has the defects that the theoretical verification of the correctness of the simplified algorithm is not as good as that of Paxos, but the method still keeps the characteristics of being consistent with Paxos, being capable of tolerating half or less of nodes down and not allowing malicious nodes, and is suitable for private chains.

The mainstream consensus mechanism of big chain discussion communities is introduced since the advent of Bizhou, and many improved versions or new consensus mechanisms are continuously introduced in the progress of research on the Block chain consensus mechanism.

Ittay Eyal et al published their recent research results at the 2016 th US ENIX Symposium on NSDI conference and proposed a new scalable blockchain protocol to address the scalability limitation inherent in the Bitcoin-derived Nakamoto consensus, Bitcin-NG (Bitcin Next Generation)^[16]Bitcoin-NG is a Byzantine fault-tolerant blockchain protocol, has certain robustness and has the same trust security model as Bitexin.

The delay of bitchoice-NG is limited only by the network propagation delay, its bandwidth is limited only by the individual node processing power. Bitcoin-NG breaks the blockchain operation of bitcoins into two planes: leader election and deal serialization. It divides the time into epochs, each epoch has a leader, and like bitcoins, leader elections are done randomly, rarely. Once a leader is selected, it has the right to unilaterally serialize the deal until a new leader is selected, marking the epoch of the former to end. The key idea of Bitcoin-NG is to separate transactions from leader elections. If the miners excavate (key) blocks in the PoW chain, they are selected as the leader, and then the miners/leader can be responsible for encapsulating small batch trades- — (micro-lock) trades until a new leader appears. Similar to PoW chains, the probability of a bitjoin-NG bifurcation is equivalent to a PoW chain, since (key) blocks are harder to mine. Each leader of a Bitcoin-NG can be considered a committee of a single member. Since the individual leaders are untrustworthy, any transactions they approve must still be buried in the Nakamoto PoW chain. Therefore, bitjoin-NG does not increase transaction confirmation time, although it can improve the robustness and extensibility of consensus and avoid the problem of selfish mining.

Christian Decker et al proposed Peercensus [17] in 2016 at 17 th ACM distributed computing and netmeeting. Peercenus introduced PBFT and the trade consensus committee, based on the bitcoin system, which was responsible for reconfiguring oneself using byzantine consensus, although it was not explained in detail how the reconfiguration was done, the proposal of peercenus shows that the byzantine consensus enables fast transaction confirmation of the blockchain system.

Eleftherios et al in 2016 at the 25 th USENIX safety monograph will suggest ByzCoin [18] to achieve the Byzantine consensus. ByzCoin employs multiple signatures to improve PBFT scalability, dynamically forming consensus groups of hash weight ratios that represent recently successful block miners, preserving open membership of bitcoin. ByzCoin adopts a communication tree to optimize transaction acceptance and verification under normal operation, meanwhile, the safety and the activity under Byzantine failure are guaranteed, and f failure group members are allowed to exist in the node with the optimal tolerance of 3f + 2. Byzcain generates a transaction block containing a collective signature within one minute of transaction submission to mitigate double-expense and selfish mining attacks. The tree-structured communication further shortens the consensus delay time to within 30 seconds.

Ittai et al is known by the Pass and Shi Pair^[19]The research result of (1) adopts a network model with mixed consensus and proposes a network model based on possible recognition in 2017Reconstructing Byzantine-type consensus Block chain protocol Solida^[20](Solidu is a gold coin used by the Burkitting empire, Solida is the way they spell Solidus). Ittai considers Nakamoto consensus as a probabilistic method for resolving leader disputes using computational competition, and is an imperfect way of leader election against Sybil attacks. Solida does not rely on Nakamoto consensus to complete any part of the protocol, but rather employs the traditional Byzantine consensus protocol to definitively resolve leader contention, setting up a dynamically configurable committee for contending for leadership. Committee election and transaction processing are both accomplished by Solida's byzantine consensus protocol. After they performed Solida on the test bed and measured its performance, a committee with 1000 members of Solida could make consensus decisions within 23.6 seconds with a network delay of 0.1 seconds and a network bandwidth of 75 Mbps.

In addition, improvements to BFT have also emerged, as proposed by Tendermint 2014, kwon^[12]The Stellar consensus protocol proposed by D.Mazieses in 2015 ^[13]SCP proposed by L.Luu^[14]The honeyy badger of BFT protocol, 2016 A.Miller et al^[15]The improvements are all established in a distributed environment, aiming at different defects of original block chain consensus and based on a consistency arbitration theory^[53-56]And establishing different models.

Block chain application scenario problem: from the current situation of consensus mechanism research, a universal consensus mechanism does not exist at present, and each consensus mechanism has a corresponding application scenario. Some are for a fully decentralized public chain, or a partially decentralized federation chain, or a single-centric private chain; some are for the licensed chain, or for the unlicensed chain. The DAO hacking event indicates^[40]It is not feasible to completely decentralize the system, and the real world still needs a centralized way to restrict and control the whole system, and the traditional single-center architecture is still subject to a long-standing problem. Therefore, the characteristic of "partial centralization" or "multicentrication" advocated by the alliance chain shows the application value in the real business scene, and the research on the consensus mechanism in the alliance chain scene is more worthy of research.

Data bulk redundancy problem: the block chain technology copies a plurality of distributed accounts into each node in the network, and the non-tampering property of the account data is realized by matching with a corresponding common identification mechanism, so that the safety and the reliability of the data are improved, meanwhile, a large amount of redundant copies of the data are also caused, a large amount of storage space is occupied, and particularly in a public chain network. However, if the permission chain is the permission chain of the alliance chain network, the data can be backed up in the authoritative multi-center node, and the client node only needs to initiate a data request to any point of the multi-center node. On the premise of ensuring the safety and fairness of data management and control, the method greatly reduces the waste of a large number of hard disk resources caused by data redundancy.

Problem of block data validation time: the block chain system has the problem of transaction confirmation time delay, namely the problem of long data confirmation time. Taking a bitcoin as an example, the interval of block output needs 10 minutes, and under the condition of 6 acknowledgements, the transaction acknowledgement time is as long as 1 hour. Although much improvement has been made over the 2-3 day cross-border remittance period, there is still a significant distance from ideal. The consensus mechanism proposed later is also continually investigated with the goal of reducing data validation latency.

Handling the issue of transaction frequency (throughput): throughput is one performance evaluation criterion that is important for the blockchain consensus mechanism. Taking the bitcoin before receiving the isolation verification as an example, each transaction is about 250 bytes, the block size is limited to 1MB, and the average speed of generating one block every 10min, the block chain can only process 6.67 transactions per second (about 7 TPS), and for real business applications, the transaction confirmation speed with such a low frequency becomes the bottleneck of the business applications, and the network congestion problem is very likely to be caused.

Security and fault tolerance issues: implementing trusted transactions and communications in a partially trusted network is an important feature of blockchains. At present, a hundred-percent safety model does not exist in a block chain and consensus mechanism, the fault-tolerant capability of the bit currency is 50%, and if the computing power of more than 50% is mastered by a malicious node, the block chain system of the bit currency loses the safety, so that the safety of the consensus mechanism model is proved to be a necessary condition for designing a consensus algorithm.

Problems of resource consumption and forking: the bit coin adopts a competitive calculation mining mode to mine a new block, so that a large number of nodes are subjected to idle running operation to cause waste of mass power resources, and the estimated 2020 bit coin mining energy consumption is equal to the global power consumption^[23](ii) a Meanwhile, due to the existence of computational competition, a plurality of branches are caused, and the system safety is indirectly influenced, so that the PoW-based consensus mode still consumes a plurality of energy sources for mining, is similar to the PoW and has no final consistency, and all the confirmations are only expressed in probability and are not deterministic. These two points also become the main optimization points for the subsequent consensus mechanism improvement and design.

Problems with compliance supervision: the characteristics of the block chain such as disintermediation and autonomy fade the concept of national supervision and bring impact on the current system. In a transaction network which can be controlled and managed by no one, criminal behaviors of supervision and prevention are easy to take effect, and countries keep a careful attitude on the development of digital currency. If the advantages of non-tampering and security of the blockchain can be combined, and the characteristics of allowing identity authentication in the alliance permit chain are combined, multi-center verification and supervision are implemented, which is probably a way for future development of blockchain applications, and then the design of the consensus mechanism is particularly critical.

The novel consensus mechanism is inspired by several mainstream consensus mechanisms, and meanwhile, all consensus mechanisms designed aiming at public chain scenes are realized to avoid the balance and game of two key points of safety and performance. The block chain items such as bitcoin and ether house which are high in safety and reliable and run for years are used, and the used consensus mechanism ensures the safety of the whole network as much as possible at the cost of performance sacrifice; most of the subsequently generated consensus mechanisms sacrifice complete security argumentation or make corresponding security assumptions or limitations on algorithm premises to a certain extent in order to improve the performance of the consensus mechanisms.

Reference to the literature

[1]S.Nakamoto,“Bitcoin:A peer-to-peer electronic cash system,”2008。

[2]D.Larime,“Delegated Proof-of-Stake(DPoS),”Bitshare whitepaper,2014。

[3] Gao-hang, Shu-Xue \21154, Wangmaolu, Block chain and New economic, digital Currency 2.0 era [ M ] electronic industry Press, 2016.

[4] Changeur, Korea block chain from digital currency to Credit society [ M ] Medit Press, 2016.

[5]Ethereum Foundation,“Ethereum’s white paper,”https://github.com/ethereum/wiki/wiki/White-Paper,2014。

[6]M.Castro,B.Liskov,“Practical Byzantine fault tolerance,”OSDI,Vol.99,pp.173-186,1999。

[7]E.Zhang,“A Byzantine Fault Tolerance Algorithm for Blockchain,”dBFT whitepaper,2014。

[8]Quorum,https://en.wikipedia.org/wiki/Quorum_(distributed_computing).

[9]L.Lamport,“The part-time parliament,”in ACM Transactions on Computer Systems(TOCS),1998,pp.133-169。

[10]D.Ongaro,“Consensus:Bridging theory and practice,”Stanford University,2014。

[11]M.Pease,R.Shostak,and L.Lamport,“Reaching Agreement in the Presence of Faults,”Journal of the Association for Computing Machinery.vol 27,no 2,pp.228-234,April 1980。

[12]J.Kwon,“Tendermint:Consensus without mining,”Draft v.0.6,fall,2014。

[13]D.Mazières,S.Polu,N.Barry,and J.Mccaleb,“The Stellar Consensus Protocol,”2015。

[14]L.Luu,V.Narayanan,K.Baweja,et al.“SCP:A Computationally-Scalable Byzantine Consensus Protocol For Blockchains,“IACR Cryptology ePrint Archive,2015。

[15]Miller A,Xia Y,Croman K,et al.“The honey badger of BFT protocols,”in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security.ACM,2016,pp.31-42。

[16]I.Eyal,A.E.Gencer,E.G.Sirer,and R.V.Renesse,“Bitcoin-NG:A scalable blockchain protocol,”in 13th USENIX Symposium on Networked Systems Design and Implementation(NSDI 16),2016,pp.45-59。

[17]C.Decker,J.Seidel,and R.Wattenhofer,“Bitcoin meets strong consistency,”in Proceedings of the 17th International Conference on Distributed Computing and Networking,ACM,2016,pp.13。

[18]E.K.Kogias,P.Jovanovic,N.Gailly,et al.“Enhancing Bitcoin security and performance with strong consistency via collective signing,”in 25th USENIX Security Symposium,USENIX Association,2016,pp.279-296。[19]R.Pass and E.Shi,“Hybrid consensus:E_cient consensus in the permissionless model,”Cryptology ePrint Archive,2016。

[20]I.Abraham,D.Malkhi,K.Nayak,et al.“Solida:A Blockchain Protocol Based on Reconfigurable Byzantine Consensus,”2016。

[21] Block chain + data Format Specification, http:// www.cesi.ac.cn/201712/3465.html, 2017.

[22] Yuanying, Wang Fei, Block chain State of technology development and prospect [ J ] Automation, vol.42, No.4, pp.481-494,2016.

[23] Russian miners called to claim the shutdown of the mining machine to raise environmental awareness, http:// www.8btc.com/russian-crypto-hour, 2018.

[24]A.Singh,T.W.Ngan,P.Druschel,et al.“Eclipse Attacks on Overlay Networks:Threats and Defenses,”in IEEE International Conference on Computer Communications.(INFOCOM).IEEE,2006,pp.1-12。

[25]D.Y.Zhang and B.F.Zhang,“Research on New Network Simulator NS-3,”Computer Technology&Development,2009。

[26]M.V.D.Khairnar and K.Kotecha,“Simulation-Based Performance Evaluation of Routing Protocols in Vehicular Ad-hoc Network,”International Review on Computers&Software,2013。

[27]A.Gervais,G.O.Karame,V.Glykantzis,et al.“On the Security and Performance of Proof of Work Blockchains,”in ACM Sigsac Conference on Computer and Communications Security.ACM,2016,pp.3-16.

[28]testmy.net.http://testmy.net/country。

[29]mbedTLS.https://github.com/ARMmbed/mbedtl

[30]Verizon.Verizon latency.http://www.verizonenterprise.com/about/ network/latency/。

[31]F.Armknecht,J.M.Bohli,G.O.Karame,et al.“Outsourced Proofs of Retrievability,”in ACM Sigsac Conference on Computer and Communications Security.ACM,2014,pp.831-843。

[32] Li is a line, and the digital currency distributed general ledger consensus system is designed and implemented [ D ]. inner Mongolia university, 2016.

[33]L.Luu,V.Narayanan,C.Zheng,et al.“A Secure Sharding Protocol For Open Blockchains,”in ACM Sigsac Conference on Computer and Communications Security.ACM,2016,pp.17-30。

[34]R.Khalil and A.Gervais,“Revive:Rebalancing Off-Blockchain Payment Networks,”in ACM Sigsac Conference on Computer and Communications Security.ACM,2017,pp.439-453。

[35]S.Bano,A.Sonnino,M.Al-Bassam,et al.“Consensus in the Age of Blockchains,”2017。

[36]BitShares,https://bitshares.org/。

[37]K.Toyoda,P.T.Mathiopoulos,I.Sasase,et al.“A Novel Blockchain-Based Product Ownership Management System(POMS)for Anti-Counterfeits in The Post Supply Chain,”IEEE Access,vol.1,no.1,pp.99,2017。

[38]S.Suzuki and J.Murai,“Blockchain as an Audit-Able Communication Channel,”in Computer Software and Applications Conference.IEEE,2017,pp.516-522。

[39]W.T.Tsai,X.Bai and L.Yu,“Design Issues in Permissioned Blockchains for Trusted Computing,”Service-Oriented System Engineering.IEEE,2017,pp.153-159。

[40]The DAO,http://www.8btc.com/what-is-the-dao。

[41]N.Shi,“A new proof-of-work mechanism for bitcoin,”Financial Innovation,vol.2,no.1,pp.31,2016。

[42]H.Watanabe,S.Fujimura and A.Nakadaira,et al.“Blockchain contract:Securing a blockchain applied to smart contracts,”in IEEE International Conference on Consumer Electronics.IEEE,2016,pp.467-468。

[43]A.M.Antonopoulos,Mastering Bitcoin[M],https://en.bitcoin.it/wiki/ Mastering_Bitcoin。

[44]L.Tseng,“Recent Results on Fault-Tolerant Consensus in Message-Passing Networks,”in International Colloquium on Structural Information and Communication Complexity.Springer International Publishing,2016,pp.92-108。

[45]A.Adya,W.J.Bolosky,M.Castro,et al.“Farsite:federated,available,and reliable storage for an incompletely trusted environment,”Acm Sigops Operating Systems Review,vol.36 no.SI,pp.1-14,2002。

[46]M.Abd-El-Malek,G.R.Ganger,G.R.Goodson,et al.“Fault-scalable Byzantine fault-tolerant services,”Acm Sigops Operating Systems Review,vol.39,no.5,pp.59-74,2005。

[47]J.Cowling,D.Myers,B.Liskov,et al.“HQ replication:a hybrid quorum protocol for byzantine fault tolerance,”in Usenix Symposium on Operating Systems Design and Implementation.USENIX Association,2006,pp.13-13。

[48]A.Clement,E.Wong,L.Alvisi,et al.“Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults,”in Usenix Symposium on Networked Systems Design and Implementation,NSDI,22-24 April 2009,pp.153-168。

[49]R.Kotla,L.Alvisi,M.Dahlin,et al.“Zyzzyva:speculative byzantine fault tolerance,”in ACM Sigops Symposium on Operating Systems Principles.ACM,2007,pp.45-58。

[50]E.Gafni and L.Lamport,“Disk Paxos,”Distributed Computing,vol.16,no.1,pp.1-20,2003。

[51]Chandra,D.Tushar,Griesemer,et al.“Paxos made live:an engineering perspective,”Twenty-Sixth ACM Symposium on Principles of Distributed Computing,PODC 2007,pp.398-407,2007。

[52]B.Lampson,“The ABCD's of Paxos,”Principles of Distributed Computing,2001。

[53]D.Malkhi and M.Reiter,“Byzantine quorum systems,”in Twenty-ninth Acm Symposium on the Theory of Computing.Springer-Verlag,1997,pp.569-578。

[54]M.Naor and U.Wieder,“Scalable and dynamic quorum systems,”Distributed Computing,vol.17,no.4,pp.311-322,2005。

[55]D.Malkhi,M.Reiter and A.Wool,“The load and availability of Byzantine quorum systems,”in Sixteenth ACM Symposium on Principles of Distributed Computing.ACM,1997,pp.249-257。

[56]M.Naora and A.Wool,“The load,capacity and availability of quorum systems,”in Foundations of Computer Science,1994 Proceedings.Symposium on.IEEE,1994,pp.214-225。

[57]V.Gatteschi,F.Lamberti,C.Demartini,et al.“Blockchain and Smart Contracts for Insurance:Is the Technology Mature Enough,”Future Internet,vol.10,no.2,pp.20,2018。

[58]The information of the bits of the audio signal,http://www.8btc.com/。

[59] bear Yongyang, distributed consistency problem research [ D ]. Harbin industry university, 2014.

[61]OpenBazaar,https://www.openbazaar.org/。

[62]Skuchain,http://www.skuchain.com/。

[63]Purse,https://purse.io/。

[64]Vechain.https://www.vechain.com/.。

[65]Factom.https://www.factom.com/。

[66]Blockai Launches,“'Netscape for Bitcoin'With Blockchain Browser,”https://www.coindesk.com/bloc kai-launches-netscape-for-bitcoin-with-blockchain-browser/,2015。

[67]MaidSafe.https://www.maidsafe.net/。

[68]elastos,https://www.elastos.org/。

[69] Chinese Block chain technology and applications develop white paper (2016), http:// www.fullrich.com/downloads/article/file/2016/1020/580866 e374069. pdf.

[70]K.Nayak,S.Kumar,A.Miller,et al.“Stubborn Mining:Generalizing Selfish Mining and Combining with an Eclipse Attack,”in IEEE European Symposium on Security and Privacy.IEEE,2016,pp.305-320。

[71]A.Sapirshtein,Y.Sompolinsky and A.Zohar,“Optimal Selfish Mining Strategies in Bitcoin,”in International Conference on Financial Cryptography and Data Security.Springer,Berlin,Heidelberg,2016,pp.515-532。

[72]C.Decker and R.Wattenhofer,“Information propagation in the bitcoin network,”in Peer-to-Peer Computing(P2P),2013 IEEE International Conference on.IEEE,2013,pp.110。

[73]S.Gilbert and N.Lynch,"Brewer's conjecture and the feasibility of consistent,available,partition-tolerant web services",ACM SIGACT News,vol.33,no.2,pp.51–59,2002。

[74]D.Pritchett,"BASE:An Acid Alternative,"vol.6,no.3,pp.48-55,2008.

[75] The science and technology review of science and technology of Ma province, 2018, a ten-major global breakthrough technology, http:// www.mittrchina.com/news/1720,2018.

Disclosure of Invention

The invention aims to provide a consensus method based on voting, and aims to solve the technical problems.

The invention is realized in such a way that a consensus method based on voting comprises the following steps:

s1, selecting a duty manager, wherein the duty manager judges whether the block to be generated is a special block, if so, collecting the vote transaction sent by the committee node to generate a pre-special block, and if not, collecting the transaction which is not confirmed from the memory pool to generate a pre-common block;

s2, the attendant sends the generated Pre-Block to all committee nodes and waits for the signatures of the committee, whether the number of signature verification of the committee nodes received by the attendant is more than half of the signature verification number is judged, if yes, the Block is valid and the next step is executed, if not, the verification is not passed, the Block is invalid, and the step S1 is returned;

S3, judging whether the effective block is overtime, if yes, the block is invalid and returns to the step S1, if no, the effective block executes the next step;

s4, judging whether the effective block is a special block, if so, the effective block is a qualified special block, if not, the effective block is a qualified common block, the on-duty manager sorts the received committee signatures and perfects the element information of the block header, the qualified special block or the qualified common block is issued to the whole network, and the step S1 is executed to repeat a new on-duty cycle.

The further technical scheme of the invention is as follows: the consensus method further comprises the steps of:

s0, before creating the blocks, the committee node becomes the manager candidate by self-recommendation, and selects the first manager from the created blocks and numbers it.

The further technical scheme of the invention is as follows: the method for generating normal blocks in steps S1-S4 includes the following steps:

s111, generating transaction data by any node and attaching a signature, receiving the transaction data and judging whether the received transaction data is correct or not, if so, forwarding the transaction data, and if not, discarding the data;

s112, all housekeeper nodes monitor transaction data and put effective transaction data into a memory pool;

S113, let M be 1, R be getproviousblockrandomnum ();

s114, the on-duty manager takes out some transactions from the memory pool and encapsulates the transactions into Pre-Block, and after digital signature is carried out on the hash value of the Block header, the Pre-Block is sent to all committee nodes and the manager node;

s115, the committee node receives the Pre-Block to verify the Block data, if the Block is generated, the Block head Pre-Header + hash value connected with the local timestamp character string is signed and then fed back to the on-duty manager;

s116, the attendant judges whether the time T is_cutIf the feedback information is larger than the signatures and the timestamps of Nc/2 nodes, if so, sequencing the signatures and the timestamps in an ascending order according to the timestamps, serializing the corresponding signatures and the timestamps into character strings, attaching the character strings to a Pre-Header, generating a Ready-Header, calculating an R value, taking the maximum value of the timestamps as Block generation time, adding the R value and the Block generation time on the basis of the Ready-Header, generating a Final-Header, issuing a complete Final-Block to the whole network, directly jumping to execute the step S117, if not, verifying the result, making R +1, increasing M, and returning the Block to the step S114 if not;

s117, if the block generation time is more than T_cutIf the previous block is an invalid block, the process proceeds to step S114, where R is R +1, M is incremented and the process returns;

S118, after the valid block is generated, the housekeeper R sends the block to all the committee nodes and issues the block, and determines whether the number of the committee nodes receiving the block is greater than half of all the committee nodes from the state of the whole network, if so, the block enters a legal state, has final confirmatory property, executes the next step, if not, the block is invalid, let R be R +1, M be incremented and return to step S114;

and S119, after the nodes related to the whole network receive the effective block, deleting the transaction contained in the effective block from the memory pool, acquiring the random number R contained in the effective block, starting the next round of consensus, judging whether the next round of consensus generates a special block, if so, executing the generation step of the special block, and if not, returning to the step S114.

The further technical scheme of the invention is as follows: the method for generating the special block in steps S1-S4 includes the following steps:

s121, all committees select and generate a sequence from the candidates of the incumbent caretaker and the housekeeper to form vote information and send the vote information to the on-duty caretaker;

s122, all the committees and the incumbent caretaker receive voting information of all other committees simultaneously and place the voting information into a memory pool;

s123, the attendant judges whether the number of the collected voting affairs exceeds half of the number of the committees, and if yes, the next step is executed; if not, continuously waiting until the time is out, replacing the on-duty housekeeper and executing S121;

S124, the on-duty manager takes out some things from the things pool and packages the things into Pre-Block, and sends the Pre-Block to all committee nodes and the manager node after digital signature is carried out on the hashed value of the Block header;

s125, the committee node receives the Pre-Block to verify and verify the Block data, if the generation of the board Block is agreed, the Block head Pre-Header + hash value connected with the local timestamp character string is signed and then fed back to the on-duty manager;

s126, judging at the time T_cutWhether the signatures and the timestamps of the feedback information which are larger than Nc/2 nodes are received or not is judged, if yes, the signatures and the timestamps are sorted according to the ascending order of the timestamps, the corresponding signatures and the timestamps are serialized into character strings, the character strings are attached to Pre-Header to generate Ready-Header, after the R value is calculated, the maximum value of the timestamps is taken as Block generation time, the R value and the Block generation time are added on the basis of the Ready-Header to generate Final-Header, complete Final-Block is issued to the whole network, the step S127 is directly skipped to execute, if not, the verification is failed, R is made to be R +1, M is increased in number, and the Block returns to the step S124 if not;

s127, if the block generation time is more than T_cutIf the previous block is an invalid block, the process proceeds to step S124, where R is R +1, M is incremented and the process returns to step S;

S128, after the effective block is generated, the housekeeper R sends the block to all the committee nodes and issues the block, the committee nodes receive the feedback signatures, whether the number of the committee nodes receiving the block is larger than half of the number of all the committee nodes is judged by the full-network state, if yes, the block enters the legal state and has final confirmability, and the block is calculated, votes are ranked N before the ranking_bIs selected as the next nodeThe manager for the appointed period writes the information of the new manager as a special transaction into the block and executes the next step, if not, the block is invalid, and makes R equal to R +1, and M is increased and returns to the step S124;

and S129, after the butler in the current round finishes the generation of the last round of special blocks, deleting the related voting information in the memory pool, ending the current round and jumping to a common block generation method.

The further technical scheme of the invention is as follows: the method for generating the created block in the step S0 includes the following steps:

s01, the initial committee nodes communicate with each other to confirm online, and the committee with the minimum public key Hash value is responsible for generating a created block;

s02, all committee nodes send the identity authority change affairs upgraded to the committee with the minimum public key Hash value;

S03, hope to hold concurrently and take charge of the committee node of the identity to send and apply for to all committee nodes at the same time, send the identity authority of the candidate person of the manager to change and apply for the message and attach the self-recommended signature, judge whether it is more than half of all committee nodes to receive the information that other committee nodes agree to signature feedback, if yes, this committee node produces a legal identity authority to change affair smoothly, send to the minimal committee of hash value of public key and issue to the network, the committee node in the whole network puts this affair into the memory pool and carries out the next step, if no, abandon the information that this committee node issues;

s04, all committees send votes to the committee with the minimum public key Hash value, all committee nodes extract candidate housekeeping information which is verified to pass from a memory pool, at least K candidate housekeeping account addresses are selected from the candidate housekeeping information, the candidate housekeeping account addresses are serialized into vote information and signed, and vote information is returned to the committee with the minimum public key Hash value;

s05, after the commission committee counts, integrating the affairs of' identity authority change affair upgraded to committee > < identity authority change affair upgraded to housekeeper candidate > < vote information of all committees > < new housekeeper list >, generating Pre-Block, sending to all committees, and issuing a created Block after signature confirmation of all the committees is obtained;

And S06, deleting the identity authority change transaction and vote transaction to be confirmed in the memory pool after all committees receive the creation block.

The further technical scheme of the invention is as follows: a round of duty cycle in the consensus method comprises the following steps:

s001, at the beginning of each duty cycle, creating a block R ═ 0, where R ═ getproviousblockrandomnum ();

s002, after the Bw round consensus is completed, generating Bw common effective blocks;

s003, in the last round of consensus of the duty cycle, the committee updates the scores in the candidate list of the housekeeper of the committee, votes for election and generates a special block which contains the information and the corresponding number of the new housekeeper;

and S004, circularly executing the steps S001-S004 after the end of the duty cycle.

The further technical scheme of the invention is as follows: each current value keeper in the normal block generation needs to perform a round of "Prepare-Ready-dispose- (confirm)" two-phase commit to ensure the unique validity of the block.

The further technical scheme of the invention is as follows: each block is generated with a random number that points to the housekeeping number of the next encapsulated block to ensure that the housekeeping generates blocks in turn in a random order.

The further technical scheme of the invention is as follows: the affairs in the consensus method are respectively an identity authority transformation affair, a voting affair and a self-defining affair.

The further technical scheme of the invention is as follows: the messages in the consensus method are signature messages of committees, messages sent to all committees after the housekeeper generates pre-blocks, block messages generated by the housekeeper for final confirmation, highest block height solving messages and block synchronization messages respectively.

The invention has the beneficial effects that: in the aspect of compliance supervision, the alliance node is allowed to comprehensively control generation and confirmation of transaction data, compared with a public chain algorithm, the controllability of the system can be realized by maintaining data on a chain and providing required data for an auditor only by more than half of committees; in the aspect of transaction performance, the CoV can realize throughput processing conforming to the transaction generation rate, the transaction confirmation time delay can reach 12.74s, the method is superior to most of the existing consensus mechanisms, and the application requirements of a alliance chain are met; in terms of resource consumption, the security of the system is ensured by the CoV through the credibility of the alliance committee nodes, the power energy consumption is only used for limiting the number of candidates in the manager bankruptcy model established in the text without the competitive competition of Nakamoto consensus, and the compared PoW can be almost ignored; in the aspect of fault-tolerant capability, CoV allows less than half of committee nodes to fail to work, allows not less than 1 housekeeper node to do harm, and establishes a safety model by utilizing the characteristics of a alliance chain, so that the safety of CoV is guaranteed to the maximum extent; in terms of consensus, the CoV only needs to achieve confirmation of more than half of the committees in the network to achieve block consensus, the consensus has final consistency, the final validity of the transaction can be confirmed only by waiting for one block, and each block has the final. The final decision of the system node is consistent with more than half of committee nodes, and the consistency of the system can be achieved. Compared with PoW, the transaction confirmation is faster, compared with PBFT, the election of the housekeeper node reduces the communication overhead, and the high efficiency of CoV can be embodied.

Drawings

Fig. 1 is a schematic diagram of conventional pay VS block chain pay.

FIG. 2 is a consensus mechanism development timeline.

FIG. 3 is a schematic diagram of a medium smart mining system.

FIG. 4 is a schematic diagram of public-private key encryption and decryption.

Fig. 5 is a schematic diagram of an elliptic curve cryptography algorithm.

FIG. 6 is a schematic diagram of a bitcoin asymmetric encryption scheme.

Fig. 7 is a schematic diagram of a signature incorporating asymmetric encryption.

Fig. 8 is a schematic diagram of a distributed billing network VS-centric billing network.

FIG. 9 is a block chain architecture.

FIG. 10 is a block diagram of a bitcoin.

Fig. 11 is a schematic diagram of a public chain VS federation chain VS private chain.

Fig. 12 is a schematic diagram of a conventional clearing book.

Fig. 13 is a schematic diagram of a distributed ledger.

FIG. 14 is a diagram of a consensus design separating voting rights and billing rights.

FIG. 15 is a schematic diagram of the evaluation criteria of the consensus mechanism.

FIG. 16 is a schematic diagram of a design objective of the consensus mechanism.

Fig. 17 is a schematic diagram of a CoV network model.

Fig. 18 is a CoV consensus model role transition diagram.

Fig. 19 is a schematic diagram of the CoV duty cycle.

FIG. 20 is a schematic diagram of a housekeeper's round robin process.

FIG. 21 is a schematic diagram showing the idea of two Consensuss of Vote.

FIG. 22 is a schematic representation of the duty cycle.

FIG. 23 is a flow chart of the run of the duty cycle.

Fig. 24 is a general block generation flowchart.

Fig. 25 is a special block generation flowchart.

Fig. 26 is a flow chart of proxy committee perspective-creation block generation.

FIG. 27 illustrates the block generation step 4-8.

FIG. 28 is a schematic diagram of implicit two-phase commit in CoV.

Fig. 29 is a schematic diagram of a random number algorithm.

Fig. 30 is a CoV consensus flow chart.

FIG. 31 is a generation diagram of housekeeper perspective- -normal and special tiles.

Fig. 32 is a generation diagram of committee views, normal blocks and special blocks.

Fig. 33 is a diagram of an example CoV algorithm.

Fig. 34 is a diagram of an example of creating a block.

FIG. 35 is a diagram of the first duty cycle { B0: a, B1: B, B2: c } of an example CoV algorithm.

FIG. 36 is a diagram of a second duty cycle { B0: c, B1: d, B2: e } for an example of the CoV algorithm.

Fig. 37 is a diagram of the assumption CoV bifurcation diagram 1.

FIG. 38 is a schematic chain non-branching diagram generated by CoV consensus.

FIG. 39 is a diagram of an example of federation chain non-forking.

FIG. 40 is a graph of P1 and P2 plots for optimal K values at the intersection.

FIG. 41 is a comparison of different probability of winning a ticket.

Fig. 42 is a schematic diagram of a selfish mining model of bitcoin.

FIG. 43 is a three-dimensional model diagram of the probability of failure of collision R.

Fig. 44 is a contour projection view of a "collision R" failure probability map.

FIG. 45 is a boundary diagram with a "crash R" failure probability > 0.99.

Fig. 46 is a graph showing the variation of the failure probability of collision R with γ.

FIG. 47 is a graphical representation of the probability of failure for a collision R >0.99 as a function of γ.

Fig. 48 is a diagram of performance and security gaming based on PoW consensus block chains.

FIG. 49 is a schematic diagram of the NS3 Simulator architecture.

FIG. 50 is a diagram of a CoV blockchain simulation system architecture.

FIG. 51 is a schematic representation of CoV feasibility verification.

FIG. 52 is a graph of the impact of the total number of blocks and the transaction generation rate on throughput (N)_c/N_b/N_all＝5/10/20，K＝10，B_all＝50，B_w＝20，T_d＝10s，T_b20 s).

FIG. 53 is a graph of throughput (N) within a block of a certain height at different transaction generation rates_c/N_b/N_all＝5/10/20，K＝10，B_all＝50，B_w＝20，T_d＝10s，T_b20 s).

FIG. 54 is a graphical illustration of the impact of different node sizes on throughput.

Fig. 55 is a schematic illustration of the effect of different latencies on throughput.

FIG. 56 is a diagram illustrating generating block rates.

FIG. 57 is a graph illustrating the comparison of latencies for different node sizes at four transaction generation rates.

FIG. 58 is a graph of different T_dSchematic of the effect on latency.

FIG. 59 is a diagram illustrating different consensus time delay comparisons.

Detailed Description

The consensus mechanism is based on the study of blockchain technology. The blockchain builds on traditional computer technology, merging with P2P, distributed storage, and cryptography techniques that have been studied decades ago. The success of the bitcoin project provides a feasible research direction for the fusion development of the technologies, and arouses the extensive attention and research of the block chain, as shown in fig. 4.

Principle of block chain technique

Asymmetric encryption and digital signature public and private keys: the encryption algorithm is generally divided into symmetric encryption and asymmetric encryption, and the encryption algorithm mainly applied in the block chain is the asymmetric encryption algorithm. Asymmetric encryption typically uses different ciphers in encryption and decryption, called public and private keys, respectively; the encryption and decryption passwords of the symmetric encryption are the same, so that the passwords need to be transmitted to a decryption party, and the risk of key leakage is increased to a certain extent. The information encrypted by one key (a public key or a private key) of the asymmetric keys used in the block chain can be decrypted by the other symmetric key, so that the public key can be used as an address account number to be disclosed to other people, the private key is kept secret, and an attacker cannot deduce the private key from the public key. As shown in fig. 3.

Common asymmetric encryption algorithms include RSA, Elgamal, D-H, ECC (elliptic curve encryption algorithm), etc., and the current encryption authentication mechanism in the blockchain system is based on the asymmetric encryption algorithm. The bitcoin private key space size is 2256, which almost exceeds the size of the number of all atoms in the universe. The public key of the bitcoin is calculated by elliptic curve multiplication, the process can be expressed in a formalized manner as K ═ K × G (K is a private key, G is a constant point of a generation point, and K is a public key), and the inverse operation thereof is called "finding a discrete logarithm", which is considered to be almost impossible to accomplish.

Elliptic curve encryption algorithm: the elliptic curve encryption algorithm is an asymmetric encryption method (or called as a public key encryption method) based on a discrete logarithm problem, and is realized by utilizing point operation on an elliptic curve. In order to make elliptic curve calculation applicable to encryption, it is necessary to discretize the elliptic curve (the horizontal and vertical coordinates of each point on the curve are integers and the number of points is limited), because the calculation of the decimal reduces the calculation speed greatly and the rounding affects the calculation accuracy. A simple example of a discrete logarithm problem is given a prime number p and a positive integer I, knowing the value of Ix mod p, finding x, for eligible p and I, this type of discrete problem is solved without polynomial difficulties. The bitcoin uses an elliptic curve defined by the secp256k1 standard, defined as the following function:

y²＝(x³+7)}over(Fp)or y² mod p＝(x³+7) mod p formula (2.1)

Equation (2.1) indicates that the curve is defined in a finite field of prime order p, and therefore it is difficult to plot a scatter plot in two dimensions. The mathematical principle is similar to that of a curve in the real number range, and the curve image can be known by a series of scatter points on an elliptic curve in a finite field of a small prime order (such as 17). As shown in fig. 5, the 17 scattered points, the result obtained by adding any two points (using elliptic curve addition) or any multiple of any one point between the 17 points is another one of the 17 points, thereby forming the public-private key algorithm. The actual p may be a large prime number, forming a series of more complex scatter points on the elliptical curve of secp256k1, with the number of points being p.

The process of generating the public-private key pair starts with a randomly generated 256-bit private key K, and multiplies a generation point G defined on the elliptic curve to obtain another point on the elliptic curve, and then a public key K is obtained. The operation of deriving the public key K from the private key K is irreversible, so that the address of the bitcoin (derivation of the public key) can be freely disclosed without fear of revealing the private key K.

For example:

k＝1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD

p＝FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

i.e. p 2256-232-29-28-27-26-24-1, where the resulting public key K is a point (x, y), where:

x＝F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A

y＝07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB

in an elliptic curve as shown in fig. 5, a multiple k × G of the generation points can be found. In elliptic curve calculation, the addition of points is equivalent to drawing a tangent from a given point to find another point that intersects the elliptic curve and then mapping to the x-axis. The right diagram in fig. 5 shows the geometric operations to obtain G, 2G, 4G. The addition and multiplication on the discrete elliptic curve are also similar to the rule of the elliptic curve, and the discrete elliptic curve operation cannot be expressed like a continuous elliptic curve. The number of the private key K is extremely large, K × G is equivalent to repeatedly running multiple addition operations, so that the reverse calculation from the public key K to the private key K is not possible for human to achieve with the computing power so far, as shown in fig. 6.

Hash (Hash) function: also known as a Hash algorithm, a Hash function is a function that maps a message of arbitrary length to a Hash value of fixed length, which Hash value (Hash value) can serve as an authentication identifier. Since the address space of the Hash value is huge, the difficulty of reverse operation (brute force cracking) is extremely high. In the digital signature scheme, generally, a direct signature method for all messages is not adopted, but a hash function is used for a Message to be signed to generate a Message Digest (Message Digest) with a fixed length, and finally the Message Digest is signed to obtain a signature Message with a fixed length, as shown in fig. 7, the method is more convenient and safer in code processing. Typical Hash algorithms are MD5, SHA1/SHA2, and SM3, and the Hash algorithm used for bitcoins is SHA-256.

The Secure Hash Algorithm (SHA) was designed by the american association of standards and technology (NIST) and was released in 1993 as the federal information processing standard (FIPS 180), and the ability of the Hash function to resist strong collisions directly affects its security. The existing Hash function attack methods include birthday attack, rainbow table attack and differential attack. In principle, a birthday attack can be used to attack any type of Hash function, since it depends only on the length of the Hash value, and does not take advantage of any algebraic weak property of the Hash function structure, and therefore whether the length of the Hash value is sufficient or not is extremely important to affect the security of the Hash function. SHA-1 produces a 160-bit Hash value, and in 2007 a pair of collisions of this function were found by researchers from Google corporation, NIST subsequently declared to abandon SHA-1. The SHA-256 generates 256-bit Hash values, except that the Hash values are safer than SHA-1 in length, the iterative algorithm structure of the Hash values enables the collision complexity to be increased along with the number of algorithm rounds, and a differential attack algorithm which utilizes the inherent property of the Hash function to perform collision cracking more effectively can be effectively resisted. Thus, SHA-256 is considered one of the most secure Hash functions at present.

Digital signatures and digital certificates: the digital signature and the encryption both use public and private key technology, but the purpose is different, and the purpose of the digital signature is to ensure the integrity and the trueness of the information. If the server a sends a message to the server B, in order to prove to the server B that only a of the message can be sent, a may encrypt the message M with a private key to form a signature C, after B receives the message M and the signature S, B may decrypt S by using the public key of a, and compare whether the decrypted message is the same as the sent message M to verify the integrity and authenticity of the message M, the process is as follows:

a) a signs M, calculates S ═ DA (M), and sends M and S to B.

b) B verifies A's signature by checking EA (S) for recovery to M.

c) If a dispute occurs between a and B, the signature of a can be authenticated by the method in step B).

Confidentiality is often also required in public key digital signature systems, and the signature scheme can be upgraded in conjunction with encryption techniques, as shown in fig. 7.

Distributed accounting book technology, the technical basis of which is distributed storage, is implemented between different peer nodes in a P2P network, compared with traditional distributed storage. The nodes in different places all store a complete account record, so that the transaction summary bookkeeping is not handed to the traditional centralized architecture any more, and a centralized trust mechanism is not needed to guarantee the authenticity and the integrity of the account. On one hand, all peer nodes can participate in monitoring the legality of transaction and can also jointly make a proof for legal data in an account; and different from the traditional accounting scheme, no node can be used as a centralized node to record accounts independently, but all nodes cooperate to account together and keep duplicate data consistent, so that the possibility that a single accounting node is maliciously controlled to account is avoided. On the other hand, because the accounting nodes are sufficient, the account is theoretically not lost unless all the nodes are damaged, and this situation is almost impossible, so the redundancy policy of the distributed accounting technique can effectively ensure the security of the account data, as shown in fig. 8.

The consensus mechanism provides a cooperative mode for all the accounting nodes, so that consensus is achieved among the accounting nodes to identify the validity of a record, and the consensus mechanism is an important means for keeping the validity and the non-tamper-resistance of the distributed accounting book data. The consensus mechanism on the block chain mainly solves the problem of who constructs the block and how to maintain block data unification in the peer-to-peer network, and the theoretical basis of the problem is Byzantine Fault-Tolerant (BFT)^[6]. BFT is researched from the last 80 th century till now, the preconditions and specific realization of the problem solution of BFT have already been made into ready-made algorithms, and a set of mature theoretical systems has been formed. However, the PoW consensus of the bitcoin uses a simple violence mode and combines an economic incentive mechanism to solve the Byzantine fault tolerance problem. Through a competitive mode, the data consistency of the PoW in a large-scale point-to-point network is realized, and data approved by nodes which exceed the full network power by more than 50% can be written into a block chain to form data which cannot be tampered. Heretofore, the byzantine algorithm could only be implemented in a relatively small, distributed environment.

The core of the consensus mechanism is the construction and inspection of blocks, the PoW system uses the "mine" (mine) approach to construct blocks, and the PoS system uses the "cast" (mint) approach to construct blocks. Different consensus protocols have adaptive application scenes, and no proper standard is available for distinguishing between good and bad, and the last section of this chapter will describe in detail the comparison and selection of consensus mechanisms in different application scenes.

The intelligent contract is based on the credible and non-falsifiable records and data on the block chain, and can automatically execute some rules and clauses defined by the pre-code^[42]. The technical basis of the intelligent contract is a script technology, and the automatic verification and the automatic execution of the contract can be realized on a block chain^[57]The script mechanism in the blockchain system of bitcoin is relatively simple, and only the relevant OP instructions can be interpreted based on the stack type, and the relatively complex logic cannot be analyzed. But it provides a prototype for programmability, for example, etherhouses design a complete set of picture-based complete language supporting scripts based on a script mechanism, making it possible for blockchain technology to be an underlying protocol. Taking the crowd funding Dapp project in the Etherlands as an example, if the project information for initiating crowd funding is written into the block chain (which can be considered as true and reliable, and even if deceptive behaviors are recorded into the block chain, the deceptive behaviors can be settled), automatic crowd funding and investment can be easily performed in the flow-based crowd funding process, and when the project meets the predefined condition, the crowd funding can be automatically cancelled or ended.

Block chain technology architecture and features: refer to block chain + data format Specification published in 12 months in 2017 ^[21](hereinafter referred to as "Specification"), where the concept of blockchains is formally defined: a block chain type data structure which is not forged, tampered and traceable is constructed through transparent and credible rules under a peer-to-peer network environment, and a transaction processing mode is realized and managed.

After studying the architecture of the block chain, Yuanying et al summarized and proposed the basic architecture model of the block chain^[22]. As shown in fig. 9, from the bottomThe data layer, the network layer, the consensus layer, the excitation layer, the contract layer and the application layer are respectively arranged on the network layer. The three layers of data, network and consensus at the bottom layer are necessary elements in a block chain architecture, and the excitation layer, the contract layer and the application layer at the top layer can be selectively configured on a basic architecture built by the necessary elements. The data layer encapsulates modules such as a data block structure, a chain connection structure, a timestamp technology, a Hash function, a Merkle tree and cryptography at the bottommost layer, and the modules are roots of essential elements; the network layer comprises a distributed networking mechanism, a data transmission mechanism and a data verification mechanism, and represents that the block chain network has an automatic networking function; the consensus layer encapsulates various consensus algorithms in the network nodes, is a brain of a block chain, is essentially a distributed consistency algorithm with an excitation effect, and is also the key point of the research; the incentive layer integrates economic factors into a block system and mainly comprises an issuing mechanism and a distributing mechanism of economic incentives; the contract layer mainly encapsulates various scripts, algorithms and intelligent contracts and is the basis of the programmable characteristic of the block chain; the application layer encapsulates various application scenes and cases of the block chain, and besides currency, finance and the like proposed in the architecture diagram, the application layer also comprises applications which are not listed and can utilize anti-counterfeiting traceability characteristics.

The block chain data organization structure lays an important foundation for the non-tampering characteristic of the block chain, transaction data in a network are concentrated in the block chain through the block chain structure and a cryptographic hash function algorithm, each block is connected with the previous block, Merkle root values obtained through pairwise hashing of all transactions (called transactions in bitcoin) are utilized, the non-reverse-destructible characteristic of the hash function is utilized, once a certain transaction in a block is tampered, Merkle at the head of the block can be correspondingly changed, otherwise, verification is failed, and the integrity of the data in the block is ensured. The uniqueness of each block is represented by hashing the block header to obtain a unique hash value for the block, as shown in fig. 10.

The hash value of the previous block is smartly added into the block head, so that the current block uniquely points to the previous block in the process of checking the correctness to form a unique chain type structure of a block chain, the identification pointing to the latest data block on the chain is always put into the current block in the process of adding new data, the tampering of any data in the chain type structure can interlockingly cause the modification of the subsequent block to ensure the correctness of the subsequent block, the structure does not allow or cannot modify the data which is added into the chain and is confirmed, otherwise, the interlocking effect is triggered to cause the data on the chain to fail to pass the checking, and the completeness, the reality and the safety of the data of the whole block chain are ensured.

The block chain characteristics depend on a plurality of core technologies of the block chain, particularly on a consensus mechanism and a cryptography technology, the block chain has strong technical advantages in the aspect of decentralization (weak) and the presented different characteristics also determine various application scenarios.

(1) Decentralization: high efficiency and low cost, solve the intermediate cost problem? The trust mechanism of the block chain is based on the asymmetric cryptographic principle and is a pure mathematical encryption method. The safety of personal privacy information of a transactor behind the data is also ensured while the information sharing in the network is realized. This allows trusted value exchange between parties to a transaction in a blockchain network in a strange mode. Meanwhile, in a decentralized network system, the intermediate cost of value exchange is almost 0, so that the block chain technology ensures the high efficiency and low cost of the system fairness while ensuring the information security. The method can be applied to the traditional centralized scene to replace the transaction flow originally processed by an intermediary or a central mechanism.

(2) Distributed record storage: the data sustainability is high, each node participating in recording and storing data information in a core defect block chain of the Internet of things has the same right, and a central node does not exist, so that the normal operation of a database can be kept when the data is attacked. Meanwhile, due to the block chain technology, the consensus and the consistency of the whole network can be achieved without trusting a single node, so that the node-node interaction is realized. In addition, the distributed architecture also greatly reduces the loss of traditional central node equipment. Data sustainability and information security are guaranteed. Can be applied to the Internet of things Intelligent traffic and supply chain^[37]And the like.

(3) Complete information, open and transparent: the method is convenient for tracking and verification, and solves the problems of data tracking and information anti-counterfeiting. The block contains all transaction data from the creation of the block, and the formed transaction record is not falsifiable or fictitious, and the data in any network can be traced, so that the exchange of valuable data between two parties of a transaction can be traced and verified at any time. In real life, the information and data are subjected to multiple exchanges in the transmission process to generate a distortion condition, and the transmission process of the long chain also provides a riding opportunity for lawbreakers. A set of non-tampered records can be created for valuable items or data using blockchain techniques. Can be applied to data tracking and anti-counterfeiting^[38]。

(4) A programmable script: the programmable script is a "smart contract" model, and thus, in environments where market order is not sufficiently regular, the "programmable nature" of the blockchain is introduced into an asset or value transfer contract to specify the future use and direction of the traded funds involved in the transaction. Applicable to contract-related services.

The blockchain and the federation chain may be divided into a public chain, a federation chain, and a private chain according to different application scenarios and different design systems, and the openness of the three blockchains is different from each other, as shown in fig. 11.

In the public chain, any node around the world can freely join or exit the blockchain system, read data, compete for accounting, send and forward a transaction to be confirmed. In what is considered a "fully decentralized" public chain, no individual or organization can maliciously control the reading and writing of data or tamper with data. Public chains typically use token mechanisms to ensure the activity of participants competing for accounting to ensure data security, and bitcoin and ether houses are typical public chains.

The write rights of the private chain are strictly controlled by some organization and authority, and the permission qualification of the participating nodes is strictly limited. Since participating nodes are limited and controllable, private chains tend to achieve extremely fast transaction validation speeds, better privacy protection, and lower transaction validation costs. The private chain can use the consensus which can not be attacked maliciously, and can also realize the requirements necessary for the financial industry such as identity authentication and the like.

A federation chain refers to a blockchain that is managed by several enterprises that each may run one or more nodes, and the data in the federation chain allows only certain enterprises within the system to read and write. The nodes with different authorities cooperate together to record transaction data. Unlike privacy privilege design in private chain, privilege design requirements in federation chain tend to be more complex ^[39]. In contrast to centralized databases, federation chains can prevent the potential for a single node within an enterprise to intentionally hide or tamper with data, and quickly locate the source even if an error occurs, so many large financial institutions are currently more inclined to use federation chain/private chain technology.

From the management perspective, the introduction of the federation chain is not intended to be a huge innovation for the federation cooperation model of the multi-party cooperation, and the de-intermediation characteristic of the block chain enables the federation cooperation to be free from independently establishing a new mechanism for coordinating and managing the parties of the federation, and the unique condition of a certain mechanism in the new mediation mechanism does not exist. Federation relies on a commonly maintained distributed account in a federation chain system to implement all information sharing and data clearing functions, in the true sense of implementing a federation system that can be co-hosted by multiple parties. From the aspect of performance efficiency, the introduction of the alliance chain enables the alliance to provide services to the outside in a distributed mode, a third-party trusted authority is not needed to serve as proxy services, and the bottleneck of single-point attack is avoided. Meanwhile, under the condition that no third-party intermediary agent exists, the operation cost of the system is greatly reduced, the overhead of one-step forwarding and integrating of system messages is technically reduced, and the commission charge collected by the third-party intermediary service is reduced in the aspect of cost. Therefore, as a core in the block chain technology, the design of the consensus mechanism is especially important in alliance chain applications, and optimization and improvement of performance indexes in all aspects of the consensus mechanism also become the most sought targets for designing the consensus mechanism herein.

Byzantine fault tolerance problem, in distributed systems, researchers' research into highly available systems has generally focused on benign errors, such as server machine, denial of service attacks, eavesdropping on messages or modifying and corrupting data over the network, which can cause server disruption, corrupting data integrity and confidentiality. But lack the study of more serious malicious attacks such as software bugs, misoperations, key loss, server control by hackers, etc. Such errors caused by malicious attacks are called byzantine errors^[10]。

Highly available system research that can tolerate Byzantine errors is a fundamental problem in the field of modern cryptography and distributed fault-tolerant computing^[45-46]. Mainly studies how to establish a highly available system that provides correct and uninterrupted service to customers in a distributed system when a byzantine error such as a software error (bug), an operation error, a key loss, or a malicious attack occurs^[47-49]. Since the seventies of the last century, a large number of scientists and computer workers have studied the problem, and the research results have important application in military and electronic commerce^[44]. The Byzantine fault-tolerant system mainly relates to the following research fields:

Byzantine agreement protocol: the byzantine agreement ensures that the distributed system provides the correct service to the customer.

Group membership protocol: the group member protocol enables the distributed system to dynamically add or delete server nodes, and ensures that the distributed system has enough correct nodes to provide service for clients. And the high availability of the distributed system for a long time is ensured by continuously deleting wrong nodes and adding correct nodes. The algorithm proposed herein will be effective to enable erroneous nodes to be automatically excluded from the system.

Fault tolerant system: through analysis of the existing fault-tolerant system construction methods and technologies, the consensus mechanism proposed herein needs to ensure that the system to which it is applied can resist byzantine errors and ensure that the protocol is practical.

A consensus mechanism and a consistency algorithm are used,

the distributed consistency condition of the consensus mechanism, blockchain, solves the problem of transferring trusted information, value transfer over untrusted channels, and the consensus mechanism solves the problem of how blockchain consistency is achieved in distributed scenarios [59 ]. The research value of the block chain is that the consensus mechanism of the block chain solves the mutual trust problem among the nodes on the basis of the decentralized idea. In conjunction with the proper operation of the consensus protocol, the blockchain can achieve a more balanced coherency state at a plurality of nodes. Cryptography can be considered to constitute the cornerstone of the blockchain technology, and the consensus mechanism of cryptography is the key to ensure the continuous operation of the blockchain system.

Before the block chain appeared, when the idea of distribution was proposed, then the research of designing the distributed consensus algorithm based on the FLP theorem and the CAP theorem was started.

In specification, the consistency of an ideal distributed system should satisfy the following three points:

(1) termination (Termination): the results of consistency can be completed in a limited time.

(2) Consensus (Consensus): the final decision-making results of different nodes should be the same.

(3) Validity (Validity): the outcome of the decision must be a proposal by other processes.

However, in an actual computer cluster, the following problems may exist:

(1) asynchronous unordered (asynchronous) message transmission, namely, the nodes have different transaction processing capabilities and different network node data throughput, message delay and loss exist, and message transmission among the nodes cannot realize synchronous order (synchronization).

(2) Node down-stop (fail-stop) a node is down continuously and cannot be recovered.

(3) And (4) node downtime recovery (fail-receiver), namely, the node is recovered after being crashed for a period of time.

(4) Network differentiation (network partition) a network link fails and N nodes are isolated into multiple parts.

(5) The problem of the general of Byzantine (byzantine failure) is that a node or a malfunction or logic fails, even the node does not operate according to the protocol and intentionally throws out information of interference resolution, namely a malicious node may appear, and the communication channel itself may be unsafe.

The summary classification of the mainstream consensus mechanisms can classify the current mainstream consensus mechanisms into three types of discussions according to the applicable scenarios of the blockchain and the differences of different consensus mechanisms on node permission and communication fault tolerance: a fully decentralized unlicensed consensus mechanism; a consensus mechanism of byzantine fault-tolerant variants; a consensus mechanism of non-Byzantine scenarios based on traditional distributed consensus algorithms.

(1) The completely decentralized non-permission consensus mechanism is a consensus agreement for block chain customization, and in addition to ensuring the security and realizing the currency issuing mechanism, an important process exists in the process of building blocks, and the important process is used for deciding who will obtain the right to build the next block approved by the whole network in a decentralized mode. A pure full decentralization consensus mechanism must be implemented such that a block generated and distributed by only one node in thousands of computers is legitimate. The time interval over which these blocks occur needs to be large enough for the network to agree between each block.

In a centralized system, there is little cost to produce or broadcast blocks, and it is sufficient to directly designate a computer to distribute blocks at intervals. In a decentralized system, however, each peer node has the same right to construct a block. If the cost of building and broadcasting blocks is substantially zero, even a slight reward per block may be sufficient to encourage such a competitive mine digging action. Therefore, the completely decentralized unlicensed consensus mechanism needs to set the cost for building blocks to increase the difficulty, so as to ensure the same block building rights of the peer nodes and avoid network congestion caused by competitive accounting. The completely decentralized non-permission consensus mechanism is generally used in public chains, nodes can freely enter and exit a network without permission, and completely decentralized consensus is realized in a point-to-point network. The representative consensus mechanisms are PoW, PoS and DPoS.

(2) The consensus mechanism of Byzantine fault-tolerant variants, the problem of the Byzantine general is the problem skillfully solved by the workload proving mechanism when bitcoin is born. The byzantine assumption is a modeling of the real world, and unpredictable behavior of computers and networks may occur due to hardware errors, network congestion or disconnection, and malicious attacks. The byzantine fault tolerance algorithms must deal with the consequences of these malicious activities and the protocols must also meet specifications required by the problem to be solved. These algorithms are generally characterized by their elasticity t, which represents the number of erroneous processes that the algorithm can handle, and many Byzantine fault tolerant algorithms have solutions only when n ≧ 3t +1, where n is the total number of processes in the system. With the development of the block chain technology, the research of the consensus mechanism is turning to the improvement of the byzantine fault-tolerant algorithm, so as to achieve point-to-point consensus while avoiding the high energy consumption caused by PoW, but the shortcoming of limited node scale still exists. Representative consensus mechanisms are PBFT and dBFT.

(3) In a traditional distributed consistent consensus mechanism of a non-Byzantine scene, a BFT algorithm machine variant mainly solves the consensus problem in the Byzantine scene, and traditional distributed consistency is realized in a closed distributed cluster, and participation of nodes needs to be permitted. The method has high efficiency, only takes the faults such as down of the nodes into consideration, and does not consider the possibility of malicious attack (namely counterfeiting and attack information) of the nodes. In this case, the Paxos and Raft algorithms are the mainstream, and the two algorithms still need to be modified to be suitable for the block chain system.

The main flow consensus mechanism represented by the consensus mechanism for the three classes is characterized by the following table:

TABLE 2.1 comparison of characteristics of mainstream consensus mechanisms

Dimensional analysis of the different consensus mechanisms,'Chinese blockchain technology and application development white paper' published by Ministry of industry and communications in 2016^[69]The proposed analysis of consensus mechanisms can be divided into the following dimensions:

and (4) compliance supervision: whether the super authority node is supported to supervise the nodes and data of the whole network or not, whether the legality of the block chain data can be controlled or not, and the transaction which does not accord with the actual legal regulation is eliminated.

Performance efficiency: the transaction data achieves the efficiency that consensus is confirmed, and the consensus mechanism allows the system to have efficiency with respect to the transaction data processing speed.

Resource consumption: resources such as a CPU, a network input/output, and storage consumed in the consensus process need to be avoided from being excessively wasted and consumed.

Fault tolerance: and the capability of preventing attack and fraud.

The following table shows the mainstream consensus classifications performing better and less well in different dimensions, based on the analysis of the superiority and inferiority of the different consensus mechanisms.

TABLE 2.2 different dimension comparison of consensus mechanisms

Different consensus mechanisms agree on the distributed system state through different compromises. One class is PoW mechanisms, represented by bitcoin, letty coin, etherhouses, and PoS and DPoS, represented by Peercoin, NXT, bitshams, which are commonly used in public chains at the expense of external resources (such as the computing power of PoW) in exchange for consistency; one is PBFT and dBFT evolved from byzantine fault-tolerant algorithms in exchange for consistency through multi-stage submission and validation; yet another category is traditional distributed coherency algorithms such as Paxos and Raft, trading coherency and security by restricting permissions and setting trusted contexts. But the existing consensus mechanism still has the possibility of 'bifurcation', the whole network data is public and transparent, the confirmation of the transaction only considers the factors on the algorithm, and the legal permission of the real world is not considered at all.

It can be seen that starting from the blockchain consensus PoW of bitcoin, the subsequently introduced consensus mechanisms propose different consensus designs for avoiding the disadvantages of pows in the aspects of complete unsupervised transaction confirmation speed and resource consumption, but sacrifice fault tolerance to some extent. Aiming at the development requirements and trends of the consensus mechanism in several dimensions, the consensus algorithm designed herein is expected to be compatible with advantages in supervision, transaction performance, resource consumption and the like on the basis of ensuring fault tolerance.

If the controllability of the blockchain transaction can be improved, and the transaction which does not meet the real world law is filtered according to a certain artificial rule, the compatibility of the blockchain system and the real application scene can be realized. It is believed that this can be achieved by using the constraints of the different identity permissions of the federation chains, in conjunction with a suitable consensus design.

A consensus mechanism facing a alliance chain scene is designed, safety reliability analysis is conducted on the consensus mechanism, a novel consensus mechanism separates a bookkeeping right and a voting right, alliance nodes have equal voting rights, bookkeeping rights are distributed to the whole network and handed over to full-time consensus nodes to be completed in turn, consensus is formed mainly through voting results, information verification and auditing are mainly conducted on the alliance nodes, signatures and multiple signatures are introduced to conduct identity authentication on key nodes, and safety controllability of the system is improved. The central idea of separating the accounting right and the voting right enables the alliance chain core consensus node to become a central cluster node of the whole network, the power is dispersed in the cluster node, transaction verification is achieved by relying on the voting result of the member node instead of any centralized mechanism, and the characteristics of partial decentralization of the alliance chain are perfectly fitted.

The above description explains the block chain technical principle, architecture, classification and consensus algorithm, and essentially, the block chain is a distributed ledger. All nodes participating in service or operation in the whole network keep a complete copy, how to maintain the unified book together, and the data stored by all the nodes participating in service or operation have consistency and completeness, and the consensus mechanism plays a very important role in the consistency and completeness. It decides who is responsible for the accounting of the account book and ensures that the account book of the whole network can be uniformly modified, so that a rule 'consensus' is formed among all nodes. Under the operation of the rule, the distributed account book can be smoothly written in and read out and can keep the consistency of the whole network. Therefore, a problem arises in how to design a rule to ensure that the blockchain system can operate in an untrusted network and still operate reliably and safely under possible malicious attacks? To this end, this section sets forth a design scheme based on a novel consensus mechanism of the federation chain.

The consensus mechanism is oriented towards a federation chain scenario, which is one option to compromise in both scenarios, compared to an unlicensed, freely accessible and unsupervised public chain, and a centralized private chain that is tightly controlled by a single organization. Federation chains are biased to run between different enterprises or organizations of the same industry or purpose. The method aims to reduce the communication and contact cost between organizations and improve the efficiency of business cooperation. The original intention of the federation chain was to join different organizations together to achieve strong associative collaborative value and decentralization within the federation, thereby achieving "partial decentralization" of the federation chain system. The alliance chain generally has strict identity permission limitation, the protection of security and privacy is limited in the system, and the requirements on the system throughput and the time delay are high. Generally, the nodes participating in the consensus in the federation chain all need to be authenticated. More importantly, the alliance members as service providers in the system, which jointly provide services to the outside, need to have sufficient control right on data and operation conditions in the alliance members. If abnormal conditions occur, the alliance can start a supervision mechanism through negotiation, and implement certain treatment measures to make tracking punishment on malicious attack behaviors of the system, or make further treatment compensation on the caused data damage to reduce loss.

Aiming at a Consensus method of a alliance chain, a voting-based Consensus mechanism Consensus of Voice (CoV) keeps the unity of organizational actions by means of 'a few majority-obeying' gold iron rules, realizes good cooperation of multi-party participation in cooperation through the design of a specific Consensus mechanism, is mainly applied to an alliance chain system which is formed by enterprises or institutions and the like in various regions around the world and can serve terminal users of the global network.

In order to better illustrate the core idea and authoring source of the CoV, a CoV consensus mechanism is introduced through a simple application scenario, so that the CoV can perfectly conform to the requirement of decentralized management of alliances, and the best consensus among the alliances is formed through voting.

Suppose there are three banks in the world, bank a, bank B, bank C, and two customers: client a and client B. Each bank keeps track of the balance and debit relationship through its own system. As shown in fig. 12:

as can be seen from fig. 12, the same transaction is recorded in different banks using their respective independently developed, operated, and maintained systems. Extending to other areas, this situation can result in more copies, with intricate association and transformation rules. For banks, the working modes of different systems are different, so that the verification, error check and clearing of the bank become more complicated; for the customer, not only does the customer spend time managing and settling the funds separately at different banks, but the banks are also believed to have sufficient reimbursement capability and system security capability to ensure that their funds are not at risk of being destroyed or stolen. It can be seen that there are many drawbacks and inconveniences to conventional fund clearing, whether for the provider of the service-the bank, or the consumer of the service-the customer.

The blockchain system can conveniently solve the fund clearing problem, and after the distributed ledger technology of the blockchain is introduced, all transaction records in 5 tables can be recorded by using only one distributed ledger instead of a part of (incomplete) records held by each bank, as shown in fig. 13.

If such an account book can be maintained, any bank can easily derive the integrity required by the bank from the super table, and the customer can conveniently calculate the balance of the bank without integrating data in different systems. The problem is that is who maintains this table (accounting)? Obviously, if a third agent is handed over to integrate data, the bank loses the significance of existence, and once the third party fails, the world which is transported as blood by capital will be influenced by the third party; if the system is handed to any bank as the leader of the bank or a world bank is established to integrate data, the system load is over concentrated, and mustard pedicles and unwarranting of other banks can be caused; if a block chain technology is introduced, a third-party center can be thoroughly abandoned, the distributed account book technology can enable the super table to be copied to each bank in a large range, loads and pressures caused by centralized integration are greatly shunted in business processing, and meanwhile the problem of single-point faults is solved.

This is typically a scenario where a federation chain may be used, the identity of the bank also acting as a fund manager, and the customer being the only consumer of the clearing system. In this case, the meaning of "partial decentralization" is actually that the alliance committee of bank constituents is the center of the entire blockchain clearing system, but decentralization needs to be achieved between individual banks. Obviously, each bank needs to verify the correctness of the data on the account book, and the best verification consensus is the voting mechanism. In a federated scenario, the best way to unify actions is to implement "few subject to majority" in the authority representative population. The novel algorithm adopts a top-level design idea of separating voting right and accounting right, each bank has the right of voting and verification, but the accounting right is opened to a free competitive node similar to a miner, and accounting is carried out by a professional accounting team in turn in a random order and is not controlled by any bank, as shown in fig. 14.

In order to avoid the situation that the billing right is excessively concentrated or dispersed due to the fact that the number of the billers is not fixed, the novel consensus limits the number of the billers. The bookers in each round are selected through voting, transaction transactions are collected in a certain due period, and the posters are recorded; and the bookers who fail to enter the selection are used as candidates to wait for the next round of election. If a common user wants to join an accounting team, the common user needs to become a candidate first, and in order to reduce the malicious behavior of the accounting team, the candidate needs to obtain the recommendation of a certain bank and obtain the unification of most banks to pass the verification.

In addition, in order to ensure the security of the account book by all people, each person in the alliance chain has a unique public and private key to identify the identity of the person. This model is the design idea of the novel consensus mechanism proposed herein.

The novel consensus mechanism is inspired by several mainstream consensus mechanisms, and meanwhile, all consensus mechanisms designed aiming at public chain scenes are realized to avoid the balance and game of two key points of safety and performance. The block chain items such as bitcoin and ether house which are high in safety and reliable and run for years are used, and the used consensus mechanism ensures the safety of the whole network as much as possible at the cost of performance sacrifice; most of the subsequently generated consensus mechanisms sacrifice complete security argumentation or make corresponding security assumptions or limitations on algorithm premises to a certain extent in order to improve the performance of the consensus mechanisms. The consensus mechanism proposed herein therefore wants to compromise the four-dimensional performance of consensus mentioned in chapter two, while achieving consensus consistency in the federation chain:

1. in compliance supervision, the alliance chain can start a supervision mechanism to reserve key logs of the system for auditing, so that the block chain system is no longer in an uncontrollable state without being supervised, and the operation of the system is more reliable;

2. In terms of transaction performance, a consensus mechanism of a federation chain needs to provide higher operation efficiency, so that the acknowledgement time delay of a transaction is lower, and the system throughput is higher;

3. in terms of resource consumption, a consensus mechanism of a alliance chain needs to get rid of high power consumption caused by Nakamoto consensus;

4. on the aspect of fault tolerance, the high reliability of the alliance nodes in the alliance chain provides natural guarantee for the blockchain system, the possibility that the network node servers provided by the alliance may be down or failed is not eliminated, and a good premise is provided for a safety model of the blockchain.

5. On the basis of consensus, the consistency of the decision-making results among the alliance nodes can be realized.

6. In terms of the legitimacy of consensus, the presenter and verifier of a transaction must be done by different processes.

7. On the termination of consensus, the novel consensus mechanism can utilize the natural security model premise of a alliance chain to realize the termination of transaction confirmation under the condition of weak synchronization, and the result of consistency can be completed within a limited time. The novel consensus mechanism enables non-forking of blocks, each block having a final, transaction acknowledgement requiring only waiting for an acknowledgement of one block, as shown in FIG. 15.

In the alliance-link network, two kinds of nodes are assumed to exist at the same time, one is a alliance node of a group network with a special identity, a commercial processor cs (commercial server) is used, and the other node is a common server pc (personal computer). There are n common processors pcset (personal Computer set) with the same computing power and security defense (PC 0, PC 1.., PCi.,. loga, PCn-1) (0 ≦ i < n), and there are m commercial processors csset (commercial Server set) with strong computing power and complete system security settings (CS 0, CS 1.., CSj.,. cndot, CSm-1) (0 ≦ j < m), where fn of the n common processors are controlled by a byzantine attacker and fm of the m commercial processors are controlled by a byzantine attacker.

In the federation chain system, valid transaction data of an unwritten block reserved in node memory is denoted by t (transaction), and a transaction belongs to a transaction set tset (transaction set). All valid transactions are received and forwarded in the network, legal transactions are added into the blocks, the block h represents a block with the height h, the transaction i in the block h is represented by txh (i), txh (i) belongs to TSet, and all processors can determine the validity of each transaction by accessing a specified agreed function C: TSet → {0, 1 }. It is desirable to design a protocol that can run between all PC and CS processors so that a processor can serialize the unprocessed valid transaction data { Tj } (1 ≦ j | TSet |) into a legal subset of TSet { txh } - { txh (i) } (1 ≦ i ≦ | txh |), i.e., generate block h, and satisfy the following conditions.

1. The supervision is as follows: the ordinary processor PCi process can request for synchronizing a legal transaction set { { tx0}, { tx1}, { txh }, } when initialized, if an audit node appears in the system, the audit node can also apply for data from CSj and simultaneously apply for the legal transaction set from other CSs to verify the consistency of the transaction set and obtain the most complete transaction set, the { txh } generated by PCSet needs to be checked by a certain rule of CSSet, and the CSSet has absolute rights on generation and checking of { { tx0}, { tx1}, { txh }, }.

2. High efficiency: assuming that the time generated by the legal transaction set can be obtained through the attribute timestamp, { Ti } (1 ≦ i ≦ TSet |) is serialized into { txh (i) } (1 ≦ i ≦ txh |), and synchronized to the time consumed by PCset and CSSet, i.e., the block generation delay Δ

the average value of delta t is as small as possible, and the average value is controlled within a second range and is only influenced by network bandwidth. Meanwhile, the system throughput is expressed as the total number of transactions Σ | { txh } | in the legal transaction set generated in a unit time, and the larger the better.

3. Low consumption performance: the Power consumed by the CSSet and PCSet processors per unit time, the lifetime consumed by the processors, the depreciation of the mechanical parts of the machine, and the sum of the losses consummation of the cabinets and the Power supply equipment (which the CSSet may be equipped with, but not necessarily the PCSet) are small, in particular the ratio Power/consummation is small.

4. High fault tolerance: the system can allow a certain proportion of byzantine attackers to exist, namely p (bad CS) ═ fm/m >0 and p (bad PC) ═ fn/n >0, because the CSSet controlled by the alliance node is a service provider of the alliance chain system and uses a commercial processor with perfect security setting, the probability of the CS being controlled by the attacker is far less than the probability of the PC being controlled by the attacker, p (bad CS) < < p (bad PC), so the fault tolerance of the CS is allowed to be poorer, but the fault tolerance is stronger than that of the mainstream consensus, and the consensus mechanism designed herein can tolerate p (bad CS) to reach 50% at most and (p bad PC) to reach (n-1)/n at most.

5. Consensus property: there is a time difference function Δ () for e (0< e <1) such that the probability that the states returned by the two CS nodes at time t to t- Δ (e) are different is less than e, i.e. the states coincide between different nodes.

6. Legitimacy: the legal set of transactions must satisfy a certain constraint function C, for example,

c (txj (i)) ═ 1. In the blockchain problem, the transaction set as the committed input must first satisfy an internal check C, which is required to check whether the committed input satisfies an externally specified constraint C, considering that this node may be a byzantine node.

7. Terminating property: there is a time difference function Δ (·), for e (0< e <1), so that the probability that the states returned by a node at two time points t', t "> t- Δ (e) are different is smaller than e, i.e. the consensus process of the same node can be completed in a limited time. And assuming that the latest transaction set received by the node is { txh }, the probability that the node receives { txh-1} and { txh-1} returned from two nodes at the same time t is different from each other is smaller than epsilon, and the probability that the node receives { txh-2} and { txh-2} returned from the two nodes is also different from each other is equal to 0, that is, the block finality can be achieved only by confirming one block, as shown in fig. 16.

The designed consensus algorithm operates under a certain safety model. The security assumption of the alliance chain underlying network is as follows:

1. in the PCSet and CSSet processors, the network graph between honest processors is connected, i.e. honest processors are not isolated in more than two network partitions, which is not required for a byzantine processor.

2. The communication between honest processors adopts a synchronous network model, when the honest processor A1 sends a message to the honest processor A2, the A2 can not receive the message from the A1 synchronously considering the network delay and the different uploading and downloading speeds of various regions, but the A2 processor can receive the message within a limited time deltat seconds, and deltat is the end-to-end message delay limit.

3. The Time of the honest processor in the point-to-point network keeps synchronous with the Time of the NTP (network Time protocol) server, when the node is down to restart or newly join the network, the Time of the processor is firstly ensured to be synchronous with the NTP server, namely, the Time of the processor is kept consistent with the Time of the bottom layer module chain.

The security assumptions for processors in a federated chain system are as follows:

1. in the alliance chain system, m commercial processors cset and n common processors PCSet exist simultaneously, wherein fm byzantine attackers are allowed in the commercial processors and fn byzantine attackers are allowed in the common processors.

2. In the real world, a federation node is generally a large company and has a large commercial server cluster independent or in a cloud, so that it can be considered that a commercial processor is far stronger than a common processor in terms of security and computing power, and therefore, the possibility of being controlled by a Byzantine node is lower, namely fm/m < < fn/n.

3. In theory, no more than 50% of the commercial nodes are allowed to be controlled by a Byzantine attacker, and no more than (n-1) common nodes are allowed to be controlled by a Byzantine attacker, for reasons that will be demonstrated in the security analysis.

Other security assumptions and threat models:

1. the behavior of the byzantine attacker controlled processor may be any malicious, such as not following the protocol, discarding valid transactions, ignoring messages sent by other processors, forging messages, forging transactions, and so forth.

2. The byzantine attacker may initiate double blossom transactions, selfish mines, Sybil attacks, etc., as will be explained in chapter IV, respectively.

3. It is assumed that the hash function and encryption algorithm are not hackable, which means that the byzantine attacker processor cannot forge signatures and certificates.

The CoV (Consensuss of Vote) may operate in a Federation chain network, i.e., in a license chain. In the permission chain, each node has a certain identity and an account number, independently possesses a public-private key pair and a digital certificate, and under the cooperation of different identity nodes, the CoV can realize the order of block chain writing and the consistency of node data in the network.

The alliance chain is used as a scene of the block chain, a network architecture based on P2P is adopted, a single-node server and centralized services do not exist, but a network formed by the alliance nodes can be regarded as a weak center in a system and is an important component for supporting the operation of the system. Although the nodes in the P2P network are peer-to-peer nodes and are connected in any way, the division of labor of each node is different according to the functions provided, and the nodes are divided into the following four roles in the common design of CoV: committee, housekeeper Butler, housekeeper candidate Butler, common node, oridinary user, and allow some degree of facultative roles, as shown in fig. 17.

Committee commission: a federation commission of enterprises or institutions from different regions of the world is expected to maintain a federation chain together. The committee is a member of a federation in a committee of the federation. The newly added committee in the federation must either accept through a federation contract or negotiate decisions through offline federation (not within the scope of the discussion herein) and correspond to a committee node in the federation chain network that provides services in the network using the commercial server CS. The committee nodes have the following characteristics:

1. the committee has the right to recommend, vote, and rate the caretaker (biller).

2. The committee also has the obligation to validate the block, vote on the transaction data and forward the transaction data over the network.

3. The rights and obligations of each committee are the same by default, equal in rank. In practical application, the voting weight can be set according to the rights of the corresponding alliance mechanism in the alliance.

4. After a block is generated using CoV consensus in a alliance-link network, transactions for valid blocks must receive approval tickets for more than 50% of committees, which represent the willingness of the committees overall.

Butler: the manager is a professional bookkeeper in the alliance chain, is granted the power of the special production block by the alliance chain, and has a limited number of manager nodes. The steward's role can be considered as a leader node in a traditional consensus algorithm. But unlike traditional algorithms, the caretaker's rights are supervised and voted on by the important committee nodes in the federation. The presence of this role of housekeeper means the separation of voting and execution rights. The committee had no rights to the production block and handed this work to the caretaker. Blocks are packaged by information collected in a federation chain, and a housekeeper needs to sign the packaged blocks. Becoming a butler requires two steps:

1. Firstly, applying for becoming a manager candidate;

2. and the election becomes a manager through the election activity at the end of each round of any period.

The election method is that all housekeeping candidates receive votes from all committees. The housekeeper alternately generates blocks in a random order during the due period, and accepts re-elections after the due period expires. The committee may have both committee and housekeeper identities.

Butler candidate: the system will select the successful housekeeper number {0,1, 2.. n-1} for each race, and to ensure the stability of the running of the consensus process, the housekeeper number is limited to be a constant, and the setting of the housekeeper number will be discussed later. To become a butler, the butler must first become a butler candidate and participate in each round of contest, accepting the committee's vote to become the butler. And the candidate who fails in election keeps the identity of the manager candidate, keeps the identity on line and waits for the next round of election. Changing from a common node to a housekeeping candidate must go through three steps:

1, registering a user account in a alliance chain system and sending an application of becoming a manager candidate to a certain committee node;

2. a recommendation letter (encrypted by a key) requiring submission of at least one committee signature, similar to the invitation code, is reviewed and guaranteed by the recommending committee to verify the identity information of the steward. The recommendation message is generated by calling a function in the client by a committee, and the implementation mode is asymmetric encryption. The private key encrypts the content of the recommendation message, and after the public key decrypts the content, whether the recommendation message is forged or not can be verified;

3. After committee submits deposit, the deposit becomes a candidate for housekeeping. The committee may have dual identities for both the committee and the housekeeping candidate, applying for enrollment by way of self-recommendation.

Ordinary user node Ordinary user: all three nodes adopt a cryptographic technology to authenticate the identities of the nodes, a hash value of an operation message sent by the nodes needs to be signed, and the behaviors of the nodes can be verified. The common user has the following characteristics:

1. the identity authentication does not need to be accepted, the behavior of the system can be arbitrary and anonymous, in the specific floor application process, the real-name of the user can be set according to the configuration of the alliance chain system, but the identity information in the user transaction process can be hidden by using an encryption function, and meanwhile, the source of each transaction can be traced through the alliance node.

2. And can join or leave the network at any time.

3. The system can not participate in the generation process of the blocks, and can only participate in the distribution and sharing process of the blocks.

4. The message is forwarded for the federation chain and the complete consensus process can be seen while enjoying the services brought by the federation chain. The relationship transition of the respective roles is as shown in fig. 18.

CoV assumes that the number of system committee nodes is Nc, the number of housekeeper nodes is Nb, the number of housekeeper candidates is Nbc, the number of common user nodes is No, and the total system node is Nall. Since a node may have dual identities, the total number of committee, housekeeping and housekeeping candidates is less than the sum of the number of partitions, i.e., Nall ≦ Nc + Nb + Nbc + No, where the number of housekeeping is quantitative. In each session, each butler who succeeds in the election will get an assigned number, starting with 0 and the last number being Nb-1. Assuming that the duty cycle of the housekeeper is Tw, Bw +1 blocks are generated in each duty cycle. The housekeeper alternately watches duty in random sequence in the duty cycle and generates a block in each duty cycle. The last block of each due period is a special block, and the voting result, that is, the server information and the manager number of the manager node elected in the next due period are recorded. The housekeeper is required to generate a block within a specified duty cycle, which is also the block packing period Tb. The notation comparison table used globally herein is referred to in appendix a. FIG. 19 shows a consensus model for an incumbent period.

The housekeeping generates and signs a valid block at a time is called a round of consensus. After each round of consensus is finished, the housekeeper calls a function to generate a random number R, wherein R is more than or equal to 0 and is less than Nb. The housekeeper with the housekeeping number equal to R is called the housekeeper on duty, which is responsible for generating and signing the next block, and the generated block must be signed by at least Nc/2+1 committee members to become a valid block. If no valid block is generated within the Tb time, the housekeeper numbered R +1 regenerates the block and let the current random number R be R +1, and so on. If the current random number exceeds Nb, R is incremented from 0. Each valid block has a final, no bifurcation, as shown in fig. 20.

The last pass of the expiration will produce the Bw +1 th block, which is a special block. The incumbent manager and the manager candidate compete for the manager name in the next circle. Each committee node votes on the housekeeping candidates, and finally the node voting the top Nb among the Nbc housekeeping candidates was elected as the housekeeping. Both the voting information and the results are written into this special block. After the voting consensus is achieved, the housekeeper officially takes off duty in the current round, and then a new duty cycle is started. And each round of the duty cycle has a total of Bw +1 rounds of consensus, and Bw +1 blocks are generated.

The incentive mechanism 1, the alliance fund and the clearing mechanism, and the purpose that the manager node participates in the election and generates the effective block are mainly to obtain the accounting commission charge. The alliance chain system can solve the billing commission problem by introducing tokens, the monetary units and conversions of which correspond one-to-one to the real monetary units and conversions. After the alliance is established, an alliance fund account address is set, and the alliance fund account address corresponds to a real account for storing funds in a bank in reality. The use and clearing of the league fund is only exemplified below, and the operation of the actual system can be added with other operations related to the transfer of the token, such as commission management and the like, or other incentive mechanisms are adopted to realize the incentive for the manager to work.

Issuance of tokens: several alliances share one real account in one bank A, which has one virtual bank account A to issue token in alliance chain system. When a certain alliance in reality recharges a fund to a real account in the bank A, the bank A confirms that the fund is received and then issues a transaction in an alliance chain system by using the identity of A, and tokens representing the same amount are transferred to an alliance fund account address. After more than half of the committee checks are obtained, the transaction can be written into the block chain as a legitimate transaction. The federation funds are used to deposit deposits submitted by the manager candidates, to release payroll to the manager, and to manage user handling fees. If necessary, the committee may transfer funds to bank a to replenish the account address with funds.

Transfer of tokens: the payroll obtained by each manager depends on the number of valid blocks ever generated, and each payroll is issued by transferring tokens to the manager's public key address.

Destruction of tokens: the bank A can cash out the received virtual token and sends the amount of the token corresponding to cash-out to a public key address without a corresponding private key for destroying.

When an ordinary user applies for joining a manager candidate, a deposit needs to be transferred to a bank A in the real world, the manager candidate can give up the identity of the manager candidate at any time, the manager can take back the own deposit if no bad record exists during giving up, and the manager cannot take back the own deposit if giving up the identity of the manager during the period of leaving the network for applying for quitting the network, because the deposit is a bad behavior.

The incentive mechanism 2, the scoring and rewarding mechanism, and the consensus mechanism are added with the scoring mechanism and the rewarding mechanism, so that the caretaker with higher score and the caretaker candidate have higher probability of obtaining the vote to be elected to the caretaker. The housekeeper who successfully encapsulates the effective blocks obtains corresponding money rewards according to the number, the system attracts more people to join in a housekeeper rank through the two external incentives, the behavior of honest work is rewarded, and the behavior of punishment is punished, so that the system develops towards the direction of more and more safety and reliability.

Each committee maintains and scores a list of housekeeping candidates according to the scoring rules:

1. each time the committee verifies and signs a block, the corresponding on-duty butler is given a bonus, and if the verification is not passed, the butler is given a deduction or even cleared.

2. If the manager node is not online and misses the chance of producing the block, the score of the manager node is subtracted by all committees or even cleared, and if the offline behavior penalty in the alliance protocol is serious and is uniformly set to be cleared, the manager node means that when the manager node is online again, the manager node needs to start the integration again.

The scores of the caretaker on each board may be different, and the score for each caretaker candidate represents the confidence level of the caretaker, and also becomes one of the basis for voting.

After each round of the holding period is finished, the manager receives the remuneration given by the alliance according to the number of the generated effective blocks, so that the manager has power to apply the employment for election, honestly work and keep online for a long time.

The set billing remuneration is an important incentive to ensure the householder's honest work, as will be discussed in detail later.

The common Consensus of CoV is called as Consensus of Vote, the initial purpose of the design of the common Consensus algorithm is to set a general identity model (a federation node and other nodes) for a federation chain, and the voting result is used as a legal certificate of the system to generate an effective block by using the special identity of the federation node in the federation chain model and following the principle of 'minority majority obeying'. On the basis, in order to ensure the decentralization of decision making among the alliances, decision making results are generated by other nodes in the system, and a recommendation mechanism and two voting certification mechanisms are introduced for standardizing the effectiveness and the reliability of the other nodes.

Consensuss of Vote on Butlers (Consumer's Vote of trust): the total votes cast by the committee to the housekeeper at the end of each tenure represent the trust of the overall committee on the housekeeper, and the reliability of each housekeeper is proved by the voting result of the committee on the housekeeper.

Consensus of volume on Blocks (validation Vote for Blocks): for the validation voting of the validity of the blocks, each block must be validated by more than half of the committee validation. This means that if the system needs to correct the result of a certain transaction, the modification of the transaction can be successfully verified by the validity check on the premise that half of the committees agree, more than half of the committees agree to the willingness of the members of the committees, and the validity of each block is verified by the voting result of the federation, as shown in fig. 21.

Meanwhile, the CoV algorithm establishes the roles of butler and butler candidates for the system, so that the decision result of the alliance chain is executed by a dynamically-changed butler team selected by decentralized voting, and a voting consensus is formed among alliance nodes invisibly. According to the analysis on the final consistency of the CoV in the following text, a majority of voting results can uniquely confirm a final decision, so that the alliance chain system stably operates under decentralized management of alliance nodes.

The concept of voting certification is embodied in the design of consensus mechanisms through two kinds of voting, the first is the voting of whether the committee approves the block generation, and the second is the voting of the committee on the housekeeping candidates. The committee votes by returning the signature.

The first is a vote on the validity of the block by committee. The block is generated by the caretaker on duty i and sent to all committees, and if the committees agree to the generation of the block, the block header and the current timestamp are encrypted and signed, and the signature and the timestamp are returned to the caretaker i. When the housekeeper i receives the signature over Nc/2+1 within the specified time, the block is valid; otherwise, the block is invalidated and repackaged by the caretaker i + 1.

The second is the voting of the committee on the housekeeping candidates. During the last duty cycle of the tenure, the committee sends the signed voting transaction to the caretaker j on duty. And after collecting and calculating the votes by the manager j, packaging all voting affairs and results into a special block, and sending the special block to all committees for voting on the block legality. The voting transaction sent by the committee contains a combination of two tickets:

1. normal ticket: the committee gives the candidate sequences with higher scores according to the scores in the self-maintained housekeeping candidate list according to the scores.

2. Assigning a ticket: considering human factors, the committee may set a set of assigned candidate sequences, or random candidate sequences, to increase the fluidity of the caretaker.

The voting of the committee on the housekeeper reflects the trust degree of the committee on the housekeeper, the random alternate billing of the housekeeper increases the mobility of the housekeeper, prevents most excellent housekeepers from occupying the housekeeper ranks for a long time under the control of a certain mechanism, and also prevents the possibility that part of housekeepers frequently elected are bought in a large range, so that the system is safer and more reliable.

In the execution process of the consensus algorithm, the cooperation of an underlying network layer and a data layer is also needed, and the consensus layer is used for realizing the consistency of correct blocks stored by all nodes under the condition of no central server. In the execution flow of the CoV algorithm, the communication between the nodes realizes the generation and synchronization of the blocks on the alliance chain in a mode of transmitting messages, transactions and blocks. The following classes of special transactions and messages are used in the description of the algorithm details in this section.

Transaction 1Tx _ PERMISSION: the identity authority transformation transaction at least comprises (from, top, pro _ sign _ list, addr, sign) attributes and represents the transaction of node identity authority transformation. from represents the original identity, tobe represents the target identity, wherein the committee node can become the housekeeping candidate at the same time, and pro _ sign _ list represents the signature list. Signatures were used to prove that the transaction has passed the validation or recommendation of the Federation Commission. If the common node becomes the authority transformation transaction of the manager candidate, the pro _ sign _ list contains the recommendation letter of a certain committee and the consent signatures of more than half of the committees; if the committee becomes the authority transformation candidate, the hive _ sign _ list includes the committee's self-referral information.

Transaction 2Tx _ VOTE: and voting affairs, namely committing the voting affairs transmitted to the on-duty manager in the on-duty period generated by the special block, including the voting candidate manager list.

Transaction 3Tx _ DEFINE: custom transactions, i.e. common transactions in blockchain applications, different systems will customize different common transactions.

Message 1SIGNpuk (data, [ time ]), committee signed message, for returning a recommendation message or an agreement message, signing the data, which may be followed by a time stamp when signed, subscript puk indicating the public key of the signer.

Message 2Pre-Blcok (Pre-Header, Body), the housekeeper generates the message sent to all committees after the Pre-block. The chunk Body containing the initial chunk header and containing the transaction { tx }.

Message 3Block (Final-Header, Body), the housekeeper generates the Final confirmed Block, including the complete Block Header and the Block Body.

Message 4height (num) requests the highest block height, and during the synchronization block, it is determined whether the block of the node needs to be updated by first requesting the highest block height from the neighboring node.

Message 5BLOCK _ SYNC, a BLOCK synchronization message, is typically used for nodes in the system to request synchronization of the latest BLOCK from a committee or neighboring node, updating system variables in the processor.

The data structure of the block facilitates formalization of the description code. Furthermore, the following abbreviations are used to denote the different identities com: a communist; bul: butter; bc: a butter candidate; a user: an organization user; as shown in the following table:

TABLE 3.1 Pre-Block data Structure

TABLE 3.2 Block data Structure

Under normal circumstances, the number of housekeeping candidates Nbc is greater than the set housekeeping number Nb. Before the creation block of the federation chain is generated, the committee node becomes a manager candidate through self-recommendation and selects the first manager in the creation block. A duty cycle comprises the following steps:

step 1, at the beginning of each round of duty cycle, R is GetProviousBlockRandomNum (), and an created block R is 0;

step 2, completing the Bw round consensus and generating Bw common effective blocks;

and 3, in the last round of consensus of the duty cycle, updating scores in the manager candidate list of the committee by the committee, and voting. A special block is generated, which contains the information of the new manager and the corresponding number;

and 4, finishing the optional period of the step 4, and circularly executing the steps 1-4.

If Nbc < Nb, in the case of insufficient candidates, the housekeeper can assign a plurality of numbers to make the system operate smoothly, for example, Nb is 8, 6 housekeeper candidates, and then 0-7 are numbered in the order of { B1, B2, B3, B4, B5, B6, B1, B2}, and housekeeper B1 and B2 can have 2 numbers as the two housekeepers with the highest votes. As shown in fig. 22, after undergoing the common block consensus of the encapsulation of the Bw round common block, a round of the common block consensus is performed, wherein hs is the height of the previous special block and also represents the deadline to which the round of the common block belongs.

The flow chart for rotation between the idle periods is shown in FIG. 23, where h is the current block height and hs is the latest special block height

The generation of a valid block is referred to as a round of consensus. If the manager i cannot generate a valid block within the time Tb, the authority to generate the block is handed over to the manager i +1, which is called the manager's round-robin process. A flow chart of generating a normal block is shown in fig. 24. The time for a round of consensus is about Tc × M × Tb (1 ≦ M ≦ Nb), where M represents that M-1 invalid blocks are discarded in the round of consensus. When M is less than or equal to Nb, at least one manager can generate an effective block, and the generation of a common block comprises the following steps:

step 1, generating transaction data by any node of the whole network, attaching a signature, receiving the transaction data, verifying whether the received transaction data is correct, and forwarding the transaction data if the received transaction data is correct, wherein all transactions are mainly forwarded to committees and stewards;

step 2, all manager nodes monitor transaction data and put effective transaction data into a transaction pool, and the manager nodes and the committee nodes in the whole network periodically synchronize NTP time;

Step 3 let M be 1 and R be getproviousblockrandomnum (). If this is the first block in the current appointment, then R can be obtained from the last valid special block in the previous appointment cycle. If the current round of consensus is to generate a created block (the first block in the block chain), default R is 0;

step 4, the housekeeping Bi (i ═ R) takes some affairs from the affair pool, packages them into Pre-Block, makes digital signature to the hash value of the Block head, proves that the Block producer is itself, and sends it to all committees and all housekeeping. Block deadline

Tcut＝GetPreviousBlockComfirmTime()+M*Tb；

Step 5, after receiving the Pre-Block, the committee node verifies the data in the Block, if the Block is agreed to generate, signs the hash value connected with the Pre-Header + local timestamp character string, and sends the signature and the timestamp back to the manager;

and 6, before the time Tcut, when the received block has at least Nc/2+1 signatures and timestamps of nodes, serializing the corresponding signatures and timestamps into character strings according to the ascending sequence of the timestamps, and attaching the character strings to a Pre-Header to generate a Ready-Header. After the R value is calculated, adding the R value and Block generation time (the maximum value in a time stamp list returned by a committee) on the basis of the Ready-Header, finally generating a Final-Header, releasing a complete Final-Block to the whole network, and directly jumping to execute the step 8;

Step 7, if the block generation time exceeds Tcut or the verification fails, identifying that the blocks before the time are all invalid blocks in the current round, making R equal to R +1 (if R is larger than or equal to Nb, R equal to 0), increasing M, and jumping to the step 4;

after the valid block is generated in step 8, the housekeeper R firstly sends the block to all the committee nodes, then issues the block, and after more than half of the committee nodes confirm that the valid block is received, the block enters a legal state and has final confirmation. If the number of signatures collected by the block does not exceed half, the block is invalid, and R ≧ R +1 (if R ≧ Nb, R ═ 0) is made, M is incremented, and the process jumps to step 4;

and 9, after all committee nodes and manager nodes receive the effective block, verifying that the block has more than half signature of the committee, deleting the transaction contained in the effective block from the transaction pool, acquiring the random number R contained in the effective block, starting the next round of consensus, judging whether the next round of consensus generates a special block, if so, jumping to the generation flow of the special block, and if not, jumping to the step 4.

In particular, if M > Nb, this means that no one caretaker can produce a valid block, which may occur in the case of network zoning, in which case the generation of blocks will fall into a dead loop until the network is restored, as discussed below.

The above describes a process of realizing a round of consensus by mutual coordination among roles from the view of the whole network state, and in the generation process of a new block, a manager plays an absolutely important role in all the participated consensus nodes, and the following algorithm pseudo code introduces the specific operation of the manager node in the duty cycle through a formal description.

The special block is the last block in an arbitrary period in order to complete the voting of the new caretaker. The generation process of the special block is similar to that of the normal block, except that the block is packed with not transaction data but next due housekeeping information, as shown in fig. 25.

Step 1, before a special block is generated, all committees select and generate a sequence from incumbent caretakers and caretaker candidates to form vote information and send the vote information to an on-duty caretaker;

and 2, simultaneously receiving the voting information of all other committees by all the committees and the incumbent caretaker, and putting the voting information into a memory pool (a transaction pool).

Step 3, the on-duty manager judges whether the number of the collected voting affairs exceeds half of the number of the committees, if so, the step 4-8 is executed to generate a new block; if not, continuously waiting until overtime and replacing the on-duty manager.

Step 4-8 is similar to step 4-8 of normal block generation, and the special block also needs to be certified by a signature of the committee to achieve consensus. Except that the content in the block is not general transaction information but vote information. After calculation, the node of Nb before the ticket ranking is selected as the manager for the next job period, and the information of the new manager is written into the block as a special transaction.

And 9, after the butler in the current round of the tenure finishes the generation of the last round of the special blocks, deleting the related voting information in the memory pool, finishing the tenure, formally releasing the tenure, and skipping to the step 3 of the common block generation flow.

Compared with the generation process of the common block, in the generation process of the special block, the housekeeper node only needs to add one step to judge whether the number of the collected voting transactions meets the regulation or not, and selects the voting transactions in the process of packaging the transactions. And the committee node adds a step of generating voting transactions in the generation process of the special blocks. The following algorithm presents the flow of operations from a committee node perspective in generating a block in a formalized manner.

The created block is the most special block in the alliance chain, the height of the created block is 0 on the block chain, the created block comprises initial alliance node information and first housekeeper node information, the basis of subsequent block generation is laid, the created block is also the most important block in the block chain, and the generation process is as follows:

Step 1, initial committee nodes of all creation unions communicate with each other to confirm online, and a committee (commission committee) with the minimum public key hash value is responsible for generating a creation block;

step 2, all committee nodes send identity authority change transactions upgraded to committees to an agency committee;

and 3, hope that the committee node which simultaneously takes the role of the manager identity sends an application to all the committee nodes, sends an identity authority change application message of the manager candidate, attaches a self-recommended signature, returns the signature if other committees approve the application, can successfully generate a legal identity authority change transaction if more than half of the signatures of the committees are received, sends the legal identity authority change transaction to an agency committee and issues the legal identity authority change transaction to the network, and the committee nodes in the whole network place the transaction into a memory pool.

And 4, all committees send votes to the commission committee, all committee nodes extract the verified candidate housekeeping information from the memory pool, select the least K candidate housekeeping account addresses (if the number of the candidate housekeeping account addresses is less than K, more than two votes can be cast for one account), serialize the votes into vote information and sign the vote information, and return the vote information to the commission committee.

Step 5, after the proxy committee counts, integrating the transactions of' identity authority change transaction for upgrading to committee > < identity authority change transaction for upgrading to housekeeper candidate > < vote message of all committees > < new housekeeper list >, generating Pre-Block, sending to all committees, and after signature confirmation of all the committees is obtained (the step confirms that communication between all the committees is smooth, which means that a alliance chain network is established), issuing a created Block, wherein the process is similar to the step 4-8 of creating a common Block.

And 6, after all committees receive the created blocks, deleting the identity authority change transactions and vote transactions to be confirmed in the memory pool.

When the created block is generated, the created block generates the first batch of housekeeping list information. In general, the number of confirmed housekeeping nodes in the created block may be smaller than the set housekeeping number Nb, and a plurality of housekeeping numbers may be allocated to some housekeeping candidates to fill the number of housekeeping numbers, so that each of housekeeping numbers 0 to Nb-1 has a corresponding node. The proxy committee takes the role of an accountant (attendant manager) in the creation of the founder block, and a flowchart thereof is shown in fig. 26.

After the creation block is generated, the generation flow of the normal block and the special block is normally operated. The pseudo code of the created block generation algorithm is as follows:

in step 4-8, where normal blocks are generated, a modified two-phase commit is actually applied to ensure the unique legitimacy of the blocks. Each current value keeper needs to perform a two-stage commit process of "Prepare-Ready-dispose- (confirm)" to complete the final confirmation of a block. Wherein the "Prepare-Ready" is a stage, which is an essential stage for block generation; "prompt- (confirm)" is a stage in which a Block is released after the Final-Block is generated. Since the system is in time synchronization with the NTP, only one attendant is defaulted to block generation and two-stage commit validation within a certain time period, the communication complexity is limited only by the number of committee nodes, and Nc messages are sent at each stage except for the Confirm stage, which is about O (3 Nc). In order to improve the algorithm operation performance as much as possible on the premise of ensuring correctness, the process of "dispose- (confirm)" is simplified into the process of issuing the block, and the confirm process is implicitly embodied in the process of consensus operation, as shown in fig. 27.

Stage Prepare: the butler on duty generates a Pre-Block which contains a list of legal transactions collected in the memory pool of the butler on duty, and the list is represented by a set { tx }, and is finally placed in a Block Body structure. The Hash of the last legal block is contained in the Pre-Header; current tile Height (Height of created tile is 0); last special block Height _ LastSpecial (which can be used to calculate whether the current block should be a special block); m may represent the number of blocks that are overtime or invalid in the current round of consensus, if M is 1, it represents that the number of the current round of attendant is the R 'value specified by the previous legal block, if M is not 1, the number of the current round of attendant is equal to (R' + M-1) mod Nb, which represents the relationship between the number of the current round of attendant and the R value specified in the previous legal block; butler _ i _ puk represents the public key information of the manager on duty, which is used to prove the accounting ownership of the block and also used to prove and count the final profit of each manager. Merkle _ Root is used as a pairwise Hash calculation value of all transactions in a transaction list, is used for checking the originality and the authenticity of all transactions, and is one of important parameters for preventing block chains from being tampered.

And Ready stage: the method comprises the steps that a manager on duty waits for all committees to check and vote on the legality of a block, the voting mode is to sign a Pre-Header and a current timestamp and return a signature to the manager on duty, wherein the signature C _ sign (j) represents a message signature obtained by encrypting the Pre-Header and C _ time (j) by the committee j, and the signature C _ time (j) represents a timestamp obtained when the block is encrypted after the block is received by the committee j, and influences the final generation time of the block to a certain extent. Each committee has and only has one chance to return a check signature for a Pre-Block during a duty cycle. When the on-duty manager collects more than half of signatures of committee pair blocks, a Ready-Block is formed locally, and then a Final-Block is generated. The Ready-Block is a transition stage from Pre-Block to Final-Block, and contains collected signatures and timestamps of committee nodes, which are represented by a list { < C _ time (1), C _ sign (1) >, …, < C _ time (j), < C _ sign (j), >, …, < C _ time (Nc), C _ sign (Nc) >, 1 ≦ j ≦ Nc, and a list of signatures and timestamps is abbreviated as a { C _ time, C _ sign } set and needs to be arranged in ascending order according to C _ time. The R value will be generated from the signature sets of all committee nodes, and the final generation time of the block is also dependent on the largest timestamp returned by the committee nodes, so whether the block generates the latest confirmation signature information returned by the committee on time, and not on the local timestamp of the attendant. After the R value information and the timestamp Time information in the Block header are supplemented, the attendant generates Final-Block.

A Propose stage: in the period of the process, the manager on duty has completed all the work, and directly releases the Final-Block to the whole network, and particularly, the Final-Block is firstly sent to the committee nodes and other manager nodes to announce the self accounting right of the Block.

And a Comfirm stage: in the stage, the committee does not need to explicitly send a confirmation message to the on-duty manager node, and after more than half of the committees receive the Final-Block, the Block really enters the confirm stage and becomes a legal Final Block. After more than half of the committees receive the Final-Block, the situation that the next serial number housekeeper on duty launches a preemptive attack to preempt the accounting right of the Block can be avoided. Each committee node only carries out signature confirmation operation on the Pre-Block sent by the current on-duty butler, so the committee can not confirm the Pre-Block submitted by the butler who carries out the preemptive attack, and as long as more than half of the committee nodes receive the Final-Block issued by the on-duty butler, the Pre-Block of the preemptive attack can not obtain more than half of the committee signatures and can not be invalid, so that the uniqueness and consistency of blocks are ensured under the implicit consensus, and the safety certification is also discussed in chapter 4. When the method is really used for system operation, modification can be made on the basis, an explicit Commirm stage is added, so that an on-duty manager can clearly know whether the Final-Block generated by the on-duty manager becomes a Final legal Block, and then the next manager is informed of the generation of the R round value Block, thereby improving the stability and the orderliness of system operation. As shown in fig. 28.

When a client initiates a data read request to a committee node in the alliance chain system, it is assumed that the committee has the latest block height h, denoted as Blockh. If the data read by the client exists in Block h-1 and the previous block, which indicates that the data has undergone the Commirm phase in the alliance Committee node, the Committee node can directly return the data after a block confirmation; if the data is present in Blockh, the committee needs to initiate a block height synchronization request to more than half of the committee. If more than half of the committees return the same < Height, Hash >, stating that the data has undergone the confirm phase in the federation committee node, the committee may return the data to the client; if the data does not exist in the committee's existing blocks, the committee also needs to initiate block height synchronization requests to more than half of the committees and determine whether the block data of the committee nodes are the latest synchronization data by judging whether more than half of the same latest height responses are recovered. By means of the system response mode, the decision service provided by each committee node of the system is the same, consensus consistency is achieved, and the consensus consistency is proved in the afternoon (theorem 4.2).

Each block is generated with a random number that points to the housekeeping number of the next encapsulated block to ensure that the housekeeping generates blocks in turn in a random order, as shown in fig. 29. The random number generation algorithm is as follows:

suppose that the butler receives K signatures of the committee and sorts the signatures in ascending order according to the timestamps sent by the committee, namely < C _ time [ i ], C _ sign [ i ] > (i is more than or equal to 0 and less than K, and Nc/2 is more than or equal to K and less than or equal to Nc-1). And (3) taking the maximum signature of C _ time and the timestamp to perform exclusive OR calculation to obtain a random number source Rsource:

let the method of intercepting the last 32 bits of string be substring end32(string), and the method of obtaining the random number R is as follows:

R＝StrToInt(SubStringEnd32(Hash(R_source)))mod N_bformula (3.2)

Because the time of the committee signature received by the attendant is unpredictable, the Rsource is unpredictable, and the obtained R value has strong randomness, so that the R value is prevented from having a certain rule. The possibility of doing badness by the housekeeper on duty is reduced. The random number algorithm pseudo-code is as follows:

the generated random number and the calculated max ({ C _ time }) are used as R and time parameters to be added into the Final-Header, are also important parameters of Block legality, and have an important check function on Final-Block which is finally released to a network. If the block is legal, the R value will directly specify the number of the next attendant housekeeper, and max ({ C _ time }) determines the generation deadline Tcut of the next block

From the summary design and detail design of the algorithm, a certain description and illustration explanation are given, and this section will make a summary of all consensus processes and all consensus key points for one consensus algorithm example, and give it in the form of a flowchart.

First, a general flowchart of the CoV is given, as shown in fig. 30, the committee node is responsible for verification and voting, and the housekeeping node is responsible for block generation. After the system is initialized, each node firstly enters the establishment stage of a founding block, and the founding block is generated by the joint of committee nodes and contains information of initial committee members and first managers. After the creation of the created blocks, the system automatically enters a cycle of 'generating Bw common blocks + generating 1 special block', wherein one cycle is an arbitrary period, one arbitrary period comprises Bw +1 rounds of consensus, and one round of consensus may go through M values of team managers to finally generate one block. The housekeeping node performs duty cycles between on-duty and off-duty periods and applies for synchronization blocks from most committees periodically to ensure the most current data state of its own node. The generation period of a block is also the duty period of a selected housekeeping generation block, each block contains a random number R generated by a random number algorithm specifically defined by CoV, and the housekeeping number i ═ R of the next block is specified. Two trends may appear in the flow depending on whether the next block to be generated by the housekeeper Bi is a special block. The algorithm flow will be described from the perspective of the caretaker on duty Bi and Nc committee node interactions.

Stage 1: generating Pre-Block

Bi judges whether a Block to be generated is a special Block or not, then determines whether to collect an unconfirmed transaction list from a memory pool or wait for a vote transaction sent by a committee node, and arranges the vote transaction or other transaction information to generate a Pre-Block.

And (2) stage: committee validation Pre-Block

And the Bi sends the Pre-Block to all committee nodes, waits for the verification of the committee, signs the hash value of the Block head and the current time stamp if the committee nodes accept the generation of the Block, and returns signature information C _ sign and the time stamp C _ time of the signature time to the Bi. When Bi receives more than half the number of signatures from the committee, the final block is generated. If the number of the received committee signatures is not more than half in the duty time or the timestamps of half of the received committee signatures are overtime, the generated block is invalid, in the next duty cycle, the generation right of the block is handed to the next manager with the sequential number, and the process jumps to the first stage to restart; if the block is valid and not timed out, then stage 3 continues.

And (3) stage: distribution block

And the Bi sequences the committee signatures received in the stage two and perfects element information of the block headers, including generating a random number R and adding block generating time, finally issuing qualified special blocks or common blocks to the whole network, and skipping to the stage 1 to repeatedly perform a new duty cycle.

After creation of the blocks, the important nodes for creating the blocks are committee nodes and housekeeping nodes. Further, the section gives the workflow of the caretaker and the committee after creating the segment, and the caretaker and the committee make the flow charts respectively, as shown in fig. 31-32. In the flow chart, < h, hs, M, time, R, sign (b) > is used to represent some key attributes in the block, and respectively represents < block height, < newest special block height, M number of shift cycles spent, timestamp generated by the block, random number generated by the block, and housekeeping signature >.

It is to be noted that the detailed flow is given for the key processes in the flowchart, but some processes are shown in an outline form. The step of checking whether the block is legal from the committee perspective includes judging whether the special block is generated at the current stage, and then determining whether the check function of the normal block or the check function of the special block is used according to the judgment result. In addition, the intention of the operation step of updating the housekeeper rating list according to the M value is to judge whether a housekeeper misses generating a new block, according to the received M value of a legal block, the consensus time in the round does not exceed M × Tb, and a block is generated, wherein M-1 blocks fail due to check failure or overtime, and committees need to make a penalty measure of deducting or even clearing the housekeeper generating the failed block.

Fig. 31-32 are only illustrative of the key flow of normal block, special block generation from a committee and housekeeping perspective. The manager and the committee node are the most critical consensus node in the CoV consensus, other nodes such as manager candidates and common nodes are in continuous cyclic operation of synchronizing blocks, updating memory data, forwarding blocks, issuing transactions and forwarding transactions, and most of the operation belongs to a network layer and a data layer. The operation of issuing a normal application transaction belongs to an application layer operation and is generally completed by a wallet function. Nodes with different identities in the P2P network respectively perform their own jobs and perform a round of consensus.

From the above summary of the overall CoV flow, the individual node operational flow, which is common to CoV, is described in formalized pseudo-code as follows. The program running on the stand-alone machine will perform different flow operations according to different identity models, wherein the pseudo-code of some of the detailed algorithms has been given in the foregoing.

Firstly, a State Machine of a single node runs an algorithm CoV _ State _ Machine, the essence of the consensus algorithm is a distributed consistency algorithm, and a message communication mode is defined on the basis of the distributed consistency algorithm. The essence of the distributed consistency algorithm is to solve the transition problem of the state machine to ensure that the state of each node in the network is consistent.

A pseudo code for running the CoV overall algorithm by one node is given in the CoV _ State _ Machine algorithm, after a series of initialization processes are carried out, the node judges the State of the node, and the operation of CoV processes with different identities is determined according to the State and configuration of the node.

The pseudo code can embody that the CoV algorithm design process is mainly a committee process and a housekeeper candidate process, and the two processes can run concurrently because the node can simultaneously take both the committee identity and the housekeeper candidate identity. The design of common user processes and non-system node processes does not belong to the category of consensus design.

The Commissioner _ Worker Algorithm describes the flow executed by the committee process, including the creation Block generation phase and the normal phase, wherein Run _ Generation _ First _ Block describes the creation Block generation Algorithm, see Algorithm 3; run _ commission _ in _ generation _ Block describes the flow of operations in the normal phase, i.e. the generation phase of normal blocks and special blocks, see Algorithm 2.

The filter _ Candidate _ Worker Algorithm describes the process executed by the manager Candidate process, and because the manager identity is a temporary identity, the manager workflow can be executed after the Candidate successfully races, so that the Candidate process comprises the executive process Run _ filter _ in _ generation _ Block and Algorithm 1 of the manager.

In the summary of the CoV algorithm, this section shows a specific operation process of the CoV by way of example, where the node parameters, random numbers, time and scores (assuming that score is added to the housekeeper to increase score by 1, and score is subtracted from the housekeeper to decrease score by 2) are all set as virtual values, and are only set for convenience of understanding the algorithm.

Suppose there are 8 nodes in the system with addresses (public keys) a, b, c, d, e, f, g, h, of which 3 committees, 6 housekeeping candidates (of which 3 doubles as housekeeping candidates and committees), and 2 common nodes. Committee nodes: a, b, c (Nc ═ 3, committee 3); a manager node: { B0, B1, B2, B3, B4} (Nb 5, the housekeeping number is limited to 5); manager candidate node: a, b, c, d, e, f; and (3) common nodes: g and h. Assume that the key system variables are: one duty cycle is Tb-10 s; generating the number Bw of the common blocks in an arbitrary period to be 3; the number Bw +1 of blocks generated in one arbitrary cycle is 4; the voting number K is 3; assume that the system is turned on at 02:15:45 as shown in FIG. 33.

02:15:45 system initialization, committee node establishment, minimum public key address of committee a, and generation of founding block for commission, as shown in fig. 34:

sending Tx _ PERMISSION (gen _ com, com, null, a/b/c, signal/b/c (Tx)) and Tx _ PERMISSION (com, bc, null, a/b/c, signal/b/c (Tx)) to each other by committees a, b, c;

Receiving a message that other committee nodes recommend the committee to become an administrator candidate by themselves, sending a voting transaction Tx _ VOTE ({ a, b, c }, signal/b/c) to the commission committee a according to the administrator candidate list and broadcasting the voting transaction Tx _ VOTE to the network;

after receiving the voting transaction, the commission committee a encapsulates all the Tx _ PERMISSION and Tx _ VOTE messages into Pre-Block and sends the Pre-Block to all other committee nodes.

D, committee a, B, c verifies the Pre-Block and sends signature SIGNa (Pre-header,02:15:48), SIGNb (Pre-header,02:15:55) and SIGNc (Pre-header,02:16:00) to a, after receiving the signature, committee a sorts the signature according to the time stamp and writes the signature into a Block header to generate R, the maximum time stamp 02:16:00 is selected as a Block time, a created Block < h is 0, hs is 0, M is 1, time is 02:16:00, R2, sign is generated, and the Block includes a next manager list { B0: a, B1: B, B2: c }.

02:16:00 starts the first run of the cycle, and the housekeeper { B0: a, B1: B, B2: c } takes turns packing the blocks, generating 3 general blocks and 1 special block through 4 rounds of consensus, as shown in FIG. 35.

1. 02:16:00-02:16:06, nodes d, e, f join the network, wish to become a candidate for housekeeping and request recommendation letters from committees a, b, c, respectively, and return a recommendation letter response after verifying their identities. d, after receiving the recommendation letter and the consent signature returned by the committee c, sending the recommendation letter to the committee a and b to obtain the consent signature of the committee a, so that d collects the consent signature of the recommendation letter of the committee c and a, the number of signatures exceeds half of the committee, and d can issue identity authority transformation transactions Tx _ PERMISSION (user, bc, < SIGNC (letter), SIGNA (letter)), d, sign (Tx)). e, f also issue Tx _ PERMISSION (user, bc, < SIGNB (lettb)), SIGNC (lettb) >, e, sign (Tx)), and Tx _ PERMISSION (user, bc, < SIGNA (letta), < SIGNB (letta), >, f, sign f (Tx)) in the same way. The butler B2: c collects all unacknowledged transactions and encapsulates them into Pre-Block for transmission to committees a, B, c. Committee B, c, upon receipt of Pre-Block, verified to be error free, sends the signature for Pre-Header to the butler B2: c and updates the butler's B2: c score. And committee a does not receive Pre-Block due to network delay, and butler B2: c generates and issues blocks Block < h ═ 1, hs ═ 0, M ═ 1, time ═ 02:16:06, R ═ 1, sign >, according to signatures of committee B, c. The time difference between the block and the time difference of the created block, namely the previous block, is 6s < Tb to 10s, more than half of signature agreement of committees (b, c) is possessed, so the block generation is effective, all the committees add scores to the block generator after receiving the block, and the scores of the housekeeper candidate list stored in the three committee nodes are SCOREa { a:0, b:0, c:1}, SCOREb { a:0, b:0, c:2}, SCORec { a:0, b:0, c:2 }.

2. 02:16:06-02:16:13, node h, g join the network, but only as a common user identity, and no candidate is applied, a housekeeper B1: B generates a Block < h ═ 2, hs ═ 0, M ═ 1, time ═ 02:16:13, R ═ 2, sign >, and each committee node score list is SCOREa { a:0, B:2, c:1}, SCOREb { a:0, B:2, c:2}, and SCOREc { a:0, B:2, c:2 }.

3. The node d, e and f become the housekeeping candidate formally, and each node updates the housekeeping candidate list. In the consensus of the round, a butler B2: c generates a Block Block < h ═ 3, hs ═ 0, M ═ 1, time ═ 02:16:21, R ═ 0, sign >, and the committee score lists are SCOREa { a:0, B:2, c:3}, SCOREb { a:0, B:2, c:4}, and SCORec { a:0, B:2, c:4 }.

4. 02:16:21-02:16:28, since the last block (h-hs) ═ 3 is equal to Bw, this round of consensus will result in a special block with h ═ 4. Committee a, B, c sends VOTE transactions Tx _ VOTE ({ c, d, f }, sign), Tx _ VOTE ({ c, d, e }, sign) to butler B0: a, where the first half (1) of 3 VOTEs in each VOTE transaction is derived from the list of highest scoring butler candidates, and the remaining VOTEs are randomly cast to butler candidates who do not participate in the round of the job. And (4) counting by the butler B0: a to obtain vote ranking { c:3, d:3, e:2, B:0, f:1 and a:0}, and obtaining a new butler list { B0: c, B1: d, B2: e } according to the butler number Nb being 3. The voting result and the original voting affair form a Pre-Block and are issued to all committees, after committee signatures are collected, blocks Block < h ═ 4, hs ═ 4, M ═ 1, time ═ 02:16:28, R ═ 2, signa > are generated, and the committee node scores are listed as SCOREa { a:2, b:2, c:3}, SCOREb { a:2, b:2, c:4}, and SCORec { a:2, b:2, c:4 }.

The second run of cycles begins at 02:16:28, where the housekeeper { B0: c, B1: d, B2: e } takes care of rotating the encapsulation blocks, generating 3 normal blocks and 1 special block through 4 rounds of consensus. In this round of consensus period example, rounds 2 and 3 consensus will show an example of generating invalid blocks due to signatures not being over half and timed out.

1. 02:16:28-02:16:33, butler B2: e generated Pre-Block, committee B, c returned a signature to butler B2: e after receiving Pre-Block, committee a did not receive Pre-Block for network reasons. The manager B2: e generates a distribution Block Block < h ═ 5, hs ═ 4, M ═ 1, time ═ 02:16:33, R ═ 0, sign >, and the list of the respective Committee node scores is SCOREa { a:2, B:2, c:3, d:0, e:1, f:0}, SCOREb { a:2, B:2, c:4, d:0, e:2, f:0}, SCORec { a:2, B:2, c:4, d:0, e:2, f:0 }.

2. 02:16:33-02:16:43-02:16:45, housekeeper B0: c generated Pre-Block, committee a, B, c received the return signature to housekeeper B0: c, because of network delays, the blocks generated and issued by housekeeper B0: c based on the signatures of committee a, B, c were not received by other nodes in the network by any time, i.e., blocks generated and issued by committee a, B, c were not received by other nodes in the network, i.e., blocks generated and issued by housekeeper B0: c were not received by other nodes in the network by any time

Block < h > 6, hs > 4, M > 1, time 02:16:42, R > 0, sign >. After 02:16:43, the account right is handed over to the housekeeper B1: d, Pre-Block generation starts again, the signature returned by committee a, B to housekeeper B1: d is received, committee c receives the generated Block, verifies that the generated Pre-Block of B1: d does not pass and deduces the housekeeper sending the Pre-Block, when B1: d generates and issues Block (h) 6, hs 4, M2, time 02:16:45, R1, signd > according to the signature of committee a, B and forwards the Block to nodes of committee a, B, c smoothly. The committee nodes deduct the behavior of the housekeeper c timeout transmission block, and the scores of the committee nodes are listed as SCOREa { a:2, b:2, c:3+1-2 ═ 2, d:0+1+1 ═ 2, e:1, f:0}, SCOREb { a:2, b:2, c:4+1-2 ═ 3, d:0+1+1 ═ 2, e:2, f:0}, SCOREc { a:2, b:2, c:4+2-2 ═ 4, d:0-2+ 1-1, e:2, f:0}, as shown in fig. 36.

3. 02:16:45-02:16:55-02:16:59, housekeeper B1: d generating Pre-Block, committee receives return signature to housekeeper B1: d, committee a, B did not receive Pre-Block due to network delay, housekeeper B1: d forced to generate and distribute Block h 7, hs 4, M1, time 02:16:53, R0, sign, and the number of verification signatures after committee a, B, c received the Block does not pass its deduction. After 02:16:55, the housekeeper B2: e who has not received the legal Block starts to regenerate Pre-Block, and committee a, B, c receives the return signature to the housekeeper B2: e, B2: e generates and issues Block < h ═ 7, hs ═ 4, M ═ 2, time ═ 02:16:59, R ═ 1, sign >, and forwards to the nodes of committee a, B, c smoothly. Each committee node score list is updated as SCOREa { a:2, b:2, c:2, d:2-2 ═ 0, e:1+1+ 3, f:0}, SCOREb { a:2, b:2, c:3, d:2-2 ═ 0, e:2+1+1 ═ 4, f:0}, SCOREc { a:2, b:2, c:4, d: -1+1-2 ═ 2, e:2+1+1 ═ 4, f:0 }.

4. 02:16:59-02:17:07, since the last Block (h-hs) ═ 3 equals Bw, the round of consensus will produce a special Block with h ═ 8, committee a, B, c sends VOTE transactions Tx _ VOTE ({ e, a, f }, signa), Tx _ VOTE ({ e, B, f }, sign), Tx _ VOTE ({ c, a, f }, sign) to the butler B1: d, wherein the 3 VOTEs in each VOTE transaction, the first half (1) is derived from the list of highest scoring butler candidates, the rest are randomly cast to butler candidates not participating in the round of duty cycle, butler B1: d counts to derive VOTEs { f:3, a:2, e:2, B:1, c:1, d:0}, the butler Nb 3 is derived as a new butler B: 32, B: 32: 36: 539, all VOTEs are generated as B-36: 36B, B-539, after receiving the half signature, generating a Block Block < h ═ 8, hs ═ 8, M ═ 1, time ═ 02:17:07, R ═ 0, sign >, and the list of the committee scores is SCOREa { a:2, b:2, c:2, d:0+2 ═ 2, e:3, f:0}, SCOREb { a:2, b:2, c:3, d:0+2 ═ 2, e:4, f:0}, SCORec { a:2, b:2, c:4, d: -2+2 ═ 0, e:4, f:0 }.

Feasibility analysis and proof of consensus mechanism

A consensus model is completely discussed based on a voting mechanism and a federation chain, and a minority majority-obeying principle is theoretically followed, so that the controllability of the federation members on the business data of the federation chain is stronger. However, the most important problem of the consensus mechanism is to ensure security and availability, most of the existing public chain consensus mechanisms sacrifice part of performance for ensuring security, and the CoV is based on the credible characteristic of an alliance node and matched with an appropriate consensus decision, so that the algorithm correctness is ensured, meanwhile, the delay of block chain transaction confirmation is greatly reduced, and the working performance of the block chain is improved.

The consensus mechanism is essentially a distributed consistency algorithm which enables data and states of nodes to be consistent in a large distributed network, so that the classical CAP theorem in distributed computing^[73]And BASE theory^[74]Are often used to verify consensus algorithms. CAP theory proves that a distributed system cannot simultaneously meet three basic requirements of Consistency (C), Availability (A) and Partition tolerance (P), and at most, only two of the three basic requirements can be met. Therefore, the existing distributed algorithm Basically makes a balance between C and A, and a famous BASE theory is also proposed, wherein BASE is the result of balancing consistency and availability in CAP, and according to the summary of distributed practice of the large-scale Internet system, the core idea is that under the condition that strong consistency (strong consistency) cannot be achieved, the distributed system can reach Basic Availability (BA), weak state (S: Soft state) and final consistency (E: eventuality consistency).

The method is based on the basic requirements of the classical distributed theory and the consensus theory, and is used for analyzing and proving the safety and the correctness of the consensus algorithm. Wherein, the correctness proof is analyzed, discussed and proved from the three aspects of final consistency, activity (availability) and partition tolerance, the three attacks common in the blockchain system and the resistance of the CoV algorithm to the three attacks are discussed in the section of security analysis, and finally the performance of the consensus mechanism is analyzed theoretically.

Under the assumption of a security model, here, first, a requirement for the correctness of the consensus algorithm in the block chain scenario is given, and the CoV algorithm is based on the following assumption:

assume that 1: weak synchronization model: all committee node time is assumed to be synchronous, and as the committee nodes are coalition member nodes, the time synchronization above millisecond level can be ensured by using an NTP time synchronization protocol;

assume 2: assuming that all committee nodes are trusted and more than half of the committees can work properly: as member nodes in the federation chain, the committee nodes use operating systems and configurations with higher security defense coefficients, and the situation of committee individual attack on the system generally does not occur, and if so, the federation members are quickly ejected from the federation and the system loss is repaired by the remaining federation committee nodes, so that the federation committee nodes can be considered as all trusted. Each committee node may be an internal cluster of an enterprise, and a strong consistency algorithm such as Paxos is used in the cluster to ensure synchronization and provide uninterrupted service to the outside, so that the possibility that the alliance node is down and cannot work is low. Even so CoV can tolerate not more than half of committee nodes going down to be inoperative or being isolated by a partition, which will be analyzed in the security analysis.

Assume that 3: assuming that at least one steward node is honest: to ensure the terminability of the algorithm, at least one steward node is required to work honestly, and for the setting that the committee node can double as the steward node, the assumption is fully valid, and is analyzed in the final consistency analysis.

Assume 4: it is assumed that even if the system is partitioned, the above-described assumptions 1-3 are satisfied in at least one partition.

On the basis of the assumptions stated above, the CoV satisfies the following three conditions to guarantee its correctness:

1. final consistency: the final consistency emphasizes that the blockchain data copies in all nodes in the blockchain system can finally reach a consistent state after a period of synchronization, and the CoV has consensus terminability, and can realize the final confirmation and non-tamper of the transaction only by one blockchain confirmation.

2. Availability: the availability means that the consensus algorithm can enable the service provided by the system to be in an available state consistently, the result can be returned within a limited time for each operation request of the user, the blocks can be produced within a limited time for the operation of the consensus process, and the CoV can ensure that the manager node can produce the effective blocks smoothly and continuously under the appropriate parameter setting.

3. Partition tolerance: partition fault tolerance presents a significant challenge to distributed systems, and it is still necessary to ensure that a service meeting consistency and availability is provided to the outside when any network partition fails. CoV may achieve a degree of partition tolerance that is met if a partition contains more than half of the committee and at least one honest butler.

The final consistency is that the consistency is the same,

theorem 4.1 under the assumption of the CoV model, the CoV consensus result can be completed in a limited time (terminability).

And (3) proving that: the CoV consensus separates the execution right and the check right of the generated block, the execution right is handed to the manager node, the check right is handed to all committee nodes, and the block can be normally and legally generated only by obtaining the signature consent of more than half of the committee nodes. The conditions under which the block cannot be generated on time include two points: (1) the housekeeper node cannot generate a block; (2) blocks generated by the housekeeper node cannot pass more than half of the committee's consent. If any one of the conditions is permanently satisfied, the CoV consensus will go on indefinitely, no blocks can be generated, and the system consensus cannot be achieved. Aiming at the condition (1), a rotation rule of execution rights is set in the CoV algorithm, an administrator must generate an effective block within a specified duty cycle Tb, all nodes synchronize time through an NTP protocol, and if the time is out, the execution rights of block packaging are automatically handed over to an administrator node with one added number. Therefore, only at least one manager capable of honest and normal operation among all manager nodes is needed to generate the correct block. Since the committee node can simultaneously take over the role of the housekeeper and the committee node is trusted, the probability that the assumption 3 is established is extremely high, and the condition (1) does not exist when the assumption 3 is true. For the condition (2), as long as the housekeeper can honestly generate a correct Pre-Block, the committee node which normally works signs and agrees to the Pre-Block, the condition (2) can be met only under the two conditions that the committee is down and cannot work or the partition cannot receive the Pre-Block, and if the condition (2) is met, the condition (2) is not met. Therefore, under the assumption of the CoV model, the CoV consensus result can be completed within a limited time, and the theorem 4.1 is established and proved.

Theorem 4.2 under the assumption of CoV model, the final decision-making results of different nodes should be the same (consensus)

And (3) proving that: the result that different nodes use the CoV consensus to complete the final decision is the same, which means that the block chain data finally stored by each node is the same. In the federation chain scenario, since the federation-committee nodes are system providers, and data of all nodes in the network are synchronized using the data of the federation-committee nodes as a standard, theorem 4.2 may be limited to the fact that the blockchain data finally saved by each federation node is the same, which is equivalent to the fact that requesting data from different committee nodes in the federation chain should be the same.

Before proving theorem 4.2, a lemma is first proved by a second mathematical induction method, which complements proving theorem 4.2. If the theorem 4.2 is established, under the condition that the system node keeps consistent with most committee node data, the block chain data finally kept by different nodes are consistent, and the decision result is the same, the theorem 4.2 is established, and the certification is finished.

And 4.1, when a Block Block with the height of h and a complete and error-free format appears in the system, the transactions of the blocks 0-Block h-1 all have final consistency and cannot be tampered.

And (3) proving that: when h is 0, Block0 is a created Block, which is generated by the commission and ensures that each committee node signs the generation of the approved Block, so each committee node will keep the same created Block.

When h is 1, a complete format check Block1 appears in the system, which indicates that more than half of committee nodes check and sign Pre-Block of Block1, and this means that a set C containing more than half of committee nodes exists, and each committee of C has Block 0. In fact, at this point in the system, each committee node has already saved the same founder Block, illustrating the final consistency that the transactions of Block0 already have had. I.e. when h is 1, the conclusion is true.

The conclusion is true when h ≦ k, i.e. when a Block with height k and perfect format check appears in the system, it indicates that the transactions of Block 0-Block-1 Block all have the final consistency.

When h is k +1, namely when a Block k +1 with the height of k +1 and complete format check appears in the system, because the format check is complete, more than half of signature of the committee nodes is contained in the Final-Header in the Block k +1, which indicates that a set C containing more than half of signature nodes exists, each committee in C signs the Pre-Block of the Block k +1, and the signature is placed in the Final-Header of the Block k +1 by the manager node. Therefore, each committee in C owns a blockak that is already identical and that has already passed the complete format check, otherwise blockak +1 cannot be verified in C, nor can it be generated by the housekeeper, and even more likely cannot pass the format check. Since there is a Block that passes the complete Format check, assuming that it holds true that all committees in C have the same Block 0-Block-1, all committees in C have the same Block0-Block, and therefore, when h ≦ k holds, h ≦ k also holds.

Then, proposition holds true for all h. Therefore, the theorem 4.1 holds, and the evidence is complete.

Lemma 4.2. the federation chain produced under CoV consensus does not branch.

And (3) proving that: lemma 4.2 is equivalent to a federation chain created using CoV consensus, where invalid blocks may occur in the chain, but no two bifurcations occur, with a default number of blocks for one bifurcation ≧ 2, and lemma 4.2 is used herein to prove lemma.

Assuming that the CoV has a bifurcation as shown in the left diagram of fig. 37, two different blocks, block h +1 and block h +1 ', a parent block of block h +1 is block h, a parent block of block h + 1' is block h ', and the bifurcation, i.e., block h and block h', is different blocks.

Since Block h +1 exists, it means that there is a set C containing more than half of the committees, and the blocks stored by the nodes in C are identical, and on this basis, the Pre-Block of Block h +1 is verified and signed, and written into the Final-Header of Block h +1 by the attendant manager.

Similarly, because Block h +1 'exists, it means that there exists a set C' containing more than half of the committees, and the Block h 'stored by the node in C' is the same, and on this basis, the Pre-Block of Block h +1 'is verified and signed and written into the Final-Header of Block h + 1' by the attendant.

Since C and C' are both sets comprising more than half of the committees, both sets necessarily include at least one common committee, i.e.

Let C ═ C ' ═ a, because a belongs to C, blockaha ═ blockah owned by any one of the committees a, and because a belongs to C ', blockah ═ blockah ' owned by any one of the committees a, and blockah ═ blockah.

Therefore, the assumption is not true, and the original proposition is true. As shown in FIG. 37, the branch with the block number less than or equal to 1 is an invalid block and cannot be confirmed, as shown in the right diagram of FIG. 37, the federation chain is not branched, and the theorem 4.2 holds, after the certification is completed.

It is deduced 4.1. the transaction in CoV only needs a validation of one block to prove its finality and non-tamper.

According to the theorem 4.1 and the theorem 4.2, the system does not have the bifurcation with the block number larger than or equal to 2, but a failure block may exist, and after a transaction Tx is packaged into a block Blockh, once a block Blockh +1 with the Blockh as a parent block appears, Tx exists in a block chain stored by more than half of committee nodes, so that the system is not falsifiable and has the finality.

The schematic diagram of the resulting CoV generation of a coalition chain in which valid and invalid blocks coexist but are not bifurcated is shown in fig. 38.

The characteristic that the CoV is not forked and can be confirmed only by one block can be illustrated by a simple example. As shown in FIG. 39, assume that the system generated a valid block at time T0, and committees C1, C2, and C3 owned this block. During T0- (T0+ Tb), the butler i is the on-duty butler for C1, C2, C3, and a verification signature is returned for the Pre-Block it generated. However, due to network delay, the Final-Block issued by the housekeeper i only reaches C1, the Block time is T1, and the Final-Block cannot reach C2 and C3 in time. Therefore, during the period of (T0+ Tb) - (T1+ Tb), the caretaker on duty is butler j for C1, and the caretaker on duty is butler i +1 for C2 and C3, so that committee C1 only returns the verification signature to the Pre-Block sent by butler j, committees C2 and C3 only return the verification signature to the Pre-Block sent by butler i +1, and the Final-Block time generated by butler i +1 is T2. After (T1+ Tb), before the Final-Block from the housekeeper i +1 is received, the housekeeper on duty is housekeeper j +1 for C1 and housekeeper i +2 for C2 and C3. After receiving the Final-Block from the housekeeper i +1, committees C1, C2 and C3 renew the memory pool and system variables, and the housekeeper on duty designates the housekeeper k for the R value of the new Block, and then C1, C2 and C3 only verify and sign the Pre-Block from the housekeeper k. The Final-Block that butler i arrived late is rejected by committees C2 and C3, and instead receives the latest Block returned by the committees. When Final-Block generated by the housekeeper k appears in the network, it shows that the Block generated by the housekeeper i +1 is the real valid Block in the housekeeper i and the housekeeper i +1, and the transaction in the Block is finally determined. When the Final-Block generated by the housekeeper k arrives at all committees, the system finally considers the blocks generated by the housekeeper i +1 and the housekeeper k as valid blocks, the Block generated by the housekeeper i is invalid, and the Block generated by the housekeeper j cannot collect more than half of signatures of the committees or generate the R value to designate the subsequent housekeeper.

Therefore, only the generation block of the manager k is needed to be obtained, the final property and the non-tamper property of the generation block of the manager i +1 can be verified, and the conclusion that 4.1 is established is concluded.

Inference 4.2. the CoV algorithm can ensure that every committee node in the federation chain provides the same decision or service externally.

And (3) proving that: since the old data of the blockchain cannot be tampered, if the client sends a request to the alliance chain system to read the latest blockchain data, the responses returned by each committee in the alliance are the same block, and the conclusion of 4.2 can be proved to be true. Under the condition that the system is not partitioned, after a node is accessed to a alliance chain network, a synchronous block is firstly applied to a committee node, and the latest and most complete block data of the current system can be obtained only by ensuring that the highest block data < Height, Hash > is the same as more than half of the committee nodes. When a client sends a request to a committee of the alliance chain system to read the data of the latest block, the committee sends a request for requesting the Height of the highest block to other committees, and the data of the block Height can be sent back to the client as long as the data < Height, Hash > of the highest block is the same as more than half of the committee nodes. The results returned to the client are the same for any one committee node, and therefore the inference is true, and the certification is complete.

Activity, in order to become a manager through layer-by-layer recommendation and competition, obtain the accounting right and obtain corresponding rewards, the manager node must keep the maximum time online, honestly work according to the provisions of the alliance protocol, and complete the responsibility of the encapsulation block within a limited time.

The theorem 4.3.CoV consensus can achieve the activity of the consensus mechanism, continuously generating valid blocks.

And (3) proving that: CoV consensus operates cooperatively between committee, housekeeper, and housekeeper candidates to generate valid blocks. The committee node only needs to conform to hypothesis 2 to continuously perform validity verification and voting on the blocks generated by the housekeeper, and the housekeeper candidate has no difference in function from the common node in the non-incumbent period. Therefore, the most important thing in the CoV algorithm is whether the housekeeping node can continuously and effectively produce the legal blocks. To demonstrate theorem 4.3, a lemma 4.3 is proposed herein to assist in the demonstration. If the theorem 4.3 is established, the system is proved to be continuously provided with a manager working honestly. Considering the worst case by combining the assumption of CoV, only one manager capable of working honestly can accept more than half of committees of the normally generated blocks, so that Final-Block can be generated smoothly, the behavior that illegal blocks generated by other managers cannot become valid blocks can only delay the speed of generating the blocks by the system, the accounting right is handed to the next manager with the serial number, the system can generate the valid blocks until the accounting right is handed to the only honest manager, and the theorem 4.3 is established and is proved to be complete.

And 4.3. leading the housekeeper nodes in the CoV to generate legal blocks more and more effectively through the competition of superior and inferior.

And (3) proving that: if the manager does not follow the protocol generation block issued by the alliance, the committee verification block is incorrect, or the manager does not generate the block in an overtime mode, scores of the manager are correspondingly deducted from all the score lists of the committees working normally, the probability of obtaining the number of tickets during election is reduced, and the election fails, so that no benefit can be obtained. It can be proved that the housekeeper who attempts to generate the illegal blocks can not obtain any income and is difficult to compete successfully, and the successful competition in the competition with the high or low quality is a reliable housekeeper, and the system is more and more reliable.

The voting process is modeled here, and a scoring mechanism and a reward mechanism are introduced to fully illustrate and prove that the reliability of the housekeeper is controllable, and the reliability and the activity of the housekeeper work can be adjusted from two parameters: committing votes and housekeeping gains.

First, the vote number K of the committee vote is discussed.

According to the voting rules, Nc committees voted for Nb householders from Nbc householder candidates during each round of election. Assuming Nbc ≧ Nb, this process can build a voting mathematical model to study how many votes each committee casts at least to select a reasonable housekeeping list, so that this list can be agreed by half of the committees to facilitate the smooth generation of special blocks.

In the first step of analysis, the model does not take into account the influence of the scoring mechanism. Assuming that the voting lists of the committees are random, no votes are discarded, and each committee casts K votes, i.e., a voting list containing K node addresses is given, then the probability that each candidate gets a vote from one committee is the same, K/Nbc, and the voting campaign obeys the two-term distribution principle:

the probability that a housekeeping candidate obtains X tickets is P (X):

by setting the size of K, the average number of votes obtained by each election housekeeper can exceed half of the number of committees Nc/2, wherein Nc/2 is set so that the voting result can be agreed by half of the number of the committees, and the probability that the special block can be generated smoothly is P1.

Since Nb housekeeping needs to be selected among the Nbc candidates, the probability of success for one candidate is P2.

P1 > P2 formula (4.4)

According to the equations (4.2) and (4.3), the minimum K value satisfying the equation (4.4) is the optimum number of votes.

For example, the setting parameter Nc is 20, Nb is 50, and Nbc is 200. Images of P1 and P2 were drawn with Matlab, as shown in fig. 40. The abscissa is K and the ordinate is probability value, and it can be seen that the value of the curve intersection is the optimal value of K.

When K is more than or equal to 81, P1 is more than P2, when K is less than 81, P1 is less than P2, so the optimal value K is 81.

As a result, when K is 81, each committee can submit 81 tickets, then the housekeeper gets more than half the number of tickets with a high probability, meaning that the housekeeper can get more than half the acceptance of the committee. Therefore, the voting result is more scientific and fair, and the condition that a special block cannot be generated is avoided, namely the voting result cannot be approved by most members. When CoV is applied to different systems, K can be easily derived by changing the values of Nc, Nb, Nbc.

Before considering the second factor, the voting model is newly improved, and the consideration factor of the scoring system is added to regulate and control the honest working factor of the housekeeper.

The more honest the candidate works during the period of electing the caretaker, the higher the probability that the candidate can generate the block agreed by the committee verification, the more legal blocks are generated, the higher the score obtained by the node in the scoring list of all the committees, the higher the honesty factor representing the node, and the higher the probability of obtaining the ticket number than that of the common node. The deviation of the probability of the node getting the committee vote from the average probability is represented by an honesty factor α, so the probability of a candidate when electing a housekeeper is:

Alpha >0 indicates that the candidate has a probability of getting a vote higher than the average level, and alpha <0 indicates that the candidate has a probability of getting a vote lower than the average level.

The probability distributions of the different cases are compared by setting α ═ 0.3, -0.2, -0.1,0,0.1,0.2, 0.3. The obtained results are shown in fig. 41. As can be seen from fig. 41, when K is determined (for example, in fig. 41, K is a straight line of 81), the more honest the householder is, the higher the probability of obtaining the number of tickets is, the more likely it is to be successfully elected.

Next, consider a second factor: and (5) gaining the housekeeper. In an arbitrary period, without considering the honesty factor first, the candidates have an average probability of Nb/Nbc electing to be caregivers. And in each duty cycle, the caretaker has a probability of packing blocks of 1/Nb. Therefore, for a butler candidate i, the probability pi of producing a valid chunk is Nb/Nbc × 1/Nb 1/Nbc, assuming that the wage for producing a valid chunk is B, the cost (including energy consumption and hardware investment) of the candidate for mining investment per unit time (single duty cycle) is denoted as ei, and in each duty cycle, the event that the candidate can become butler and can be selected as the duty butler production chunk can be denoted as Eik.

Eik satisfy the independent random variable distribution, it can be deduced that after n encapsulation periods, the node i can get the following benefits:

The average gains and variances available are:

μ(R_i)＝n*p_i*B-e_in type (4.9)

δ²(R_i)＝n*B*(p_i+p₀)(1-p_i-p₀) Formula (4.10)

When mu (R)_i) Only when the administrator node is more than 0, the probability is good, so that each administrator candidate node can establish a bankruptcy model. If the income of a node in the process of participating in the accounting consensus can not fill the cost of the node in the process of waiting for accounting for a long time, the manager is said to be in a bankruptcy state, and the node can quit the network because the node is not in a payoff state. The failure probability of a node i participating in election of a manager is as follows:

P[μ(R_i)＜0]formula (4.11)

Combining equations (4.5) - (4.11), it can be seen that if node i is the more honest and reliable work and keeps on-line for a long time, the higher the probability of getting high score in each committee, the higher the α value, the higher the probability P3 of being selected as the manager, the higher the probability pi of getting the accounting right for the manager on duty, and the profit μ (R) of the node_i) The greater the probability of failure P [ mu (R) ]_i)＜0]Correspondingly, the lower the node is, the less the node is prone to being damaged in the process of competing for the housekeeper, the truthful and reliable work can be continuously kept, the larger the power of long-time online is, and therefore a positive incentive is formed, and the housekeeper is encouraged to work more and more truthfully and reliably. On the contrary, it can be deduced that nodes attempting to do malicious or infected nodes are automatically quitted from the network because the number of times of generating the failure blocks is large, the scores are low at each committee, the alpha value is small, the electing probability is small, the probability of obtaining the accounting is reduced, and the probability of obtaining the profit is lower and lower. Because of the security guarantee of the CoV algorithm, the malicious node attacks the network The attack is limited to delaying the speed of generating valid blocks by the system when selecting invalid blocks for the housekeeper candidate, which leads to the reduction of the system throughput, and such malicious nodes are finally eliminated due to the incentive mechanism of the system.

In addition to eliminating malicious nodes, the number of candidates of the system can be effectively limited by the setting of the incentive mechanism, according to the formula (4.9), the revenue setting of the system for the housekeeper packaging block must meet the following conditions, otherwise, most housekeepers enter and leave no longer, the number of housekeepers is reduced, the safety of the system is affected, and therefore, the setting of wages needs to meet the requirement of mu (R) in the formula (4.9)_i) > 0, i.e.:

B＞N_bc*e_iformula (4.12)

Observing equation (4.12), it can be seen that the profit B of the packaged block can be set according to the number of candidates expected by the system, which means that by regulating the profit B, the number of candidates expected in the system can be regulated. Considering the scoring mechanism, the probability pi that a candidate i gets a benefit is less than the average level, and the node that joins the system later is less likely to get a higher honest factor. If the number of system candidates is too large, the candidate nodes are bound to enter and leave, and the yield cannot cover the cost consumed for waiting for the encapsulation block, so that the candidate is lost due to bankruptcy, the number of managers is effectively controlled, and the enthusiasm of excellent managers is improved. Thus, the lemma 4.3 can be proved to be established.

Partition tolerance, theorem 4.4.CoV consensus under the condition of partition operation, only a certain partition including more than half of committees capable of normally operating and at least one housekeeper capable of working honestly can keep continuous operation.

And (3) proving that: according to theorem 4.1, in the case of a partition, if a partition includes more than half of the committees that can work properly and at least one housekeeping agent that can work honestly, the partition can continue to run and yield blocks. Due to the insufficient number of the committees in other partitions, the consensus process falls into the process of continuously and circularly replacing the housekeeper, and new blocks cannot be generated. Therefore, the system can continue to operate only when the partition exists, and the theorem 4.4 is established and the certification is finished.

It was reasoned that the CoV would not "branch" in the case of partitioning either "

And (3) proving that: given that network partitioning is an important factor in initiating block chain forking, this proof will demonstrate that CoV will not fork in extreme partitioning scenarios as well. Consider a network that is split into two completely separate partitions, partition a and partition B,

as long as the committee number of one of the partitions is met

And at least one honestly working housekeeper, the block in partition a can still be effectively generated according to theorem 4.4. But in partition B, then

The transaction of (a) cannot be verified and written to the block because even if the block can be successfully packaged by the housekeeper, more than half of the committee's check signature cannot be obtained, so no new chain can be generated in partition B. Thus, under the condition of meeting the number of committees and honest housekeepers of a certain partition, CoV allows the partition without bifurcation, and the partition is proved to be complete.

Safety analysis, theorem 4.5, setting the number of alliance nodes in the system as Nc, and when the alliance committee nodes which work effectively in the system

Data in the blockchain can be guaranteed to be safe and legal.

And (3) proving that: using the anti-syndrome method, it is assumed that illegal blocks can be validated effectively. The valid block must be acquired not less than

And (4) signature. Since the number of committees of active work in the system is not less than

The committee of active work does not verify the signature of the illegal block, and even sends the illegal block to the housekeeper to reduce the honesty factor, so that the signature number obtained by the illegal block at most does not exceed the

Cannot exceed half the number. Therefore, the assumption is false, the original proposition is correct, and the evidence is complete.

A double-flower attack, in a blockchain transaction, for example, in terms of bitcoins, is equivalent to a transfer transaction tx. tx has an input equal to a bit money balance not yet spent and an output from a previously confirmed transaction; the amount of the address converted after the tx output, i.e. the confirmation of the Transaction, becomes UTXO (Unpend Transaction output) as the new amount of the unspent bitcoin. One UTXO can only be used for one-time input of a new transaction, and if two different transactions use the same UTXO as input, the situation where the two transactions exist in a chain at the same time is called a double-flower attack. In an extended way, if two contradictory and incommorable transactions exist on the blockchain at the same time, the blockchain is called to suffer from double-flower attack, and great challenges exist to the security of the blockchain data.

The double-flower attack is still a serious loophole in the public chain consensus algorithm, and the consensus algorithm depends on uncontrollable public awareness to compete for accounting rights because the public chain algorithm is not managed. Especially in Nakamoto consensus, when malicious nodes are computationally intensive, which may cause illegal transactions to be encapsulated into blockchains as well, attacks by double-flower transactions are inevitable. Users in the network need to wait for the validation of multiple tiles to increase the confidence in a transaction that has been posted in the chain of tiles, with no final validation of the transaction. When the computation power of the malicious node exceeds 50%, the block number can be forcibly added to the wrong fork until the wrong fork becomes the longest chain recognized by the whole network, so that the block chain system is no longer reliable.

There is no possibility of a double flower attack in CoV consensus. Since the CoV is applied in the alliance chain scene, all transactions can pass the verification of more than half of alliance member nodes, the alliance member nodes are regarded as the service parties of the credible alliance chain system in the network, and any contradictory incoherent transactions cannot be simultaneously verified. Once one of the two conflicting transactions is verified through the write chain, as a corollary 4.1, after waiting for the confirmation of one block, the other transaction that is not compatible with it cannot be verified through more than half of the committees, and cannot be confirmed. Thus, at any time, a transaction that has a double flower attack can only have one legitimate transaction written onto the chain. Therefore, the CoV can automatically avoid double-flower attack, even under the condition of system accounting errors, through more than half committee negotiation and agreement, the influence caused by the previous accounting errors can be filled up by adding a new transaction, the CoV can greatly play a role of alliance, and the safety and reliability of the system are greatly improved.

And (4) self-privacy ore excavation, wherein the self-privacy ore excavation is earliest to appear in a bitcoin system, and as the public chain has the possibility of branching, the longest chain is selected as a legal chain by default for the selection of the branching chain. In short, an attacker who digs the mine from private does not publish immediately after digging a new block, so that other common knowledge nodes do not know the existence of the new block and continue to generate bookings on the original chain, and the attacker publishes the blocks together at the same time after stocking the blocks which are longer than the original chain. At this time, the chain branching moment of the attacker becomes the longest chain, all miners can choose to continue working on the self-private excavated chain, and the attack mode needs calculation power higher than the average level in bitcoin but does not need to exceed 50%. In the paper of Ittay Eyal, Israeli^[16]The model of (2) is calculated, even if no consensus node supports the mine excavation of an attacker in the whole network, one node only needs to occupy 30% of calculation power and can be profitable by starting the attack of private mine excavation. The selfish excavation has no harm to the correctness of the system, and the difficulty is greatly reduced compared with the double-flower attack. However, as an attack mode of earning block income and commission charge, the selfish mining mainly damages the benefits of other consensus nodes in the system, is extremely unfair to miners who have successfully mined ores on the original chain, and also aggravates energy waste, as shown in fig. 42.

Selfish mining behaves differently in different consensus algorithms^[71-72]In summary, selfish mining is an act of compromising consensus fairness in order to win higher gains in the consensus process without compromising system correctness. Since the accounting nodes of the CoV consensus are randomly designated and the housekeeper nodes need to be continuously rotated through election, the CoV does not have the situation of acquiring higher consensus gain through the "accumulation" blocks in the Nakamoto consensus. However, in the CoV consensus process, due to the addition of an excitation mechanism, the possibility of selfish excavation attack exists to a certain extent.

One approach to selfish mining that may exist in CoV will be discussed: since the manager on duty is specified by the R value of the previous legal block, although the generation method of the random number is specified, there is a method that can improve the possibility that the node becomes the manager on duty next, and particularly in the case where the number of managers is extremely small, this method can be called a "collision R" method.

And (3) collision R: according to the design of chapter three, random numbers are generated by combining the signatures of all committee signature sets Q { …,<C_time[i],C_sign[i]>… (i is more than or equal to 1 and less than or equal to K, Nc/2 is more than or equal to K and less than or equal to Nc-1), ascending order is carried out, the signature with the largest C _ time is taken as the input of the random number algorithm, the R value output by the algorithm points to the serial number of the next manager on duty, and the random number can be calculated and Final-Block can be generated only if the number K of the received committee signatures meets the condition that Nc/2 is more than or equal to K and less than or equal to Nc-1. If the caretaker on duty is a selfish mine-digging attacker, it is possible to choose half of the committee signatures in different combinations to obtain different R values, and this process is called "collision R". The set of R upon collision is

If it is

The attacker can become the next manager on duty by the number of the attacker, and the normal output block earns the accounting benefit. With very low probability, an attacker will likely occupy the role of an on-duty butler, the production zone, for a long timeBlock to gain more revenue.

Next, the process of "colliding with R" is modeled. The election process of the candidate election manager and the process of generating the random number R are mutually independent, so that probability analysis of whether the attacker elects successfully is eliminated, the assumption is that the current election-period owner set is B ═ B0, B1 and B2 … BNb-1}, the number of blocks to be generated is Bw +1, and the shift period of Bw +1 in the shift period is T ═ τ₀,τ₁,…,τ_i,…,τ_Bw}. Suppose that attacker a has elected the caretaker and reached its duty cycle, a ∈ B, the caretaker (attacker) number Bj, and during the current duty time interval τ_iThe set of all committee signatures received by the Pre-Block generated is Q ═ …,<C_time[k],C_sign[k]>,…}(1≤k≤Nc，C_time[k]≤C_time[k+1]). Consider the worst case scenario where an attacker Bj can collect signatures for all committees at a time, and Q is sorted in ascending order of C _ time. Suppose Q1(k) represents a subset of Q and contains only one element, i.e. Q1(k) ═ spherical<C_time[k],C_sign[k]>Q, where 0 < n ≦ m-k, representing a final image formed from Qm-k (k, m) ═ m <C_time[k],C_sign[k]>,…,<C_time[m],C_sign[m]>N elements are arbitrarily selected.

For Bj, the largest combination of "collisions R" is Qn (1, k) # Q1(k +1), Nc/2 ≦ n ≦ k ≦ Nc, and the results obtained for c/2(c being a positive integer) in this model are generally rounded downward unless otherwise specified. The best strategy of the 'R collision' attack for Bj is to select Q1(k +1) satisfying k ≧ Nc/2 in Q as the signature with the largest C _ time in the committee signature list which can be written into Final-Block, and then select n signature sets Qn (1, k) from Qk (1, k), wherein n ≧ Nc/2 is satisfied, i.e. the C _ times of the elements in Qn (1, k) are all smaller than Q1(k +1), so that the number of signatures in the finally composed committee signature list Qn (1, k) # Q1(k +1) which can be written into Final-Block is ≧ Nc/2+1, and the maximum value of C _ time can be specified as the element in Q1(k +1), and | Qn (1, k) # Q1(k +1) | n +1 ≧ Nc/2+ 1.

Thus, the caretaker (attacker) Bj on duty can specify the value of Q1(k +1) to get a result set of different "collisions R

Because k is more than or equal to Nc/2, k +1 is less than or equal to Nc, the value of Q1(k +1) has Nc/2 possible maximum, namely Bj can have Nc/2 chances to recalculate the random number R to expect to obtain a value of R ═ j, namely the size of the collided R set

So that the calculation of Bj can be derived from

Possibility of obtaining the desired value R ═ j

I.e. P (collision R succeeds).

Each time the random number R is recalculated, R ∈ {0,1,2, …, Nb-1}, the probability that R exactly equals j is 1/Nb,

whether each R in (1) is j is an independent event, set to Yk. Yk ═ 1 denotes R ≠ j, and Yk ═ 0 denotes R ≠ j.

{ Yk } is an independent identically distributed random variable sequence, Yk to B (1, p) obey a 0-1 distribution, e (Yk) is p, d (Yk) is pq, Yk to N (p, pq), q is (1-p). Setting:

additivity from a binomial distribution, the sequence and Xn-B (n, p), where Xn represents the set

The number of R-j exists, and according to the central limit theorem of binomial distribution, namely the central limit theorem of Schermofilance, the limit distribution of mutually independent random variables and is a standard normal distribution, namely, the following components exist:

when n is sufficiently large (in the normal approximation of binomial distribution, "n is sufficiently large" is generally regarded as n.gtoreq.50), the approximation is

X_nN (np, npq) type (4.16)

Applied to the probability problem of "collision R" success, set

The probability that the number of R ═ j is not greater than 1 is the probability of failure of "collision R", which means that the way that the caretaker (attacker) Bj on duty tries all possible "collision R" still cannot make the next caretaker number R equal to its own number j. If the attacker succeeds in R collision, namely the probability of completing one-time selfish excavation is lower than 0.01, the selfish excavation can be regarded as a small-probability event, and therefore the relationship between the housekeeper quantity Nb and the committee quantity Nc can be deduced through probability calculation.

Looking up the standard normal distribution table, Φ (2.33) ═ 0.99, so:

solution of the calculation equation (n)²+5.4289n)p²-7.4289np+1＝0

From equation (4.23), since n >0, it is deduced from the widal law:

TABLE 4.1 example Table of relationship between Committee number Nc and housekeeper number Nb

In summary, combining the curve characteristics of a quadratic equation with a single element, 0< P <1, and in the case of n, satisfying P ≦ x2 satisfies P (collision R success) < 0.01. According to the following steps:

it is known that after Nc is set, the probability that the minimum number of Nb can be obtained to satisfy the success of the attack by the attacker is less than 0.01. The analysis list shows the relationship of each parameter as Nc varies in size.

As can be seen from table 4.1, after the number Nc of committee nodes is determined, the optimal value of the number Nb of housekeeper nodes can be set, that is, the probability p of success of the selfish excavation attack can be reduced to the minimum value of Nb below 0.01. Accordingly, it is possible to follow:

(n²+5.4289n)p²-7.4289np+1≥0,n＝N_c,N _b1/p type (4.26)

The corresponding values of the committee number and the housekeeper number are obtained, the number of Nb can be rounded up to ten-hundred and the same value for convenient calculation, an example is given in the table 4.2, and under the condition that the committee number is known, the corresponding Nb when Nc is in a certain interval can be obtained through table lookup, so that when the committee number slightly changes, the housekeeper number value set by the system does not need to be frequently changed.

TABLE 4.2 corresponding example Table of Committee number Nc and housekeeper number Nb

Observe the numerical value of two tables, can obtain a law, the butler quantity only need set up 3 ~ 4 times that can make the attacker carry out the success rate of selfish excavation and be less than 0.01 for the committee quantity, consequently can draw a conclusion: the alliance chain system using the CoV consensus may be attacked by selfish mining, that is, an attacker continuously tries new random numbers to improve the probability of designating the next housekeeper on duty as the attacker under the premise of not damaging the correctness of the system, but as long as the number of the housekeepers is set to be large enough, unfairness caused by selfish mining can be avoided.

By establishing a three-dimensional model for the "collision R", the influence of the housekeeper quantity and the committee quantity on the safety can be quantitatively analyzed, and the following model is established in matlab, so that the three-dimensional model shown in FIG. 43 can be obtained.

The left graph in fig. 43 shows that the higher the committee number Nb is, the higher the probability of "collision R" failure is, and the lower the selfish excavation success rate is, the higher the safety is, when the committee number Nc is fixed. Analysis of the contour diagram shown on the right shows that the contour lines of the graph are linearly distributed, i.e., the size of P (failure in collision R) can be kept equal when the committee number Nc and the housekeeper number Nb are in a certain proportional relationship. When the Nb to Nc ratio is greater than a fixed value, it is guaranteed that P (collision R failure) is greater than a value, consistent with the previous guess for the Nb and Nc quantity constraints.

Projecting the contour map of the three-dimensional model map onto the xy plane, it can be seen that P (crash R failure) will reach a very high value when Nb/Nc is about 1000/300 in the left diagram. Further expanding the ratio of the x-axis to the y-axis, the effect on the P (collision R failure) distribution when Nb/Nc is about 3-4 times can be seen more clearly, as shown in fig. 44.

Further, using a plan view where z is 0.99 intersecting with the P (failure to collide R) surface view, as shown in fig. 45, the boundary line can be found as a straight line. After two enlargements, the graph at the upper right corner can find the intersection line to intersect the xz plane (1000,3640, 0.99). It is considered that P (crash R failure) is 0.99 or more when Nb/Nc is 3.64 or more.

Assuming that γ is Nb/Nc, the following model is built in matlab, and a three-dimensional model as shown in fig. 46 can be obtained.

It can be seen that P (collision R failure) always increases as the householder committee number ratio γ increases, regardless of the change in the committee number Nc. For further analysis, as shown in fig. 47, the contour line of the model map is projected on the xy plane, and a cross section with z equal to 0.99 is added to intersect with the model map, and a straight line formed at the intersection is at γ equal to 3.6. So far, the model fully verifies that when the housekeeper quantity/committee quantity is about 3-4 times and is more than or equal to 3.6, P (collision R failure) is more than or equal to 0.99, and selfish mining success is a small probability event, which represents that the system is safe to some extent, as shown in FIG. 47.

In addition, in an application system of the CoV algorithm, a new algorithm can be set to identify bad behavior of the housekeeper, and the malicious behavior of the housekeeper is punished by reducing the score, so that the yield breaking probability of malicious nodes is improved, and the robustness of the system is enhanced.

Sybil Attack, a Chinese translation name of Sybil Attack, published by Douceur et al^[24]The first time. Big (a)In a P2P network of a certain size, redundancy strategies are used to deal with the threat of malicious nodes in the system, for example, a blockchain system adopts blockchain redundancy backup in multiple peer nodes to ensure that blockchain data is not tamper-proof, but an attacker can occupy most nodes in an anonymous system by virtualizing multiple identities and weaken the redundancy backup strategy of the system.

For CoV consensus, if an attacker with multiple virtual machines controls most of the housekeeper and housekeeper candidate nodes, the system will be at great risk. But the witch attack only generates great threat to the unlicensed public link, and the witch attack cannot play the original role for the league link with the license admission mechanism.

The CoV is set aiming at the alliance chain scene, and in the system initialization and operation processes, all the added nodes can verify the node identities in the modes of identity verification and digital certificate distribution, so that the principle that one node in the alliance chain system is one ticket is ensured, and therefore Sybil attack is effectively avoided.

Consensus algorithm Performance analysis, according to Arthur et al in-process paper^[13]The study in the publication shows that, under comparison of several types of block chains based on PoW, various block-out speeds and transaction confirmation delay times are compared and shown in fig. 48, it can be seen that the game of the conventional public chain consensus on performance and safety greatly hinders the improvement of the performance of the conventional public chain consensus. Compared with the common chain consensus, the CoV can achieve the characteristic of transaction confirmation which cannot be tampered by only one block, and the performance improvement of the CoV is not limited by the safety; compared with the message complexity of O (N2) achieved by the famous PBFT consensus algorithm under the condition that the total number of nodes is N, the two-stage submission communication complexity of the CoV is only O (3Nc) and is only influenced by the number of committee nodes, and theoretically, better performance can be achieved.

In terms of energy consumption, CoV does not need to expend significant computing power, nor does it promote the appearance of dedicated mining circuits (ASICs). Thus unnecessary energy waste can be avoided using CoV consensus in the federation chain.

In addition, the CoV consensus supports the regular rotation of the consensus nodes, so that the problem of distributed single-point failure is greatly avoided, and the system can be well prevented from being controlled by an attack node for a long time. Meanwhile, the CoV is controlled by all alliance nodes, and in the establishment of a real block chain system, the appropriate audit layer is matched to enable the government and the regulatory agency to participate in the supervision properly. If there is illegal affair to be changed, only need to consult over half of committees to agree to issue special modification affair through government level, revise the existing error data. Therefore, the CoV not only can adapt to top-down supervision, but also can adapt to bottom-up correction of a block chain system, and has flexible supervision.

And analyzing and demonstrating the accuracy and safety of the CoV on the basis of the CoV consensus strategy and process design. On the basis of the demonstration of correctness, the chapter proves that the CoV can ensure the final consistency of the transaction and certain network partition tolerance according to the requirement of a distributed consistency theory CAP/BASE on distributed consensus, so that the transaction can be finally confirmed only by passing through one block; and by modeling a voting mechanism, the most important consensus node in the algorithm can realize the activity of 'winning or losing' through an incentive mechanism of CoV. Meanwhile, the chapter introduces common attack modes in three blockchains of double-blossom attack, selfish mining and Sybil attack, and analyzes the corresponding modes of the expression forms of the attack modes in CoV. The chapter proves that the system can resist 99% selfish mining attack under the condition that the number of housekeeper nodes is at least 3.6 times of the number of committee nodes. Finally, it is theoretically analyzed that CoV can achieve better performance and lower energy consumption than the public link in the time of transaction confirmation.

Simulation experiment and test, according to the problem description of consensus design, the design requirements of the consensus mechanism include manageability, high efficiency, low consumption, high fault tolerance, consensus, legality and terminability. Chapter iv herein has demonstrated the consensus, legitimacy, terminability, low consumption, supervisobility and partial fault tolerance of CoV in proof of correctness and security analysis of consensus algorithms. In this chapter, simulation testing is performed on CoV in three aspects of transaction confirmation experiments, transaction throughput, system fault tolerance and the like, and simulation is the only feasible alternative scheme which can capture the performance of a block chain under different parameter instances at present. To this end, the work herein also constructs a CoV blockchain simulator to evaluate the performance of CoV instances according to different parameters, thereby verifying the effectiveness and usability of the CoV consensus algorithm.

The experiment environment is software and hardware environment, the experiment is carried out in the operating system environment of 64-bit Ubuntu16.04 LTS, and the experiment is carried out in a PC (personal computer) (processor)

CoreTM i7-7700 CPU @360GHz x 8 and internal memory 15.6GB), and on the basis, an NS3 simulation platform (NS3.27 version) and development codes are installed, so that simulation and test of CoV consensus instances are realized, the feasibility of CoV is verified, the running condition of a CoV algorithm is researched through control variables, and time delay and throughput are calculated.

NS3 simulation platform, NS3(Network Simulator Version 3) is a discrete random event-driven Network Simulator. The simulation system has detailed network modules and routing protocols, is a real simulation of the actual application of engineering, and has a simulation result closer to the actual engineering due to the fact that the simulation system is purely programmed by C + + and matched with a complete bottom layer design. The NS3 inherits the latest network standard protocols and can be used for almost all current network simulations.

As shown in fig. 49, NS3 is comprised of a total of five network components: node, Application, Network Device, Channel and Topology generator [25 ]. The basic computer device at NS3 is abstracted to nodes Node, described by the NodeContainer class, and provides a variety of methods for managing computer devices. A Channel refers to a data stream transmitted over a medium. The Network Device refers to hardware and Network card drivers on the internet. The Application program type is used for describing Application programs running on the computer Node, and provides various methods for managing user-level Application programs in a simulation process, so that developers can customize and create new Application programs by using an object-oriented method. The simulator kernel of the NS3 mainly comprises two parts, one part is responsible for time scheduling, the other part is responsible for System core support, the time scheduling comprises default scheduling and real-time scheduling, and the support System mainly comprises an Attribute, a log System and a tracking System.

The NS3 has good maintainability, flexible architecture, perfect documentation, compliance with open source (GPL) protocol, is mainly used as a simulation tool in research, and is excellent in simulation speed and accuracy. The simulation steps of the NS3 script are generally as follows:

parameters used in the simulation are defined, which may be established by using command line classes to dynamically change parameters used in the simulation, such as the number of nodes, the transmission frequency of packets, packet size, routing protocols, and so forth.

A plurality of nodes are created by the Create method of the NodeContainer class, the connection between the nodes is set using the Link helper class, and a network card is installed on the nodes through NetDeviceContainer [26 ]. Then, an IP protocol stack is installed by using the Internet Stackhelper and an IP address is configured for each node.

After the communication network is established, it is necessary to install an application service for each node, and establish parameters such as a source node, a target node, and their transmission rates and delays.

And finally, setting simulation Stop time simulation through Simulator:: Stop ().

Experimental design, in order to test feasibility and effectiveness of the CoV algorithm, this section describes a summary of a process of deploying CoV on an NS3 simulation platform, and adds a simulation transaction generation module in the simulation, so that each node randomly generates a common transaction according to a certain adjustable probability to adjust the speed and density of transaction generation, thereby better testing throughput and delay of CoV and robustness of the system.

A CoV simulator is characterized in that a CoV block chain simulation system built on an NS3 simulation platform mainly comprises a global Ipv4address generation module, a P2P link topology networking module, a network message propagation module, a transaction generation module, a block generation module, a message creation module, a key management module and a CoV common identification module. The construction of the relevant part of the underlying network refers to the operation of the bit coin simulator constructed by Gervais [27] et al, as shown in FIG. 50.

Global Ipv4address generation module: using the Ipv4 addressdrillstom class implements a simple Ipv4address generator, calls the partial function implementation of the Ipv4AddressGenerator class in NS3, and calls the global address generator to ensure no duplicate address generation.

P2P link topology networking module: the links between nodes in the system are realized by directly creating point-to-point channels, and all other intermediate devices such as routers, switches and the like are removed. The characteristics of the point-to-point Channel can simulate the Delay and bandwidth of the link through setting of the NS3 simulator for two parameters of Delay and DataRate of the Channel type. The emulator is consistent with the underlying network settings of the bitcoin emulator created by Gervais [27] et al. To capture the actual delay in the network, the simulator uses Verizon's Global IP delay statistics message [30], assuming that the Pareto traffic distribution accounts for 20% of the average delay [31 ]. On the other hand, in order to establish a realistic bandwidth distribution in the network, the link bandwidth of the simulator in the class blockchaintopologyhaler is set to be randomly distributed according to the data on testmy.net [28] (upload bandwidth characteristics: min is 0.1Mbps, max is 100Mbps, interval is 0.1Mbps, download bandwidth characteristics: min is 0.1Mbps, max is 500Mbps, and interval is 0.5 Mbps).

The network message propagation module: since all nodes Node belong to peers in the P2P system and all blocks need to be received, a broadcast protocol is required. Miners in the bitcoin network can improve the robustness and the expandability of the network through the relay network, and the CoV simulator only considers the most basic broadcasting protocol to ensure the feasibility and the effectiveness of the protocol. APIs for message propagation are encapsulated in a blockchain _ network class.

A transaction generation module: the transaction generation module is realized in a CoVTransaction class, and identity authority transformation transactions, special voting transactions and common transactions (user-defined transactions) in the CoV are simulated by setting Data and MetaData MetaData of the transactions. The generation rate VGen of the common transactions can be adjusted through the probability PGen of the node generating the common transactions, the probability of generating the common transactions is improved, the transaction data can be sent to the consensus module at a high speed, the PGen is controllable, and the method is used for testing the confirmation delay of the consensus module for the transaction processing and the TPS of the whole system.

A block generation module: the generation of Block data, especially the generation process of data for Pre-Block and Pre-Header in CoV, is simulated by CoVHeader class, CoVBlock class and CoVBlockChain class.

A message creation module: all messages used by the CoV simulator are defined in the MessageManager class, and the creating functions of requests and responses are realized.

The key management module: implemented in the KeyManager class. The method for generating and managing the secret key and the public key and encrypting and decrypting is realized. The encryption algorithm of SHA256, RSA and elliptic hyperbolic secp256k1 required in the block chain uses a mbedTLS code base [29], is written by using a C programming language, has no external dependency, is a small ssl code base, and is convenient to transplant and compile.

CoV consensus module: the module is the key of a CoV simulator system and is responsible for transaction and block consensus confirmation, message and transaction processing, the configuration of data such as a complete block chain and a memory pool stored by each node is realized through a CoV class, and a network identity model in a CoV model is realized through an account class and an Account manager class. The key class of the CoV-class system is an execution component of a CoV algorithm, the performance of the execution component directly determines the test effect of indexes such as time delay, throughput and the like of the system, and the functional design of the CoV consensus execution module refers to the algorithm description in chapter three.

Experimental contents, according to the main research contents, the feasibility of the CoV consensus algorithm is simulated and verified in the chapter, and key performance indexes in application of various block chains such as time delay and throughput of the CoV are tested, so that the effectiveness and the advantages of the CoV algorithm are demonstrated.

TABLE 5.1 independent variables and their description

(1) Independent variable-simulation parameter

Table 5.1 gives the independent variables and their description in the test experiments. It should be noted that the size Txpbmax and the transaction content length Txsize of the maximum number of normal transactions of a block may determine an upper limit for the block size. In addition, the CoV simulator also simulates a scene in which real transactions occur, a probability P of generating a common transaction is set for each node, when the NS3 runs the CoV program, the CoV program is run for 0.1 second by default, the common transaction is sent to the outside to test throughput with the probability of P each time, and the rate of transaction generation can be calculated by VGen ═ Nall (1/0.1) × P.

(2) Dependent variable-Performance index

In the block chain system, two most important indexes for improving the performance are that firstly, the throughput of the transaction is improved, and secondly, the confirmation delay of the transaction is reduced.

Throughput: throughput is defined as the amount of data successfully transmitted per unit time (most of the transmission units are bit, byte, and packet) between nodes (devices, ports, virtual circuits, or other facilities) in the network. In the block chain system, throughput is an important index for measuring the concurrency capability of the system, and is mainly used for measuring the capability of processing transactions, requests and the like in a unit time of the system, and is expressed by throughput, and the unit is tps (Transaction Per Second). Transaction throughput in a block chain can be counted by counting the total number of transactions per unit time from issue to written to the block and confirming that tampering is not possible, as shown in equation (5.1), where δ t is some time interval in the system.

Time delay: the delay in the block chain is defined differently from the delay in the packet switched network, and the delay in the block chain mainly refers to transaction delay and is closely related to throughput. Latency in testing herein refers to the time interval from when a normal transaction (issued by a node in the system at some adjustable rate) is issued by a client to when it is acknowledged by a write blockchain. Delay index for measuring transmission performance of block chain system and operation of consensus algorithmThe lower the line time and the delay, the faster the transaction in the blockchain network is confirmed, the less time the user waits for the transaction to succeed, and the better the experience, meaning the faster the response speed of the blockchain system. The latency indicator in the blockchain can be counted by dividing the sum of the time differences from the issuance to the validation of a large number of transactions by the total number of transactions to obtain an average value of the transaction latency, as shown in equation (5.2) (5.3). Where n represents the counted number of transactions, Ttransfer is the transmission time from the transmission of a transaction from a node to the broadcast in the network, Tconsensus represents the execution time of the consensus algorithm, and Tcomfirm represents the acknowledgement time from the completion of the execution of the consensus algorithm to the broadcast of a Block containing a transaction to the network to obtain an acknowledgement of one Block, which means that more than half of the committees have received Final-Block containing the transaction. Delay can be modified according to whether Tcommirm is included _txEncapsulated Delay differentiated into transactions_packAnd acknowledgement Delay_comfirmDelay containing no Tcomfirm_packRepresenting the encapsulation delay from the generation of the transaction to the encapsulation into a block, Tc is the block time of the transaction; delay containing Tcomfirm_comfirmWhat represents the acknowledgement latency from the time the transaction is generated until it is acknowledged as untrustworthy, Tc, takes the next block time the transaction is in.

Delay_tx＝T_transfer+T_consensus+T_comfirmFormula (5.3)

For the purposes of the study herein, the following 3 experiments were designed herein. The default transaction size is consistent with the bitcoin and is 250 bytes, the influence of the change of the system throughput and the time delay when the proportion of the committee number and the housekeeper number is consistent under the change of different block numbers Ball, node numbers Nall, transaction occurrence numbers PGen and consensus waiting numbers Td and Tb is mainly researched, and the influence of the change of the proportion of the committee number and the housekeeper number on the consensus performance is also researched.

1) And (3) usability testing, wherein a set of standard independent variable parameters are set, the whole CoV process can be completely tested to run smoothly, and the whole block is identified between the nodes and continuously generated.

2) And throughput testing is carried out, the influence of the number Ball of generated blocks on throughput, the influence of the node scale Nall on throughput, the influence of the transaction generation speed VGen on throughput, the influence of the waiting time Td and the deadline time Tb on throughput and the influence of an arbitrary period on throughput are researched, and the optimal throughput parameters are analyzed.

3) And (4) time delay testing, wherein the influence of Ball, Nall, VGen, Td and Tb on the transaction confirmation time delay is researched, and the optimal time delay parameter is analyzed.

In the performance test experiment, a CoV simulator can modify the configuration of an underlying network such as link bandwidth, delay and the like in design, and because hardware resources (memory) are limited, the CoV simulator uses better configuration with high bandwidth and low delay in throughput test and delay test, and takes a small number of nodes for representative test in the selection of the number of the nodes so as to measure and calculate rough parameter ratio; in a feasibility test, the adaptability of the CoV node to a long-distance and wide-range point-to-point network is shown by using low-bandwidth and high-delay network transmission parameters which span five continents in a real network. Because the experiment is a simulation measuring and calculating experiment, the feasibility and the effectiveness of the algorithm can be better shown, but because the actual network parameters are complicated and changeable, the actual hardware resources are more superior than the simulation hardware resources, and the test of the algorithm performance is only referred.

Feasibility test, test mainly for completely testing the feasibility of the CoV flow, a set of basic parameters is set, some parameters of the bitcoin system are referred to, the transaction size is set to TxSize 250byte and the block size BlockSize 1MB, so the maximum number of transactions that a block can accommodate is Txpbmax 4000. The CoV simulator underlying network module sets a random distribution interval for the connection number and the uploading and downloading speed of each node participating in consensus, and is closer to the running condition of a real network. Taking the example that the number of committee nodes Nc is 5, the number of housekeeping nodes Nb is 10, and the total number of system nodes Nall is 20, the emulator assumes that there are no common nodes and that the committee nodes all share the identity of the housekeeping candidate, so the number of housekeeping candidate nodes is Nbc Nall-Nb is 10. In the feasibility test, the simulator randomly allocates a connection number of more than 5 and less than 15 to each node. A realistic bandwidth distribution is set for each point-to-point connection according to the area (ASIA _ PACIFIC, EUROPE, NORTH _ AMERICA, SOUTH _ AMERICA, JAPAN, AUSTRALIA, OTHER) to which each node belongs.

The test results are shown in fig. 51, which shows that the CoV simulator can continue to produce a smoother yield block under the low bandwidth and high latency network transmission parameters across five continents.

And (3) throughput testing, in order to better test throughput and time delay, the test of the CoV simulator runs under the bandwidth of 10Mbps, so that the running nodes all belong to an ASIA _ PACIFIC area, the application scenes of a alliance chain are better fitted, and 0.1s of delay is added to each link between the nodes. Assuming that a block does not exceed 0.5MB, 10s generate a block and a transaction 250Byte, in the CoV test, in order to improve the memory utilization rate, a block is defined not to exceed 2000 transactions, and each test sets a different common transaction occurrence rate, namely the generation rate of common transactions. Under the same test conditions (total of 50 blocks Ball, 20 blocks in an arbitrary period Bw), the node count is arranged to be Nc/Nb/Nall 5/10/20, the vote count is default to K10 corresponding to the housekeeper count, a certain waiting time is set for the housekeeper output block to collect enough transactions Td 10s, and the duty Tb 20 s. Observing each subgraph of fig. 52, it can be seen that, in the case of a small block height, the throughput ratio is low, and the predictable reason is that the system generates transactions gradually after initialization, and the transactions of the initial block are not saturated, so that the throughput change is large, and the throughput gradually stabilizes as the block height increases.

According to the formula (5.1), the throughput of the first n blocks in the 50 blocks is statistically analyzed, so that the throughput is delta_ttime-Block0.time, Sigma Transactions is the total number of Transactions that the first n blocks contain (only normal Transactions, no special votes)Transaction or identity rights change transaction). Measured out of

The values of (c) are shown in fig. 52.

As can be seen from comparison of the four subgraphs in fig. 52, throughput increases with the increase of transaction generation rate, and there is a large change when the total number of blocks is 20 and 40, the reason should be that a special block is generated at heights of 20 and 40, respectively, the special block does not contain normal transactions, and in the special block generation interval, there are accumulated many normal transactions generated at uniform speed between networks. Therefore, when the number of system transactions is not full, e.g. (a), (b), and (c), the system throughput is slightly affected after the special transaction, but gradually recovers to be smooth, and when the transaction occurrence rate is greater than the throughput (200tps) that can be accommodated by the 10s throughput block in the case of full number of system transactions, e.g. (d), the system throughput is about 150 tps.

If the throughput of each of the 50 blocks is statistically analyzed according to equation (5.1), let δ be _tTime-block n-1.time, Σ Transactions is the total number of Transactions that the nth block contains (only normal Transactions, no special voting Transactions or identity right change Transactions). Measured out of

The values of (c) are shown in fig. 52.

As can be seen from comparison of the four subgraphs in fig. 53, the throughput variation substantially coincides with the transaction generation rate, and the housekeeping generates one block every 10s, and since the upper limit of the number of block transactions is 2000, when the transaction generation rate exceeds 320tps, the system throughput is obviously limited (not exceeding 200 tps). Analyzing the special blocks with heights of 20 and 40, it can be seen that the throughput of the block at the special block is 0 (not including any ordinary transactions), and the throughput curve has a distinct peak at the first block after the special block, because the first manager in the next tenure can collect the number of transactions between two blocks, which is more than the number of transactions that can normally be collected and wait for only 10s, and the characteristic of the system throughput variation is in accordance with the theoretical analysis.

Assuming that the transaction generation rates are respectively 40, 80, 160, 320tps, the average throughputs of 25 blocks generated when the total number of nodes is measured to be 20 are respectively 39.83, 80.05, 113.13, 151.45. When the total number of the nodes is measured to be 40, the average throughputs of 25 blocks are respectively 39.80, 79.45, 118.51 and 145.06, and the change of the number of the nodes has little influence on the average throughputs. As shown in fig. 54, it can be seen that the impact of different node scales on throughput is mainly reflected in that the throughput change of each block changes more severely under the condition that the number of nodes is increased, the communication overhead of the nodes is increased, the number of transactions received by a manager on duty is affected during forwarding, and the number of transactions in a memory pool during block generation is large or small, which is a normal performance.

As shown in fig. 55, it can be seen that different latencies Td have an influence on throughput, and since transactions in the network are generated at a uniform speed, a waiter on duty needs to set a certain latency to collect enough transactions for encapsulation, so as to obtain a higher throughput. Since the duty time is 20s, the time setting of Td is too small, for example, 1s, which results in that the housekeeper has no time to collect enough transactions, and the transactions contained in the block are not too many, the throughput is low, while the time setting of Td is too large, for example, 15s, which results in that the consensus time is only 5s, if the consensus cannot be completed within the specified time, the block generation rate may be reduced by replacing the housekeeper on duty, and the throughput may be reduced.

In the delay test, the delay of the block chain transaction has a closer relationship with the throughput, and it can be seen from fig. 56 that the block-out speed of the CoV simulator operation shows a more stable trend along with the uniform transaction occurrence, which also shows that the CoV can quickly confirm the newly generated transaction in the network under the condition that the upper limit of the number of block transactions allows. As can be seen from the comparison of the left and right graphs in fig. 56, the influence of the network node size on the block output rate is not great.

According to the setting of the formula (5.2) to the transaction Delay, the experiment of the simulator can obtain two types of Delay, one is the average Delay of the transaction encapsulated into the block _packThe other is that the transaction is confirmed as noneMethod-tampered average Delay_comfirm. Let n be the total number of transactions generated from the creation block to the end of the operation of the CoV simulator, let Tp be the time of recording the transaction in the metadata of the transaction, if Tc is the generation time of the block where the transaction is located, calculate sigma (T)_c-T_p) Then the Delay can be obtained_pack(ii) a If Tc is the generation time of the next block of the block where the transaction is located (the transaction can be confirmed as not being tampered when the next block appears), then by calculating sigma (T)_c-T_p) Then the Delay can be obtained_comfirm. Under the same test conditions as in the previous section of FIG. 54, an average transaction latency statistical plot is derived.

The test results of FIG. 57 show the encapsulation Delay of transactions at different transaction generation rates and at different node sizes_packAnd acknowledgement Delay_comfirm. It can be seen from the figure that the encapsulation latency for a transaction averages 9.34s, while the acknowledgement latency for a transaction averages 21.46 s. It can be considered that Delay_packContaining the consensus time Tconsenssus of the transaction and the propagation time Ttrans, Delay in the network_comfirmThen in Delay_packAlso includes the transaction confirmation time Tcomfirm. Considering that a transaction needs to go through a block of acknowledgements to reach the final acknowledgement, Tcomfirm is equal to about 12.12s per block of out-of-block interval.

In the test condition, the time Td of waiting for collecting the transaction by the housekeeper block on duty is set to be 10s, the block output interval also floats around 10s, interval is approximately equal to Tcomfirm approximately equal to 10s, and the test result accords with the theoretical calculation. The time that the block travels through the network also includes the residence time in the attendant memory pool, Ttransfer ≦ Td, so that the CoV consensus time Tconsenssus can be estimated to be completed in about a few seconds. In addition, as can be seen from fig. 57, the transaction generation rate VGen and the node size Nall have relatively small influence on the encapsulation delay and the acknowledgement delay, and do not show a certain increase and decrease rule. Different node sizes Nall and notDelay under the influence of the same transaction generation rate VGen_packAnd Delay_comfirmBoth floating up and down around their average. The scalability of the CoV is explained to a certain extent.

FIG. 58 shows the effect of latency Td before the housekeeper performs the consensus step during the duty cycle. For the encapsulation latency, similar to the effect of Td on the throughput of fig. 55, as Td increases, the number of block-collectable transactions gradually increases, the throughput increases, and the latency decreases. However, when Td exceeds a certain value, the remaining time left for the caretaker to recognize during the duty cycle is gradually reduced, which is more likely to cause the caretaker on duty to replace, and increases the transaction encapsulation delay. For the acknowledgement delay, increasing Td decreases the block rate and affects the final acknowledgement time tcommirm of the transaction, and when Td is relatively low, decreasing Td decreases the number of transactions that can be collected by the block, so it is necessary to adjust Td to a suitable size, such as about 5s, to ensure maximum performance of throughput and delay.

It can be seen that the transaction acknowledgement time delay of the CoV can reach 12.74s under the condition that the parameter setting is reasonable, compared with the PoW and ByzCoin improved PBFT of bitcoin mentioned in the literature review^[18]Solida improved Byzantine consensus^[19]The performance of CoV is comparable enough to handle most applications in the existing federation chain scenario, as shown in fig. 59.

The simulation test of the CoV algorithm is realized, the NS3 simulation platform is used for simulating a real network transmission environment as much as possible, and the test result shows that CoV can normally run in the NS3 network environment and generate a created block, a common block and a special block. Meanwhile, an evaluation model is established for two most important performance parameters of the consensus algorithm, namely throughput and time delay. And testing the throughput and the time delay of the CoV simulator under different parameter environments according to the content of the evaluation model, and analyzing the influence of the block number, the node scale, the transaction generation rate and the consensus waiting time on the performance. Under the condition that 0.1s of time delay is added to a network link, the throughput of the measured CoV for different transaction generation rates is increased along with the increase of the transaction generation rate, and newly added transactions in the network can be processed smoothly. Under the existing test hardware condition, when the waiting time before the block is taken out is set to be 5 seconds, the block interval is about 5 seconds, the average time delay of the CoV transaction packaged into the block is 6.26 seconds, the time delay confirmed to be not falsifiable is 12.74 seconds, and compared with the existing consensus mechanism, the method has certain comparability and can also meet the application requirements of a real block chain system, especially a alliance chain.

Based on the research background and the research theoretical basis of introducing the block chain, the design of a consensus mechanism, which is a core algorithm in the block chain, is explored. On the basis of summarizing the research on the design of consensus algorithm by predecessors, a novel consensus algorithm-CoV facing to a alliance chain is provided, the correctness and the safety are proved, and the simulation is implemented through an NS3 platform. CoV is based on the idea of alliance committee voting certification, relies on credibility differences of alliance committee nodes and other nodes in an alliance chain, and designs four roles in a model: committee, caretaker candidate, general user. The algorithm introduces a manager role and a candidate role to realize the rotation of consensus nodes, and establishes a voting mechanism to ensure that the consensus result needs to pass the verification of most committees. The consensus process of separating the voting right and the execution right can realize decentralized management among the alliances in the alliance chain. Compared with the existing algorithm, the CoV has the following advantages:

1. in the aspect of compliance supervision, the alliance node is allowed to comprehensively manage generation and confirmation of transaction data, and compared with a public chain algorithm, the system has the controllable effect that data on a chain can be maintained and required data can be provided for an auditor only by more than half of committees.

2. In the aspect of transaction performance, the CoV can realize throughput processing according with the transaction generation rate, the transaction confirmation time delay can reach 12.74s, the method is superior to most existing consensus mechanisms, and the application requirements of a alliance chain are met.

3. In terms of resource consumption, the security of the system is ensured by the credibility of the alliance committee nodes by the CoV, the power energy consumption is only used for limiting the number of candidates in the manager bankruptcy model established in the text without the competitive competition of the Nakamoto consensus formula, and compared with PoW, the number of candidates is almost negligible.

4. In the aspect of fault-tolerant capability, the CoV allows less than half committee nodes to fail to work, allows not less than 1 housekeeper node to do harm, and establishes a safety model by utilizing the characteristics of a alliance chain, so that the safety of the CoV is guaranteed to the maximum extent.

In terms of consensus, the CoV only needs to achieve confirmation of more than half of the committees in the network to achieve block consensus, the consensus has final consistency, the final validity of the transaction can be confirmed only by waiting for one block, and each block has the final. The final decision of the system node is consistent with more than half of committee nodes, and the consistency of the system can be achieved. Compared with PoW, the transaction confirmation is faster, compared with PBFT, the election of the housekeeper node reduces the communication overhead, and the high efficiency of CoV can be embodied.

On the basis of the design of a consensus mechanism, further research and analysis are carried out on the correctness and the safety of the CoV, the final consistency and the limited partition tolerance of the CoV are proved, and the CoV applied to the permit chain can resist the common double blossom attack and Sybil attack in a block chain system in the aspect of safety. Further, modeling analysis is performed herein for the activity of the most important housekeeper role in consensus and the possibility of selfish mining. The result shows that under the setting of reasonable voting number and housekeeper income, the housekeeper node can be superior or inferior according to honesty and activity, and the honesty reliability of a housekeeper node team is kept; meanwhile, the CoV algorithm can be kept to resist the selfish excavation attack by 99 percent when the number of the housekeepers is kept to be more than 3.6 times of the number of the committees. Simulation implementations also further show that the throughput and latency of the consensus algorithm are affected by the transaction generation rate, node size, and CoV consensus switching parameters, but behave stable overall.

The novel consensus mechanism has certain theoretical contribution and practical significance for the research of the block chain technology and the distributed consistency theory which are currently in a research hotspot, provides a selection of multiple consensus schemes in the aspect of promoting the landing application of a alliance chain, and has certain application prospect. However, due to the time factor, the design herein still has some disadvantages, and future work may try to make further attempts from several aspects.

1. For the CoV algorithm proposed herein, the designed random number algorithm is an important factor for selfish mining, but the random number algorithm is one of important designs for avoiding the maverick of housekeeping union, and further improvement is needed to enhance the randomness and unpredictability thereof.

2. The CoV consensus mechanism has strong expandability and controllability, and the consensus protocol can be modified. After the proposal is approved by signatures of a plurality of committees, the proposal can be packaged into a block chain, and the update of the block chain protocol is easily completed. The following two points may be considered with respect to the direction of protocol improvement: the first point is that the voting right of the coalition members can be shared according to the share of the member share, so that the voting system can reflect the change of the speaking weight of each coalition member as much as possible and is closer to the application of the real world; the second point is that when the union chain system is realized, the judgment conditions of the committee nodes on the affairs and the blocks can be customized in a personalized mode, so that the block chain can intelligently reject certain affairs which are illegal in reality.

For the simulation program itself, the validity of the CoV is only verifiable and a simple analysis of throughput and latency is made. Link delay and bandwidth parameters conforming to a real communication environment are set on the NS3 simulation platform as much as possible to test the feasibility of the link delay and bandwidth parameters. Due to insufficient memory and limited test time of experimental equipment, the test on the throughput and the time delay is only analyzed under the condition that the link delay is 0.1 s. Future considerations may include implementing MPI simulation of NS3, simulating simulation tests with more nodes and block numbers, or implementing a blockchain system with CoV consensus as the core in the test bed, and further improvements.

The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.

Claims (8)

1. A consensus voting-based method, comprising the steps of:

s1, selecting a duty manager, wherein the duty manager judges whether the block to be generated is a special block, if so, collecting the vote transaction sent by the committee node to generate a pre-special block, and if not, collecting the transaction which is not confirmed from the memory pool to generate a pre-common block;

s2, the attendant sends the generated Pre-Block to all committee nodes and waits for the signatures of the committee, whether the number of signature verification of the committee nodes received by the attendant is more than half of the signature verification number is judged, if yes, the Block is valid and the next step is executed, if not, the verification is not passed, the Block is invalid, and the step S1 is returned;

s3, judging whether the effective block is overtime, if yes, the block is invalid and returning to the step S1, if no, the block is effective, and executing the next step;

s4, judging whether the effective block is a special block, if so, the effective block is a qualified special block, if not, the effective block is a qualified common block, the on-duty manager sorts the received committee signatures and perfects element information of the block head, issues the qualified special block or the qualified common block to the whole network and executes the step S1 to repeat a new on-duty cycle;

The consensus method further comprises the steps of:

s0, before the creation block is generated, the committee nodes become manager candidates through self recommendation, and select a first manager from the creation block and number the first manager;

the method for generating the created block in the step S0 includes the following steps:

s01, the initial committee nodes communicate with each other to confirm online, and the committee with the minimum public key Hash value is responsible for generating a created block;

s02, all committee nodes send the identity authority change affairs upgraded to the committee with the minimum public key Hash value;

s03, hope to hold concurrently and take charge of the committee node of the identity to send and apply for to all committee nodes at the same time, send the identity authority of the candidate person of the manager to change and apply for the message and attach the self-recommended signature, judge whether it is more than half of all committee nodes to receive the information that other committee nodes agree to signature feedback, if yes, this committee node produces a legal identity authority to change affair smoothly, send to the minimal committee of hash value of public key and issue to the network, the committee node in the whole network puts this affair into the memory pool and carries out the next step, if no, abandon the information that this committee node issues;

s04, all committees send votes to the committee with the minimum public key Hash value, all committee nodes extract candidate housekeeping information which is verified to pass from a memory pool, at least K candidate housekeeping account addresses are selected from the candidate housekeeping information, the candidate housekeeping account addresses are serialized into vote information and signed, and vote information is returned to the committee with the minimum public key Hash value;

S05, after the commission committee counts, integrating the affairs of' identity authority change affair upgraded to committee > < identity authority change affair upgraded to housekeeper candidate > < vote information of all committees > < new housekeeper list >, generating Pre-Block, sending to all committees, and issuing a created Block after signature confirmation of all the committees is obtained;

and S06, deleting the identity authority change transaction and vote transaction to be confirmed in the memory pool after all committees receive the creation block.

2. The consensus method of claim 1, wherein the method of generating the common blocks in steps S1-S4 comprises the steps of:

s111, generating transaction data by any node and attaching a signature, receiving the transaction data and judging whether the received transaction data is correct or not, if so, forwarding the transaction data, and if not, discarding the data;

s112, all housekeeper nodes monitor transaction data and put effective transaction data into a memory pool;

s113, let M be 1, R be getproviousblockrandomnum ();

s114, the on-duty manager takes out some transactions from the memory pool and encapsulates the transactions into Pre-Block, and after digital signature is carried out on the hash value of the Block header, the Pre-Block is sent to all committee nodes and the manager node;

S115, the committee node receives the Pre-Block to verify the Block data, if the Block is generated, the Block head Pre-Header + hash value connected with the local timestamp character string is signed and then fed back to the on-duty manager;

s116, the attendant judges whether the time T is_cutIf the feedback information is larger than the signatures and the timestamps of Nc/2 nodes, if so, sequencing the signatures and the timestamps in an ascending order according to the timestamps, serializing the corresponding signatures and the timestamps into character strings, attaching the character strings to a Pre-Header, generating a Ready-Header, calculating an R value, taking the maximum value of the timestamps as Block generation time, adding the R value and the Block generation time on the basis of the Ready-Header, generating a Final-Header, issuing a complete Final-Block to the whole network, directly jumping to execute the step S117, if not, verifying the result, making R +1, increasing M, and returning the Block to the step S114 if not;

s117, if the block generation time is more than T_cutIf the previous block is an invalid block, the process proceeds to step S114, where R is R +1, M is incremented and the process returns;

s118, after the valid block is generated, the housekeeper R sends the block to all the committee nodes and issues the block, and determines whether the number of the committee nodes receiving the block is greater than half of all the committee nodes from the state of the whole network, if so, the block enters a legal state, has final confirmatory property, executes the next step, if not, the block is invalid, let R be R +1, M be incremented and return to step S114;

And S119, after the nodes related to the whole network receive the effective block, deleting the transaction contained in the effective block from the memory pool, acquiring the random number R contained in the effective block, starting the next round of consensus, judging whether the next round of consensus generates a special block, if so, executing the generation step of the special block, and if not, returning to the step S114.

3. The consensus method of claim 2, wherein the method of generating the special blocks in steps S1-S4 comprises the steps of:

s121, all committees select and generate a sequence from the candidates of the incumbent caretaker and the housekeeper to form vote information and send the vote information to the on-duty caretaker;

s122, all the committees and the incumbent caretaker receive voting information of all other committees simultaneously and place the voting information into a memory pool;

s123, the attendant judges whether the number of the collected voting affairs exceeds half of the number of the committees, and if yes, the next step is executed; if not, continuously waiting until the time is out, replacing the on-duty housekeeper and executing S121;

s124, the on-duty manager takes out some things from the things pool and packages the things into Pre-Block, and sends the Pre-Block to all committee nodes and the manager node after digital signature is carried out on the hashed value of the Block header;

s125, the committee node receives the Pre-Block and verifies the Block data, and if the generation of the board Block is agreed, the Block head Pre-Header + hash value connected with the local timestamp character string is signed and then fed back to the on-duty manager;

S126, judging at the time T_cutWhether the signatures and the timestamps of the feedback information which are larger than Nc/2 nodes are received or not is judged, if yes, the signatures and the timestamps are sorted according to the ascending order of the timestamps, the corresponding signatures and the timestamps are serialized into character strings, the character strings are attached to Pre-Header to generate Ready-Header, after the R value is calculated, the maximum value of the timestamps is taken as Block generation time, the R value and the Block generation time are added on the basis of the Ready-Header to generate Final-Header, complete Final-Block is issued to the whole network, the step S127 is directly skipped to execute, if not, the verification is failed, R is made to be R +1, M is increased in number, and the Block returns to the step S124 if not;

s127, if the block generation time is more than T_cutIf the previous block is an invalid block, the process proceeds to step S124, where R is R +1, M is incremented and the process returns to step S;

s128, after the effective block is generated, the housekeeper R sends the block to all the committee nodes and issues the block, whether the number of the committee nodes receiving the block is larger than half of all the committee nodes is judged by the whole network state, if so, the block enters a legal state and has final confirmation, and the block is calculated, votes are ranked N before_bWhen the node is selected as the manager for the next job period, writing the information of the new manager as a special transaction into the block and executing the next step, if not, the block is invalid, making R equal to R +1, and M increase progressively and returning to the step S124;

And S129, after the butler in the current round finishes the generation of the last round of special blocks, deleting the related voting information in the memory pool, ending the current round and jumping to a common block generation method.

4. A consensus method as claimed in claim 3, wherein a cycle of appointments in said consensus method comprises the steps of:

s001, at the beginning of each duty cycle, creating a block R ═ 0, where R ═ getproviousblockrandomnum ();

s002, after the Bw round consensus is completed, generating Bw common effective blocks;

s003, in the last round of consensus of the duty cycle, the committee updates the scores in the candidate list of the housekeeper of the committee, votes for election and generates a special block which contains the information and the corresponding number of the new housekeeper;

and S004, circularly executing the steps S001-S004 after the end of the duty cycle.

5. The consensus method of claim 4, wherein each current value keeper in the generation of the normal block needs to perform a round of "Prepare-Ready-dispose- (Commirm)" two-stage submission to ensure the unique validity of the block.

6. The consensus method of claim 5 wherein each chunk is generated with a random number that points to the housekeeping number of the next chunk to ensure that the housekeeping generates chunks in turn in a random order.

7. The consensus method of claim 6, wherein the transactions in said consensus method are identity authority transformation transaction, voting transaction, and custom transaction, respectively.

8. The consensus method of claim 7, wherein the messages in said consensus method are signature messages of committee, messages sent to all committees after the housekeeping generates pre-blocks, block messages for housekeeping to generate final acknowledgements, highest block height finding messages, and block synchronization messages, respectively.

Images