WO2019080235A1 - 基于以太坊的区块链系统和交易数据处理方法 - Google Patents

基于以太坊的区块链系统和交易数据处理方法

Info

Publication number
WO2019080235A1
WO2019080235A1 PCT/CN2017/112664 CN2017112664W WO2019080235A1 WO 2019080235 A1 WO2019080235 A1 WO 2019080235A1 CN 2017112664 W CN2017112664 W CN 2017112664W WO 2019080235 A1 WO2019080235 A1 WO 2019080235A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
certificate
node
stage
stage certificate
Prior art date
Application number
PCT/CN2017/112664
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 平安科技（深圳）有限公司
Priority to SG11201809101WA priority Critical patent/SG11201809101WA/en
Priority to US16/097,876 priority patent/US11294888B2/en
Publication of WO2019080235A1 publication Critical patent/WO2019080235A1/zh

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • 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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • 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
    • 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/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • 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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1474—Saving, restoring, recovering or retrying in transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82—Solving problems relating to consistency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/87—Monitoring of transactions
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the present application relates to the field of network communication technologies, and in particular, to a blockchain system and transaction data processing method based on Ethereum.
  • the alliance chain is usually a blockchain built by some commercial alliances using Ethereum technology for the common good.
  • the alliance chain is not open to the public and is managed only by members of the business alliance. However, members of the business alliance do not fully trust each other.
  • Each member of the alliance needs to supervise other members of the blockchain to maintain accurate operation of the alliance chain.
  • each node in the coalition chain needs to reach an agreement, that is, a consensus is reached. Therefore, the consensus mechanism of the alliance chain is particularly important.
  • the PBFT Practical Byzantine Fault Tolerance
  • the nodes do not need to be mined, although the large amount of operations required to reach consensus through computational power is avoided, but the PBFT consensus mechanism has higher network resource consumption and greater network overhead. Therefore, how to effectively reduce network resource consumption when trading through the alliance chain has become a technical problem that needs to be solved.
  • a blockchain system and transaction data processing method based on Ethereum is provided.
  • a blockchain system based on Ethereum including a master node and multiple backup nodes, where:
  • the master node is configured to receive a transaction request sent by the client terminal, invoke a smart contract deployed in the alliance chain to perform transaction processing according to the transaction request, and obtain transaction data; use the transaction data to generate a block, and use the transaction block to generate the block
  • the backup nodes broadcast; the blocks have corresponding block information;
  • the backup node is configured to receive the block, and verify transaction data of the block
  • the primary node is further configured to generate a first-stage certificate by using the complete block information, and send the first-stage certificate to multiple backup nodes; the backup node is further configured to use, according to the block in the first-stage certificate
  • the hash value respectively generates a second-stage certificate and a third-stage certificate, and respectively negotiates the block by using the second-stage certificate and the third-stage certificate to obtain a negotiation result;
  • the primary node and the multiple backup nodes respectively add the blocks to the copy of the local alliance chain.
  • a transaction data processing method based on the Ethereum blockchain comprising:
  • the master node receives the transaction request sent by the client terminal, and invokes the smart contract deployed in the copy of the local alliance chain to perform transaction processing according to the transaction request, to obtain transaction data;
  • the master node generates a block by using transaction data to verify transaction data of the block; the block has corresponding block information;
  • the master node generates a first-stage certificate by using the complete block information, and sends the first-stage certificate to multiple backup nodes, so that the backup node separately according to the block hash value in the first-stage certificate.
  • the primary node adds the block to a copy of the local federation chain.
  • a transaction data processing method based on the Ethereum blockchain comprising:
  • the backup node receives the block broadcast by the master node, and the block is the number of transactions that the master node calls the smart contract deployed in the alliance chain to receive the transaction request when receiving the transaction request sent by the client terminal. And generated by using the transaction data; the block has corresponding block information;
  • the backup node Receiving, by the backup node, the block, and verifying transaction data of the block; the backup node receiving a first-stage certificate generated by the primary node by using complete block information, according to the first-stage certificate
  • the block hash value in the second stage certificate and the third stage certificate are respectively generated, and the block is negotiated by using the second stage certificate and the third stage certificate respectively, and the negotiation result is obtained;
  • the backup node adds the block to a copy of the local federation chain.
  • a computer device comprising a memory and one or more processors having stored therein computer readable instructions, the computer readable instructions being executable by the processor to cause the one or more processors to execute The steps of any of the above methods.
  • Computer readable instructions computer readable instructions
  • One or more computer readable non-volatile storage media storing computer readable instructions, when executed by one or more processors, causing one or more processors to perform the steps of any of the above methods .
  • Computer readable instructions computer readable instructions
  • 1 is an application scenario diagram of a blockchain system based on Ethereum in one embodiment
  • FIG. 2 is a block diagram of a blockchain system based on Ethereum in one embodiment
  • FIG. 3 is a schematic diagram of a block negotiation process in an embodiment
  • 4 is a flow chart of a blockchain method based on Ethereum in one embodiment
  • 5 is a flow chart of a blockchain method based on Ethereum in another embodiment
  • Figure 6 is a block diagram of a computer device in one embodiment.
  • the blockchain system based on Ethereum provided by the present application can be applied to the application environment as shown in FIG. 1.
  • the client terminal 102 is in communication with the first terminal 104 in the blockchain system via a network.
  • the blockchain system further includes a plurality of second terminals 106, wherein the first terminal 104 establishes a communication connection with the plurality of second terminals 106.
  • the first terminal 104 may be referred to as a primary node in a blockchain system
  • the second terminal 106 may be referred to as a backup node in a blockchain system.
  • a copy of the federated chain is stored locally in the first terminal 104 and the plurality of second terminals 106, respectively. That is, decentralization between multiple nodes of the alliance chain, and distributed storage of the alliance chain.
  • the client terminal 102 sends a transaction request to the first terminal 104, and the first terminal 104 invokes the smart contract deployed in the alliance chain to perform transaction processing according to the transaction request, and obtains transaction data.
  • the first terminal 104 generates a block using the transaction data. Before the block is written into the federation chain, a consensus needs to be reached in the blockchain system. Consensus on the block requires verification and negotiation of the block.
  • the first terminal 104 broadcasts the block to the plurality of second terminals 106.
  • the second terminal 106 receives the block and verifies the transaction data of the block.
  • the block negotiation may include three stages, and the first terminal 104 generates the first stage certificate required for the first stage negotiation by using the complete block information, and transmits the first stage certificate to the plurality of second terminals 106.
  • the second terminal 106 generates a second-stage certificate by using the block hash value in the first-stage certificate, sends the second-stage certificate to the first terminal 104 and the other second terminal 106 for the second-stage negotiation, and utilizes the block.
  • the hash generates a third-phase certificate, and the third-stage certificate is sent to the first terminal 104 and the other second terminal 106 for the third-phase negotiation.
  • the first terminal 104 and the plurality of second terminals 106 respectively add the blocks to the copies of the local federation chain.
  • the third-stage certificate is not complete block information, but a block hash value that can uniquely identify a block. Therefore, it is possible to effectively reduce network resource consumption and save communication overhead in the block consensus process.
  • a blockchain system based on Ethereum including a master node 202 and a plurality of backup nodes 204, wherein:
  • the master node 202 is configured to receive a transaction request sent by the client terminal, invoke a smart contract deployed in the alliance chain to perform transaction processing according to the transaction request, and obtain transaction data; use the transaction data to generate a block, and the block has corresponding block information, and The block broadcasts to multiple backup nodes.
  • the backup node 204 is configured to receive the block and verify the transaction data of the block.
  • the master node 202 is further configured to generate the first-stage certificate by using the complete block information, and send the first-stage certificate to the multiple backup nodes.
  • the backup node 204 is further configured to generate the first-stage certificate according to the block hash value in the first-stage certificate.
  • the second-stage certificate and the third-stage certificate respectively use the second-stage certificate and the third-stage certificate to negotiate the block and obtain the negotiation result.
  • the primary node 202 and the plurality of backup nodes 204 respectively add the blocks to the copy of the local federation chain.
  • the blockchain system based on Ethereum includes a plurality of nodes, and the nodes include a primary node and a backup node. There can be only one primary node and multiple backup nodes. Multiple nodes can form a Byzantine system.
  • the node has a corresponding configuration file, and the IP address is recorded in the configuration file.
  • Each node establishes a communication connection with other nodes according to the IP address in the configuration file.
  • the corresponding public key is sent to other nodes, and the other nodes complete the verification by the private key signature.
  • the verification indicates that an effective connection is established between the nodes. .
  • a federated chain can be seen as a decentralized, distributed digital ledger between affiliates.
  • a copy of the federation chain is stored locally on both the primary node and the backup node.
  • a copy of the digital ledger is recorded in each of the nodes corresponding to the blockchain system corresponding to the alliance chain.
  • the alliance chain contains multiple blocks, each of which records the transaction data corresponding to the electronic transaction, including transaction time, transaction object, transaction type, transaction amount and transaction quantity.
  • Smart contracts can be deployed in advance on the alliance chain. Smart contracts can be understood as an executable Code, and defines the rights and obligations of contract participants. Smart contracts allow parties to trade electronically in accordance with contracts.
  • the master node can receive the transaction request sent by the client terminal, and execute the transaction by calling the smart contract to obtain the transaction data.
  • the master node generates the block using the transaction data. Specifically, before the master node generates the block by using the transaction data, the master node obtains the optimal block in the local link chain copy, and determines whether the timestamp of the current time interval from the optimal block is less than a threshold.
  • the threshold can be the maximum time required to reach a consensus in the blockchain system. If it is less than the threshold, the block is generated using the transaction data.
  • the block has corresponding block information, and in addition to recording transaction data, the block information also records information such as a hash value corresponding to the block.
  • the hash value contains the block hash value and the parent hash value.
  • the block hash value is a unique identifier for a block.
  • the parent hash value refers to the block hash value of the previous block corresponding to a block.
  • the master node broadcasts the newly generated block to multiple backup nodes.
  • the backup node receives the block and makes a consensus on the block.
  • the consensus includes both verification and negotiation. Verification can be that multiple nodes (including the primary node and the backup node) verify the legality of the block locally.
  • Negotiation requires multiple nodes to agree through three phases of negotiation.
  • the node Before the node (including the primary node and the backup node) checks the newly generated block, obtain the optimal block in the local link chain copy, obtain the parent hash value of the newly generated block, and determine the newly generated block. Whether the parent hash value points to the optimal block, and if so, the transaction data of the newly generated block is verified; otherwise, the newly generated block is added to the local transaction list.
  • the node checks the transaction data of the newly generated block, the Merkle tree is generated by using the transaction data contained in the block, and the root hash value of the Merkle tree is calculated. The node acquires the block header transaction tree corresponding to the newly generated block, and calculates a hash value of the transaction tree.
  • the node modifies the account information corresponding to the transaction, uses the modified account information to generate a state tree corresponding to the block, and calculates a root hash value of the state tree.
  • the node generates a receipt tree based on the copy of the warehouse class and calculates the root hash value of the receipt tree. If the root hash value of the state tree is the same as the root hash value of the receipt tree, the transaction data of the newly generated block is verified.
  • the consensus of the block also needs to be negotiated and agreed upon by multiple nodes of the blockchain system.
  • Root According to the Byzantine algorithm, the number of nodes that a Byzantine system can tolerate Byzantine errors does not exceed one third of the total number of nodes. That is to say, in the Byzantine system, as long as two-thirds of the nodes feedback to a block agree to join the information in the alliance chain, the negotiation is successful and an agreement is reached.
  • a blockchain system includes at least four nodes.
  • pre-preparation phase also called first phase
  • preparation phase also called second phase
  • confirmation phase also called third stage
  • Each stage has a corresponding certificate.
  • the certificate is also the message transmitted during the block consensus process.
  • the negotiation process of the block is shown in FIG. 3, in which the master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to multiple backup nodes.
  • the complete block information is also the block information corresponding to one block.
  • the master node enters the second phase state (ie, the ready state).
  • the backup node receives the first-stage certificate, it receives the complete block information of the block, and the backup node enters the second-stage state.
  • the backup node determines that the first-phase certificate is from the primary node and is receiving the certificate for the first time, the backup node saves the first-phase certificate.
  • the block information corresponding to the newly generated block is recorded in each backup node.
  • the backup node calculates a corresponding block hash value according to the complete block information, and generates a second stage certificate by using the block hash value.
  • the other nodes check the second-stage certificate. After the verification is passed, the information agreed to the second-stage certificate can be returned.
  • the backup node receives the information returned by the 2f nodes for the second stage certificate
  • the backup node enters the third stage.
  • the backup node uses the block hash value to generate a third-stage certificate, and sends the third-stage certificate to other nodes.
  • the negotiation of the newly generated block in the blockchain system is completed. Since the block hash value can uniquely identify a block, the second stage certificate and the third stage certificate can accurately reflect the negotiated block.
  • the PBFT mechanism can be used to divide the execution process of the blockchain system into a view, and the view includes a primary node and multiple backup nodes.
  • Each node (including the primary node and the backup node) is initialized with the same view identifier.
  • the backup node can also generate the second-stage certificate and the third-stage certificate by using the block hash value, the view identifier, and the node identifier. Since the second stage certificate and the third stage certificate contain the view identifier and the node identifier, it is possible to quickly identify which node issued the message in the second stage and the third stage, so that other nodes can return to the node. The message of consent is conducive to improving the efficiency of consultation.
  • the block reaches a consensus in the blockchain system.
  • the master node and the backup node respectively add the consensus blocks to the copy of the local federation chain. Thereby, the transaction initiated by the client terminal can be realized safely and effectively.
  • each stage needs to generate a corresponding certificate by using the complete block information.
  • multiple backup nodes are used to transmit certificates including complete block information, which results in a large amount of network resources being consumed during the negotiation process, resulting in large communication overhead.
  • only the first block information is used to generate the first stage certificate in the first stage of the negotiation, and the second stage certificate and the third part are respectively generated by the block hash value in the second stage and the third stage.
  • the phase certificate can effectively reduce network resource consumption and save communication overhead during the negotiation process of the second phase and the third phase.
  • the verification code and the negotiation code are written in a package of a class.
  • the verification and negotiation of the block can only be performed in a serial manner, and the coupling degree of the two parts is relatively high, resulting in a low consensus efficiency of the block.
  • the verification code and the negotiation code are respectively written in different classes of packets.
  • Each node can separately run the class corresponding to the verification code and the class corresponding to the negotiation code, so that the verification and negotiation of the block can be performed asynchronously, which reduces the coupling degree of verification and negotiation. Not only is it beneficial for code maintenance, but it can also effectively improve the consensus efficiency of the block.
  • the master node after receiving the transaction request sent by the client terminal, invokes the smart contract deployed in the alliance chain to perform transaction processing.
  • the master node generates a block using the transaction data and broadcasts the block to a plurality of backup nodes in the blockchain system.
  • Prepare The serving node verifies the received block.
  • the master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to multiple backup nodes.
  • the multiple backup nodes respectively generate the second-stage certificate and the third according to the block hash value in the first-stage certificate.
  • the phase certificate uses the second-stage certificate and the third-stage certificate to negotiate the block and obtain the negotiation result.
  • the block verification passes and the negotiation is successful, it indicates that the block reaches a consensus in the blockchain system, and can be written into the copy of the local alliance chain by the primary node and the backup node respectively.
  • the second-stage certificate and the third-stage certificate transmitted during the negotiation process are not complete block information, but a block hash value that can uniquely identify a block. Therefore, it is possible to effectively reduce network resource consumption and save communication overhead in the block consensus process. Thereby, the problem of effectively reducing network resource consumption when transacting through the alliance chain is realized.
  • the master node and the backup node are further configured to obtain a timestamp corresponding to the optimal block in the local coalition chain, and obtain a first phase certificate, a second phase certificate, and a third phase certificate generation time; If the generation time of the stage certificate or the generation time of the second stage certificate or the generation time of the third stage certificate is earlier than the timestamp corresponding to the optimal block, the first stage certificate or the second stage certificate or the third stage certificate is cleared.
  • each node In the blockchain system based on Ethereum, a large number of certificates are generated during the negotiation process of the block, and each node will record a large number of certificates correspondingly, including the first-stage certificate, the second-stage certificate and the third-stage certificate. .
  • the invalid certificate In the traditional PBFT mechanism, in order to reduce the memory consumption of the node, the invalid certificate can be deleted through the checkpoint protocol. However, in the traditional checkpoint protocol, timing negotiation between multiple nodes is required, and the invalid certificates are agreed according to the PBFT mechanism. After the consensus is reached, each node deletes the invalid certificate. Due to the consensus process, three phases of negotiation are required, and each phase of the negotiation needs to transmit the corresponding certificate, which leads to more network resources in the consensus process.
  • each node may perform certificate clearing according to the timestamp of the optimal block in the alliance chain.
  • the alliance chain is formed in the form of a linked list according to the generation time of the block.
  • a block When a block is added to the alliance chain, it indicates that the certificates before the timestamp of the block have been verified, that is, in the node.
  • the certificate-related status has been broadcast and can be cleared, and the certificate information can be saved in the node forever in the form of a block. Therefore, each node can add a local to the local area. Block events are listened to, and whenever a block is added to a copy of the federated chain, the certificate stored locally before the block timestamp is cleared. The whole process does not require mutual communication between nodes, and also ensures timely cleaning of certificates, which effectively saves network resource consumption.
  • the backup node includes a first backup node and a second backup node.
  • the first The backup node requests the other backup node for the block hash value corresponding to the block to be added in the local link chain copy. If the same hash value exists in the received block hash value and the same number exceeds the threshold, then the The block hash value obtains the first-stage certificate locally, and the corresponding block is added to the local link chain copy through the first-stage certificate.
  • the solution of the inter-node synchronization block is included in the Ethereum, that is, when a node finds that the block chain maintained by itself is different from the block number of the optimal block of the block chain maintained by its trusted node, A node asks for a block that it trusts (usually a node maintained by the developer) and adds the block to the blockchain. There is no fully trusted node in the alliance chain, so this scheme is not feasible in the alliance chain.
  • the first backup node may request the block hash value corresponding to the block to be added by the link chain copy to the 2f+1 nodes in the belonging view.
  • a block hash value is a 256-bit byte array that uniquely identifies a block.
  • the first backup node locally queries the first-stage certificate corresponding to the block. If the first-stage certificate is queried, the complete block information can be obtained according to the first-stage certificate, thereby directly adding the required block to the In the local alliance chain copy, synchronization with other node alliance chains is realized. In this process, the first backup node does not need to request the block from other backup nodes or the master node, and the block can be added through the first-stage certificate stored locally, which effectively saves network resource consumption.
  • the primary node and the plurality of backup nodes form a corresponding view; when the primary node sends When a fault occurs, multiple backup nodes are also used to obtain the time, performance index, and response times of the joined blockchain corresponding to all the backup nodes in the associated view; the new one is elected according to the time, performance index, and response times of the added blockchain.
  • the primary node when the primary node sends When a fault occurs, multiple backup nodes are also used to obtain the time, performance index, and response times of the joined blockchain corresponding to all the backup nodes in the associated view; the new one is elected according to the time, performance index, and response times of the added blockchain.
  • a view switching protocol is also provided.
  • the view can be identified in the manner mentioned in the above embodiments.
  • the primary node fails the next numbered backup node becomes the new primary node.
  • the view also switches, and the view number increases by 1. For example, if the view is marked as v and there are N nodes in the view, the master node can be marked as p, and the backup node is marked as 0, 1, ..., N-1.
  • the backup node numbered 0 becomes the new primary node and the view number is v+1.
  • the abnormality judgment of the primary node may be determined by using the timestamp and the threshold of the optimal block in the local alliance chain copy of each node.
  • the threshold may be the maximum time that the blockchain system agrees, and the time from the generation to the addition of the block to the blockchain is less than the threshold.
  • the optimal block timestamp and the current time interval are greater than the threshold, it is determined that the primary node is abnormal; or when the primary node or the backup node
  • the transaction list is empty, if no block is added to the local federation chain copy within the threshold time, it is determined that the primary node has an exception. Therefore, by using the timestamp and the threshold corresponding to the optimal block, it is possible to quickly and effectively confirm whether the primary node in the blockchain system is abnormal.
  • multiple backup nodes elect a new primary node, triggering a view switch.
  • Multiple backup nodes can be elected according to the following rules to obtain a new primary node: the time when the backup node joins the blockchain system; the performance index of the backup node; and the number of responses of the backup node.
  • the time at which the backup node joins the blockchain coefficient has a first weight
  • the performance parameter of the backup node has a second weight
  • the response number of the backup node has a third weight.
  • the backup node calculates the weight values of the other nodes by using the first weight, the second weight, and the third weight, respectively, and elects a new primary node according to the weight value.
  • the new master node and other backup nodes form a new view to complete the view switch.
  • FIG. 4 a transaction data processing method based on the Ethereum blockchain
  • the steps in the flowchart of FIG. 4 are sequentially displayed as indicated by the arrows, these The steps are not necessarily performed in the order indicated by the arrows. Except as explicitly stated herein, the execution of these steps is not strictly limited, and may be performed in other sequences. Moreover, at least some of the steps in FIG. 4 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be executed at different times, and the order of execution thereof is not necessarily This may be performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of the other steps. Includes the following steps:
  • Step 402 The master node receives the transaction request sent by the client terminal, and invokes the smart contract deployed in the copy of the local alliance chain to perform transaction processing according to the transaction request, to obtain transaction data.
  • Step 404 The master node uses the transaction data to generate a block, and verifies the transaction data of the block; the block has corresponding block information;
  • Step 406 The master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to the multiple backup nodes, so that the backup node generates the second-stage certificate according to the block hash value in the first-stage certificate. And the third-stage certificate, the receiving backup node obtains the negotiation result obtained by negotiating the block by using the second-stage certificate and the third-stage certificate respectively;
  • Step 408 When the block verification passes and the negotiation result is successful, the primary node adds the block to the copy of the local federation chain.
  • a copy of the federation chain is stored locally on both the primary node and the backup node.
  • a smart contract can also be deployed on the alliance chain, and the master node can receive the transaction request sent by the client terminal, and execute the transaction by calling the smart contract to obtain the transaction data.
  • the master node generates the block using the transaction data.
  • the master node broadcasts the newly generated block to multiple backup nodes.
  • the backup node receives the block and makes a consensus on the block.
  • the consensus includes both verification and negotiation.
  • the verification may be that multiple nodes (including the primary node and the backup node) respectively verify the transaction data of the block locally.
  • Negotiation requires multiple nodes to agree through three phases of negotiation.
  • the negotiation of the block needs to go through three phases, including: the pre-preparation phase (also called the first phase), the preparation phase (also called the second phase), and the confirmation phase (also Called the third stage).
  • Each stage has a corresponding certificate.
  • the master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to multiple backup nodes.
  • the master node enters the second phase state (ie, the ready state).
  • the backup node receives the first-stage certificate, it receives the complete block information of the block, and the backup node enters the second-stage state.
  • the backup node saves the first-stage certificate. Thereby, the block information corresponding to the newly generated block is recorded in each backup node.
  • the backup node calculates a corresponding block hash value according to the complete block information, and generates a second stage certificate by using the block hash value.
  • the other nodes check the second-stage certificate. After the verification is passed, the information agreed to the second-stage certificate can be returned.
  • the backup node receives the information returned by the 2f nodes for the second stage certificate
  • the backup node enters the third stage.
  • the backup node uses the block hash value to generate a third-stage certificate, and sends the third-stage certificate to other nodes.
  • the negotiation of the newly generated block in the blockchain system is completed. Since the block hash value can uniquely identify a block, the second stage certificate and the third stage certificate can accurately reflect the negotiated block.
  • the block reaches a consensus in the blockchain system.
  • the master node and the backup node respectively add the consensus blocks to the copy of the local federation chain. Thereby, the transaction initiated by the client terminal can be realized safely and effectively.
  • the second-stage certificate and the third-stage certificate transmitted during the negotiation process are not complete block information, but may be a block hash value that uniquely identifies a block. Therefore, it is possible to effectively reduce network resource consumption and save communication overhead in the block consensus process. Thereby, the problem of effectively reducing network resource consumption when transacting through the alliance chain is realized.
  • the method further includes: the master node acquires a timestamp corresponding to the optimal block in the local coalition chain; and the master node acquires a first-stage certificate, a second-stage certificate, and a third-stage certificate generation time; The first-stage certificate or the second-stage certificate or the third-stage certificate is cleared when the generation time of the one-stage certificate or the generation time of the second-stage certificate or the generation time of the third-stage certificate is earlier than the timestamp corresponding to the optimal block.
  • the master node may perform certificate clearing according to the timestamp of the optimal block in the local link chain replica.
  • the certificate includes the first stage certificate, the second stage certificate and the third stage certificate.
  • the alliance chain is formed in the form of a linked list according to the generation time of the block.
  • the method further includes: when the number of blocks in the local link chain copy is less than the number of blocks in the first backup node, sending the block hash corresponding to the block to be added to the other backup node.
  • the first-stage certificate is obtained locally; the corresponding block is added to the local federated chain copy through the first-stage certificate.
  • a block hash value is a 256-bit byte array that uniquely identifies a block.
  • the master node locally queries the first-stage certificate corresponding to the block. If the first-stage certificate is queried, the complete block information can be obtained according to the first-stage certificate, thereby directly adding the required block to the primary node. In the local link chain copy, synchronization with other backup node alliance chains is implemented. In this process, the master node does not need to request the block from other backup nodes, and the block can be added through the first-stage certificate stored locally, which effectively saves network resource consumption.
  • a number of transactions based on the Ethereum blockchain is provided.
  • the respective steps in the flowchart of FIG. 5 are sequentially displayed in accordance with the indication of the arrows, these steps are not necessarily performed in the order indicated by the arrows. Except as explicitly stated herein, the execution of these steps is not strictly limited, and may be performed in other sequences. Moreover, at least some of the steps in FIG.
  • 5 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be executed at different times, and the order of execution thereof is not necessarily This may be performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of the other steps. Includes the following steps:
  • Step 502 The backup node receives the block broadcast by the master node, where the master node invokes the smart contract deployed in the alliance chain to obtain the transaction data when the transaction request sent by the client terminal is received, and generates the transaction data by using the transaction data;
  • the block has corresponding block information;
  • Step 504 The backup node receives the block, and verifies the transaction data of the block.
  • Step 506 The backup node receives the first-stage certificate generated by the master node by using the complete block information, and generates the second-stage certificate and the third-stage certificate according to the block hash value in the first-stage certificate, respectively, and utilizes the second stage respectively.
  • the certificate and the third-stage certificate negotiate the block and get the result of the negotiation;
  • Step 508 When the block verification passes and the negotiation result is successful negotiation, the backup node adds the block to the copy of the local alliance chain.
  • a copy of the federation chain is stored locally on both the primary node and the backup node.
  • a smart contract can also be deployed on the alliance chain, and the master node can receive the transaction request sent by the client terminal, and execute the transaction by calling the smart contract to obtain the transaction data.
  • the master node generates the block using the transaction data.
  • the master node broadcasts the newly generated block to multiple backup nodes.
  • the backup node receives the block and makes a consensus on the block.
  • the consensus includes both verification and negotiation.
  • the verification may be that multiple nodes (including the primary node and the backup node) respectively verify the transaction data of the block locally.
  • Negotiation requires multiple nodes to agree through three phases of negotiation.
  • pre-preparation phase also called first phase
  • preparation phase also called second phase
  • confirmation phase also called third stage
  • Each stage has a corresponding certificate.
  • the master node uses the complete block information to generate
  • the first-stage certificate is sent to the multiple backup nodes.
  • the master node enters the second phase state (ie, the ready state).
  • the backup node receives the first-stage certificate, it receives the complete block information of the block, and the backup node enters the second-stage state.
  • the backup node saves the first-stage certificate. Thereby, the block information corresponding to the newly generated block is recorded in each backup node.
  • the backup node calculates a corresponding block hash value according to the complete block information, and generates a second stage certificate by using the block hash value.
  • the other nodes check the second-stage certificate. After the verification is passed, the information agreed to the second-stage certificate can be returned.
  • the backup node receives the information returned by the 2f nodes for the second stage certificate
  • the backup node enters the third stage.
  • the backup node uses the block hash value to generate a third-stage certificate, and sends the third-stage certificate to other nodes.
  • the negotiation of the newly generated block in the blockchain system is completed. Since the block hash value can uniquely identify a block, the second stage certificate and the third stage certificate can accurately reflect the negotiated block.
  • the block reaches a consensus in the blockchain system.
  • the master node and the backup node respectively add the consensus blocks to the copy of the local federation chain. Thereby, the transaction initiated by the client terminal can be realized safely and effectively.
  • the second-stage certificate and the third-stage certificate transmitted during the negotiation process are not complete block information, but may be a block hash value that uniquely identifies a block. Therefore, it is possible to effectively reduce network resource consumption and save communication overhead in the block consensus process. Thereby, the problem of effectively reducing network resource consumption when transacting through the alliance chain is realized.
  • the method further includes: when the primary node fails, the backup node obtains the time, performance index, and response times of the joined blockchain corresponding to all the backup nodes in the associated view; according to the time of joining the blockchain, The new primary node is elected in the performance index and response times.
  • the primary node when the transaction list in the backup node is not empty, if the optimal block timestamp and the current time interval are greater than the threshold, it is determined that the primary node is abnormal; or when the transaction list in the backup node is empty, If no blocks are added to the local federated chain copy within the threshold time, then the primary is determined An exception occurred on the node.
  • multiple backup nodes elect a new primary node, triggering a view switch.
  • Multiple backup nodes can be elected according to the time when the backup node joins the blockchain system; the performance index of the backup node; the number of responses of the backup node is elected to obtain a new primary node.
  • the new master node and other backup nodes form a new view to complete the view switch.
  • the method further includes: the backup node acquiring a timestamp corresponding to the optimal block in the local coalition chain; and the backup node acquiring the first-stage certificate, the second-stage certificate, and the generation time of the third-stage certificate;
  • the first-stage certificate or the second-stage certificate or the third-stage certificate is cleared when the generation time of the one-stage certificate or the generation time of the second-stage certificate or the generation time of the third-stage certificate is earlier than the timestamp corresponding to the optimal block.
  • the backup node may perform certificate clearing according to the timestamp of the optimal block in the local link chain replica.
  • the certificate includes the first stage certificate, the second stage certificate and the third stage certificate.
  • the alliance chain is formed in the form of a linked list according to the generation time of the block.
  • the backup node can listen to the local added block event, and whenever a block is added to the copy of the federated chain, the certificate stored in the local node before the block time stamp is cleared. The whole process does not require mutual communication between nodes, and also ensures timely cleaning of certificates, which effectively saves network resource consumption.
  • a computer device such as a primary node or a backup node in a blockchain system, wherein the primary or backup node can be a desktop computer, a laptop or a server, and the like.
  • the computer device includes a processor, a memory, and a network interface connected by a system bus.
  • the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory. Nonvolatile of the computer device
  • the storage medium stores an operating system and computer readable instructions.
  • the internal memory of the computer device provides an environment for the operation of an operating system and computer readable instructions in a non-volatile storage medium.
  • the network interface of the computer device is used to communicate with an external terminal via a network connection.
  • the computer readable instructions are executed by the processor to implement a transaction data processing method based on the Ethereum blockchain.
  • a computer apparatus comprising a memory and one or more processors having stored therein computer readable instructions that, when executed by the processor, cause The one or more processors perform the following steps:
  • the master node receives the transaction request sent by the client terminal, and invokes the smart contract deployed in the copy of the local alliance chain according to the transaction request to perform transaction processing to obtain transaction data;
  • the master node uses the transaction data to generate a block, and verifies the transaction data of the block; the block has corresponding block information;
  • the master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to the multiple backup nodes, so that the backup node generates the second-stage certificate and the third according to the block hash value in the first-stage certificate.
  • a phase certificate the result of the negotiation obtained by the receiving backup node using the second-stage certificate and the third-stage certificate to negotiate the block;
  • the master node adds the block to the copy of the local federation chain.
  • the computer readable instructions are executed by the processor such that the one or more processors further perform the following steps:
  • the master node obtains a timestamp corresponding to the optimal block in the local coalition chain
  • the master node obtains the generation time of the first-stage certificate, the second-stage certificate, and the third-stage certificate.
  • the generation time is earlier than the timestamp corresponding to the optimal block, and the first-stage certificate or the second-stage certificate or the third-stage certificate is cleared.
  • the computer readable instructions are executed by the processor such that the one or more processors further perform the following steps:
  • the acquiring request of the block hash value corresponding to the block to be added is sent to the other backup nodes;
  • the corresponding block is added to the local federated chain copy through the first stage certificate.
  • a computer apparatus comprising a memory and one or more processors having stored therein computer readable instructions that, when executed by the processor, cause The one or more processors perform the following steps:
  • the backup node receives the block broadcast by the master node, and the block is the master node that calls the smart contract deployed in the alliance chain to obtain the transaction data when receiving the transaction request sent by the client terminal, and generates the transaction data by using the transaction data; the block has a corresponding Block information;
  • the backup node verifies the transaction data of the received block
  • the backup node receives the first-stage certificate generated by the master node by using the complete block information, and generates the second-stage certificate and the third-stage certificate according to the block hash value in the first-stage certificate, respectively, and utilizes the second-stage certificate and the first-stage certificate respectively.
  • the three-stage certificate negotiates the block and obtains the result of the negotiation;
  • the backup node adds the block to the copy of the local federation chain.
  • the computer readable instructions are executed by the processor such that the one or more processors further perform the following steps:
  • the backup node obtains the time, performance index, and response times of the joined blockchain corresponding to all the backup nodes in the associated view;
  • the computer readable instructions are executed by the processor such that the one or more processors further perform the following steps:
  • the backup node obtains a timestamp corresponding to the optimal block in the local coalition chain
  • the backup node obtains the generation time of the first-stage certificate, the second-stage certificate, and the third-stage certificate.
  • the generation time of the first stage certificate or the generation time of the second stage certificate or the generation time of the third stage certificate is earlier than the timestamp corresponding to the optimal block, the first stage certificate or the second stage certificate or the third stage is cleared. certificate.
  • one or more computer readable non-volatile storage media storing computer readable instructions are provided, the computer readable instructions being executed by one or more processors such that one or more The processor performs the following steps:
  • the master node receives the transaction request sent by the client terminal, and invokes the smart contract deployed in the copy of the local alliance chain according to the transaction request to perform transaction processing to obtain transaction data;
  • the master node uses the transaction data to generate a block, and verifies the transaction data of the block; the block has corresponding block information;
  • the master node generates the first-stage certificate by using the complete block information, and sends the first-stage certificate to the multiple backup nodes, so that the backup node generates the second-stage certificate and the third according to the block hash value in the first-stage certificate.
  • a phase certificate the result of the negotiation obtained by the receiving backup node using the second-stage certificate and the third-stage certificate to negotiate the block;
  • the master node adds the block to the copy of the local federation chain.
  • the one or more processors when the computer readable instructions are executed by one or more processors, the one or more processors further perform the following steps:
  • the master node obtains a timestamp corresponding to the optimal block in the local coalition chain
  • the master node obtains the generation time of the first-stage certificate, the second-stage certificate, and the third-stage certificate.
  • the generation time is earlier than the timestamp corresponding to the optimal block, and the first-stage certificate or the second-stage certificate or the third-stage certificate is cleared.
  • the one or more processors when the computer readable instructions are executed by one or more processors, the one or more processors further perform the following steps:
  • the acquiring request of the block hash value corresponding to the block to be added is sent to the other backup nodes;
  • the corresponding block is added to the local federated chain copy through the first stage certificate.
  • one or more computer readable non-volatile storage media storing computer readable instructions are provided, the computer readable instructions being executed by one or more processors such that one or more The processor performs the following steps:
  • the backup node receives the block broadcast by the master node, and the block is the master node that calls the smart contract deployed in the alliance chain to obtain the transaction data when receiving the transaction request sent by the client terminal, and generates the transaction data by using the transaction data; the block has a corresponding Block information;
  • the backup node verifies the transaction data of the received block
  • the backup node receives the first-stage certificate generated by the master node by using the complete block information, and generates the second-stage certificate and the third-stage certificate according to the block hash value in the first-stage certificate, respectively, and utilizes the second-stage certificate and the first-stage certificate respectively.
  • the three-stage certificate negotiates the block and obtains the result of the negotiation;
  • the backup node adds the block to the copy of the local federation chain.
  • the one or more processors when the computer readable instructions are executed by one or more processors, the one or more processors further perform the following steps:
  • the backup node obtains the time, performance index, and response times of the joined blockchain corresponding to all the backup nodes in the associated view;
  • the one or more processors when the computer readable instructions are executed by one or more processors, the one or more processors further perform the following steps:
  • the backup node obtains a timestamp corresponding to the optimal block in the local coalition chain
  • the backup node obtains the generation time of the first-stage certificate, the second-stage certificate, and the third-stage certificate.
  • the generation time of the first stage certificate or the generation time of the second stage certificate or the generation time of the third stage certificate is earlier than the timestamp corresponding to the optimal block, the first stage certificate or the second stage certificate or the third stage is cleared. certificate.
  • the dysfunctional computer can be readable in a storage medium, which when executed, can include the flow of an embodiment of the methods described above.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请涉及一种基于以太坊的区块链系统，包括：主节点，用于接收客户终端发送的交易请求，根据交易请求调用联盟链中部署的智能合约进行交易处理，得到交易数据；利用交易数据生成区块，将区块向多个备份节点进行广播；备份节点，用于对区块的交易数据进行验证；主节点还用于利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点；备份节点还用于根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果；当区块验证通过且协商结果为协商成功时，主节点和多个备份节点分别将区块分别添加至本地联盟链的副本中。

Description

基于以太坊的区块链系统和交易数据处理方法
本申请要求于2017年10月26日提交中国专利局、申请号为2017110170233、发明名称为“基于以太坊的区块链系统和交易数据处理方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及网络通信技术领域，特别是涉及一种基于以太坊的区块链系统和交易数据处理方法。
背景技术
联盟链通常是由一些商业联盟出于共同的利益采用以太坊技术搭建的区块链。联盟链不对外公开，只由商业联盟的各个成员进行管理。但是商业联盟的成员之间并没有完全相互信任，每一个联盟成员都需要去对区块链中其他成员进行监督，以维持联盟链准确运行。在一个新生成的区块被写入联盟链之前，需要联盟链中的各个节点达成一致意见，即达成共识。因此，联盟链的共识机制显得尤为重要。
利用联盟链进行交易时，在传统的方式中通常采用PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错算法)机制使得各个节点进行共识。在PBFT机制中，节点不需要进行挖矿，虽然避免了通过算力竞争达到共识所需的大量运算，但是PBFT共识机制的网络资源消耗较高，网络开销较大。因此，如何在通过联盟链进行交易时有效减少网络资源消耗成为目前需要解决的一个技术问题。
发明内容
根据本申请公开的各种实施例，提供一种基于以太坊的区块链系统和交易数据处理方法。
一种基于以太坊的区块链系统，包括主节点和多个备份节点，其中：
所述主节点，用于接收客户终端发送的交易请求，根据所述交易请求调用联盟链中部署的智能合约进行交易处理，得到交易数据；利用交易数据生成区块，将所述区块向多个备份节点进行广播；所述区块具有对应的区块信息；
所述备份节点，用于接收所述区块，对所述区块的交易数据进行验证；
所述主节点还用于利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点；所述备份节点还用于根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；
当所述区块验证通过且所述协商结果为协商成功时，所述主节点和多个备份节点分别将所述区块分别添加至本地联盟链的副本中。
一种基于以太坊区块链的交易数据处理方法，包括：
主节点接收客户终端发送的交易请求，根据所述交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
所述主节点利用交易数据生成区块，对所述区块的交易数据进行验证；所述区块具有对应的区块信息；
所述主节点利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点，以使得所述备份节点根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收所述备份节点分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商所得到的协商结果；及
当所述区块验证通过且所述协商结果为协商成功时，所述主节点将所述区块添加至本地联盟链的副本中。
一种基于以太坊区块链的交易数据处理方法，包括：
备份节点接收主节点广播的区块，所述区块是所述主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数 据，并利用所述交易数据生成的；所述区块具有对应的区块信息；
所述备份节点接收所述区块，对所述区块的交易数据进行验证；所述备份节点接收所述主节点利用完整的区块信息生成的第一阶段证书，根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；及
当所述区块验证通过且所述协商结果为协商成功时，所述备份节点将所述区块添加至本地联盟链的副本中。
一种计算机设备，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行上述任一项方法的步骤。计算机可读指令计算机可读指令
一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一项方法的步骤。计算机可读指令计算机可读指令
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为一个实施例中基于以太坊的区块链系统的应用场景图；
图2为一个实施例中基于以太坊的区块链系统的框图；
图3为一个实施例中区块协商过程的示意图；
图4为一个实施例中基于以太坊的区块链方法的流程图；
图5为另一个实施例中基于以太坊的区块链方法的流程图；
图6为一个实施例中计算机设备的框图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请提供的基于以太坊的区块链系统，可以应用于如图1所示的应用环境中。客户终端102通过网络与区块链系统中的第一终端104进行通信连接。区块链系统中还包括多个第二终端106，其中第一终端104与多个第二终端106两两之间建立通信连接。第一终端104可以称为区块链系统中的主节点，第二终端106可以称为区块链系统中的备份节点。第一终端104和多个第二终端106中分别在本地存储了联盟链的副本。也就是联盟链的多个节点之间去中心化，对联盟链进行分布式存储。
客户终端102向第一终端104发送交易请求，第一终端104根据交易请求调用联盟链中部署的智能合约进行交易处理，得到交易数据。第一终端104利用交易数据生成区块。区块被写入联盟链之前，需要在区块链系统中达成共识，对区块达成共识需要对区块进行验证和协商。第一终端104将区块向多个第二终端106进行广播。第二终端106接收区块，对区块的交易数据进行验证。对区块协商可以包括三个阶段，第一终端104利用完整的区块信息生成第一阶段协商所需的第一阶段证书，将第一阶段证书发送至多个第二终端106。第二终端106利用第一阶段证书中的区块哈希值生成第二阶段证书，将第二阶段证书发送至第一终端104和其他第二终端106进行第二阶段协商，以及利用区块哈希值生成第三阶段证书，将第三阶段证书发送至第一终端104和其他第二终端106进行第三阶段协商。当区块验证通过且协商成功时，表示该区块在区块链系统中达成共识。第一终端104和多个第二终端106分别将区块分别添加至本地联盟链的副本中。在协商过程中传输的第二阶段证书 和第三阶段证书并不是完整的区块信息，而是可以唯一标识一个区块的区块哈希值。因此能够在区块共识过程中有效减少网络资源消耗，节省通信开销。
在一个实施例中，如图2所示，提供了一种基于以太坊的区块链系统，包括主节点202和多个备份节点204，其中：
主节点202，用于接收客户终端发送的交易请求，根据交易请求调用联盟链中部署的智能合约进行交易处理，得到交易数据；利用交易数据生成区块，区块具有对应的区块信息，将区块向多个备份节点进行广播。
备份节点204，用于接收区块，对区块的交易数据进行验证。
主节点202还用于利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点；备份节点204还用于根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果。
当区块验证通过且协商结果为协商成功时，主节点202和多个备份节点204分别将区块分别添加至本地联盟链的副本中。
本实施例中，基于以太坊的区块链系统包括多个节点，节点包括主节点和备份节点。主节点可以只有一个，备份节点可以有多个。多个节点可以组成一个拜占庭系统。
节点具有相应的配置文件，配置文件中记录了IP地址。每个节点根据配置文件中IP地址建立与其他节点之间的通信连接，建立连接后向其他节点发送对应的公钥，其他节点通过私钥签名完成验证，验证通过即表示节点间建立了有效连接。
联盟链可以视为联盟成员之间的一个去中心化的、分布式的数字账本。主节点和备份节点上都分别在本地存储了联盟链的副本。相当于联盟链对应的区块链系统中的每一个节点中都记录了该数字账本的复印件。联盟链中包含多个区块，每个区块都分别记录了电子交易对应的交易数据，包括交易时间、交易对象、交易类型、交易金额以及交易数量等内容。
联盟链上可以预先了部署智能合约。智能合约可以理解为一段可执行的 代码，并且定义了合约参与方的权利和义务。通过智能合约可以使得参与方按照合约进行电子交易。主节点可以接收客户终端发送的交易请求，通过调用智能合约进行交易，得到交易数据。主节点利用交易数据生成区块。具体的，主节点在利用交易数据生成区块之前，获取本地联盟链副本中的最优区块，判断当前时间距离最优区块的时间戳是否小于阈值。阈值可以是区块链系统中对区块达成一致所需的最长时间。若小于阈值，则利用交易数据生成区块。区块具有对应的区块信息，区块信息中除了记录交易数据之外，还记录了区块对应的哈希值等信息。其中，哈希值包含区块哈希值和父哈希值。区块哈希值是一个区块的唯一标识。父哈希值是指一个区块对应的上一个区块的区块哈希值。
主节点将新生成的区块向多个备份节点进行广播。备份节点接收该区块，对区块进行共识。共识包括验证和协商两部分。验证可以是多个节点(包括主节点和备份节点)分别在本地对区块的合法性进行验证。协商需要多个节点通过三个阶段的协商达成一致。
节点(包括主节点和备份节点)对新生成的区块进行校验之前，获取本地联盟链副本中的最优区块，获取新生成的区块的父哈希值，判断新生成的区块的父哈希值是否指向最优区块，若是，则对新生成的区块的交易数据进行校验；否则，将新生成的区块添加至本地交易列表中。节点对新生成的区块的交易数据进行校验时，利用区块中包含的交易数据生成Merkle树，计算Merkle树的根哈希值。节点获取新生成的区块对应的区块头交易树，计算交易树的哈希值。如果Merkle树的根哈希值与区块头交易树的哈希值相同，则在本地创建仓库类副本，并在该仓库类副本中执行交易。交易执行之后，节点修改交易对应的账户信息，利用修改后的账户信息生成该区块对应的状态树，计算状态树的根哈希值。节点根据该仓库类副本生成收据树，计算收据树的根哈希值。如果状态树的根哈希值与收据树的根哈希值相同，则新生成的区块的交易数据通过验证。
区块的共识还需要经过区块链系统的多个节点进行协商，达成一致。根 据拜占庭算法可知，一个拜占庭系统可以容忍发生拜占庭错误的节点数量不超过全部节点数量的三分之一。也就是说，在拜占庭系统中只要多余三分之二的节点对一个区块都反馈了同意加入联盟链中的信息，则协商成功，达成一致。为了可以容忍拜占庭错误，本实施例中的区块链系统中共有3f+1个节点，其中f是该系统中允许出现的最大错误节点数量。例如，区块链系统中至少包括四个节点。根据PBFT机制，区块的协商需要经过三个阶段，包括：预准备阶段(也可以称为第一阶段)、准备阶段(也可以称为第二阶段)和确认阶段(也可以称为第三阶段)。每个阶段都具有相应的证书。证书也就是在区块共识过程中所传输的消息。
区块的协商过程如图3所示，其中，主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点。完整的区块信息也就是一个区块对应的全部的区块信息。主节点进入第二阶段状态(即准备状态)。备份节点收到第一阶段证书时，即接收到区块完整的区块信息，同时该备份节点进入第二阶段状态。当备份节点确定该第一阶段证书来自与主节点并且是第一次接收到该证书时，备份节点对第一阶段证书进行保存。由此使得每个备份节点中记录了新生成的区块对应的区块信息。备份节点根据完整的区块信息计算对应的区块哈希值，利用区块哈希值生成第二阶段证书。将第二阶段证书发送给其他节点(包括主节点和其他备份节点)。其他节点对第二阶段证书进行校验，校验通过之后，可以返回对第二阶段证书同意的信息。当第二阶段信息经过2f个节点的同意，即该备份节点接收到2f个节点返回的对第二阶段证书同意的信息时，该备份节点进入第三阶段。备份节点利用区块哈希值再生成第三阶段证书，将第三阶段证书发送至其他节点。当第三阶段证书得到了2f+1个节点(包括该备份节点本身)的同意，则新生成的区块在区块链系统中的协商工作得以完成。由于区块哈希值可以唯一标识一个区块，因此第二阶段证书和第三阶段证书能够准确反映出被协商的区块。
进一步的，利用PBFT机制，可以将区块链系统的执行过程划分为视图，视图中包括一个主节点和多个备份节点。每个视图可以有相应的标识，每个 节点也可以有相应的标识。例如，视图标记为v，该视图中共有N个节点，则可以将主节点标记为p，备份节点以此标记为0，1，…，N-1，且满足p＝v mod N。各个节点(包括主节点和备份节点)采用相同的视图标识进行初始化。由于节点可以被划分为不同的视图，备份节点还可以利用区块哈希值、视图标识和节点标识生成第二阶段证书和第三阶段证书。由于第二阶段证书和第三阶段证书中包含了视图标识和节点标识，由此在第二阶段和第三阶段中能够快速识别出是由哪个节点发出的消息，以便其他节点能向该节点返回同意的消息，有利于提高协商效率。
当区块的验证工作和协商工作都完成时，该区块在区块链系统中达成共识。在，主节点和备份节点将达成共识后的区块分别添加至本地联盟链的副本中。从而使得客户终端本次发起的交易能够安全有效的得以实现。
在传统的PBFT机制中，区块协商的三个阶段中，每个阶段都需要利用完整的区块信息分别生成对应的证书。协商过程中每个阶段都会通过多个备份节点来传输包括完整区块信息的证书，由此导致协商过程中会消耗大量的网络资源，造成较大的通信开销。而本实施例中，只在协商的第一阶段会使用完整的区块信息来生成第一阶段证书，在第二阶段和第三阶段利用区块哈希值分别生成第二阶段证书和第三阶段证书，由此能够在第二阶段和第三阶段的协商过程中能有效减少网络资源消耗，节省通信开销。
此外，在传统的方式中，验证代码和协商代码是写在一个类的包中。区块的验证和协商只能以串行的方式执行，这两部分的耦合度较高，导致区块的共识效率较低。而本实施例中，验证代码和协商代码分别写在不同的类的包中。每个节点可以分别运行验证代码对应的类和协商代码对应的类，使得区块的验证和协商可以异步执行，降低了验证与协商的耦合度。不仅有利于代码维护，而且能够有效提高区块的共识效率。
本实施例中，基于以太坊的区块链系统中，主节点接收客户终端发送的交易请求后，调用联盟链中部署的智能合约进行交易处理。主节点利用交易数据生成区块，并且将该区块向区块链系统中的多个备份节点进行广播。备 份节点对接收到的区块进行验证。主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点，多个备份节点根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果。当区块验证通过且协商成功时，表示区块在区块链系统中达成共识，可以被主节点和备份节点分别写入本地联盟链的副本中。在协商过程中所传输的第二阶段证书和第三阶段证书并不是完整的区块信息，而是可以唯一标识一个区块的区块哈希值。因此能够在区块共识过程中有效减少网络资源消耗，节省通信开销。从而实现了通过联盟链进行交易时有效减少网络资源消耗的问题。
在一个实施例中，主节点和备份节点还用于获取本地联盟链中最优区块对应的时间戳，获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
在基于以太坊的区块链系统中，对区块的协商过程中会生成大量的证书，每个节点都会相应的记录大量的证书，包括第一阶段证书、第二阶段证书和第三阶段证书。在传统的PBFT机制中，为了降低节点的内存消耗，可以通过检查点协议对失效的证书进行删除。但是传统的检查点协议中，需要多个节点之间定时协商，对失效的证书按照PBFT机制进行共识，在达成共识之后，各个节点对失效的证书进行删除。由于共识过程中，需要进行三个阶段的协商，每个阶段的协商都需要传输相应的证书，由此导致共识过程中会耗费较多的网络资源。
本实施例中，各个节点可以根据联盟链中最优区块的时间戳进行证书清除。联盟链是以链表的形式按照区块的生成时间相连而成，当一个区块添加到联盟链中，则说明在该区块的时间戳之前的证书都已经被校验过，即节点中这些证书相关的状态已经广播完毕，并可以进行清除，而证书的信息可以通过区块的形式永远保存在该节点中。因此，各个节点可以对本地的添加区 块事件进行监听，每当有区块添加到联盟链的副本中时，将该区块时间戳之前存储在该节点本地的证书进行清除。整个过程不需要节点间相互通信，同时也可以保证证书及时的清理，有效节省了网络资源的消耗。
在一个实施例中，备份节点包括第一备份节点和第二备份节点，当第一备份节点本地联盟链副本的区块数量少于第二备份节点本地联盟链副本的区块数量时，第一备份节点向其他备份节点请求本地联盟链副本中需要添加的区块对应的区块哈希值，若接收到的区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据区块哈希值在本地获取第一阶段证书，通过第一阶段证书将对应区块添加至本地联盟链副本中。
以太坊中包含了节点间同步区块的解决方案，即当一个节点发现自身维护的区块链与其可信任的节点维护的区块链的最优区块的区块号相差一定大小时，该节点会向其信任的节点(一般为开发者维护的节点)索要区块并将区块添加到区块链中。而在联盟链中并不存在完全可信的节点，因此这一方案在联盟链中并不可行。
本实施例中，当某节点(主节点或备份节点)的联盟链副本的状态与其他节点的联盟链副本的状态不一致时，例如，当第一备份节点本地联盟链副本的区块数量少于第二备份节点本地联盟链副本的区块数量时，第一备份节点可以向所属视图中的2f+1个节点请求其联盟链副本需要添加的区块对应的区块哈希值。区块哈希值是可以唯一标识区块的256位字节数组。当有不少于f+1个节点返回的区块哈希值一致时，表示该区块哈希值对应的区块在区块链系统中达成共识。第一备份节点在本地查询该区块对应的第一阶段证书，如果查询到第一阶段证书，则根据第一阶段证书可以获得完整的区块信息，由此可以直接将所需区块添加至本地联盟链副本中，实现了与其他节点联盟链的同步。在这个过程中，第一备份节点不需向其他备份节点或主节点索取区块，通过本地存储的第一阶段证书既可以完成区块添加，有效节省了网络资源的消耗。
在一个实施例中，主节点和多个备份节点组成相应的视图；当主节点发 生故障时，多个备份节点还用于获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
在传统的PBFT机制中，还提供了视图切换协议。视图可以按上述实施例中提及的方式进行标识。当主节点发生故障时，下一个编号的备份节点即可成为新的主节点。视图也随之发生切换，视图编号增加1。例如，视图标记为v，该视图中共有N个节点，则可以将主节点标记为p，备份节点以此标记为0，1，…，N-1。当主节点发生故障时，编号为0的备份节点即成为新的主节点，视图编号为v+1。
本实施例中，主节点的异常判断可以通过各个节点的本地联盟链副本中的最优区块的时间戳与阈值进行判断。其中，阈值可以是区块链系统达成一致的最长时间，一个区块从生成到添加到区块链的时间小于阈值。
在其中一个实施例中，当主节点或备份节点中的交易列表不为空时，若最优区块时间戳与当前时间间隔大于阈值，则确定主节点出现异常；或者当主节点或备份节点中的交易列表为空时，如果阈值时间内没有区块添加到本地联盟链副本中，则确定主节点发生异常。由此通过最优区块对应的时间戳与阈值，能够快速有效的确认区块链系统中的主节点是否发生异常。
在确定主节点发生异常时，多个备份节点选举新的主节点，触发视图切换。多个备份节点可以根据以下规则进行选举，得到新的主节点:备份节点加入到区块链系统中的时间；备份节点的性能指数；备份节点的响应次数。备份节点加入区块链系数的时间具有第一权重，备份节点的性能参数具有第二权重，备份节点的响应次数具有第三权重。备份节点利用第一权重、第二权重和第三权重分别计算其他节点的权重值，根据权重值选举出新的主节点。新的主节点和其他备份节点组成新的视图，从而完成视图切换。
由于在选举中考虑到了备份节点加入区块链系统的时间长短、备份节点的性能指数和响应次数等，由此能够确保选举得到的新的主节点的性能是众多从节点中性能最优的。从而能够使得切换后的视图更加稳健。
在一个实施例中，如图4所示，一种基于以太坊区块链的交易数据处理方法，应该理解的是，虽然图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。包括以下步骤：
步骤402，主节点接收客户终端发送的交易请求，根据交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
步骤404，主节点利用交易数据生成区块，对区块的交易数据进行验证；区块具有对应的区块信息；
步骤406，主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点，以使得备份节点根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收备份节点分别利用第二阶段证书和第三阶段证书对区块进行协商所得到的协商结果；
步骤408，当区块验证通过且协商结果为协商成功时，主节点将区块添加至本地联盟链的副本中。
本实施例中，主节点和备份节点上都分别在本地存储了联盟链的副本。联盟链上还可以部署智能合约，主节点可以接收客户终端发送的交易请求，通过调用智能合约进行交易，得到交易数据。主节点利用交易数据生成区块。主节点将新生成的区块向多个备份节点进行广播。备份节点接收该区块，对区块进行共识。共识包括验证和协商两部分。验证可以是多个节点(包括主节点和备份节点)分别在本地对区块的交易数据进行验证。协商需要多个节点通过三个阶段的协商达成一致。
根据PBFT机制，区块的协商需要经过三个阶段，包括：预准备阶段(也可以称为第一阶段)、准备阶段(也可以称为第二阶段)和确认阶段(也可以 称为第三阶段)。每个阶段都具有相应的证书。主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点。主节点进入第二阶段状态(即准备状态)。备份节点收到第一阶段证书时，即接收到区块完整的区块信息，同时该备份节点进入第二阶段状态。备份节点对第一阶段证书进行保存。由此使得每个备份节点中记录了新生成的区块对应的区块信息。备份节点根据完整的区块信息计算对应的区块哈希值，利用区块哈希值生成第二阶段证书。将第二阶段证书发送给其他节点(包括主节点和其他备份节点)。其他节点对第二阶段证书进行校验，校验通过之后，可以返回对第二阶段证书同意的信息。当第二阶段信息经过2f个节点的同意，即该备份节点接收到2f个节点返回的对第二阶段证书同意的信息时，该备份节点进入第三阶段。备份节点利用区块哈希值再生成第三阶段证书，将第三阶段证书发送至其他节点。当第三阶段证书得到了2f+1个节点(包括该备份节点本身)的同意，则新生成的区块在区块链系统中的协商工作得以完成。由于区块哈希值可以唯一标识一个区块，因此第二阶段证书和第三阶段证书能够准确反映出被协商的区块。
当区块的验证工作和协商工作都完成时，该区块在区块链系统中达成共识。在，主节点和备份节点将达成共识后的区块分别添加至本地联盟链的副本中。从而使得客户终端本次发起的交易能够安全有效的得以实现。
本实施例中，在协商过程中传输的第二阶段证书和第三阶段证书并不是完整的区块信息，而是可以唯一标识一个区块的区块哈希值。因此能够在区块共识过程中有效减少网络资源消耗，节省通信开销。从而实现了通过联盟链进行交易时有效减少网络资源消耗的问题。
在一个实施例中，该方法还包括：主节点获取本地联盟链中最优区块对应的时间戳；主节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
本实施例中，主节点可以根据本地联盟链副本中最优区块的时间戳进行证书清除。证书包括第一阶段证书、第二阶段证书和第三阶段证书。联盟链是以链表的形式按照区块的生成时间相连而成，当一个区块添加到联盟链中，则说明在该区块的时间戳之前的证书都已经被校验过，即主节点中这些证书相关的状态已经广播完毕，并可以进行清除，而证书的信息可以通过区块的形式永远保存在该节点中。因此，主节点可以对本地的添加区块事件进行监听，每当有区块添加到联盟链的副本中时，将该区块时间戳之前存储在该节点本地的证书进行清除。整个过程不需要节点间相互通信，同时也可以保证证书及时的清理，有效节省了网络资源的消耗。
在一个实施例中，该方法还包括：当本地联盟链副本中的区块数量少于第一备份节点中的区块数量时，向其他备份节点发送需要添加的区块对应的区块哈希值的获取请求；接收其他备份节点返回的区块哈希值，若接收到的多个区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据区块哈希值在本地获取第一阶段证书；通过第一阶段证书将对应区块添加至本地联盟链副本中。
当主节点的联盟链副本的状态与备份节点的联盟链副本的状态不一致时，例如，当主节点本地联盟链副本的区块数量少于第一备份节点本地联盟链副本的区块数量时，主节点可以向所属视图中的2f+1个备份节点请求其联盟链副本需要添加的区块对应的区块哈希值。区块哈希值是可以唯一标识区块的256位字节数组。当有不少于f+1个备份节点返回的区块哈希值一致时，表示该区块哈希值对应的区块在区块链系统中达成共识。主节点在本地查询该区块对应的第一阶段证书，如果查询到第一阶段证书，则根据第一阶段证书可以获得完整的区块信息，由此可以直接将所需区块添加至主节点本地的联盟链副本中，实现了与其他备份节点联盟链的同步。在这个过程中，主节点不需向其他备份节点索取区块，通过本地存储的第一阶段证书既可以完成区块添加，有效节省了网络资源的消耗。
在一个实施例中，如图5所示，提供了一种基于以太坊区块链的交易数 据处理方法，应该理解的是，虽然图5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图5中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。包括以下步骤：
步骤502，备份节点接收主节点广播的区块，区块是主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用交易数据生成的；区块具有对应的区块信息；
步骤504，备份节点接收区块，对区块的交易数据进行验证；
步骤506，备份节点接收主节点利用完整的区块信息生成的第一阶段证书，根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果；
步骤508，当区块验证通过且协商结果为协商成功时，备份节点将区块添加至本地联盟链的副本中。
本实施例中，主节点和备份节点上都分别在本地存储了联盟链的副本。联盟链上还可以部署智能合约，主节点可以接收客户终端发送的交易请求，通过调用智能合约进行交易，得到交易数据。主节点利用交易数据生成区块。主节点将新生成的区块向多个备份节点进行广播。备份节点接收该区块，对区块进行共识。共识包括验证和协商两部分。验证可以是多个节点(包括主节点和备份节点)分别在本地对区块的交易数据进行验证。协商需要多个节点通过三个阶段的协商达成一致。
根据PBFT机制，区块的协商需要经过三个阶段，包括：预准备阶段(也可以称为第一阶段)、准备阶段(也可以称为第二阶段)和确认阶段(也可以称为第三阶段)。每个阶段都具有相应的证书。主节点利用完整的区块信息生 成第一阶段证书，将第一阶段证书发送至多个备份节点。主节点进入第二阶段状态(即准备状态)。备份节点收到第一阶段证书时，即接收到区块完整的区块信息，同时该备份节点进入第二阶段状态。备份节点对第一阶段证书进行保存。由此使得每个备份节点中记录了新生成的区块对应的区块信息。备份节点根据完整的区块信息计算对应的区块哈希值，利用区块哈希值生成第二阶段证书。将第二阶段证书发送给其他节点(包括主节点和其他备份节点)。其他节点对第二阶段证书进行校验，校验通过之后，可以返回对第二阶段证书同意的信息。当第二阶段信息经过2f个节点的同意，即该备份节点接收到2f个节点返回的对第二阶段证书同意的信息时，该备份节点进入第三阶段。备份节点利用区块哈希值再生成第三阶段证书，将第三阶段证书发送至其他节点。当第三阶段证书得到了2f+1个节点(包括该备份节点本身)的同意，则新生成的区块在区块链系统中的协商工作得以完成。由于区块哈希值可以唯一标识一个区块，因此第二阶段证书和第三阶段证书能够准确反映出被协商的区块。
当区块的验证工作和协商工作都完成时，该区块在区块链系统中达成共识。在，主节点和备份节点将达成共识后的区块分别添加至本地联盟链的副本中。从而使得客户终端本次发起的交易能够安全有效的得以实现。
本实施例中，在协商过程中传输的第二阶段证书和第三阶段证书并不是完整的区块信息，而是可以唯一标识一个区块的区块哈希值。因此能够在区块共识过程中有效减少网络资源消耗，节省通信开销。从而实现了通过联盟链进行交易时有效减少网络资源消耗的问题。
在一个实施例中，该方法还包括：当主节点发生故障时，备份节点获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
本实施例中，当备份节点中的交易列表不为空时，若最优区块时间戳与当前时间间隔大于阈值，则确定主节点出现异常；或者当备份节点中的交易列表为空时，如果阈值时间内没有区块添加到本地联盟链副本中，则确定主 节点发生异常。
在确定主节点发生异常时，多个备份节点选举新的主节点，触发视图切换。多个备份节点可以根据备份节点加入到区块链系统中的时间；备份节点的性能指数；备份节点的响应次数进行选举，得到新的主节点。新的主节点和其他备份节点组成新的视图，从而完成视图切换。
由于在选举中考虑到了备份节点加入区块链系统的时间长短、备份节点的性能指数和响应次数等，由此能够确保选举得到的新的主节点的性能是众多从节点中性能最优的。从而能够使得切换后的视图更加稳健。
在一个实施例中，该方法还包括：备份节点获取本地联盟链中最优区块对应的时间戳；备份节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
本实施例中，备份节点可以根据本地联盟链副本中最优区块的时间戳进行证书清除。证书包括第一阶段证书、第二阶段证书和第三阶段证书。联盟链是以链表的形式按照区块的生成时间相连而成，当一个区块添加到联盟链中，则说明在该区块的时间戳之前的证书都已经被校验过，即备份节点中这些证书相关的状态已经广播完毕，并可以进行清除，而证书的信息可以通过区块的形式永远保存在该节点中。因此，备份节点可以对本地的添加区块事件进行监听，每当有区块添加到联盟链的副本中时，将该区块时间戳之前存储在该节点本地的证书进行清除。整个过程不需要节点间相互通信，同时也可以保证证书及时的清理，有效节省了网络资源的消耗。
在一个实施例中，提供了一种计算机设备，如区块链系统中的主节点或备份节点等，其中主节点或备份节点可以是台式电脑、笔记本电脑或服务器等。如图6所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该计算机设备的非易失 性存储介质存储有操作系统和计算机可读指令。该计算机设备的内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机可读指令被处理器执行时以实现一种基于以太坊区块链的交易数据处理方法。本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机设备，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
主节点接收客户终端发送的交易请求，根据交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
主节点利用交易数据生成区块，对区块的交易数据进行验证；区块具有对应的区块信息；
主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点，以使得备份节点根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收备份节点分别利用第二阶段证书和第三阶段证书对区块进行协商所得到的协商结果；及
当区块验证通过且协商结果为协商成功时，主节点将区块添加至本地联盟链的副本中。
在一个实施例中，计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
主节点获取本地联盟链中最优区块对应的时间戳；
主节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；及
若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书 的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
在一个实施例中，计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
当主节点本地联盟链副本中的区块数量少于第一备份节点中的区块数量时，向其他备份节点发送需要添加的区块对应的区块哈希值的获取请求；
接收其他备份节点返回的区块哈希值，若接收到的多个区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据区块哈希值在本地获取第一阶段证书；及
通过第一阶段证书将对应区块添加至本地联盟链副本中。
在一个实施例中，提供了一种计算机设备，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
备份节点接收主节点广播的区块，区块是主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用交易数据生成的；区块具有对应的区块信息；
备份节点对接收到的区块的交易数据进行验证；
备份节点接收主节点利用完整的区块信息生成的第一阶段证书，根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果；及
当区块验证通过且协商结果为协商成功时，备份节点将区块添加至本地联盟链的副本中。
在一个实施例中，计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
当主节点发生故障时，备份节点获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及
根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
在一个实施例中，计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
备份节点获取本地联盟链中最优区块对应的时间戳；
备份节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；及
若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
在一个实施例中，提供了一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
主节点接收客户终端发送的交易请求，根据交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
主节点利用交易数据生成区块，对区块的交易数据进行验证；区块具有对应的区块信息；
主节点利用完整的区块信息生成第一阶段证书，将第一阶段证书发送至多个备份节点，以使得备份节点根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收备份节点分别利用第二阶段证书和第三阶段证书对区块进行协商所得到的协商结果；及
当区块验证通过且协商结果为协商成功时，主节点将区块添加至本地联盟链的副本中。
在一个实施例中，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器还执行以下步骤：
主节点获取本地联盟链中最优区块对应的时间戳；
主节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；及
若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书 的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
在一个实施例中，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器还执行以下步骤：
当主节点本地联盟链副本中的区块数量少于第一备份节点中的区块数量时，向其他备份节点发送需要添加的区块对应的区块哈希值的获取请求；
接收其他备份节点返回的区块哈希值，若接收到的多个区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据区块哈希值在本地获取第一阶段证书；及
通过第一阶段证书将对应区块添加至本地联盟链副本中。
在一个实施例中，提供了一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
备份节点接收主节点广播的区块，区块是主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用交易数据生成的；区块具有对应的区块信息；
备份节点对接收到的区块的交易数据进行验证；
备份节点接收主节点利用完整的区块信息生成的第一阶段证书，根据第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用第二阶段证书和第三阶段证书对区块进行协商，得到协商结果；及
当区块验证通过且协商结果为协商成功时，备份节点将区块添加至本地联盟链的副本中。
在一个实施例中，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器还执行以下步骤：
当主节点发生故障时，备份节点获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及
根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
在一个实施例中，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器还执行以下步骤：
备份节点获取本地联盟链中最优区块对应的时间戳；
备份节点获取第一阶段证书、第二阶段证书和第三阶段证书的生成时间；及
若第一阶段证书的生成时间或第二阶段证书的生成时间或第三阶段证书的生成时间早于最优区块对应的时间戳，则清除第一阶段证书或第二阶段证书或第三阶段证书。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，所述的计算机可读指令可存储于一个或多个非易失性计算机可读取存储介质中，该计算机可读指令在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种基于以太坊的区块链系统，包括主节点和多个备份节点，其中：
    所述主节点，用于接收客户终端发送的交易请求，根据所述交易请求调用联盟链中部署的智能合约进行交易处理，得到交易数据；利用交易数据生成区块，将所述区块向多个备份节点进行广播；所述区块具有对应的区块信息；
    所述备份节点，用于接收所述区块，对所述区块的交易数据进行验证；
    所述主节点还用于利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点；所述备份节点还用于根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述主节点和多个备份节点分别将所述区块分别添加至本地联盟链的副本中。
  2. 根据权利要求1所述的系统，其特征在于，所述主节点和多个备份节点组成相应的视图；当所述主节点发生故障时，所述备份节点还用于获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
  3. 根据权利要求1所述的系统，其特征在于，所述主节点以及所述备份节点还用于获取本地联盟链中最优区块对应的时间戳，获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一阶段证书或所述第二阶段证书或所述第三阶段证书。
  4. 根据权利要求1所述的系统，其特征在于，所述备份节点包括第一备份节点和第二备份节点，当所述第一备份节点本地联盟链副本的区块数量少于所述第二备份节点本地联盟链副本的区块数量时，所述第一备份节点向其 他备份节点请求本地联盟链副本中需要添加的区块对应的区块哈希值，若接收到的区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据所述区块哈希值在本地获取第一阶段证书，及通过所述第一阶段证书将对应区块添加至本地联盟链副本中。
  5. 根据权利要求1所述的系统，其特征在于，所述主节点和多个备份节点组成相应的视图；当所述主节点发生故障时，多个备份节点还用于获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及根据所述加入区块链的时间、所述性能指数和所述响应次数中选举新的主节点。
  6. 一种基于以太坊区块链的交易数据处理方法，包括：
    主节点接收客户终端发送的交易请求，根据所述交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
    所述主节点利用交易数据生成区块，对所述区块的交易数据进行验证；所述区块具有对应的区块信息；
    所述主节点利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点，以使得所述备份节点根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收所述备份节点分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商所得到的协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述主节点将所述区块添加至本地联盟链的副本中。
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    所述主节点获取本地联盟链中最优区块对应的时间戳；
    所述主节点获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及
    若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一 阶段证书或所述第二阶段证书或所述第三阶段证书。
  8. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    当所述主节点本地联盟链副本中的区块数量少于第一备份节点中的区块数量时，向其他备份节点发送需要添加的区块对应的区块哈希值的获取请求；
    接收其他备份节点返回的区块哈希值，若接收到的多个区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据所述区块哈希值在本地获取第一阶段证书；及
    通过所述第一阶段证书将对应区块添加至本地联盟链副本中。
  9. 一种基于以太坊区块链的交易数据处理方法，包括：
    备份节点接收主节点广播的区块，所述区块是所述主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用所述交易数据生成的；所述区块具有对应的区块信息；
    所述备份节点接收所述区块，对所述区块的交易数据进行验证；
    所述备份节点接收所述主节点利用完整的区块信息生成的第一阶段证书，根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述备份节点将所述区块添加至本地联盟链的副本中。
  10. 根据权利要求9所述的方法，其特征在于，所述方法还包括：
    当所述主节点发生故障时，所述备份节点获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及
    根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
  11. 根据权利要求9所述的方法，其特征在于，所述方法还包括：
    所述备份节点获取本地联盟链中最优区块对应的时间戳；
    所述备份节点获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及
    若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一阶段证书或所述第二阶段证书或所述第三阶段证书。
  12. 一种计算机设备，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    主节点接收客户终端发送的交易请求，根据所述交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
    所述主节点利用交易数据生成区块，对所述区块的交易数据进行验证；所述区块具有对应的区块信息；
    所述主节点利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点，以使得所述备份节点根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收所述备份节点分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商所得到的协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述主节点将所述区块添加至本地联盟链的副本中。
  13. 根据权利要求11所述的计算机设备，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
    所述主节点获取本地联盟链中最优区块对应的时间戳；
    所述主节点获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及
    若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一阶段证书或所述第二阶段证书或所述第三阶段证书。
  14. 根据权利要求11所述的计算机设备，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
    当所述主节点本地联盟链副本中的区块数量少于第一备份节点中的区块数量时，向其他备份节点发送需要添加的区块对应的区块哈希值的获取请求；
    接收其他备份节点返回的区块哈希值，若接收到的多个区块哈希值中存在相同的哈希值且相同的数量超过阈值，则根据所述区块哈希值在本地获取第一阶段证书；及
    通过所述第一阶段证书将对应区块添加至本地联盟链副本中。
  15. 一种计算机设备，包括存储器和一个或多个处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器执行以下步骤：
    备份节点接收主节点广播的区块，所述区块是所述主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用所述交易数据生成的；所述区块具有对应的区块信息；
    所述备份节点接收所述区块，对所述区块的交易数据进行验证；
    所述备份节点接收所述主节点利用完整的区块信息生成的第一阶段证书，根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述备份节点将所述区块添加至本地联盟链的副本中。
  16. 根据权利要求15所述的计算机设备，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
    当所述主节点发生故障时，所述备份节点获取所属视图中的所有备份节点对应的加入区块链的时间、性能指数和响应次数；及
    根据加入区块链的时间、性能指数和响应次数中选举新的主节点。
  17. 根据权利要求15所述的计算机设备，其特征在于，所述计算机可读指令被所述处理器执行时，使得所述一个或多个处理器还执行以下步骤：
    所述备份节点获取本地联盟链中最优区块对应的时间戳；
    所述备份节点获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及
    若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一阶段证书或所述第二阶段证书或所述第三阶段证书。
  18. 一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
    主节点接收客户终端发送的交易请求，根据所述交易请求调用本地联盟链副本中部署的智能合约进行交易处理，得到交易数据；
    所述主节点利用交易数据生成区块，对所述区块的交易数据进行验证；所述区块具有对应的区块信息；
    所述主节点利用完整的区块信息生成第一阶段证书，将所述第一阶段证书发送至多个备份节点，以使得所述备份节点根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，接收所述备份节点分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商所得到的协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述主节点将所述区块添加至本地联盟链的副本中。
  19. 根据权利要求18所述的存储介质，其特征在于，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器还执行以下步骤：
    所述主节点获取本地联盟链中最优区块对应的时间戳；
    所述主节点获取所述第一阶段证书、所述第二阶段证书和所述第三阶段证书的生成时间；及
    若所述第一阶段证书的生成时间或所述第二阶段证书的生成时间或所述第三阶段证书的生成时间早于所述最优区块对应的时间戳，则清除所述第一阶段证书或所述第二阶段证书或所述第三阶段证书。
  20. 一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
    备份节点接收主节点广播的区块，所述区块是所述主节点在接收到客户终端发送的交易请求时调用联盟链中部署的智能合约进行交易得到交易数据，并利用所述交易数据生成的；所述区块具有对应的区块信息；
    所述备份节点接收所述区块，对所述区块的交易数据进行验证；
    所述备份节点接收所述主节点利用完整的区块信息生成的第一阶段证书，根据所述第一阶段证书中的区块哈希值分别生成第二阶段证书和第三阶段证书，分别利用所述第二阶段证书和第三阶段证书对所述区块进行协商，得到协商结果；及
    当所述区块验证通过且所述协商结果为协商成功时，所述备份节点将所述区块添加至本地联盟链的副本中。
PCT/CN2017/112664 2017-10-26 2017-11-23 基于以太坊的区块链系统和交易数据处理方法 WO2019080235A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG11201809101WA SG11201809101WA (en) 2017-10-26 2017-11-23 Blockchain system and blockchain transaction data processing method based on ethereum
US16/097,876 US11294888B2 (en) 2017-10-26 2017-11-23 Blockchain system and blockchain transaction data processing method based on ethereum

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201711017023.3A CN107819749A (zh) 2017-10-26 2017-10-26 基于以太坊的区块链系统和交易数据处理方法
CN201711017023.3 2017-10-26

Publications (1)

Publication Number Publication Date
WO2019080235A1 true WO2019080235A1 (zh) 2019-05-02

Family

ID=61603151

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/112664 WO2019080235A1 (zh) 2017-10-26 2017-11-23 基于以太坊的区块链系统和交易数据处理方法

Country Status (4)

Country Link
US (1) US11294888B2 (zh)
CN (1) CN107819749A (zh)
SG (1) SG11201809101WA (zh)
WO (1) WO2019080235A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111190862A (zh) * 2019-12-28 2020-05-22 广州创想云科技有限公司 区块链的实现方法
CN111339110A (zh) * 2020-02-25 2020-06-26 中国工商银行股份有限公司 基于区块链的交易备份方法及系统
US10700876B1 (en) * 2019-03-04 2020-06-30 Alibaba Group Holding Limited Methods and devices for processing certificates in blockchain system
US10922195B2 (en) 2019-03-18 2021-02-16 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US10938750B2 (en) 2019-03-18 2021-03-02 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US10977135B2 (en) 2019-03-18 2021-04-13 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
CN112839041A (zh) * 2021-01-05 2021-05-25 国网浙江省电力有限公司嘉兴供电公司 基于区块链的电网身份认证方法、装置、介质和设备
CN112995278A (zh) * 2021-02-02 2021-06-18 曲阜师范大学 一种基于云计算平台的区块链装置管理方法及sdn控制器
CN113556234A (zh) * 2021-07-21 2021-10-26 永旗(北京)科技有限公司 一种区块链跨链通信方法及系统
CN113660318A (zh) * 2021-07-30 2021-11-16 太原理工大学 一种基于区块链的学历、学位认证方法
CN114401150A (zh) * 2019-09-05 2022-04-26 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
CN114915377A (zh) * 2022-05-12 2022-08-16 中国人民解放军国防科技大学 一种基于喷泉码的联盟链存储系统

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108615148B (zh) * 2018-03-26 2019-03-15 北交金科金融信息服务有限公司 一种基于区块链技术的担保资产前置交易方法及系统
CN108537666A (zh) * 2018-04-09 2018-09-14 深圳市云蚂蚁科技有限责任公司 一种区块链系统以及区块链网络交易方法
CN108521426B (zh) * 2018-04-13 2020-09-01 中国石油大学(华东) 一种基于区块链的阵列蜜罐协同控制方法
WO2019200461A1 (en) * 2018-04-21 2019-10-24 Interbit Ltd. Method and system for performing an action requested by a blockchain
CN110417833B (zh) * 2018-04-27 2022-05-20 百度在线网络技术（北京）有限公司 基于区块链的数据处理方法、装置及存储介质
CN110489485B (zh) * 2018-04-28 2023-05-30 腾讯科技（深圳）有限公司 联盟区块链网络及在其中存储产品数据的方法和存储介质
CN108701271A (zh) * 2018-05-30 2018-10-23 深圳市元征科技股份有限公司 一种维修设备的管理方法、系统及数据管理服务器
CN108810120B (zh) * 2018-05-31 2021-01-26 中国联合网络通信集团有限公司 区块链节点通信方法、装置及区块链节点
EP3804279A4 (en) * 2018-06-01 2022-01-19 Nokia Technologies OY METHOD AND DEVICE FOR DISTRIBUTED TRUST ASSESSMENT IN A DISTRIBUTED NETWORK
CN108776890A (zh) * 2018-06-04 2018-11-09 青岛大学 一种基于区块链的可信智能工资发放方法和系统
CN110276693B (zh) * 2018-06-07 2021-05-07 腾讯科技（深圳）有限公司 保险理赔方法及系统
CN108768618B (zh) * 2018-06-07 2021-05-11 广东工业大学 一种基于区块链的ip软核授权方法、装置及介质
CN109067539B (zh) * 2018-06-13 2021-09-28 深圳前海微众银行股份有限公司 联盟链交易方法、设备及计算机可读存储介质
CN110620801A (zh) * 2018-06-20 2019-12-27 鸿富锦精密工业(武汉)有限公司 基于区块链的合约确认方法及会议系统
CN108990002A (zh) * 2018-06-27 2018-12-11 柳州市蓝海数链科技有限公司 一种区块链数据处理方法、装置、终端及存储介质
JP7056430B2 (ja) * 2018-07-18 2022-04-19 株式会社デンソー 履歴管理方法、履歴管理装置及び履歴管理システム
CN110784331B (zh) * 2018-07-30 2022-05-13 华为技术有限公司 一种共识流程恢复方法及相关节点
CN110782343B (zh) * 2018-07-30 2022-12-16 中移(苏州)软件技术有限公司 分布式网络中基于区块链的算力流通方法及系统
CN109189853B (zh) * 2018-08-08 2021-05-28 众安信息技术服务有限公司 一种区块链之间数据同步方法与装置
CN110611701B (zh) * 2018-08-21 2022-10-11 汇链丰(北京)科技有限公司 一种基于区块链的参数配置和交易处理方法
CN109462574B (zh) * 2018-09-26 2021-02-02 广州鲁邦通物联网科技有限公司 一种基于区块链的广告牌控制网关
CN108965342B (zh) * 2018-09-28 2021-05-28 真相网络科技（北京）有限公司 数据请求方访问数据源的鉴权方法及系统
CN110968879A (zh) * 2018-09-30 2020-04-07 中思博安科技（北京）有限公司 基于区块链的数据处理方法及装置
CN109299336B (zh) * 2018-09-30 2022-07-01 腾讯科技（深圳）有限公司 数据备份方法、装置、存储介质及计算设备
CN109508991A (zh) * 2018-10-16 2019-03-22 深圳市圆世科技有限责任公司 一种基于区块链的边缘协作方法
CN109670950B (zh) * 2018-10-29 2023-09-15 平安科技（深圳）有限公司 基于区块链的交易监听方法、装置、设备和存储介质
CN109508973A (zh) * 2018-11-09 2019-03-22 京东方科技集团股份有限公司 基于区块链的价格管理方法、装置和区块链系统
EP3566392B1 (en) * 2018-12-13 2021-08-25 Advanced New Technologies Co., Ltd. Achieving consensus among network nodes in a distributed system
CN109618007A (zh) * 2019-01-28 2019-04-12 北京融链科技有限公司 基于区块链的氢能行业数据管理系统及方法、存储介质
SG11201908853YA (en) 2019-03-18 2019-10-30 Alibaba Group Holding Ltd System and method for ending view change protocol
CA3057395A1 (en) 2019-03-18 2019-05-31 Alibaba Group Holding Limited System and method for ending view change protocol
CN110086780B (zh) * 2019-03-26 2021-11-02 北京百度网讯科技有限公司 基于以太坊的被篡改交易的处理方法、装置及存储介质
CN110018676B (zh) * 2019-04-30 2021-03-23 江苏领焰智能科技股份有限公司 分布式组网的声光视械控制系统
US11444776B2 (en) * 2019-05-01 2022-09-13 Kelce S. Wilson Blockchain with daisy chained records, document corral, quarantine, message timestamping, and self-addressing
CN110263544B (zh) * 2019-05-20 2021-04-27 创新先进技术有限公司 结合交易类型和判断条件的收据存储方法和节点
CN110245947B (zh) * 2019-05-20 2021-08-24 创新先进技术有限公司 结合交易与用户类型的条件限制的收据存储方法和节点
US10764062B2 (en) 2019-06-03 2020-09-01 Alibaba Group Holding Limited Blockchain ledger compression
CN110362568B (zh) * 2019-06-03 2020-07-24 阿里巴巴集团控股有限公司 一种针对块链式账本的压缩方法、装置及设备
CN112153085B (zh) * 2019-06-26 2022-05-17 华为技术有限公司 一种数据处理方法、节点及区块链系统
CN110351133B (zh) * 2019-06-28 2021-09-17 创新先进技术有限公司 用于区块链系统中的主节点切换处理的方法及装置
US10944624B2 (en) 2019-06-28 2021-03-09 Advanced New Technologies Co., Ltd. Changing a master node in a blockchain system
CN110460536B (zh) * 2019-08-26 2022-11-29 中国工商银行股份有限公司 用于区块链的数据处理方法和装置、介质和电子设备
CN110554823B (zh) * 2019-09-10 2021-04-20 腾讯科技（深圳）有限公司 一种图像处理方法、装置、设备及存储介质
CN110852734B (zh) * 2019-11-06 2021-07-02 上海景域文化传播股份有限公司 基于区块链的景区业务结算方法、系统及电子设备
CN110990497A (zh) * 2019-12-19 2020-04-10 上海优扬新媒信息技术有限公司 一种基于区块链的信息处理方法及装置、设备、存储介质
CN111191294B (zh) * 2019-12-27 2022-05-24 诚镌科技(广州)有限公司 基于区块链的单节点记账方法、系统、设备和存储介质
US11381401B2 (en) * 2020-01-07 2022-07-05 Seagate Technology Llc Blockchain transaction forwarding
CN113592638A (zh) * 2020-04-30 2021-11-02 顺丰科技有限公司 交易请求的处理方法、装置以及联盟链
CN113709197B (zh) * 2020-05-21 2024-02-23 顺丰科技有限公司 联盟区块链组织系统、区块链系统
CN111783133B (zh) * 2020-06-02 2023-06-30 广东科学技术职业学院 一种基于区块链技术的网络资源管理方法
CN111901293B (zh) * 2020-06-08 2021-08-27 北京邮电大学 面向联盟链的资源恶意竞争避免方法
CN111711526B (zh) * 2020-06-16 2024-03-26 深圳前海微众银行股份有限公司 一种区块链节点的共识方法及系统
CN111522822A (zh) * 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备
CN112039987B (zh) * 2020-08-28 2022-05-20 平安科技（深圳）有限公司 区块链中区块的处理方法、装置、节点设备及存储介质
US20220109577A1 (en) * 2020-10-05 2022-04-07 Thales DIS CPL USA, Inc Method for verifying the state of a distributed ledger and distributed ledger
CN112511338A (zh) * 2020-11-09 2021-03-16 迅鳐成都科技有限公司 区块链共识网络动态恢复方法、电子设备、系统及介质
CN112529508A (zh) * 2020-12-23 2021-03-19 杭州电子科技大学 一种基于pbft联盟链的电力物资管理系统
CN112950204A (zh) * 2021-02-25 2021-06-11 北京邮电大学 频谱资源认证与交易方法、系统和电子设备
CN113364871B (zh) * 2021-06-07 2022-05-17 杭州溪塔科技有限公司 一种基于智能合约的节点选举方法、装置及电子设备
WO2023043762A2 (en) * 2021-09-17 2023-03-23 The Regents Of The University Of California Collaborative transaction notarization in a byzantine computing environment
WO2023050012A1 (en) * 2021-09-30 2023-04-06 Ureeqa Inc. Groups a and b: system and method for decentralized timestamping of a submission of content onto a blockchain group c: method for timestamping verification of a submission of content onto a blockchain
CN115174090B (zh) * 2022-05-20 2023-04-25 清华大学 区块链共识方法、装置、计算机设备及可读存储介质
CN115150132B (zh) * 2022-06-13 2024-04-30 桂林电子科技大学 一种基于以太坊gas的联盟链抗DDOS攻击方法
CN115203330B (zh) * 2022-07-21 2024-01-19 深圳前海环融联易信息科技服务有限公司 智能合约部署方法及其装置、设备、介质、产品

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106447311A (zh) * 2016-09-26 2017-02-22 北京天德科技有限公司 一种四次通信的拜占庭容错算法的区块链建块方法
CN106789908A (zh) * 2016-11-23 2017-05-31 江苏通付盾科技有限公司 区块链中区块共识建立方法及系统
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
US20170193464A1 (en) * 2015-12-18 2017-07-06 Justin SHER Protocol utilizing bitcoin blockchain for maintaining independently proposed and approved set contents
CN107146087A (zh) * 2017-04-11 2017-09-08 广东网金控股股份有限公司 一种基于区块链联盟链的快速共识记账方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5214702A (en) * 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US7797457B2 (en) * 2006-03-10 2010-09-14 Microsoft Corporation Leaderless byzantine consensus
CN106445711B (zh) * 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170193464A1 (en) * 2015-12-18 2017-07-06 Justin SHER Protocol utilizing bitcoin blockchain for maintaining independently proposed and approved set contents
CN106447311A (zh) * 2016-09-26 2017-02-22 北京天德科技有限公司 一种四次通信的拜占庭容错算法的区块链建块方法
CN106789908A (zh) * 2016-11-23 2017-05-31 江苏通付盾科技有限公司 区块链中区块共识建立方法及系统
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
CN107146087A (zh) * 2017-04-11 2017-09-08 广东网金控股股份有限公司 一种基于区块链联盟链的快速共识记账方法及系统

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10700876B1 (en) * 2019-03-04 2020-06-30 Alibaba Group Holding Limited Methods and devices for processing certificates in blockchain system
US10833875B2 (en) 2019-03-04 2020-11-10 Advanced New Technologies Co., Ltd. Methods and devices for processing certificates in blockchain system
AU2019203851B2 (en) * 2019-03-04 2021-04-08 Advanced New Technologies Co., Ltd. Methods and devices for processing certificates in blockchain system
US10977135B2 (en) 2019-03-18 2021-04-13 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US11347598B2 (en) 2019-03-18 2022-05-31 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US10922195B2 (en) 2019-03-18 2021-02-16 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
US10938750B2 (en) 2019-03-18 2021-03-02 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
CN114401150A (zh) * 2019-09-05 2022-04-26 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
CN114401150B (zh) * 2019-09-05 2023-10-20 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
CN111190862A (zh) * 2019-12-28 2020-05-22 广州创想云科技有限公司 区块链的实现方法
CN111190862B (zh) * 2019-12-28 2023-06-30 广州创想云科技有限公司 区块链的实现方法
CN111339110B (zh) * 2020-02-25 2023-04-07 中国工商银行股份有限公司 基于区块链的交易备份方法及系统
CN111339110A (zh) * 2020-02-25 2020-06-26 中国工商银行股份有限公司 基于区块链的交易备份方法及系统
CN112839041A (zh) * 2021-01-05 2021-05-25 国网浙江省电力有限公司嘉兴供电公司 基于区块链的电网身份认证方法、装置、介质和设备
CN112839041B (zh) * 2021-01-05 2022-09-23 国网浙江省电力有限公司嘉兴供电公司 基于区块链的电网身份认证方法、装置、介质和设备
CN112995278A (zh) * 2021-02-02 2021-06-18 曲阜师范大学 一种基于云计算平台的区块链装置管理方法及sdn控制器
CN112995278B (zh) * 2021-02-02 2022-07-01 武汉温茂科技有限公司 一种基于云计算平台的区块链装置管理方法及sdn控制器
CN113556234A (zh) * 2021-07-21 2021-10-26 永旗(北京)科技有限公司 一种区块链跨链通信方法及系统
CN113660318A (zh) * 2021-07-30 2021-11-16 太原理工大学 一种基于区块链的学历、学位认证方法
CN114915377A (zh) * 2022-05-12 2022-08-16 中国人民解放军国防科技大学 一种基于喷泉码的联盟链存储系统
CN114915377B (zh) * 2022-05-12 2024-04-02 中国人民解放军国防科技大学 一种基于喷泉码的联盟链存储系统

Also Published As

Publication number Publication date
CN107819749A (zh) 2018-03-20
US11294888B2 (en) 2022-04-05
US20210256007A1 (en) 2021-08-19
SG11201809101WA (en) 2019-05-30

Similar Documents

Publication Publication Date Title
WO2019080235A1 (zh) 基于以太坊的区块链系统和交易数据处理方法
WO2020258831A1 (zh) 用于区块链系统中的主节点切换处理的方法及装置
Wang et al. Chainsplitter: Towards blockchain-based industrial iot architecture for supporting hierarchical storage
TWI705690B (zh) 分布式網路中進行主節點變更的系統
US20200143366A1 (en) Methods for decentralized digital asset transfer and smart contract state transition
TWI709063B (zh) 用於結束視域變換協定的系統和方法
WO2019119929A1 (zh) 区块链共识方法、装置和系统、标识信息处理方法和装置
US11128522B2 (en) Changing a master node in a blockchain system
JP4896438B2 (ja) 分散障害許容型コンピューティングシステムにおける効率のよいレプリカセットの変更
TWI717135B (zh) 用於結束視域變換協定的系統和方法
Nelson et al. Extending existing blockchains with virtualchain
WO2021135857A1 (zh) 对信任节点信息进行更新的方法及装置
WO2021184878A1 (zh) 用于区块链系统的节点管理的方法、节点和计算设备
CN113612614B (zh) 基于区块链网络的共识容灾方法、装置、设备和存储介质
WO2021000802A1 (zh) 一种通信方法、节点以及通信系统
JP2022523217A (ja) 投票集計を伴うトポロジードリブンビザンチンフォールトトレラント合意プロトコル
CN111211876B (zh) 发送针对数据请求的应答消息的方法及装置、区块链系统
WO2024092936A1 (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
Yu et al. GPBFT: A Practical Byzantine Fault‐Tolerant Consensus Algorithm Based on Dual Administrator Short Group Signatures
CN116846888A (zh) 区块链网络的共识处理方法、装置、设备及存储介质
CN113111074A (zh) 基于区块链的交互数据监测方法及装置
WO2024066974A1 (zh) 基于区块链的数据处理方法、设备以及可读存储介质
WO2023221772A1 (zh) 基于区块链网络的数据处理方法及相关产品
Li et al. A Secure and Efficient Cross-Chain Model Based on Credentials
CN116881045A (zh) 区块链数据恢复方法、装置及系统

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: 17929936

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24/09/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17929936

Country of ref document: EP

Kind code of ref document: A1