WO2021042880A1 - 区块链网络中删除节点的方法和区块链系统 - Google Patents

区块链网络中删除节点的方法和区块链系统 Download PDF

Info

Publication number
WO2021042880A1
WO2021042880A1 PCT/CN2020/102350 CN2020102350W WO2021042880A1 WO 2021042880 A1 WO2021042880 A1 WO 2021042880A1 CN 2020102350 W CN2020102350 W CN 2020102350W WO 2021042880 A1 WO2021042880 A1 WO 2021042880A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
consensus
nodes
deleted
list
Prior art date
Application number
PCT/CN2020/102350
Other languages
English (en)
French (fr)
Inventor
陈盛龙
邓福喜
谢桂鲁
夏凝
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Publication of WO2021042880A1 publication Critical patent/WO2021042880A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This application relates to the field of computer technology, and in particular to a method for deleting nodes in a blockchain network and a blockchain system.
  • Blockchain technology is built on a transmission network (such as a peer-to-peer network).
  • the network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data. Nodes in these blockchain networks sometimes need to be increased.
  • the purpose of the embodiments of the present application is to provide a method for deleting nodes in a blockchain network and a blockchain system.
  • the method for deleting a node in a blockchain network includes: the first consensus node in the blockchain network receives a transaction request for deleting a node, and initiates a consensus on the transaction request of the deleted node; after reaching a consensus, the consensus node executes the deletion Node transactions are sequentially numbered for the remaining consensus nodes except the node to be deleted; the consensus node initiates a view switch; after the view switch is completed, the remaining consensus node participates in the consensus process of the blockchain.
  • a block chain system includes: a first consensus node, which is used to receive a transaction request of a deleted node, and initiate a consensus on the transaction request of the deleted node; the consensus node is used to execute the deletion after a consensus is reached The transaction of the node is used to sequentially number the remaining consensus nodes except the node to be deleted; it is also used to initiate a view switch; the remaining consensus node is used to participate in the consensus process of the blockchain after the view switch is completed.
  • the remaining consensus nodes after deleting the node each have the same node number list locally, so that the remaining consensus nodes after deleting the node can normally participate in the consensus. . In this way, the process of deleting nodes is completed.
  • Fig. 1 is a diagrammatic process of creating a smart contract according to an embodiment of the application.
  • Figure 2 is a diagrammatic process of invoking a smart contract according to an embodiment of the application.
  • Figure 3 is a schematic diagram of creating a smart contract and invoking a smart contract in an embodiment of the application.
  • Figure 4 is a flowchart of the PBFT algorithm.
  • Figure 5 is a schematic diagram of the PBFT algorithm that needs to be restored after the view is switched.
  • Figure 6 is a schematic diagram of the view switching process in the PBFT algorithm.
  • FIG. 7 is a flowchart of an embodiment of deleting a node in the alliance chain of the application.
  • FIG. 8 is a structural diagram of an embodiment of a blockchain system of this application.
  • the embodiment of the present application provides a method for deleting a node in a blockchain network and a blockchain system.
  • Block chains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • the public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations.
  • the private chain is the opposite.
  • the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization/institution. To put it simply, the private chain can be a weakly centralized system with strict restrictions and a small number of participating nodes.
  • a smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system.
  • a smart contract on the blockchain is a contract that can be triggered and executed by a transaction on the blockchain system.
  • Ethereum Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network. This is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology.
  • the core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM.
  • EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users can publish and call smart contracts in Ethereum that can run on the EVM.
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • "0x6f8ae93" in Figure 1 represents the address of this contract.
  • the data field of the transaction can be stored as bytecode, and the to field of the transaction is an empty account.
  • a contract account corresponding to the smart contract appears on the blockchain and has a specific address.
  • the contract code and account storage will be stored in the contract account.
  • the behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract.
  • smart contracts enable virtual accounts containing contract codes and account storage (Storage) to be generated on the blockchain.
  • the EVM of node 1 can execute the transaction and generate a corresponding contract instance.
  • the from field of the transaction in Figure 2 is the address of the account that initiated the call to the smart contract, the "0x6f8ae93" in the to field represents the address of the smart contract being called, and the value field is the value of the ether in Ethereum.
  • the transaction is The method and parameters of calling the smart contract stored in the data field. After calling the smart contract, the value of balance may change. Later, a certain client can view the current value of balance through a certain blockchain node (for example, node 6 in Figure 2).
  • Smart contracts can be independently executed on each node in the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain, so when such a transaction is completed, the blockchain is stored and cannot be tampered with. , A transaction certificate that will not be lost.
  • FIG. 3 The schematic diagram of creating a smart contract and invoking a smart contract is shown in Figure 3.
  • To create a smart contract in Ethereum you need to go through the process of writing a smart contract, turning it into bytecode, and deploying it to the blockchain.
  • Invoking a smart contract in Ethereum is to initiate a transaction that points to the address of the smart contract.
  • the smart contract code runs in a distributed manner in the virtual machine of each node in the Ethereum network.
  • smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, the data structure, parameters, attributes and methods of some blockchain networks can be set in the creation contract. In addition, an account with system administrator authority can create system-level contracts or modify system-level contracts (referred to as system contracts for short). In addition to the EVM in Ethereum, different blockchain networks may also use various virtual machines, which are not limited here.
  • One of the decentralized characteristics of blockchain technology that distinguishes it from traditional technologies is that accounting is performed on each node, or called distributed accounting, instead of traditional centralized accounting.
  • distributed accounting For the blockchain system to become a hard-to-break, open, and non-tamperable decentralized, honest and trustworthy system for data records, it needs to be safe, clear, and irreversible for distributed data records in the shortest possible time.
  • a consensus algorithm is usually used to ensure that, that is, the aforementioned consensus mechanism. After a node (such as a unique node) generates a block, if the generated block is approved by other nodes, the other nodes record the same block.
  • the process by which the blocks generated above are recognized by other nodes is the consensus mechanism.
  • the consensus mechanism is a mechanism by which blockchain nodes reach a consensus on block information throughout the network, which can ensure that the latest block is accurately deleted to the blockchain.
  • the current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), and Practical Byzantine Fault Tolerance (PBFT) ) Algorithm, HoneyBadgerBFT algorithm, etc.
  • Figure 4 shows the flow chart of the traditional PBFT algorithm.
  • This algorithm was proposed by Miguel Castro and Barbara Liskov in 1999. It solves the problem of low efficiency of the original Byzantine fault-tolerant algorithm and reduces the complexity of the algorithm from exponential level to polynomial level. , which makes the Byzantine fault-tolerant algorithm feasible in actual system applications.
  • the paper was published at the 1999 International Conference on Operating System Design and Implementation (OSDI99). The algorithm assumes that when there are at most f replicas (that is, nodes) fail, if there are at least 3f+1 replicas in total, the security and liveness can be guaranteed in the asynchronous system.
  • OSDI99 Operating System Design and Implementation
  • a set of a certain number of replicas is required, which is generally a set composed of most nodes in a distributed system, constituting the majority (Quorum). For example, when the total number of nodes n is 3f+1, Quorum is 2f+1. In this way, for a distributed system containing four nodes, any three nodes can form a Quorum.
  • all replicas run in a succession of configuration called a view.
  • a view In a certain view, one copy is used as the primary node, and the other copies are used as backups. Views are consecutively numbered integers.
  • the client c sends a request to the master node 0 (ie replica 0);
  • the master node 0 sends the request to each backup node through broadcast;
  • the client needs to wait for f+1 different replica nodes to send back the same result as the final result of the entire operation.
  • the numbers of the four nodes are 0, 1, 2, and 3 respectively, and the bad node is node 3, and the process includes S1-S5.
  • the master node 0 After the master node 0 receives the client request (or a group of client requests), it sorts the requests (for a group of client requests) and packs it into a message m, and then sends it
  • the pre-prepare request is sent to nodes 1, 2, and 3 (that is, backup nodes 1, 2, 3, also replica 1, 2, 3, hereinafter referred to as nodes), and the pre-prepare request includes message m;
  • nodes 1, 2, and 3 After nodes 1, 2, and 3 receive the request, if the check message m is legal, they will broadcast again respectively. Specifically, node 1 spreads the prepare message to nodes 0, 2, and 3, and node 2 spreads the prepare message to nodes 0, 1, 3, and node 3 is, for example, a bad node that cannot be broadcast due to a downtime. Moreover, each node also receives prepare messages broadcast by other nodes. Each node deletes the prepare message (representing its own approval) and the received prepare message (representing the approval of other nodes) to the local Log. If a node receives Quorum-1 confirmations for the same message from different nodes (including pre-prepare and prepare messages, so there are a total of Quorum in the local Log), it changes to the prepared state.
  • each participating consensus node After each participating consensus node enters the prepared state, it sends a commit message to other consensus nodes, and deletes the commit message sent by itself to the local Log (representing its own approval), and, Each node also receives commit messages broadcast by other nodes. If a node receives a number of legal commit messages of Quorum-1 from different nodes, it is deleted to the local Log (at this time, the total number of Quorums that it has deleted to the local Log is added), and it changes to the committed state.
  • the client receives f+1 identical REPLY messages, it indicates that the request initiated by the client has reached a consensus of the entire network, otherwise the client c may need to determine whether to resend the request to the master node 0.
  • the consensus process can be initiated by a certain node, that is, it mainly includes the PRE-PREPARE, PREPARE, and COMMIT processes in Figure 4 above.
  • clients may or may not be included. If the client is not included, there is no need to have the REQUEST and REPLY links in Figure 4, but the PBFT consensus is initiated after the master node collects a certain amount of transactions. If the client is included, the consensus process may not be initiated by the client, but the master node initiates the PBFT consensus after collecting a certain amount of transactions, that is, the REQUEST in the process of Figure 4 does not directly lead to the start of the PRE-PREPARE phase.
  • the client can set a timeout mechanism. If it times out, the client can broadcast a request message to all replica nodes. After the replica node detects that the master node is malicious or offline, it can also initiate the View Change protocol phase to replace the master node.
  • the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to the wrong proposal initiated by the master node, or the number of Quorum may not be consistent in the PRE-PREPARE and COMMIT phases, and consensus cannot be completed.
  • the View Change protocol phase may also be initiated to replace the master node.
  • the master node Replica 0 has entered the committed (submitted) state for the propose m5 corresponding to ⁇ v,n,d> in the view V before the VC, and has executed the propose m5, while Replica 1 may not be correct due to network delays.
  • the proposed m5 enters the committed state, but the prepared state.
  • Replica 2 (and 3) may also be prepared for propose m5. After that, Replica 0 went down. In this way, different nodes have different states.
  • Replica 0 may restart and recover. For example, if the master node is replaced with Replica 1, Replica 1-3 needs to keep up with the pace of Replica 0, so the new master node Replica 1 needs to resend prepare m5. , Let Replica 1-3 finish execution, to be consistent with the status of Replica 0. Otherwise, it is possible that Replica 1-3 completed the three-phase consensus on the new message m6 in the new view V+1, but only replica 0 completed the execution of m5 before, in fact, replica 1-3 did not complete the execution of m5.
  • the execution of the new message m6 by Replica 1-3 in the new view V+1 starts in a state different from that of replica 0, so that inconsistencies in the state machines on different nodes will occur, forming a fork.
  • Replica 0 is only in the prepared state for m5, that is, it is not executed on the state machine, and other Replicas are processed more slowly than Replica 0, the prepared state reached by Replica 0 can be deleted without affecting the global state consistency. .
  • a replica node that detects that the master node is malicious or offline can broadcast a ⁇ VIEW-CHANGE,v+1,n,C,P,i> message to other replica nodes.
  • replica 1 detects that the original master node replica 0 is malicious or offline, then replica 1 sends ⁇ VIEW-CHANGE,v+1,n,C,P,i> to replica 0, replica 2, and replica 3 Message; similarly, replica 2 sends ⁇ VIEW-CHANGE,v+1,n,C,P,i> to replica 0, replica 1, and replica 3, and replica 3 sends ⁇ VIEW-CHANGE, v+1,n,C,P,i> to replica 0, replica 1, and replica 3 -CHANGE,v+1,n,C,P,i>message.
  • VIEW-CHANGE is the protocol identifier, which indicates that the protocol is the VIEW-CHANGE protocol; v+1 is the number of the next view; n is the number of the latest stable checkpoint; C is the 2f+1 verified A collection of CheckPoint messages; P is optional. If there is one, it means that the replica node that currently sends the VIEW-CHANGE message has reached a collection of several messages in the prepared state (corresponding to the ⁇ v,n,d> of each prepared state, including pre -prepare the message and the signature of 2f different nodes).
  • the new master node p (v+1)mod
  • NEW-VIEW is the protocol identifier, identifying that the protocol is the NEW-VIEW protocol;
  • v+1 is the number of the next view;
  • V is the signed view-change message sent by 2f different nodes received by the new master node, and The view-change message for v+1 that the new master node wants to send or has already sent.
  • O is a collection of unfinished PRE-PREPARE messages re-initiated by the master node.
  • p is the signature of the current node.
  • the selection rules of PRE-PREPARE message set include:
  • the replica node receives the NEW-VIEW message from the master node and verifies that the signature is legal and the view-change message in V is legal, and O is legal. If it is legal, enter the v+1 state, and start the PRE-PREPARE message processing flow in O.
  • a node can correspond to one or more accounts.
  • a node may not correspond to any account, but only serves as a consensus node.
  • the creation contract and the system contract can be generated as described above.
  • the consensus node list of the alliance chain can be set in the creation contract/system contract, for example, a set of public keys of the consensus nodes is set, and the public keys in the set are arranged in a certain order.
  • Each consensus node in the alliance chain can store a local node list locally according to the consensus node list set in the creation contract.
  • Each consensus node in its local node list can arrange the consensus nodes according to the corresponding public key according to the specific order given in the creation contract/system contract, so that each consensus node has the same local node list. Consensus nodes and these consensus nodes are arranged in the same order. Moreover, the method and parameters for deleting consensus nodes can be set in the creation contract/system contract, so that, according to the creation contract/system contract, the node can change the node in the local node list to complete the operation of deleting the node.
  • the request is, for example, a transaction request
  • the first consensus node can receive the request.
  • the request may be, for example, a transaction request for deleting a node initiated by a client to trigger the process of deleting the node to be deleted, or a transaction request for deleting a node initiated by the console command end received by the first consensus node, thereby triggering The process of deleting the node to be deleted.
  • the console can generally be operated by an administrator who controls the node, for example, through graphical or coded instructions to initiate operations. It should be noted that for master consensus algorithms such as PBFT, the first consensus node is generally the master node.
  • the first consensus node may be a transaction request sent directly from the client or console, or it may be a transaction request that is transferred and received through other consensus nodes.
  • unowned consensus algorithms such as HoneyBadgerBFT, if there is no master node, the first consensus node is one of multiple equal consensus nodes.
  • the process of deleting nodes in the alliance chain includes S701-S705.
  • the first consensus node in the blockchain network receives the transaction request of the deleted node, and initiates a consensus on the transaction request of the deleted node; after reaching a consensus, the consensus node executes the transaction of the deleted node to remove the node to be deleted
  • the remaining consensus nodes are numbered sequentially.
  • the transaction request may be a transaction request for calling a contract.
  • the called contract is the aforementioned creation contract/system contract
  • the called method is the method of deleting the node
  • the incoming parameters include, for example, one or more of the identification of the node to be deleted, IP address, and port number.
  • the first consensus node can trigger the process of deleting a node by receiving a transaction request to delete the node.
  • the first consensus node can trigger the process of deleting the node to be deleted by receiving a transaction request to delete the node initiated by the client, or it can be the deletion node initiated by the first consensus node by receiving the console command terminal.
  • the transaction request triggers the process of deleting the node to be deleted.
  • the console can generally be operated by an administrator who controls the node, for example, through graphical or coded instructions to initiate operations.
  • the first consensus node may also receive the related information of the node to be deleted from the node to be deleted, so as to initiate the process of deleting the node to be deleted.
  • the transaction request to delete a node is generally propagated to each consensus node based on the underlying peer-to-peer (P2P) network in the blockchain network.
  • P2P peer-to-peer
  • the first consensus node can initiate a consensus process as a master node with a master consensus algorithm or a consensus node without a master consensus algorithm.
  • a master consensus algorithm such as PBFT
  • the first consensus node can be the master node, and can initiate a consensus process for the transaction request including the deleted node, that is, mainly including the PRE-PREPARE, PREPARE, and COMMIT processes in Figure 4 above.
  • At least Quorum consensus nodes in the blockchain network have locally the message content in the transaction request of the delete node, and reach a consensus. Moreover, if the message content in the transaction request of the delete node and other messages constitute the consensus result, the message content in the transaction request of the delete node has the same message sequence on different nodes, that is, at least Quorum number of consensus nodes A consensus was reached on the content and order of the messages in the request to delete the node.
  • the consensus node can execute the corresponding contract locally.
  • the consensus node calls the aforementioned creation contract/system contract, executes the method specified in the called creation contract/system contract in a virtual machine such as EVM, and passes in corresponding parameters.
  • the incoming parameters include, for example, the identification, IP address, and port number of the node to be deleted.
  • the consensus node may delete the information of the node to be deleted based on the consensus node in the local node list, and sequentially number the remaining consensus nodes. In this way, at least the consensus node list maintained by the consensus nodes of Quorum already has the same remaining consensus nodes, and the remaining consensus nodes have the same sequence number.
  • the consensus node can locally maintain a consensus node list, that is, the aforementioned local node list, which records the basic information of all consensus nodes in the current blockchain network.
  • the basic information may include, for example, one or more of the identity, IP address, and port number of the consensus node.
  • the consensus nodes may be sequentially numbered in the local node list.
  • a consensus node generally has an identifier (ID), which can be an identifier that can uniquely identify the node, for example, the node's public key, IP address + port number, etc., of course, it can also be other content.
  • ID can be an identifier that can uniquely identify the node, for example, the node's public key, IP address + port number, etc., of course, it can also be other content.
  • the consensus node list may logically exist in the world state in some blockchain projects. Take the commercial projects of Ethereum, Fabric and some consortium chains as examples. Each node maintains the world state locally, in which the state of all accounts is up-
  • consensus nodes a, b, c, d, and m each have a list of local nodes stored in their respective world states, and the consensus nodes stored in the respective local node lists of consensus nodes a, b, c, d, and m are all There are five nodes a, b, c, d, and m, and they are all in the order of abcdm. Then, the numbers of a, b, c, d, and m are 0, 1, 2, 3, and 4, respectively.
  • each consensus node executes the processes of S701 and S702 in the embodiment of the present application on the basis of the consensus node list maintained locally, and the nodes in the local node list of each consensus node include a, b, There are 4 nodes in c and d, and the numbering sequence of the remaining consensus nodes is also the same, all 0-1-2-3.
  • the consensus node in the local node list can also include two states: activated and inactivated. Consensus nodes in the active state can normally participate in the consensus; while the consensus nodes in the inactive state do not participate in the consensus, so they are not numbered sequentially with other consensus nodes in the active state. In this way, in addition to deleting the node to be deleted from the local node list mentioned above, the consensus node can also set the status of the node to be deleted as inactive, thereby freezing the node to be deleted without deleting the node.
  • S703 The consensus node initiates a view switch.
  • the local node list is updated. In the current view, there are still all the nodes and the order of the original consensus participating nodes that have not performed the delete operation. In this way, after the consensus node executes the transaction of deleting the node, it will detect that the number of consensus nodes in the local consensus node list is inconsistent with the number of consensus nodes in the current view, or detect that the consensus node identification in the local consensus node list is consistent with the current one. There are inconsistencies in the identification of consensus nodes in the view. In this way, the consensus node can initiate a view switch.
  • R in the view switching process (that is, the number of replica sets during the view switching process) is the total number of consensus nodes including the nodes to be deleted, that is, the local node list includes the number of nodes to be added to the node.
  • the consensus node can broadcast the ⁇ VIEW-CHANGE,v+1,n,C,P,i> message to other replica nodes.
  • n is the number of the latest stable checkpoint
  • C is a set of 2f+1 verified CheckPoint messages
  • P is a set of PRE-PREPARE and PREPARE messages of the unfinished request of the current replica node.
  • the node to be deleted is node m
  • the remaining consensus nodes include nodes a, b, c, and d.
  • Node a is, for example, the primary node in PBFT
  • nodes b, c, d, and m are, for example, backup nodes in PBFT.
  • R is the number of remaining consensus nodes after removing the node to be deleted from the local node list.
  • each consensus node may be the sequence number of the remaining consensus nodes after removing the node to be deleted, so that only node a is left.
  • B, c, d the numbers are 0, 1, 2, 3.
  • R becomes 4.
  • the view number is incremented, that is, as described above, it changes from v to v+1.
  • each consensus node may be the sequence number of the remaining consensus nodes after removing the node to be deleted, so that only node a is left.
  • B, d, m are 0, 1, 2, and 3 after renumbering.
  • the consensus node initiates a view switch when it detects any of the following situations: the number of active consensus nodes in the local consensus node list and the number of consensus nodes in the current view There is an inconsistency; or, the active consensus node ID in the local consensus node list is inconsistent with the consensus node ID in the current view.
  • the remaining consensus nodes except the node to be deleted have the same node number list locally and have the same block data, so that the remaining consensus nodes can reach a consensus normally. In this way, the process of deleting nodes is completed.
  • FIG. 8 shows an architecture diagram of an embodiment of a blockchain system of the present application.
  • the blockchain system includes: a first consensus node 801 for receiving a transaction request for a deleted node and responding to transactions of the deleted node Request to initiate a consensus; consensus node 802, used to execute the transaction of the deleted node after reaching a consensus, to sequentially number the remaining consensus nodes 804 except for the node to be deleted 803; also used to initiate view switching; remaining consensus nodes 804. Used to participate in the consensus process of the blockchain after the view switching is completed.
  • the consensus node 802 includes a first consensus node 801, a node to be deleted 803, and a remaining consensus node 804.
  • the transaction request for deleting the node includes a transaction request for calling a contract.
  • the called contract includes a creation contract or a system contract.
  • the first consensus node 801 receives the transaction request for deleting the node, including: the first consensus node 801 receives the transaction request for deleting the node initiated by the client; or, the first consensus node 801 receives the transaction for deleting the node initiated by the console command terminal. request.
  • the consensus node 802 maintains a node list locally, and the node list includes one or more of the identity, IP address, and port number of the consensus node 802; wherein, the consensus node 802 is numbered sequentially in the local node list.
  • the node list maintained locally by the consensus node 802 is located in the world state.
  • the consensus node 802 executes the transaction for deleting the node, including: the consensus node 802 deletes the node to be deleted in the local node list; or, the consensus node 802 deletes the node to be deleted in the local node list
  • the status of is set to inactive.
  • the consensus node 802 initiates a view switch when detecting any of the following situations: the number of consensus nodes in the local consensus node list is inconsistent with the number of consensus nodes in the current view; or, the number of active consensus nodes in the local consensus node list There is an inconsistency with the number of consensus nodes in the current view; or, the consensus node ID in the local consensus node list is inconsistent with the consensus node ID in the current view; or, the active consensus node ID in the local consensus node list is inconsistent with that in the current view There are inconsistencies in the consensus node identification.
  • the consensus node 802 initiates view switching after receiving the message for initiating view switching broadcast by the node to be deleted 803.
  • the number of replica sets in the view switching process is the total number of remaining consensus nodes 804 excluding the node 803 to be deleted.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.
  • the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
  • processors CPU
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent 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 computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Retry When Errors Occur (AREA)
  • Hardware Redundancy (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请实施例公开了一种区块链网络中删除节点的方法和区块链系统。区块链网络中删除节点的方法包括：区块链网络中的第一共识节点接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；达成共识后，共识节点执行所述删除节点的交易，以对除待删除节点之外的剩余共识节点顺序编号；所述共识节点发起视图切换；所述视图切换完成后，所述剩余共识节点参与所述区块链的共识过程。

Description

区块链网络中删除节点的方法和区块链系统 技术领域
本申请涉及计算机技术领域，尤其涉及一种区块链网络中删除节点的方法和区块链系统。
背景技术
区块链技术构建在传输网络(例如点对点网络)之上。传输网络中的网络节点利用链式数据结构来验证与存储数据，并采用分布式节点共识算法来生成和更新数据。这些区块链网络中的节点有时需要增加。
针对此，需要提供一种区块链网络中删除节点的方法。
发明内容
本申请实施例的目的是提供一种区块链网络中删除节点的方法和区块链系统。
为解决上述技术问题，本申请实施例是这样实现的。
区块链网络中删除节点的方法，包括：区块链网络中的第一共识节点接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；达成共识后，共识节点执行所述删除节点的交易，以对除待删除节点之外的剩余共识节点顺序编号；所述共识节点发起视图切换；所述视图切换完成后，所述剩余共识节点参与所述区块链的共识过程。
一种区块链系统，包括：第一共识节点，用于接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；所述共识节点，用于在达成共识后，执行所述删除节点的交易，以并对除待删除节点之外的剩余共识节点顺序编号；还用于发起视图切换；剩余共识节点，用于在所述视图切换完成后参与所述区块链的共识过程。
由以上本申请实施例提供的技术方案可见，本申请实施例视图切换完成之后，删除节点之后的剩余共识节点本地各自存有相同的节点编号列表，从而删除节点后的剩余共识节点可以正常参与共识。这样，就完成了删除节点的过程。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使 用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一个实施例的创建智能合约的图示过程。
图2为本申请一个实施例的调用智能合约的图示过程。
图3为本申请一个实施例中创建智能合约和调用智能合约的示意图。
图4为PBFT算法的流程图。
图5为PBFT算法中需要在视图切换后进行恢复的原理图。
图6为PBFT算法中视图切换过程的原理图。
图7为本申请联盟链中删除节点的一个实施例的流程图。
图8为本申请一区块链系统实施例的架构图。
具体实施方式
本申请实施例提供一种区块链网络中删除节点的方法和区块链系统。
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织/机构规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且数量少。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。链上各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网 络并组成利益相关联盟，共同维护区块链运行。上述不同类型的区块链中，都有节点动态加入区块链网络的需求。
不论是公有链、私有链还是联盟链，都可能提供智能合约(Smart contract)的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约可以在EVM上运行的。
例如图1所示，Bob将一个包含创建智能合约的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x6f8ae93…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为一个空的账户。节点间通过共识机制达成一致后，这个合约成功创建，后续用户可以调用这个合约。
合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码和账户存储将保存在该合约账户中。智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图2所示，仍以以太坊为例，Bob将一个包含调用智能合约信息的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是发起调用智能合约的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。调用智能合约后，balance的值可能改变。后续，某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。
智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易完成后，区块链上就保存了无法篡改、不会丢失的交易凭证。
创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链网络的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。另外除了以太坊中的EVM外，不同的区块链网络还可能采用各类的虚拟机，这里并不限定。
区块链技术区别于传统技术的去中心化特点之一，就是在各个节点上进行记账，或者称为分布式记账，而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统，需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中，为了在各个记录账本的节点中保持账本的一致，通常采用共识算法来保证，即前述提到的共识机制。在节点(例如某个独特的节点)产生一个区块后，如果产生的这个区块得到其它节点的认可，其它节点记录相同的区块。上述产生的区块得到其它节点的认可的过程，就是共识机制。共识机制是区块链节点就区块信息达成全网一致共识的机制，可以保证最新区块被准确删除至区块链。当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法，HoneyBadgerBFT算法等。
图4示出了传统的PBFT算法的流程图。该算法是Miguel Castro(卡斯特罗)和Barbara Liskov(利斯科夫)在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上(OSDI99)。该算法中假设，当最多存在f个副本(即节点)失效时，如果存在总数为至少3f+1个副本，就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求，需要的一定数量副本的集合，一般是分布式系统中的大多数节点构成的集合，构成大多数(Quorum)。例如在总节点数n为3f+1的情况下，Quorum为2f+1。这样，对于包含四个节点的分布式系统，任意三个节点可以构成一个Quorum。
而且，所有的副本(replica)在一个被称为视图(View)的轮换过程(succession of configuration)中运行。在某个视图中，一个副本作为主节点(primary)，其他的副本作为备份节点(backups)。视图是连续编号的整数。主节点由公式p＝v mod|R|计算得到，这里v是视图编号，p是副本编号，|R|是副本集合的个数。当主节点失效的时候就 需要启动视图切换(view change)过程，从而在在系统存在故障进行状态调整，更换新的主节点。
PBFT算法的过程如下：
1.客户端c向主节点0(即replica 0)发送请求；
2.主节点0通过广播将请求发送给各备份节点；
3.所有副本(replica)都执行请求并将结果发回客户端；
4.客户端需要等待f+1个不同副本节点发回相同的结果，作为整个操作的最终结果。
下面以一个PBFT的例子(例如结合著名的拜占庭将军问题)来进行说明。这里首先假设N＝4，F＝1，即总共有4个节点，其中坏节点的数量是1。这里假设四个节点的编号分别是0、1、2、3，其中坏节点是节点3，则过程包括S1-S5。
S1.(REQUEST请求阶段)客户端c发送请求request到0号主节点；
S2.(PRE-PREPARE预准备阶段)主节点0收到客户端请求(或一组客户端的请求requests)后，对requests排序(对于一组客户端请求而言)并打包为消息m后，发送pre-prepare请求至节点1、2、3(即备份节点1，2，3，也是replica1，2，3，以下简称节点)，pre-prepare请求中包括消息m；
S3.(PREPARE准备阶段)节点1、2、3收到请求后，如果检查消息m合法，则分别再次广播。具体的，节点1将prepare消息扩散至节点0、2、3，节点2将prepare消息扩散至节点0、1、3，节点3例如是因为宕机而无法广播的坏节点。而且，每一节点还接收其他节点广播的prepare消息。每一节点将自己发送的prepare消息(代表自己的认可)和收到的prepare消息(代表其它节点的认可)都删除到本地Log中。如果某一节点接收到来自不同节点的Quorum-1个数量的针对同一消息的确认后(包括pre-prepare和prepare消息，这样本地Log中共有Quorum个)，转变成prepared状态。
S4.(COMMIT提交阶段)参与共识节点中的每一个在进入prepared状态后，发送commit消息给其他的共识节点，并将自己发送的commit消息删除到本地Log中(代表自己的认可)，而且，每一节点还接收其他节点广播的commit消息。某一节点如果接收到来自不同节点的Quorum-1数量的合法的commit消息后，删除到本地Log中(这时加上自己删除到本地Log中的共有Quorum个)，转变成commited状态。
S5.(REPLY响应阶段)所有参与共识的节点中的每一个在本地状态机中顺序执行pre-prepare消息m中的一个request或一组有序requests，并返回应答消息reply至Client，即对客户端c进行反馈。
客户端如果收到f+1个相同的REPLY消息，说明客户端发起的请求已经达成全网共识，否则客户端c可能需要判断是否重新发送请求给主节点0。
上述图4所示的过程和对应的文字内容，是传统的PBFT的算法过程。这个过程往往由客户端发起，进而针对客户端发起的REQUEST消息中的交易(单个交易或者多个交易)进行共识，并在共识的结束环节中将共识结果反馈给该客户端。
在联盟链场景中，共识过程可以由某个节点发起，即主要包括上述图4中的PRE-PREPARE、PREPARE和COMMIT过程。联盟链场景中，可以包括客户端或者不包括客户端。如果不包括客户端，可以不必具有图4中的REQUEST、REPLY的环节，而是在主节点收集一定量的交易后发起PBFT共识。如果包括客户端，共识过程可以不是由客户端发起，而是主节点收集一定量的交易后发起PBFT共识，即图4过程中的REQUEST并不直接导致PRE-PREPARE阶段的启动。
如果主节点掉线或者作恶而不广播客户端的请求，客户端可以设置超时机制。如果超时的话，客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后，也可以发起View Change协议阶段，以更换主节点。
此外，也可能由于主节点发起错误的提议导致PRE-PREPARE、PREPARE和COMMIT三阶段共识过程失败，或者，PREPARE、COMMIT阶段可能达不成Quorum数量的一致，也都无法完成共识。这些情况下也可能发起View Change协议阶段，以更换主节点。
View Change协议阶段，还需要考虑之前某个节点和其它节点处理不同步的问题，需要在View Change(也简称为VC)后恢复，如图5所示。例如，主节点Replica 0在VC前的视图V下对<v,n,d>对应的propose m5已经进入committed(提交)状态，并已经执行了propose m5，而Replica 1可能由于网络延迟还没有对propose m5进入committed状态，而是prepared(准备)状态。Replica 2(以及3)可能对propose m5也是prepared状态。此后，Replica 0宕机。这样，在不同节点上具有不完全相同的状态。更换主节点后，Replica 0可能重启恢复，主节点例如更换为Replica 1，则Replica 1-3需要跟上Replica 0的步伐，所以新的主节点Replica 1需要把处于prepared状态的 propose m5重发一遍，让Replica 1-3执行完毕，才能与Replica 0的状态一致。否则，可能Replica 1-3在新视图V+1中对新的消息m6完成三阶段共识，而仅有replica 0之前对m5完成了执行，实际上replica 1-3并未完成对m5的执行，即Replica 1-3在新视图V+1中对新的消息m6的执行是在与replica 0不同的状态上开始的，这样就会出现不同节点上状态机的不一致，形成分叉。另外，上述过程中，如果Replica 0对m5只是prepared状态，即并没有在状态机上执行，其它Replicas比Replica 0处理的还慢，则Replica 0达成的prepared状态可以删除，而不影响全局的状态一致。
View Change(视图改变)协议阶段一般至少包括View-Change和New-View(新视图)两个协议过程。这两个协议过程执行完毕后，完成更换主节点。更换主节点完成之后，视图编号加1，即更改为v+1，根据p＝(v+1)％N，主节点可以由如图4中的replica 0更换为replica 1。
具体的，如图6所示，检测出主节点作恶或者下线的副本节点可以向其他副本节点广播<VIEW-CHANGE,v+1,n,C,P,i>消息。如图6中所示，replica 1检测到原主节点replica 0作恶或者下线，则replica 1向replica 0，replica 2和replica 3发送<VIEW-CHANGE,v+1,n,C,P,i>消息；类似的，replica 2向replica 0，replica 1和replica 3发送<VIEW-CHANGE,v+1,n,C,P,i>消息，replica 3向replica 0，replica 1和replica 3发送<VIEW-CHANGE,v+1,n,C,P,i>消息。
其中，VIEW-CHANGE是协议标识，标识该协议是VIEW-CHANGE协议；v+1是下一视图的编号；n是最新的stable checkpoint(稳定检查点)的编号；C是2f+1验证过的CheckPoint消息的集合；P是可选项，如果有则表示当前发出VIEW-CHANGE消息的副本节点已经达到prepared状态的若干个消息的集合(对应每个prepared状态的<v,n,d>，包括pre-prepare消息和2f个不同节点的签名)。
当新的主节点p＝(v+1)mod|R|，例如此时为如图6中的replica 1，收到2f个有效的VIEW-CHANGE消息后，向其他节点广播<NEW-VIEW,v+1,V,O，p>消息。NEW-VIEW是协议标识，标识该协议是NEW-VIEW协议；v+1是下一视图的编号；V是新的主节点接收到的2f个不同节点发出的带签名的view-change消息，以及新的主节点自己要发出或已发出的对于v+1的view-change消息。O是主节点重新发起的未经完成的PRE-PREPARE消息的集合。p是当前节点的签名。PRE-PREPARE消息集合的选取规则包括：
1.选取V中最小的stable checkpoint编号min-s，选取V中prepare消息的最大编 号max-s。
2.在min-s和max-s之间，如果存在P消息集合，则创建<<PRE-PREPARE,v+1,n,d>,m>消息。否则创建一个空的PRE-PREPARE消息，即：<<PRE-PREPARE,v+1,n,d(null)>,m(null)>,m(null)是空消息，d(null)是空消息的摘要。
副本节点收到主节点的NEW-VIEW消息，验证签名合法并且V中的view-change消息合法，O合法。如果合法的话，进入v+1状态，并且开始O中的PRE-PREPARE消息处理流程。
以联盟链为例，联盟链场景中，一个节点可以对应一个或多个账号，当然，一个节点也可以不对应任何账号，而只是作为共识节点。此外，联盟链中可以存在创世合约或系统合约。创世合约和系统合约可以如前述所述产生。一般地，创世合约/系统合约中可以设置联盟链的共识节点列表，例如，设置共识节点的公钥的集合，并且该集合中的公钥按照某一特定顺序排列。联盟链中的各个共识节点，按照创世合约中设置的共识节点列表，可以在本地存储本地节点列表。每个共识节点在其本地的节点列表中，可以根据创世合约/系统合约中给定的特定顺序将各共识节点按照对应的公钥排列，从而，各共识节点各自本地节点列表中具有相同的共识节点并且这些共识节点按照相同顺序排列。而且，创世合约/系统合约中可以设置删除共识节点的方法和参数，从而，根据创世合约/系统合约，节点可以更改本地节点列表中的节点，从而完成删除节点的操作。
当某一账号发起一个删除共识节点的请求，该请求例如是一个交易请求，第一共识节点可以接收该请求。所述请求例如可以是一个客户端发起的删除节点的交易请求，从而触发删除该待删除节点的过程，也可以是第一共识节点接收的控制台指令端发起的删除节点的交易请求，从而触发删除该待删除节点的过程。控制台一般可以由控制该节点的管理员操作，例如通过图形化或代码化的指令发起操作。需要说明的是，对于PBFT这类有主共识算法来说，第一共识节点一般为主节点。而第一共识节点可能是直接从客户端或控制台发来的交易请求，也可能是通过其它共识节点中转而接收的交易请求。对于HoneyBadgerBFT等无主的共识算法来说，不存在主节点，则第一共识节点为多个平等的共识节点中的一个。
则如图7所示，联盟链中删除节点的过程包括S701-S705。
S701：区块链网络中的第一共识节点接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；达成共识后，共识节点执行所述删除节点的交易，以对除待删 除节点之外的剩余共识节点顺序编号。
所述交易请求，可以是调用合约的交易请求。该交易请求中，可以指明被调用的智能合约的地址，调用的方法和传入的参数。例如调用的合约为前述提到的创世合约/系统合约，调用的方法为删除节点的方法，传入的参数例如包括待删除节点的标识，IP地址,端口号等一个或多个。
第一共识节点，可以通过接收删除节点的交易请求而触发删除节点的过程。例如，如前所述，第一共识节点可以通过接收客户端发起的删除节点的交易请求而触发删除该待删除节点的过程，也可以是第一共识节点通过接收控制台指令端发起的删除节点交易请求而触发删除该待删除节点的过程。控制台一般可以由控制该节点的管理员操作，例如通过图形化或代码化的指令发起操作。此外，第一共识节点也可以是收到待删除节点发来的所述待删除节点的相关信息，从而发起删除该待删除节点的过程。
删除节点的交易请求一般会在区块链网络中基于底层的对等(peer-to-peer，P2P)网络传播至各共识节点。第一共识节点接收删除节点的交易请求后，作为有主共识算法的主节点或者无主共识算法的共识节点，可以发起共识过程。以PBFT这类有主共识算法为例，第一共识节点可以是主节点，可以针对包括该删除节点的交易请求发起共识过程，即主要包括上述图4中的PRE-PREPARE、PREPARE和COMMIT过程。
完成共识后，区块链网络中的至少Quorum数量的共识节点都在本地具有了所述删除节点的交易请求中的消息内容，并达成了共识。并且，如果该删除节点的交易请求中的消息内容与其它消息一同构成共识的结果，则该删除节点的交易请求中的消息内容在不同节点上具有相同的消息顺序，即至少Quorum数量的共识节点对该删除节点请求中的消息内容和顺序都达成了共识。
在S701之后，如前所述，至少Quorum数量的共识节点对包括所述删除节点的交易请求中的消息内容达成了共识。进而，共识节点可以在本地执行相应的合约。例如，共识节点调用前述提到的创世合约/系统合约，在EVM之类的虚拟机中执行调用的创世合约/系统合约中指明的方法，并传入相应的参数。具体的，传入的参数例如包括待删除节点的标识，IP地址,端口号等。执行合约过程中，共识节点可以是在本地节点列表中共识节点的基础上将所述待删除节点的信息删除，并对剩余共识节点顺序编号。这样，至少Quorum数量的共识节点本地维护的共识节点列表中也已具有了相同的剩余共识节点，且剩余共识节点具有相同的顺序编号。
如前所述，共识节点可以在本地维护一个共识节点列表，即前述的本地节点列表，其中记载了当前区块链网络中所有共识节点的基础信息。具体的，这些基础信息例如可以包括共识节点的标识、IP地址、端口号等中的一个或多个。其中，共识节点在本地节点列表中可以是顺序编号的。一个共识节点一般具有一个标识(ID)，这个ID可以是能够唯一标识该节点的标识，例如可以是该节点的公钥、IP地址+端口号之类，当然也可以是其它内容。所述共识节点列表，在一些区块链项目中，可以从逻辑上存在于世界状态(world state)中。以以太坊、Fabric和一些联盟链的商业项目为例，每个节点在本地维护世界状态，在该世界状态中有最新的全部账户的状态。例如在以太坊中，节点可以根据区块中状态树、交易树和收据树的内容维护最新的全部账户的状态。
由于此前共识节点已经进行过若干次共识，理论上各共识节点之间已经保持了共识节点列表的一致。例如，共识节点a、b、c、d、m，各自的世界状态中存储有本地节点列表，并且，共识节点a、b、c、d、m各自的本地节点列表中存储的共识节点均是a、b、c、d、m五个节点，并且都是a-b-c-d-m的顺序。那么，a、b、c、d、m的编号分别是0、1、2、3、4。这样，对于删除的节点m，各共识节点在本地维护的共识节点列表基础上，执行本申请实施例的S701和S702的过程，则各共识节点在本地节点列表中的节点均包括a、b、c、d共4个节点，且剩余共识节点的编号顺序也是相同的，都是0-1-2-3。
本地节点列表中的共识节点，还可以包括激活和未激活两种状态。处于激活状态的共识节点可以正常参与共识；而处于未激活状态的共识节点并不参与共识，也就不与其它处于激活状态的共识节点一同顺序编号。这样，共识节点除了上述提到的在本地节点列表中删除所述待删除节点，也可以将待删除的节点的状态设置为未激活，从而在不删除节点的情况下将待删除节点冻结。
S703：共识节点发起视图切换。
S701中，共识节点执行所述删除节点的交易后，会更新本地节点列表。当前视图中，仍然是原有的未执行删除操作的所有参与共识的节点及顺序。这样，共识节点执行所述删除节点的交易后，会检测到本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致，或检测到本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致。这样，共识节点可以发起视图切换。
其中，视图切换过程中的R(即视图切换过程中的副本集合个数)为包括待删除节点的共识节点总数，也即本地节点列表中包括待加入节点的节点数量。
类似前面所述，共识节点可以向其他副本节点广播<VIEW-CHANGE,v+1,n,C,P,i>消息。n是最新的stable checkpoint(稳定检查点)的编号，C是2f+1个验证过的CheckPoint消息集合，P是当前副本节点未完成的请求的PRE-PREPARE和PREPARE消息集合。
例如，之前一共有5个共识节点，编号分别为a、b、c、d、m。假设待删除节点为节点m，剩余共识节点包括节点a、b、c、d。节点a例如是PBFT中的主节点(Primary)，节点b、c、d、m例如是PBFT中的备份节点。可以通过p＝(v)mod|R|计算得到新的主节点的编号，例如是1，即对应b。这里的R为本地节点列表中除去待删除节点后的剩余共识节点数量。每个共识节点在本地的节点列表中都记录了a、b、c、d、m共五个节点的编号。该情况下，R＝5。执行本实施例的S701～S703后的一个例子中，每一共识节点在本地节点列表中共识节点的编号的基础上可以为除去待删除节点后的剩余共识节点顺序编号，从而只剩下节点a、b、c、d，其编号为0、1、2、3。该情况下，R变为了4。发起视图切换过程中的视图编号递增，即如前所述，由v变为v+1。
再一个例子中，之前一共有5个共识节点，编号分别为a、b、c、d、m。假设待删除节点为节点c，剩余共识节点包括节点a、b、d、m。执行本实施例的S701～S703后的一个例子中，每一共识节点在本地节点列表中共识节点的编号的基础上可以为除去待删除节点后的剩余共识节点顺序编号，从而只剩下节点a、b、d、m，重新编号后为0、1、2、3。
此外，对于设置为未激活状态来冻结参与共识的节点的方式，所述共识节点检测到下面任一情形时发起视图切换：本地共识节点列表中激活的共识节点数量与当前视图中的共识节点数量存在不一致；或，本地共识节点列表中激活的共识节点标识与当前视图中的共识节点标识存在不一致。
S705：所述视图切换完成后，所述剩余共识节点参与共识。
视图切换完成之后，除待删除节点后的剩余共识节点本地各自存有相同的节点编号列表，且具有相同的区块数据，从而剩余共识节点可以正常共识。这样，就完成了删除节点的过程。
图8示出了本申请一种区块链系统实施例的架构图，所述区块链系统，包括：第一共识节点801，用于接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；共识节点802，用于在达成共识后，执行所述删除节点的交易，以对除待删除节点803之外的剩余共识节点804顺序编号；还用于发起视图切换；剩余共识节点804，用 于在所述视图切换完成后参与所述区块链的共识过程。
共识节点802包括第一共识节点801、待删除节点803及剩余共识节点804。
其中，所述删除节点的交易请求包括调用合约的交易请求。
其中，所述调用的合约包括创世合约或系统合约。
其中，第一共识节点801接收删除节点的交易请求，包括：第一共识节点801接收客户端发起的删除节点的交易请求；或，第一共识节点801接收控制台指令端发起的删除节点的交易请求。
其中，共识节点802在本地维护有节点列表，所述节点列表中包括共识节点802的标识、IP地址、端口号中的一个或多个；其中，共识节点802在本地节点列表中顺序编号。
共识节点802在本地维护的节点列表位于世界状态中。
所述共识节点802执行所述删除节点的交易，包括：所述共识节点802在本地节点列表中删除所述待删除节点；或，所述共识节点802在本地节点列表中将所述待删除节点的状态设置为未激活。
其中，所述共识节点802检测到下面任一情形时发起视图切换：本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，本地共识节点列表中激活的共识节点数量与当前视图中的共识节点数量存在不一致；或，本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致；或，本地共识节点列表中激活的共识节点标识与当前视图中的共识节点标识存在不一致。
其中，所述共识节点802接收到所述待删除节点803广播的发起视图切换的消息后发起视图切换。
其中，视图切换过程中的副本集合个数为除去待删除节点803的剩余共识节点804总数。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (20)

  1. 区块链网络中删除节点的方法，包括：
    区块链网络中的第一共识节点接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；达成共识后，共识节点执行所述删除节点的交易，以对除待删除节点之外的剩余共识节点顺序编号；
    所述共识节点发起视图切换；
    所述视图切换完成后，所述剩余共识节点参与所述区块链的共识过程。
  2. 如权利要求1所述的方法，其中，所述删除节点的交易请求包括调用合约的交易请求。
  3. 如权利要求2所述的方法，其中，所述调用的合约包括创世合约或系统合约。
  4. 如权利要求1所述的方法，其中，所述第一共识节点接收删除节点的交易请求，包括：
    第一共识节点接收客户端发起的删除节点的交易请求；或，
    第一共识节点接收控制台指令端发起的删除节点的交易请求。
  5. 如权利要求1所述的方法，其中，所述共识节点在本地维护有节点列表，所述节点列表中包括共识节点的标识、IP地址、端口号中的一个或多个；其中，共识节点在本地节点列表中顺序编号。
  6. 如权利要求5所述的方法，其中，所述共识节点在本地维护的节点列表位于世界状态中。
  7. 如权利要求5所述的方法，其中，所述共识节点执行所述删除节点的交易，包括：
    所述共识节点在本地节点列表中删除所述待删除节点；或，
    所述共识节点在本地节点列表中将所述待删除节点的状态设置为未激活。
  8. 如权利要求1或7所述的方法，其中，所述共识节点检测到下面任一情形时发起视图切换：
    本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，
    本地共识节点列表中激活的共识节点数量与当前视图中的共识节点数量存在不一致；或，
    本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致；或，
    本地共识节点列表中激活的共识节点标识与当前视图中的共识节点标识存在不一致。
  9. 如权利要求1所述的方法，其中，所述共识节点接收到所述待删除节点广播的发起视图切换的消息后发起视图切换。
  10. 如权利要求1所述的方法，其中，视图切换过程中的副本集合个数为除去待删除节点的剩余共识节点总数。
  11. 一种区块链系统，包括：
    第一共识节点，用于接收删除节点的交易请求，并针对该删除节点的交易请求发起共识；
    所述共识节点，用于在达成共识后，执行所述删除节点的交易，以并对除待删除节点之外的剩余共识节点顺序编号；还用于发起视图切换；
    剩余共识节点，用于在所述视图切换完成后参与所述区块链的共识过程。
  12. 如权利要求11所述的区块链系统，其中，所述删除节点的交易请求包括调用合约的交易请求。
  13. 如权利要求12所述的区块链系统，其中，所述调用的合约包括创世合约或系统合约。
  14. 如权利要求11所述的区块链系统，其中，所述第一共识节点接收删除节点的交易请求，包括：
    第一共识节点接收客户端发起的删除节点的交易请求；或，
    第一共识节点接收控制台指令端发起的删除节点的交易请求。
  15. 如权利要求11所述的区块链系统，其中，所述共识节点在本地维护有节点列表，所述节点列表中包括共识节点的标识、IP地址、端口号中的一个或多个；其中，共识节点在本地节点列表中顺序编号。
  16. 如权利要求15所述的区块链系统，其中，所述共识节点在本地维护的节点列表位于世界状态中。
  17. 如权利要求15所述的区块链系统，其中，所述共识节点执行所述删除节点的交易，包括：
    所述共识节点在本地节点列表中删除所述待删除节点；或，
    所述共识节点在本地节点列表中将所述待删除节点的状态设置为未激活。
  18. 如权利要求11或17所述的区块链系统，其中，所述共识节点检测到下面任一情形时发起视图切换：
    本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，
    本地共识节点列表中激活的共识节点数量与当前视图中的共识节点数量存在不一 致；或，
    本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致；或，
    本地共识节点列表中激活的共识节点标识与当前视图中的共识节点标识存在不一致。
  19. 如权利要求11所述的区块链系统，其中，所述共识节点接收到所述待删除节点广播的发起视图切换的消息后发起视图切换。
  20. 如权利要求11所述的区块链系统，其中，视图切换过程中的副本集合个数为除去删除节点的剩余共识节点总数。
PCT/CN2020/102350 2019-09-05 2020-07-16 区块链网络中删除节点的方法和区块链系统 WO2021042880A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910838733.5 2019-09-05
CN201910838733.5A CN110730204B (zh) 2019-09-05 2019-09-05 区块链网络中删除节点的方法和区块链系统

Publications (1)

Publication Number Publication Date
WO2021042880A1 true WO2021042880A1 (zh) 2021-03-11

Family

ID=69143332

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/CN2019/109400 WO2020011283A2 (en) 2019-09-05 2019-09-30 System and method for deleting node in blockchain network
PCT/CN2020/102350 WO2021042880A1 (zh) 2019-09-05 2020-07-16 区块链网络中删除节点的方法和区块链系统

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/109400 WO2020011283A2 (en) 2019-09-05 2019-09-30 System and method for deleting node in blockchain network

Country Status (6)

Country Link
US (2) US10740325B2 (zh)
EP (1) EP3701666B1 (zh)
CN (3) CN110730204B (zh)
SG (1) SG11202004815RA (zh)
TW (1) TWI761879B (zh)
WO (2) WO2020011283A2 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113379422A (zh) * 2021-08-12 2021-09-10 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN114064343A (zh) * 2022-01-13 2022-02-18 北京溪塔科技有限公司 一种区块链的异常处置方法及装置
CN114205233A (zh) * 2021-11-30 2022-03-18 北京大学 一种面向数据管控的智能合约自适应配置与执行框架

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11201908887XA (en) 2019-03-18 2019-10-30 Alibaba Group Holding Ltd System and method for ending view change protocol
CN110800258B (zh) * 2019-03-18 2022-04-22 创新先进技术有限公司 用于结束视图更改协议的系统和方法
CN110730204B (zh) * 2019-09-05 2022-09-02 创新先进技术有限公司 区块链网络中删除节点的方法和区块链系统
JP6993587B2 (ja) * 2019-09-30 2022-01-13 ダイキン工業株式会社 フロン管理システム、管理者ノード及びフロン管理方法
KR102363271B1 (ko) * 2019-11-06 2022-02-14 알리페이 (항저우) 인포메이션 테크놀로지 씨오., 엘티디. 에러 정정 코드에 기초한 공유 블록체인 데이터 저장의 데이터 보안
JP6852776B1 (ja) * 2019-11-26 2021-03-31 ダイキン工業株式会社 ブロックチェーンシステム、プログラム及びネットワーク接続装置
CN111314151B (zh) * 2020-02-27 2023-08-08 腾讯科技（深圳）有限公司 节点管理方法、装置、电子设备及计算机可读存储介质
US20210279255A1 (en) * 2020-03-04 2021-09-09 Vmware, Inc. Synchronous state machine replication for achieving consensus
CN111404928B (zh) * 2020-03-13 2021-07-06 电子科技大学 一种适用于实时交易场景的区块链节点共识方法
CN111461886B (zh) * 2020-04-01 2022-02-01 杭州溪塔科技有限公司 区块链上不依赖智能合约的系统配置的管理方法和装置
CN111507840B (zh) * 2020-04-15 2024-03-26 财付通支付科技有限公司 区块链共识方法、装置、计算机以及可读存储介质
US11250021B2 (en) * 2020-04-17 2022-02-15 International Business Machines Corporation Faster view change for blockchain
CN111444216A (zh) * 2020-06-15 2020-07-24 支付宝(杭州)信息技术有限公司 一种基于中心化块链式账本的数据块删除方法
CN111901388B (zh) * 2020-06-30 2022-12-20 达闼机器人股份有限公司 区块链多链系统、用于区块链多链系统的方法、电子设备
CN111917572B (zh) * 2020-07-12 2022-10-25 中信银行股份有限公司 交易请求的处理方法、装置、电子设备及可读存储介质
CN112272092B (zh) * 2020-08-30 2021-07-27 河南大学 一种应用于区块链的数据编辑方法
CN112037873B (zh) * 2020-08-31 2022-09-13 合肥工业大学 一种基于集群选主和共识机制的单点优化方法
CN112398908B (zh) * 2020-10-20 2023-04-07 杭州云象网络技术有限公司 一种区块链网络节点删除方法、系统、存储介质和装置
CN112507019A (zh) * 2020-11-20 2021-03-16 南京航空航天大学 一种基于智能合约的pbft共识系统及方法
CN113162971B (zh) * 2020-12-03 2022-07-22 腾讯科技（深圳）有限公司 区块链节点管理方法、装置、计算机以及可读存储介质
CN113157709A (zh) * 2021-01-29 2021-07-23 百果园技术(新加坡)有限公司 分布式系统节点动态变更方法、装置、设备及存储介质
KR102574890B1 (ko) * 2021-04-02 2023-09-06 주식회사 헤세그 장애 노드에 내성을 갖는 블록체인 시스템 및 그 동작 방법
CN113592639B (zh) * 2021-05-21 2023-10-13 上海简苏网络科技有限公司 一种区块链交易删除方法及系统
CN113067895B (zh) * 2021-06-02 2021-08-31 支付宝(杭州)信息技术有限公司 组建区块链子网的方法和区块链系统
CN113067894B (zh) * 2021-06-02 2021-09-24 支付宝(杭州)信息技术有限公司 节点退出区块链子网的方法
US11809453B2 (en) * 2021-06-04 2023-11-07 Vmware, Inc. Two-round byzantine fault tolerant (BFT) state machine replication (SMR) protocol with linear authenticator complexity and optimistic responsiveness
US11983161B2 (en) 2021-06-23 2024-05-14 Bank Of America Corporation System for mitigating data loss in an edge computing environment using machine learning and distributed ledger techniques
CN113656499B (zh) * 2021-08-16 2024-04-02 工银科技有限公司 基于区块链的价值转移方法及装置
WO2023035065A1 (en) * 2021-09-07 2023-03-16 Jalalzai Mohammad Methods and systems for fast consensus within distributed ledgers
KR20230090027A (ko) * 2021-12-14 2023-06-21 한국전자통신연구원 블록체인 네트워크에서의 합의 노드 정보 동기화 장치 및 방법
US11960502B2 (en) * 2021-12-17 2024-04-16 VMware LLC Byzantine fault tolerance protocol for backing up blockchains
CN114760198B (zh) * 2022-01-17 2023-03-24 清华大学 一种基于区块链网络的共识方法、装置及系统
CN114070733B (zh) * 2022-01-17 2023-01-31 清华大学 一种基于区块链网络的共识方法、装置及系统
CN114726866A (zh) * 2022-04-07 2022-07-08 网易（杭州）网络有限公司 联盟链的共识节点维护方法、电子设备、存储介质
CN115001809A (zh) * 2022-05-31 2022-09-02 深圳壹账通智能科技有限公司 区块链网络共识方法、装置、设备及介质
CN115185972B (zh) * 2022-09-13 2022-12-16 北京大学 一种数字对象的存证副本的管理方法与装置
US11973666B1 (en) * 2022-10-11 2024-04-30 Verizon Patent And Licensing Inc. Systems and methods for using blockchain to manage service-level agreements between multiple service providers
CN115314369A (zh) * 2022-10-12 2022-11-08 中国信息通信研究院 区块链节点共识的方法和装置、设备和介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6594624B1 (en) * 1999-06-22 2003-07-15 The United States Of America As Represented By The National Security Agency Method of identifying all minimum-cost cutsets in a network
CN106878000A (zh) * 2017-03-06 2017-06-20 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种联盟链共识方法及系统
CN107528882A (zh) * 2017-07-14 2017-12-29 阿里巴巴集团控股有限公司 区块链共识网络中处理共识请求的方法、装置和电子设备
US20190188086A1 (en) * 2017-12-14 2019-06-20 International Business Machines Corporation Redundancy reduction in blockchains
CN110730204A (zh) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 区块链网络中删除节点的方法和区块链系统

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140149715A1 (en) * 2012-11-28 2014-05-29 Los Alamos National Security, Llc Scalable and programmable computer systems
US9372892B1 (en) * 2015-12-28 2016-06-21 International Business Machines Corporation Bloom filter construction method for use in a table join operation portion of processing a query to a distributed database
US10720232B2 (en) 2016-04-13 2020-07-21 Accenture Global Solutions Limited Distributed healthcare records management
US10445698B2 (en) 2016-06-30 2019-10-15 Clause, Inc. System and method for forming, storing, managing, and executing contracts
US10360191B2 (en) 2016-10-07 2019-07-23 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
US10158527B2 (en) 2016-10-28 2018-12-18 International Business Machines Corporation Changing an existing blockchain trust configuration
CN111917864B (zh) * 2017-02-22 2023-08-22 创新先进技术有限公司 一种业务校验的方法及装置
US11196573B2 (en) * 2017-03-06 2021-12-07 Nokia Technologies Oy Secure de-centralized domain name system
US10521604B2 (en) * 2017-03-17 2019-12-31 Labyrinth Research Llc Unified control of privacy-impacting devices
CN110445619B (zh) * 2017-03-30 2020-10-16 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
CN107171829B (zh) * 2017-04-24 2019-12-24 杭州趣链科技有限公司 一种基于bft共识算法实现的动态节点管理方法
US10896169B2 (en) 2017-05-12 2021-01-19 International Business Machines Corporation Distributed system, computer program product and method
CN107395665B (zh) * 2017-05-22 2020-04-24 创新先进技术有限公司 一种区块链业务受理及业务共识方法及装置
US10740733B2 (en) 2017-05-25 2020-08-11 Oracle International Corporaton Sharded permissioned distributed ledgers
CN107332701A (zh) * 2017-06-26 2017-11-07 中国人民银行数字货币研究所 管理节点的方法和系统
US10567359B2 (en) 2017-07-18 2020-02-18 International Business Machines Corporation Cluster of secure execution platforms
US11281644B2 (en) 2017-07-28 2022-03-22 Hitachi, Ltd. Blockchain logging of data from multiple systems
US20190058709A1 (en) 2017-08-16 2019-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Tenant management method and system in a cloud computing environment
CN107579848B (zh) * 2017-08-30 2020-08-25 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
US10528551B2 (en) * 2017-09-29 2020-01-07 Oracle International Corporation System and method for providing a representational state transfer proxy service for a blockchain cloud service
US11159537B2 (en) 2017-11-30 2021-10-26 Bank Of America Corporation Multicomputer processing for data authentication and event execution using a blockchain approach
US10567156B2 (en) 2017-11-30 2020-02-18 Bank Of America Corporation Blockchain-based unexpected data detection
US10949511B2 (en) 2017-11-30 2021-03-16 Bank Of America Corporation Multicomputer processing for data authentication using a blockchain approach
US11243945B2 (en) 2017-12-11 2022-02-08 International Business Machines Corporation Distributed database having blockchain attributes
US11544708B2 (en) 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain
US20190207751A1 (en) 2018-01-04 2019-07-04 Bank Of America Corporation Blockchain enterprise data management
US11296863B2 (en) 2018-01-04 2022-04-05 Bank Of America Corporation Blockchain enterprise data management
CN108365993B (zh) * 2018-03-09 2020-04-28 深圳前海微众银行股份有限公司 区块链节点动态变更方法、系统和计算机可读存储介质
CN108390891A (zh) * 2018-03-28 2018-08-10 电子科技大学天府协同创新中心 基于私有区块链的信息保护方法
CN108616596B (zh) * 2018-05-09 2020-12-25 南京邮电大学 基于动态授权和网络环境感知的区块链自适应共识方法
US10542046B2 (en) 2018-06-07 2020-01-21 Unifyvault LLC Systems and methods for blockchain security data intelligence
US10713133B2 (en) * 2018-06-11 2020-07-14 Vmware, Inc. Linear view-change BFT
US20190386995A1 (en) 2018-06-14 2019-12-19 Zero31Skytech Inc. Apparatus, system and method to limit access to open networks by requiring the consensus of pre-existing nodes to admit candidate nodes
CN109150598B (zh) * 2018-08-10 2021-09-03 上交所技术有限责任公司 一种基于块片的bft共识算法带宽使用率改进方法
US10992455B2 (en) * 2018-08-14 2021-04-27 International Business Machines Corporation Consensus based ad-hoc group creation
WO2019072263A2 (en) * 2018-11-07 2019-04-18 Alibaba Group Holding Limited FACILITATION OF BLOCK CHAIN CONSENSUS AND NODE SYNCHRONIZATION FOR PRACTICAL TOLERANCE TO ARBITRARY FAILURES
CN113850676A (zh) * 2018-11-30 2021-12-28 创新先进技术有限公司 用于在区块链网络内原子转移智能资产的平台
KR102151896B1 (ko) * 2018-11-30 2020-09-03 알리바바 그룹 홀딩 리미티드 블록체인 네트워크 내에서 스마트 에셋의 원자적 전송을 위한 플랫폼
CN109784916A (zh) * 2018-12-12 2019-05-21 广东工业大学 一种改进pbft的以太坊共识机制应用于联盟链的方法
CN109859047A (zh) * 2019-01-31 2019-06-07 北京瑞卓喜投科技发展有限公司 一种区块链更新方法和区块链更新系统
AU2019203865B2 (en) * 2019-03-18 2021-01-21 Advanced New Technologies Co., Ltd. Consensus system downtime recovery

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6594624B1 (en) * 1999-06-22 2003-07-15 The United States Of America As Represented By The National Security Agency Method of identifying all minimum-cost cutsets in a network
CN106878000A (zh) * 2017-03-06 2017-06-20 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种联盟链共识方法及系统
CN107528882A (zh) * 2017-07-14 2017-12-29 阿里巴巴集团控股有限公司 区块链共识网络中处理共识请求的方法、装置和电子设备
US20190188086A1 (en) * 2017-12-14 2019-06-20 International Business Machines Corporation Redundancy reduction in blockchains
CN110730204A (zh) * 2019-09-05 2020-01-24 阿里巴巴集团控股有限公司 区块链网络中删除节点的方法和区块链系统

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113379422A (zh) * 2021-08-12 2021-09-10 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN113379422B (zh) * 2021-08-12 2021-10-15 腾讯科技（深圳）有限公司 基于智能合约的数据处理方法、设备以及可读存储介质
CN114205233A (zh) * 2021-11-30 2022-03-18 北京大学 一种面向数据管控的智能合约自适应配置与执行框架
CN114205233B (zh) * 2021-11-30 2022-07-12 北京大学 一种面向数据管控的智能合约自适应配置与执行的系统
CN114064343A (zh) * 2022-01-13 2022-02-18 北京溪塔科技有限公司 一种区块链的异常处置方法及装置

Also Published As

Publication number Publication date
EP3701666A4 (en) 2020-12-23
TW202112115A (zh) 2021-03-16
CN116527696A (zh) 2023-08-01
US20200117657A1 (en) 2020-04-16
TWI761879B (zh) 2022-04-21
EP3701666A2 (en) 2020-09-02
EP3701666B1 (en) 2024-05-08
US20200293516A1 (en) 2020-09-17
CN110730204A (zh) 2020-01-24
SG11202004815RA (en) 2020-06-29
US10740325B2 (en) 2020-08-11
CN111183625A (zh) 2020-05-19
WO2020011283A2 (en) 2020-01-16
WO2020011283A3 (en) 2020-06-25
CN110730204B (zh) 2022-09-02
CN111183625B (zh) 2023-06-06

Similar Documents

Publication Publication Date Title
WO2021042880A1 (zh) 区块链网络中删除节点的方法和区块链系统
WO2021042885A1 (zh) 区块链网络中加入节点的方法和区块链系统
Gupta et al. Resilientdb: Global scale resilient blockchain fabric
Christidis et al. Blockchains and smart contracts for the internet of things
WO2021196350A1 (zh) 区块链Raft+PBFT的混合共识网络算法及系统
CN111400112B (zh) 分布式集群的存储系统的写入方法、装置及可读存储介质
Yanovich et al. Exonum: Byzantine fault tolerant protocol for blockchains
JP2022523217A (ja) 投票集計を伴うトポロジードリブンビザンチンフォールトトレラント合意プロトコル
JP7416768B2 (ja) 分散コンピューティング環境で分散調整エンジンを非破壊的にアップグレードする方法、装置およびシステム
Swathi et al. An analysis on blockchain consensus protocols for fault tolerance
WO2023207076A1 (zh) 区块链子网的组建方法及装置
Bogdanov et al. A multilayer approach to the security of blockchain networks of the future
Xu et al. An Improved Practical Byzantine Fault Tolerance Consensus Algorithm
US20240193153A1 (en) Governance implementation in an n-dimensional blockchain
Van Dame et al. A Comparative Study of Consensus Algorithms for Distributed Systems
KR102574890B1 (ko) 장애 노드에 내성을 갖는 블록체인 시스템 및 그 동작 방법
Bashir Classical Consensus
Babi et al. Increasing the Trustworthiness of Collaborative Applications
BOOK NYU ID

Legal Events

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

Ref document number: 20860880

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20860880

Country of ref document: EP

Kind code of ref document: A1