WO2021244568A1 - Procédé de consensus dans une chaîne de blocs, et système - Google Patents

Procédé de consensus dans une chaîne de blocs, et système Download PDF

Info

Publication number
WO2021244568A1
WO2021244568A1 PCT/CN2021/097897 CN2021097897W WO2021244568A1 WO 2021244568 A1 WO2021244568 A1 WO 2021244568A1 CN 2021097897 W CN2021097897 W CN 2021097897W WO 2021244568 A1 WO2021244568 A1 WO 2021244568A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
data
node
target proposal
target
Prior art date
Application number
PCT/CN2021/097897
Other languages
English (en)
Chinese (zh)
Inventor
李帅
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021244568A1 publication Critical patent/WO2021244568A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Definitions

  • This document relates to the field of computer technology, in particular to a consensus method and system in the blockchain.
  • the nodes in the blockchain generally communicate with each other in a P2P direct connection.
  • this direct communication method will make the entire blockchain network have a relatively large demand for delay and bandwidth.
  • the embodiments of this specification provide a consensus method and system in the blockchain to solve the problem of communication between nodes in the existing blockchain through P2P direct connection, so that the entire blockchain network has a problem of delay and bandwidth.
  • the demand is larger.
  • a consensus method in the blockchain including: the consensus master node initiates a target proposal for the consensus data in the blockchain,
  • the target proposal includes the root hash composed of the data to be agreed;
  • the consensus master node calls the broadcast network client of the node to broadcast the data to be agreed to the consensus backup node in the blockchain; receives the The consensus backup node proposed by the target determines whether the broadcast network client of this node has data matching the root hash in the target proposal; if the consensus backup node proposed by the target is received, if the broadcast network of this node is determined If the client has data that matches the root hash of the target proposal, then a consensus operation is performed on the target proposal.
  • a blockchain system including: a consensus master node, which initiates a target proposal for the data to be consensus in the blockchain, and the target proposal contains the root hash composed of the data to be consensus; and calls The broadcast network client of this node broadcasts the to-be-consensus data to the consensus backup node in the blockchain; the consensus backup node that receives the target proposal, determines whether the broadcast network client of this node is consistent with the target proposal If it is determined that the broadcast network client of this node has data that matches the root hash in the target proposal, then perform a consensus operation on the target proposal.
  • the consensus master node initiates a target proposal for the data to be consensus in the blockchain, and calls the broadcast network of this node
  • the client broadcasts the data to be consensus to the consensus backup node in the blockchain.
  • the target proposal contains the root hash composed of the data to be consensus; the consensus backup node proposed by the target is received, and it is determined whether the broadcast network client of this node exists and The data that matches the root hash in the target proposal, and if it is determined that the broadcast network client of this node has data that matches the root hash in the target proposal, then a consensus operation is performed on the target proposal.
  • the consensus master node initiates a consensus operation
  • what is transmitted to the consensus backup node is the root hash of the consensus data proposed by the target, not the original data of the consensus data, and the broadcast network client in the consensus master node
  • the terminal broadcasts the original data of the data to be consensus to the consensus backup node in the blockchain.
  • the root hash of the data to be consensus is directly transmitted between nodes, the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.
  • Figure 1 is a schematic diagram of the implementation process of a consensus method in a blockchain provided by an embodiment of this specification
  • FIG. 2 is a schematic diagram of the consensus method in the blockchain provided by an embodiment of the specification applied in an actual scenario
  • Fig. 3 is a schematic structural diagram of a blockchain system provided by an embodiment of this specification.
  • the embodiment of this specification proposes a consensus method in the blockchain.
  • the consensus master node initiates a target proposal for the consensus data in the blockchain and calls The broadcast network client of this node broadcasts the consensus data to the consensus backup node in the blockchain.
  • the target proposal contains the root hash composed of the consensus data; the consensus backup node proposed by the target is received, and the broadcast network of this node is determined Whether the client has data that matches the root hash of the target proposal, and if it is determined that the broadcast network client of this node has data that matches the root hash of the target proposal, then consensus operations are performed on the target proposal.
  • the consensus master node initiates a consensus operation
  • what is transmitted to the consensus backup node is the root hash of the consensus data proposed by the target, not the original data of the consensus data, and the consensus is waiting for the consensus through the broadcast network client in the consensus master node.
  • the original data of the data is broadcast to the consensus backup node in the blockchain.
  • the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.
  • the target proposal of the target proposal contains the root hash of the data to be agreed.
  • the consensus master node when the consensus master node initiates a target proposal for the consensus data in the blockchain, the consensus master node sends the root hash composed of the consensus data to the consensus backup node in the blockchain Since the root hash is usually a 32-byte data, this will greatly reduce the network bandwidth occupied by the direct data transmission between nodes, and at the same time reduce the data transmission delay.
  • the consensus master node in the embodiment of this specification can also initiate a target proposal for the data to be consensus Determine whether the collected transaction set meets the preset transaction collection conditions.
  • the consensus master node initiates a target proposal for the consensus data in the blockchain, including: the consensus master node obtains the consensus data, and based on the consensus data, generates a target proposal containing the root hash of the consensus data ; If the consensus master node determines that the consensus data meets the preset transaction collection conditions, based on the consensus data, it generates a target proposal containing the root hash composed of the consensus data.
  • the preset transaction collection conditions include at least one of the following: the number of transactions in the data to be agreed is greater than or equal to the preset number; the period for collecting transactions in the data to be agreed is greater than or equal to the specified collection period; the data to be agreed The size is greater than or equal to the specified capacity.
  • the data to be agreed may include one or more transaction sets, and one transaction set includes one or more transaction data, and the data to be agreed may also be empty.
  • the consensus master node obtains the data to be consensus, the consensus master node can obtain one or more transaction sets from the transaction pool, and package the target proposal based on the one or more transaction sets. Specifically, in order to reduce the amount of data transmission between nodes, the target proposal is packaged based on one or more transaction sets, and the packaged target proposal may only include the root hash composed of one or more transaction sets.
  • the consensus master node in the blockchain initiates a consensus algorithm corresponding to the target proposal for the data to be consensus, including at least one of the following: Practical Byzantine Fault Tolerance (PBFT) consensus algorithm; Hotstuff consensus algorithm; LibraBFT Consensus algorithm; Tendermint consensus algorithm.
  • PBFT Practical Byzantine Fault Tolerance
  • the consensus master node sends the PRE-PREPARE message proposed for the target and the signature of the PRE-PREPARE message to the consensus backup node in the blockchain.
  • the format of the PRE-PREPARE message is ⁇ PRE-PREPARE, v, n, d >, where v is the view number of the target proposal, d is the root hash formed by one or more transaction sets corresponding to the target proposal, and n is [h, H] within a certain range.
  • Step 120 The consensus master node calls the broadcast network client of the node to broadcast the data to be consensus to the consensus backup node in the blockchain.
  • the broadcast network client is additionally set in the node based on the defect of the P2P transmission method between nodes in the embodiment of this specification, and the broadcast network client is used to transmit the original data of the data to be consensus to other nodes in the blockchain .
  • the broadcast network client performs data transmission, it does not occupy the network transmission bandwidth between nodes, and specifically transmits data via the broadcast network in the blockchain.
  • the original data of the data to be agreed in the embodiment of this specification is the root of the target proposal.
  • the original data of one or more transaction sets in the corresponding data for consensus can be sent to the consensus backup in the blockchain by the broadcast network client in the consensus master node.
  • the broadcast network client of the node can call the broadcast network client of the node to broadcast the data to be consensus to the broadcast network client of the consensus backup node in the blockchain.
  • the embodiment of this specification may pre-deploy a broadcast network in the blockchain.
  • the broadcast network is used to transmit large-capacity data between nodes, and the broadcast network clients in each node
  • the terminal is used to send and receive data transmitted in the broadcast network.
  • the consensus master node calls the broadcast network client of this node to broadcast the consensus data to the consensus backup node in the blockchain, including: the consensus master node sends the consensus data to the broadcast network client of the node; consensus The broadcast network client of the master node broadcasts the consensus data to the consensus backup node in the blockchain via the broadcast network of the blockchain.
  • the method provided by one or more embodiments of this specification can greatly reduce the amount of data directly communicated between nodes, thereby reducing the amount of data between nodes. Network transmission bandwidth requirements.
  • Step 130 Receive the consensus backup node proposed by the target, and determine whether the broadcast network client of this node has data matching the root hash in the target proposal.
  • the consensus backup node that can receive the target proposal determines whether the broadcast network client of the node has data matching the root hash in the target proposal based on the view identifier in the target proposal.
  • the consensus backup node that receives the target proposal determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, including: the consensus backup node that receives the target proposal, corresponds to the target proposal
  • the target view of the target view is obtained from the broadcast network client of this node corresponding to the transaction data of the target view; the consensus backup node that receives the target proposal, based on the transaction data corresponding to the target view, determines whether the broadcast network client of this node exists Data that matches the root hash in the target proposal.
  • the consensus backup node that receives the target proposal, based on the transaction data corresponding to the target view, determines whether the broadcast network client of the node has data that matches the root hash in the target proposal.
  • the transaction data of the view obtains the root hash formed by the transaction data corresponding to the target view, and then it is determined whether the root hash formed by the transaction data corresponding to the target view is consistent with the root hash carried in the target proposal.
  • the root hash formed by the transaction data corresponding to the target view is consistent with the root hash carried in the target proposal, it indicates that the broadcast network client of this node has data that matches the root hash in the target proposal; and if The root hash formed by the transaction data corresponding to the target view is inconsistent with the root hash carried in the target proposal, indicating that the broadcast network client of this node does not have data that matches the root hash in the target proposal.
  • the consensus backup node that receives the target proposal determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, including: the broadcast network client that receives the consensus backup node proposed by the target The end receives the consensus data from the consensus master node via the broadcast network; the consensus backup node that receives the target proposal determines whether the consensus data received by the broadcast network client of this node matches the root hash of the target proposal.
  • the method further includes: receiving the consensus backup proposed by the target The node, if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, it will determine whether the broadcast network client of this node receives the target proposal for a preset period of time To the data that matches the root hash in the target proposal.
  • the preset time period is the upper limit of the preset timeout period.
  • the consensus backup node that receives the target proposal if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, it will usually wait for a timeout period. If the broadcast network client cannot find the data that matches the root hash of the target proposal, it can initiate a view switching operation, that is, start a consensus operation on the next proposal proposed by the target.
  • the method further includes: the consensus backup node that receives the target proposal, if after receiving the target proposal for a preset time period, it is determined that the broadcast network client of the node does not have data that matches the root hash of the target proposal, The view switching operation is initiated.
  • the consensus backup node After the consensus backup node receives the PRE-PREPARE message proposed for the target, it verifies the PRE-PREPARE message, mainly verifying the following: the consensus master node’s signature of the PRE-PREPARE message is correct, and the broadcast network client of its own node Whether there are one or more transaction sets that match d, whether n is in the interval [h, H], and whether the consensus backup node has received a PRE that is under the same v and numbered n but has a different signature -PREPARE information.
  • step 140 the consensus backup node proposed by the target is received, and if it is determined that the broadcast network client of the node has data matching the root hash in the target proposal, then a consensus operation is performed on the target proposal.
  • the method further includes: if the node in the blockchain receives A valid verification message from no less than 3f+1 nodes for the target proposal will generate a block recording the data to be consensus; where f is the maximum number of abnormal nodes allowed in the blockchain.
  • the consensus backup node After the consensus backup node passes the verification of the received PRE-PREPARE message, it sends a PRE-PREPARE message to other nodes in the blockchain, including the consensus master node, in the format of ⁇ PREPARE,v,n,d,i>message, v,n ,d,m have the same content as the above PRE-PREPARE message, i is the number of the current consensus backup node, and at the same time sign ⁇ PREPARE,v,n,d,i>; the consensus master node and other consensus backups in the blockchain
  • the node receives the PREPARE message it mainly performs the following checks: whether the signature of the PREPARE message is correct, whether the node receiving the PREPARE message has received the n under the same view, and whether n is in the interval [h, H] , And whether d is the same as d in the received PRE-PREPARE message.
  • the message is discarded; if the consensus master node and other consensus backup nodes in the blockchain receive PREPARE messages from no less than 3f+1 nodes, and the verification is passed, the message is sent to the blockchain
  • the other nodes in the node send the COMMIT message and the message signature in the format of ⁇ COMMIT,v,n,d,i>, where v,n,d,i are the same as the above PREPARE message content; the node in the blockchain receives the After the COMMIT message, verify the COMMIT message, mainly to verify the following items: whether the signature of the COMMIT message is correct, whether the n under the same view has been received, and whether there is a matching d in the transaction memory pool managed by it One or more transaction sets, whether n is in the interval [h, H].
  • the blockchain network includes a consensus master. Nodes and multiple consensus backup nodes.
  • the consensus backup node takes one of the consensus backup nodes as an example. It should be understood that in actual scenarios, the number of consensus backup nodes is usually multiple.
  • the implementation process of the consensus method in the blockchain includes:
  • the consensus master node After determining whether at least one transaction set collected by this node meets the preset transaction collection conditions, the consensus master node sends the at least one to the broadcast network client of the node when initiating a consensus proposal for the at least one transaction set.
  • the preset transaction collection conditions include, for example, whether the number of transactions in the at least one transaction set is greater than or equal to a preset number, whether the collection period of the at least one transaction set is greater than or equal to a specified collection period, and/or the at least one transaction Is the size of the collection greater than or equal to the specified capacity, etc.
  • the consensus master node sends a pre-prepare message to the consensus backup node.
  • the pre-prepare message contains the root hash of at least one transaction set and block metadata (used to indicate the view and area corresponding to the initiated consensus proposal). Block number).
  • S3 The broadcast network client in the consensus master node sends the at least one transaction set to the broadcast network, so that the broadcast network sends the at least one transaction set to the broadcast network client of the consensus backup node.
  • the broadcast network sends the at least one transaction set to the broadcast network client of the consensus backup node.
  • the consensus backup node obtains transaction data consistent with the block metadata in the pre-prepare message from the broadcast network client of the node, and determines whether the root hash corresponding to the obtained transaction data is the same as that in the pre-prepare message The root hashes are consistent. If they are consistent, continue the consensus operation on the consensus proposal, otherwise wait for the preset time period.
  • the consensus backup node If after the preset time period, the consensus backup node still does not find the transaction data matching the root hash in the pre-prepare message from the broadcast network client of the node, it will initiate a view switch operation to download the consensus proposal.
  • the consensus backup node finds the transaction set corresponding to the block number to be written in the target proposal and is not in the managed transaction memory pool within the specified time period, execute S7, and continue to execute the target proposal after passing the verification If the consensus backup node does not find the transaction set corresponding to the block number to be written in the target proposal and not in the managed transaction memory pool within the specified time period, the view switching operation will be performed.
  • the consensus master node initiates a target proposal for the data to be agreed in the blockchain, and calls the broadcast network client of this node to broadcast the data to be agreed to the consensus backup node in the blockchain ,
  • the target proposal contains the root hash of the consensus data;
  • the consensus backup node that receives the target proposal determines whether the broadcast network client of this node has data that matches the root hash in the target proposal, and if it is determined The broadcast network client of the node has data that matches the root hash in the target proposal, and then performs a consensus operation on the target proposal.
  • the consensus master node initiates a consensus operation
  • what is transmitted to the consensus backup node is the root hash of the consensus data proposed by the target, not the original data of the consensus data, and the broadcast network client in the consensus master node
  • the terminal broadcasts the original data of the data to be consensus to the consensus backup node in the blockchain.
  • the root hash of the data to be consensus is directly transmitted between nodes, the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.
  • FIG. 3 is a schematic structural diagram of a blockchain system 300 provided by an embodiment of this specification.
  • the blockchain system 300 may include a consensus master node 310 and a plurality of consensus backup nodes 320, among which: the consensus master node 310 initiates a transaction for the consensus data in the blockchain A target proposal, the target proposal contains the root hash composed of the data to be agreed; and the broadcast network client that calls the node broadcasts the data to be agreed to the consensus backup node in the blockchain; the target proposal is received
  • the consensus backup node 320 of this node determines whether the broadcast network client of this node has data that matches the root hash in the target proposal; and if it is determined that the broadcast network client of this node has the root hash in the target proposal For data matching the hash, a consensus operation is performed on the target proposal.
  • the consensus master node initiates a consensus operation
  • the root hash of the consensus data proposed by the target is transmitted to the consensus backup node, rather than the original data of the consensus data.
  • the original data of the data to be consensus is broadcast to the consensus backup node in the blockchain.
  • the transmission of root hash between nodes greatly saves the bandwidth occupied during data transmission compared with the original data; on the other hand, through the broadcast network Transmission of the original data of the data to be agreed also reduces the delay of data transmission.
  • the consensus backup node 320 that has received the target proposal is configured to: based on the target view corresponding to the target proposal, obtain from the broadcast network client of the node corresponding to the Transaction data of the target view; based on the transaction data corresponding to the target view, determine whether the broadcast network client of this node has data that matches the root hash in the target proposal.
  • the consensus master node 310 is configured to: obtain the data to be agreed, and based on the data to be agreed, generate a root hash that contains the data to be agreed The target proposal; if it is determined that the data to be agreed upon meets a preset transaction collection condition, based on the data to be agreed, the target proposal including the root hash formed by the data to be agreed is generated.
  • the consensus master node 310 is configured to: send the data to be agreed to the broadcast network client of the node; the broadcast network client of the consensus master node sends the The consensus data is broadcast to the consensus backup node in the blockchain via the broadcasting network of the blockchain.
  • the consensus backup node 320 receiving the target proposal performs a consensus operation on the target proposal
  • the consensus master node 310 or the consensus backup node 320 in the blockchain Receive valid verification messages from no less than 3f+1 nodes for the target proposal, then generate a block recording the data to be agreed; where f is the maximum number of abnormal nodes allowed in the blockchain .
  • the consensus backup node 320 to the target proposal is also used to: if it is determined that the broadcast network client of this node does not have data that matches the root hash in the target proposal, then the target proposal is received After a preset period of time, it is determined whether the broadcast network client of the node receives data that matches the root hash in the target proposal.
  • the consensus backup node 320 to the target proposal is also used to: if the target proposal is received for the preset time period, it is determined that the broadcast network client of this node does not have the root hash in the target proposal. If the matching data is matched, the view switching operation is initiated.
  • the consensus algorithm used by the consensus master node to initiate a target proposal for the consensus data in the blockchain includes at least one of the following: a practical Byzantine fault-tolerant PBFT consensus algorithm; a Hotstuff consensus algorithm; LibraBFT Consensus algorithm; Tendermint consensus algorithm.
  • the blockchain system 300 can implement the methods of the method embodiments shown in FIGS. 1 to 2. For details, please refer to the consensus method in the blockchain of the embodiment shown in FIGS. 1 to 2, which will not be repeated here.
  • a typical implementation device is a computer.
  • the computer may be, for example, a personal computer, a laptop computer, a cell phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Any combination of these devices.
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Sont divulgués dans la présente description un procédé de consensus dans une chaîne de blocs et un système, le procédé faisant appel aux étapes suivantes : dans une chaîne de blocs, un nœud principal de consensus initie une proposition cible par rapport à des données à soumettre à un consensus, la proposition cible comprenant un hachage racine formé à partir des données à soumettre à un consensus ; le nœud principal de consensus utilise une extrémité client de réseau de diffusion d'un nœud courant, et diffuse les données à soumettre à un consensus à un nœud de sauvegarde de consensus dans la chaîne de blocs ; le nœud de sauvegarde de consensus qui a reçu la proposition cible détermine, pour l'extrémité client de réseau de diffusion du nœud courant, si des données correspondant au hachage racine dans la proposition cible existent ; si le nœud de sauvegarde de consensus qui a reçu la proposition cible détermine, pour l'extrémité client de réseau de diffusion du nœud courant, que des données correspondant au hachage racine dans la proposition cible existent, la réalisation d'une opération consensus sur la proposition cible.
PCT/CN2021/097897 2020-06-05 2021-06-02 Procédé de consensus dans une chaîne de blocs, et système WO2021244568A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010506075.2A CN111600965B (zh) 2020-06-05 2020-06-05 区块链中的共识方法和系统
CN202010506075.2 2020-06-05

Publications (1)

Publication Number Publication Date
WO2021244568A1 true WO2021244568A1 (fr) 2021-12-09

Family

ID=72190106

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/097897 WO2021244568A1 (fr) 2020-06-05 2021-06-02 Procédé de consensus dans une chaîne de blocs, et système

Country Status (2)

Country Link
CN (1) CN111600965B (fr)
WO (1) WO2021244568A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114338673A (zh) * 2021-12-30 2022-04-12 马上消费金融股份有限公司 一种交易数据处理方法、装置、设备、系统及存储介质
CN114401271A (zh) * 2022-01-13 2022-04-26 中国人民解放军国防科技大学 一种试验数据防篡改方法、区块链系统及介质
CN114598475A (zh) * 2022-01-24 2022-06-07 浙江甲骨文超级码科技股份有限公司 基于fabric的拜占庭容错共识算法及系统

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111600965B (zh) * 2020-06-05 2023-10-27 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统
CN112801794B (zh) * 2021-02-08 2022-04-15 网易（杭州）网络有限公司 交易执行方法、装置、电子设备、存储介质
CN113365229B (zh) * 2021-05-28 2022-03-25 电子科技大学 一种多联盟链共识算法的网络时延优化方法
CN113254272B (zh) * 2021-06-09 2022-09-13 腾讯科技（深圳）有限公司 区块链网络的数据处理方法、装置、计算机设备和介质
CN113573255A (zh) * 2021-07-26 2021-10-29 上海点融信息科技有限责任公司 基于区块链进行共识的方法、装置及存储介质
CN113821569B (zh) * 2021-09-30 2024-02-06 广州智链未来科技有限公司 一种区块链的共识方法及区块链

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180253702A1 (en) * 2015-11-24 2018-09-06 Gartland & Mellina Group Blockchain solutions for financial services and other transactions-based industries
CN108550038A (zh) * 2018-04-18 2018-09-18 杭州秘猿科技有限公司 一种应用于区块链的数据传播系统及方法
CN109150598A (zh) * 2018-08-10 2019-01-04 上交所技术有限责任公司 一种基于块片的bft共识算法带宽使用率改进方法
CN109379397A (zh) * 2018-08-31 2019-02-22 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
US20200026699A1 (en) * 2018-07-20 2020-01-23 True Blockchain Technology Ltd. Highly Performant Decentralized Public Ledger with Hybrid Consensus
CN110798308A (zh) * 2019-10-31 2020-02-14 支付宝(杭州)信息技术有限公司 一种区块链的签名方法和系统
CN111600965A (zh) * 2020-06-05 2020-08-28 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656618B (zh) * 2009-09-11 2012-09-05 中兴通讯股份有限公司 一种基于结构化对等网络的多媒体消息广播方法及系统
WO2014168428A1 (fr) * 2013-04-11 2014-10-16 엘지전자 주식회사 Procédé pour fournir un itinéraire optimal intégrant une pluralité de lieux de passage et appareil correspondant
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
CN106878000B (zh) * 2017-03-06 2020-02-21 中钞信用卡产业发展有限公司杭州区块链技术研究院 一种联盟链共识方法及系统
CN107220130B (zh) * 2017-05-12 2021-12-07 北京众享比特科技有限公司 一种在区块链的节点处实现的信息共识方法、装置及系统
US10826987B2 (en) * 2018-04-06 2020-11-03 Datalogic Ip Tech S.R.L. Systems and methods for consensus-based data security for networked devices
KR102079786B1 (ko) * 2018-10-25 2020-02-21 주식회사 팀그릿 블록체인을 이용한 방송 판매 방법 및 그 시스템
CN109327548A (zh) * 2018-11-27 2019-02-12 北京瑞卓喜投科技发展有限公司 一种区块链更新方法及区块链更新系统
CN114401150B (zh) * 2019-09-05 2023-10-20 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
CN111212126B (zh) * 2019-12-27 2023-05-26 百度在线网络技术（北京）有限公司 一种区块链网络的数据传输方法、装置、设备和介质
GB2592980A (en) * 2020-03-13 2021-09-15 Nchain Holdings Ltd Blockchain transaction double spend proof

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180253702A1 (en) * 2015-11-24 2018-09-06 Gartland & Mellina Group Blockchain solutions for financial services and other transactions-based industries
CN108550038A (zh) * 2018-04-18 2018-09-18 杭州秘猿科技有限公司 一种应用于区块链的数据传播系统及方法
US20200026699A1 (en) * 2018-07-20 2020-01-23 True Blockchain Technology Ltd. Highly Performant Decentralized Public Ledger with Hybrid Consensus
CN109150598A (zh) * 2018-08-10 2019-01-04 上交所技术有限责任公司 一种基于块片的bft共识算法带宽使用率改进方法
CN109379397A (zh) * 2018-08-31 2019-02-22 阿里巴巴集团控股有限公司 基于区块链的交易共识处理方法及装置、电子设备
CN110798308A (zh) * 2019-10-31 2020-02-14 支付宝(杭州)信息技术有限公司 一种区块链的签名方法和系统
CN111600965A (zh) * 2020-06-05 2020-08-28 支付宝(杭州)信息技术有限公司 区块链中的共识方法和系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114338673A (zh) * 2021-12-30 2022-04-12 马上消费金融股份有限公司 一种交易数据处理方法、装置、设备、系统及存储介质
CN114401271A (zh) * 2022-01-13 2022-04-26 中国人民解放军国防科技大学 一种试验数据防篡改方法、区块链系统及介质
CN114598475A (zh) * 2022-01-24 2022-06-07 浙江甲骨文超级码科技股份有限公司 基于fabric的拜占庭容错共识算法及系统
CN114598475B (zh) * 2022-01-24 2022-11-01 浙江甲骨文超级码科技股份有限公司 基于fabric的拜占庭容错共识方法及系统

Also Published As

Publication number Publication date
CN111600965B (zh) 2023-10-27
CN111600965A (zh) 2020-08-28

Similar Documents

Publication Publication Date Title
WO2021244568A1 (fr) Procédé de consensus dans une chaîne de blocs, et système
CN109189751B (zh) 基于区块链的数据同步方法及终端设备
CN108648078B (zh) 一种交易预处理方法、装置及电子设备
TWI710979B (zh) 跨區塊鏈的互動方法及裝置、系統、電子設備
TWI690184B (zh) 跨區塊鏈的認證方法及裝置、電子設備
CN111539726B (zh) 区块链共识系统及方法
TWI727467B (zh) 聯盟鏈的可信度驗證方法、系統、裝置及設備
US11444783B2 (en) Methods and apparatuses for processing transactions based on blockchain integrated station
WO2021244581A1 (fr) Procédé de consensus dans une chaîne d'alliance et système de chaîne d'alliance
WO2023045620A1 (fr) Procédé et appareil de traitement de données de transaction, dispositif informatique et support de stockage
EP3933646B1 (fr) Méthodes et systèmes de consensus dans la blockchain de consortium
WO2019042101A1 (fr) Procédé et appareil de trading cross-chaînes
TWI724574B (zh) 基於區塊鏈的記帳方法及裝置、電子設備
WO2020063763A1 (fr) Procédé, appareil et système de stockage de données, et serveur, nœud de commande et support
US11783339B2 (en) Methods and apparatuses for transferring transaction based on blockchain integrated station
US20230025449A1 (en) Method and apparatus for dynamically adding consensus node in blockchain
US20210158351A1 (en) Methods, systems, apparatuses and devices for verifying credibility of consortium blockchain
CN110111095B (zh) 支付交易判重方法及支付系统
EP3933647A1 (fr) Méthodes et systèmes de consensus dans la blockchain de consortium
US20230098190A1 (en) Data processing method, apparatus, device and medium based on distributed storage
TWI716822B (zh) 事務因果序的校正方法及裝置、電子設備
EP3813335A1 (fr) Procédé et système de traitement de données basés sur un réseau de chaînes d'alliance
US11218402B2 (en) Blockchain systems, and message transmission methods and apparatuses
WO2023050986A1 (fr) Maintenance d'informations d'architecture de réseau de système de chaîne de blocs
WO2022151709A1 (fr) Procédé de traitement de partitionnement de contrat intelligent

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21817892

Country of ref document: EP

Kind code of ref document: A1