WO2018171545A1 - 一种发送交易信息和共识验证的方法及装置 - Google Patents

一种发送交易信息和共识验证的方法及装置 Download PDF

Info

Publication number
WO2018171545A1
WO2018171545A1 PCT/CN2018/079439 CN2018079439W WO2018171545A1 WO 2018171545 A1 WO2018171545 A1 WO 2018171545A1 CN 2018079439 W CN2018079439 W CN 2018079439W WO 2018171545 A1 WO2018171545 A1 WO 2018171545A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction information
consensus
transaction
node
information
Prior art date
Application number
PCT/CN2018/079439
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
Priority to KR1020197018216A priority Critical patent/KR102151899B1/ko
Priority to BR112019012905A priority patent/BR112019012905A2/pt
Priority to JP2019534718A priority patent/JP6794551B2/ja
Priority to CA3047884A priority patent/CA3047884C/en
Priority to EP18770722.9A priority patent/EP3543937A4/en
Priority to RU2019119564A priority patent/RU2735156C1/ru
Application filed by 阿里巴巴集团控股有限公司, 李宁 filed Critical 阿里巴巴集团控股有限公司
Priority to MX2019007557A priority patent/MX2019007557A/es
Priority to AU2018240159A priority patent/AU2018240159B2/en
Publication of WO2018171545A1 publication Critical patent/WO2018171545A1/zh
Priority to ZA2019/04053A priority patent/ZA201904053B/en
Priority to PH12019501470A priority patent/PH12019501470A1/en
Priority to US16/523,580 priority patent/US10679217B2/en

Links

Images

Classifications

    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]

Definitions

  • the present application relates to the field of blockchain technology, and in particular, to a method and apparatus for transmitting transaction information and consensus verification.
  • the blockchain node responsible for consensus verification of transactions is called a consensus node.
  • the consensus node that initiates the consensus verification needs to package the transaction information of the transaction generated within a period of time into a pre-processing block and send it to other consensus nodes for consensus verification.
  • Other consensus nodes will verify whether the transaction pool contains the transaction. All transaction information in the pre-processing block, if included, the verification result is passed, if not, the verification result is not passed.
  • each consensus node will reach a legal or illegal consensus on the transaction information in the pre-processing block according to the verification result of each consensus node to the pre-processing block, as a result of consensus verification of the pre-processing block by each consensus node. Therefore, in order to make the consensus verification results of the consensus nodes as accurate as possible, it is necessary to ensure that the transaction information stored in the transaction pool of each consensus node is consistent.
  • each consensus node may be used as a node for accepting transactions (hereinafter referred to as the acceptance node) to obtain transaction information of the transaction.
  • the acceptance node For a transaction, the acceptance node corresponding to the transaction needs to send transaction information to each other consensus node, and other consensus nodes that receive the transaction information will store the transaction information into their own transaction pool. It is in this way that the consensus nodes keep the transaction information stored in the transaction pool of each consensus node consistent.
  • the instability of the network often leads to the instability of information transmission between the consensus nodes, and some consensus nodes may not receive the transmitted information.
  • the receiving node sends transaction information to other consensus nodes. If network disturbance occurs, the transaction information sent by the receiving node to other consensus nodes may not be received by all other consensus nodes, which may result in transaction pool storage of each consensus node. The transaction information cannot be consistent, which reduces the accuracy of the consensus verification results of the consensus nodes.
  • the embodiment of the present application provides a method and a device for transmitting transaction information and consensus verification, so as to solve the problem that the existing method for sending transaction information and consensus verification reduces the accuracy of the consensus verification result of each consensus node.
  • the consensus node obtains transaction information
  • the transaction information is resent according to the consensus verification failure notification.
  • the consensus node receives the pre-processing block sent by other consensus nodes;
  • the consensus verification process if it is determined that the at least one transaction information included in the pre-processing block does not exist in the transaction pool, determining, in the transaction information included in the pre-processing block, the missing transaction in the transaction pool The information of the information is identified, and a consensus verification failure notification including the information identifier is sent to other consensus nodes.
  • the first sending module sends the transaction information to other consensus nodes
  • the second sending module resends the transaction information according to the consensus verification failure notification when receiving the consensus verification failure notification sent by the other consensus node and containing the information identifier of the transaction information.
  • Receiving a module receiving a pre-processing block sent by another consensus node
  • the consensus verification module performs consensus verification on the pre-processing block according to the transaction information stored in the transaction pool and the transaction information included in the pre-processing block;
  • a sending module in the consensus verification process, if it is determined that the at least one transaction information included in the preprocessing block does not exist in the transaction pool, determining, in the transaction information included in the preprocessing block, the transaction pool The information of the missing transaction information is identified, and a consensus verification failure notification including the information identifier is sent to other consensus nodes.
  • the node in the transaction acceptance stage, if some other consensus node fails to receive the transaction information sent by the acceptance node, then the other consensus is reached in the consensus verification phase. If the node determines that the transaction information included in the pre-processing block does not exist in its own transaction pool, the node may send a consensus verification failure notification including the information identifier of the transaction information to the receiving node, so that the receiving node re-sends the transaction information. Sent to the other consensus node. Through the embodiments of the present application, it is possible to ensure that the transaction information stored in the transaction pool of each consensus node is consistent as much as possible, so that the accuracy of the consensus verification result of each consensus node is not reduced.
  • FIG. 1 is a flowchart of a method for sending transaction information according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of a reliable mechanism for accepting a transaction phase according to an embodiment of the present application
  • FIG. 3 is a flowchart of a method for consensus verification provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of an apparatus for sending transaction information according to an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a device for consensus verification provided by an embodiment of the present application.
  • Embodiments of the present application provide a method and apparatus for transmitting transaction information and consensus verification.
  • FIG. 1 is a flowchart of a method for sending transaction information according to an embodiment of the present application, including the following steps:
  • S101 The consensus node acquires transaction information.
  • the transaction information may be all detailed information related to the transaction, such as an account address, a transaction amount, a transaction category, and the like.
  • the consensus node acts as an accepting node and can receive transaction information sent by the client.
  • the client may be a client of a blockchain node participating in the transaction.
  • the consensus node can also initiate a transaction and generate transaction information for the transaction.
  • the acceptance node described below refers to the consensus node that accepts the transaction at the acceptance stage, and is the execution subject of the embodiment of the present application.
  • S102 Send the transaction information to other consensus nodes.
  • the receiving node After obtaining the transaction information, the receiving node stores the transaction information in its own transaction pool on the one hand, and sends the transaction information to other consensus nodes on the other hand, so that other consensus nodes receive the transaction. After the information, the transaction information is stored in the transaction pool of other consensus nodes, and in the consensus verification phase, each consensus node can judge whether the transaction information stored in the transaction pool contains all the transaction information in the pre-processing block. To verify the pre-processing block.
  • the other consensus node is a consensus node other than the receiving node.
  • the transaction pool is a database for storing transaction information.
  • Each consensus node has its own transaction pool.
  • the transaction pool can be built in the memory of the consensus node or can be built into the external memory of the consensus node.
  • each consensus node can perform multi-process work, that is, accepting one transaction A on the one hand and the pre-processing block (excluding transaction A) containing a batch of transaction information on the other hand. Consensus verification. As long as the computing power is sufficient, the consensus node can process the acceptance or consensus verification of different transactions at the same time.
  • the transaction acceptance phase and the consensus verification phase are relative to a transaction. In terms of trading information.
  • the consensus node may create a thread for each other consensus node, and send the transaction information to the other consensus nodes by using the thread.
  • the consensus node may use the asynchronous call technology to send the transaction information through the thread, and after the transaction information is sent, the thread may be revoked regardless of whether the other consensus node can receive the transaction information;
  • the transaction information may be sent by using a synchronous calling technology. After the transaction information is to be sent, the consensus node continues to wait for the response signal returned by the other consensus node after receiving the transaction information.
  • the consensus verification failure notification is sent by other consensus nodes in a subsequent consensus verification phase.
  • the consensus-initiated consensus node (hereinafter referred to as the leader leader node) packages the transaction information of a batch of transactions in its transaction pool into a pre-processing block, and sends the pre-processing block to the consensus node except the leader node. (hereinafter referred to as the replica replica node), so that the consensus nodes (leader nodes and each replica node) perform consensus verification on the pre-processing block.
  • the leader node may be elected in each consensus node, or may be randomly specified.
  • the execution subject of the embodiment of the present application is an accepting node in the transaction acceptance stage.
  • the receiving node may be a leader node at the same time, or a replica node at the same time, which is not limited in this application.
  • the other consensus nodes are other consensus nodes except the receiving node in the receiving phase, which may generally be a replica node or a leader node.
  • each consensus node may change accordingly.
  • the previous acceptance node may become a replica node, and some other consensus nodes may become leader nodes. .
  • the transaction information in the pre-processing block is compared with the transaction information stored in the transaction pool, and if it is stored in its own transaction pool.
  • the transaction information includes all the transaction information in the pre-processing block, indicating that the replica node successfully received the transaction information in the previous transaction acceptance phase.
  • the replica node is before The transaction acceptance phase does not successfully receive the transaction information, then the verification of the pre-processing block by the replica node is unsuccessful, and it will broadcast the consensus verification of the information identifier containing the missing transaction information to other replica nodes and the leader node. Failure notification.
  • Each consensus node that receives the consensus verification failure notification may view the transaction pool of the consensus node, and if the transaction pool of the consensus node stores the transaction information corresponding to the information identifier included in the consensus verification failure notification (the consensus) When the node successfully receives the transaction information in the transaction acceptance phase or the consensus node is the acceptance node, the transaction information corresponding to the information identifier is sent to the replica node that sends the consensus verification failure notification.
  • each consensus node may lack preprocessing. Part of the transaction information contained in the block, and the transaction information missing from each consensus node is definitely stored in the transaction pool of the receiving node that originally broadcast the transaction information. Moreover, the transaction information missing from each consensus node may also be stored in the transaction pool of more than one other consensus node. That is to say, in the consensus verification phase, the transaction information missing from each consensus node can be compensated by the common help of other consensus nodes.
  • A there are five consensus nodes A, B, C, D, and E in the blockchain network.
  • A In the consensus verification phase, A generates a pre-processing block as a leader node, and the transaction information contained in the pre-processing block is A, B, and C, where A is broadcast when E is the receiving node, B is broadcast when A is the receiving node, and C is broadcast when D is the receiving node.
  • A is broadcast when E is the receiving node
  • B is broadcast when A is the receiving node
  • C is broadcast when D is the receiving node.
  • B will send consensus verification of information signs containing A, B, and C to A, C, D, and E. Failure notification. In this way, B will receive A, B, C sent by A, B, C sent by C, A, B, C sent by D, and A and C sent by E. In other words, the missing transaction information in B's trading pool can be compensated by the consensus help of A, C, D, and E.
  • the consensus node that receives the notification of the consensus verification failure sends the transaction information to the replica node in a compensatory manner, and actually ensures that the replica node receives the message with a high probability.
  • the transaction information is overcome, thereby overcoming the network disturbance and ensuring the consistency of the transaction pools of the consensus nodes.
  • the consensus verification phase may be waited according to the received The consensus verification failure notification, compensatingly resends the transaction information to other consensus nodes that send the consensus verification failure notification.
  • the transaction acceptance stage it is assumed that some other consensus node fails to receive the transaction information sent by the acceptance node, and then wait until the consensus verification phase, the other consensus node determines the pre-processing block. If the included transaction information does not exist in its own transaction pool, the consensus verification failure notification including the information identifier of the transaction information may be sent to the receiving node, so that the receiving node resends the transaction information to the other consensus node. .
  • the embodiments of the present application it is possible to ensure that the transaction information stored in the transaction pool of each consensus node is consistent as much as possible, so that the accuracy of the consensus verification result of each consensus node is not reduced.
  • some reliable mechanisms may also be adopted to enhance the reliability of the consensus node to send transaction information to other consensus nodes.
  • step S102 the consensus node creates a thread for each of the other consensus nodes, and sends transaction information to the other consensus nodes through the thread. If it is determined that the other consensus node does not receive the transaction information, the transaction information is resent to the other consensus node by the thread until it is determined that the other consensus node receives the transaction information or meets a preset stop sending condition. until.
  • the response signal returned by the other consensus node is received by the thread within the specified time period, it is determined that the other consensus node receives the transaction information; if the thread does not receive the other information within the specified time period The response signal returned by the consensus node determines that the other consensus node has not received the transaction information.
  • the preset stop sending condition may be that the number of times the transaction information is sent to the other consensus node reaches a preset number of times, or from the first time the transaction information is sent to the other consensus node. The time exceeds the preset duration.
  • the present application does not specifically limit the preset number of times and the preset duration.
  • the way in which the consensus node resends the transaction information to the other consensus nodes by using the thread may be resent once the last transmission failure is determined, or may be delayed waiting for a specific time interval to be sent.
  • the specific time interval is configurable, and the specific time interval for each retransmission wait may be the same or different, such as a specific time interval gradually lengthening or decreasing.
  • the consensus node creates a thread for each other consensus node, and sends a transaction information to the other consensus node first through the thread. If the other consensus node does not return a response signal, the consensus node may delay 5S. Resend the transaction information. If the response signal has not been received, the transaction information will be resent after 15S delay. If the corresponding signal has not been received, the transaction information can be resent after a longer time, if it continues, until The number of times of transmission reaches a preset number of times, or the elapsed time since the first time the transaction information is sent to the other consensus node exceeds a preset duration.
  • the transaction information may be further added to the return queue (back queue), and a thread dedicated to scanning the back queue may be created.
  • Recovery scans the back queue every specific time interval, scans the transaction information, and sends it out through Recovery until the elapsed time since the first time the transaction information is sent to the other consensus nodes exceeds the preset duration.
  • the specific time interval of the Recovery scan back queue is also configurable.
  • the thread that sends the transaction information to the preset number of times will be revoked to save the resources of the consensus node
  • the transaction information is added to the back queue
  • the standby Recovery queue is responsible for scanning and transmitting the transaction information in the back queue every specific time interval. . In this way, it is possible to avoid waste of resources caused by the consensus node maintaining more threads.
  • the consensus node actually uses the weak synchronization calling technology to send transaction information to the other consensus nodes.
  • the consensus node for each of the other consensus nodes, asynchronously invokes a thread, and sends a transaction information to the other consensus node by using the synchronous call by the thread.
  • the thread occupies the computing resource of the consensus node, and the consensus node waits for the other consensus node to return a response signal through the thread, and if the other consensus node fails to return the response signal within the specified time period, If the other consensus node fails to receive the transaction information, the consensus node further sends the transaction information to the other consensus node through the thread.
  • the weak synchronization calling technology is adopted in the transaction acceptance phase, so that the consensus node does not have to put a more important work process on the one hand to specifically wait for the response signal returned by other consensus nodes, and on the other hand, can utilize each other.
  • the thread corresponding to the consensus node waits for the response signal and repeatedly sends the transaction information, thereby ensuring that the other consensus nodes successfully receive the transaction information.
  • the transaction information when the preset stop sending condition is met, if the other consensus node still does not return a response signal, the transaction information may be added to the preset queue.
  • the transaction information corresponding to the information identifier is searched in the queue and sent according to the information identifier included in the consensus verification failure notification.
  • the queue is a storage space in the memory of the consensus node, and is used to store transaction information that is repeatedly received by the other consensus nodes but is not repeatedly received by the other consensus nodes.
  • the transaction pool of the consensus node is not built in the memory, repeatedly trying to send the transaction information that still fails to be stored in the queue, so that the consensus node may be in the consensus verification phase to other consensus that the transaction information is missing. The node sends the transaction information more quickly.
  • the consensus node when the transaction pool is not built in the memory, in the consensus verification phase, when the consensus node receives the consensus verification failure notification sent by a certain replica node, it should check whether there is a missing of the replica node in its own queue. Transaction information, without having to look at its own transaction pool, if there is transaction information missing from the replica node in its own queue, it can be sent to the replica node. If there is no transaction information missing from the replica node in its own queue, then it is not necessary to The replica node sends (even if there is a transaction in the transaction pool that is missing from the replica node).
  • FIG. 2 is a schematic diagram of a reliable mechanism for accepting a transaction phase according to an embodiment of the present application.
  • the receiving node in the transaction acceptance phase, the receiving node will try to send transaction information to other consensus nodes by delay 5S, delay 10min, etc., and the way this attempt is sent is not unrestrained, when the number of transmissions exceeds 3 times, a longer delay will be used to send the transaction information, when the transaction information activity period (the time since the first time the transaction information was sent to the other consensus node) exceeds the preset duration (such as 1 hour) ), the transaction information will be added to the default queue and stop sending. Waiting for the consensus verification phase, the consensus node receives the consensus verification failure notification to activate the transaction information in the queue.
  • the preset duration may be determined according to a period in which the consensus nodes perform consensus verification, or may be determined according to a troubleshooting period of a general network fault.
  • the consensus node delays attempting to send the transaction information, and after transmitting the transaction information 2 times in the repeated delay 5S, it indicates that there is a transmission problem that cannot be solved temporarily (may be unsuccessful reception). Other consensus nodes are down or the network has a big fault), so the transaction information is temporarily suspended and sent to the other consensus nodes. After waiting for a long time (such as 10 minutes), the transmission problem may have been solved, and then continue to send, waiting for the transaction information. If the activity period is too long, the transaction information can be added to the preset queue, and then waited for subsequent compensation to be sent to other consensus nodes lacking the transaction information.
  • each consensus node compensates for each consensus node lacking transaction information, which can well solve the inconsistency of the transaction pool of each consensus node caused by the network disturbance.
  • the problem On this basis, through the reliable mechanism described in Figure 2, it is possible to take measures to improve the success rate of other consensus nodes receiving transaction information from the transaction acceptance stage.
  • FIG. 3 is a method for consensus verification provided by an embodiment of the present application, including the following steps:
  • S301 The consensus node receives the pre-processing block sent by other consensus nodes.
  • S302 Perform consensus verification on the pre-processing block according to the transaction information stored in the transaction pool and the transaction information included in the pre-processing block.
  • S304 Send a consensus verification failure notification including the information identifier to other consensus nodes.
  • the consensus node is a consensus verification phase, and a consensus node that performs verification on the pre-processing block is a replica node.
  • the other consensus nodes are nodes that initiate consensus, that is, leader nodes.
  • the embodiment of the present application further provides a device for sending transaction information, as shown in FIG. 4 , including:
  • Obtaining module 401 acquiring transaction information
  • the first sending module 402 sends the transaction information to other consensus nodes
  • the second sending module 403 when receiving the consensus verification failure notification sent by the other consensus node and including the information identifier of the transaction information, resends the transaction information according to the consensus verification failure notification.
  • the obtaining module 401 receives transaction information sent by the client.
  • the first sending module 402 creates a thread for each other consensus node, and sends the transaction information to the other consensus nodes through the thread.
  • the first sending module 402 if it is determined that the other consensus node does not receive the transaction information, resend the transaction information to the other consensus node through the thread until it is determined that the other consensus node receives the transaction information. Or until the preset stop sending condition is met.
  • the first sending module 402 if the response signal returned by the other consensus node is received by the thread within the specified time period, determining that the other consensus node receives the transaction information; if the thread fails to pass the specified time period Receiving the response signal returned by the other consensus node, determining that the other consensus node does not receive the transaction information.
  • the preset stop sending condition specifically includes: sending the transaction information to the other consensus node for a preset number of times; or elapsed from the first time sending the transaction information to the other consensus node Set the duration.
  • the device further includes: an adding module 404, when the preset stop sending condition is met, adding the transaction information to a preset queue;
  • the second sending module 403 searches for the transaction information corresponding to the information identifier in the queue according to the information identifier included in the consensus verification failure notification, and sends the information.
  • the embodiment of the present application further provides a device for consensus verification, as shown in FIG. 5, including:
  • the receiving module 501 receives the pre-processing block sent by other consensus nodes
  • the consensus verification module 502 performs consensus verification on the pre-processing block according to the transaction information stored in the transaction pool and the transaction information included in the pre-processing block;
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media including both permanent and non-persistent, removable and non-removable media can be implemented by any method or technology.
  • the message can be a computer readable instruction, a data structure, a module of the program, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • ROM read only memory
  • EEPROM electrically erasable programmable read only memory
  • flash memory or other memory technology
  • compact disk read only memory CD-ROM
  • DVD digital versatile disk
  • a magnetic tape cartridge, magnetic tape storage or other magnetic storage device or any other non-transportable medium can be used to store messages that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • the present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Retry When Errors Occur (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请实施例公开了一种发送交易信息和共识验证的方法及装置。在交易受理阶段，倘若某个其他共识节点未能接收到受理节点发送的交易信息，那么在共识验证阶段，该其他共识节点若确定预处理块包含的所述交易信息不存在于自己的交易池中，则可以向受理节点发送包含所述交易信息的信息标识的共识验证失败通知，使得受理节点重新将所述交易信息发送给该其他共识节点。通过本申请实施例，可以尽可能确保各共识节点的交易池中存储的交易信息是一致的，从而不会降低各共识节点的共识验证结果的准确性。

Description

一种发送交易信息和共识验证的方法及装置 技术领域
本申请涉及区块链技术领域，尤其涉及一种发送交易信息和共识验证的方法及装置。
背景技术
在区块链技术领域中，负责对交易进行共识验证的区块链节点称为共识节点。
在共识验证阶段，发起共识验证的共识节点需要将一段时间内产生的交易的交易信息打包成预处理块发送给其他共识节点以进行共识验证，其他共识节点会验证自己的交易池中是否包含该预处理块中的所有交易信息，如果包含，则验证结果为通过，如果不包含，则验证结果为不通过。随后，各共识节点会根据每个共识节点对预处理块的验证结果来对该预处理块中的交易信息达成合法或不合法的共识，作为各共识节点对预处理块共识验证的结果。因此，为了使各共识节点的共识验证结果尽可能准确，需要确保各共识节点的交易池存储的交易信息一致。
在交易受理阶段，针对不同的交易，每个共识节点都可能作为受理交易的节点(下称受理节点)，获取交易的交易信息。对某笔交易而言，这笔交易对应的受理节点需要向每个其他共识节点发送交易信息，接收到交易信息的其他共识节点会将交易信息存入自己的交易池中。各共识节点正是通过这样的方式使得各共识节点的交易池存储的交易信息保持一致的。
但是，由于网络的扰动总是不可避免的，因此网络的不稳定时常会导致共识节点间信息传输的不稳定，有的共识节点可能未接收到发送的信息。例如，受理节点向其他共识节点发送交易信息，倘若出现网络扰动，则受理节点发送给其他共识节点的交易信息有可能未被所有其他共识节点接收到，这就会导致 各共识节点的交易池存储的交易信息无法保持一致，从而降低各共识节点的共识验证结果的准确性。
发明内容
本申请实施例提供一种发送交易信息和共识验证的方法及装置，以解决现有的发送交易信息和共识验证的方法会降低各共识节点的共识验证结果的准确性的问题。
为解决上述技术问题，本申请实施例是这样实现的：
本申请实施例提供的一种发送交易信息的方法，包括：
共识节点获取交易信息；
发送所述交易信息给其他共识节点；
当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信息。
本申请实施例提供的一种共识验证的方法，包括：
共识节点接收其他共识节点发送的预处理块；
根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证；
在共识验证过程中，若确定所述预处理块包含的至少一个交易信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识，并向其他共识节点发送包含所述信息标识的共识验证失败通知。
本申请实施例提供的一种发送交易信息的装置，包括：
获取模块，获取交易信息；
第一发送模块，发送所述交易信息给其他共识节点；
第二发送模块，当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信 息。
本申请实施例提供的一种共识验证的装置，包括：
接收模块，接收其他共识节点发送的预处理块；
共识验证模块，根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证；
发送模块，在共识验证过程中，若确定所述预处理块包含的至少一个交易信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识，并向其他共识节点发送包含所述信息标识的共识验证失败通知。
由以上本申请实施例提供的技术方案可见，在本申请实施例中，在交易受理阶段，假设某个其他共识节点未能接收到受理节点发送的交易信息，那么等到共识验证阶段，该其他共识节点若确定预处理块包含的所述交易信息不存在于自己的交易池中，则可以向受理节点发送包含所述交易信息的信息标识的共识验证失败通知，使得受理节点重新将所述交易信息发送给该其他共识节点。通过本申请实施例，可以尽可能确保各共识节点的交易池中存储的交易信息是一致的，从而不会降低各共识节点的共识验证结果的准确性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种发送交易信息的方法流程图；
图2是本申请实施例提供的一种受理交易阶段的可靠机制示意图；
图3是本申请实施例提供的一种共识验证的方法流程图；
图4是本申请实施例提供的一种发送交易信息的装置示意图；
图5是本申请实施例提供的一种共识验证的装置示意图。
具体实施方式
本申请实施例提供一种发送交易信息和共识验证的方法及装置。
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
以下结合附图，详细说明本申请各实施例提供的技术方案。
图1是本申请实施例提供的一种发送交易信息的方法流程图，包括以下步骤：
S101：共识节点获取交易信息。
在本申请实施例中，所述交易信息可以是交易涉及的所有详情信息，如账户地址、交易金额、交易类别等。
在交易受理阶段，所述共识节点作为受理节点，可以接收客户端发送的交易信息。所述客户端可以是参与所述交易的区块链节点的客户端。当然，所述共识节点也可以自己发起交易并生成交易的交易信息。
为了描述的方便，下文所述的受理节点，即是指在受理阶段受理交易的共识节点，是本申请实施例的执行主体。
S102：发送所述交易信息给其他共识节点。
所述受理节点在获取交易信息之后，一方面会将所述交易信息存储在自己的交易池中，另一方面会向其他共识节点发送所述交易信息，以使其他共识节点接收到所述交易信息后分别将所述交易信息存储在其他共识节点的交易池中，进而在共识验证阶段，各共识节点就可以通过判断自己的交易池中存储的交易信息是否包含预处理块中的所有交易信息来验证预处理块。
其中，所述其他共识节点是除所述受理节点之外的共识节点。所述交易池是用于存储交易信息的数据库。每个共识节点都有自己的交易池。所述交易池可以被搭建在共识节点的内存中，也可以被搭建在共识节点的外部存储器中。
值得强调的是，对每个共识节点而言，其可以执行多进程工作，即一方面受理一笔交易A，另一方面参与对包含一批交易信息的预处理块(不包含交易A)的共识验证。只要运算能力足够，共识节点可以同时多进程处理不同交易的受理或共识验证。
而在本申请实施例中，由于为了详细说明如何尽可能保证每个其他共识节点都接收到某笔交易的交易信息，因此，所述交易受理阶段和所述共识验证阶段是相对于一笔交易的交易信息而言的。
在本申请实施例中，所述共识节点可以针对每个其他共识节点创建线程，并通过该线程发送所述交易信息给该其他共识节点。其中，所述共识节点通过该线程，可以采用异步调用技术发送所述交易信息，待发送所述交易信息后，不论该其他共识节点能否接收到所述交易信息，该线程都会被撤销；也可以采用同步调用技术发送所述交易信息，待发送所述交易信息后，所述共识节点继续通过该线程等待接收该其他共识节点在接收到所述交易信息后返回的响应信号。
S103：当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信息。
在本申请实施例中，所述共识验证失败通知是在后续的共识验证阶段，由其他共识节点发送的。在共识验证阶段，发起共识的共识节点(下称领导leader节点)会将自身交易池中的一批交易的交易信息打包成预处理块，并将预处理块发送给除leader节点外的共识节点(下称副本replica节点)，以使各共识节点(leader节点和各replica节点)对预处理块进行共识验证。其中，leader节点可以是各共识节点选举中的，也可以是随机指定的。
值得强调的是，本申请实施例的执行主体是交易受理阶段的受理节点，在 共识验证阶段，所述受理节点可以同时是leader节点，或同时是replica节点，本申请对此不做限制。还有，所述其他共识节点是受理阶段除所述受理节点之外的其他共识节点，其一般可以是replica节点，也可以是leader节点。
总之，在由交易受理阶段过渡到共识验证阶段后，各共识节点的具体身份可能会随之发生变化，之前的受理节点可能变为replica节点，而之前的某个其他共识节点可能变为leader节点。
在本申请实施例中，某个replica节点在对预处理块进行验证时，会将预处理块中的交易信息与自己的交易池中存储的交易信息进行比对，如果自己的交易池中存储的交易信息囊括了预处理块中的所有交易信息，则说明该replica节点在之前的交易受理阶段成功接收到了所述交易信息。
如果自己的交易池中存储的交易信息未囊括预处理块中的所有交易信息，即自己的交易池中存储的交易信息缺少了预处理块中的某些交易信息，则说明该replica节点在之前的交易受理阶段未成功接收到这些交易信息，那么，该replica节点对预处理块的验证是失败的，其会向其他的replica节点和leader节点广播包含这些缺失的交易信息的信息标识的共识验证失败通知。每个接收到所述共识验证失败通知的共识节点，可以查看该共识节点的交易池，如果该共识节点的交易池中存储了所述共识验证失败通知包含的信息标识对应的交易信息(该共识节点在交易受理阶段成功接收到了所述交易信息或该共识节点是受理节点)，则将所述信息标识对应的交易信息发送给发送所述共识验证失败通知的replica节点。
值得强调的是，由于预处理块中包含的一批交易信息往往数量巨大，这些交易信息也往往是经由不同的受理节点广播的，因此，在共识验证阶段，每个共识节点都可能缺少预处理块中包含的部分交易信息，而每个共识节点缺少的交易信息，肯定是存储在当初广播该交易信息的受理节点的交易池中的。并且，每个共识节点缺少的交易信息也可能存储在不止一个其他的共识节点的交易池中。也就是说，在共识验证阶段，每个共识节点缺少的交易信息都可以通过 其他的共识节点共同的帮助，从而得到补偿。
例如，区块链网络中有5个共识节点A、B、C、D、E，在共识验证阶段，A作为leader节点生成预处理块，预处理块中包含的交易信息分别为甲、乙、丙，其中，甲是E作为受理节点时广播的，乙是A作为受理节点时广播的，丙是D作为受理节点时广播的。假设在甲的受理阶段，B、C没有接收到甲，在乙的受理阶段，B、E没有接收到乙，在丙的受理阶段，B没有接收到丙，那么在共识验证阶段，A发送给B、C、D、E预处理块后，由于B的交易池中缺少甲、乙、丙，因此，B会向A、C、D、E发送包含甲、乙、丙的信息标识的共识验证失败通知。如此一来，B会分别接收到A发送的甲、乙、丙，C发送的乙、丙，D发送的甲、乙、丙，E发送的甲、丙。也就是说，B的交易池中缺少的交易信息可以通过A、C、D、E的共识帮助而得到补偿。
此外，由于网络扰动，因此由所有接收到所述共识验证失败通知的共识节点都向该replica节点补偿性地发送所述交易信息，实际上也能够确保该replica节点在很大概率上接收到所述交易信息，从而克服了网络扰动，保证了各共识节点交易池的一致。
综上，在本申请实施例中，所述共识节点在向其他共识节点发送了交易信息后，不论每个其他共识节点是否接收到了所述交易信息，都可以等到共识验证阶段，根据接收到的共识验证失败通知，补偿性地重新向发送共识验证失败通知的其他共识节点发送所述交易信息。
可见，通过图1所示的发送信息的方法，在交易受理阶段，假设某个其他共识节点未能接收到受理节点发送的交易信息，那么等到共识验证阶段，该其他共识节点若确定预处理块包含的所述交易信息不存在于自己的交易池中，则可以向受理节点发送包含所述交易信息的信息标识的共识验证失败通知，使得受理节点重新将所述交易信息发送给该其他共识节点。通过本申请实施例，可以尽可能确保各共识节点的交易池中存储的交易信息是一致的，从而不会降低各共识节点的共识验证结果的准确性。
进一步地，在本申请实施例中，在交易受理阶段，还可以采取一些可靠机制，来增强所述共识节点向其他共识节点发送交易信息的可靠性。
在步骤S102中，所述共识节点针对每个其他共识节点创建线程，并通过该线程向该其他共识节点发送交易信息。若确定该其他共识节点未接收到所述交易信息，则重新通过该线程向该其他共识节点发送所述交易信息，直至确定该其他共识节点接收到所述交易信息或满足预设的停止发送条件为止。
其中，若在指定时间段内通过该线程接收到该其他共识节点返回的响应信号，则确定该其他共识节点接收到所述交易信息；若在指定时间段内未通过该线程未接收到该其他共识节点返回的响应信号，则确定该其他共识节点未接收到所述交易信息。
具体而言，所述预设的停止发送条件可以是向该其他共识节点发送所述交易信息的次数达到预设次数，或，自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。本申请对所述预设次数、预设时长不做具体限制。
值得说明的是，所述共识节点每次通过线程向其他共识节点重发交易信息的方式，可以是一经确定上一次发送失败就重新发送，也可以是等待特定的时间间隔延时发送，其中，特定的时间间隔是可配置的，每次重发等待的特定时间间隔可以相同，也可以不同，如特定的时间间隔逐渐加长或减少。
例如，所述共识节点针对每个其他共识节点创建线程，并通过该线程先向该其他共识节点发送一次交易信息，若该其他共识节点未返回响应信号，则所述共识节点可以延时5S后重新发送交易信息，若仍未接收到响应信号，则延时15S后重新发送交易信息，若仍未接收到相应信号，则可以延时更长时间后重新发送所述交易信息，如是继续，直至发送次数达到预设次数，或自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。
特殊地，在上述举例中，若所述共识节点发送交易信息的次数达到预设次数，则可以进一步将所述交易信息添加到返回队列(back队列)，并创建专门 用于扫描back队列的线程Recovery，Recovery每特定时间间隔扫描一次back队列，将所述交易信息扫描出来，并通过Recovery发送出去，直至自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。当然，Recovery扫描back队列的特定时间间隔也是可配置的。也就是说，发送交易信息达到预设次数的线程会被撤销以节省共识节点的资源，交易信息被添加到back队列，而由常备的Recovery队列负责每特定时间间隔扫描发送back队列中的交易信息。这样以来，可以避免共识节点维持较多的线程造成的资源浪费。
在上述举例中，所述共识节点实际上是采用弱同步调用技术，向该其他共识节点发送交易信息的。具体而言，所述共识节点针对每个其他共识节点，异步调用一个线程后，通过该线程采用同步调用向该其他共识节点发送交易信息。该线程会占用所述共识节点的运算资源，所述共识节点正是通过该线程等待该其他共识节点返回响应信号，并且，若该其他共识节点未能在指定时间段内返回响应信号，则说明该其他共识节点未能接收到交易信息，则所述共识节点还会通过该线程重新向该其他共识节点发送交易信息。如此一来，在交易受理阶段采用弱同步调用技术，可以使得所述共识节点一方面不必搁置更为重要的工作进程来专门等待其他共识节点返回的响应信号，另一方面又可以利用每个其他共识节点对应的线程来等待响应信号、重复发送交易信息，从而保证其他共识节点顺利接收到交易信息。
此外，在本申请实施例中，当满足预设的停止发送条件时，如果该其他共识节点仍未返回响应信号，则可以将所述交易信息添加到预设的队列中。待接收到所述共识验证失败通知时，再根据所述共识验证失败通知中包含的信息标识，在所述队列中查找所述信息标识对应的交易信息并发送。
其中，所述队列是所述共识节点内存中的存储空间，用于存储在受理阶段虽反复尝试发送却仍未被每个其他共识节点接收到的交易信息。当所述共识节点的交易池未被搭建在内存中时，将反复尝试发送仍失败的交易信息存入所述队列，可以使得所述共识节点在共识验证阶段向缺少所述交易信息的其他共识 节点更快速地发送所述交易信息。
特殊地，当交易池未被搭建在内存中时，在共识验证阶段，所述共识节点接收到某个replica节点发送的共识验证失败通知时，应查看自己的队列中是否有该replica节点缺少的交易信息，而不必查看自己的交易池，若自己的队列中有该replica节点缺少的交易信息，则可以向该replica节点发送，若自己的队列中没有该replica节点缺少的交易信息，则不必向该replica节点发送(即便自己的交易池中有该replica节点缺少的交易)。这样一来，假设该replica缺少交易信息X，则总能够保证是由广播该交易信息X的受理节点来从其队列中捞取并发送该交易信息X，从而使得缺少交易信息的replica节点总能得到快速的补偿。
图2是本申请实施例提供的一种受理交易阶段的可靠机制示意图。如图2所示，在交易受理阶段，受理节点会通过延时5S、延时10min等方式尝试向其他共识节点发送交易信息，并且，这种尝试发送的方式不是无节制的，当发送次数超过3次，就会采用更长的延时来发送交易信息，当交易信息活动期(自第一次向该其他共识节点发送所述交易信息起经过的时间)超过预设时长(如1个小时)，交易信息就会被添加到预设的队列，停止发送。等待共识验证阶段，所述共识节点接收到所述共识验证失败通知，才会激活所述队列中的交易信息。
值得强调的是，所述预设时长可以是根据各共识节点执行共识验证的周期确定的，也可以是根据一般网络故障的排障期确定的。
通过图2所示的可靠机制，所述共识节点延时尝试发送所述交易信息，在重复延时5S发送交易信息达到2次后，说明存在暂时无法解决的传输问题(可能是未接收成功的其他共识节点宕机或者网络出现大的故障)，于是先暂停向该其他共识节点发送交易信息，等待较长时间(如10min)后，传输问题可能已经解决了，再继续发送，待交易信息的活动期过长，便可以将交易信息添加到预设的队列，等待后续通过补偿地方式再发送给缺少所述交易信息的其他共 识节点。
在本申请实施例中，通过在共识验证阶段，由各共识节点共同补偿性地为每个缺少交易信息的共识节点进行补偿，可以很好地解决网络扰动带来的各共识节点的交易池不一致的问题。在此基础上，通过图2所述的可靠机制，可以从交易受理阶段开始，就采取措施提升其他共识节点接收到交易信息的成功率。
图3是本申请实施例提供的一种共识验证的方法，包括以下步骤：
S301：共识节点接收其他共识节点发送的预处理块。
S302：根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证。
S303：在共识验证过程中，若确定所述预处理块包含的至少一个交易信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识。
S304：向其他共识节点发送包含所述信息标识的共识验证失败通知。
在本申请实施例中，所述共识节点是共识验证阶段，对预处理块进行验证的某个共识节点，也就是replica节点。所述其他共识节点是发起共识的节点，也就是leader节点。
关于对图3所示的共识验证的方法的详细说明，在对图1所示的发送交易信息的方法的说明中已有记载，不再赘述。
基于图1所示的发送交易信息的方法，本申请实施例还对应提供了一种发送交易信息的装置，如图4所示，包括：
获取模块401，获取交易信息；
第一发送模块402，发送所述交易信息给其他共识节点；
第二发送模块403，当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信息。
所述获取模块401，接收客户端发送的交易信息。
所述第一发送模块402，针对每个其他共识节点创建线程，并通过该线程发送所述交易信息给该其他共识节点。
所述第一发送模块402，若确定该其他共识节点未接收到所述交易信息，则重新通过该线程向该其他共识节点发送所述交易信息，直至确定该其他共识节点接收到所述交易信息或满足预设的停止发送条件为止。
所述第一发送模块402，若在指定时段内通过该线程接收到该其他共识节点返回的响应信号，则确定该其他共识节点接收到所述交易信息；若在指定时段内未通过该线程未接收到该其他共识节点返回的响应信号，则确定该其他共识节点未接收到所述交易信息。
所述预设的停止发送条件，具体包括：向该其他共识节点发送所述交易信息的次数达到预设次数；或自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。
所述装置还包括：添加模块404，当满足预设的停止发送条件时，将所述交易信息添加到预设的队列中；
所述第二发送模块403，根据所述共识验证失败通知中包含的信息标识，在所述队列中查找所述信息标识对应的交易信息并发送。
基于图3所示的共识验证的方法，本申请实施例还对应提供了一种共识验证的装置，如图5所示，包括：
接收模块501，接收其他共识节点发送的预处理块；
共识验证模块502，根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证；
发送模块503，在共识验证过程中，若确定所述预处理块包含的至少一个交易信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识，并向其他共识节点发送包含所述信息标识的共识验证失败通知。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器 的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算 机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现消息存储。消息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的消息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排 他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

  1. 一种发送交易信息的方法，其特征在于，包括：
    共识节点获取交易信息；
    发送所述交易信息给其他共识节点；
    当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信息。
  2. 根据权利要求1所述的方法，其特征在于，共识节点获取交易信息，具体包括：
    共识节点接收客户端发送的交易信息。
  3. 根据权利要求1所述的方法，其特征在于，发送所述交易信息给其他共识节点，具体包括：
    针对每个其他共识节点创建线程，并通过该线程发送所述交易信息给该其他共识节点。
  4. 根据权利要求3所述的方法，其特征在于，通过该线程发送所述交易信息给该其他共识节点，具体包括：
    若确定该其他共识节点未接收到所述交易信息，则重新通过该线程向该其他共识节点发送所述交易信息，直至确定该其他共识节点接收到所述交易信息或满足预设的停止发送条件为止。
  5. 根据权利要求4所述的方法，其特征在于，确定该其他共识节点接收到所述交易信息，具体包括：
    若在指定时段内通过该线程接收到该其他共识节点返回的响应信号，则确定该其他共识节点接收到所述交易信息；
    确定该其他共识节点未接收到所述交易信息，具体包括：
    若在指定时段内未通过该线程接收到该其他共识节点返回的响应信号，则确定该其他共识节点未接收到所述交易信息。
  6. 根据权利要求4所述的方法，其特征在于，所述预设的停止发送条件， 具体包括：
    向该其他共识节点发送所述交易信息的次数达到预设次数；或
    自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。
  7. 根据权利要求4所述的方法，其特征在于，当满足预设的停止发送条件时，所述方法还包括：
    将所述交易信息添加到预设的队列中；
    根据所述共识验证失败通知，重新发送所述交易信息，具体包括：
    根据所述共识验证失败通知中包含的信息标识，在所述队列中查找所述信息标识对应的交易信息并发送。
  8. 一种共识验证的方法，其特征在于，包括：
    共识节点接收其他共识节点发送的预处理块；
    根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证；
    在共识验证过程中，若确定所述预处理块包含的至少一个交易信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识，并向其他共识节点发送包含所述信息标识的共识验证失败通知。
  9. 一种发送交易信息的装置，其特征在于，包括：
    获取模块，获取交易信息；
    第一发送模块，发送所述交易信息给其他共识节点；
    第二发送模块，当接收到其他共识节点发送的包含所述交易信息的信息标识的共识验证失败通知时，根据所述共识验证失败通知，重新发送所述交易信息。
  10. 根据权利要求9所述的装置，其特征在于，所述获取模块，接收客户端发送的交易信息。
  11. 根据权利要求9所述的装置，其特征在于，所述第一发送模块，针对每个其他共识节点创建线程，并通过该线程发送所述交易信息给该其他共识节点。
  12. 根据权利要求11所述的装置，其特征在于，所述第一发送模块，若确定该其他共识节点未接收到所述交易信息，则重新通过该线程向该其他共识节点发送所述交易信息，直至确定该其他共识节点接收到所述交易信息或满足预设的停止发送条件为止。
  13. 根据权利要求12所述的装置，其特征在于，所述第一发送模块，若在指定时段内通过该线程接收到该其他共识节点返回的响应信号，则确定该其他共识节点接收到所述交易信息；若在指定时段内未通过该线程未接收到该其他共识节点返回的响应信号，则确定该其他共识节点未接收到所述交易信息。
  14. 根据权利要求12所述的装置，其特征在于，所述预设的停止发送条件，具体包括：
    向该其他共识节点发送所述交易信息的次数达到预设次数；或
    自第一次向该其他共识节点发送所述交易信息起经过的时间超过预设时长。
  15. 根据权利要求12所述的装置，其特征在于，所述装置还包括：
    添加模块，当满足预设的停止发送条件时，将所述交易信息添加到预设的队列中；
    所述第二发送模块，根据所述共识验证失败通知中包含的信息标识，在所述队列中查找所述信息标识对应的交易信息并发送。
  16. 一种共识验证的装置，其特征在于，包括：
    接收模块，接收其他共识节点发送的预处理块；
    共识验证模块，根据交易池中存储的交易信息和所述预处理块包含的交易信息，对所述预处理块进行共识验证；
    发送模块，在共识验证过程中，若确定所述预处理块包含的至少一个交易 信息不存在于所述交易池中，则在所述预处理块包含的交易信息中，确定所述交易池中缺少的交易信息的信息标识，并向其他共识节点发送包含所述信息标识的共识验证失败通知。
PCT/CN2018/079439 2017-03-24 2018-03-19 一种发送交易信息和共识验证的方法及装置 WO2018171545A1 (zh)

Priority Applications (11)

Application Number Priority Date Filing Date Title
BR112019012905A BR112019012905A2 (pt) 2017-03-24 2018-03-19 método para o envio das informações de transação e dispositivo para o envio das informações de transação
JP2019534718A JP6794551B2 (ja) 2017-03-24 2018-03-19 トランザクション情報を送信するためのおよびコンセンサス検証のための方法およびデバイス
CA3047884A CA3047884C (en) 2017-03-24 2018-03-19 Method and device for sending transaction information and for consensus verification
EP18770722.9A EP3543937A4 (en) 2017-03-24 2018-03-19 METHOD AND DEVICE FOR SENDING TRANSACTION INFORMATION AND CONSENSUS VERIFICATION
RU2019119564A RU2735156C1 (ru) 2017-03-24 2018-03-19 Способ и устройство для отправки информации о транзакциях и для проверки консенсуса
KR1020197018216A KR102151899B1 (ko) 2017-03-24 2018-03-19 트랜잭션 정보 전송 및 합의 검증을 위한 방법 및 디바이스
MX2019007557A MX2019007557A (es) 2017-03-24 2018-03-19 Metodo y dispositivo para enviar informacion de transaccion y para verificacion de consenso.
AU2018240159A AU2018240159B2 (en) 2017-03-24 2018-03-19 Method and device for sending transaction information and for consensus verification
ZA2019/04053A ZA201904053B (en) 2017-03-24 2019-06-21 Method and device for sending transaction information and for consensus verification
PH12019501470A PH12019501470A1 (en) 2017-03-24 2019-06-24 Method and device for sending transaction information and for consensus verification
US16/523,580 US10679217B2 (en) 2017-03-24 2019-07-26 Methods and devices for sending transaction information and for consensus verification

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710181241.4 2017-03-24
CN201710181241.4A CN107392611B (zh) 2017-03-24 2017-03-24 一种发送交易信息和共识验证的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/523,580 Continuation US10679217B2 (en) 2017-03-24 2019-07-26 Methods and devices for sending transaction information and for consensus verification

Publications (1)

Publication Number Publication Date
WO2018171545A1 true WO2018171545A1 (zh) 2018-09-27

Family

ID=60338903

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/079439 WO2018171545A1 (zh) 2017-03-24 2018-03-19 一种发送交易信息和共识验证的方法及装置

Country Status (15)

Country Link
US (1) US10679217B2 (zh)
EP (1) EP3543937A4 (zh)
JP (1) JP6794551B2 (zh)
KR (1) KR102151899B1 (zh)
CN (2) CN111612468B (zh)
AU (1) AU2018240159B2 (zh)
BR (1) BR112019012905A2 (zh)
CA (1) CA3047884C (zh)
MX (1) MX2019007557A (zh)
PH (1) PH12019501470A1 (zh)
RU (1) RU2735156C1 (zh)
SG (1) SG10202107139RA (zh)
TW (1) TWI727120B (zh)
WO (1) WO2018171545A1 (zh)
ZA (1) ZA201904053B (zh)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111612468B (zh) * 2017-03-24 2024-03-19 创新先进技术有限公司 一种发送交易信息和共识验证的方法及装置
CN108009824A (zh) * 2017-11-28 2018-05-08 北京博晨技术有限公司 数据共识方法、装置及电子设备
CN108537525B (zh) 2018-03-09 2020-06-09 阿里巴巴集团控股有限公司 一种共识验证方法、装置及设备
CN108600163B (zh) * 2018-03-13 2020-12-15 南京邮电大学 一种云环境分布式哈希链架构及云数据完整性验证方法
GB2572340A (en) * 2018-03-26 2019-10-02 Fetch Ai Ltd Data processing system using directed acyclic graph and method of use thereof
CN108765150A (zh) * 2018-05-11 2018-11-06 中国联合网络通信集团有限公司 交易信息处理方法及存储节点
CN108665365B (zh) * 2018-05-16 2021-07-13 四川大学 一种混合区块链架构系统、处理方法及处理系统
CN108960604B (zh) * 2018-06-25 2021-06-29 山东大海集团有限公司 一种信息处理的方法、系统及装置
CN109191135A (zh) * 2018-08-27 2019-01-11 北京京东金融科技控股有限公司 基于区块链的交易重试方法、装置、设备及可读存储介质
CN109461079B (zh) * 2018-10-29 2022-04-05 众安信息技术服务有限公司 基于区块链的交易处理方法和装置
CN111182009B (zh) * 2018-11-09 2023-06-20 北京天德科技有限公司 一种区块链交易消息多汇点分发的方法
CN109639656B (zh) * 2018-12-03 2020-12-25 北京瑞卓喜投科技发展有限公司 一种区块链隐私数据传输方法及隐私数据传输系统
CN111353884B (zh) * 2018-12-20 2024-05-03 上海智知盾科技有限公司 区块链交易处理方法及系统
CN109831425B (zh) * 2019-01-25 2022-02-15 中国联合网络通信集团有限公司 区块链共识方法、装置、设备及计算机可读存储介质
CN110033271B (zh) * 2019-03-22 2023-12-22 湖南天河国云科技有限公司 一种跨链交易方法、系统及计算机可读存储介质
CN110570171B (zh) * 2019-09-11 2022-03-11 杭州秘猿科技有限公司 交易池节点同步方法、电子设备和计算机可读存储介质
CN110782255B (zh) * 2019-11-06 2022-11-15 杭州复杂美科技有限公司 延时交易取消方法、设备和存储介质
CN111064813B (zh) * 2020-03-16 2020-06-30 支付宝(杭州)信息技术有限公司 在区块链共识处理时进行处理消息同步的方法及装置
US11321149B1 (en) 2021-02-08 2022-05-03 Visa International Service Association Synchronization consensus token system and method
CN112883068A (zh) * 2021-04-30 2021-06-01 支付宝(杭州)信息技术有限公司 区块链交易执行方法、区块链节点及控制装置
CN113379542B (zh) * 2021-05-28 2024-01-09 中邮信息科技(北京)有限公司 一种区块链交易的查询方法、装置、介质及电子设备
CN113269645B (zh) * 2021-05-28 2024-05-17 中邮信息科技(北京)有限公司 一种区块链的交易信息调度方法、装置、介质及电子设备
CN113378240B (zh) * 2021-06-23 2023-03-28 浪潮云信息技术股份公司 一种基于区块链的同步调用用户身份认证方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106506146A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 基于区块链技术的交易信息校验方法、装置及系统
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
CN107392611A (zh) * 2017-03-24 2017-11-24 阿里巴巴集团控股有限公司 一种发送交易信息和共识验证的方法及装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5819020A (en) * 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
US5931917A (en) * 1996-09-26 1999-08-03 Verifone, Inc. System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser
US7620680B1 (en) * 2002-08-15 2009-11-17 Microsoft Corporation Fast byzantine paxos
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
CN102792325B (zh) * 2010-04-09 2017-09-01 维萨国际服务协会 用于安全地证实交易的系统和方法
US11270298B2 (en) * 2014-04-14 2022-03-08 21, Inc. Digital currency mining circuitry
US11232415B2 (en) * 2015-05-28 2022-01-25 OX Labs Inc. Method for cryptographically managing title transactions
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN105630609B (zh) 2016-02-24 2021-05-11 杭州复杂美科技有限公司 区块链的打包存储方法
CN106060036B (zh) * 2016-05-26 2019-07-16 布比（北京）网络技术有限公司 去中心化共识方法及装置
RU2016123959A (ru) 2016-06-16 2017-12-21 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки запроса на транзакцию в распределенных системах обработки данных
CN106445711B (zh) * 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
CN106372868B (zh) * 2016-09-06 2020-02-18 联动优势科技有限公司 一种对写入区块链的交易数据的验证方法和装置
US10862959B2 (en) * 2016-11-28 2020-12-08 Keir Finlow-Bates Consensus system and method for adding data to a blockchain

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106506146A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 基于区块链技术的交易信息校验方法、装置及系统
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
CN107392611A (zh) * 2017-03-24 2017-11-24 阿里巴巴集团控股有限公司 一种发送交易信息和共识验证的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3543937A4 *

Also Published As

Publication number Publication date
JP6794551B2 (ja) 2020-12-02
MX2019007557A (es) 2019-09-06
CN107392611A (zh) 2017-11-24
BR112019012905A2 (pt) 2019-12-03
CN111612468B (zh) 2024-03-19
JP2020516973A (ja) 2020-06-11
AU2018240159B2 (en) 2021-02-04
TW201835831A (zh) 2018-10-01
CA3047884C (en) 2021-01-19
PH12019501470A1 (en) 2020-02-24
CA3047884A1 (en) 2018-09-27
ZA201904053B (en) 2021-01-27
KR102151899B1 (ko) 2020-09-03
RU2735156C1 (ru) 2020-10-28
EP3543937A1 (en) 2019-09-25
EP3543937A4 (en) 2019-12-04
SG10202107139RA (en) 2021-08-30
KR20190086747A (ko) 2019-07-23
TWI727120B (zh) 2021-05-11
CN111612468A (zh) 2020-09-01
CN107392611B (zh) 2020-04-24
US20190347663A1 (en) 2019-11-14
US10679217B2 (en) 2020-06-09
AU2018240159A1 (en) 2019-07-11

Similar Documents

Publication Publication Date Title
WO2018171545A1 (zh) 一种发送交易信息和共识验证的方法及装置
WO2018161901A1 (zh) 一种共识方法及装置
WO2018171543A1 (zh) 一种广播消息的方法及装置
JP6876806B2 (ja) ブロックチェーンコンセンサス形成の方法およびデバイス
WO2018219283A1 (zh) 一种区块链共识方法及设备
JP2020508594A (ja) サービス処理およびコンセンサスの方法およびデバイス
KR102050006B1 (ko) 서비스 실행 방법 및 장치
WO2018177255A1 (zh) 一种基于区块链的共识方法及装置
KR20190067195A (ko) 블록체인 데이터 처리 방법 및 장치
WO2019034039A1 (zh) 一种目标图形码识别方法和装置
WO2019141108A1 (zh) 基于扫描doi的信息处理方法、装置及设备
WO2020168933A1 (zh) 一种网络请求的处理方法、装置、终端及存储介质
US11321125B2 (en) Task priority processing method and processing device
CN104426624B (zh) 一种图像同步显示方法及装置
CN112445597B (zh) 定时任务调度方法和装置
WO2019019957A1 (zh) 一种发送电子券的方法及装置
Park et al. Improve Scouter APM notification function and Develop automatic performance summary report generation module
CN116010106A (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: 18770722

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3047884

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2019534718

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197018216

Country of ref document: KR

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019012905

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2018770722

Country of ref document: EP

Effective date: 20190619

ENP Entry into the national phase

Ref document number: 2018240159

Country of ref document: AU

Date of ref document: 20180319

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 112019012905

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20190621