WO2019232789A1 - Procédé de consensus à base de vote - Google Patents

Procédé de consensus à base de vote Download PDF

Info

Publication number
WO2019232789A1
WO2019232789A1 PCT/CN2018/090453 CN2018090453W WO2019232789A1 WO 2019232789 A1 WO2019232789 A1 WO 2019232789A1 CN 2018090453 W CN2018090453 W CN 2018090453W WO 2019232789 A1 WO2019232789 A1 WO 2019232789A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
consensus
steward
members
nodes
Prior art date
Application number
PCT/CN2018/090453
Other languages
English (en)
Chinese (zh)
Inventor
李挥
李科浇
黄建森
朱伏生
马军锋
伊鹏
侯韩旭
李恪聃
王贤桂
张昕淳
Original Assignee
北京大学深圳研究生院
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京大学深圳研究生院 filed Critical 北京大学深圳研究生院
Priority to CN201880004219.5A priority Critical patent/CN109964446B/zh
Priority to PCT/CN2018/090453 priority patent/WO2019232789A1/fr
Priority to US16/361,067 priority patent/US20190220768A1/en
Publication of WO2019232789A1 publication Critical patent/WO2019232789A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps

Definitions

  • the invention belongs to the field of Internet technology improvement, and particularly relates to a novel consensus mechanism method based on voting for an alliance chain.
  • Blockchain technology is based on the principle of cryptography and not based on credit. It is the basic technology for constructing the Bitcoin network and the encrypted transmission of transaction information [1] . It enables any agreed parties to directly generate transactions [34] without the involvement of third-party intermediaries.
  • the blockchain can realize the value exchange of the Internet, plus its own distributed, disintermediation, immutable, and concealment advantages, the blockchain can make up for
  • the lack of centralized management of traditional financial institutions has greatly reduced operating costs, improved stability, and reduced the risk of single points of failure.
  • Santander Bank of Spain released a report that if blockchain technology is used in the global banking system, it will save about 20 billion U.S. dollars a year by 2020, so many financial institutions have gradually joined the financial market application research of blockchain technology [4 ] .
  • ADPT Internet of Things
  • e-commerce OpenBazaar [61] , Skuchain [62] , Purse [63] ), Supply chain management (Vechain [64] ), notarization and anti-counterfeiting (Factom [65] , Blockai [66] ), file storage (MaidSafe [67] ), operating systems (Elastos [68] ), and other fields.
  • Blockchain technology's multi-point backup storage and non-tampering characteristics can solve many pain points and difficulties in finance, public welfare, supervision, counterfeiting, etc., resulting in the rapid spread of blockchain technology, and it has evolved to seek innovation opportunities and challenges for all walks of life. .
  • the blockchain is derived from a unique way of storing data such as Bitcoin and other cryptocurrencies.
  • a self-referencing block chain model can be used to store all historical data, transaction records, and other related information on the data storage structure.
  • the generated large amount of data is distributed and stored in the P2P network, and is encrypted into a series of data blocks using cryptography.
  • Each data block contains the key identification information of the previous data block in the chain structure.
  • the blocks are linked in chronological order to form a global distributed log record. If you want to tamper with certain data in a block, you need to recalculate the block and all the block information afterwards.
  • Bitcoin has introduced a consensus mechanism for blockchain technology, making the attack of tampering with data difficult to calculate in terms of computational difficulty.
  • Blockchain is a composite technology integrated with technologies such as distributed storage, cryptography, consensus mechanism, and peer-to-peer transmission. Its core breakthrough is to reach an autonomous consensus in the decentralized environment that maintains the interests of the group. .
  • the consensus mechanism is a mathematical algorithm that implements fault-tolerant communication between P2P nodes on the basis of distributed consistency in a blockchain system. Relying on cryptography and clever distributed algorithms, the blockchain can enable participants to reach consensus in a distributed system without the intervention of a third-party center.
  • blockchain can be divided into public chain, alliance chain and private chain.
  • Blockchain technology arises from public chains, but in practical applications, public chains have been subject to varying responses from countries due to their completely open and transparent nature, the untraceability of private information, and the uncontrolled nature of regulation.
  • the alliance chain is more suitable for achieving a "partially decentralized" alliance ecosystem between some existing commercial organizations, making the operations between alliances more efficient and fair. From the fact that major international financial giants have participated in the R3CEV blockchain project [58], it seems that financial institutions are more suitable to form financial consortia and build application scenarios of alliance chains. Therefore, the research on the special consensus mechanism of the alliance chain has not become negligible.
  • the consensus mechanism plays a key role in the application of blockchain and directly affects the security and performance of blockchain products. There is no good or bad consensus mechanism. Different consensus mechanisms have different products and application scenarios. Therefore, different consensus mechanisms have been proposed and studied since the birth of the blockchain. The essence of the consensus mechanism in the blockchain can be traced back to the distributed consensus algorithm that has been studied since the last century, but the blockchain consensus mechanism that combines the incentive mechanism has gradually become an emerging direction after 2008. Discussion and research, as shown in Figure 2.
  • PoW Proof of Work, proof of workload [1] .
  • the PoW consensus mechanism is the most widely used consensus mechanism in existing blockchains. As the veteran of the blockchain, the Nakamoto consensus, the design concept of proof of work (PoW) has become the classic idea of the blockchain consensus.
  • Bitcoin uses PoW based on a hash function. Its consensus node, the miner, needs to find a random value, so that when the random value is hashed with additional block parameters (for example, Merkle hash, previous block hash), the hash is hashed. The resulting value must be less than the current target value. When such a random number is found, the miner can encapsulate the block and forward it to the nodes connected to it in the peer-to-peer network.
  • additional block parameters for example, Merkle hash, previous block hash
  • PoW is the backbone of mining and Bitcoin security, as shown in Figure 3.
  • PoW is called the Nakamoto consensus.
  • Participants accept the longest proof of work (PoW) chain as the system's historical transaction data, and try to extend it to contribute blocks to the longest chain. Therefore, the historical transaction data of cryptocurrencies is also called distributed ledger or blockchain data.
  • PoW also has some disadvantages.
  • the most serious disadvantages are its limited throughput and long transaction confirmation time. For example, it is currently possible to add a block every ten minutes [7], and it is recommended to wait for the output of six subsequent blocks to ensure the data security of this block, which means that the transaction data of this block is about one hour verify the time.
  • the current block size of Bitcoin after Segregated Witness is activated is about 2MB, and each block can contain about 1500 transactions.
  • PoW has a "51% hash power attack" [8] . When the hash computing power of the attacker exceeds 51%, it may cause double payments and lose security.
  • PoS Proof of Stake, Proof of Stake [3] .
  • Quantum Mechanic proposed the PoS mechanism on the Bitcointalk forum.
  • PoS uses Proof-of-Stake instead of Proof-of-Work. This mechanism has been fully discussed and proved to be feasible.
  • the coin age concept discussed therein is considered to be another viable design in addition to the PoW design.
  • the coin age (the number of coin days) represents the time when a particular token was last traded on the network. The number of people who hold long-term and do not use money is increasing.
  • the number of coin days can be regarded as the representative of the node equity in the network, and the proof of equity is realized by the number of coin days destroyed by each transaction.
  • the corresponding number of coin days is destroyed, which means that the entire network can randomly select leaders based on the distribution of coins and fluctuations in coin age, and the coins in the hands of nodes that have not been elected leaders for a long time.
  • the number of days can be continuously accumulated to increase the probability of the next elected leader and increase the randomness and security of the system leader election. This method can replace most of the guarantees currently provided by the workload verification PoW, and the best block in PoS is measured by the total number of days of coin destruction, not entirely by the total workload.
  • PoS solves the two pain points of PoW waste of energy and computing power in one fell swoop. Theoretically, it can shorten the consensus delay and improve performance, but the cost is easier forking and more block confirmation is required to ensure security. Although in the subsequent development of PoS2.0 and PoS3.0, some security details were optimized, and in the process of evolution, in addition to different currencies similar to Diandian, black coins, etc., its security and Fault tolerance has not been rigorously demonstrated in mathematics.
  • DPoS Delegate Proof of Stake, certificate of share authorization [2] .
  • the Larimer team proposed a DPoS white paper in March 2014, the first of which was Bitshares [36] .
  • the Bitcoin system using PoW has become more and more concentrated due to the emergence of mining pools and ASIC mining machines. As a result, some public opinion has doubted that PoW has deviated from the "decentralization" original intention of "one CPU, one vote”. .
  • the Larimer team believes that the decentralization of PoS can rely on a certain number of representatives, not all shareholders, and all shareholders have voting rights.
  • the DPoS mechanism expects to return the accounting rights to those who hold digital currencies, and let everyone who holds BTS (Bitcoin Currency) vote on the nodes that are elected representatives in the entire system resources.
  • the 101 nodes that have obtained the most votes have obtained the right to encapsulate and calculate the blocks, and they are performed in a random and unpredictable order.
  • DPoS expects to solve the problem of concentrated PoW computing power, and distributes the power evenly to 101 CPUs, and each CPU has exactly the same rights as each other.
  • These representative nodes that can be accounted for and verified are selected by voting by the holders of the entire network.
  • DPoS is similar to the US parliamentary system, except that the timing of the election can occur at any time.
  • DPoS has been reduced from the entire network to a certain number of nodes, claiming that they can achieve second-level delays.
  • DPoS still relies on the operation of tokens, and the number of block confirmations required to achieve a certain level of security is high. 51% of the 100 blocks after the transaction is written into the block are produced before the transaction can be processed. Think safe on the main chain.
  • Ripple Consensus [4] . Ripple was born in Silicon Valley, USA, and was developed by @ripplelabs ⁇ ⁇ .
  • the Ripple consensus mechanism produced the world's first open clearing payment network, which can be used for payment, transfer, exchange and clearing of any currency, including RMB, USD, EUR, JPY and even Bitcoin.
  • the consensus of the Ripple consensus mechanism is mainly reached between the validating nodes.
  • the tracking node is mainly responsible for distributing transaction information and the account request of the user client.
  • the verification nodes are restricted by configuring a trusted whitelist. Permission to vote on transactions.
  • the verification node in the protocol is the node that has the authority to write new ledger instance data, and also contains all the functions of the tracking node.
  • the verification node and tracking node will automatically forward and verify the transaction, summarize the legitimate transactions into a transaction candidate set, and send it as a proposal to other verification nodes; received
  • the verification node of the proposal compares whether the transaction has been verified by itself and the nodes on the whitelist to decide whether to vote on this transaction. After multiple rounds of voting, 80% of the transactions confirmed by the whitelist nodes are officially written in the distributed The ledger becomes the Last Closed Ledger.
  • the efficiency brought about by the public identity of the node can make the transaction reach the second-level confirmation, which also determines that the consensus algorithm is only applicable to application scenarios with permission permission, and its security can tolerate 20% of the entire network. Node has Byzantine error.
  • PBFT Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance [6] .
  • This algorithm has been proposed by Castro as early as 1999, which solves the problem that the original Byzantine fault tolerance algorithm is not efficient. It reduces the complexity of the algorithm from exponential to polynomial, making the Byzantine fault-tolerant algorithm feasible in practical system applications. It belongs to the state machine Byzantine protocol, and is one of the consensus algorithms implemented and recommended by IBM HyperLedger. The fabric project in HyperLedger also uses the PBFT-based consensus protocol to implement the state consistency of code execution results and introduces code execution result signatures for verification. . In the PBFT protocol, all nodes jointly maintain a state and take consistent actions, and implement the consistency protocol, checkpoint protocol, and view replacement protocol.
  • the consistency protocol distinguishes different states and is configured as a view.
  • the server in the view is composed of a master node and other slave nodes. There is only one master node.
  • the master node broadcasts the consistency request and finally summarizes all the responses. If it receives more than a certain number of responses, it proves that The node is already in the committed state, and the response is the final result of the consistency operation. If the master node fails to work due to the downtime, the slave node broadcasts a message to drive all nodes into the view change state. After the view replacement of all nodes is agreed, the new master node will open a new view state.
  • PBFT can reach the consensus consensus delay in seconds, which basically meets the requirements of commercial real-time processing. It can achieve the characteristics of detaching tokens while improving throughput. Its fault tolerance is tolerated by no more than 1/3 of malicious node attacks. Generally, PBFT is used in private chain and alliance chain scenarios that require strong consistency.
  • dBFT delegated BFT, authorizing Byzantine fault tolerance [7] .
  • the accounting node is an important node in the consensus process. It is responsible for collecting and serializing transaction messages in the network and recording them into the distributed ledger maintained by the entire network. Ordinary nodes do not participate in the consensus process and are only responsible for sending and forwarding transaction messages.
  • the dBFT is an improvement based on the PBFT.
  • the response mode of its C / S architecture is modified to a P2P mode suitable for peer-to-peer networks and nodes can dynamically join and exit.
  • the system works in a time-synchronized state. Each round Consensus generates a block within a certain time interval, and the generation of each block may experience different views; in one view, one node acts as the speaker (leader) and the other nodes are members (followers). A certain number of members' block authentication support can reach a consensus on a new block.
  • dBFT is applicable to the alliance chain and private chain. The digital certificate is used to solve the problem of authentication of the identity of consensus nodes. The dBFT white paper does not demonstrate performance level improvements, but it shows that no more than 1/3 of malicious node attacks can be tolerated in terms of fault tolerance.
  • Paxos [9,50-52] is a consensus algorithm based on message passing and highly fault-tolerant proposed by Leslie Lamport in 1990. Paxos divides system nodes into three virtual roles: Proposer, Acceptor, and Learner. In actual operation, a node can perform multiple functions. Paxos behaves as a three-phase protocol: the Proposer sends a Prepare request to the Acceptor, and after receiving half of the Acceptor's Response, the learner of each node is notified to achieve final consistency, otherwise the three-phase process is repeated for a new round of consistency process. Paxos is essentially a consensus mechanism based on leader election. Leader nodes have absolute authority and allow strong supervisory nodes to participate.
  • Paxos Its high performance, low resource consumption, and the correctness and reliability of the algorithm have been rigorously demonstrated. It has a very high status in traditional distributed consensus algorithms and is widely used.
  • the design of Paxos only considers agreeing on a change in value. Because the Paxos protocol does not allow malicious nodes in the system to be maliciously attacked, it does not have fault tolerance. As long as the n / 2 + 1 nodes are not down, they can provide consistent services. .
  • the design of Paxos does not consider the application in the blockchain, but mainly considers the application in distributed storage systems. All nodes generally have wired access mechanisms. Therefore, as a highly robust consistency protocol, Paxos can be transformed and applied in In a private chain scenario.
  • Raft [10] is also a traditional distributed consensus algorithm, which is an improved Paxos. Diego Ongaro, a doctoral student at Stanford University, has made research on the Paxos protocol his own PhD project. In the fall of 2014, he formally published his doctoral thesis CONSENSUS: BRIDGING THEORY AND PRACTICE, and presented an implementation algorithm for a distributed consensus protocol that simplifies the Paxos protocol, which is Raft.
  • a node can play one of three roles: Leader, Follower, and Candidate.
  • the consensus process is implemented in two stages. The first stage is the election process, and any node can act as Candidate.
  • Bitcoin-NG Bitcoin Next Generation
  • Bitcoin-NG is a Byzantine fault-tolerant blockchain protocol, has certain robustness, and has the same trust and security model as Bitcoin .
  • Bitcoin-NG's delay is limited only by the network propagation delay, and its bandwidth is limited only by the processing capabilities of individual nodes.
  • Bitcoin-NG breaks down Bitcoin's blockchain operations into two planes: leader election and transaction serialization. It divides time into epochs, and each epoch has a leader.
  • leader elections are conducted randomly and rarely. Once a leader is selected, it has the right to serialize transactions unilaterally until a new leader is selected, marking the end of the former's epoch.
  • the key idea of Bitcoin-NG is to separate transactions from leader election. If a miner mines a (critical) block in the PoW chain, he is selected as the leader, and then this miner / leader can be responsible for encapsulating small batch transactions-(microlock) transactions until a new leader appears. Similar to PoW chain, because (critical) blocks are harder to mine, the possibility of Bitcoin-NG fork is equivalent to PoW chain. It can be considered that each leader of Bitcoin-NG is a single-member committee. Since individual leaders cannot be trusted, any transactions they approve must still be buried in the Nakamoto PoW chain. Therefore, although Bitcoin-NG can improve the robustness and scalability of the consensus and avoid the problem of selfish mining, it will not improve the transaction confirmation time.
  • PeerCensus introduced the PBFT and transaction consensus committee based on the Bitcoin system. The committee is responsible for reconfiguring itself using the Byzantine consensus. Although it did not specify how to reconfigure, PeerCensus's proposal shows that the Byzantine consensus can achieve rapid transaction confirmation of the blockchain system.
  • ByzCoin uses multi-signature to improve the scalability of PBFT, and dynamically forms a consensus group that can represent the hash power ratio of recently successful block miners, retaining the open membership of Bitcoin.
  • ByzCoin uses a communication tree to optimize transaction commitment and verification under normal operation, while ensuring safety and activity under Byzantine faults, and f nodes with an optimal tolerance of 3f + 2 are allowed to exist.
  • ByzCoin generates collectively signed transaction blocks within one minute of transaction submission to mitigate double spending and selfish mining attacks.
  • the tree-structured communication further reduces the consensus delay time to less than 30 seconds.
  • Blockchain application scenario From the current status of the consensus mechanism research, there is currently no “universal” consensus mechanism, and each consensus mechanism has a corresponding application scenario. Some are for fully decentralized public chains, or partially decentralized alliance chains, or single-center private chains; some are for licensed chains, or for non-licensed chains.
  • the DAO hacking incident shows [40] that complete decentralization is not feasible.
  • the real world still needs some centralized way to restrict and control the entire system, and the traditional single-center architecture has been criticized for a long time. . Therefore, the characteristics of "partial centralization" or “multi-centralization” advocated by the alliance chain highlight its application value in real business scenarios, and the research on the consensus mechanism in the alliance chain scenario is more worthy of study.
  • Blockchain technology copies multiple distributed ledgers to each node in the network, and cooperates with the corresponding consensus mechanism to achieve the non-tamperable modification of the ledger data. While improving the security and reliability of the data, it also It has caused a large number of redundant copies of data and occupied a large amount of storage space, especially in the public chain network. However, if it is for a permission chain such as the alliance chain network, the data can be backed up in an 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 security and fairness of data management and control, the waste of a large amount of hard disk resources caused by data redundancy is greatly reduced.
  • the problem of block data confirmation time There is a problem of transaction transaction confirmation delay in the blockchain system, that is, the problem of long data confirmation time. Taking Bitcoin as an example, the block generation interval takes 10 minutes. In the case of 6 confirmations, the transaction confirmation time is extended by 1 hour. Although it has been greatly improved for cross-border remittances in 2-3 days, it is still far from ideal. Consensus mechanisms that have been proposed in the subsequent years have also been continuously researched to reduce the goal of data confirmation delay.
  • Throughput is a very important performance evaluation criterion for the blockchain consensus mechanism. Take Bitcoin before accepting isolation verification as an example. Each transaction is about 250 Bytes and the block size is limited to 1 MB. According to the average speed of generating a block every 10 minutes, the blockchain can only process up to 6.67 transactions per second ( About 7TPS (transactions per second), for real business applications, such low-frequency transaction confirmation speed will become the bottleneck of its business applications, which is likely to cause network congestion problems.
  • TPS transactions per second
  • testmy.net Http://testmy.net/country .
  • Blockai Launches "'Netscape for Bitcoin' With Blockchain Browser,” https://www.coindesk.com/blockai-launches-netscape-for-bitcoin-with-blockchain-browser/, 2015.
  • the object of the present invention is to provide a voting-based consensus method, which aims to solve the above technical problems.
  • a voting-based consensus method includes the following steps:
  • the watchkeeper is selected, and the watchkeeper judges whether the upcoming block is a special block. If so, the ballot transaction sent by the member node is collected to generate a pre-special block. If not, the un-confirmed block is collected from the memory pool. Transactions generate pre-ordinary blocks;
  • the steward on duty sends the generated Pre-Block to all member nodes and waits for the members' signatures, and judges whether the number of member nodes received by the duty steward verifies that the number of signatures is greater than half of the members ’signatures. If not, the verification fails, the block is invalid, and returns to step S1;
  • step S3. Determine whether the valid block has timed out. If yes, the block is invalid and return to step S1; if not, the valid block executes the next step;
  • the member nodes Before the genesis block is generated, the member nodes become the steward candidates through self-recommendation and select the first batch of stewards in the genesis block and number them.
  • a further technical solution of the present invention is that the method for generating ordinary blocks in steps S1-S4 includes the following steps:
  • Any node generates transaction data and attaches a signature, and simultaneously receives the transaction data and determines whether the received transaction data is correct. If the transaction data is correct, the transaction data is forwarded, and if it is incorrect, the data is discarded;
  • the steward on duty takes some transactions from the memory pool and encapsulates them into a Pre-Block. After digitally signing the hash value of the block header, the Pre-Block is sent to all members and stewards;
  • the member node receives the Pre-Block to verify the block data, and if it agrees to generate the block, it signs the hash value of the block header Pre-Header + local timestamp string and feeds it back to the steward on duty;
  • the steward R sends the block to all member nodes and publishes the block.
  • step S119 After the relevant nodes on the entire network receive the valid block, delete the transactions contained in the valid block from the memory pool, obtain the random number R contained in the valid block, start the next round of consensus, and determine whether the next round of consensus is generated.
  • the special block if yes, executes the step of generating the special block, and if not, returns to step S114.
  • a further technical solution of the present invention is that the method for generating special blocks in steps S1-S4 includes the following steps:
  • the steward on duty determines whether the number of voting affairs collected exceeds half of the number of members, and if yes, executes the next step; if not, continues to wait until the timeout expires and replaces the steward on duty and executes S121;
  • the steward on duty is engaged in taking things out of the pool and packaging them into Pre-Blocks, and digitally signing the hash value of the block header and sending it to all committee members and steward nodes;
  • the member node receives the Pre-Block to verify and verify the block data. If it agrees to generate a block, it signs the hash value of the block header Pre-Header + local time stamp string and feeds it back to the steward on duty;
  • the steward R sends the block to all the member nodes and publishes the block, and receives the member node's feedback signature.
  • the state of the entire network determines whether the number of member nodes receiving the block is greater than half of all the member nodes If so, the block enters a legal state with final confirmation.
  • the node with the top N b votes will be elected as the steward hired in the next duty cycle, and the information of the new steward will be written as a special transaction.
  • step S0 includes the following steps:
  • the initial member nodes communicate with each other to confirm that they are online.
  • the member with the smallest public key hash value is responsible for generating the genesis block.
  • the member node wishing to concurrently serve as a steward sends an application to all the members, sends a request for a change in the identity and authority of the steward candidate and attaches a self-referred signature, and judges whether the information received from other members of the node agrees to sign the feedback more than half of all members If yes, the member node successfully generates a legal identity permission change transaction, sends it to the member with the smallest public key hash value, and publishes it to the network.
  • the member nodes in the entire network place this transaction into the memory pool and execute the following One step, if not, discard the information posted by the member node;
  • All members send votes to the member with the smallest public key hash value.
  • All member nodes extract verified candidate housekeeper information from the memory pool, select at least K candidate housekeeper account addresses, serialize into ballot information and sign , Return the ballot message to the member with the smallest public key hash value;
  • the committee updates the scores in its steward candidate list and conducts voting to generate a special block containing the information of the new steward and the corresponding number;
  • Steps S001-S004 are executed cyclically after the end of the duty cycle.
  • a further technical solution of the present invention is that each duty steward in the ordinary block generation needs to perform a two-phase commit of "Prepare-Ready-Propose- (Comfirm)" to ensure the unique legitimacy of the block.
  • a further technical solution of the present invention is that the generation of each block corresponds to a random number, and the random number points to the steward number of the next encapsulation block, so as to ensure that the steward generates the blocks in a random order in turn.
  • a further technical solution of the present invention is that the transactions in the consensus method are respectively an identity permission conversion transaction, a voting transaction, and a custom transaction.
  • the messages in the consensus method are the member's signature message
  • the steward generates a pre-block message to all members
  • the steward generates the final confirmed block message
  • the highest block height message is obtained.
  • block synchronization messages are the messages in the consensus method.
  • the beneficial effect of the present invention is that in terms of compliance supervision, the alliance node is allowed to fully control the generation and confirmation of transaction data.
  • the controllability of the system is reflected in the fact that only half of the members need to agree to maintain the data on the chain And provide the required data to the auditors; in terms of transaction performance, CoV can achieve throughput processing that is consistent with the transaction generation rate, and the transaction confirmation delay can reach 12.74s, which is better than most existing consensus mechanisms and is consistent with the alliance chain.
  • Figure 1 is a schematic diagram of traditional payment vs blockchain payment.
  • Figure 2 is the development timeline of the consensus mechanism.
  • FIG. 3 is a schematic diagram of the mining mechanism of Satoshi Nakamoto.
  • Figure 4 is a schematic diagram of public and private key encryption and decryption.
  • FIG. 5 is a schematic diagram of an elliptic curve encryption algorithm.
  • Figure 6 is a schematic diagram of Bitcoin's asymmetric encryption mechanism.
  • FIG. 7 is a schematic diagram of a signature combined with asymmetric encryption.
  • FIG. 8 is a schematic diagram of a distributed accounting network VS a centralized accounting network.
  • Figure 9 is a schematic diagram of the blockchain technology architecture.
  • Figure 10 is a schematic diagram of the Bitcoin block structure.
  • FIG. 11 is a schematic diagram of a public chain vs an alliance chain vs a private chain.
  • FIG. 12 is a schematic diagram of a traditional clearing book.
  • Figure 13 is a schematic diagram of a distributed ledger.
  • FIG. 14 is a schematic diagram of a consensus design for separating voting rights and bookkeeping rights.
  • Figure 15 is a schematic diagram of the evaluation criteria of the consensus mechanism.
  • Figure 16 is a schematic diagram of the design goals of the consensus mechanism.
  • FIG. 17 is a schematic diagram of a CoV network model.
  • Figure 18 is a role transition diagram of the CoV consensus model.
  • Figure 19 is a schematic diagram of the CoV duty cycle.
  • FIG. 20 is a schematic diagram of a rotation process of a housekeeper.
  • Figure 21 is a schematic representation of the ideas of two Consensus of Vote.
  • Fig. 22 is a schematic diagram of a duty cycle.
  • FIG. 23 is a flowchart of the duty cycle operation.
  • FIG. 24 is a flowchart of ordinary block generation.
  • FIG. 25 is a flowchart of generating a special block.
  • Fig. 26 is a flow chart of the genesis block generation from the perspective of acting members.
  • Figure 27 is a schematic diagram of block generation steps 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.
  • Figure 30 is a CoV consensus flowchart.
  • Figure 31 is a housekeeper's perspective--general block and special block generation diagram.
  • Figure 32 is a member's perspective--general block and special block generation diagram.
  • Figure 33 is an example of a CoV algorithm.
  • Figure 34 is an example of the genesis block generation.
  • Figure 35 is a schematic diagram of the first duty cycle ⁇ B0: a, B1: b, B2: c ⁇ of the CoV algorithm example.
  • Figure 36 is a schematic diagram of the second duty cycle ⁇ B0: c, B1: d, B2: e ⁇ of the CoV algorithm example.
  • FIG. 37 is a hypothetical CoV bifurcation diagram 1.
  • FIG. 38 is a schematic diagram of the chain non-forking generated by the CoV consensus.
  • Figure 39 is a schematic diagram of an example where the alliance chain is not forked.
  • Figure 40 is a distribution diagram of P1 and P2.
  • the optimal K value can be obtained at the junction point.
  • FIG. 41 is a comparison diagram of different probability of getting votes.
  • Figure 42 is a schematic diagram of Bitcoin's selfish mining model.
  • FIG. 43 is a three-dimensional model diagram of the collision R failure probability.
  • Figure 44 is a contour projection of the "collision R" failure probability map.
  • FIG. 45 is a schematic diagram of a boundary where the “collision R” failure probability is> 0.99.
  • FIG. 46 is a graph showing the change of the collision R failure probability with ⁇ .
  • Figure 47 is a graphical representation of the change in collision R failure probability> 0.99 with ⁇ .
  • FIG. 48 is a schematic diagram of a game based on the performance and security of the PoW consensus block chain.
  • Figure 49 is a schematic diagram of the NS3Simulator architecture.
  • Figure 50 is a structural diagram of a CoV blockchain simulation system.
  • Figure 51 is a schematic diagram of the feasibility verification of CoV.
  • Figure 54 is a schematic diagram of the impact of different node sizes on throughput.
  • Figure 55 is a schematic diagram of the effect of different latency on throughput.
  • FIG. 56 is a schematic diagram of a generated block rate.
  • Figure 57 is a comparison diagram of the delays of different node sizes at four transaction generation rates.
  • FIG. 58 is a diagram illustrating the effect of different T d on the delay.
  • FIG. 59 is a comparison diagram of delays of different consensuses.
  • Blockchain is built on traditional computer technology. It integrates P2P, distributed storage, and cryptography technologies that have been studied decades ago. The success of the Bitcoin project has provided a feasible research direction for the integrated development of these technologies, and has attracted widespread attention and research on the blockchain, as shown in Figure 4.
  • Asymmetric encryption and digital signature Public key and private key: Encryption algorithms are generally divided into symmetric encryption and asymmetric encryption.
  • the encryption algorithms mainly used in blockchains are asymmetric encryption algorithms.
  • Asymmetric encryption usually uses different passwords in encryption and decryption, which are called public and private keys.
  • the encryption and decryption passwords for symmetric encryption are the same. This requires the password to be transmitted to the decryption party, and the key is added to a certain extent. Risk of leakage.
  • the asymmetric key used by the blockchain is encrypted with one key (public or private key). The information must be unlocked by another symmetric key. Therefore, its public key can be disclosed to others as an address account.
  • the private key is kept secret, and an attacker cannot deduce the private key from the public key. As shown in Figure 3.
  • asymmetric encryption algorithms include RSA, Elgamal, D-H, ECC (Elliptic Curve Encryption Algorithm), etc.
  • the encryption verification mechanisms in blockchain systems are based on asymmetric encryption algorithms.
  • the size of the Bitcoin private key space is 2256, which almost exceeds the number of all atoms in the universe.
  • Elliptic curve encryption algorithm is an asymmetric encryption method (also called public key encryption method) based on the discrete logarithm problem. It uses a point operation on the elliptic curve to implement the encryption algorithm. In order for the elliptic curve calculation to be applicable to encryption, it must be discretized (the horizontal and vertical coordinates of each point on the curve are integers and the number of points is limited), because the calculation of decimals will greatly reduce the calculation speed and rounding will affect 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, find x. For the p and I that meet the conditions, this type of discrete problem has no polynomial difficulty solution.
  • Bitcoin uses the elliptic curve defined by the secp256k1 standard, which is defined as the following function:
  • Equation (2.1) shows that the curve is defined in a finite field of a prime order p, so it is difficult to draw a scatter plot in two dimensions.
  • the mathematical principle is similar to the curve in the real number range, and a series of scattered points on an elliptic curve in the finite field of a small prime order (such as 17) can help understand its curve image.
  • a series of scattered points on an elliptic curve in the finite field of a small prime order (such as 17) can help understand its curve image.
  • the addition of any two points between the 17 points (using elliptic curve addition) or a multiple of any one point will result in the other of the 17 points.
  • the actual p may be a large prime number, forming a series of more complex scattered points on the secp256k1 elliptic curve, and the number of points is p.
  • the process of generating a public-private key pair starts with a randomly generated 256-bit private key k and multiplies it with a defined generation point G on the elliptic curve to obtain another point on the elliptic curve to obtain the public key K.
  • the operation of obtaining the public key K from the private key k is irreversible, so the Bitcoin address (derivation of the public key) can be freely disclosed without worrying about leaking the private key k.
  • Hash function Also called a hash algorithm, a hash function is a function that maps a message of any length to a fixed-length hash value, and the hash value (hash value) can be used as an authentication identifier. Because the address space of the hash value is extremely large, it is extremely difficult to perform reverse calculation (violent cracking). In digital signature schemes, the general method of directly signing all messages is not adopted. Instead, a hash function is used for messages that need to be signed to generate a fixed-length message digest. Finally, the message digest is signed. A signed message of a certain length is obtained, as shown in FIG. 7, which is more convenient and secure in terms of code processing. Typical hash algorithms are MD5, SHA1 / SHA2, and SM3. The hash algorithm used by Bitcoin is SHA-256.
  • SHA secure hash algorithm
  • NIST American Institute of Standards and Technology
  • FIPS 180 Federal Information Processing Standard
  • Hash function attack methods include birthday attack, rainbow table attack and differential attack.
  • the birthday attack can be used to attack any type of hash function, because it only depends on the length of the hash value, and does not take advantage of any algebraic weak properties of the hash function structure. Therefore, is the length of the hash value sufficient for the security of the hash function? The impact is extremely important.
  • SHA-1 generates a 160-bit hash value. In 2007, Google researchers found a pair of collisions with this function. NIST immediately announced that it would abandon SHA-1.
  • SHA-256 generates a 256-bit hash value.
  • its iterative algorithm structure makes collision complexity increase sharply with the number of algorithm rounds, which can effectively resist the use of the inherent properties of the hash function.
  • Digital signature and digital certificate Both digital signature and encryption use public and private key technology, but the purpose is different. The purpose of digital signature is to ensure the integrity and authenticity of the information. If server A sends a message to server B, in order to prove to B that only A can send this message, A can use the private key to encrypt message M into a signature C. After B receives message M and signature S, You can verify the integrity and authenticity of message M by decrypting S with A's public key and comparing whether the decrypted message is the same as the sent message M. The process is as follows:
  • A's signature can be verified by the method in step b).
  • Distributed ledger technology the technical basis of distributed ledger technology is distributed storage. Compared with traditional distributed storage, distributed ledger technology is implemented between different peer nodes in a P2P network. Nodes in different places maintain a complete account record, so that transaction summary accounting is no longer handed over to a traditional centralized structure, and there is no need for a centralized trust institution to guarantee the authenticity and integrity of the accounts.
  • all peer nodes can participate in monitoring the legitimacy of transaction transactions, and can also jointly testify for the legal data in the accounts; and unlike the traditional accounting scheme, no node can record the accounts separately as a centralized node, and It is the joint accounting of all nodes and keeping the copy data consistent, thereby avoiding the possibility of a single accounting node being maliciously controlled to record false accounts.
  • the redundant strategy of distributed ledger technology can effectively ensure the accounts The security of the data is shown in Figure 8.
  • the consensus mechanism provides a cooperative way for all bookkeeping nodes to reach a consensus among them to determine the validity of a record. It is an important means to maintain the validity and immutability of distributed ledger data.
  • the consensus mechanism on the blockchain mainly solves who constructs the blocks and how to maintain the uniformity of the block data in the peer-to-peer network.
  • the theoretical basis of this problem is the Byzantine Fault-Tolerant [ BFT] [6] . Since the research of BFT in the 1980s, the prerequisites for the solution of the problem and the specific implementation of the BFT have existing algorithms, and a relatively mature theoretical system has been formed.
  • Bitcoin's PoW consensus uses a simple and violent approach, combined with economic incentives, to solve the Byzantine fault tolerance problem.
  • PoW achieves data consistency in large-scale peer-to-peer networks. Only data that is recognized by more than 50% of the entire network's computing power can be written into the blockchain to form immutable data. . Until now, Byzantine algorithms were only implemented in relatively small distributed environments.
  • the core of the consensus mechanism is the construction and verification of blocks.
  • the PoW system uses the “mine” method to construct blocks, and the PoS system uses the “mint” method to construct blocks.
  • Different consensus protocols have their own application scenarios. There is no suitable standard to distinguish between good and bad. The last section of this chapter will describe in detail the comparison and selection of consensus mechanisms in different application scenarios.
  • Smart contracts, smart contracts are based on these credible and immutable records and data on the blockchain, and can automatically execute some rules and terms defined in advance with code [42] .
  • the technical basis of smart contracts is script technology, which can implement automatic verification and automatic contract execution on the blockchain [57] .
  • the script mechanism in Bitcoin's blockchain system is relatively simple, and can only explain related OP instructions based on stacking. Can't parse more complicated logic. However, it provides a prototype for programmability.
  • Ethereum is a set of Turing-complete languages that support scripting based on a scripting mechanism, making blockchain technology possible as an underlying protocol.
  • Blockchain technology architecture After researching the architecture of the blockchain, Yuan Yong and others put forward the basic architecture model of the blockchain [22] .
  • the data layer, network layer, consensus layer, incentive layer, contract layer, and application layer are respectively from bottom to top.
  • the bottom three layers of data, network, and consensus are essential elements in the blockchain architecture.
  • the top-level incentive layer, contract layer, and application layer can be selectively configured on the basic structure built by the essential elements.
  • the data layer encapsulates the lowest-level data block structure, chain connection structure, timestamp technology, Hash function, Merkle tree, and cryptography. It is the foundation of the necessary elements.
  • the network layer includes a distributed networking mechanism.
  • the consensus layer encapsulates various types of consensus algorithms in network nodes, is the brain of the blockchain, and is essentially a distributed consensus with incentive effects
  • the algorithm is also the focus of this study.
  • the incentive layer integrates economic factors into the block system, mainly including the issue mechanism and distribution mechanism of economic incentives.
  • the contract layer mainly encapsulates various scripts, algorithms, and smart contracts. It is a blockchain The basis of programmable features; the application layer encapsulates various application scenarios and cases of the blockchain. In addition to the currency and finance proposed in the architecture diagram, it also includes applications that are not listed and can use anti-counterfeiting traceability features.
  • the organization structure of the blockchain data The block-chain structure at the bottom of the blockchain lays an important foundation for its tamper-resistant characteristics.
  • transaction data in the network is concentrated in the area In the blockchain, each block is linked to the previous one.
  • the value of the Merkle root obtained by hashing all transactions (called transactions in Bitcoin) one by one, using the irreversible cracking feature of the hash function, makes the block once A certain transaction in the block is tampered, and the Merkle of the block header will need to be changed accordingly, otherwise the check will not pass to ensure the integrity of the data in the block.
  • the unique hash value of each block is obtained by hashing the block header to represent the uniqueness of the block, as shown in FIG. 10.
  • the blockchain has strong technical advantages in de (weak) centralization, and the different characteristics presented by it also determine To its various application scenarios.
  • the trust mechanism of the blockchain is based on the principle of asymmetric cryptography and is a purely mathematical encryption method. While realizing information sharing in the network, it also ensures the security of the personal privacy information of the traders behind the data. This allows the two parties to the transaction in the blockchain network to exchange trusted value in an unfamiliar mode. At the same time, in a decentralized network system, the intermediate cost of value exchange is almost zero. Therefore, while ensuring information security, blockchain technology also ensures the high efficiency and low cost of system fairness. It can be used in traditional centralized scenarios, instead of the transaction process that was originally handled by intermediaries or central agencies.
  • Programmable script is a "smart contract” mode. Therefore, in an environment where the market order is not standardized, the "programmable features" of the blockchain are introduced into asset or value transfer contracts. Future use and direction of transaction funds involved in the transaction. Can be applied to contract-related business.
  • Blockchain and alliance chain According to different application scenarios and design systems, blockchain can be divided into public chain, alliance chain and private chain. These three types of blockchain have different degrees of openness, as shown in Figure 11.
  • any node in the world can freely join or withdraw from the blockchain system, and read data, compete for accounting, send and forward pending transactions in it.
  • a public chain considered to be "fully decentralized" no individual or institution can maliciously control the reading, writing, or tampering of data.
  • Public chains generally use the token mechanism to ensure the activity of participants' competitive bookkeeping to ensure the security of data. Bitcoin and Ethereum are typical public chains.
  • the write permission of the private chain is strictly controlled by an organization and institution, and the license qualification of participating nodes will be strictly restricted. Because participating nodes are limited and controllable, private chains can often achieve extremely fast transaction confirmation speeds, better privacy protection, and lower transaction confirmation costs.
  • the private chain can use consensus that cannot be maliciously attacked, and can also implement the requirements required by the financial industry such as identity authentication.
  • the alliance chain refers to a blockchain that is jointly managed by several institutions. Each institution may run one or more nodes.
  • the data in the alliance chain allows only certain institutions in the system to read and write. Nodes with different permissions work together to record transaction data. Different from the privacy permission design of the private chain, the permission design requirements in the alliance chain tend to be more complicated [39] .
  • the alliance chain can prevent the possibility of a single node in the institution intentionally concealing or tampering with the data, and can quickly locate the source even if an error occurs. Therefore, many large financial institutions are more inclined to use the alliance chain / private chain technology at present.
  • the introduction of the alliance chain is not intended to be a huge innovation for the multi-party cooperation alliance cooperation model.
  • the de-intermediating nature of the blockchain makes the cooperation of the alliance no longer need to establish a new institution for the alliance.
  • the party does coordination and management, and there is no such thing as a single institution in this new intermediary institution.
  • the alliance chain system the alliance relies on a distributed ledger that is jointly maintained to realize all the functions of information sharing and data clearing, and truly realizes an alliance system that can be co-managed by multiple parties.
  • the introduction of the alliance chain enables the alliance to provide services externally in a distributed manner, eliminating the need for a third-party trusted agency to perform proxy services, and avoiding the bottleneck of a single point of attack.
  • the operating cost of the system is greatly reduced, technically reducing the overhead of the system message one-step forwarding and integration, and reducing the fees charged by the third-party intermediary service.
  • Only a reliable consensus protocol is needed to achieve the decentralized management and operation of the system. Therefore, as the core of blockchain technology, the design of the consensus mechanism is particularly important in the application of the alliance chain. The performance indicators of all aspects of the consensus mechanism Optimization and promotion has also become the most sought goal in the design of consensus mechanism in this article.
  • the Byzantine Consistency Agreement guarantees that distributed systems provide the correct service to customers.
  • Group membership agreement enables the distributed system to dynamically add or delete server nodes, ensuring that the distributed system has enough correct nodes to provide services to customers. By continuously deleting the wrong nodes and increasing the correct nodes, the distributed system is highly available for a long time. The algorithm proposed in this paper can effectively make the wrong nodes automatically excluded from the system.
  • Fault-tolerant systems Through the analysis of the existing fault-tolerant systems' construction methods and technologies, the consensus mechanism proposed in this paper needs to ensure that the system to which they are applied can resist Byzantine errors and that the protocol is practical.
  • the distributed consensus conditions of the consensus mechanism The blockchain solves the problem of transmitting trusted information and value transfer on untrusted channels, and the consensus mechanism solves the problem of how the blockchain achieves consistency in a distributed scenario [59 ].
  • the research value of blockchain is that its consensus mechanism solves the problem of mutual trust between nodes based on decentralized thinking. With the correct operation of the consensus protocol, the blockchain can reach a more balanced and consistent state among many nodes. It can be considered that cryptography builds the cornerstone of blockchain technology, and the use of cryptography's consensus mechanism is the key to ensuring the continuous operation of the blockchain system.
  • Termination Consistent results can be completed in a limited time.
  • Asynchronous message passing Different nodes have the ability to process transactions, network node data throughput is different, there are message delays and losses, and message passing between nodes cannot achieve synchronous order.
  • node fail-stop The node is continuously down and will not recover.
  • node fail-recover The node recovers after a period of downtime.
  • a completely decentralized non-permissive consensus mechanism is a consensus protocol tailored for the blockchain. In the process of building a block, in addition to ensuring its security and implementing the currency issuance mechanism, In addition, there is an important process. This process determines in a decentralized manner who will get the right to build the next block recognized by the entire network.
  • a purely completely decentralized consensus mechanism must implement that the block generated and published by only one node in thousands of computers is legal. The time interval between the appearance of these blocks needs to be large enough to allow the network to reach consensus between each block.
  • a completely decentralized non-permissive consensus mechanism needs to set the cost of building blocks to increase its difficulty, which not only guarantees the same block building rights of peer nodes, but also avoids network congestion caused by competing accounting.
  • a completely decentralized non-permissive consensus mechanism is generally used in the public chain. Nodes can freely move in and out of the network without obtaining permission, and achieve a completely decentralized consensus in a point-to-point network. Representative consensus mechanisms include PoW, PoS, and DPoS.
  • consensus mechanism With the development of blockchain technology, the research on the consensus mechanism has turned to the improvement of the Byzantine fault tolerance algorithm in order to avoid the high energy consumption brought by PoW while achieving point-to-point consensus, but it still has the disadvantage of limited node size.
  • Representative consensus mechanisms include PBFT and dBFT.
  • the traditional distributed consensus mechanism in non-Byzantine scenarios The machine variant of the BFT algorithm mainly solves the consensus problem in the Byzantine scenario.
  • the traditional distributed consistency is implemented in a relatively closed distributed cluster with the participation of nodes. Need permission. Its efficiency is high, but it only considers failures such as node downtime, and does not consider the possibility of malicious attacks (ie, forgery, and attack information) on the nodes.
  • the two mainstream algorithms are Paxos and Raft, and these two algorithms still need to be modified to apply to blockchain systems.
  • Compliance supervision Whether it supports super-authority nodes to supervise the entire network nodes and data, whether it can control the legality of blockchain data, and eliminate transaction transactions that do not meet the requirements of actual laws.
  • Performance efficiency The efficiency of transaction data to reach consensus and confirmation.
  • the consensus mechanism allows the system to be efficient in transaction data processing speed.
  • Resource consumption CPU, network input and output, storage and other resources consumed during the consensus process need to avoid excessive waste and consumption of resources.
  • Fault tolerance the ability to prevent attacks and fraud.
  • the blockchain is a distributed ledger.
  • the nodes participating in the service or operation of the entire network keep a complete copy. How to maintain this unified ledger together and make the data stored by all participating nodes consistent and complete, the consensus mechanism plays a very important role in it. effect. It determines who is responsible for bookkeeping for this ledger, and ensures that the ledger across the network can be modified uniformly, so that a kind of rule "consensus" is formed between each node. Under the operation of this rule, this distributed ledger can be smoothly written, read, and kept consistent across the network.
  • the consensus mechanism is oriented to the alliance chain scenario.
  • the alliance chain is a compromise between the two scenarios.
  • the alliance chain prefers to run between different institutions or organizations in the same industry or for the same purpose. In order to reduce the cost of communication and liaison between institutions and improve the efficiency of business cooperation.
  • the original intention of the alliance chain is to bring different organizations together to achieve the value of strong association and the decentralization within the alliance, so as to achieve "partial decentralization" of the alliance chain system.
  • the alliance chain generally has strict identity permission restrictions, and the protection of security and privacy is limited to the internal system, which requires higher system throughput and delay.
  • the nodes participating in the consensus in the alliance chain need to perform identity verification. More importantly, the alliance members, as service providers in the system, provide services to the outside world and need to have sufficient control over their data and operating conditions. If an abnormal situation occurs, the alliance can negotiate to enable the supervision mechanism and implement certain governance measures to track the punishment of malicious attacks on the system or make further governance compensation for the data corruption that has been caused to reduce losses.
  • this article introduces the CoV consensus mechanism through a simple application scenario, explaining that CoV can perfectly fit the needs of alliance decentralized management, and through voting to make the best consensus between alliances. .
  • the blockchain system can easily solve the above-mentioned fund settlement problem.
  • After the introduction of the distributed ledger technology of the blockchain it is possible to record all transaction records in 5 tables with only one distributed ledger, instead of each The bank holds some (incomplete) records, as shown in Figure 13.
  • any bank can easily derive the completeness it needs from this super table, and at the same time, customers can easily calculate their own balance from it without the need to integrate data from different systems.
  • the question is, who will maintain this form (accounting)? Obviously, if it is handed over to a third intermediary agent to integrate the data, the bank will lose its existence, and once this third party fails, it will have a negligible impact on the world where capital operates as blood. As a bank's leader or the establishment of a World Bank to integrate data, any bank will not only make the system load too concentrated, but will also cause other banks to be stubborn and dissatisfied.
  • the new consensus places a certain limit on the number of bookkeepers.
  • the bookkeepers are elected by voting in each round, and the transaction transactions are collected and recorded in the account book within a certain tenure.
  • the bookkeepers who have not been selected are waiting for the next election as candidates. If ordinary users want to join the bookkeeping team, they need to become candidates first.
  • the candidate In order to reduce the malicious behavior of the bookkeeper team, the candidate must obtain a recommendation letter from a bank and obtain the unification of most banks to pass the verification.
  • the new consensus mechanism is inspired by several mainstream consensus mechanisms, and also realizes that all consensus mechanisms designed for public chain scenarios cannot avoid the trade-offs and games of the two key points of security and performance.
  • Blockchain projects such as Bitcoin and Ethereum, which have been running for many years with high security and reliability, use consensus mechanisms that guarantee the security of the entire network as much as possible at the expense of performance; most of the subsequent consensus mechanisms are designed to Improve the performance of the consensus mechanism, sacrificing a complete security argument to some extent or making corresponding security assumptions or restrictions on the premise of the algorithm. Therefore, the consensus mechanism proposed in this article hopes to take into account the performance of the four dimensions of the consensus mentioned in Chapter 2, while achieving consensus consistency in the alliance chain:
  • the alliance chain can use the supervision mechanism to keep the system's key logs for audit, making the blockchain system no longer in an uncontrollable state without supervision and making the system's operation more credible and reliable;
  • the high credibility of the alliance nodes in the alliance chain provides a natural guarantee for the blockchain system. It does not rule out that the network node server provided by the alliance may be down or invalid, but this is a block.
  • the chain's security model provides a good premise.
  • the new consensus mechanism can use the premise of the alliance chain's natural security model to achieve the termination of transaction confirmation under weak synchronization. Consistent results can be completed in a limited time. The new consensus mechanism can realize that the blocks are not forked, and each block has finality. The transaction confirmation only needs to wait for the confirmation of one block, as shown in Figure 15.
  • PCSet Personal Computer Set
  • PCi Physical Computer Set
  • PCn-1 Physical ServerSet
  • CSSet Common ServerSet
  • fn of n ordinary processors are controlled by Byzantine attackers
  • fm of m commercial processors are controlled by Byzantine attackers.
  • the effective transaction data of unwritten blocks retained in the node memory is represented by T (Transaction), and the transaction belongs to the transaction set TSet (Transaction Set). Receive and forward all valid transactions in the network, and add legal transactions to the block.
  • Block h represents the block with height h
  • transaction i in block h is represented by txh (i)
  • txh (i) ⁇ TSet. All processors can determine the validity of each transaction by accessing a specified contract function C: TSet ⁇ ⁇ 0,1 ⁇ .
  • the ordinary processor PCi process can request CSj to synchronize the legal transaction set ⁇ tx0 ⁇ , ⁇ tx1 ⁇ , ..., ⁇ txh ⁇ , ... ⁇ during initialization. If an audit node appears in the system, Audit nodes can also apply to CSj for data and apply for legal transaction sets to other CSs to verify the consistency of transaction sets and obtain the most complete transaction set.
  • the ⁇ txh ⁇ generated by PCSet needs to be checked by certain rules of CSSet. CSSet has absolute right to generate and verify ⁇ tx0 ⁇ , ⁇ tx1 ⁇ , ..., ⁇ txh ⁇ , ... ⁇ .
  • Consensus There is a time difference function ⁇ ( ⁇ ). For ⁇ (0 ⁇ ⁇ 1), the probability that two CS nodes return at time t to be different at t- ⁇ ( ⁇ ) is less than ⁇ , that is, different nodes The status is consistent.
  • Termination There is a time difference function ⁇ ( ⁇ ). For ⁇ (0 ⁇ ⁇ 1), the state returned by a node at the time t ', t ”> t- ⁇ ( ⁇ ) is different. The probability is less than ⁇ , that is, the consensus process of the same node can be completed in a limited time.
  • the designed consensus algorithm runs under a certain security model.
  • the security assumptions of the underlying network of the alliance chain are as follows:
  • the communication between honest processors uses a synchronous network model.
  • the honest processor A1 sends a message to the honest processor A2, considering network delay, and the upload and download speeds in different regions are different, A2 may not be able to receive synchronously.
  • the time of the honest processor in the point-to-point network is synchronized with the time of the NTP (Network Time Protocol) server.
  • NTP Network Time Protocol
  • alliance nodes are generally large companies with large commercial server clusters that are independent or in the cloud. Therefore, it can be considered that commercial processors are far stronger than ordinary processors in terms of security and computing power, so they are considered Byzantine nodes. The possibility of control is also lower, that is fm / m ⁇ fn / n.
  • the behavior of the processor controlled by the Byzantine attacker can be arbitrary malicious, such as not following the protocol, discarding valid transactions, ignoring messages sent by other processors, forging messages, forging transactions, and so on.
  • CoV Consensus of Vote
  • the alliance chain network that is, in the permission chain.
  • each node has a certain identity and account number, and independently has public and private key pairs and digital certificates.
  • CoV can achieve the orderly writing of the blockchain and the node data in the network. Consistency.
  • the alliance chain adopts a P2P-based network architecture.
  • a network composed of alliance nodes can be considered a weak center in the system and a supporting system.
  • each node in the P2P network is a peer node and is connected in any way, according to the different functions provided, each node's division of labor is different.
  • the nodes are divided into the following four roles: commissioner, steward Butler, butler candidate, housekeeper candidate, ordinary node Ordinary user, and allows part-time roles, as shown in Figure 17.
  • voting weights can be set according to the rights and interests of the corresponding alliance institutions in the alliance.
  • the transaction of a valid block must receive more than 50% of the votes of the members, which represents the wishes of all members.
  • Butler is a professional bookkeeper in the alliance chain.
  • the alliance chain has been granted the right to specialize in producing blocks.
  • the number of housekeeper nodes is limited.
  • the role of steward can be considered as the leader node in traditional consensus algorithms. But unlike traditional algorithms, the authority of the steward is supervised and voted by important member nodes in the alliance.
  • the emergence of the role of steward means the separation of voting rights and enforcement rights.
  • the members do not have the right to produce the blocks, leaving the work to the steward.
  • the block is encapsulated by the information collected in the alliance chain, and the steward needs to sign the encapsulated block. There are two steps to becoming a steward:
  • the method of election is that all housekeeper candidates receive votes from all members.
  • the steward generates blocks in a random order during his term, and accepts re-election after his term expires.
  • a member can have both the status of member and steward.
  • Butler candidate the system will number ⁇ 0,1,2, ... n-1 ⁇ the successful steward for each round of election. To ensure the stability of the consensus process, the number of stewards is limited to a constant number. The setting will be discussed later. To become a steward, you must first become a steward candidate, participate in each round of elections, and accept members' votes to become stewards. Candidates who failed the election retain their identity as stewards and remain online, waiting for the next round of elections. There are three steps to becoming a steward candidate from an ordinary node:
  • a recommendation letter signed by at least one member is required, similar to an invitation code, and the recommended member reviews and guarantees that the identity information of the housekeeper is correct.
  • the recommendation letter is generated by the member by calling a function in the client, and the implementation method is asymmetric encryption.
  • the private key encrypts the content of the recommendation letter. After the public key decrypts it, you can verify whether the recommendation letter is forged;
  • CoV assumes that the number of system member nodes is Nc, the number of housekeeper nodes is Nb, the number of housekeeper candidates is Nbc, the number of ordinary user nodes is No, and the total system node is Nall. Because a node can have dual identities, the total number of members, stewards, and steward candidates is less than the sum of the number of parts, that is, Nall ⁇ Nc + Nb + Nbc + No, where the number of stewards is quantitative. In each term, each steward who successfully campaigns will get an allocation number, starting from 0, and the last one is Nb-1. Assume that the steward's tenure cycle is Tw, and Bw + 1 blocks are generated during each term.
  • the steward rotates on duty in a random order during the duty cycle, and generates a block in each duty cycle.
  • the last block of each tenure cycle is a special block that records the voting results, that is, the server information and steward number of the steward node elected for the next term.
  • the housekeeper is required to generate a block within the specified duty cycle, which is also the block's packaging cycle Tb. See Appendix A for the symbol comparison table used globally in this article.
  • Figure 19 shows a consensus model for the tenure cycle.
  • the steward generates and signs a valid block each time called a round of consensus.
  • the housekeeper calls a function to generate a random number R, 0 ⁇ R ⁇ Nb.
  • the steward with the same housekeeper number as R is called the watchkeeper.
  • the watchkeeper is responsible for generating and signing the next block.
  • Each valid block is final and will not fork, as shown in Figure 20.
  • the last round of consensus in the term will generate the Bw + 1 block, which is a special block.
  • the current steward and steward candidate are running for the next round of stewardship.
  • Each member node votes on the steward candidate, and finally the top Nb node among the Nbc steward candidates is elected as the steward.
  • Voting information and results are written into this special block.
  • the steward After reaching a consensus on voting, the steward officially resigned this round, and then started a new round of appointment cycle. There are a total of Bw + 1 rounds of consensus in each round of the service cycle, resulting in Bw + 1 blocks.
  • Incentive mechanism 1 Alliance funds and clearing mechanisms. The purpose of the steward node to participate in the election and generate valid blocks is mainly to obtain accounting fees.
  • the alliance chain system can solve the problem of bookkeeping fees by introducing tokens. The amount unit and conversion of the token corresponds to the actual currency amount unit and conversion. After the alliance is established, an alliance fund account address will be set up, which corresponds to a real account where funds are deposited in the bank in reality. The following only illustrates the use and clearing methods of the alliance funds.
  • the actual system operation can add other operations related to token transfers, such as fee management, or other incentive mechanisms to encourage the stewardship.
  • Issuance of tokens Multiple alliance institutions jointly set up a real account in a bank A, and bank A has a virtual bank account A * that issues tokens in the alliance chain system. Whenever an alliance recharges a real account in bank A in reality, after bank A confirms the receipt of funds, it will use A * 's identity to issue a transaction in the alliance chain system, indicating that the same amount of tokens will be transferred to the alliance Fund account address. After being verified by more than half of the members, this transaction can be written into the blockchain as a legitimate transaction.
  • This alliance fund is used to store deposits submitted by housekeeper candidates, pay salaries to housekeepers, and manage user fees. When necessary, members can transfer funds to Bank A to replenish funds at the account address.
  • Token transfer The salary received by each steward depends on the number of valid blocks that have been generated. The payment of each salary is realized by transferring the token to the steward's public key address.
  • Destruction of tokens You can withdraw cash in Bank A according to the virtual tokens you receive, and send the corresponding withdrawal token amount to a public key address without a corresponding private key for destruction.
  • Incentive mechanism 2 Scoring and reward mechanism. At the same time, the scoring mechanism and reward mechanism are also added to the consensus mechanism. The higher the score, the steward and the steward candidate have a greater probability of getting votes to be elected as stewards. The steward who successfully encapsulates valid blocks will receive a corresponding amount of reward according to the number. The system uses these two external incentives to attract more people to join the ranks of the steward, rewards honest work, punishes evil behavior, and makes the system more More and more secure and reliable development.
  • Each committee member maintains and grades a butler candidate list.
  • the scoring rules are:
  • the housekeeper node is not online and misses the opportunity to produce the block, its score will be reduced or even cleared by all members. If the offline agreement is severely punished in the alliance agreement and it is uniformly set to zero, it means that When the housekeeper comes back online, you need to start over.
  • the housekeeper's scores for each member may be different.
  • the score for each housekeeper candidate represents the degree of trust in the housekeeper, and also becomes one of the basis for voting.
  • the housekeeper After the end of each round of office, the housekeeper will receive remuneration from the alliance based on the number of valid blocks that have been generated, giving them the motivation to apply for elections, work honestly, and stay online for a long time.
  • the accounting remuneration is an important incentive to ensure the honest work of the housekeeper, which will be discussed in detail later.
  • the full name of the CoV consensus is Consensus of Vote.
  • the original intention of the consensus algorithm design is to set up a universal identity model (confederation nodes and other nodes) for the alliance chain, using the special identity of the alliance nodes in the alliance chain model, and obeying the "minority obeying the majority"
  • the principle is to use the voting result as a legal proof of a valid block generated by the system.
  • the decision results are generated by other nodes in the system.
  • a recommendation mechanism and two voting proof mechanisms are introduced.
  • Consensus of Vote Butlers Trust vote for stewards. The total number of votes cast by members at the end of each term indicates the trust of all members in this steward and the reliability of each steward. Prove by the members' vote on the housekeeper.
  • Consensus of Blocks used to verify the legitimacy of block generation, each block must be verified by more than half of the members to be considered valid legal blocks. This means that if the system needs to modify the result of a certain transaction, the amendment of the transaction can pass the legality check smoothly with the consent of more than half of the members. The opinions of more than half of the members represent the will of all members. The legitimacy is proved by the voting results of the alliance, as shown in Figure 21.
  • the CoV algorithm establishes the role of steward and steward candidate for the system, so that the decision result of the alliance chain is executed by a dynamically replaced steward team elected by decentralized voting, and a voting consensus is virtually formed among the alliance nodes.
  • the analysis of the final consistency of CoV in the following it is proved that more than half of the voting results can uniquely confirm a final decision, so that the alliance chain system can run stably under the decentralized management of the alliance nodes.
  • proof of voting is reflected in the design of the consensus mechanism through two types of voting, the first is the vote of members on whether to agree with the block, and the second is the vote of members on the steward candidate. Members vote by returning their signatures.
  • the first is a member's vote on the legitimacy of the block.
  • the block generated by the watchkeeper i is sent to all members. If the member agrees to the generation of the block, the block header and the current time stamp are encrypted and signed, and the signature and time stamp are returned to the housekeeper i.
  • the housekeeper i receives a signature of Nc / 2 + 1 or more within the specified time, the block is valid; otherwise, the block is invalidated and the housekeeper i + 1 repackages the block.
  • the second is a member's vote on the steward candidate.
  • the member sends a signed vote to the steward j.
  • Housekeeper j collects and calculates the votes, encapsulates all voting affairs and results into a special block, and sends it to all members to vote for the legitimacy of the block.
  • a combination of two types of votes are included in the voting transactions sent by members:
  • Designated votes Considering human factors, members can set up a set of designated candidate sequences or random candidate sequences to increase the liquidity of the steward.
  • the vote of members on the steward reflects the degree of trust of the steward, and the random rotation of the steward increases the liquidity of the steward, preventing an institution from controlling most of the excellent stewards to occupy the rank of the steward permanently, and also avoids some frequent elections.
  • the possibility that the housekeepers on the market will be bought in a wide range makes the system more secure and reliable.
  • the cooperation of the underlying network layer and the data layer is also required.
  • the role of the consensus layer is to achieve the consistency of the correct blocks stored by all nodes without a central server.
  • the communication between nodes implements the generation and synchronization of blocks on the alliance chain by spreading messages, transactions, and blocks. The following types of special transactions and messages are used in the algorithm description in this chapter.
  • Tx_PERMISSION identity permission transformation transaction, which contains at least several attributes (from, tobe, prove_sign_list, addr, sign), and represents the node identity permission transformation transaction. from indicates the original identity, tobe indicates the target identity, in which the member node can become a steward candidate at the same time, and prove_sign_list indicates the signature list. Use a signature to prove that the transaction has been verified or recommended by the Alliance members.
  • provide_sign_list contains the recommendation letter of a member and the consent signatures of more than half of the members; in case of authority change of members to become steward candidates, the recommendation letter of the members is included in provide_sign_list.
  • Transaction 2 Tx_VOTE voting transaction, during the duty cycle generated by the special block, the voting affairs sent by the member to the steward on duty, including the list of candidate stewards.
  • Tx_DEFINE Custom transactions, that is, ordinary transactions in blockchain applications. Different systems will customize different ordinary transactions.
  • SIGNpuk data, [time]
  • the member's signature message used to return a recommendation letter or consent message
  • sign the data data and the data can be attached with the timestamp at the time of signing.
  • the subscript puk indicates the public key.
  • Pre-Blcok (Pre-Header, Body) the message sent by the housekeeper to all members after the pre-block is generated. Contains the initial block header and the block body containing the transaction ⁇ tx ⁇ .
  • the steward generates the final confirmed block, including the complete block header and the block body.
  • Message 5 BLOCK_SYNC a block synchronization message, is generally used in a system where a node requests a member node or a neighboring node to synchronize the latest block, and updates system variables in the processor.
  • the data structure of the block facilitates the formal description of the code.
  • commissioner bul: bulter
  • bc bulter candidate
  • user ordinary user; as shown in the following table:
  • a tenure cycle includes the following steps:
  • Step 2 Complete the Bw round of consensus and generate Bw ordinary valid blocks
  • Step 3 In the last round of consensus in the tenure cycle, the committee updates the scores in its steward candidate list and conducts voting. A special block will be generated containing the information of the new housekeeper and the corresponding number;
  • Step 4 The term ends, and steps 1-4 are performed cyclically.
  • Nbc ⁇ Nb
  • the generation of a valid block is called a round of consensus.
  • a round of consensus may take M packaging cycles. If steward i cannot generate a valid block within Tb time, the authority of the production block will be transferred to steward i + 1. This process is called the steward rotation process.
  • the flowchart of generating a common block is shown in Figure 24.
  • the generation of an ordinary block goes through the following steps:
  • Step 1 Any node on the entire network generates transaction data and attaches a signature, and also receives transaction data to verify whether the received transaction data is correct. If the transaction data is correct, the transaction data is forwarded, and all transactions are mainly forwarded to members and stewards;
  • Step 2 All housekeeper nodes listen to transaction data and put valid transaction data into the transaction pool. Housekeeper nodes and committee members in the entire network regularly synchronize NTP time.
  • Block cut-off time Tcut GetPreviousBlockComfirmTime () + M * Tb;
  • Step 5 After the member node receives the Pre-Block, it verifies the data in the block. If it agrees with the generation of the block, it signs the hash value of the Pre-Header + local timestamp string connection, and sends the signature and timestamp back. To the steward
  • Step 6 Before the time Tcut, when the received block already has the signatures and timestamps of at least Nc / 2 + 1 nodes, the corresponding signatures and timestamps will be serialized into strings in ascending order of timestamps.
  • a Ready-Header After the Pre-Header, a Ready-Header is generated.
  • add the R value and the block generation time take the maximum value in the timestamp list returned by the member on the basis of the Ready-Header, and finally generate a Final-Header, and publish a complete Final- Block, go directly to step 8;
  • Step 9 After receiving the valid block, all member nodes and housekeeper nodes verify that the block has the signatures of more than half of the members, delete the transactions contained in the valid block from the transaction pool, and obtain the random number R contained in the valid block. , Start the next round of consensus, and determine whether the next round of consensus generates a special block. If yes, skip to the special block generation process. If no, skip to step 4.
  • the above description is the process of achieving a round of consensus among various roles from the perspective of the entire network.
  • the steward plays an absolutely important role in all participating consensus nodes.
  • the following algorithm is false
  • the code introduces the specific operation of the housekeeper node during the duty cycle through a formal description.
  • the special block is the last block in a tenure cycle, and its purpose is to complete the election voting of the new housekeeper.
  • the process of generating a special block is similar to the process of generating a normal block. The difference is that the block encapsulates not transaction data, but the butler information for the next term, as shown in Figure 25.
  • Step 1 Before the special block is generated, all members select a sequence from the current housekeeper and housekeeper candidates to form ballot information and send it to the housekeeper on duty;
  • Step 2 All members and the current housekeeper receive the voting information of all other members at the same time and put them into the memory pool (transaction pool).
  • Step 3 The on-duty steward determines whether the number of voting transactions collected exceeds half of the number of members. If so, perform steps 4-8 to generate a new block; if not, continue to wait until the time-out and replace the on-duty steward.
  • Steps 4-8 are similar to steps 4-8 of normal block generation. Special blocks also need to be signed and authenticated by members to reach consensus. The difference is that the content in the block is not ordinary transaction information but vote information. After calculation, the node with the top Nb votes is elected as the steward hired in the next duty cycle, and the information of the new steward will be written into the block as a special transaction.
  • Step 9 After completing the last round of special block generation, the steward of this round of office deletes the relevant voting information in the memory pool. After the term ends, he officially resigns and jumps to step 3 of the ordinary block generation process.
  • the housekeeper node Compared with the ordinary block generation process, in the special block generation process, the housekeeper node only needs to add one step to determine whether the number of collected voting transactions meets the requirements, and select the voting transaction in the process of encapsulating the transaction. And the member nodes have added the step of generating voting transactions in the process of generating special blocks.
  • the following algorithm shows in a formal way the operation flow of the member node perspective in the process of generating a block.
  • the genesis block is the most special block in the alliance chain. It has a height of 0 on the blockchain and contains the initial alliance node information and the first batch of housekeeper node information, which lays the foundation for subsequent block generation.
  • the most important block in the chain, its generation process is as follows:
  • Step 1 The initial member nodes of each founding alliance communicate with each other to confirm online, and the member (agent member) with the smallest public key hash value is responsible for generating the genesis block;
  • Step 2 All member nodes will send the status and authority change affairs for upgrading to members to the deputy members;
  • Step 3 The member node wishing to serve as the steward at the same time sends an application to all member nodes, and sends a request message for the change in the identity and authority of the steward candidate, with a self-signed signature. If other members agree with their application, they return the signature. Signature, this node can successfully generate a legitimate identity permission change transaction, send it to the proxy member and publish it to the network, and the member nodes in the entire network put this transaction into the memory pool.
  • Step 4 All members send ballots to the deputy members, and all member nodes extract verified candidate housekeeper information from the memory pool, and select at least K candidate housekeeper account addresses (if there are not enough K, you can cast two for one account The above votes) are serialized into ballot information and signed, and the ballot message is returned to the deputy member.
  • Step 5 After the deputy members count, they will integrate the issues of upgrading the status and authority of the members and the changing of the status and authority of the candidates for stewardship.
  • the ballot information for all members will be integrated into the new round of stewardship.
  • Generate Pre-Block send to all members, and get the signature confirmation of all members Steps 4-8 of the block.
  • Step 6 After all members have received the genesis block, they will delete the identity permission change transaction and ballot transaction to be confirmed in the memory pool.
  • the genesis block When the genesis block was generated, the genesis block generated the first batch of butler list information.
  • the number of confirmed housekeeper nodes in the genesis block may be less than the set number of housekeepers Nb.
  • Some housekeeper candidates can be assigned multiple housekeeper numbers to fill the number of housekeepers, so that the housekeeper numbers 0 to Nb-1 are all There are corresponding nodes.
  • the acting member acted as a bookkeeper (keeper on duty). The flowchart is shown in Figure 26.
  • the pseudo code of the genesis block generation algorithm is as follows:
  • steps 4-8 of generating ordinary blocks an improved two-phase commit is actually used to ensure the unique legitimacy of the block.
  • Each duty steward needs to perform a two-phase commit process such as "Prepare-Ready-Propose- (Comfirm)" to complete the final confirmation of a block.
  • Prepare-Ready is a stage that is a necessary stage for block generation
  • Propose- (Comfirm) is a stage that refers to the stage where blocks are released after the Final-Block is generated.
  • Nc messages are sent at each stage with a message complexity of approximately O (3Nc).
  • "Propose- (Comfirm)” is simplified to the process of publishing blocks. The Comfirm process is implicitly reflected in the process of consensus operation, as shown in Figure 27.
  • the watchkeeper generates the Pre-Block and sends it to all members.
  • the Pre-Block contains the list of legal transactions collected in the watchkeeper's memory pool, which is represented by the set ⁇ tx ⁇ , and is finally placed in the block body structure.
  • the number of the steward on duty is equal to (R '+ M-1) mod Nb, which reflects the relationship between the number of the steward in this rotation and the R value specified in the previous legal block;
  • Butler_i_puk represents the public key information of the steward on duty, It is used to prove the book ownership of this block. It is also used to prove and calculate the final income of each housekeeper.
  • Merkle_Root is a hash value calculation of all transactions in the transaction list. It is used to verify the originality and authenticity of all transactions. It is one of the important parameters of blockchain tamper resistance.
  • the steward on duty waits for all members to verify the legitimacy of the block and vote.
  • the way to vote is to sign the Pre-Header and the current timestamp and return the signature to the steward on duty, where the signature C_sign (j) represents member j
  • the message signature obtained by encrypting Pre-Header and C_time (j).
  • C_time (j) represents the timestamp when member j received the block and encrypted the block, which affects the final block generation to some extent time.
  • Each member has one and only one chance to return a verification signature for a Pre-Block during a duty cycle.
  • Ready-Block is a transition phase from Pre-Block to Final-Block, which includes the signatures and timestamps of the collected member nodes.
  • the R value will be generated from the signature set of all member nodes, and the final generation time of the block also depends on the maximum timestamp returned by the member nodes. Therefore, whether the block is generated on time depends on the latest confirmed signature information returned by the members. It does not depend on the local timestamp of the steward on duty. After supplementing the R value information and the time stamp Time information in the block header, the steward on duty generates a Final-Block.
  • Propose phase In the Propose phase, the steward on duty has completed all the work, and released the Final-Block directly to the entire network. In particular, it will first be sent to the member nodes and other steward nodes to announce their own responsibility for this block. Bookkeeping rights.
  • Comfirm stage At this stage, the member node does not need to explicitly send a confirmation message to the steward node on duty. After more than half of the members received the Final-Block, this block really entered the Comfirm stage and became a legal final block. After more than half of the members receive this Final-Block, they can prevent the next number housekeeper on duty from launching a "preemption" attack to preempt the block's accounting rights.
  • Each member node will only perform signature confirmation operations on the Pre-Block sent by the current steward, so members will not confirm the Pre-Block submitted by the steward who conducts "preemption” attacks, as long as more than half of the member nodes have received the duty In the Final-Block released by the housekeeper, it is impossible for the Pre-Block of the "preemption” attack to obtain the signature of more than half of the members and become invalid, thereby ensuring the uniqueness and consistency of the block under the implicit consensus. This security Proofs will also be discussed in Chapter 4.
  • each block corresponds to a random number, and this random number points to the steward number of the next package block to ensure that the steward generates blocks in a random order, as shown in Figure 29.
  • the random number generation algorithm is as follows:
  • the housekeeper receives the signatures of K members, and sorts them in ascending order according to the timestamp sent by the members, which are ⁇ C_time [i], C_sign [i]> (0 ⁇ i ⁇ K, Nc / 2 ⁇ K ⁇ Nc-1) .
  • C_sign [i]> (0 ⁇ i ⁇ K, Nc / 2 ⁇ K ⁇ Nc-1) .
  • the member node is responsible for verification and voting, and the steward node is responsible for block generation.
  • each node first enters the establishment stage of the genesis block.
  • the genesis block is jointly generated by the member nodes and contains the information of the members of the initial committee and the first housekeepers.
  • the system automatically enters the cycle of "generating Bw ordinary blocks + generating 1 special block", one cycle is a duty cycle, and one duty cycle contains Bw + 1 rounds of consensus. A round of consensus may It will take M housekeepers to finally generate a block.
  • the housekeeper section performs the work during the on-duty and non-on-duty cycles, and periodically requests the majority of members to synchronize the blocks to ensure the latest data status of its own nodes.
  • the generation period of a block is also the duty cycle of the selected steward to generate a block.
  • the next block to be produced by Steward Bi is a special block, there may be two trends in the process. The algorithm flow will be described from the perspective of the interaction between the steward Bi and the Nc member nodes.
  • Bi first judges whether the block to be generated is a special block, and then decides whether to collect a list of unconfirmed transactions from the memory pool, or wait for the ballot transaction issued by the member node. Bi will organize the ballot transaction or other transaction information to generate Pre- Block.
  • Bi sends the Pre-Block to all member nodes and waits for the members' verification. If the member nodes accept the generation of this block, they sign the hash value of the block header and the current time stamp, and sign the signature information C_sign and the time of the signature. The timestamp C_time is returned to Bi.
  • the final block is generated. If not more than half of the members 'signatures are received or the time stamp of half of the members' signatures received has expired during the duty period, the generated block will be invalid. In the next duty cycle, the right to generate blocks will be handed over to the numbered extension. The next housekeeper jumps to Phase 1 and restarts; if the block is valid and has not timed out, then Phase 3 continues.
  • Phase 3 Publish the block
  • Bi sorts the members' signatures received in phase two and improves the element information of the block header, including generating a random number R and adding the generation time of the block. Finally, it publishes qualified special blocks or ordinary blocks to the entire network, and jumps. Go to stage 1 and repeat the new duty cycle.
  • the important nodes for creating the block are the member node and the steward node.
  • the workflow of the steward and members after the genesis block is given, and the flowcharts are taken from the perspective of the steward and members, as shown in Figure 31-32.
  • the flow chart uses ⁇ h, hs, M, time, R, sign (B)> to represent some key attributes in the block, which respectively represent ⁇ block height, the latest special block height, and it takes M duty cycles , The timestamp generated by this block, the random number generated by this block, butler's signature>.
  • the step of checking whether a block is legal from the perspective of a committee member includes a judgment as to whether a special block is generated at the current stage, and then based on the judgment result, it is determined whether to use a check function for a normal block or a special block.
  • the purpose of the operation step of updating the butler's score list according to the M value is to determine whether any butler has missed generating a new block.
  • M value of the received legitimate block it indicates that the consensus time in this round does not exceed M * Tb, and A block, of which M-1 blocks have failed due to failed verification or timeout, members need to make penalties to reduce or even clear the housekeeper who generated the failed block.
  • Figure 31-32 only explains the key processes of ordinary block and special block generation from the perspective of members and housekeepers.
  • the steward and member nodes are the most critical consensus nodes in the CoV consensus.
  • Other nodes such as steward candidates and ordinary nodes are in a continuous loop operation of continuously synchronizing blocks, updating memory data, forwarding blocks, publishing transactions, and forwarding transactions.
  • Most of the operations belong to the network layer and the data layer.
  • the operation of publishing ordinary application transactions belongs to the application layer operation, and is generally completed by the wallet function.
  • nodes with different identities each perform their duties, and round after round of consensus.
  • the first is the state machine running algorithm CoV_State_Machine of a single node.
  • the essence of the consensus algorithm is a distributed consensus algorithm, and the message communication method is defined on the basis of the distributed consensus algorithm.
  • the essence of the distributed consistency algorithm is to solve the problem of state machine transition to ensure that the states of each node in the network are consistent.
  • the CoV_State_Machine algorithm gives pseudo-code for a node to run the overall CoV algorithm. After a series of initialization processes, the node judges its own state and decides to run CoV processes with different identities based on its own state and configuration.
  • the pseudo-code can reflect the design process of the CoV algorithm, which is mainly a member process and a steward candidate process. Since the node can concurrently serve as a member and a steward candidate, these two processes can run concurrently.
  • the design of ordinary user processes and non-system node processes does not belong to the category of consensus design.
  • the Commissioner_Worker algorithm describes the execution process of the commissioner process, including the genesis block generation phase and the normal phase, of which Run_Generate_First_Block describes the genesis block generation algorithm, see Algorithm 3; Run_Commissioner_in_Generate_Block describes the commissioner in the normal phase, that is, the ordinary area For the operation flow in the generation phase of blocks and special blocks, see Algorithm 2.
  • the Bulter_Candidate_Worker algorithm describes the process performed by the steward candidate process. Since the steward status is a temporary identity, the steward work process can be executed after the candidate is successfully elected, so the candidate process includes the steward execution process Run_Bilter_in_Generate_Block, Algorithm1.
  • Tx_PERMISSION (gen_com, com, null, a / b / c, signa / b / c (Tx)) and Tx_PERMISSION (com, bc, null, a / b / c, signa / b) / c (Tx));
  • deputy member a After receiving the voting affairs, deputy member a encapsulates all Tx_PERMISSION and Tx_VOTE messages into the Pre-Block and sends it to all other member nodes.
  • 4Committees a, b, and c verify Pre-Block and send signatures SIGNa (Pre-header, 02:15:48), SIGNb (Pre-header, 02:15:55), SIGNc (Pre-header, 02:16:00), after the member node a receives it, it sorts the signatures according to the timestamp and writes it into the block header to generate R.
  • the maximum time stamp 02:16:00 is selected as the block time, and the genesis block is generated.
  • nodes d, e, f join the network, hoping to become housekeeper candidates and request recommendation letters from members a, b, c, and a, b, c verify their identity And return a recommendation letter response.
  • d After receiving the recommendation letter and consent signature returned by member c, he sent a recommendation letter to member a, b to obtain the consent signature of a. Therefore, d collected a total of the signatures of recommendation letters from member c, a. The number of signatures exceeded half of the members.
  • Tx_PERMISSION (user, bc, ⁇ SIGNc (letterc), SIGNa (letterc)>, d, signd (Tx)).
  • e, f also published Tx_PERMISSION (user, bc, ⁇ SIGNb (letterb), SIGNc (letterb)>, e, signe (Tx)) and Tx_PERMISSION (user, bc, ⁇ SIGNa (lettera), SIGNb (lettera) )>, f, signf (Tx)).
  • Members b and c receive the Pre-Block, and after verifying that they are correct, they send the signature of the Pre-Header to the steward B2: c, and update the score of the steward B2: c.
  • the block generator scores extra points, and the scores of the steward candidate list stored in the three member nodes are SCOREa ⁇ a: 0, b: 0, c: 1 ⁇ , SCOREb ⁇ a: 0, b: 0, c: 2 ⁇ , SCOREc ⁇ a: 0, b: 0, c: 2 ⁇ .
  • the voting results and the original voting affairs form a Pre-Block and are sent to all members.
  • the score list of each member node is SCOREa ⁇ a: 2, b: 2, c: 3 ⁇ , SCOREb ⁇ a: 2, b: 2, c: 4 ⁇ , SCOREc ⁇ a: 2, b: 2, c: 4 ⁇ .
  • the steward ⁇ B0: c, B1: d, B2: e ⁇ is responsible for encapsulating the blocks in turn.
  • 3 ordinary blocks and 1 special block are generated. .
  • the second and third rounds of consensus will show examples of invalid blocks due to signatures not exceeding half and timeout.
  • the member node deducts points for the behavior of the housekeeper c sending the block overtime.
  • the consensus mechanism is essentially a distributed consensus algorithm in a large distributed network that allows each node's data and status to agree. Therefore, the classic CAP theorem [73] and BASE theory [74] in distributed computing are often used to test Consensus algorithm.
  • CAP theory proves that a distributed system cannot meet the three basic requirements of consistency (C: Consistency), availability (A: Availability) and partition tolerance (P: Partition tolerance) at the same time, and can only meet at most two of them. Therefore, the existing distributed algorithms will basically make a trade-off between C and A, and thus the famous BASE theory is proposed.
  • BASE is the result of the consistency and availability trade-off in CAP. According to the distributed practice of large-scale Internet systems In summary, the core idea is that in the case that strong consistency cannot be achieved, distributed systems can achieve Basic Available (BA: Basically Available), weak state (S: Soft state), and eventual consistency (E : Eventually consistent).
  • BA Basic Available
  • S weak state
  • E Eventually consistent
  • Assumption 2 As member nodes in the alliance chain, member nodes use operating systems and configurations with higher security precautions, and members will not normally appear In the case of a single attack on the system, if any, members of this alliance will be expelled from the alliance soon, and the remaining alliance member nodes will repair the system's losses. Therefore, the alliance member nodes can be considered to be all credible.
  • Each member node may be an enterprise's internal cluster. A strong consistency algorithm such as Paxos is used inside the cluster to ensure synchronization and provide uninterrupted services to the outside. Therefore, it is unlikely that the alliance node will fail to work. Even so, CoV can tolerate that no more than half of the members' nodes are down, not working, or isolated by partitions. This will be analyzed in the security analysis.
  • Final consistency The final consistency emphasizes the copy of the blockchain data in all nodes in the blockchain system. After a period of synchronization, it can finally reach a consistent state, and CoV has consensus termination. Only one block confirmation is required to achieve the final confirmation and immutability of the transaction.
  • Availability refers to the fact that the consensus algorithm can make the services provided by the system in a usable state. For each operation request of the user, the results can always be returned in a limited time, and the operation of the consensus process can also be performed in a limited time. To produce a block, CoV can ensure that the housekeeper node produces a valid block smoothly and continuously under the proper parameter settings.
  • Partition tolerance poses a great challenge to distributed systems. It needs to be able to provide external services that meet consistency and availability when the system fails in any network partition. CoV can achieve a certain degree of partition tolerance, which satisfies partition fault tolerance in a case where a partition contains more than half of the members and at least one honest housekeeper.
  • Theorem 4.1 Under the assumption of the CoV model, the CoV consensus result can be completed in a limited time (termination).
  • the CoV consensus separates the execution right and check right of the generated block.
  • the execution right is given to the steward node and the check right is given to all member nodes. Only by obtaining the signature and consent of more than half of the member nodes can the block be legally and normally generate.
  • the condition that the block cannot be generated on time includes two points: (1) the steward node cannot generate the block; (2) the block generated by the steward node cannot be approved by more than half of the members. If any one of the conditions is established permanently, the CoV consensus will continue indefinitely, no block can be generated, and no systematic consensus can be reached.
  • condition (1) the CoV algorithm sets a rotation rule for the execution right. The steward must generate a valid block within the specified duty cycle Tb.
  • condition (2) is likely to be true. If hypothesis 2 and 4 are true, condition (2) is not true. Therefore, under the premise of the CoV model assumption, the CoV consensus result can be completed in a limited time, Theorem 4.1 holds, and the proof is complete.
  • this article Before proving Theorem 4.2, this article first uses a second mathematical induction method to prove a lemma. This lemma can supplement theorem 4.2. If Lemma 4.2 holds, and the system nodes maintain the same data with most of the members' nodes, the blockchain data finally maintained by different nodes is consistent and the decision results are the same, then Theorem 4.2 holds, and the proof is complete.
  • Lemma 4.1 When a block Blockh with height h and complete format and error-free appears in the system, it means that the transactions of Block0-Blockh-1 block have the final consistency and cannot be tampered with.
  • Block0 is a genesis block, and the genesis block is generated by a proxy member, and it is ensured that each member node signs the generation of a recognized block, so each member node will save the same genesis Block.
  • Block1 with complete format verification appears in the system, indicating that more than half of the member nodes have verified signatures on Block1's Pre-Block, which means that there is a set C, C that contains more than half of the member nodes
  • Lemma 4.2 is equivalent to the alliance chain generated by using CoV consensus. Invalid blocks may appear in the chain, but there will not be two forks. By default, the number of blocks in a fork is ⁇ 2. Proof Lemma 4.2.
  • Blockh + 1 and Blockh + 1 ' there are two different blocks, Blockh + 1 and Blockh + 1 '.
  • the parent block of Blockh + 1 is Blockh
  • the parent block of Blockh + 1' is Blockh ', assuming that the fork, Blockh and Blockh', are different blocks.
  • Blockh + 1 exists, it means that there is a set C that contains more than half of the members.
  • the Blockh stored in the nodes of C is the same. Based on this, the Pre-Block of Blockh + 1 is verified and signed, and the watchkeeper is on duty. Write to Final-Header of Blockh + 1.
  • Blockh + 1 ' exists, it means that there is a set C' containing more than half of the members.
  • the Blockh 'stored in the nodes of C' is the same, and on this basis, the Pre-Block of Blockh + 1 'is performed.
  • the signature was verified and written by the watchkeeper into the Final-Header of Blockh + 1 '.
  • a simple example can illustrate the characteristics that CoV does not fork and can be confirmed with only one block.
  • the system generates a legal block at time T0, and members C1, C2, and C3 own the block.
  • T0- T0 + Tb
  • the steward i is the steward on duty for C1, C2, and C3, so the Pre-Block generated by it is returned to verify the signature.
  • the Final-Block released by butler i only reached C1, the block time was T1, and it failed to reach C2 and C3 in time.
  • the steward on duty is the steward j for C1
  • the steward on duty is the steward i + 1 for C2 and C3, so the member C1 will only send it to the steward j
  • Pre-Block returns the verification signature.
  • Members C2 and C3 will only return the verification signature to the Pre-Block sent by the housekeeper i + 1.
  • the Final-Block time generated by the housekeeper i + 1 is T2.
  • the steward on duty for C1 is the steward j + 1
  • the steward on duty for C2 and C3 is the steward i + 2.
  • the CoV algorithm can ensure that each member node in the alliance chain provides the same external decision or service.
  • the client sends a request to a member of the alliance chain system to read the latest block data
  • this member sends a request for the highest block height to other members, as long as the highest block data ⁇ Height, Hash> and more than half of the members If the nodes are the same, the data of the block Height can be sent back to the client. For any member node, the result returned to the client is the same, so the inference is valid and proven.
  • the steward node In order to become a steward through layer-by-layer recommendation and competition, to obtain bookkeeping rights, and to receive corresponding rewards, the steward node must remain online for the maximum time, work honestly in accordance with the provisions of the alliance agreement, and complete the responsibility of encapsulating blocks within a limited time .
  • CoV consensus can realize the activity of the consensus mechanism and continue to generate valid blocks.
  • the housekeeper node in CoV can generate legal blocks more and more effectively after the survival of the fittest.
  • This article models the voting process and introduces a scoring mechanism and a reward mechanism to fully explain and prove that the reliability of the steward is controllable.
  • Two parameters can be used to adjust the reliability and activity of the steward's work: the number of votes cast by members And housekeeping gains.
  • Nc members voted for Nb stewards from among Nbc steward candidates. Assuming Nbc ⁇ Nb, this process can establish a mathematical model of voting to study how many votes each member has cast at least to select a reasonable butler list, so that this list can get the consent of half of the members and promote the success of special blocks. generate.
  • the model does not consider the impact of the scoring mechanism. Assume that the members' voting list is random and there are no abstentions. Each member has voted K, that is, a voting list containing K node addresses is given. Then each candidate receives one from one member. The votes have the same probability, K / Nbc, and the voting activity obeys the binomial distribution principle:
  • the average number of votes obtained by each elected steward exceeds half of the number of members Nc / 2.
  • the setting of Nc / 2 is to allow the voting results to be approved by half of the members, so that special blocks can be successfully generated. , This probability is P1.
  • Nb stewards need to be selected from among Nbc candidates, the probability of success for a candidate is P2.
  • Equation (4.4) the minimum K value that satisfies equation (4.4) is the optimal number of votes.
  • Matlab to draw the images of P1 and P2, as shown in Figure 40.
  • the abscissa is K and the ordinate is the probability value. It can be seen that the value of the intersection of the curves is the optimal value of K.
  • the honesty factor ⁇ is used to represent the deviation between the probability that the node gets a member's vote and the average probability. Then the probability of a candidate being elected as a steward is:
  • ⁇ > 0 indicates that the candidate has a higher probability than the average
  • ⁇ ⁇ 0 indicates that the candidate has a lower than average probability
  • the housekeeper node has a probability of profit when ⁇ (R i )> 0, so each housekeeper candidate node can establish a bankruptcy model. If a node's income in the process of participating in the bookkeeping consensus has not been able to cover its costs in the long-term waiting for bookkeeping, the housekeeper is said to be in bankruptcy and will withdraw from the network because it cannot make ends meet.
  • the ruin probability of a node i participating in the campaign for steward is:
  • the setting of the incentive mechanism can also effectively limit the number of candidates in the system.
  • the system's income setting for the housekeeper package block must meet the following conditions, otherwise most housekeepers will make ends meet and make ends meet.
  • the number of housekeepers is reduced, which affects the security of the system, so the setting of wages needs to satisfy ⁇ (R i )> 0 in equation (4.9), that is:
  • the revenue B of the encapsulation block can be set according to the number of candidates expected by the system, which means that by regulating the revenue B, the number of candidates expected in the system can be regulated.
  • the probability pi of candidate i's gain is less than the average level, and the nodes that join the system later may get a lower honesty factor. If there are too many candidates in the system, there must be candidate nodes to make ends meet, because the revenue cannot cover the cost of waiting for the encapsulation block, which leads to bankruptcy and exits the candidate, thereby effectively controlling the number of housekeepers and improving the quality of the butler. Motivation. Therefore, it can be proved that Lemma 4.3 is valid.
  • Double spend attack In the transaction of the blockchain, taking Bitcoin as an example, a transaction is equivalent to a transfer transaction tx. tx has inputs and outputs. The input is equal to a bitcoin balance that has not yet been spent, and the output from a previously confirmed transaction. The tx output is the amount of the address that has been converted after the transaction is confirmed, as a new one. The amount of unspent Bitcoin becomes UTXO (Unspent Transaction Output). A UTXO can only be used for the input of a new transaction at one time. If two different transactions use the same UTXO as an input, the situation where these two transactions are on the chain at the same time is called a double spend attack. . To extend, if two contradictory and non-coexisting transactions exist on the blockchain at the same time, it is said that this blockchain has suffered a double spend attack, which poses a great challenge to the security of blockchain data.
  • UTXO Unspent Transaction Output
  • the double-spend attack is still a serious loophole in the public chain consensus algorithm. Since the public chain algorithm has no regulatory organization, the consensus algorithm relies on uncontrollable public awareness to compete for bookkeeping rights. Especially in the Nakamoto consensus, when malicious nodes have large computing power, illegal transactions can also be encapsulated into the blockchain, and an attack on double-spend transactions is inevitable. Users in the network need to wait for the confirmation of multiple blocks to increase the credibility of transactions that have been credited to the blockchain. Transactions have no final confirmation. When the malicious node's computing power exceeds 50%, the number of blocks can be forcibly added to the wrong fork to become the longest chain recognized throughout the network, making its blockchain system no longer reliable.
  • CoV can automatically avoid double spending attacks, and even in the case of system accounting errors, through the consultation of more than half of the members, a new transaction can be added to fill the impact of previous accounting errors.
  • CoV can greatly play The role of the alliance greatly improves the safety and reliability of the system.
  • Selfish mining performs differently in different consensus algorithms [71-72] .
  • selfish mining is a damage to consensus fairness in order to win higher returns in the consensus process without compromising the correctness of the system.
  • sexual behavior Since the accounting nodes of the CoV consensus are randomly assigned, and the steward nodes also need to be continuously rotated through elections, CoV does not exist in the Nakamoto consensus by "hoarding" blocks to obtain higher consensus returns.
  • the CoV consensus process due to the added incentive mechanism, there is also the possibility of selfish mining attacks to a certain extent.
  • the R set collided is If The attacker's ID exists in the attacker, and the attacker can become the next steward on duty and normally generate blocks to earn bookkeeping income. With a very low probability, the attacker will likely occupy the role of steward on duty for a long time, producing blocks to get more revenue.
  • a ⁇ B the steward (attack) number of the steward is Bj
  • the attacker Bj can collect the signatures of all the members every time, and Q is arranged in ascending order of C_time.
  • the maximum “collision R” combination is Qn (1, k) ⁇ Q1 (k + 1), Nc / 2 ⁇ n ⁇ k ⁇ Nc, unless otherwise specified, c / 2 in this model (c is a positive integer)
  • the result is generally rounded down.
  • the best strategy for a "collision R" attack is to first select a Q1 (k + 1) in Q that satisfies k ⁇ Nc / 2 as the signature with the largest C_time in the member list of Final-Block.
  • n signature sets Qn (1, k) from Qk (1, k), satisfying n ⁇ Nc / 2, that is, the C_time of the elements in Qn (1, k) are less than Q1 (k + 1), so that The number of signatures that can be written in the Final-Block member's signature list Qn (1, k) (Q1 (k + 1) ⁇ Nc / 2 + 1, and the maximum C_time can be specified as Q1 (k + 1) Element of
  • n + 1 ⁇ Nc / 2 + 1.
  • the steward (attacker) Bj on duty can specify the value of Q1 (k + 1) to get a result set of different "collisions R" Because k ⁇ Nc / 2 and k + 1 ⁇ Nc, there are at most Nc / 2 possibilities for Q1 (k + 1). That is, Bj can have Nc / 2 chances to recalculate the random number R in order to get one.
  • n is sufficiently large (in the normal approximation of a binomial distribution, "n is sufficiently large” is generally considered to be n ⁇ 50), the approximation is
  • the optimal value of the number of housekeeper nodes Nb can be set, that is, the success probability p of the selfish mining attack can be reduced to a minimum value of Nb below 0.01. Based on this, it can be based on:
  • the corresponding value of the number of members and the number of housekeepers is obtained.
  • the number of Nb can be rounded up to ten or one hundred equivalents.
  • Table 4.2 gives an example. When the number of members is known, it can be found by checking the table. The corresponding Nb when Nc is in a certain interval makes it unnecessary to frequently change the number of housekeepers set by the system when the number of members changes slightly.
  • the left diagram in Figure 43 shows that when the number of members Nc is fixed, the larger the number of housekeepers Nb, the greater the probability of "collision R" failure, the lower the success rate of selfish mining, and the higher the safety.
  • Analyzing the contour map shown in the right figure we can see that the contour lines of the graph are linearly distributed, that is, when the number of members Nc and the number of housekeepers Nb show a certain proportional relationship, the size of P (collision R failure) can be kept equal.
  • P collision R failure
  • the contour map of the 3D model is projected onto the xy plane. It can be seen that when Nb / Nc is about 1000/300 in the left figure, P (collision R failure) will reach a very high value. By further expanding the ratio of the x-axis and the y-axis, it can be seen more clearly that the effect of Nb / Nc on the distribution of P (collision R failure) is about 3-4 times, as shown in Figure 44.
  • a new algorithm can also be set to identify the bad behavior of the housekeeper, reduce the penalty for the malicious behavior of the housekeeper, increase the probability of bankruptcy of the malicious node, and enhance the robustness of the system.
  • the witch attacker controls most of the steward and steward candidate nodes as multiple virtual machines, the system will also face great danger.
  • the witch attack only poses a great threat to the public chain without permission.
  • the witch attack cannot play its original role.
  • CoV is set for the alliance chain scenario.
  • all participating nodes will verify node identity through identity verification and digital certificate distribution, ensuring the principle of one node and one vote in the alliance chain system, thereby effectively avoiding Witch attack.
  • CoV can achieve the characteristics of non-tamperable transaction confirmation with only one block, ensuring that its performance is not restricted by security; compared with the well-known PBFT consensus algorithm when the total number of nodes is N Reaching the message complexity of O (N2), the complexity of CoV's two-phase commit communication is only O (3Nc), which is only affected by the number of member nodes, and theoretically can achieve better performance.
  • CoV does not need to consume a lot of computing power, nor will it promote the emergence of dedicated mining circuits (ASIC). Therefore, using CoV consensus in the alliance chain can avoid unnecessary energy waste.
  • CoV consensus supports the regular rotation of consensus nodes, which greatly avoids the problem of distributed single points of failure and can also effectively prevent the system from being controlled by an attacking node for a long time.
  • CoV is under the control of all alliance nodes.
  • the government and the regulators can be properly involved in the supervision. If there are illegal matters that need to be changed, only the consent of more than half of the members at the government level can be released to issue special amendments to correct the existing erroneous data. Therefore, CoV can not only adapt to the top-down supervision, but also adapt to the bottom-up correction of the blockchain system, and has flexible supervision.
  • NS3 Simulation platform
  • NS3 Network Simulator Version 3
  • NS3 is a discrete random event-driven network simulator. It has detailed network modules and routing protocols. It is a real simulation of actual engineering applications. Because it is purely programmed in C ++ and cooperates with a complete underlying design, its simulation results are closer to the actual project.
  • NS3 inherits the latest network standard protocols and can be used for almost all network simulations today.
  • NS3 consists of five types of network components: Node, Application, Network Device, Channel, and Topology generator [25].
  • the basic computer equipment in NS3 is abstracted as a Node, which is described by the NodeContainer class, which provides multiple methods for managing computer equipment.
  • Channel refers to the data stream transmitted through the medium.
  • Network device Network device refers to the hardware and network card drivers on the Internet.
  • Application The Application class is used to describe an application running on a computer node Node. It provides various methods for managing user-level applications during the simulation process, and can be used by developers to customize and create new applications using object-oriented methods.
  • the NS3 simulator kernel mainly includes two parts, one is responsible for time scheduling, and the other is responsible for system core support. Time scheduling includes default scheduling and real-time scheduling.
  • the support system mainly includes attribute Attribute, logging system, Logging system, and tracking system Tracing system. .
  • NS3 has good maintainability, flexible architecture, and complete documentation. It complies with the open source (GPL) protocol and is mainly used as a simulation tool in research. It excels in simulation speed and accuracy.
  • GPL open source
  • the simulation steps of NS3 script are generally as follows:
  • Define the parameters used in the simulation which can be established by using command line classes to dynamically change the parameters used in the simulation, such as the number of nodes, the transmission frequency of data packets, the size of data packets, routing protocols, and so on.
  • the CoV blockchain simulation system built on the NS3 simulation platform mainly includes a global IPv4 address generation module, a P2P link topology networking module, a network message propagation module, a transaction generation module, a block generation module, and a message creation module. , Key management module and CoV consensus module.
  • the construction of the relevant part of the underlying network refers to the work of the Bitcoin simulation simulator built by Gervais [27] and others, as shown in Figure 50.
  • Ipv4AddressHelperCustom class is used to implement a simple Ipv4 address generator. It calls part of the implementation of the Ipv4AddressGenerator class in NS3 and calls the global address generator to ensure that there is no duplicate address generation.
  • P2P link topology networking module The links between nodes in the system are implemented by directly creating point-to-point channels, eliminating all other intermediate devices such as routers and switches.
  • the characteristics of the point-to-point channel can be simulated by the NS3 simulator for the delay and bandwidth of the channel Channel class Delay and DataRate parameters.
  • the emulator is consistent with the underlying network settings of the Bitcoin emulator created by Gervais [27] and others.
  • the simulator uses Verizon's global IP delay statistics message [30], assuming that Pareto traffic distribution accounts for 20% of the average delay [31].
  • Network message propagation module Since all nodes are peers in the P2P system, all blocks need to be received, so a broadcast protocol is required. In the Bitcoin network, miners can improve the robustness and scalability of the network through the relay network. The CoV simulator only considers the most basic broadcast protocol to ensure the feasibility and effectiveness of the protocol.
  • the API for message propagation is encapsulated in the blockchain_network class.
  • Transaction generation module The transaction generation module is implemented in the CoVTransaction class. By setting the transaction data Data and metadata MetaData, it simulates identity permission conversion transactions, special voting transactions, and ordinary transactions (user-defined transactions) in CoV. Among them, the generation rate of common transactions VGen can be adjusted by the probability that a node generates a common transaction PGen. Increasing the probability of generating a common transaction can achieve high-speed transmission of transaction data to the consensus module, which can be controlled by PGen, and is used to test the consensus module's confirmation of transaction processing. Delay and TPS for the entire system.
  • Block generation module CoVHeader class, CoVBlock class and CoVBlockChain class are used to simulate the generation of block data, especially the data generation process of Pre-Block and Pre-Header in CoV.
  • Message creation module All messages used by the CoV simulator are defined in the MessageManager class, and the creation functions of requests and responses are implemented.
  • Key management module implemented in the KeyManager class. The method of generating and managing secret and public keys, and encryption and decryption are realized. Among them, the SHA256, RSA, and elliptic hyperbolic secp256k1 encryption algorithms needed in the blockchain use the mbedTLS code library [29], written in the C programming language, without external dependencies, and is a compact ssl code library that is easy to port and Compile.
  • CoV consensus module This module is the key to the CoV simulator system. It is responsible for the consensus confirmation of transactions and blocks, and the processing of messages and transactions. Through the CoV class, each node stores the configuration and data of the complete blockchain and memory pool.
  • the account class and AccountManager class implement the network identity model in the CoV model.
  • the key class of the CoV system is the execution component of the CoV algorithm. Its performance directly determines the test results of the system's delay and throughput.
  • the functional design of the CoV consensus execution module refers to the algorithm description in Chapter 3.
  • Table 5.1 shows the independent variables and their descriptions in the test experiments. It should be noted that the size of the maximum common transaction number of the block Txpbmax and the length of the transaction content Txsize can determine the upper limit of a block size.
  • Throughput is defined as the amount of data that is successfully transmitted per unit time between nodes (devices, ports, virtual circuits, or other facilities) in the network (transmission units are mostly bit, byte, and packet).
  • throughput is a very important indicator for measuring the system's concurrency capability. It is mainly used to measure the system's ability to process transactions and requests per unit of time. It is expressed in throughput, and the unit is tps, which is the number of transactions per second (Transaction Per Second).
  • the transaction throughput in the blockchain can be calculated by counting the total number of transactions per unit time from the time the transaction is issued to the time it is written to the block and it is confirmed that it cannot be tampered with, as shown in formula (5.1), where ⁇ t is a certain time interval of the system.
  • the delay in the blockchain is different from the definition of the delay in the packet switching network.
  • the delay in the blockchain mainly refers to the transaction delay, which is closely related to the throughput.
  • the delay time in this paper in the test refers to the time interval between a common transaction (issued by a node in the system at a certain adjustable rate) from being sent by the client to being written into the blockchain confirmation.
  • the delay indicator is used to measure the transmission performance of the blockchain system and the running time of the consensus algorithm. The lower the delay, the faster the transactions in the blockchain network are confirmed, the less time users have to wait for the transaction to be successful, and the experience Better means faster blockchain system response.
  • the delay indicator in the blockchain can be calculated by dividing the sum of the time difference between the issue and confirmation of a large number of transactions by the total number of transactions to obtain the average value of transaction delays, as shown in formulas (5.2) (5.3).
  • n represents the number of transactions being counted
  • Ttransfer is the transmission time of transactions from a node to broadcast to the network
  • Tconsensus represents the execution time of the consensus algorithm
  • Tcomfirm represents the time from when the consensus algorithm is executed to the block containing the transaction.
  • the confirmation time it takes to get a block confirmation in the network means that more than half of the members received a Final-Block containing this transaction. According to whether Tcomfirm is included, Delay tx can be divided into the delay delay pack and confirmation delay delay of the transaction .
  • Excluding the delay pack containing Tcomfirm represents the delay of the transaction from being generated to being encapsulated into a block.
  • Tc takes the block time of the firm;
  • Delay comfirm which includes Tcomfirm, represents the confirmation delay from when the transaction is generated until it is confirmed to be tamper-resistant.
  • Tc takes the next block time of the firm.
  • the default transaction size is the same as that of Bitcoin, which is 250 bytes.
  • the main research is to keep the ratio of the number of members and the number of stewards consistent with the changes in the number of blocks, Ball, node Nall, transaction number PGen, consensus wait number Td and Tb At the same time, the impact of changes in system throughput and latency will also be explored on the impact on consensus performance when the ratio of the number of members to the number of stewards changes.
  • the CoV simulator can modify the underlying network configuration such as link bandwidth and delay. Due to the limited hardware resources (memory), this section uses better high-bandwidth and low-latency Configuration, in the selection of the number of nodes, a small number of nodes are also representatively tested to calculate the rough parameter ratio; in the feasibility test, low-bandwidth and high-latency network transmission parameters across five continents are used in the real network. Shows the adaptability of CoV nodes to long-distance and wide-range point-to-point networks. Because this experiment is a simulation measurement experiment, it can better demonstrate the feasibility and effectiveness of the algorithm, but because the actual network parameters are complex and changeable, the actual hardware resources are also superior to the simulated hardware resources, so the algorithm performance test For reference only.
  • the test is mainly to fully test the feasibility of the CoV process.
  • the simulator randomly assigns each node a number of connections greater than 5 and less than 15. Set realistic bandwidth distribution for each point-to-point connection according to the area to which each node belongs (ASIA_PACIFIC, EUROPE, NORTH_AMERICA, SOUTH_AMERICA, JAPAN, AUSTRALIA, OTHER).
  • the test of the CoV simulator is run at a bandwidth of 10Mbps, so that the running nodes belong to the ASIA_PACIFIC region, which is more suitable for the application scenario of the alliance chain, and is a node A delay of 0.1s is added between each link. Assume that a block does not exceed 0.5MB, a block is generated in 10s, and a transaction is 250Byte. In the CoV test, in order to improve memory utilization, a block does not exceed 2000 transactions. Each test sets a different rate of common transactions, that is, The rate at which ordinary transactions occur.
  • the change in throughput is basically consistent with the transaction generation rate.
  • the steward produces a block every 10s. Since the maximum number of block transactions is 2000, the transaction generation rate exceeds 320 tps. When you can clearly see that the system throughput is limited (not more than 200tps).
  • Analyzing the special blocks with heights of 20 and 40 we can find that the throughput of the block is 0 (excluding any ordinary transactions) at the special block.
  • the throughput curve of the first block after the special block is: An obvious spike, because the first housekeeper in the next term can collect the number of transactions between the two block intervals, which is more than the number of transactions that can only be collected with a delay of 10s.
  • the system throughput varies. The characteristics are consistent with theoretical analysis.
  • Equation (5.2) is set to delay the transaction, simulator experiments two types of delay can be obtained, one is the average delay Delay pack transaction is encapsulated into blocks, the transaction is confirmed and the other is Delay comfirm is the average delay that cannot be tampered with.
  • n be the total number of transactions generated from the genesis block to the end of the CoV simulator.
  • Tp be the time of transaction generation in the metadata of the transaction.
  • Tc is the generation time of the transaction in the block
  • calculate ⁇ (T c -T p ) can get the Delay pack ; if Tc is the generation time of the next block of the transaction in the block (when the next block appears, the transaction can be confirmed as tamper-proof), by calculating ⁇ (T c -T p ) can get Delay comfirm .
  • the average transaction delay statistics are obtained.
  • FIG 57 shows the transaction generated at different rates and different circumstances node size, and the package delay Delay pack acknowledgment delay Delay comfirm transaction.
  • the average package delay of a transaction is 9.34s
  • the average confirmation delay of a transaction is 21.46s.
  • the Delay pack contains the transaction consensus time Tconsensus and the propagation time Ttransfer in the network
  • the Delay comfirm also includes the transaction confirmation time Tcomfirm on the basis of the Delay pack .
  • Tcomfirm is approximately equal to the block generation interval of a block interval ⁇ 12.12s.
  • the time Td of the watchkeeper block waiting to collect transactions is set to 10s, and the block output interval also fluctuates around 10s, interval ⁇ Tcomfirm ⁇ 10s, and the test results are consistent with theoretical calculations.
  • the time for the block to propagate in the network also includes the residence time in the memory pool of the watchkeeper, Ttransfer ⁇ Td, so it can be estimated that the CoV consensus time Tconsensus can be completed in a few seconds.
  • Ttransfer ⁇ Td the residence time in the memory pool of the watchkeeper
  • the CoV consensus time Tconsensus can be completed in a few seconds.
  • the transaction generation rate VGen and the node size Nall have relatively small effects on the encapsulation delay and the confirmation delay, and do not show a certain increase and decrease law.
  • the Delay pack and Delay comfirm both fluctuate around their average. To some extent, it illustrates the scalability of CoV.
  • Figure 58 shows the effect of the wait time Td on the delay before the housekeeper performs the consensus step during the duty cycle.
  • Td For the packaging delay, similar to the effect of Td on the throughput of Figure 55, as Td increases, the amount of transactions that can be collected by the block gradually increases, the throughput increases, and the delay decreases. However, when Td exceeds a certain size, the remaining time left for the steward to reach consensus during the duty cycle gradually decreases, the easier it is to cause the steward on duty to change and increase the delay of transaction encapsulation.
  • Tcomfirm an increase in Td will reduce the block generation rate and affect the final confirmation time of the transaction, Tcomfirm.
  • Td is relatively low, lowering Td will reduce the number of transactions that can be collected by the block, so Td needs to be adjusted to a suitable
  • the size is about 5s to ensure the maximum throughput and latency performance.
  • the simulation test of the CoV algorithm was implemented.
  • the NS3 simulation platform was used to simulate the real network transmission environment as much as possible.
  • the test results show that CoV can operate normally in the NS3 network environment and generate genesis blocks, ordinary blocks, and special blocks.
  • an evaluation model is established for the two most important performance parameters of the consensus algorithm-throughput and delay.
  • the throughput of CoV measured for different transaction generation rates increases as the transaction generation rate increases, and it can smoothly handle new transactions in the network.
  • the block interval is about 5 seconds.
  • the average delay of the CoV transaction being encapsulated in the block is 6.26 seconds, which is confirmed as impossible.
  • the average tampering delay is 12.74 seconds, which is comparable to the existing consensus mechanism, and can also meet the application requirements of real blockchain systems, especially the alliance chain.
  • alliance nodes are allowed to fully control the generation and confirmation of transaction data.
  • the controllability of the system is reflected in the fact that only half of the members need to agree to maintain the data on the chain and provide it to auditors Required data.
  • CoV can achieve throughput processing in accordance with the transaction generation rate.
  • the transaction confirmation delay can reach 12.74s, which is better than most existing consensus mechanisms and meets the application requirements of the alliance chain.
  • CoV guarantees the security of the system through the credibility of the alliance member nodes. There is no need to compete through Nakamoto consensus computing power. Electricity and energy consumption are only used to limit candidates in the butler bankruptcy model established in this paper. The number of people is almost negligible compared to PoW.
  • CoV allows less than half of the member nodes to fail to work, allows no less than 1 housekeeper node to do evil, and uses the characteristics of the alliance chain to establish a security model to maximize the security of CoV.
  • CoV In terms of consensus, CoV only needs to achieve the confirmation of more than half of the members in the network to reach the consensus of the block.
  • the consensus has ultimate consistency, and the final validity of the transaction can be confirmed only by waiting for one block.
  • Each district Blocks are final.
  • the final decision of the system nodes is consistent with more than half of the member nodes, and the consistency of the system can be achieved.
  • transaction confirmation is faster.
  • the election of the steward node reduces the communication overhead, which can reflect the efficiency of CoV.
  • this article further studies and analyzes the correctness and security of CoV, and proves that CoV's ultimate consistency and limited partition tolerance, and CoV applied to the permission chain in terms of security Resistant to double-spend attacks and witch attacks common in blockchain systems.
  • this article models and analyzes the activity of the most important steward role in the consensus and the possibility of selfish mining.
  • the results show that under the setting of a reasonable number of voting votes and the butler's income, the butler node can realize survival of the fittest according to honesty and activity, and maintain the honesty and reliability of the butler node team.
  • CoV algorithm can be kept 99% resistant to selfish mining attacks.
  • the simulation implementation also further shows that the throughput and latency of the consensus algorithm are affected by the transaction generation rate, node size, and CoV consensus switching parameters, but overall the performance is stable.
  • the proposed new consensus mechanism has a certain theoretical contribution and practical significance for the research of blockchain technology and distributed consistency theory that are currently in the research hotspot, and provides an alternative consensus solution in promoting the application of the alliance chain. Has certain application prospects.
  • due to the time factor there are still some shortcomings in the design of this article. Future work can try further attempts from the following aspects.
  • the CoV consensus mechanism is highly scalable and controllable, and the consensus protocol can be modified. After the proposal has been signed and approved by the majority of the members, it can be packaged into the blockchain and the blockchain protocol can be easily updated. There are two points regarding the direction of the agreement improvement. The first point is that the voting rights of alliance members can be based on the shareholdings of members, so that the voting system can reflect the changes in the discourse weight of each alliance member as much as possible, closer to the real world. Application; The second point is that when the alliance chain system is implemented, the judging conditions for the members and the blocks of the member nodes can be customized, so that the blockchain can intelligently reject certain illegal transactions in reality.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de consensus à base de vote, comprenant les étapes suivantes : S1, sélectionner un intendant en service, et l'intendant en service détermine si un bloc à venir est un bloc spécial ; S2, l'intendant en service envoie un prébloc produit à tous les nœuds membres et attend les signatures des membres, et détermine si le nombre de signatures de vérification de nœud membre reçues par l'intendant en service est supérieur à la moitié du nombre de membres ; S3, déterminer si un bloc valide a expiré ; et S4, déterminer si le bloc valide est un bloc spécial. En termes de réglementation de conformité, des nœuds d'alliance sont autorisés à commander complètement la production et la confirmation de données de transaction. Par comparaison avec un algorithme de chaîne publique, le contrôle du système est reflété dans la nécessité d'avoir seulement la moitié des membres pour accepter de maintenir des données sur une chaîne et de fournir à un auditeur les données requises.
PCT/CN2018/090453 2017-05-16 2018-06-08 Procédé de consensus à base de vote WO2019232789A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201880004219.5A CN109964446B (zh) 2018-06-08 2018-06-08 一种基于投票的共识方法
PCT/CN2018/090453 WO2019232789A1 (fr) 2018-06-08 2018-06-08 Procédé de consensus à base de vote
US16/361,067 US20190220768A1 (en) 2017-05-16 2019-03-21 Constructing topology for satisfying partition tolerance in consortium blockchain consensus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/090453 WO2019232789A1 (fr) 2018-06-08 2018-06-08 Procédé de consensus à base de vote

Related Child Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/084431 Continuation WO2018209542A1 (fr) 2017-05-16 2017-05-16 Procédé consensuel pour système de nom de domaine décentralisé

Publications (1)

Publication Number Publication Date
WO2019232789A1 true WO2019232789A1 (fr) 2019-12-12

Family

ID=67023434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/090453 WO2019232789A1 (fr) 2017-05-16 2018-06-08 Procédé de consensus à base de vote

Country Status (2)

Country Link
CN (1) CN109964446B (fr)
WO (1) WO2019232789A1 (fr)

Cited By (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251527A1 (en) * 2018-02-14 2019-08-15 Christopher Walter Surdak System, Method, and Computer Program Product for a Distributed, Cryptographically Secured Proof-of-Intent Transaction Network
CN111083221A (zh) * 2019-12-13 2020-04-28 北京菲林方德科技有限公司 一种交易验证方法及装置
CN111125131A (zh) * 2019-12-16 2020-05-08 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法
CN111159299A (zh) * 2019-12-31 2020-05-15 预言机(重庆)科技有限公司 一种区块链的上链方法
CN111179087A (zh) * 2019-12-31 2020-05-19 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111182510A (zh) * 2020-01-09 2020-05-19 重庆邮电大学 一种基于区块链的工业物联网节点共识方法
CN111190862A (zh) * 2019-12-28 2020-05-22 广州创想云科技有限公司 区块链的实现方法
CN111199504A (zh) * 2019-12-29 2020-05-26 杭州拓深科技有限公司 一种基于区块链的去中心化消防维保监管方法
CN111242618A (zh) * 2020-01-08 2020-06-05 成都库珀区块链科技有限公司 一种基于区块链合约技术的私钥保管方法及装置
CN111242619A (zh) * 2020-01-09 2020-06-05 厦门顺势共识信息科技有限公司 引入监管机制的联盟链共识方法、区块链网络及存储介质
CN111275554A (zh) * 2020-01-22 2020-06-12 北京瑞卓喜投科技发展有限公司 一种证券型通证的交易方法和系统、存储介质
CN111291965A (zh) * 2020-01-06 2020-06-16 北京时代天鉴科技发展有限公司 一种基于员工互评数据挖掘不同目标团组的系统
CN111311414A (zh) * 2020-02-27 2020-06-19 杭州云象网络技术有限公司 一种基于一致性哈希算法的区块链多方共识方法
CN111414433A (zh) * 2020-05-09 2020-07-14 北京阳光欣晴健康科技有限责任公司 基于区块链和密文检索技术的分布式随访系统
CN111522561A (zh) * 2020-03-06 2020-08-11 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN111556133A (zh) * 2020-04-26 2020-08-18 布比（北京）网络技术有限公司 区块链共识方法、系统及计算机存储介质、电子设备
CN111563278A (zh) * 2020-05-09 2020-08-21 电子科技大学 一种改进的股权授权证明方法
CN111612472A (zh) * 2020-06-10 2020-09-01 上海黔链科技有限公司 一种区块链权威节点授权共识算法
CN111626722A (zh) * 2020-06-01 2020-09-04 中国联合网络通信集团有限公司 一种跨境支付方法及装置
CN111639124A (zh) * 2020-04-29 2020-09-08 西安电子科技大学 安全时间同步方法、系统、存储介质、程序、智能设备
CN111711526A (zh) * 2020-06-16 2020-09-25 深圳前海微众银行股份有限公司 一种区块链节点的共识方法及系统
CN111723406A (zh) * 2020-06-08 2020-09-29 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN111858768A (zh) * 2020-07-27 2020-10-30 苏州区盟链数字科技有限公司 一种优化区块链可信节点与共识算法的装置
CN111861505A (zh) * 2020-06-28 2020-10-30 石家庄铁道大学 基于区块链的农产品溯源方法
CN111917826A (zh) * 2020-06-23 2020-11-10 海南大学 一种基于区块链知识产权保护的pbft共识算法
CN111913833A (zh) * 2020-06-28 2020-11-10 华南理工大学 一种基于区块链的医疗物联网交易系统
CN111930698A (zh) * 2020-07-01 2020-11-13 南京晓庄学院 基于哈希图和联邦学习的数据安全共享的方法
CN112039964A (zh) * 2020-08-24 2020-12-04 大连理工大学 一种基于区块链的节点信誉共识方法
CN112100278A (zh) * 2020-09-17 2020-12-18 重庆大学 一种基于私有链的智慧系统数据监管方法
CN112217683A (zh) * 2020-11-02 2021-01-12 西安西电链融科技有限公司 跨异构链数据可达性处理方法、系统、介质、设备、终端
CN112398640A (zh) * 2020-11-13 2021-02-23 华南农业大学 一种优化的区块链共识算法
CN112434343A (zh) * 2020-11-25 2021-03-02 江西理工大学 一种基于双重区块链技术的虚拟电厂安全调度与交易方法
CN112733204A (zh) * 2021-01-16 2021-04-30 阳江市链点创新科技发展有限公司 一种基于区块链和多重签名技术的防伪溯源方法
US20210142418A1 (en) * 2018-10-22 2021-05-13 Panasonic Intellectual Property Corporation Of America Control method, fund management system, recording medium, and data structure
CN112801791A (zh) * 2021-01-29 2021-05-14 武汉大学 一种基于授权的区块链共识方法及系统
CN112819433A (zh) * 2021-02-01 2021-05-18 北京工业大学 一种用于协同政务区块链的共识方法
CN113052596A (zh) * 2019-12-28 2021-06-29 中移(成都)信息通信科技有限公司 基于区块链的出块方法、装置、设备和介质
CN113114620A (zh) * 2021-03-02 2021-07-13 深信服科技股份有限公司 一种暴力破解的检测方法和装置，及存储介质
CN113111373A (zh) * 2021-05-13 2021-07-13 北京邮电大学 Vbft共识机制的随机数生成方法和共识机制系统
CN113254526A (zh) * 2021-03-02 2021-08-13 中国信息通信研究院 区块链共识方法、装置及系统
CN113591161A (zh) * 2021-08-19 2021-11-02 北京优品三悦科技发展有限公司 一种联盟链管理方法、装置、设备及存储介质
CN113708968A (zh) * 2021-08-27 2021-11-26 中国互联网络信息中心 区块链的节点选举控制方法和装置
CN113722545A (zh) * 2021-06-30 2021-11-30 电子科技大学 一种许可链环境下的数据编校方法
CN113949709A (zh) * 2021-10-13 2022-01-18 甘肃同兴智能科技发展有限责任公司 一种提高区块链网络安全性的共识方法及系统
CN114065283A (zh) * 2020-11-20 2022-02-18 北京邮电大学 一种轻量级可循环再生的区块链存储方法及装置
CN114095209A (zh) * 2021-10-27 2022-02-25 中通服中睿科技有限公司 一种基于权重激励主节点选举的联盟链共识方法及系统
CN114089744A (zh) * 2021-11-01 2022-02-25 南京邮电大学 一种基于改进Raft算法选择车辆队列领航车的方法
CN114189522A (zh) * 2021-10-15 2022-03-15 敏博科技(武汉)有限公司 一种车联网中基于优先级的区块链共识方法及系统
CN114189325A (zh) * 2021-11-19 2022-03-15 新疆大学 具有高容错可扩展的拜占庭容错方法、装置及存储介质
CN114258015A (zh) * 2021-12-23 2022-03-29 成都三零瑞通移动通信有限公司 一种基于全网共识的集群终端防失控方法及系统
CN114301928A (zh) * 2021-11-29 2022-04-08 之江实验室 一种基于sgx的链上链下混合共识方法及系统
CN114385647A (zh) * 2021-12-15 2022-04-22 达闼科技（北京）有限公司 联盟链出块方法、装置、电子设备及介质
CN114401099A (zh) * 2021-08-17 2022-04-26 同济大学 一种基于网络拓扑的区块链PoW自私挖矿攻击防御方法
CN114422155A (zh) * 2022-03-30 2022-04-29 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质
CN114444090A (zh) * 2021-12-17 2022-05-06 中国科学院信息工程研究所 一种高效的秘密唯一领导人选举方法
CN114466024A (zh) * 2022-02-21 2022-05-10 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 基于新型PoM共识算法的分布式账本系统及方法
CN114584312A (zh) * 2021-10-09 2022-06-03 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114584450A (zh) * 2022-03-04 2022-06-03 中国建设银行股份有限公司 双层区块链系统及共识方法
CN114615281A (zh) * 2022-03-07 2022-06-10 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法
CN114640500A (zh) * 2022-02-14 2022-06-17 南京邮电大学 一种基于服务的联盟链高效共识方法
CN114841789A (zh) * 2022-06-27 2022-08-02 国网浙江省电力有限公司金华供电公司 基于区块链的审计审价故障数据在线编辑方法及系统
CN115086313A (zh) * 2022-05-24 2022-09-20 复旦大学 一种维护区块链链下网络数据一致性的方法
CN115549931A (zh) * 2022-12-02 2022-12-30 佛山赛思禅科技有限公司 一种基于拟态防御的拜占庭容错实现方法及系统
CN115842767A (zh) * 2022-09-07 2023-03-24 湖北工业大学 基于共识算法的物联网设备集群协同方法及系统
CN115914225A (zh) * 2022-10-28 2023-04-04 三峡大学 一种针对Raft共识算法选举阶段的优化方法
CN115941691A (zh) * 2023-03-09 2023-04-07 中国信息通信研究院 区块链上数据修改方法、装置、设备和介质
CN116192382A (zh) * 2023-03-01 2023-05-30 齐齐哈尔大学 一种基于区块链的dh密钥第三方篡改验证方法及系统
CN116684426A (zh) * 2023-08-03 2023-09-01 南方科技大学 一种基于拜占庭共识协议的任务处理方法
CN116737810A (zh) * 2023-05-06 2023-09-12 清华大学 一种用于分布式时序数据库的共识服务接口
CN117037988A (zh) * 2023-08-22 2023-11-10 广州视景医疗软件有限公司 一种基于区块链的电子病历存储方法及装置
CN117149534A (zh) * 2023-11-01 2023-12-01 北京铁力山科技股份有限公司 分布式数据库现主节点选举方法、装置、设备及存储介质
CN117527610A (zh) * 2024-01-05 2024-02-06 南京信息工程大学 一种基于ns3网络仿真平台的数据链仿真方法

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11295293B2 (en) * 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
CN110335156A (zh) * 2019-07-09 2019-10-15 广东投盟科技有限公司 区块链的规则维护方法及其系统
CN110572429B (zh) * 2019-07-30 2022-01-07 中钞信用卡产业发展有限公司杭州区块链技术研究院 基于区块链的共识方法、装置、设备及存储介质
CN110535955A (zh) * 2019-09-02 2019-12-03 广东电网有限责任公司 一种基于多链的配用电数据共享系统与方法
CN110659901B (zh) * 2019-09-03 2022-06-17 北京航空航天大学 基于博弈模型的区块链复杂事务验证方法及装置
CN110599340A (zh) * 2019-09-19 2019-12-20 姚忠凯 一种基于联盟链的代币方法、系统及钱包
CN110535629B (zh) * 2019-09-20 2022-06-10 奥科塞尔控股公司 一种异步网络条件下的出块共识方法
CN112671815A (zh) * 2019-10-16 2021-04-16 陈小虎 一种非许可网络的拜占庭容错共识方案
CN112702367A (zh) * 2019-10-22 2021-04-23 陈小虎 一种去中心化的共识节点管理方案
CN110796547A (zh) * 2019-10-30 2020-02-14 桂林电子科技大学 一种基于联盟区块链的改进的实用拜占庭容错系统
CN111045938B (zh) * 2019-12-09 2021-03-30 山西大学 基于Pareto分布故障引进开源软件可靠性建模方法
US11379464B2 (en) 2019-12-12 2022-07-05 Micro Focus Llc Asymmetric quorum protocol based distributed transaction database consistency control
CN111061769B (zh) * 2019-12-24 2021-09-10 腾讯科技（深圳）有限公司 一种区块链系统的共识方法及相关设备
CN111159764A (zh) * 2019-12-26 2020-05-15 杭州趣链科技有限公司 基于投票选举的链上与链下相结合实现联盟链自治的方法
CN111177796B (zh) * 2019-12-26 2022-03-15 西安电子科技大学 一种基于区块链的可溯源云存储系统的共识机制
CN111277407B (zh) * 2020-01-14 2023-01-24 南京如般量子科技有限公司 基于秘密共享的抗量子计算联盟链投票系统及方法
CN111274318B (zh) * 2020-01-16 2023-04-25 杭州趣链科技有限公司 一种区块链状态数据的存储、回滚方法、设备和存储介质
CN111312337A (zh) * 2020-01-17 2020-06-19 中国地质大学（武汉） 基于热重实验的单峰可燃物热解反应机理模型确定方法
CN111274110B (zh) * 2020-01-20 2023-03-31 四川万物数创科技有限公司 一种基于区块链的边缘设备性能评价方法、管理方法及介质
CN111400403B (zh) * 2020-03-14 2021-04-23 北京工业大学 一种基于区块链技术的物联网数据真实性分布式验证的方法
CN111541737B (zh) * 2020-03-25 2023-10-10 广东工业大学 一种基于区块链的aed设备位置共享方法
CN111461885B (zh) * 2020-03-31 2024-03-19 财付通支付科技有限公司 共识网络管理方法、装置、计算机以及可读存储介质
US11722589B2 (en) * 2020-04-08 2023-08-08 Huawei Technologies Co., Ltd. Rapid ledger consensus system and method for distributed wireless networks
CN111510347B (zh) * 2020-04-08 2021-10-26 北京链化未来科技有限公司 一种提高区块链共识效率的方法
CN113726828B (zh) * 2020-05-25 2023-07-25 北京北信源软件股份有限公司 一种支持微服务的高并发的可信区块链系统及方法
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
CN111786818B (zh) * 2020-06-16 2023-04-18 杭州溪塔科技有限公司 一种区块链共识节点状态监控方法和装置
CN111885050B (zh) * 2020-07-21 2022-01-11 腾讯科技（深圳）有限公司 基于区块链网络的数据存储方法、装置、相关设备及介质
CN112104482B (zh) * 2020-08-11 2021-06-29 佛山赛思禅科技有限公司 一种基于并行投票的共识方法
CN112529703B (zh) * 2020-11-23 2023-09-01 中国联合网络通信集团有限公司 一种区块链的记账节点选择方法及装置
CN112511312B (zh) * 2020-11-23 2023-10-17 北京微芯区块链与边缘计算研究院 一种可组装的共识方法及系统
CN112511619B (zh) * 2020-11-26 2022-11-18 北京工业大学 无线边缘区块链场景中的资源节点间交易匹配方法
CN112600682B (zh) * 2020-12-09 2022-01-18 四川大学 一种基于委托权益证明算法的区块链共识方法和装置
CN112636905B (zh) * 2020-12-11 2022-02-15 北京航空航天大学 基于多角色的可扩展共识机制的系统及方法
CN112527647B (zh) * 2020-12-15 2022-06-14 浙江大学 基于NS-3的Raft共识算法测试系统
CN114638452A (zh) * 2020-12-16 2022-06-17 中兴通讯股份有限公司 区块组头的获取方法及装置，存储介质及电子装置
CN112653692B (zh) * 2020-12-21 2022-02-08 中山大学 一种针对比特币内存池DDoS攻击的可调节动态防御机制
CN112583858B (zh) * 2021-01-05 2023-04-18 广州华资软件技术有限公司 一种基于区块链pbft算法的统一身份鉴权方法
CN112910982B (zh) * 2021-01-27 2023-06-16 网易（杭州）网络有限公司 一种联盟链的节点准入方法、装置、电子设备及存储介质
CN112749968B (zh) * 2021-01-29 2022-09-06 支付宝实验室(新加坡)有限公司 基于区块链的业务数据记录方法及装置
CN112907370B (zh) * 2021-02-10 2022-06-03 北京航空航天大学 多角色驱动的流水线共识方法及系统
CN113014384B (zh) * 2021-03-16 2022-07-15 平安付科技服务有限公司 基于dh密钥交换算法的数据比较方法、装置、计算机设备及存储介质
CN112991068B (zh) * 2021-05-20 2021-08-20 卓尔智联(武汉)研究院有限公司 股份授权证明DPoS共识方法、装置、电子设备和存储介质
CN113419823B (zh) * 2021-06-22 2023-07-18 东北大学 一种适用于高并发事务的联盟链系统及其设计方法
CN113378240B (zh) * 2021-06-23 2023-03-28 浪潮云信息技术股份公司 一种基于区块链的同步调用用户身份认证方法
CN113537593A (zh) * 2021-07-15 2021-10-22 之江实验室 预测议员投票倾向的方法及其装置
CN113535855B (zh) * 2021-07-28 2024-01-26 卫宁健康科技集团股份有限公司 基于区块链的主数据管理方法、系统、计算机设备及介质
CN114124961A (zh) * 2021-11-02 2022-03-01 杭州复杂美科技有限公司 区块确认方法、计算机设备和存储介质
CN114285602B (zh) * 2021-11-26 2024-02-02 成都安恒信息技术有限公司 一种分布式业务安全检测方法
CN114218809B (zh) * 2021-12-29 2022-06-03 中国科学技术大学 面向以太坊智能合约的协议自动形式化建模方法与系统
CN114448996B (zh) * 2022-03-08 2022-11-11 南京大学 基于计算存储分离框架下的冗余存储资源的共识方法和系统
CN114925403B (zh) * 2022-05-18 2023-04-07 易观科技股份有限公司 区块链混合共识数据处理方法和系统
CN115063927A (zh) * 2022-05-30 2022-09-16 湖南天河国云科技有限公司 基于区块链的共享充电系统及运行设备
CN115314352B (zh) * 2022-07-27 2023-12-12 北京航空航天大学 隐私增强的公平区块链领导者选举方法及装置
CN115296972B (zh) * 2022-08-04 2023-09-26 重庆邮电大学 一种基于区块链pbft共识机制的数据一致性共识方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106878000A (zh) * 2017-03-06 2017-06-20 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种联盟链共识方法及系统
CN107171829A (zh) * 2017-04-24 2017-09-15 杭州趣链科技有限公司 一种基于bft共识算法实现的动态节点管理方法
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN107623686A (zh) * 2017-09-12 2018-01-23 深圳先进技术研究院 区块链共识达成方法、装置、设备及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2438985A1 (fr) * 2001-02-20 2002-08-29 C. Andrew Neff Detection de bulletins de vote falsifies
US10007438B2 (en) * 2016-06-25 2018-06-26 International Business Machines Corporation Method and system for achieving consensus using alternate voting strategies (AVS) with incomplete information
CN106445711B (zh) * 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
CN106651332B (zh) * 2016-12-29 2020-11-06 成都质数斯达克科技有限公司 一种区块链中新区块的生成方法及区块链
CN107124403A (zh) * 2017-04-14 2017-09-01 朱清明 区块链中共识区块的生成方法与计算设备
CN107294727B (zh) * 2017-05-22 2020-06-19 联动优势科技有限公司 一种电子投票方法、终端设备以及区块链网络

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN106878000A (zh) * 2017-03-06 2017-06-20 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种联盟链共识方法及系统
CN107171829A (zh) * 2017-04-24 2017-09-15 杭州趣链科技有限公司 一种基于bft共识算法实现的动态节点管理方法
CN107623686A (zh) * 2017-09-12 2018-01-23 深圳先进技术研究院 区块链共识达成方法、装置、设备及存储介质

Cited By (124)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251527A1 (en) * 2018-02-14 2019-08-15 Christopher Walter Surdak System, Method, and Computer Program Product for a Distributed, Cryptographically Secured Proof-of-Intent Transaction Network
US20210142418A1 (en) * 2018-10-22 2021-05-13 Panasonic Intellectual Property Corporation Of America Control method, fund management system, recording medium, and data structure
CN111083221A (zh) * 2019-12-13 2020-04-28 北京菲林方德科技有限公司 一种交易验证方法及装置
CN111083221B (zh) * 2019-12-13 2023-08-04 北京菲林方德科技有限公司 一种交易验证方法及装置
CN111125131A (zh) * 2019-12-16 2020-05-08 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法
CN111125131B (zh) * 2019-12-16 2023-06-06 武汉大学 一种具备状态缓冲能力的两级共识区块链系统及部署方法
CN111190862B (zh) * 2019-12-28 2023-06-30 广州创想云科技有限公司 区块链的实现方法
CN111190862A (zh) * 2019-12-28 2020-05-22 广州创想云科技有限公司 区块链的实现方法
CN113052596B (zh) * 2019-12-28 2024-04-09 中移(成都)信息通信科技有限公司 基于区块链的出块方法、装置、设备和介质
CN113052596A (zh) * 2019-12-28 2021-06-29 中移(成都)信息通信科技有限公司 基于区块链的出块方法、装置、设备和介质
CN111199504B (zh) * 2019-12-29 2023-09-26 杭州拓深科技有限公司 一种基于区块链的去中心化消防维保监管方法
CN111199504A (zh) * 2019-12-29 2020-05-26 杭州拓深科技有限公司 一种基于区块链的去中心化消防维保监管方法
CN111179087A (zh) * 2019-12-31 2020-05-19 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111179087B (zh) * 2019-12-31 2023-07-18 重庆邮电大学 一种基于网格仲裁的联盟链共识方法
CN111159299A (zh) * 2019-12-31 2020-05-15 预言机(重庆)科技有限公司 一种区块链的上链方法
CN111291965A (zh) * 2020-01-06 2020-06-16 北京时代天鉴科技发展有限公司 一种基于员工互评数据挖掘不同目标团组的系统
CN111242618A (zh) * 2020-01-08 2020-06-05 成都库珀区块链科技有限公司 一种基于区块链合约技术的私钥保管方法及装置
CN111242619B (zh) * 2020-01-09 2023-09-19 易联众信息技术股份有限公司 引入监管机制的联盟链共识方法、区块链网络及存储介质
CN111182510A (zh) * 2020-01-09 2020-05-19 重庆邮电大学 一种基于区块链的工业物联网节点共识方法
CN111242619A (zh) * 2020-01-09 2020-06-05 厦门顺势共识信息科技有限公司 引入监管机制的联盟链共识方法、区块链网络及存储介质
CN111275554A (zh) * 2020-01-22 2020-06-12 北京瑞卓喜投科技发展有限公司 一种证券型通证的交易方法和系统、存储介质
CN111311414A (zh) * 2020-02-27 2020-06-19 杭州云象网络技术有限公司 一种基于一致性哈希算法的区块链多方共识方法
CN111311414B (zh) * 2020-02-27 2023-12-08 杭州云象网络技术有限公司 一种基于一致性哈希算法的区块链多方共识方法
CN111522561A (zh) * 2020-03-06 2020-08-11 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN111522561B (zh) * 2020-03-06 2023-06-06 杜晓楠 Dbft分布式网络中平滑向后兼容升级的方法、计算机可读存储介质和dbft网络
CN111556133B (zh) * 2020-04-26 2023-03-14 布比（北京）网络技术有限公司 区块链共识方法、系统及计算机存储介质、电子设备
CN111556133A (zh) * 2020-04-26 2020-08-18 布比（北京）网络技术有限公司 区块链共识方法、系统及计算机存储介质、电子设备
CN111639124A (zh) * 2020-04-29 2020-09-08 西安电子科技大学 安全时间同步方法、系统、存储介质、程序、智能设备
CN111639124B (zh) * 2020-04-29 2023-02-24 西安电子科技大学 安全时间同步方法、系统、存储介质、程序、智能设备
CN111414433A (zh) * 2020-05-09 2020-07-14 北京阳光欣晴健康科技有限责任公司 基于区块链和密文检索技术的分布式随访系统
CN111563278B (zh) * 2020-05-09 2023-11-28 电子科技大学 一种改进的股权授权证明方法
CN111563278A (zh) * 2020-05-09 2020-08-21 电子科技大学 一种改进的股权授权证明方法
CN111626722B (zh) * 2020-06-01 2023-11-24 中国联合网络通信集团有限公司 一种跨境支付方法及装置
CN111626722A (zh) * 2020-06-01 2020-09-04 中国联合网络通信集团有限公司 一种跨境支付方法及装置
CN111723406A (zh) * 2020-06-08 2020-09-29 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN111723406B (zh) * 2020-06-08 2023-04-28 上海朝夕网络技术有限公司 一种区块链的共识算法及系统
CN111612472A (zh) * 2020-06-10 2020-09-01 上海黔链科技有限公司 一种区块链权威节点授权共识算法
CN111711526B (zh) * 2020-06-16 2024-03-26 深圳前海微众银行股份有限公司 一种区块链节点的共识方法及系统
CN111711526A (zh) * 2020-06-16 2020-09-25 深圳前海微众银行股份有限公司 一种区块链节点的共识方法及系统
CN111917826A (zh) * 2020-06-23 2020-11-10 海南大学 一种基于区块链知识产权保护的pbft共识算法
CN111861505B (zh) * 2020-06-28 2024-03-01 石家庄铁道大学 基于区块链的农产品溯源方法
CN111861505A (zh) * 2020-06-28 2020-10-30 石家庄铁道大学 基于区块链的农产品溯源方法
CN111913833B (zh) * 2020-06-28 2023-08-18 华南理工大学 一种基于区块链的医疗物联网交易系统
CN111913833A (zh) * 2020-06-28 2020-11-10 华南理工大学 一种基于区块链的医疗物联网交易系统
CN111930698B (zh) * 2020-07-01 2024-03-15 南京晓庄学院 基于哈希图和联邦学习的数据安全共享的方法
CN111930698A (zh) * 2020-07-01 2020-11-13 南京晓庄学院 基于哈希图和联邦学习的数据安全共享的方法
CN111858768A (zh) * 2020-07-27 2020-10-30 苏州区盟链数字科技有限公司 一种优化区块链可信节点与共识算法的装置
CN111858768B (zh) * 2020-07-27 2023-06-16 苏州区盟链数字科技有限公司 一种优化区块链可信节点与共识算法的装置
CN112039964B (zh) * 2020-08-24 2022-01-04 大连理工大学 一种基于区块链的节点信誉共识方法
CN112039964A (zh) * 2020-08-24 2020-12-04 大连理工大学 一种基于区块链的节点信誉共识方法
CN112100278B (zh) * 2020-09-17 2023-10-20 重庆大学 一种基于私有链的智慧系统数据监管方法
CN112100278A (zh) * 2020-09-17 2020-12-18 重庆大学 一种基于私有链的智慧系统数据监管方法
CN112217683B (zh) * 2020-11-02 2023-10-17 西安链融科技有限公司 跨异构链数据可达性处理方法、系统、介质、设备、终端
CN112217683A (zh) * 2020-11-02 2021-01-12 西安西电链融科技有限公司 跨异构链数据可达性处理方法、系统、介质、设备、终端
CN112398640B (zh) * 2020-11-13 2024-02-13 华南农业大学 一种优化的区块链共识算法
CN112398640A (zh) * 2020-11-13 2021-02-23 华南农业大学 一种优化的区块链共识算法
CN114065283A (zh) * 2020-11-20 2022-02-18 北京邮电大学 一种轻量级可循环再生的区块链存储方法及装置
CN114065283B (zh) * 2020-11-20 2024-05-28 北京邮电大学 一种轻量级可循环再生的区块链存储方法及装置
CN112434343A (zh) * 2020-11-25 2021-03-02 江西理工大学 一种基于双重区块链技术的虚拟电厂安全调度与交易方法
CN112434343B (zh) * 2020-11-25 2024-03-01 江西理工大学 一种基于双重区块链技术的虚拟电厂安全调度与交易方法
CN112733204B (zh) * 2021-01-16 2023-01-20 阳江市链点创新科技发展有限公司 一种基于区块链和多重签名技术的防伪溯源方法
CN112733204A (zh) * 2021-01-16 2021-04-30 阳江市链点创新科技发展有限公司 一种基于区块链和多重签名技术的防伪溯源方法
CN112801791A (zh) * 2021-01-29 2021-05-14 武汉大学 一种基于授权的区块链共识方法及系统
CN112801791B (zh) * 2021-01-29 2023-06-16 武汉大学 一种基于授权的区块链共识方法及系统
CN112819433A (zh) * 2021-02-01 2021-05-18 北京工业大学 一种用于协同政务区块链的共识方法
CN112819433B (zh) * 2021-02-01 2024-03-26 北京工业大学 一种用于协同政务区块链的共识方法
CN113254526A (zh) * 2021-03-02 2021-08-13 中国信息通信研究院 区块链共识方法、装置及系统
CN113114620A (zh) * 2021-03-02 2021-07-13 深信服科技股份有限公司 一种暴力破解的检测方法和装置，及存储介质
CN113111373A (zh) * 2021-05-13 2021-07-13 北京邮电大学 Vbft共识机制的随机数生成方法和共识机制系统
CN113111373B (zh) * 2021-05-13 2022-06-07 北京邮电大学 Vbft共识机制的随机数生成方法和共识机制系统
CN113722545A (zh) * 2021-06-30 2021-11-30 电子科技大学 一种许可链环境下的数据编校方法
CN113722545B (zh) * 2021-06-30 2023-04-28 电子科技大学 一种许可链环境下的数据编校方法
CN114401099A (zh) * 2021-08-17 2022-04-26 同济大学 一种基于网络拓扑的区块链PoW自私挖矿攻击防御方法
CN113591161B (zh) * 2021-08-19 2023-09-08 北京优品三悦科技发展有限公司 一种联盟链管理方法、装置、设备及存储介质
CN113591161A (zh) * 2021-08-19 2021-11-02 北京优品三悦科技发展有限公司 一种联盟链管理方法、装置、设备及存储介质
CN113708968A (zh) * 2021-08-27 2021-11-26 中国互联网络信息中心 区块链的节点选举控制方法和装置
CN113708968B (zh) * 2021-08-27 2023-08-11 中国互联网络信息中心 区块链的节点选举控制方法和装置
CN114584312A (zh) * 2021-10-09 2022-06-03 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114584312B (zh) * 2021-10-09 2024-03-29 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN113949709A (zh) * 2021-10-13 2022-01-18 甘肃同兴智能科技发展有限责任公司 一种提高区块链网络安全性的共识方法及系统
CN113949709B (zh) * 2021-10-13 2024-05-10 甘肃同兴智能科技发展有限责任公司 一种提高区块链网络安全性的共识方法及系统
CN114189522A (zh) * 2021-10-15 2022-03-15 敏博科技(武汉)有限公司 一种车联网中基于优先级的区块链共识方法及系统
CN114189522B (zh) * 2021-10-15 2024-04-16 敏博科技(武汉)有限公司 一种车联网中基于优先级的区块链共识方法及系统
CN114095209A (zh) * 2021-10-27 2022-02-25 中通服中睿科技有限公司 一种基于权重激励主节点选举的联盟链共识方法及系统
CN114089744A (zh) * 2021-11-01 2022-02-25 南京邮电大学 一种基于改进Raft算法选择车辆队列领航车的方法
CN114089744B (zh) * 2021-11-01 2023-11-21 南京邮电大学 一种基于改进Raft算法选择车辆队列领航车的方法
CN114189325B (zh) * 2021-11-19 2023-09-29 新疆大学 具有高容错可扩展的拜占庭容错方法、装置及存储介质
CN114189325A (zh) * 2021-11-19 2022-03-15 新疆大学 具有高容错可扩展的拜占庭容错方法、装置及存储介质
CN114301928A (zh) * 2021-11-29 2022-04-08 之江实验室 一种基于sgx的链上链下混合共识方法及系统
CN114385647A (zh) * 2021-12-15 2022-04-22 达闼科技（北京）有限公司 联盟链出块方法、装置、电子设备及介质
CN114444090A (zh) * 2021-12-17 2022-05-06 中国科学院信息工程研究所 一种高效的秘密唯一领导人选举方法
CN114258015A (zh) * 2021-12-23 2022-03-29 成都三零瑞通移动通信有限公司 一种基于全网共识的集群终端防失控方法及系统
CN114258015B (zh) * 2021-12-23 2023-10-24 成都三零瑞通移动通信有限公司 一种基于全网共识的集群终端防失控方法及系统
CN114640500B (zh) * 2022-02-14 2023-07-28 南京邮电大学 一种基于服务的联盟链高效共识方法
CN114640500A (zh) * 2022-02-14 2022-06-17 南京邮电大学 一种基于服务的联盟链高效共识方法
CN114466024B (zh) * 2022-02-21 2024-02-13 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 基于新型PoM共识算法的分布式账本系统及方法
CN114466024A (zh) * 2022-02-21 2022-05-10 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 基于新型PoM共识算法的分布式账本系统及方法
CN114584450A (zh) * 2022-03-04 2022-06-03 中国建设银行股份有限公司 双层区块链系统及共识方法
CN114615281B (zh) * 2022-03-07 2023-02-28 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法
CN114615281A (zh) * 2022-03-07 2022-06-10 中国科学院软件研究所 基于小规模委员会的区块链出块方法及PoS协议确认方法
CN114422155A (zh) * 2022-03-30 2022-04-29 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质
CN114422155B (zh) * 2022-03-30 2022-08-02 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质
CN115086313B (zh) * 2022-05-24 2023-07-14 复旦大学 一种维护区块链链下网络数据一致性的方法
CN115086313A (zh) * 2022-05-24 2022-09-20 复旦大学 一种维护区块链链下网络数据一致性的方法
CN114841789A (zh) * 2022-06-27 2022-08-02 国网浙江省电力有限公司金华供电公司 基于区块链的审计审价故障数据在线编辑方法及系统
CN114841789B (zh) * 2022-06-27 2022-09-09 国网浙江省电力有限公司金华供电公司 基于区块链的审计审价故障数据在线编辑方法及系统
CN115842767A (zh) * 2022-09-07 2023-03-24 湖北工业大学 基于共识算法的物联网设备集群协同方法及系统
CN115842767B (zh) * 2022-09-07 2024-04-23 湖北工业大学 基于共识算法的物联网设备集群协同方法及系统
CN115914225A (zh) * 2022-10-28 2023-04-04 三峡大学 一种针对Raft共识算法选举阶段的优化方法
CN115914225B (zh) * 2022-10-28 2024-04-30 三峡大学 一种针对Raft共识算法选举阶段的优化方法
CN115549931A (zh) * 2022-12-02 2022-12-30 佛山赛思禅科技有限公司 一种基于拟态防御的拜占庭容错实现方法及系统
CN116192382B (zh) * 2023-03-01 2023-09-15 齐齐哈尔大学 一种基于区块链的dh密钥第三方篡改验证方法及系统
CN116192382A (zh) * 2023-03-01 2023-05-30 齐齐哈尔大学 一种基于区块链的dh密钥第三方篡改验证方法及系统
CN115941691B (zh) * 2023-03-09 2023-05-05 中国信息通信研究院 区块链上数据修改方法、装置、设备和介质
CN115941691A (zh) * 2023-03-09 2023-04-07 中国信息通信研究院 区块链上数据修改方法、装置、设备和介质
CN116737810A (zh) * 2023-05-06 2023-09-12 清华大学 一种用于分布式时序数据库的共识服务接口
CN116684426B (zh) * 2023-08-03 2024-01-09 南方科技大学 一种基于拜占庭共识协议的任务处理方法
CN116684426A (zh) * 2023-08-03 2023-09-01 南方科技大学 一种基于拜占庭共识协议的任务处理方法
CN117037988A (zh) * 2023-08-22 2023-11-10 广州视景医疗软件有限公司 一种基于区块链的电子病历存储方法及装置
CN117037988B (zh) * 2023-08-22 2024-05-17 广州视景医疗软件有限公司 一种基于区块链的电子病历存储方法及装置
CN117149534B (zh) * 2023-11-01 2024-02-06 北京铁力山科技股份有限公司 分布式数据库现主节点选举方法、装置、设备及存储介质
CN117149534A (zh) * 2023-11-01 2023-12-01 北京铁力山科技股份有限公司 分布式数据库现主节点选举方法、装置、设备及存储介质
CN117527610A (zh) * 2024-01-05 2024-02-06 南京信息工程大学 一种基于ns3网络仿真平台的数据链仿真方法
CN117527610B (zh) * 2024-01-05 2024-03-19 南京信息工程大学 一种基于ns3网络仿真平台的数据链仿真方法

Also Published As

Publication number Publication date
CN109964446B (zh) 2022-03-25
CN109964446A (zh) 2019-07-02

Similar Documents

Publication Publication Date Title
WO2019232789A1 (fr) Procédé de consensus à base de vote
Kolb et al. Core concepts, challenges, and future directions in blockchain: A centralized tutorial
Uddin et al. A survey on the adoption of blockchain in iot: Challenges and solutions
Belotti et al. A vademecum on blockchain technologies: When, which, and how
Kwon et al. Cosmos whitepaper
Dinh et al. Untangling blockchain: A data processing view of blockchain systems
Baird et al. Hedera: A public hashgraph network & governing council
McConaghy et al. Bigchaindb: a scalable blockchain database
US11153069B2 (en) Data authentication using a blockchain approach
US20200394183A1 (en) System and method of executing, confirming and storing a transaction in a serverless decentralized node network
US10693646B2 (en) Event execution using a blockchain approach
CN115152177B (zh) 提供机密知识的专门证明的系统和方法
CN110998631A (zh) 分布式账本技术
US20200351074A1 (en) System for synchronizing a cryptographic key state through a blockchain
Yadav et al. A comparative study on consensus mechanism with security threats and future scopes: Blockchain
CN116670701A (zh) 实施同步信任共识模型的分布式分类账网络
Gao et al. The notarial office in E-government: a blockchain-based solution
Zhang et al. OBBC: A blockchain-based data sharing scheme for open banking
Mao et al. A survey on cross-chain technology: Challenges, development, and prospect
Xu et al. Exploring blockchain technology through a modular lens: A survey
TW202139127A (zh) 用於與區塊鏈相關聯之服務平台之運算服務
Wels Guaranteed-TX: The exploration of a guaranteed cross-shard transaction execution protocol for Ethereum 2.0.
Bagchi Using blockchain technology and smart contracts for access management in IoT devices
Haffke Technical analysis of established blockchain systems
Furtado et al. Towards characterising architecture and performance in blockchain: a survey

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18921588

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18921588

Country of ref document: EP

Kind code of ref document: A1