CN114710507B - Consensus method, blockchain node, medium and consensus node - Google Patents
Consensus method, blockchain node, medium and consensus node Download PDFInfo
- Publication number
- CN114710507B CN114710507B CN202210325860.7A CN202210325860A CN114710507B CN 114710507 B CN114710507 B CN 114710507B CN 202210325860 A CN202210325860 A CN 202210325860A CN 114710507 B CN114710507 B CN 114710507B
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- nodes
- delegation
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 73
- 238000003860 storage Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 9
- 230000008569 process Effects 0.000 description 18
- 230000006870 function Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 15
- 238000002360 preparation method Methods 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 11
- 238000005516 engineering process Methods 0.000 description 8
- 230000006872 improvement Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 7
- 230000008520 organization Effects 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000012546 transfer Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 108010001267 Protein Subunits Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000005284 excitation Effects 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002427 irreversible effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 229920001296 polysiloxane Polymers 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
- H04L67/1093—Some peer nodes performing special functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1042—Peer-to-peer [P2P] networks using topology management mechanisms
-
- 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
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/46—Secure multiparty computation, e.g. millionaire problem
- H04L2209/463—Electronic voting
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Marketing (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Computing Systems (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method of consensus and a blockchain node, the method performed by a first node in a blockchain, the blockchain including a plurality of consensus nodes, the first node being one of the plurality of consensus nodes, the method comprising: the delegation information of the plurality of consensus nodes is obtained from a blockchain, the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes delegation any consensus node in the blockchain to carry out consensus; and carrying out consensus operation on the consensus proposal based on the entrusting information.
Description
Technical Field
The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to a consensus method and a blockchain node.
Background
Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.
Disclosure of Invention
The invention aims to provide a consensus scheme for improving consensus efficiency in a block chain.
A first aspect of the present specification provides a method of consensus performed by a first node in a blockchain, the blockchain including a plurality of consensus nodes, the first node being one of the plurality of consensus nodes, the method comprising: obtaining delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes delegation any consensus node in the block chain to perform consensus; and carrying out consensus operation on the consensus proposal based on the entrusting information.
A second aspect of the present specification provides a consensus node comprising: the obtaining unit is used for obtaining delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes delegation any consensus node in the block chain to perform consensus; and the consensus unit is used for performing consensus operation on the consensus proposal based on the delegation information.
A third aspect of the present description provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first aspect.
A fourth aspect of the present specification provides a consensus node comprising a memory having executable code stored therein and a processor implementing the method of the first aspect when executing the executable code.
According to the consensus scheme provided by the embodiment of the specification, the nodes participating in consensus are reduced to a smaller number through delegation among the nodes, so that the consensus time is reduced, the consensus efficiency is improved, the consensus communication data volume is reduced, and the cost is reduced.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a block chain architecture diagram in one embodiment;
FIG. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm in an embodiment;
FIG. 3 is a flow diagram of a method for delegation of node commonalities in a blockchain in an embodiment of the present disclosure;
FIG. 4 is a flow chart of a consensus method in an embodiment of the present description;
FIG. 5 is a flow diagram of a method of setting malicious nodes in a blockchain in an embodiment of the present description;
FIG. 6 is a flow chart of a method for canceling delegation to a consensus node when the consensus node fails in an embodiment of the present disclosure;
fig. 7 is a block diagram of a consensus node in an embodiment of the present description.
Detailed Description
In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks through consensus, and the like. In the private chain, the write authority of the network is controlled by a certain organization or organization, and the data read authority is regulated by the organization. The federated chain is a blockchain that is interposed between public and private chains, enabling "partial decentralization". Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.
FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, a blockchain 100 includes, for example, 7 nodes from node 1 to node 7. The connections between nodes are schematically represented as P2P (Peer to Peer) connections. The nodes may store a full amount of ledgers, i.e., the state of all blocks and all accounts. Wherein each node in the blockchain may generate the same state in the blockchain by performing the same transaction, each node in the blockchain may store the same state database. It will be appreciated that while 7 nodes are shown in FIG. 1 as being included in a blockchain, embodiments of the present description are not so limited, but may include other numbers of nodes. Specifically, the nodes included in the blockchain may meet the bayer fault tolerance (Byzantine Fault Tolerance, BFT) requirements. The bayer fault tolerance requirement is understood to be that the bin node may exist inside the blockchain, and the blockchain does not show the bin behavior. In general, some bayer fault-tolerant algorithms require a number of nodes greater than 3f+1, where f is the number of bayer nodes (i.e., malicious nodes), such as the practical bayer fault-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).
Transactions in the blockchain domain may refer to task units that execute in the blockchain and are recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates an account address From which the transaction was initiated (i.e., a transfer task To another account was initiated), the To field indicates an account address From which the transaction was received (i.e., a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in a blockchain, the From field represents the account address From which the transaction originated, the To field represents the account address of the contract that the transaction called, and the Data field includes Data, such as the name of the function in the calling contract, and the incoming parameters To the function, for retrieving the code of the function From the blockchain and executing the code of the function when the transaction is executed.
The functionality of the smart contract may be provided in the blockchain. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes. Invoking the smart contract in the blockchain initiates a transaction directed to the smart contract address such that each node in the blockchain runs the smart contract code in a distributed manner. It should be noted that, in addition to the smart contracts that can be created by the user, the smart contracts can also be set by the system in the creation block. Such contracts are commonly referred to as an opening contract. In general, some blockchain data structures, parameters, properties, and methods may be set in the creating contract. In addition, an account with system administrator rights may create a system level contract, or modify a system level contract (simply referred to as a system contract). Wherein the system contracts can be used to add data structures for data of different services in the blockchain.
In the scenario of deploying contracts, for example, bob sends a transaction containing information to create an intelligent contract (i.e., deploying a contract) into a blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is empty to indicate that the transaction is for deploying the contract. After agreement is reached between nodes through a consensus mechanism, determining a contract address '0 x6f8ae93 …' of the contract, adding a contract account corresponding to the contract address of the intelligent contract in a state database by each node, distributing a state storage corresponding to the contract account, and storing a contract code in the state storage of the contract, so that the contract is successfully created.
In the scenario of invoking a contract, for example, bob sends a transaction for invoking a smart contract into a blockchain as shown in fig. 1, the from field of the transaction is the address of the account of the transaction initiator (i.e., bob), the "0x6f8ae93 …" in the to field represents the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain may execute the transaction separately, thereby executing the contract separately, updating the status database based on execution of the contract.
Blockchain technology differs from one of the decentralized features of conventional technology in that accounting is performed on individual nodes, otherwise known as distributed accounting, rather than conventional centralized accounting. The blockchain system is to be a hard-to-break, public, untampered, decentralised, honest and trusted system for data records, and needs to be secure, clear and irreversible for distributed data records in as short a time as possible. In different types of blockchain networks, in order to keep account books consistent among the nodes of each record account book, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a block granularity consensus mechanism may be implemented between blockchain nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block. For another example, a transaction granularity consensus mechanism may be implemented between blockchain nodes, for example, after a node (e.g., a unique node) obtains a blockchain transaction, if the blockchain transaction is approved by other nodes, each node approving the blockchain transaction may respectively add the blockchain transaction to its own maintained latest block, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism that the blockchain node achieves the consensus of the whole network about the blockinformation (or blockdata), and can ensure that the latest block is accurately added to the blockchain. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (Delegated Proof of Stake, DPOS), practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithms, and the like. Among the various consensus algorithms, the success of consensus on a consensus proposal is determined, typically after a preset number of nodes agree on the data to be consensus (i.e., the consensus proposal). Specifically, in the PBFT algorithm, f malicious nodes can be tolerated for N.gtoreq.3f+1 consensus nodes, that is, when 2f+1 nodes in the N consensus nodes agree, success of the consensus can be determined.
Fig. 2 is a schematic diagram of a consensus process in a PBFT consensus algorithm. As shown in fig. 2, according to the PBFT consensus algorithm, the consensus process can be divided into four phases of Request, preparation and Commit. Assuming that a blockchain includes four consensus nodes of node n 1-node n4, wherein node n1 is, for example, a master node, and node n 2-node n4 is, for example, a slave node, f=1 malicious nodes can be tolerated in node n 1-node n4 according to the PBFT algorithm. Specifically, during the request phase, a user of the blockchain may send a request, for example in the form of a blockchain transaction, to node n1 through his user device. In the preliminary stage, the node n1 may package a plurality of transactions into a consensus proposal after receiving the plurality of transactions from one or more user devices, and send the consensus proposal and a signature of the consensus proposal by the node n1 to other consensus nodes (i.e. nodes n 2-n 4) for generating blocks, where the consensus proposal may include information such as a transaction body of the plurality of transactions and a submitting sequence of the plurality of transactions. In the preparation phase, each slave node may sign the consensus proposal and send it to the other individual nodes. Assuming node n4 is a malicious node, nodes n1, n2, and n3, after each receiving the signatures of 2 f=2 other consensus nodes for the consensus proposal, may determine that the preparation phase is complete, and may enter the commit phase. For example, as shown in fig. 2, after receiving the signatures of node n2 and node n3, node n1 verifies that both the signatures of node n2 and node n3 are correct signatures of the consensus proposal, and then determines that the preparation phase is complete, and node n2 determines that the preparation phase is complete after receiving the signature of node n3 and the signature of preparation phase node n1 and verifying passed. In the submitting stage, each consensus node performs signature of the submitting stage on the consensus proposal and sends the signature to other consensus nodes, and each consensus node can determine that the submitting stage is completed and the consensus is successful after receiving the signatures of the submitting stages of 2 f=2 other consensus nodes. For example, the node n1 may determine that the commit phase is completed after receiving the signatures of the commit phases of the node n2 and the node n3 and verifying, so that the node n1 may perform executing the plurality of transactions according to the consensus proposal, generate and store a block (e.g., block B1) including the plurality of transactions, update the world state according to the execution results of the plurality of transactions, and return the execution results of the plurality of transactions to the user device. Similarly, after determining that the commit phase is complete, nodes n2 and n3 execute the plurality of transactions, generate and store block B1, and update the world state based on the execution results of the plurality of transactions. Through the above process, the storage consistency of the node n1, the node n2 and the node n3 is realized. That is, the nodes n 1-n 4 can still realize successful consensus of the consensus proposal in the presence of a malicious node, and complete execution of the block.
In recent years, the size of blockchains is larger and larger, and the service is also more and more complex. As the size of the node increases, the process shown in fig. 2, in which a plurality of nodes are commonly identified, requires a plurality of communications between the plurality of nodes, so that the efficiency of the sharing is reduced. For example, in the blockchain shown in fig. 1, the number of nodes is 7, and in the case where all of the 7 nodes participate in consensus, the number of tolerable malicious nodes f is 2. In the preparation phase or commit phase of the consensus process, each node can confirm that the phase is complete after receiving the signature of the consensus proposal by 2 f=4 other nodes and verifying the passing.
In one related art, a predetermined number of consensus nodes are voted for by a plurality of nodes. This related art generally operates on the public chain and is based on three key elements: 1) Excitation mechanism: incentive nodes participate in the competitive election and voting through issued virtual tokens, equity, interest and other rewards; 2) The rights and interests mortgage: by the aid of the high-enough equity mortgage, the doing and averting cost is increased, the selected representative node cannot be disused, and the safety of the system is ensured; 3) And (3) treating under a chain: the management of the arbitration meeting is realized through the foundation under the chain, the value of the medals is improved, and the benign operation of the system is ensured. However, the consensus mechanism described above cannot be used in a federated chain, as these elements are typically not included in the federated chain.
Therefore, the embodiment of the specification provides a scheme for converging the scale of the consensus nodes through a delegation mechanism, and the scheme can reasonably utilize some trust relations among the nodes in an actual project and support stable consensus of the large-scale nodes.
FIG. 3 is a flow chart of a method for delegation of node commonalities in a blockchain in an embodiment of the present disclosure.
As shown in fig. 3, first, in step S301, node 5 sends a transaction Tx1 to the blockchain for delegating node 2 for consensus.
Assuming node 5 in fig. 1 treats node 2 as a trusted node, node 5 may send a transaction Tx1 to the blockchain for delegation to delegate node 2 to agree on behalf of node 5. The node 5 and the node 2 may be two nodes in the same organization, for example. Specifically, node 5 may generate transaction Tx1, which may be used to invoke a pre-deployed smart contract C1 in the blockchain for recording delegation information in the blockchain. After generating transaction Tx1, node 5 may send transaction Tx1 to any node in the blockchain (e.g., node 1) to be recognized and executed in the blockchain by the process shown in fig. 2.
In step S303, the node in the blockchain executes transaction Tx1, recording commit information in the blockchain.
Assume that, as shown in fig. 1, all nodes 1-7 in the blockchain are currently consensus nodes, and each consensus node in the blockchain executes the transaction Tx1 after the consensus proposal corresponding to the block (e.g., block B1) where the transaction Tx1 is located is successful, and updates the world state according to the execution result of the transaction Tx 1. Taking node 1 as an example, node 1 may record the delegation information in the contract state of contract C1 after executing transaction Tx 1.
In one embodiment, the contract state of contract C1 may have stored therein a table of consensus node information, for example as shown in Table 1, prior to executing transaction Tx 1:
TABLE 1
| Consensus node | Weighting of | Entrusting node |
| Node 1 | 1 | |
| Node 2 | 1 | |
| Node 3 | 1 | |
| Node 4 | 1 | |
| Node 5 | 1 | |
| Node 6 | 1 | |
| Node 7 | 1 |
Table 1 shows that nodes 1-7 are all consensus nodes, and that the list of delegated nodes is empty, which indicates that no other node presently has delegated its proxy to make consensus, and that the weight of 1 indicates that each consensus node presently only makes consensus on behalf of itself.
After the node 1 performs the completion transaction Tx1 and updates the contract state of the contract C1 according to the transaction Tx1, since the node 5 entrusts the node 2 with entrustment, the node 5 no longer performs consensus, and therefore, the information of the node 5 is deleted in the consensus node information table and the information of the node 2 is changed, and after the modification is performed, the consensus node information table is as shown in table 2:
TABLE 2
| Consensus node | Weighting of | Entrusting node |
| Node 1 | 1 | |
| Node 2 | 2 | Node 5 |
| Node 3 | 1 | |
| Node 4 | 1 | |
| Node 6 | 1 | |
| Node 7 | 1 |
Similarly, assuming node 6 transmits transaction Tx2 to the blockchain for delegation to node 2 for consensus, node 7 transmits transaction Tx3 to the blockchain for delegation to node 3 for consensus, the consensus node information table shown in table 3 is available in the blockchain by sequentially executing transaction Tx2 and transaction Tx 3:
TABLE 3 Table 3
| Consensus node | Weighting of | Entrusting node |
| Node 1 | 1 | |
| Node 2 | 3 | Node 5, node 6 |
| Node 3 | 2 | Node 7 |
| Node 4 | 1 |
After delegation by the process described above, the number of consensus nodes in the blockchain is reduced from 7 to 4, thereby greatly reducing the traffic in the blockchain consensus process. In the consensus, the nodes 1 to 4 can calculate the number of signatures based on the weights, so as to perform the consensus on behalf of the delegate node.
In another embodiment, the contract state of the contract C1 further includes a delegation node information table, and the delegation node information table includes, for example, an identifier of a node delegating the other nodes to make a consensus and an identifier of a corresponding trusted node. The nodes in the blockchain also update the delegated node information table in the contract state of contract C1 after executing each transaction for the delegated node. For example, the number of the cells to be processed,
After executing the transaction Tx3 described above, the node 1 may generate a delegated node information table as shown in table 4:
TABLE 4 Table 4
| Entrusting node | Trusted node |
| Node 5 | Node 2 |
| Node 6 | Node 2 |
| Node 7 | Node 3 |
It will be appreciated that in the embodiment of the present specification, the delegation information recorded in the blockchain is not limited to the above, and the consensus method provided in the embodiment of the present specification may be performed as long as the delegation information may indicate the number of delegation nodes corresponding to each consensus node.
Fig. 4 is a flowchart of a consensus method in an embodiment of the present description. The consensus method can be executed by any consensus node in the blockchain, and specifically comprises the following steps:
step S401, obtaining entrusting information from a block chain;
step S403, performing consensus operation based on the delegated information.
The individual steps of the method shown in fig. 4 will be described in detail below.
First, in step S401, each consensus node acquires delegation information in a blockchain.
The method shown in fig. 4 is described below by taking node 1 as an example. The delegation information includes, for example, a consensus node information table as shown in table 3 of the contract states of the contract C1 in the node 1. Assuming that node 1 is the master node of the plurality of consensus nodes, referring to fig. 2, in the request phase, node 1, upon receiving a plurality of transactions from one or more user devices, generates a consensus proposal, which includes, for example, the plurality of transactions in block B2 to be generated and the order of submission of the plurality of transactions. In order to share with the consensus nodes in the blockchain, node 1 needs to obtain information for each consensus node in the blockchain. Thus, node 1 may read the consensus node information table as shown in Table 3 from the blockchain. Specifically, node 1 may initiate a query request (or query transaction) to invoke contract C1, thereby querying the current consensus node information table of contract C1 from local.
In step S403, each consensus node performs a consensus operation based on the delegate information.
Specifically, in the preliminary stage, node 1 transmits the consensus proposal and the signature of the consensus proposal by node 1 to node 2, node 3 and node 4, respectively, based on the identity of each consensus node in table 3.
In the preparation phase, node 2, node 3 and node 4 respectively sign the consensus proposal and send the consensus proposal and its signature to the other consensus nodes respectively. For example, node 1 receives signatures of the consensus proposals by node 2 and node 3, and node 1 may calculate the number of acquired signatures S1, that is, s1=1+3+2=6, according to weights of node 1, node 2, and node 3 in the consensus node information table. As described above, in the blockchain shown in fig. 1, f=2 malicious nodes can be tolerated, and therefore each consensus node needs to obtain the signature of 2f+1=5 consensus nodes to confirm that the preparation phase is complete. Node 1 calculates the signature number s1= 6>5 as described above, and thus can confirm that the preliminary phase is completed.
After receiving the signatures proposed by node 1 and node 3, node 2 may calculate the number of acquired signatures s2=1+3+2= 6>5 according to the weights of node 1, node 2, and node 3 in table 3, and thus may confirm that the preliminary stage is completed.
Node 3 and node 4 may similarly determine that the preliminary phase is complete.
After the completion of the preparation phase, nodes 1-4 each send signatures of the preparation phase's proposals for consensus to the other consensus nodes in table 3. Each consensus node may similarly determine the number of signatures acquired from table 3, and in the event that the number of signatures is greater than or equal to 5, may determine that the preparation phase is complete, thus completing the consensus process for block B2.
Node 1-after node 4 completes consensus for block B2, performs multiple transactions in block B2, generates block B2, and updates the world state based on the execution of block B2. Thereafter, nodes 1-4 may each send the generated block B2 to the respective delegated node. Specifically, node 2 may send its generated block B2 to nodes 5 and 6, and node 3 may send its generated block B2 to node 7. Each entrusting node, after receiving the block B2, stores the block B2 and updates the world state by executing a plurality of transactions included in the block B2, thereby reaching the world state consistent with the consensus node.
In another embodiment, each consensus node may broadcast a block synchronization event to the blockchain nodes after generating block B2. After receiving the event, the delegation node synchronizes the block B2 from its delegated consensus node. In another embodiment, the delegation node may send a query request to its delegated consensus node at regular time to query the block height of the consensus node, and synchronize a new block from its delegated consensus node when the block height of the consensus node is found to be higher than its own block height.
In the process of carrying out consensus, each consensus node can record information such as the identification of the source node of each received signature in a log, so that when the received consensus proposal is bifurcated (namely different consensus proposals and the signatures thereof are received), malicious nodes in the consensus nodes can be locked according to the log. After determining the malicious node, the consensus node can limit its participation in consensus by recording the malicious node and its delegated node in the blockchain.
FIG. 5 is a flow chart of a method of setting malicious nodes in a blockchain in an embodiment of the present disclosure.
As shown in fig. 5, assuming that the node 4 determines that the node 3 is a malicious node in the consensus process, the node 4 can determine that the weight of the node 3 is 2, that is, the number of malicious nodes tolerable by the blockchain by querying the contract state of the intelligent contract, so that the node 3 can be set as a malicious node in the blockchain through the consensus.
Specifically, in step S501, node 4 sends a transaction Tx4 to node 1, the transaction Tx4 being operable to invoke the smart contract described above for setting node 3 as a malicious node in the blockchain.
In step S503, the consensus node in the blockchain performs transaction Tx4, updating the delegation information in the blockchain.
After receiving the consensus proposal for block B3 including transaction Tx4, the current consensus nodes (nodes 1-4) in the blockchain consensus the consensus proposal by the process shown in fig. 2, and node 1-3 can consensus the consensus proposal successfully because the sum of the weights (7) of the respective consensus nodes and the malicious node (node 3) weight 2 satisfy the relation of 3f+1:f. Taking node 1 as an example, node 1 performs transaction Tx4 after the consensus proposal for block B3 succeeds, in the contract state of contract C1, deletes the information of node 3 in table 3, deletes the information of node 7 in table 4, and puts nodes 3 and 7 into the malicious node list in the contract state, and when nodes 3 and 7 are added to the malicious node list, neither node 3 nor node 7 can participate in the consensus anymore, but can synchronize blocks from only any of the consensus nodes.
It will be appreciated that in the case where the consensus node determines that node 2 is a malicious node, since the weight of node 2 is 3, the sum (7) of the weights of the respective consensus nodes cannot satisfy the relationship of less than or equal to f3f+1, and thus node 2 cannot be set as a malicious node by performing a transaction.
In addition, the consensus nodes may monitor the operational status of each other, or the delegation node may monitor the status of its delegated consensus node after delegating the consensus node, and when failure of the consensus node is monitored, a transaction may be sent to the blockchain for delegation of the delegation node to the consensus node.
FIG. 6 is a flow chart of a method for delegating a consensus node when the consensus node fails in an embodiment of the present disclosure.
As shown in fig. 6, assuming node 4 determines that node 3 is malfunctioning, at step S601, node 4 may send a transaction Tx5 to node 1 that invokes contract C1 described above for delegation to node 3 by the delegation node (i.e., node 7).
In step S603, the node 1 executes the transaction Tx5, updating the delegation information.
Assuming that the current consensus node in the blockchain is as shown in table 3, as described above, since the sum of the weight of node 3 and the weights of all the consensus nodes satisfies the relationship of f3f+1, node 1, node 2, and node 4 can succeed in consensus transaction Tx5 and update the delegation information according to transaction Tx 5. Specifically, taking the node 1 as an example, after the node 1 successfully performs the transaction Tx5 and performs the consensus, the node 3 information is deleted from the consensus node information table of table 3, the node 7 is added as the consensus node, and the node 7 information is deleted from the delegation node information table shown in table 4.
Fig. 7 is a block diagram of a consensus node in an embodiment of the present disclosure, including:
an obtaining unit 71, configured to obtain delegation information of a plurality of consensus nodes from a blockchain, where the delegation information is used to indicate a number of delegation nodes associated with each of the consensus nodes, and the delegation node is a node delegating any one of the consensus nodes in the blockchain to perform consensus;
And a consensus unit 72 for performing a consensus operation for a consensus proposal based on the delegation information.
In one embodiment, the consensus node further comprises: a receiving unit, configured to receive a first transaction, where the first transaction is sent by a second node of the plurality of consensus nodes, and is used to delegate a third node of the plurality of consensus nodes to perform consensus; and the updating unit is used for updating the entrusting information according to the first transaction.
In one embodiment, the delegation information includes a consensus node information table, the consensus node information table includes an identifier of each consensus node and a weight, the weight is used for indicating the number of delegation nodes associated with each consensus node, and the updating unit is specifically configured to: deleting the information of the second node in the consensus node information table, and adding one to the weight of the third node.
In one embodiment, the delegation information further includes a delegation node information table, and the updating unit is specifically configured to: and recording the delegation of the second node to the third node in a delegation node information table.
In one embodiment, the consensus unit 72 is specifically configured to: generating self signature of the consensus proposal, receiving the signature of the consensus proposal by other consensus nodes from the other consensus nodes, calculating the obtained signature number of the consensus proposal according to the weight information of each consensus node, and confirming whether the consensus is successful or not according to the signature number.
In one embodiment, the delegation information of the first node further includes an identification of a fourth node delegating the first node, and the consensus node further includes: and the generation unit is used for generating a first block according to the consensus proposal after the consensus proposal is successful, and transmitting the first block to the fourth node.
In one embodiment, the blockchain includes a smart contract therein, the delegation information is stored in a contract state of the smart contract, and the first transaction invokes the smart contract.
In an embodiment, the delegation information further comprises a list of malicious nodes, and the receiving unit is further configured to: receiving a second transaction for indicating that a fifth node of the plurality of consensus nodes is a malicious node, the updating unit further being for: and executing the second transaction, deleting the information of the fifth node in the common node information table, and adding the identifier of the fifth node and the identifier of the delegation node associated with the fifth node in the malicious node list.
In one embodiment, the receiving unit is further configured to receive a third transaction, where the third transaction is used to indicate that a sixth node of the plurality of consensus nodes is a faulty node, perform the third transaction, delete information of the sixth node in the consensus node information table, and add an identifier and a weight of a delegate node associated with the sixth node in the consensus node information table.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the application does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.
For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.
Claims (13)
1. A consensus method performed by a first node in a blockchain, the blockchain including a plurality of consensus nodes, the first node being one of the plurality of consensus nodes, the method comprising:
obtaining delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes delegation any consensus node in the block chain to perform consensus;
performing a consensus operation on a consensus proposal based on the delegation information, comprising: generating self signature of the consensus proposal, receiving the signature of the consensus proposal from other consensus nodes, calculating the obtained signature number of the consensus proposal according to the number of the consignment nodes associated with each consensus node, and confirming whether the consensus is successful according to the signature number.
2. The method of claim 1, the method further comprising:
receiving a first transaction, wherein the first transaction is sent by a second node in the plurality of consensus nodes and is used for entrusting a third node in the plurality of consensus nodes to carry out consensus;
and deleting the information of the second node in the delegation information according to the first transaction, and updating the number of delegation nodes associated with the third node.
3. The method of claim 2, wherein the delegation information includes a table of consensus node information, the table of consensus node information includes an identification of each consensus node and a weight, the weight is used to indicate a number of delegation nodes associated with each consensus node, and updating the delegation information according to the first transaction includes:
deleting the information of the second node in the consensus node information table, and adding one to the weight of the third node.
4. The method of claim 3, further comprising a delegated node information table in the delegation information, the method further comprising: and recording the delegation of the second node to the third node in a delegation node information table.
5. The method according to claim 1 or 2, wherein the delegation information further comprises an identification of a fourth node delegating the first node, the method further comprising:
After the consensus proposal is successful, generating a first block according to the consensus proposal, and sending the first block to the fourth node.
6. The method of claim 2, wherein a smart contract is included in the blockchain, the delegation information is stored in a contract state of the smart contract, and the first transaction invokes the smart contract.
7. The method of claim 3, the delegation information further comprising a list of malicious nodes, the method further comprising: and receiving a second transaction, wherein the second transaction is used for indicating that a fifth node in the plurality of consensus nodes is a malicious node, executing the second transaction, deleting information of the fifth node in the consensus node information table, and adding an identifier of the fifth node and an identifier of a delegation node associated with the fifth node in the malicious node list.
8. A method according to claim 3, further comprising receiving a third transaction indicating that a sixth node of the plurality of consensus nodes is a faulty node, performing the third transaction to delete information of the sixth node in the consensus node information table and to add an identification and a weight of a delegate node associated with the sixth node in the consensus node information table.
9. A blockchain node, the blockchain including a plurality of consensus nodes, the blockchain node being one of the plurality of consensus nodes, comprising:
the obtaining unit is used for obtaining delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with each consensus node, and the delegation nodes are nodes delegation any consensus node in the block chain to perform consensus;
the consensus unit is used for performing consensus operation on the consensus proposal based on the delegation information, wherein the consensus unit is specifically used for: generating self signature of the consensus proposal, receiving the signature of the consensus proposal from other consensus nodes, calculating the obtained signature number of the consensus proposal according to the number of the consignment nodes associated with each consensus node, and confirming whether the consensus is successful according to the signature number.
10. The node of claim 9, further comprising:
a receiving unit, configured to receive a first transaction, where the first transaction is sent by a second node of the plurality of consensus nodes, and is used to delegate a third node of the plurality of consensus nodes to perform consensus;
And the updating unit is used for deleting the information of the second node in the delegation information according to the first transaction and updating the number of delegation nodes associated with the third node.
11. The node according to claim 10, wherein the delegation information includes a consensus node information table, the consensus node information table includes an identifier of each consensus node and a weight, the weight is used for indicating the number of delegation nodes associated with each consensus node, and the updating unit is specifically configured to:
deleting the information of the second node in the consensus node information table, and adding one to the weight of the third node.
12. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-8.
13. A consensus node comprising a memory having executable code stored therein and a processor, which when executing the executable code, implements the method of any of claims 1-8.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210325860.7A CN114710507B (en) | 2022-03-30 | 2022-03-30 | Consensus method, blockchain node, medium and consensus node |
| PCT/CN2022/135666 WO2023185059A1 (en) | 2022-03-30 | 2022-11-30 | Consensus method and blockchain node |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210325860.7A CN114710507B (en) | 2022-03-30 | 2022-03-30 | Consensus method, blockchain node, medium and consensus node |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114710507A CN114710507A (en) | 2022-07-05 |
| CN114710507B true CN114710507B (en) | 2023-10-27 |
Family
ID=82170823
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210325860.7A Active CN114710507B (en) | 2022-03-30 | 2022-03-30 | Consensus method, blockchain node, medium and consensus node |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN114710507B (en) |
| WO (1) | WO2023185059A1 (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114710507B (en) * | 2022-03-30 | 2023-10-27 | 蚂蚁区块链科技(上海)有限公司 | Consensus method, blockchain node, medium and consensus node |
| CN115658807A (en) * | 2022-09-30 | 2023-01-31 | 蚂蚁区块链科技(上海)有限公司 | Consensus method in block chain system, consensus node and block chain system |
| CN115665164A (en) * | 2022-09-30 | 2023-01-31 | 蚂蚁区块链科技(上海)有限公司 | Transaction processing method and device in blockchain system and blockchain system |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108133420A (en) * | 2018-01-10 | 2018-06-08 | 杭州复杂美科技有限公司 | A kind of commission common recognition method of block chain |
| CN108259235A (en) * | 2018-01-04 | 2018-07-06 | 杭州复杂美科技有限公司 | A kind of block chain accounting nodes selection method |
| CN108737175A (en) * | 2018-05-19 | 2018-11-02 | 上海分布信息科技有限公司 | A kind of node administration method and its realize system |
| CN109104396A (en) * | 2017-06-21 | 2018-12-28 | 上海钜真金融信息服务有限公司 | A kind of block chain agent authorization method based on allograph, medium |
| CN113269542A (en) * | 2021-04-07 | 2021-08-17 | 北京邮电大学 | Consensus method, device and storage medium for block chain system |
| CN113783697A (en) * | 2021-08-18 | 2021-12-10 | 区块链新科技(广州)有限公司 | Committee-based data broadcast service certification consensus protocol application method |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190354518A1 (en) * | 2018-05-01 | 2019-11-21 | Michael Zochowski | Chain mesh network for decentralized transaction systems |
| US11343073B2 (en) * | 2019-06-18 | 2022-05-24 | Electronics And Telecommunications Research Institute | Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance |
| CN111539726B (en) * | 2020-04-20 | 2024-03-19 | 中国工商银行股份有限公司 | Block chain consensus system and method |
| CN112184454B (en) * | 2020-11-09 | 2023-07-25 | 度小满科技(北京)有限公司 | Block chain consensus method, device, system and storage medium |
| CN114025012B (en) * | 2022-01-10 | 2022-03-22 | 国网电子商务有限公司 | Node selection method, device, storage medium and equipment based on credit grouping |
| CN114710507B (en) * | 2022-03-30 | 2023-10-27 | 蚂蚁区块链科技(上海)有限公司 | Consensus method, blockchain node, medium and consensus node |
-
2022
- 2022-03-30 CN CN202210325860.7A patent/CN114710507B/en active Active
- 2022-11-30 WO PCT/CN2022/135666 patent/WO2023185059A1/en unknown
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109104396A (en) * | 2017-06-21 | 2018-12-28 | 上海钜真金融信息服务有限公司 | A kind of block chain agent authorization method based on allograph, medium |
| CN108259235A (en) * | 2018-01-04 | 2018-07-06 | 杭州复杂美科技有限公司 | A kind of block chain accounting nodes selection method |
| CN108133420A (en) * | 2018-01-10 | 2018-06-08 | 杭州复杂美科技有限公司 | A kind of commission common recognition method of block chain |
| CN108737175A (en) * | 2018-05-19 | 2018-11-02 | 上海分布信息科技有限公司 | A kind of node administration method and its realize system |
| CN113269542A (en) * | 2021-04-07 | 2021-08-17 | 北京邮电大学 | Consensus method, device and storage medium for block chain system |
| CN113783697A (en) * | 2021-08-18 | 2021-12-10 | 区块链新科技(广州)有限公司 | Committee-based data broadcast service certification consensus protocol application method |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023185059A1 (en) | 2023-10-05 |
| CN114710507A (en) | 2022-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114710507B (en) | Consensus method, blockchain node, medium and consensus node | |
| US20190354518A1 (en) | Chain mesh network for decentralized transaction systems | |
| KR101159322B1 (en) | Efficient changing of replica sets in distributed fault-tolerant computing system | |
| CN111066047A (en) | Implementing a blockchain based workflow | |
| CN114827165B (en) | Method and block link point for grouping multiple transactions | |
| CN110263580B (en) | Data processing method and device based on block chain and block chain link points | |
| WO2023231337A1 (en) | Method for executing transaction in blockchain, and master node and slave node of blockchain | |
| WO2023231335A1 (en) | Method for executing transaction in blockchain, and master node of blockchain | |
| Azbeg et al. | An overview of blockchain consensus algorithms: comparison, challenges and future directions | |
| CN114936256A (en) | Method for executing transaction in block chain and block chain link point | |
| Yao et al. | Sok: A taxonomy for critical analysis of consensus mechanisms in consortium blockchain | |
| CN116366666A (en) | Chain state updating method and block link point in block chain system | |
| CN116645061A (en) | Customs clearance data processing method based on block chain system and consensus node | |
| CN114710350B (en) | Method and device for distributing callable resources, electronic equipment and storage medium | |
| CN115150409A (en) | Method for executing transaction in block chain system, block chain system and node | |
| Sheng et al. | TrustBoost: Boosting Trust among Interoperable Blockchains | |
| CN114697344B (en) | Method for determining consensus node in blockchain system, node, storage medium and computing device | |
| CN115174572B (en) | Data multicasting method in blockchain, blockchain node and storage medium | |
| CN116305311A (en) | Method and device for verifying read-write set in block chain system | |
| CN115174573B (en) | Data broadcasting method in block chain system, node and block chain system | |
| CN113987566B (en) | HYPERLEDGER FABRIC-based internal bridging cross-chain method, device, equipment and medium | |
| CN116668002A (en) | Transaction distribution method in blockchain system, blockchain node and blockchain system | |
| CN116455728A (en) | State data software version switching method, blockchain node and blockchain system | |
| CN118233075A (en) | Multi-party computing method, participant node, blockchain node and system based on blockchain system | |
| CN114780973A (en) | Method and device for managing accounts in block chain system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |