CN114710507A - Consensus method and block link point - Google Patents
Consensus method and block link point Download PDFInfo
- Publication number
- CN114710507A CN114710507A CN202210325860.7A CN202210325860A CN114710507A CN 114710507 A CN114710507 A CN 114710507A CN 202210325860 A CN202210325860 A CN 202210325860A CN 114710507 A CN114710507 A CN 114710507A
- Authority
- CN
- China
- Prior art keywords
- node
- consensus
- nodes
- information
- delegation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000003860 storage Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 9
- 230000008569 process Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 15
- 238000002360 preparation method Methods 0.000 description 15
- 230000007246 mechanism Effects 0.000 description 12
- 230000006872 improvement Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 8
- 230000008520 organization Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000012546 transfer Methods 0.000 description 4
- 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
- RTZKZFJDLAIYFH-UHFFFAOYSA-N Diethyl ether Chemical compound CCOCC RTZKZFJDLAIYFH-UHFFFAOYSA-N 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000018109 developmental process Effects 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
- 238000013459 approach 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
- 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
- 230000000977 initiatory effect Effects 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
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012544 monitoring process Methods 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
- 238000000275 quality assurance Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
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 consensus method and blockchain nodes, the method being 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: acquiring entrusting information of the consensus nodes from a block chain, wherein the entrusting information is used for indicating the number of entrusting nodes associated with the consensus nodes, and the entrusting nodes are nodes entrusting any consensus node in the block chain to perform consensus; performing consensus operations on consensus offers based on the delegation information.
Description
Technical Field
The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a consensus method and a block link point.
Background
The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.
Disclosure of Invention
The invention aims to provide a consensus scheme to improve consensus efficiency in a block chain.
A first aspect of the present specification provides 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: acquiring delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with all the consensus nodes, and the delegation nodes are nodes delegating any one of the consensus nodes to perform consensus in the block chain; performing consensus operations on consensus offers based on the delegation information.
A second aspect of the present specification provides a consensus node, comprising: an obtaining unit, configured to obtain delegation information from a block chain, 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 that delegates any one of the consensus nodes to perform consensus in the block chain; and the consensus unit is used for performing consensus operation on consensus suggestions based on the entrusted information.
A third aspect of the present specification provides a computer readable storage medium having stored thereon a computer program which, when executed on 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 stored therein an executable code, and a processor implementing the method of the first aspect when executing the executable code.
Through the consensus scheme provided by the embodiment of the specification, nodes participating in consensus are reduced to a smaller number through delegation among the nodes, consensus time is reduced, consensus efficiency is improved, consensus communication data volume is reduced, and cost is reduced.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.
FIG. 1 is a block chain architecture diagram in one embodiment;
FIG. 2 is a diagram illustrating a consensus process in a PBFT consensus algorithm, under an embodiment;
FIG. 3 is a flow diagram of a method for delegating nodes to agree on a blockchain in one embodiment of the present description;
FIG. 4 is a flow diagram of a consensus method in one embodiment of the present description;
fig. 5 is a flowchart of a method for setting a malicious node in a blockchain in an embodiment of the present specification;
FIG. 6 is a flow diagram of a method for canceling delegation of a consensus node when the consensus node fails in one embodiment of the present description;
fig. 7 is a structural diagram of a consensus node in one embodiment of the present specification.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present specification, 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 a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.
Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks through consensus, and the like. In the private chain, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. A federation chain is a block chain between public and private chains, and may implement "partial decentralization. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.
FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the block chain architecture diagram shown in fig. 1, the block chain 100 includes 7 nodes, for example, node 1-node 7. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. The nodes may have a full ledger stored on them, i.e. the status of all blocks and all accounts. Wherein each node in the blockchain can generate the same state in the blockchain by performing the same transaction, and each node in the blockchain can store the same state database. It is to be understood that although fig. 1 illustrates 7 nodes included in the blockchain, embodiments of the present specification are not limited thereto and may include other numbers of nodes. Specifically, the nodes included in the block chain can meet the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood as that byzantine nodes can exist in a block chain, and the block chain does not show the byzantine behavior to the outside. Generally, some Byzantine Fault-tolerant algorithms require the number of nodes to be greater than 3f +1, where f is the number of Byzantine nodes (i.e., malicious nodes), such as the practical Byzantine Fault-tolerant algorithm pbft (practical Byzantine Fault-tolerant algorithm).
A transaction in the blockchain domain may refer to a unit of a task that is performed in the blockchain and 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 the address of the account From which the transaction was initiated (i.e., From which a transfer task To another account was initiated), the To field indicates the address of the account From which the transaction was received (i.e., From which a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling an intelligent contract in a blockchain, a From field represents an account address for initiating the transaction, a To field represents an account address of the contract called by the transaction, and a Data field includes Data such as a function name in the calling contract and incoming parameters To the function, so as To obtain code of the function From the blockchain and execute the code of the function when the transaction is executed.
The block chain may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed by a transaction trigger on the blockchain system. An intelligent contract may be defined in the form of code. Calling the intelligent contract in the blockchain initiates a transaction pointing to the address of the intelligent contract, so that each node in the blockchain runs the intelligent contract code in a distributed mode. It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchains may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). Wherein the system contract is usable to add data structures for different services in a blockchain.
In the scenario of contract deployment, for example, Bob sends a transaction containing information to create an intelligent contract (i.e., a deployment contract) into the 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 null to indicate that the transaction is for contract deployment. After the agreement is achieved among the nodes through a consensus mechanism, a contract address '0 x6f8ae93 …' of the contract is determined, each node adds a contract account corresponding to the contract address of the intelligent contract in a state database, allocates a state storage corresponding to the contract account, and stores a contract code in the state storage of the contract, so that the contract creation is successful.
In the scenario of invoking a contract, for example, Bob sends a transaction for invoking a smart contract into the blockchain as shown in fig. 1, where the from field of the transaction is the address of the account of the transaction initiator (i.e., Bob), and "0 x6f8ae93 …" 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 identified in the blockchain, each node in the blockchain can execute the transaction respectively, so that the contract is executed respectively, and the state database is updated based on the execution of the contract.
The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. In various consensus algorithms, after a predetermined number of nodes agree on data to be agreed (i.e., a consensus proposal), it is determined that the consensus proposal is successful. Specifically, in the PBFT algorithm, for N ≧ 3f +1 consensus nodes, f malicious nodes can be tolerated, that is, when 2f +1 nodes among the N consensus nodes agree, it can be determined that consensus is successful.
FIG. 2 is a schematic diagram of the consensus process in the 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 (Request), Prepare (Pre-Prepare), Prepare (Prepare), and Commit (Commit). Assuming that a blockchain includes four common nodes, i.e., node n 1-node n4, where node n1 is a master node, and node n 2-node n4 is a slave node, according to the PBFT algorithm, 1 malicious node can be tolerated in node n 1-node n 4. In particular, during the request phase, the user of the blockchain may send a request, for example in the form of a blockchain transaction, to node n1 via his user device. In a preliminary phase, node n1, after receiving multiple transactions from one or more user devices, may package the multiple transactions into a consensus proposal, which may be sent to other consensus nodes (i.e., node n 2-node n4) along with the signatures of the consensus proposal by node n1 for use in generating blocks, which may include information about the transaction bodies of the multiple transactions and the order of submission of the multiple transactions. In the preparation phase, each slave node may sign the consensus proposal and send it to other respective nodes. Assuming node n4 is a malicious node, node n1, node n2, and node n3 may determine that the preparation phase is complete and may enter the commit phase after receiving the signatures for consensus proposals for 2f ═ 2 other consensus nodes, respectively. For example, as shown in fig. 2, node n1, after receiving the signatures of node n2 and node n3, verifies that the signatures of node n2 and node n3 are both correct signatures for consensus proposals, then determines that the preparation phase is complete, and node n2, after receiving the signature of node n3 and the signature of preparation phase node n1 and verifying that pass, determines that the preparation phase is complete. In the submission stage, each consensus node signs the consensus offer in the submission stage and sends the consensus offer to other consensus nodes, and after receiving the signatures of the submission stages of 2 f-2 other consensus nodes, each consensus node can determine that the submission stage is completed and the consensus is successful. For example, node n1, after receiving signatures of the commit phases of node n2 and node n3 and verifying, determines that the commit phase is complete, such that node n1 may perform performing the plurality of transactions according to consensus offers, generate and store tiles (e.g., tile B1) including the plurality of transactions, update the world state according to results of the performing of the plurality of transactions, and return results of the performing of the plurality of transactions to the user device. Similarly, node n2 and node n3, upon determining that the commit phase is complete, execute the plurality of transactions, generate and store block B1, and update the world state according to 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 node n 1-the node n4 can still achieve successful consensus on the consensus proposal in the presence of a malicious node, and complete the execution of the block.
In recent years, the size of the block chain is getting larger and more, and the service is also getting more and more complicated. As the scale of the node increases, when the multiple consensus nodes are identified through the process shown in fig. 2, multiple communications between the multiple consensus nodes will be required, so that the consensus efficiency is reduced. For example, in the block chain shown in fig. 1, the number of nodes is 7, and in the case where the 7 nodes all participate in the consensus, the number f of tolerable malicious nodes 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 signatures of 2f ═ 4 other nodes for the consensus proposal and verifying it.
In one related technique, a predetermined number of consensus nodes are voted up by a plurality of nodes. This related art generally operates on a public chain and is based on three key elements: 1) the excitation mechanism is as follows: incentivizing the nodes to participate in the contests and votes through issued virtual tokens, equities, interest, and the like awards; 2) right and quality assurance: by means of high enough interest pledge, the cost of doing malice is improved, the selected representative nodes cannot do malice, and the safety of the system is guaranteed; 3) treating under a chain: through the fund meeting under the chain, the governing of the arbitration meeting improves the value of the token and ensures the good operation of the system. However, since these elements are not typically included in the federation chain, the above-described consensus mechanism cannot be used in federation chains.
Therefore, the embodiment of the specification provides a scheme for converging the scale of the consensus node through a delegation mechanism, and the scheme can reasonably utilize some trust relationships among nodes in an actual project and support stable consensus of large-scale nodes.
Fig. 3 is a flowchart of a method for delegating nodes to agree on a blockchain in one embodiment of the present disclosure.
As shown in fig. 3, first, in step S301, the node 5 sends a transaction Tx1 to the blockchain for delegating the node 2 to consensus.
Assuming node 5 in fig. 1 treats node 2 as a trusted node, node 5 may send transaction Tx1 for delegation into the blockchain to delegate node 2 to agree on node 5. Node 5 and node 2 may be two nodes in the same organization, for example. Specifically, the node 5 may generate a transaction Tx1, and the transaction Tx1 may be used to invoke the pre-deployed intelligent contract C1 in the blockchain for recording the delegation information in the blockchain. Node 5, after generating transaction Tx1, may send transaction Tx1 to any node in the blockchain (e.g., node 1) to be identified and executed in the blockchain through the process shown in fig. 2.
In step S303, the node in the blockchain executes transaction Tx1, and records the delegation information in the blockchain.
Assuming that nodes 1-7 in the blockchain are all currently consensus nodes as shown in fig. 1, after the consensus proposed for the block (e.g. block B1) where the transaction Tx1 is located succeeds, the transaction Tx1 is executed respectively, and the world state is updated 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 the contract C1 after executing the transaction Tx 1.
In one embodiment, a consensus node information table may be stored in the contract state of the contract C1, such as shown in Table 1, before executing the transaction Tx 1:
TABLE 1
| Consensus node | Weight of | Delegation 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 to 7 are all consensus nodes, and the columns of the delegation nodes are all null, which indicates that no other node delegates its generation to perform consensus currently, and the weight is 1, which indicates that each consensus node only represents itself to perform consensus currently.
After the node 1 executes the completed transaction Tx1 and updates the contract status of the contract C1 according to the transaction Tx1, according to the transaction Tx1, since the node 5 commits the node 2 to commit, the node 5 does not perform consensus any more, 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, the consensus node information table is as shown in table 2:
TABLE 2
| Consensus node | Weight of | Delegation node |
| Node 1 | 1 | |
| Node 2 | 2 | Node 5 |
| Node 3 | 1 | |
| Node 4 | 1 | |
| Node 6 | 1 | |
| Node 7 | 1 |
Similarly, assuming that node 6 sends transaction Tx2 to the blockchain for delegating node 2 to agree on, and node 7 sends transaction Tx3 to the blockchain for delegating node 3 to agree on, the consensus node information table shown in table 3 can be obtained by sequentially executing transaction Tx2 and transaction Tx3 in the blockchain:
TABLE 3
| Consensus node | Weight of | Delegation node |
| Node 1 | 1 | |
| Node 2 | 3 | Node 5, node 6 |
| Node 3 | 2 | Node 7 |
| Node 4 | 1 |
After delegation is performed through the process as described above, the number of the consensus nodes in the block chain is reduced from 7 to 4, so that the traffic in the block chain consensus process can be greatly reduced. When nodes 1-4 agree, the number of signatures can be calculated based on the weights, so as to agree on behalf of the delegate node.
In another embodiment, the contract state of the contract C1 also includes a delegation node information table that includes, for example, an identification of nodes that delegate consensus to other nodes and an identification of corresponding trusted nodes. The nodes in the blockchain also update the principal node information table in the contract state of contract C1 after performing each transaction for the principal node. For example,
after performing the transaction Tx3, node 1 may generate a trusted node information table as shown in table 4:
TABLE 4
| Delegation node | Entrusted node |
| Node 5 | Node 2 |
| Node 6 | Node 2 |
| Node 7 | Node 3 |
It is to be understood that, in the embodiment of the present specification, the delegation information recorded in the blockchain is not limited to the above, and as long as the delegation information can indicate the number of delegation nodes corresponding to the respective consensus nodes, the consensus method provided in the embodiment of the present specification can be performed.
Fig. 4 is a flowchart of a consensus method in an embodiment of the present specification. The consensus method can be executed by any consensus node in the block chain, and specifically comprises the following steps:
step S401, obtaining entrusted information from a block chain;
in step S403, consensus operation is performed based on the request 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 block chain.
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 status of the contract C1 in 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 generates a consensus proposal, for example, including the plurality of transactions in block B2 to be generated and the submission order of the plurality of transactions, after receiving the plurality of transactions from one or more user devices. In order to perform consensus with the consensus nodes in the blockchain, the node 1 needs to acquire information of each consensus node in the blockchain. Therefore, node 1 can read the common node information table shown in table 3 from the blockchain. Specifically, node 1 may initiate a query request (or query transaction) to invoke contract C1 to query the contract C1 current consensus node information table from local.
In step S403, each consensus node performs consensus operation based on the delegation information.
Specifically, in the preparation stage, the node 1 sends the consensus proposal and the signature of the consensus proposal by the node 1 to the node 2, the node 3 and the node 4, respectively, based on the identification of each consensus node in table 3.
In the preparation phase, node 2, node 3 and node 4 sign the consensus proposal, respectively, and send the consensus proposal and its signature to the other consensus nodes, respectively. For example, node 1 receives signatures proposed by node 2 and node 3, and node 1 may calculate the number of signatures obtained S1 according to the weights of node 1, node 2 and node 3 in the consensus node information table, i.e., S1 ═ 1+3+2 ═ 6. As described above, in the block chain shown in fig. 1, 2 malicious nodes can be tolerated, and therefore, each of the common nodes needs to obtain signatures of 2f + 15 common nodes to confirm the completion of the preparation stage. Node 1 calculates the signature number S1 ═ 6>5 as described above, and therefore can confirm that the preparation phase is complete.
After receiving the signatures proposed by the nodes 1 and 3, the node 2 may calculate the number of signatures S2 ═ 1+3+2 ═ 6>5 according to the weights of the nodes 1, 2, and 3 in table 3, and thus may confirm that the preparation phase is completed.
Node 3 and node 4 may similarly determine that the preparation phase is complete.
After the preparation phase is completed, nodes 1-4 send the signatures of the preparation phase for the consensus proposal to the other consensus nodes in table 3, respectively. 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 has completed the consensus on block B2, perform the transactions in block B2, respectively, generate block B2, and update the world state according to the results of the block B2. Nodes 1-4 may then each send generated tile B2 to their respective delegate node. Specifically, node 2 may send its generated tile B2 to node 5 and node 6, and node 3 may send its generated tile B2 to node 7. After receiving the block B2, each delegate node stores the block B2 and updates the world state by performing transactions included in the block B2 to reach the world state consistent with the consensus node.
In another embodiment, each consensus node may broadcast a block synchronization event to each node of the blockchain after generating block B2. Upon receipt of the event, the delegate node synchronizes block B2 from its delegated consensus node. In another embodiment, the delegating node can periodically send a query request to its delegated consensus node to query the consensus node for its block height, and upon finding that the consensus node's block height is higher than its own block height, synchronize a new block from its delegated consensus node.
During the process of consensus, each consensus node may record information such as an identifier of a source node of each received signature in a log, so that in the case that a divergence occurs in the received consensus offers (i.e. a different consensus offer and its signature are received), a malicious node in the consensus nodes may be locked according to the log. After the consensus node determines the malicious node, the malicious node and the delegate node thereof can be recorded in the blockchain to limit participation in consensus.
Fig. 5 is a flowchart of a method for setting a malicious node in a blockchain in an embodiment of the present specification.
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 may determine, by querying the contract state of the intelligent contract, that the weight of the node 3 is 2, which is the number of malicious nodes tolerable by the block chain, and therefore, the node 3 may be set as a malicious node in the block chain through the consensus.
Specifically, at step S501, node 4 sends transaction Tx4 to node 1, and transaction Tx4 may be used to invoke the above-described intelligent contract for setting node 3 as a malicious node in the blockchain.
In step S503, the consensus node in the blockchain executes the transaction Tx4, and updates the delegation information in the blockchain.
After receiving the consensus proposal for the tile B3 including the transaction Tx4, the current consensus nodes (node 1-node 4) in the tile chain agree on the consensus proposal through the process shown in FIG. 2, and since the sum of the weights of the respective consensus nodes (7) and the weight of the malicious node (node 3) 2 satisfy the relationship of 3f +1: f, the nodes 1-node 3 can agree on the consensus proposal successfully. Taking node 1 as an example, after the consensus proposal for the block B3 succeeds, the node 1 performs the transaction Tx4, deletes the information of the node 3 in table 3, deletes the information of the node 7 in table 4 in the contract state of the contract C1, and puts the node 3 and the node 7 in the malicious node list in the contract state, and after the node 3 and the node 7 are added to the malicious node list, neither the node 3 nor the node 7 can participate in the consensus anymore, but the block can only be synchronized from any consensus node.
It is understood that, in the case where the consensus node determines that the node 2 is a malicious node, since the weight of the node 2 is 3, the sum (7) of the weights of the respective consensus nodes cannot satisfy the relationship less than or equal to f:3f +1, and thus the node 2 cannot be set as a malicious node by performing a transaction.
In addition, the consensus nodes can monitor the operation state mutually, or the entrusting node can monitor the state of the consensus node entrusted by the entrusting node after entrusting the consensus node, and when monitoring that the consensus node has a fault, the transaction can be sent to the block chain so as to cancel the entrusting of the consensus node by the entrusting node.
Fig. 6 is a flowchart of a method for canceling delegation to a consensus node when the consensus node fails according to an embodiment of the present specification.
Assuming that the node 4 determines that the node 3 has failed, as shown in fig. 6, the node 4 may send a transaction Tx5 calling the contract C1 described above to the node 1 for canceling the delegation of the delegating node (i.e., the node 7) to the node 3 at step S601.
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 weight of node 3 and the sum of the weights of all consensus nodes satisfy the relationship of f:3f +1, node 2, and node 4 may agree successfully with transaction Tx5 and update the delegation information according to transaction Tx 5. Specifically, taking node 1 as an example, after node 1 performs transaction Tx5 and successfully recognizes, it deletes the information of node 3 in the recognition node information table in table 3, adds node 7 as a recognition node, and deletes the information of node 7 in the request node information table shown in table 4.
Fig. 7 is a structural diagram of a consensus node in an embodiment of the present specification, 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 the number of delegation nodes associated with each consensus node, and the delegation node is a node that delegates any one of the consensus nodes to perform consensus in the blockchain;
a consensus unit 72 for performing a consensus operation on 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 multiple consensus nodes, and is used to delegate a third node of the multiple consensus nodes to perform consensus; and the updating unit is used for updating the entrusting information according to the first transaction.
In an embodiment, the delegation information includes a consensus node information table, where the consensus node information table includes an identifier and a weight of each consensus node, where the weight is used to indicate the number of delegation nodes associated with each consensus node, and the updating unit is specifically configured to: and deleting the information of the second node in the consensus node information table, and adding one to the weight of the third node.
In an 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: and generating a self signature to the consensus proposal, receiving the signatures of the other consensus nodes to the consensus proposal from other consensus nodes, calculating the number of acquired signatures to the consensus proposal according to the weight information of each consensus node, and confirming whether consensus succeeds or not according to the number of the signatures.
In one embodiment, the delegation information of the first node further includes an identifier of a fourth node that delegates to the first node, and the consensus node further includes: and the generating unit is used for generating a first block according to the consensus proposal after the consensus proposal is successfully agreed, and sending the first block to the fourth node.
In one embodiment, the blockchain includes an intelligent contract, the delegation information is stored in a contract state of the intelligent contract, and the first transaction invokes the intelligent contract.
In one embodiment, the delegation information further includes a list of malicious nodes, and the receiving unit is further configured to: receiving a second transaction indicating a fifth node of the plurality of consensus nodes as a malicious node, the updating unit further configured to: and executing the second transaction, deleting the information of the fifth node in the consensus node information table, and adding the identifier of the fifth node and the identifier of the entrusting 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 in the multiple consensus nodes is a failed node, execute the third transaction to 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 a technology could clearly distinguish between improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements to process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, 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 for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that with future developments in computer technology, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, 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 approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or 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, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.
For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
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 computer storage media 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, 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 that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
As will be appreciated by one skilled in the art, 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. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
One or more embodiments of the present description 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 can 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.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," 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 specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer 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, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.
Claims (15)
1. A consensus method performed by a first node in a blockchain, the blockchain comprising a plurality of consensus nodes, the first node being one of the plurality of consensus nodes, the method comprising:
acquiring delegation information from a block chain, wherein the delegation information is used for indicating the number of delegation nodes associated with all the consensus nodes, and the delegation nodes are nodes delegating any one of the consensus nodes to perform consensus in the block chain;
performing consensus operations on consensus offers based on the delegation information.
2. The method of claim 1, further comprising:
receiving a first transaction, wherein the first transaction is sent by a second node of the plurality of consensus nodes and used for entrusting consensus of a third node of the plurality of consensus nodes;
and deleting the information of the second node in the entrusting information according to the first transaction, and updating the number of entrusting nodes related to the third node.
3. The method of claim 2, wherein the delegation information comprises a consensus node information table, wherein the consensus node information table comprises an identifier and a weight of each consensus node, wherein the weight is used to indicate a number of delegation nodes associated with each consensus node, and wherein updating the delegation information according to the first transaction comprises:
and 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, the delegation information further comprising a delegation node information table, 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 of claim 1 or 2, the performing a consensus operation on a consensus proposal based on the delegation information comprising: and generating own signature for the consensus proposal, receiving the signatures of the other consensus proposals from other consensus nodes, calculating the number of acquired signatures for the consensus proposal according to the number of the entrusted nodes associated with each consensus node, and confirming whether the consensus is successful according to the number of the signatures.
6. The method of claim 1 or 2, further comprising an identification of a fourth node that delegates the first node in the delegation information, the method further comprising:
after the consensus is successful on the consensus proposal, a first block is generated according to the consensus proposal and is sent to the fourth node.
7. The method of claim 2, wherein the blockchain includes an intelligent contract, the delegation information is stored in a contract state of the intelligent contract, and the first transaction invokes the intelligent contract.
8. The method of claim 3, the delegation information further comprising a list of malicious nodes, the method further comprising: receiving a second transaction, where the second transaction is used to indicate a fifth node in the multiple consensus nodes as 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.
9. The method of claim 3, further comprising receiving a third transaction indicating a sixth node of the plurality of consensus nodes is a failed node, executing the third transaction to delete information of the sixth node in the consensus node information table and add an identification and a weight of a delegate node associated with the sixth node in the consensus node information table.
10. A block link point, comprising:
an obtaining unit, configured to obtain delegation information from a block chain, where the delegation information is used to indicate the number of delegation nodes associated with each consensus node, and the delegation node is a node that delegates any one of the consensus nodes to perform consensus in the block chain;
and the consensus unit is used for performing consensus operation on consensus suggestions based on the entrusted information.
11. The node of claim 10, further comprising:
a receiving unit, configured to receive a first transaction, where the first transaction is sent by a second node of the multiple consensus nodes, and is used to delegate a third node of the multiple consensus nodes to perform consensus;
and the updating unit is used for deleting the information of the second node in the entrusted information according to the first transaction and updating the number of the entrusted nodes related to the third node.
12. The node according to claim 11, wherein the delegation information includes a consensus node information table, the consensus node information table includes an identifier and a weight of each consensus node, the weight is used to indicate the number of delegation nodes associated with each consensus node, and the updating unit is specifically configured to:
and deleting the information of the second node in the consensus node information table, and adding one to the weight of the third node.
13. The node according to claim 10 or 11, wherein the consensus unit is specifically configured to: and generating own signature for the consensus proposal, receiving the signatures of the other consensus proposals from other consensus nodes, calculating the number of acquired signatures for the consensus proposal according to the number of the entrusted nodes associated with each consensus node, and confirming whether the consensus is successful according to the number of the signatures.
14. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-9.
15. A consensus node comprising a memory having stored therein executable code and a processor that, when executing the executable code, implements the method of any of claims 1-9.
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 true CN114710507A (en) | 2022-07-05 |
| CN114710507B 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) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023185059A1 (en) * | 2022-03-30 | 2023-10-05 | 蚂蚁区块链科技(上海)有限公司 | Consensus method and blockchain node |
| WO2024066010A1 (en) * | 2022-09-30 | 2024-04-04 | 蚂蚁区块链科技(上海)有限公司 | Method and apparatus for transaction processing in blockchain system, and blockchain system |
| WO2024066006A1 (en) * | 2022-09-30 | 2024-04-04 | 蚂蚁区块链科技(上海)有限公司 | Consensus method and consensus node in blockchain system, and blockchain system |
Citations (7)
| 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 |
| US20200403776A1 (en) * | 2019-06-18 | 2020-12-24 | Electronics And Telecommunications Research Institute | Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance |
| 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 (5)
| 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 |
| 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 (7)
| 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 |
| US20200403776A1 (en) * | 2019-06-18 | 2020-12-24 | Electronics And Telecommunications Research Institute | Apparatus and method for achieving distributed consensus based on decentralized byzantine fault tolerance |
| 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 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023185059A1 (en) * | 2022-03-30 | 2023-10-05 | 蚂蚁区块链科技(上海)有限公司 | Consensus method and blockchain node |
| WO2024066010A1 (en) * | 2022-09-30 | 2024-04-04 | 蚂蚁区块链科技(上海)有限公司 | Method and apparatus for transaction processing in blockchain system, and blockchain system |
| WO2024066006A1 (en) * | 2022-09-30 | 2024-04-04 | 蚂蚁区块链科技(上海)有限公司 | Consensus method and consensus node in blockchain system, and blockchain system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114710507B (en) | 2023-10-27 |
| WO2023185059A1 (en) | 2023-10-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108898390B (en) | Intelligent contract calling method and device based on block chain and electronic equipment | |
| CN109003078B (en) | Intelligent contract calling method and device based on block chain and electronic equipment | |
| JP7379332B2 (en) | Systems and methods for simultaneous bytecode interpretation implemented by blockchain | |
| US20190354518A1 (en) | Chain mesh network for decentralized transaction systems | |
| CN114710507A (en) | Consensus method and block link point | |
| US20200082398A1 (en) | Proof-of-Devotion Blockchain Consensus Algorithm | |
| US20220147512A1 (en) | Blockchain-based transaction methods | |
| 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 | |
| CN111753335A (en) | Editing method and device for block content | |
| CN110263580B (en) | Data processing method and device based on block chain and block chain link points | |
| Azbeg et al. | An overview of blockchain consensus algorithms: comparison, challenges and future directions | |
| CN114942847A (en) | Method for executing transaction and block link point | |
| CN114936256A (en) | Method for executing transaction in block chain and block chain link point | |
| CN114827165A (en) | Method and block link point for grouping multiple transactions | |
| US20200202355A1 (en) | Storage and execution of smart contracts in blockchains | |
| US20210073197A1 (en) | Byzantine consensus without centralized ordering | |
| CN113206893B (en) | Method for block synchronization and node joining block chain network | |
| CN115860884A (en) | Method and device for processing digital resources in block chain system | |
| CN115174572B (en) | Data multicasting method in blockchain, blockchain node and storage medium | |
| CN116012155B (en) | Method and device for processing digital resources in blockchain | |
| CN116186763A (en) | Method and apparatus for processing block data in a blockchain system | |
| EP4036778A1 (en) | Receipts of a distributed ledger | |
| CN115098595A (en) | Node grouping method in blockchain system and blockchain node | |
| CN116305311A (en) | Method and device for verifying read-write set 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 |