WO2018177239A1 - 一种业务受理及共识的方法及装置 - Google Patents

一种业务受理及共识的方法及装置 Download PDF

Info

Publication number
WO2018177239A1
WO2018177239A1 PCT/CN2018/080461 CN2018080461W WO2018177239A1 WO 2018177239 A1 WO2018177239 A1 WO 2018177239A1 CN 2018080461 W CN2018080461 W CN 2018080461W WO 2018177239 A1 WO2018177239 A1 WO 2018177239A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain node
service
server
service request
consensus
Prior art date
Application number
PCT/CN2018/080461
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 JP2019535947A priority Critical patent/JP6773912B2/ja
Priority to EP18775664.8A priority patent/EP3547648B1/en
Priority to CA3048737A priority patent/CA3048737C/en
Priority to MYPI2019003674A priority patent/MY194387A/en
Application filed by 阿里巴巴集团控股有限公司, 李奕 filed Critical 阿里巴巴集团控股有限公司
Priority to KR1020197018692A priority patent/KR102152556B1/ko
Priority to MX2019007812A priority patent/MX2019007812A/es
Priority to AU2018243075A priority patent/AU2018243075B2/en
Priority to RU2019119888A priority patent/RU2735096C1/ru
Priority to BR112019013204-0A priority patent/BR112019013204B1/pt
Publication of WO2018177239A1 publication Critical patent/WO2018177239A1/zh
Priority to ZA2019/04230A priority patent/ZA201904230B/en
Priority to PH12019501538A priority patent/PH12019501538B1/en
Priority to US16/516,483 priority patent/US10681175B2/en
Priority to US16/882,057 priority patent/US11057493B2/en
Priority to US17/367,137 priority patent/US11943317B2/en

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
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • 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
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1063—Discovery through centralising entities
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates

Definitions

  • the present application relates to the field of computer technology, and in particular, to a method and apparatus for service acceptance and consensus.
  • the blockchain node receives the service request sent by the user, and stores the service request in the service memory of the blockchain node, and at the same time, the blockchain node broadcasts the service request to the consensus.
  • Other blockchain nodes in the network so that other blockchain nodes store the service request in their corresponding service memory after receiving the service request.
  • the blockchain node In the process of business consensus, the blockchain node will retrieve a certain number of service requests from its corresponding service memory, and process the retrieved service requests to obtain a pre-processing block. Then, the blockchain node broadcasts the pre-processing block to other blockchain nodes in the consensus network, so that other blockchain nodes perform service consensus on the pre-processing block after receiving the pre-processing block.
  • the processing of the blockchain service requires the close cooperation of the blockchain nodes in the consensus network to be effectively completed.
  • the blockchain node is usually restricted by a single server, so the stability is relatively low. Once the server is abnormal, the program restarts, etc., the blockchain node is unavailable, which affects The stability in the entire consensus network has an impact on the processing of the blockchain business. Not only that, the software and hardware resources of a single server are very limited, which leads to the inefficiency of blockchain nodes for business processing.
  • the embodiment of the present invention provides a method for service acceptance, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service acceptance, including:
  • the first blockchain node receives a service request sent by the client by using a server included in the first blockchain node, where the first blockchain node includes multiple servers and at least one service memory;
  • the second blockchain node includes a plurality of servers and at least one service memory.
  • the embodiment of the present application provides a service acceptance device, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides an apparatus for service acceptance, including:
  • Receiving a module receiving a service request sent by the client
  • a storage module where the service request is stored in a corresponding service storage
  • the sending module And sending, by the sending module, the service request to each second blockchain node in the consensus network, so that after the second blockchain node receives the service request, storing the service request in its own In the service memory, the second blockchain node includes a plurality of servers and at least one service memory.
  • the embodiment of the present invention provides a method for service acceptance, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service acceptance, including:
  • the second blockchain node receives a service request sent by the first blockchain node by using a server included in the second blockchain node, where the second blockchain node includes multiple servers and at least one service memory, the first blockchain The node includes multiple servers and at least one business memory;
  • the service request is stored in a business memory contained in itself.
  • the embodiment of the present invention provides a service acceptance device, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides an apparatus for service acceptance, including:
  • Receiving a request module receiving a service request sent by the first blockchain node, where the first blockchain node includes multiple servers and at least one service memory;
  • the storage module is requested to store the service request in its corresponding business storage.
  • the embodiment of the present invention provides a method for service acceptance, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service acceptance, including:
  • the client receives the business information input by the user;
  • the second blockchain node includes a plurality of servers and at least one service memory
  • the first blockchain node includes a plurality of Servers and at least one business store.
  • the embodiment of the present application provides a service acceptance device, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides an apparatus for service acceptance, including:
  • the request generation module generates a corresponding service request according to the service information
  • the sending module And sending, by the sending module, the service request to a server included in the first blockchain node, so that the first blockchain node stores the received service request in a service included in the first blockchain node And storing, in the memory, the service request to each second block chain node in the consensus network, the second block chain node includes a plurality of servers and at least one service memory, the first block chain node Contains multiple servers and at least one business storage.
  • the embodiment of the present invention provides a method for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service consensus, including:
  • the first blockchain node selects a server from a plurality of servers included in the first blockchain node, the first blockchain node includes a plurality of servers and at least one service memory;
  • the at least one service request is packaged into a pre-processing block by the selected server, and the pre-processing block is sent to each second block chain node in the consensus network, so that the second block chain nodes are Performing a service consensus on the pre-processing block, the second block chain node includes a plurality of servers and at least one service memory.
  • the embodiment of the present invention provides a device for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • An embodiment of the present application provides a device for service consensus, including:
  • the at least one service request is packaged into a pre-processing block, and the pre-processing block is sent to each second blockchain node in the consensus network, so that the second block chain node is opposite
  • the pre-processing block performs service consensus
  • the second blockchain node includes a plurality of servers and at least one service memory.
  • the embodiment of the present invention provides a device for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • An embodiment of the present application provides a device for service consensus, including:
  • the selection module selects a server from a plurality of servers included in the first blockchain node, the first blockchain node includes a plurality of servers and at least one service storage.
  • the embodiment of the present invention provides a method for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service consensus, including:
  • the blockchain node obtains a pre-processing block by a first server included in itself, the block chain node comprising a plurality of servers and at least one service memory;
  • the service consensus is performed on the pre-processing block by the first server according to each service request stored in the service storage included in the service.
  • the embodiment of the present invention provides a device for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • An embodiment of the present application provides a device for service consensus, including:
  • the consensus module performs business consensus on the pre-processing block according to each service request stored in the corresponding service memory.
  • the embodiment of the present invention provides a method for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • the embodiment of the present application provides a method for service consensus, including:
  • the registration center obtains addresses of a plurality of servers included in the blockchain node, and each blockchain node includes multiple servers and at least one service memory;
  • the obtained addresses of the plurality of servers included in the blockchain node are sent to other blockchain nodes in the consensus network and the client storage.
  • the embodiment of the present invention provides a device for service consensus, which is used to solve the problem that the blockchain node in the prior art has poor stability and low service processing efficiency when performing service processing.
  • An embodiment of the present application provides a device for service consensus, including:
  • An obtaining module for each blockchain node in the consensus network, obtaining addresses of a plurality of servers included in the blockchain node, each blockchain node comprising multiple servers and at least one service memory;
  • the sending module sends the obtained addresses of the plurality of servers included in the blockchain node to other blockchain nodes in the consensus network and the client storage.
  • the first blockchain node includes multiple servers, and the first blockchain node can receive and store the service request sent from the client through a server included, and Extracting at least one service request from the service memory included in the first blockchain node, obtaining a pre-processing block, and sending the pre-processing block to each second block chain node of the consensus network by using at least one service request server to The pre-processing block is subjected to service consensus through each second block chain node. Since in the plurality of servers included in the first blockchain node, as long as one server is available, the first blockchain node can be guaranteed to be available, thereby greatly improving the first blockchain node in the consensus network. stability. Moreover, since each server included in the first blockchain node can receive the service request sent by the user through the client, and each server can initiate a business consensus to each second blockchain node in the consensus network, Thereby greatly improving the business processing efficiency of the blockchain business.
  • FIG. 1 is a schematic diagram of a process of service consensus provided by an embodiment of the present application
  • FIG. 2 is a schematic diagram of a registration center pushing an address to a client according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of a registration center pushing an address of each server in a second blockchain node to each server in a first blockchain node according to an embodiment of the present disclosure
  • FIG. 4 is a schematic diagram of determining, by a server, a feature value to be verified according to an embodiment of the present disclosure
  • FIG. 5 is a schematic diagram of a process for a server to perform service consensus on a pre-processing block in a second blockchain node according to an embodiment of the present disclosure
  • FIG. 6 is a schematic diagram of an apparatus for service acceptance according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an apparatus for service acceptance according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of an apparatus for service acceptance according to an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a device for service consensus according to an embodiment of the present application.
  • FIG. 10 is a schematic diagram of an apparatus for service consensus according to an embodiment of the present application.
  • FIG. 11 is a schematic diagram of an apparatus for service consensus according to an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a device for service consensus according to an embodiment of the present application.
  • FIG. 1 is a schematic diagram of a process of a service consensus according to an embodiment of the present disclosure, which specifically includes the following steps:
  • the first blockchain node receives a service request sent by the client by using a server of the multiple servers included in the first blockchain node.
  • the user may send a service request to the first blockchain node through the client during the process of performing the service processing, where the client mentioned here may be installed in the terminal held by the user.
  • the user can start the client in the terminal, and input the service information in the interface displayed by the client to the user.
  • the client After receiving the service information input by the user, the client can select the stored business logic according to the pre-selection in the client. A corresponding service request is generated, and the service request is sent to the first blockchain node by the terminal.
  • the user may directly input corresponding service information in the terminal, and the terminal may generate a corresponding service request according to the service information input by the user, and send the service request to the first blockchain.
  • the terminal may generate a corresponding service request according to the service information input by the user, and send the service request to the first blockchain.
  • the node In the node.
  • the first blockchain node includes multiple servers (in other words, the first blockchain node includes a server cluster, and the server cluster is equivalent to the first blockchain node. And, each server shares node configuration information such as point-to-point routing table, node asymmetric public private key, node identity number (Identity, ID), etc., so for other blockchain nodes and clients in the consensus network It is said that the operations performed by the servers in the first blockchain node are regarded as being from the first blockchain node itself.
  • a registration center is provided in the embodiment of the present application.
  • the registration center is configured to manage the addresses of the servers in the blockchain node, and push the addresses of the servers to the client.
  • the client can randomly select an address from the address pushed by the registration center, and send the service request. To the server corresponding to the address, as shown in Figure 2.
  • FIG. 2 is a schematic diagram of a registration center pushing an address to a client according to an embodiment of the present application.
  • the first blockchain node includes a plurality of servers, and each server is registered at the registration center when the server is online (the online line mentioned here means that the server starts normal business acceptance), in other words, That is, to notify the registration center that the server is currently available, and can receive the service request sent by the client.
  • the registration center can obtain the address of the server, and then push the address to the client, so that the client stores the address after receiving the address.
  • the registration center may actively obtain the address of the server from the server, or the server may provide the address to the registration center. For example, after the server registers in the registration center, the registration center may send the server to the server. Returning the message of successful registration, after receiving the message, the server can actively send its own address to the registration center, so that the registration center manages the address.
  • the registration center can also actively obtain the addresses managed in the registration center.
  • the client may send an inquiry message for obtaining an address to the registration center in addition to sending a service request to the first blockchain node, and after receiving the inquiry message, the registration center may use the server currently available to the first blockchain node (That is, the address of the server currently registered in the registration center is sent to the client, so that after receiving the addresses sent by the registration center, the client selects an address from each address and sends the service request to the selection.
  • the address corresponds to the server.
  • the client can also obtain the addresses of the servers included in the first blockchain node from the registration center by other means, and the examples are not illustrated here.
  • the server in the first blockchain node may have such problems as running faults, program restarts, etc., causing the server to go offline (that is, the server cannot perform business acceptance), and if the registration center is to be down, The address of the line server is sent to the client, and the client selects the address of the offline server when selecting the server, which may cause the client to fail to send the service request to the first blockchain node, thereby causing the first A blockchain node cannot process the service request.
  • the registration center can send a heartbeat detection message to the server every set time, when the server is still running normally online.
  • the response message can be returned to the registration center according to the received heartbeat detection message.
  • the registration center can determine that the server is still running normally online, and then continue to manage the address of the server.
  • the registration center After the registration center sends the heartbeat detection message to the server, it is determined that the server has not received the response message returned by the server according to the heartbeat detection message after the set time has elapsed, and then it may be determined that the server may currently have an operation failure such as an operation failure.
  • the program restarts, etc., causing the server to go offline, and then no longer pushes the address of the server to the client, and if the address of the server has been pushed to the client before, the server can be sent offline to the client. Notification to cause the client to delete the server's address from the local based on the notification.
  • the service request will not be sent to the server until the server is back online, and the client re-acquires the address of the server from the registry, and then passes the address to The server sends a service request.
  • the second blockchain node in the consensus network can also receive the service request sent by the client, and process the service request. Therefore, in the embodiment of the present application, each of the consensus networks is used.
  • a second block chain node each server included in the second block chain node can also be registered in the registration center, so that the registration center can push the address of each server included in the second block chain node to the client In the end. In this way, the client can also send a service request to the server in the second blockchain node by using the obtained address.
  • S102 The service request is stored by the server in a service memory included in the first blockchain node, and the service request is sent to each second blockchain node in the consensus network, so that After receiving the service request, each second blockchain node stores the service request in a service memory included in itself.
  • the server included in the first blockchain node may store the service request in the service storage included in the first blockchain node, and at the same time, the server may be the client.
  • the sent service request is sent to each second blockchain node in the consensus network, so that after receiving the service request, the second blockchain node stores the service request in its own service memory.
  • the server in the first block chain node may perform legal verification on the service request.
  • the legal verification may be an asymmetric signature legal verification such as an RSA algorithm, or may be other forms. verification.
  • the service request may be stored in a service memory included in the first blockchain node, and the service request is sent to each second blockchain in the consensus network.
  • the server determines that the service request does not pass the legal verification, the service request is not stored, and the message that the service request acceptance failure is returned to the client, so that after the user views the message through the client,
  • the service request may be re-edited in the client, and the edited service request is sent to the server included in the first blockchain node through the client.
  • each blockchain node in the consensus network may include multiple servers, when the server in the first blockchain node sends the service request to the second blockchain node, the same It is also necessary to obtain the address of each server in the second blockchain node, and then send the service request to the server included in the second blockchain node by the obtained address.
  • the registration center also needs to manage the addresses of the servers in the second blockchain node, and send the addresses of the servers in the second blockchain node to the first blockchain node.
  • Each server is shown in Figure 3.
  • FIG. 3 is a schematic diagram of a registration center pushing an address of each server in a second blockchain node to each server in a first blockchain node according to an embodiment of the present application.
  • the registration can also be performed in the registration center, so that the registration center obtains the address of each server in the second blockchain node, wherein the registration center can Automatically obtaining an address from each server in the second blockchain node, and each server in the second blockchain node may actively send the respective address to the registration center.
  • the registration center obtains the first address.
  • the addresses of the servers in the blockchain node are the same, and will not be described in detail here.
  • each server in the first blockchain node After each server in the first blockchain node obtains the address of each server in the second blockchain node through the registration center, the obtained address can be stored.
  • the server in the first block chain node sends a service request to the second block chain node, an address may be selected from each address included in the second block chain node saved by itself, and then the service request is sent to the address.
  • the service request is stored in the service memory corresponding to the second blockchain node.
  • the server in the second block chain node may also perform legal verification on the service request.
  • the service request may be stored in the second area.
  • the block chain node is included in the service memory, and when the server determines that the service request does not pass the legal verification, the service request is not stored.
  • the registration center obtains the address of each server in the second blockchain node. After that, a heartbeat detection message may be sent to the server corresponding to the address every time a set time interval elapses, and after the set time elapses (or within the set time), the response message returned by the server according to the heartbeat detection message is received. At the same time, it can be determined that the server is still in the online state, and then the management of the address of the server is continued, and after the set time has elapsed, the response message returned by the server according to the heartbeat detection message is not received, then it can be determined.
  • the server may be in a situation such as a running failure, a network instability, etc., causing the server to go offline.
  • the address of the server may no longer be managed until the server is re-routed and the address of the server is re-acquired and managed.
  • the server may send a notification of the server offline to each server and the client in the first blockchain node.
  • each server and the client in the first block chain node delete the address of the server, and then no longer send a service request to the server of the address in the subsequent process until the server is back online.
  • the address can be obtained, and a service request is sent to the server corresponding to the address.
  • the entire consensus network includes multiple blockchain nodes
  • the first blockchain node mentioned in the embodiment of the present application refers to a blockchain that receives client service requests.
  • the node, and the other block chain nodes except the first block chain node may be referred to as a second block chain node in the embodiment of the present application
  • the first block chain node and the second block chain node are one a relative concept, that is, a blockchain node that receives a service request from a client may be referred to as a first blockchain node, and a blockchain node that receives the service request sent by the first blockchain node may be referred to as Is the second block chain node.
  • each blockchain node in the consensus network can request a service sent by the client
  • each blockchain node can be substantially the first blockchain node or the second blockchain node, and the first zone The division of the block chain node and the second block chain node depends on where the service request is received.
  • the division of the first blockchain node and the second blockchain node can also be distinguished by which node initiates a consensus check, that is, a pre-processing block that contains at least one service request.
  • the consensus check initiator sent to the consensus network may be the first block chain node, and the block chain node receiving the pre-processing block may be referred to as the second block chain node.
  • S103 In a service consensus phase, selecting a server from a plurality of servers included in the first blockchain node, and extracting at least one service from a service storage included in the first blockchain node by using the selected server request.
  • the server in the first blockchain node needs to perform service consensus on the service request in the service memory included in the first blockchain node. Therefore, in the service consensus phase, the first blockchain node The server in the server may extract at least one service request from the service storage included in the first blockchain node, and in the subsequent process, package the retrieved service requests into a pre-processing block and send to each second block in the consensus network. Chain nodes conduct business consensus.
  • the first blockchain node includes a plurality of servers and service memories, and includes a timing task trigger, and the timing task trigger is used to periodically pass through the first blockchain node.
  • the server initiates a business consensus to each blockchain node in the consensus network, and since the first blockchain node contains multiple servers, in the business consensus phase, the timing task trigger can be from the first blockchain node One of the plurality of included servers is selected, and the server further extracts at least one service request from the service storage included in the first blockchain node.
  • the timing task trigger may be a hardware device or may exist in the form of software, wherein, for the form of the software, the timing task trigger may be set in the first block chain node.
  • a server when the scheduled task trigger is running in the server, a server may be selected from each server included in the first blockchain node in the business consensus phase, and the server where the scheduled task trigger is located Sending a notification to the selected server, so that the selected server, after receiving the notification, retrieves at least one request from the service memory included in the first blockchain node.
  • the service request may be fetched in the time sequence stored in the service memory according to each service request, or may be requested according to each service request.
  • the type of business is used for fishing, or it is based on the business level of each business request. There are many ways to fish, and there is no example here.
  • S104 Packet the at least one service request into a pre-processing block by using the selected server, and send the pre-processing block to each second block chain node in the consensus network by using the selected server, so that the Each second block chain node performs business consensus on the pre-processing block.
  • the processed service request may be processed and packaged into a pre-processing block, where the server According to the preset sorting rule, the business requests retrieved may be sorted, the sorting result of each service request is obtained, and the preset feature value determining rule and the sorting result are used to determine that the service request uniquely corresponds to be verified.
  • the feature value, and then the server may package the retrieved service request, the sort result of each service request, and the determined feature value to be verified into a pre-processing block, and then send the pre-processing block to the second blockchain In the server that the node contains.
  • the specific manner in which the server determines the feature value to be verified may be as shown in FIG. 4 .
  • FIG. 4 is a schematic diagram of determining, by a server, a feature value to be verified according to an embodiment of the present disclosure.
  • the server of the first block chain node retrieves from the first blockchain node including the service memory as shown in FIG.
  • the four service requests the server can sort the four service requests according to a preset sorting rule, thereby obtaining the sorting result as shown in FIG.
  • the server may determine a rule according to a preset feature value: a hash algorithm, respectively determining sub-feature values Hash1 to Hash4 corresponding to the four service requests, and determining the determined four sub-feature values according to the obtained sorting result. From left to right, it is placed in the leaf node of the Merkle tree, and then the root node value Hash7 of the Merkle tree is determined.
  • the server may determine the determined Merkle tree root node value Hash7 as the unique corresponding to-be-verified feature value of the four service requests, and then package the determined feature value to be verified, the sorting result, and the four service requests into pre-processing. Piece.
  • the manner of determining the feature value to be verified shown in FIG. 4 is not unique.
  • the server in the first block chain node may use the hash as the preset feature value determination rule to determine each service request.
  • an algorithm such as the Message Digest Algorithm (MD5) can be used to determine the unique feature value to be verified for each service request, and only the determined feature to be verified needs to be ensured.
  • MD5 Message Digest Algorithm
  • the value corresponds to each service request.
  • the form of the Merkle tree in addition to the form shown in FIG. 4, other forms may be used, and the examples are not illustrated here.
  • the server of the first blockchain node can determine the unique feature value to be verified corresponding to each service request through the Merkle tree, and can also be determined by other methods, for example, the server determines separately.
  • the determined sub-feature values may be sorted in a certain order, and the sorted result is encrypted again, and the encrypted result is uniquely corresponding to each service request.
  • the server can generate a globally unique ID by using the snowflake algorithm, and the ID is used as the unique corresponding to each service request to be verified.
  • the eigenvalues; or the server may determine a Universally Unique Identifier (UUID) of each sub-feature value according to each sub-feature value corresponding to each service request, and use the UUID as each service. Request a unique corresponding feature value to be verified.
  • UUID Universally Unique Identifier
  • the server in the first block chain node may determine the pre-processing block to send the pre-processing block to the consensus network.
  • each server in the first blockchain node can obtain the address of each server included in each second blockchain node in the consensus network from the registration center, the first blockchain
  • the server of the node needs to send the pre-processing block to a certain second blockchain node in the consensus network
  • the address of each server in the second blockchain node that can be stored by itself is the second An address is selected in the address of the server in the uplink state of the blockchain node, and the pre-processing block is sent to the server corresponding to the address, so that the server corresponding to the address receives the pre-processing block.
  • the pre-processing block is subjected to consensus verification.
  • the server in the first blockchain node sends the pre-processing block to each second blockchain node
  • the above manner may be respectively
  • Each of the stored addresses respectively determines each server of each second block chain node that receives the pre-processed block, and then sends the pre-processed block to each server of each second blockchain node through the determined address. in.
  • the pre-processing block may be parsed and determined.
  • Each service request included in the pre-processing block, a sort result of each service request, and the to-be-verified feature value are obtained, and then the server in the second block chain node can be searched from the service memory included in the second block chain node.
  • the determined feature value may be compared with the to-be-verified feature value included in the pre-processing block, and when it is determined that the two are consistent, the server may determine the
  • the pre-processing block passes the consensus check of the local (ie, the server of the second block chain node), and then stores the check result in the service memory included in the second block chain node, and sends the check result To other blockchain nodes in the consensus network (other blockchain nodes mentioned herein include each second blockchain node and the first blockchain node).
  • the manner in which the server in the second block chain node sends the check result is the same as the manner in which the server in the first block chain node sends the service request or the pre-processing block to each second block chain node in the consensus network. That is, when the server of the second block chain node needs to send the verification result to a certain blockchain node in the consensus network (may be the second blockchain node may also be the first blockchain node)
  • the server may select an address from the addresses of the servers in the locally stored blockchain node, and send the check result to the server corresponding to the address. After receiving the verification result, the server corresponding to the address may store the verification result in the service memory included in the blockchain node.
  • the server in the second blockchain node sends the verification result to each blockchain node in the consensus network, and other servers in the second blockchain node or the server can also receive other nodes in the consensus network.
  • the check result sent by the block chain node about the pre-processing block, and the received check result is uniformly stored in the service memory included in the second block chain node.
  • the server in the second blockchain node may determine, from the service memory included in the second blockchain node, each blockchain node in the consensus network about the pre-processing
  • the check result of the block (including the check result made by itself) determines a comprehensive check result of each block chain node in the consensus network about the pre-process block, and then the server can pass the same check result as the above
  • the determined comprehensive verification result is sent to each blockchain node in the consensus network, and at the same time, the comprehensive verification result is stored in the service memory included in the second blockchain node.
  • a block check node (including each second block chain node and the first block chain node) sends a comprehensive check result about the pre-processing block, and stores the comprehensive check result in the second block chain node. In the business memory.
  • the server in the second blockchain node may obtain the comprehensive verification result sent by other blockchain nodes in the consensus network from the service memory included in the second blockchain node. And determining, by the received comprehensive verification result and the comprehensive verification result determined by itself, whether the pre-processing block passes the service consensus of the consensus network, and if it is determined according to each comprehensive verification result stored in the service memory (including itself) Determining the service consensus of each service request included in the pre-processing block through the consensus network, and writing each service request included in the pre-processing block to the blockchain saved by the second block chain node Otherwise, each service request is not written into the blockchain, wherein the server in the second block chain node can write the complete content of each service request into the blockchain, or only each service The requested message digest is written to the blockchain.
  • FIG. 5 is a schematic diagram of a process for a server to perform service consensus on a pre-processing block in a second blockchain node according to an embodiment of the present disclosure.
  • the server #3 in the first block chain node extracts at least one service request from the service memory included in the first block chain node, and packages the at least one service request into a pre-processing block and sends the message to the other two blockchains.
  • the server A1 and the server B1 may perform consensus verification on the pre-processing block, and store the obtained verification result for the pre-processing block in the service included in the blockchain node. In memory.
  • the server A1 and the server B1 can respectively send the determined verification result to the other two blockchain nodes in the consensus network, wherein the server A1 is based on each of the other two blockchain nodes stored by itself.
  • the address determines that the verification result obtained by itself is sent to the server #2 in the first block chain node and the server B2 in the second block chain node B, and the server B1 determines the verification obtained by itself.
  • the result is sent to the server #3 of the first block chain node and the server A3 of the second block chain node A.
  • the received verification results may be stored in the blockchain node. Included in the business memory.
  • the server A1 ie, the server receiving the pre-processing block
  • a comprehensive verification result of each blockchain node in the consensus network for the pre-processing block is obtained.
  • the server A1 may store the obtained comprehensive verification result in the service memory included in the second blockchain node A, and send the comprehensive verification result to the other two blockchain nodes, and send the manner The way to send the verification result is the same, and will not be described in detail here.
  • a comprehensive verification result for the pre-processing block can also be determined in this way, and will be obtained.
  • the resulting comprehensive verification result is sent to the other two blockchain nodes in the consensus network.
  • each server of each blockchain node in the consensus network may store the received comprehensive verification result in the service memory included in the own blockchain node.
  • the server A1 may obtain the comprehensive verification result (including the comprehensive verification result made by itself) sent by each blockchain node from the service memory included in the second blockchain node A, and then the server A1 may Determining, according to the comprehensive verification result, whether the pre-processing block passes the service consensus in the consensus network, and if yes, writing the service request included in the pre-processing block to the blockchain of the second blockchain node A If no, the service request is not written into the blockchain.
  • the server #3 and the server B1 can also obtain the comprehensive verification results from the service memories included in the blockchain nodes to which they belong, and determine according to the obtained comprehensive verification results. Whether to write each service request contained in the pre-processing block to the blockchain of the blockchain node to which it belongs.
  • each blockchain node in the consensus network includes multiple servers, for each blockchain node, as long as one of the servers in the blockchain node is in an online state, That is, the blockchain node is a usable blockchain node in the consensus network, thereby greatly improving the stability of the blockchain node in the consensus network.
  • each server since each block chain node contains multiple servers, each server has the same function and status for the block chain node. In other words, the block chain node is in the prior art. On the basis of this, the server with the same status is added, which greatly improves the performance of the blockchain node, thereby improving the service processing efficiency of the blockchain node.
  • each blockchain node in the consensus network can determine its own verification result for the pre-processing block, and send the obtained verification result to the consensus network.
  • the other blockchain node stores the check result in the service memory corresponding to the block chain node, wherein the block chain node can perform consensus verification on the pre-process block by using the first server included in the block chain node.
  • the first server may be a designated server in the blockchain node, or may be a server selected from each server included in the blockchain node.
  • the blockchain node will also receive the verification result sent by the other blockchain nodes in the consensus network for the pre-processing block, wherein the blockchain node can receive other servers through the server it contains.
  • the verification result sent by the blockchain node, and the received verification result is stored in the service memory corresponding to the blockchain node, where the server that receives the verification result sent by the other blockchain node can be received.
  • the second server may be any one of the blockchain nodes, and may of course be the first server described above, and which second server is used to receive the other blockchain nodes.
  • the result of the check depends on which server included in the other blockchain node selects which second server receives the check result sent by it.
  • the client in addition to randomly selecting an address from the addresses of the servers in the stored first blockchain node, the client may also select an address according to the load balancing condition.
  • the registration center pushes the client to the client.
  • the load condition of each server is pushed to the client together, so that the client selects a load from each address through a preset load balancing algorithm.
  • the address of the server, and the above service request is sent to the server corresponding to the address.
  • load balancing can also be adopted, and the server is selected from the stored addresses, of course,
  • the server of a block chain node sends the pre-processing block, and each block chain node in the consensus network can also perform load balancing mode when transmitting the verification result and the comprehensive verification result, and the specific process client is load balanced.
  • the way to send a service request to the first blockchain node is the same, and will not be described in detail here.
  • the server in the blockchain node in addition to the task timing trigger can be used to select the server that initiates the service consensus, the server in the blockchain node (including the first blockchain node and the second blockchain node) A consensus period is set, and the consensus periods of different servers are different.
  • the server monitors that the current time reaches its own consensus period at least one service request can be extracted from the service memory of the blockchain node.
  • the server in the blockchain node may also forward the service request to the blockchain node.
  • the service request is stored by the other server in the service memory included in the blockchain node.
  • the server in the second blockchain node may also receive the pre-processing block after receiving the pre-processing block sent by the first blockchain node. Forwarding to other servers in the second blockchain node for consensus verification, and storing the obtained verification result in the service memory included in the second blockchain node.
  • the embodiment of the present application further provides the following devices for service acceptance and devices for service consensus, as shown in FIGS. 6-12.
  • FIG. 6 is a schematic diagram of a device for service acceptance according to an embodiment of the present disclosure, specifically including:
  • the receiving module 601 receives a service request sent by the client.
  • the storage module 602 is configured to store the service request in its corresponding service storage.
  • the sending module 603 sends the service request to each second blockchain node in the consensus network, so that after the second blockchain node receives the service request, the service request is stored in the service request.
  • the second blockchain node includes a plurality of servers and at least one service memory.
  • the device also includes:
  • the registration module 604 when it is determined that the device is online, sends the address of the device to the registration center, so that the registration center sends the address to the client and each second blockchain node in the consensus network. .
  • the device also includes:
  • the sending module 603, for each second blockchain node selects an address from the acquired addresses of the plurality of servers included in the second blockchain node; and sends the service request to the selected address. In the server.
  • the storage module 602 performs legal verification on the service request. When it is determined that the service request passes the legal verification, the service request is stored in the service storage.
  • the storage module 602 does not store the service request when it is determined that the service request does not pass the legal verification.
  • a plurality of said devices are included in a blockchain node.
  • FIG. 7 is a schematic diagram of a device for service acceptance according to an embodiment of the present disclosure, which specifically includes:
  • the receiving request module 701 receives a service request sent by the first blockchain node, where the first blockchain node includes multiple servers and at least one service memory;
  • the request storage module 702 stores the service request in its own corresponding service memory.
  • the device also includes:
  • the request storage module 702 performs legal verification on the service request. When it is determined that the service request passes the legal verification, the service request is stored in the service storage.
  • the request storage module 702 does not store the service request when it is determined that the service request does not pass the legal verification.
  • FIG. 8 is a schematic diagram of a device for service acceptance according to an embodiment of the present disclosure, which specifically includes:
  • Receiving information module 801 receiving service information input by a user
  • the request generating module 802 generates a corresponding service request according to the service information
  • the sending module 803 is configured to send the service request to a server included in the first blockchain node, so that the first blockchain node stores the received service request in a first blockchain node. And in the service memory, sending the service request to each second blockchain node in the consensus network, where the first blockchain node includes multiple servers and at least one service memory, and the second blockchain A node contains multiple servers and at least one business store.
  • the sending module 803 acquires, from the registration center, an address of the plurality of servers included in the first blockchain node, and selects an address from the acquired addresses of the plurality of servers included in the first blockchain node, and Sending the service request to the server corresponding to the selected address.
  • the device also includes:
  • the deleting module 804 deletes the address of the server when receiving the offline notification sent by the registration center for a certain server.
  • FIG. 9 is a schematic diagram of a device for service consensus according to an embodiment of the present disclosure, which specifically includes:
  • the sending module 902 the at least one service request is packaged into a pre-processing block, and the pre-processing block is sent to each second block chain node in the consensus network, so that the second block chain node pair
  • the pre-processing block performs a service consensus
  • the second blockchain node includes a plurality of servers and at least one service memory.
  • the device also includes:
  • the obtaining address module 903 is configured, for each second blockchain node, the address of the plurality of servers included in the second blockchain node from the registration center.
  • the sending module 902 for each second blockchain node, selects an address from the acquired addresses of the plurality of servers included in the second blockchain node; and sends the pre-processed block to the selected address In the corresponding server, the server corresponding to the selected address performs service consensus on the received pre-processed block.
  • FIG. 10 is a schematic diagram of a device for service consensus according to an embodiment of the present disclosure, which specifically includes:
  • the selecting module 1001 selects a server from a plurality of servers included in the first blockchain node, where the first blockchain node includes multiple servers and at least one service memory.
  • the selecting module 1001 monitors whether the current time meets the task triggering condition; when it is detected that the task triggering condition is met, the server is selected from the plurality of servers included in the first blockchain node.
  • FIG. 11 is a schematic diagram of a device for service consensus according to an embodiment of the present disclosure, which specifically includes:
  • the consensus module 1102 performs a service consensus on the pre-processing block according to each service request stored in the corresponding service memory.
  • the consensus module 1102 performs consensus verification on the pre-processing block to obtain a verification result; receives each verification result sent by another blockchain node in the consensus network, and stores the received verification result in itself. Corresponding service storage; obtaining each verification result from the service storage, and performing service consensus on the pre-processing block by using the obtained verification results.
  • FIG. 12 is a schematic diagram of a device for service consensus according to an embodiment of the present disclosure, which specifically includes:
  • the obtaining module 1201 is configured to obtain, for each blockchain node in the consensus network, an address of multiple servers included in the blockchain node, where each blockchain node includes multiple servers and at least one service memory;
  • the sending module 1202 sends the acquired addresses of the multiple servers included in the blockchain node to other blockchain nodes in the consensus network and the client storage.
  • the device also includes:
  • the embodiment of the present application provides a method and a device for service consensus, where the first blockchain node includes multiple servers, and the first blockchain node can receive the service sent from the client through multiple servers included. Requesting and storing, and extracting at least one service request from a service memory included in the first blockchain node by a server in a plurality of servers, obtaining a pre-processing block, and transmitting the pre-processing block to each of the consensus networks through the server In the second blockchain node, a service consensus is performed on the pre-processing block by each second blockchain node. Since in the plurality of servers included in the first blockchain node, as long as one server is available, the first blockchain node can be guaranteed to be available, thereby greatly improving the first blockchain node in the consensus network. stability. Moreover, since each server included in the first blockchain node can receive the service request sent by the user through the client, and each server can initiate a business consensus to each second blockchain node in the consensus network, Thereby greatly improving the business processing efficiency of the blockchain business.
  • 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 includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information 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.

Abstract

本申请实施例公开一种业务受理及共识的方法及装置，该方法中第一区块链节点中包含有多个服务器，第一区块链节点可通过包含的多个服务器接收从客户端发送的业务请求并存储，以及通过多个服务器中的服务器从该第一区块链节点包含的业务存储器中捞取至少一个业务请求，得到预处理块，并将预处理块通过该服务器发送至共识网络的各第二区块链节点中，以通过各第二区块链节点对该预处理块进行业务共识。由于在第一区块链节点包含的多个服务器中，只要有一个服务器可用，即能保证该第一区块链节点可用，从而提高了第一区块链节点在共识网络中的稳定性。

Description

一种业务受理及共识的方法及装置 技术领域
本申请涉及计算机技术领域，尤其涉及一种业务受理及共识的方法及装置。
背景技术
随机计算机技术的不断发展，区块链技术的应用范围得到了进一步提升，人们除了利用区块链技术实现有效的数据存证外，还为一些业务的实现提供了全新的思路。
当前，通过区块链技术进行业务处理的大致分为两个过程，一个是业务受理过程，一个为业务共识过程。在业务受理过程中，区块链节点接收用户发送的业务请求，并将该业务请求存储在该区块链节点的业务存储器中，与此同时，区块链节点会将该业务请求广播给共识网络中的其他区块链节点，以使其他区块链节点在接收到该业务请求后，将该业务请求存储在自身对应的业务存储器中。
在业务共识过程中，区块链节点将从自身对应的业务存储器中捞取一定数量的业务请求，并将捞取出的业务请求进行一定的处理，得到预处理块。而后，区块链节点将该预处理块广播给共识网络中的其他区块链节点，以使其他的区块链节点在接收到该预处理块后，对该预处理块进行业务共识。
从上述说明的两个过程中可以看出，区块链业务的处理过程需要共识网络中各区块链节点的密切配合才能有效的完成。然而，在实际应用中，区块链节点通常受单一服务器的制约，所以，稳定性相对较低，一旦服务器出现异常、程序重启等现象，则都会导致该区块链节点不可用，从而影响了整个共识网络中的稳定性，给区块链业务的处理过程带来影响。不仅如此，单一服务器的软、硬件资源都十分有限，从而导致了区块链节点进行业务处理时效率较低。
发明内容
本申请实施例提供一种业务受理的方法，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的方法，包括：
第一区块链节点通过自身包含的一个服务器接收客户端发送的业务请求，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
将所述业务请求存储在自身包含的业务存储器中；
将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务受理的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的装置，包括：
接收模块，接收客户端发送的业务请求；
存储模块，将所述业务请求存储在自身对应的业务存储器中；
发送模块，将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务受理的方法，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的方法，包括：
第二区块链节点通过自身包含的一个服务器接收第一区块链节点发送的业务请求，所述第二区块链节点包含有多个服务器以及至少一个业务存储器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
将所述业务请求存储在自身包含的业务存储器中。
本申请实施例提供一种业务受理的装置，用以解决现有技术中区块链节点 在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的装置，包括：
接收请求模块，接收第一区块链节点发送的业务请求，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
请求存储模块，将所述业务请求存储在自身对应的业务存储器中。
本申请实施例提供一种业务受理的方法，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的方法，包括：
客户端接收用户输入的业务信息；
根据所述业务信息，生成相应的业务请求；
将所述业务请求发送至第一区块链节点包含的一个服务器，以使所述第一区块链节点将接收到的所述业务请求存储在第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，所述第二区块链节点包含有多个服务器以及至少一个业务存储器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务受理的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务受理的装置，包括：
接收信息模块，接收用户输入的业务信息；
请求生成模块，根据所述业务信息，生成相应的业务请求；
发送模块，将所述业务请求发送至第一区块链节点包含的一个服务器，以使所述第一区块链节点将接收到的所述业务请求存储在第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，所述第二区块链节点包含有多个服务器以及至少一个业务存储器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务共识的方法，用以解决现有技术中区块链节点 在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的方法，包括：
第一区块链节点从自身包含的多个服务器中选取服务器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
通过选取出的服务器从自身包含的业务存储器中捞取至少一个业务请求；
通过选取出的服务器将所述至少一个业务请求打包成预处理块，并将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务共识的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的装置，包括：
请求捞取模块，从自身对应的业务存储器中捞取至少一个业务请求；
发送模块，将所述至少一个业务请求打包成预处理块，并将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务共识的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的装置，包括：
选取模块，从第一区块链节点包含的多个服务器中选取服务器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器。
本申请实施例提供一种业务共识的方法，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的方法，包括：
区块链节点通过自身包含的第一服务器获取预处理块，所述区块链节点包 含有多个服务器以及至少一个业务存储器；
根据自身包含的业务存储器中存储的各业务请求，通过所述第一服务器对所述预处理块进行业务共识。
本申请实施例提供一种业务共识的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的装置，包括：
获取模块，获取预处理块；
共识模块，根据自身对应的业务存储器中存储的各业务请求，对所述预处理块进行业务共识。
本申请实施例提供一种业务共识的方法，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的方法，包括：
针对共识网络中的每个区块链节点，注册中心获取该区块链节点包含的多个服务器的地址，每个区块链节点包含有多个服务器以及至少一个业务存储器；
将获取到的该区块链节点包含的多个服务器的地址发送至共识网络中其他区块链节点以及客户端存储。
本申请实施例提供一种业务共识的装置，用以解决现有技术中区块链节点在进行业务处理时稳定性较差、业务处理效率较低的问题。
本申请实施例提供了一种业务共识的装置，包括：
获取模块，针对共识网络中的每个区块链节点，获取该区块链节点包含的多个服务器的地址，每个区块链节点包含有多个服务器以及至少一个业务存储器；
发送模块，将获取到的该区块链节点包含的多个服务器的地址发送至共识网络中其他区块链节点以及客户端存储。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：
在本申请实施例中，第一区块链节点中包含有多个服务器，第一区块链节 点可通过包含的一个服务器接收从客户端发送的业务请求并存储，以及通过包含的一个服务器从该第一区块链节点包含的业务存储器中捞取至少一个业务请求，得到预处理块，并将预处理块通过捞取至少一个业务请求服务器发送至共识网络的各第二区块链节点中，以通过各第二区块链节点对该预处理块进行业务共识。由于在第一区块链节点包含的多个服务器中，只要有一个服务器可用，即能保证该第一区块链节点可用，从而极大的提高了第一区块链节点在共识网络中的稳定性。不仅如此，由于第一区块链节点中包含的每个服务器均可接收用户通过客户端发送的业务请求，并且每个服务器均可向共识网络中的各第二区块链节点发起业务共识，从而极大的提高了区块链业务的业务处理效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的业务共识的过程示意图；
图2为本申请实施例提供的注册中心向客户端推送地址的示意图；
图3为本申请实施例提供的注册中心向第一区块链节点中的各服务器推送第二区块链节点中各服务器的地址的示意图；
图4为本申请实施例提供的服务器确定待验证特征值的示意图；
图5为本申请实施例提供的第二区块链节点中的服务器对预处理块进行业务共识的过程示意图；
图6为本申请实施例提供的一种业务受理的装置示意图；
图7为本申请实施例提供的一种业务受理的装置示意图；
图8为本申请实施例提供的一种业务受理的装置示意图；
图9为本申请实施例提供的一种业务共识的装置示意图；
图10为本申请实施例提供的一种业务共识的装置示意图；
图11为本申请实施例提供的一种业务共识的装置示意图；
图12为本申请实施例提供的一种业务共识的装置示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
图1为本申请实施例提供的业务共识的过程示意图，具体包括以下步骤：
S101：第一区块链节点通过所述第一区块链节点包含的多个服务器中的服务器接收客户端发送的业务请求。
在本申请实施例中，用户在进行业务处理的过程中，可通过客户端向第一区块链节点发送业务请求，其中，这里提到的客户端可以是用户所持有的终端中安装的客户端，用户可在终端中启动该客户端，并在客户端向用户展示的界面中输入业务信息，而客户端接收到用户输入的业务信息后，可根据客户端中预选存储的业务逻辑，生成相应的业务请求，进而通过终端将该业务请求发送至第一区块链节点中。
当然，在本申请实施例中，用户也可直接在终端中输入相应的业务信息，而终端则可根据用户输入的业务信息生成相应的业务请求，并将该业务请求发送至第一区块链节点中。
在本申请实施例中，第一区块链节点中包含有多个服务器(换句话说，第一区块链节点中包含有一个服务器集群，该服务器集群就相当于是该第一区块链节点)，且，每个服务器都共享诸如点对点路由表、节点非对称公私钥、节点身份标识号码(Identity，ID)等节点配置信息，所以，对于共识网络中的其他区块链节点以及客户端来说，该第一区块链节点中各服务器所执行的操作均 看作是来自于第一区块链节点本身发出的。
因此，客户端向第一区块链节点发送业务请求时，需要先确定出应该向第一区块链节点中的哪个服务器发送该业务请求，为此，本申请实施例中提供了一个注册中心，该注册中心用于管理区块链节点中各服务器的地址，并将各服务器的地址推送至客户端中，客户端可随机从注册中心推送的地址中选取一个地址，并将该业务请求发送至该地址所对应的服务器中，如图2所示。
图2为本申请实施例提供的注册中心向客户端推送地址的示意图。
在图2中，第一区块链节点中包含有多个服务器，每个服务器在上线时(这里提到的上线是指该服务器开始正常进行业务受理)可向注册中心进行注册，换句话说即为通知注册中心该服务器当前处于可用状态，可以接收客户端发送的业务请求。注册中心在确定该服务器上线后，可获取到该服务器的地址，继而将该地址推送给客户端，以使客户端在接收到该地址后，将该地址进行存储。
其中，在本申请实施例中，注册中心可以主动从该服务器中获取到该服务器的地址，也可由该服务器向注册中心提供该地址，例如，服务器在注册中心进行注册后，注册中心可向服务器返回注册成功的消息，该服务器在接收到该消息后，可主动将自身的地址发送至注册中心中，以使注册中心对该地址进行管理。
而注册中心除了可将获取到的地址主动推送至客户端中外，客户端也可主动获取注册中心中管理的各地址。例如，客户端在向第一区块链节点发送业务请求之外，可向注册中心发送获取地址的询问消息，注册中心接收到询问消息后，可将第一区块链节点当前可用的服务器(即当前在注册中心中注册的服务器)的地址发送给该客户端，以使该客户端在接收到注册中心发送的各地址后，从各地址中选取一个地址，并将该业务请求发送至选取的地址所对应的服务器中。当然，客户端也可通过其他的方式从注册中心中获取第一区块链节点包含的各服务器的地址，在此就不一一进行举例说明了。
需要说明的是，在实际应用中，第一区块链节点中的服务器可能会出现诸 如运行故障、程序重启等情况，导致服务器下线(即该服务器无法进行业务受理)，注册中心若是将下线服务器的地址发送给客户端，且客户端在选择服务器时，恰好选择了下线服务器的地址，则可能会导致客户端无法将上述业务请求发送至第一区块链节点中，进而导致第一区块链节点无法对该业务请求进行处理。
为了避免上述问题的发生，在本申请实施例中，对于已经注册在注册中心的每个服务器来说，注册中心每隔设定时间即可向该服务器发送心跳检测消息，当服务器依然正常运行在线上时，则可根据接收到的心跳检测消息向注册中心返回应答消息，注册中心在接收到该应答消息后，可确定该服务器依然正常的运行在线上，进而继续管理该服务器的地址。
而当注册中心向该服务器发送上述心跳检测消息后，监测到经过设定时间后仍未接收到该服务器根据该心跳检测消息返回的应答消息时，则可确定该服务器当前可能出现了诸如运行故障、程序重启等情况，导致该服务器下线，继而不再向客户端推送该服务器的地址，并且，若之前已经向该客户端推送该服务器的地址，则可向该客户端发送该服务器下线的通知，以使该客户端根据该通知将该服务器的地址从本地中进行删除。
客户端将下线服务器的地址删除后，后续将不再向该服务器发送业务请求，直到该服务器重新上线，客户端才会从注册中心中重新获取到该服务器的地址，继而通过该地址，向该服务器发送业务请求。
需要说明的是，上述图2中仅仅是以客户端从注册中心获取第一区块链节点包含的各地址来进行说明的，在图2中，由于第一区块链节点能够从客户端中接收客户端发送的业务请求，所以，第一区块链节点中的各服务器需要在注册中心进行注册，以使注册中心能够将第一区块链节点中各服务器的地址推送至客户端中，以使客户端能够通过获取到的地址向第一区块链节点中的服务器发送业务请求。
而在实际应用中，由于共识网络中的第二区块链节点同样可以接收客户端 发送的业务请求，并对该业务请求进行处理，所以，在本申请实施例中，针对共识网络中的每个第二区块链节点，该第二区块链节点包含的各服务器同样可在注册中心中进行注册，以使注册中心能够将该第二区块链节点包含的各服务器的地址推送至客户端中。这样一来，客户端同样可通过获取到的地址，向第二区块链节点中的服务器发送业务请求。
S102：通过所述服务器将所述业务请求存储在所述第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中。
第一区块链节点中包含的服务器接收到客户端发送的业务请求后，可将该业务请求存储在第一区块链节点所包含的业务存储器中，与此同时，该服务器可将客户端发送的业务请求发送至共识网络中的各第二区块链节点，以使该第二区块链节点接收到该业务请求后，将该业务请求存储在自身包含的业务存储器中。
其中，第一区块链节点中的服务器在接收到上述业务请求后，可先对该业务请求进行合法验证，该合法验证可以是诸如RSA算法等非对称签名合法验证，也可以是其他形式的验证。当该服务器确定该业务请求通过合法验证时，则可将该业务请求存储在第一区块链节点所包含的业务存储器中，并将该业务请求发送至共识网络中的各第二区块链节点，而当该服务器确定该业务请求未通过合法验证时，则不对该业务请求进行存储，并可向客户端返回该业务请求受理失败的消息，以使用户通过客户端查看到该消息后，执行一定的操作，如，用户查看到该消息后，可在客户端中重新编辑业务请求，并将编辑好的业务请求通过客户端发送至第一区块链节点所包含的服务器中。
在本申请实施例中，由于共识网络中的各区块链节点均可包含有多个服务器，所以，第一区块链节点中的服务器在向第二区块链节点发送上述业务请求时，同样也需要获取第二区块链节点中各服务器的地址，继而通过获取到的地 址，向第二区块链节点包含的服务器发送该业务请求。
所以，在本申请实施例中，注册中心同样需要对第二区块链节点中各服务器的地址进行管理，并将第二区块链节点中各服务器的地址发送至第一区块链节点中的各服务器，如图3所示。
图3为本申请实施例提供的注册中心向第一区块链节点中的各服务器推送第二区块链节点中各服务器的地址的示意图。
在图3中，第二区块链节点中的各服务器上线后，同样可在注册中心中进行注册，以使注册中心获取到第二区块链节点中各服务器的地址，其中，注册中心可自动从第二区块链节点中的各服务器获取地址，也可由第二区块链节点中的各服务器主动向注册中心发送各自的地址，具体的方式与上述步骤S101中，注册中心获取第一区块链节点中各服务器的地址的方式相同，在此就不进行详细赘述了。
第一区块链节点中的各服务器通过注册中心获取到第二区块链节点中各服务器的地址后，可将获取到的地址进行存储。第一区块链节点中的服务器向第二区块链节点发送业务请求时，可从自身保存的第二区块链节点包含的各地址中选取一个地址，进而将该业务请求发送至该地址所对应的服务器中，以使该地址所对应的服务器在接收到该业务请求后，将该业务请求存储在第二区块链节点所对应的业务存储器中。
其中，第二区块链节点中的服务器在接收到上述业务请求后，也可对该业务请求进行合法验证，当确定该业务请求通过合法验证时，则可将该业务请求存储在第二区块链节点包含的业务存储器中，而当该服务器确定该业务请求未通过合法验证时，则不对该业务请求进行存储。
需要说明的是，由于第二区块链节点中包含的服务器也会存在上述步骤S101中提到的服务器下线的情况，所以，注册中心在获取到第二区块链节点中各服务器的地址后，可每经过一个设定时间间隔，向这些地址对应的服务器发送心跳检测消息，当经过设定时间后(也可以是在设定时间内)接收到服务器 根据该心跳检测消息返回的应答消息时，则可确定该服务器仍然处于上线状态，进而继续对该服务器的地址实施管理，而当经过设定时间后，仍未接收到该服务器根据该心跳检测消息返回的应答消息时，则可确定该服务器可能出现了诸如运行故障、网络不稳定等情况致使该服务器下线，则可不再继续对该服务器的地址进行管理，直到该服务器重新上线后重新获取该服务器的地址并管理。
不仅如此，注册中心通过上述方式确定出第二区块链节点中的某一服务器下线时，则可向第一区块链节点中的各服务器以及客户端发送该服务器下线的通知，以使第一区块链节点中的各服务器以及客户端在接收到该通知后，将该服务器的地址进行删除，继而在后续过程中不再向该地址的服务器发送业务请求，直到该服务器重新上线，并从注册中心中重新获取到该服务器的地址后，可通过获取到该地址，向该地址对应的服务器发送业务请求。
图3中只列举出了一个第二区块链节点将其包含的各服务器注册在注册中心中的情况，在实际应用中，共识网络中存在多个第二区块链节点，所以，对于共识网络中的每个第二区块链节点来说，该第二区块链节点中的服务器在上线后，均可注册在注册中心中，以使注册中心获取到该第二区块链节点中各服务器的地址，并将获取到的地址推送至第一区块链节点的各服务器中，换句话说，对于第一区块链节点的每个服务器来说，该服务器将会存储共识网络中每个第二区块链节点所包含的各服务器的地址。
需要说明的是，在实际应用中，整个共识网络中包含有多个区块链节点，而本申请实施例所提到的第一区块链节点指的是接收客户端业务请求的区块链节点，而除第一区块链节点之外其他区块链节点，在本申请实施例中可以称之为第二区块链节点，第一区块链节点和第二区块链节点是一个相对概念，即，从客户端接收业务请求的区块链节点可以称之为第一区块链节点，而接收由第一区块链节点发送的该业务请求的区块链节点则可称之为第二区块链节点。由于共识网络中的各区块链节点均可客户端发送的业务请求，因此，各区块链节点实质上均可以是第一区块链节点，也可以是第二区块链节点，而第一区块链 节点和第二区块链节点的划分取决于业务请求是从何处接收的。
当然，在共识校验过程中，第一区块链节点和第二区块链节点的划分也可以通过哪一节点发起共识校验来区分，即，将包含有至少一个业务请求的预处理块发送至共识网络的共识校验发起者可以是第一区块链节点，而接收该预处理块的区块链节点则可以称之为第二区块链节点。
S103：在业务共识阶段中，从所述第一区块链节点包含的多个服务器中选取服务器，并通过选取出的服务器从所述第一区块链节点包含的业务存储器中捞取至少一个业务请求。
在本申请实施例中，第一区块链节点中的服务器需要将第一区块链节点包含的业务存储器中的业务请求进行业务共识，所以，在业务共识阶段中，第一区块链节点中的服务器可从第一区块链节点包含的业务存储器中捞取至少一个业务请求，并在后续过程中，将捞取的各业务请求打包成预处理块发送至共识网络中的各第二区块链节点进行业务共识。
其中，在本申请实施例中，第一区块链节点除了包含有多个服务器、业务存储器外，还包含有一个定时任务触发器，该定时任务触发器用于定时通过第一区块链节点中的服务器向共识网络中的各区块链节点发起业务共识，而由于第一区块链节点中包含有多个服务器，所以，在业务共识阶段中，定时任务触发器可从第一区块链节点包含的多个服务器中选取一个服务器，进而由该服务器从第一区块链节点包含的业务存储器中捞取至少一个业务请求。
在本申请实施例中，上述定时任务触发器可以是一个硬件设备，也可以是以软件的形式存在，其中，对于软件的形式来说，该定时任务触发器可以设置在第一区块链节点中的某一个服务器中，该定时任务触发器在该服务器中运行时，可在业务共识阶段中从第一区块链节点包含的各服务器中选取一个服务器，并通过定时任务触发器所在的服务器向选取出的服务器发送通知，以使选取出的服务器在接收到该通知后，从第一区块链节点包含的业务存储器中捞取至少一个请求。
服务器上述业务存储器(即第一区块链节点包含的业务存储器)中捞取各业务请求的过程中，可以按照各业务请求在该业务存储器中存储的时间顺序进行捞取，也可按照各业务请求的业务类型进行捞取，抑或是按照各业务请求的业务等级来进行捞取，捞取的方式有很多，在此就不一一举例说明了。
S104：通过选取出的服务器将所述至少一个业务请求打包成预处理块，并通过选取出的服务器将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识。
第一区块链节点中的服务器从第一区块链节点包含的业务存储器中捞取至少一个业务请求后，可将捞取出的各业务请求进行处理，并打包成预处理块，其中，该服务器可按照预设的排序规则，将捞取出的各业务请求进行排序，得到各业务请求的排序结果，并通过预设的特征值确定规则以及该排序结果，确定出各业务请求唯一对应的待验证特征值，而后，该服务器可将捞取出的各业务请求、各业务请求的排序结果以及确定出的待验证特征值打包成一个预处理块，继而将该预处理块发送至第二区块链节点所包含的服务器中。
其中，该服务器确定待验证特征值的具体方式可以如图4所示。
图4为本申请实施例提供的服务器确定待验证特征值的示意图。
在图4中，第一区块链节点的服务器(即通过第一区块链节点包含的定时任务触发器确定出的服务器)从第一区块链节点包含业务存储器中捞取了图4所示的4个业务请求，服务器可将这4个业务请求按照预设的排序规则进行排序，从而得到如图4所示的排序结果。而后，该服务器可按照预设的特征值确定规则：Hash算法，分别确定出这4个业务请求对应的子特征值Hash1～Hash4，并将确定出的这4个子特征值按照得到的排序结果，从左到右依次置于Merkle树的叶子节点中，进而确定出Merkle树的根节点值Hash7。该服务器可将确定出的Merkle树根节点值Hash7确定为这4个业务请求唯一对应的待验证特征值，进而将确定出的待验证特征值，排序结果以及这4个业务请求打包成预处理块。
需要说明的是，图4中所示的待验证特征值的确定方式并不唯一，如，第一区块链节点中的服务器除了可采用Hash作为预设的特征值确定规则，确定各业务请求唯一对应的待验证特征值外，还可通过诸如消息摘要算法第5版(Message Digest Algorithm，MD5)等算法来确定各业务请求唯一对应的待验证特征值，只需保证确定出的待验证特征值唯一对应的各业务请求即可。而对于Merkle树的形式来说，除了可以采用如图4所示的形式外，还可采用其他的形式，在此就不一一举例说明了。
当然，在本申请实施例中，第一区块链节点的服务器除了通过Merkle树确定出各业务请求唯一对应的待验证特征值外，还可采用其他的方式进行确定，如，该服务器分别确定出各业务请求对应的各子特征值后，可将确定出的各子特征值按照一定的顺序进行排序，并将排序的结果再次进行加密，进而将加密后的结果就作为各业务请求唯一对应的待验证特征值；或是，服务器分别确定出各业务请求对应的各子特征值后，可通过snowflake算法来生成一个全局唯一的ID，并将该ID就作为各业务请求唯一对应的待验证特征值；抑或是服务器可根据分别确定出的各业务请求对应的各子特征值，确定出各子特征值的一个通用唯一识别码(Universally Unique Identifier，UUID)，并将该UUID就作为各业务请求唯一对应的待验证特征值。当然还有其他的确定方式，在此就不进行一一举例说明了，只需保证确定出的待验证特征值能够唯一对应的各业务请求即可。
第一区块链节点中的服务器(即第一区块链节点中定时任务触发器在业务共识阶段选取出的服务器)确定出上述预处理块后，可将该预处理块发送至共识网络中的各第二区块链节点，而由于共识网络中每个第二区块链节点中均包含多个服务器，所以，第一区块链节点的服务器在发送该预处理块时，需要确定出将该预处理块发送至各第二区块链节点中的哪个服务器中。
在本申请实施例中，由于第一区块链节点中的各服务器可从注册中心获取到共识网络中每个第二区块链节点所包含的各服务器的地址，因此，第一区块 链节点的服务器需要将该预处理块发送至共识网络中的某一第二区块链节点时，可从自身存储的该第二区块链节点中各服务器的地址(存储的地址为该第二区块链节点中处于上线状态的服务器的地址)中选取一个地址，并将该预处理块发送至该地址所对应的服务器中，以使该地址对应的服务器在接收到该预处理块后，对该预处理块进行共识校验。
由于在共识网络中存在多个第二区块链节点，所以，第一区块链节点中的服务器在将上述预处理块发送至各第二区块链节点时，可通过上述方式，分别从存储的各地址中分别确定出接收该预处理块的各第二区块链节点的各服务器，继而将该预处理块通过确定出的各地址分别发送至各第二区块链节点的各服务器中。
对于第二区块链节点来说，当第二区块链节点中包含的服务器接收到上述第一区块链节点中的服务器发送的预处理块后，可对该预处理块进行解析，确定出该预处理块中包含的各业务请求、各业务请求的排序结果以及上述待验证特征值，而后，第二区块链节点中的服务器可从第二区块链节点包含的业务存储器中查找出与该预处理块中包含的各业务请求相匹配的各业务请求，并通过预设的特征值确定规则以及确定出的各业务请求的排序结果，确定出从第二区块链节点包含的业务存储器中查找出的各业务请求唯一对应的特征值，其中，这里提到的预设的特征值确定规则与第一区块链节点中的服务器所使用的特征值确定规则相同。
第二区块链节点中的服务器确定出上述特征值后，可将确定出的特征值与上述预处理块中包含的待验证特征值进行比对，当确定两者一致时，则可确定该预处理块通过本地的(即第二区块链节点的该服务器)的共识校验，进而将校验结果存储在该第二区块链节点包含的业务存储器中，以及将该校验结果发送至共识网络中的其他区块链节点(这里提到的其他区块链节点包含有各第二区块链节点以及第一区块链节点)。
其中，第二区块链节点中的服务器发送上述校验结果的方式与第一区块链 节点中的服务器将业务请求或预处理块发送给共识网络中各第二区块链节点的方式相同，即，当该第二区块链节点的服务器需要将该校验结果发送至共识网络中的某一个区块链节点时(可以是第二区块链节点也可以是第一区块链节点)，该服务器可从本地存储的该区块链节点中各服务器的地址中选取一个地址，并将该校验结果发送至该地址所对应的服务器。而地址所对应的服务器在接收到该校验结果后，可将该校验结果存储在所属区块链节点所包含的业务存储器中。
上述第二区块链节点中的服务器在将上述校验结果发送至共识网络中各区块链节点的同时，该第二区块链节点中的其他服务器或是该服务器也可接收共识网络中其他区块链节点发送的关于上述预处理块的校验结果，并将接收的校验结果统一存储在该第二区块链节点包含的业务存储器中。而后，第二区块链节点中的服务器(该服务器可以是接收上述预处理块的服务器)可从第二区块链节点包含的业务存储器中确定出共识网络中各区块链节点关于该预处理块的校验结果(包括自身做出的校验结果)，确定共识网络中的各区块链节点关于该预处理块的一个综合校验结果，而后，该服务器可通过与上述发送校验结果相同的方式，将确定出的该综合校验结果发送至共识网络中的各区块链节点中，与此同时将该综合校验结果存储该第二区块链节点所包含的业务存储器中。
上述第二区块链节点中的服务器发送上述综合校验结果后，该第二区块链节点中的其他服务器或是该服务器(即发送综合校验结果的服务器)也可接收共识网络中各区块链节点(包含各第二区块链节点以及第一区块链节点)发送的关于上述预处理块的综合校验结果，并将该综合校验结果存储在该第二区块链节点包含的业务存储器中。
上述第二区块链节点中的服务器(即发送综合校验结果的服务器)可从该第二区块链节点包含的业务存储器中捞取共识网络中其他区块链节点发送的综合校验结果，并通过接收到的综合校验结果以及自身确定出的综合校验结果， 确定上述预处理块是否通过共识网络的业务共识，若根据该业务存储器中存储的各综合校验结果(包含自身确定出的)确定该预处理块中包含的各业务请求通过共识网络的业务共识，则可将该预处理块中包含的各业务请求写入到该第二区块链节点所保存的区块链中，否则不将各业务请求写入到该区块链中，其中，第二区块链节点中的服务器可将各业务请求的完整内容写入到该区块链中，也可只将各业务请求的信息摘要写入到该区块链中。
上述说明的业务共识过程较为复杂，为了便于理解，下面将列举一个简单的例子清楚的说明第二区块链节点中的服务器对上述预处理块进行业务共识的过程，如图5所示。
图5为本申请实施例提供的第二区块链节点中的服务器对预处理块进行业务共识的过程示意图。
假设，在共识网络中存在第一区块链节点、第二区块链节点A以及第二区块链节点B这三个区块链节点。这三个区块链节点中的各服务器分别存有其他两个区块链节点包含的各服务器的地址。第一区块链节点中的服务器#3从第一区块链节点包含的业务存储器中捞取至少一个业务请求，并将所述至少一个业务请求打包成预处理块发送给其他两个区块链节点，其中，服务器#3通过自身存储的其他两个区块链节点包含的各服务器的地址，确定将该预处理块分别发送给服务器A1以及服务器B1。
服务器A1以及服务器B1接收到上述预处理块后，可对该预处理块进行共识校验，并将得到出的针对该预处理块的校验结果分别存储在所属区块链节点所包含的业务存储器中。与此同时，服务器A1以及服务器B1可分别将确定出的校验结果发送至共识网络中的其他两个区块链节点，其中，服务器A1根据自身存储的其他两个区块链节点中各服务器的地址，确定将自身得出的校验结果发送至第一区块链节点中的服务器#2以及第二区块链节点B中的服务器B2，而服务器B1则确定将自身得出的校验结果发送至第一区块链节点的服务器#3以及第二区块链节点A中的服务器A3。
共识网络中的这三个区块链节点中的服务器分别接收到其余两个区块链节点的服务器所发送的校验结果后，可将接收到的校验结果存储在所属区块链节点所包含的业务存储器中。而服务器A1(即接收上述预处理块的服务器)可从第二区块链节点A包含的业务存储器中获取各校验结果(其中包含自身得出的校验结果)，并根据这些校验结果得出共识网络中各区块链节点针对该预处理块的一个综合校验结果。服务器A1可将得出的该综合校验结果存储在第二区块链节点A所包含的业务存储器中，并将该综合校验结果发送至其他两个区块链节点中，发送的方式与发送校验结果的方式相同，在此就不进行详细赘述了。而对于服务器#3(即发送业务共识的服务器)以及服务器B1(接收预处理块的服务器)来说，同样可以按照这种方式确定出针对该预处理块的一个综合校验结果，并将得出的综合校验结果发送至共识网络中的其他两个区块链节点。
共识网络中各区块链节点的各服务器在接收到其他两个区块链节点发送的综合校验结果后，可将接收到的综合校验结果存储在所属区块链节点包含的业务存储器中。
服务器A1可从第二区块链节点A包含的业务存储器中获取到各区块链节点发送的针对上述预处理块的综合校验结果(包含自身作出的综合校验结果)，而后，服务器A1可根据各综合校验结果，确定出该预处理块是否通过共识网络中的业务共识，若是，则将该预处理块中包含的各业务请求写入到第二区块链节点A的区块链中，若否，则不将各业务请求写入到该区块链中。同理，服务器#3以及服务器B1也可通过这种方式，从各自所属的区块链节点所包含的业务存储器中获取到各综合校验结果，并根据获取到的各综合校验结果，确定是否将该预处理块中包含的各业务请求写入到所属区块链节点的区块链中。
从上述方法中可以看出，由于共识网络中的各区块链节点均包含有多个服务器，对于每个区块链节点来说，该区块链节点中的各服务器只要有一个处于上线状态，即可用，则该区块链节点在共识网络中即为可用的区块链节点，从 而极大的提高了区块链节点在共识网络中的稳定性。不仅如此，由于每个区块链节点中都包含有多个服务器，每个服务器对于区块链节点来说，其功能和地位都是等同的，换句话说，区块链节点在现有技术的基础上，增加了地位等同的服务器，这就极大的提高了区块链节点的性能，从而提高了区块链节点的业务处理效率。
需要说明的是，在业务共识的过程中，共识网络中的每个区块链节点均可确定出自身针对上述预处理块的校验结果，将得出的校验结果发送至共识网络中的其他区块链节点以及将该校验结果存储在该区块链节点所对应的业务存储器中，其中，该区块链节点可通过自身包含的第一服务器对该预处理块进行共识校验，而该第一服务器可以是该区块链节点中的一个指定的服务器，也可以是从区块链节点中包含的各服务器中选取出的一个服务器。
与此同时，该区块链节点也将接收到共识网络中的其他区块链节点发送的针对上述预处理块的校验结果，其中，该区块链节点可通过其所包含的服务器接收其他区块链节点发送的校验结果，并将接收到的校验结果存储在该区块链节点所对应的业务存储器中，这里可将接收由其他区块链节点所发送的校验结果的服务器称之为第二服务器，该第二服务器可以是该区块链节点中任意一个服务器，当然也可以是上述说明的第一服务器，而到底通过哪个第二服务器来接收其他区块链节点发送的校验结果，则取决于其他区块链节点中包含的服务器选取哪个第二服务器接收其发送的校验结果。
在上述步骤S101中，客户端除了可从存储的第一区块链节点中各服务器的地址中随机选取一个地址外，也可根据负载均衡情况来选取地址，为此，注册中心向客户端推送第一区块链节点中各服务器的地址时，可连带将各服务器的负载情况一并推送给客户端，以使客户端通过预设的负载均衡算法，从各地址中选取一个负载较小的服务器的地址，并将上述业务请求发送至该地址所对应的服务器中。
同理，第一区块链节点的服务器在发送上述业务请求至共识网络中的各第 二区块链节点时，也可采用负载均衡的方式，从存储的各地址中选取服务器，当然，第一区块链节点的服务器发送上述预处理块，以及共识网络中各区块链节点在发送上述校验结果以及综合校验结果时，也可采用负载均衡的方式进行，具体过程客户端通过负载均衡的方式向第一区块链节点发送业务请求的方式相同，在此就不作详细赘述了。
在本申请实施例中，除了可以使用任务定时触发器来选取发起业务共识的服务器外，还可以在区块链节点(包含第一区块链节点以及第二区块链节点)中的服务器分别设置一个共识周期，不同服务器的共识周期各不相同，当服务器监测到当前时间到达自身的共识周期，则可从所属区块链节点的业务存储器中捞取至少一个业务请求。
在本申请实施例中，区块链节点(包含第一区块链节点以及第二区块链节点)中服务器在接收到上述业务请求后，也可将该业务请求转发至该区块链节点的其他服务器中，并由其他的服务器将该业务请求存储在该区块链节点所包含的业务存储器中。而对于共识网络中的每个第二区块链节点来说，该第二区块链节点中的服务器在接收到第一区块链节点发送的预处理块后，也可将该预处理块转发至该第二区块链节点中的其他服务器中进行共识校验，并将得出的校验结果存储在该第二区块链节点所包含的业务存储器中。
以上为本申请实施例提供的业务共识的方法，基于同样的思路，本申请实施例还提供以下几种业务受理的装置以及业务共识的装置，如图6～12所示。
图6为本申请实施例提供的一种业务受理的装置示意图，具体包括：
接收模块601，接收客户端发送的业务请求；
存储模块602，将所述业务请求存储在自身对应的业务存储器中；
发送模块603，将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
所述装置还包括：
注册模块604，当确定所述装置上线时，则将所述装置的地址发送至注册中心，以使所述注册中心将所述地址发送至客户端以及共识网络中的各第二区块链节点。
所述装置还包括：
获取模块605，针对每个第二区块链节点，所述装置从注册中心中获取该第二区块链节点包含的多个服务器的地址。
所述发送模块603，针对每个第二区块链节点，从获取的该第二区块链节点包含的多个服务器的地址中选取地址；将所述业务请求发送至选取的地址所对应的服务器中。
所述存储模块602，对所述业务请求进行合法验证；当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业务存储器中。
所述存储模块602，当确定所述业务请求未通过所述合法验证时，则不对所述业务请求进行存储。
区块链节点中包含有多个所述装置。
图7为本申请实施例提供的一种业务受理的装置示意图，具体包括：
接收请求模块701，接收第一区块链节点发送的业务请求，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
请求存储模块702，将所述业务请求存储在自身对应的业务存储器中。
所述装置还包括：
注册模块703，当确定所述装置上线时，则将所述装置的地址发送注册中心，以使所述注册中心将所述地址发送至所述第一区块链节点、客户端以及共识网络中其他第二区块链节点中。
所述请求存储模块702，对所述业务请求进行合法验证；当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业务存储器中。
所述请求存储模块702，当确定所述业务请求未通过所述合法验证时，则 不对所述业务请求进行存储。
图8为本申请实施例提供的一种业务受理的装置示意图，具体包括：
接收信息模块801，接收用户输入的业务信息；
请求生成模块802，根据所述业务信息，生成相应的业务请求；
发送模块803，将所述业务请求发送至第一区块链节点包含的一个服务器，以使所述第一区块链节点将接收到的所述业务请求存储在第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，所述第一区块链节点包含有多个服务器以及至少一个业务存储器，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
所述发送模块803，从注册中心中获取所述第一区块链节点包含的多个服务器的地址；从获取的所述第一区块链节点包含的多个服务器的地址中选取地址，并将所述业务请求发送至选取的地址所对应的服务器中。
所述装置还包括：
删除模块804，当接收到所述注册中心针对某一服务器发送的下线通知时，则将该服务器的地址进行删除。
图9为本申请实施例提供的一种业务共识的装置示意图，具体包括：
请求捞取模块901，从自身对应的业务存储器中捞取至少一个业务请求；
发送模块902，将所述至少一个业务请求打包成预处理块，并将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
所述装置还包括：
获取地址模块903，针对每个第二区块链节点，所述装置从注册中心中获取该第二区块链节点包含的多个服务器的地址。
所述发送模块902，针对每个第二区块链节点，从获取到的该第二区块链节点包含的多个服务器的地址中选取地址；将所述预处理块发送至选取的地址 所对应的服务器中，以使选取的地址所对应的服务器对接收到的所述预处理块进行业务共识。
图10为本申请实施例提供的一种业务共识的装置示意图，具体包括：
选取模块1001，从第一区块链节点包含的多个服务器中选取服务器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器。
所述选取模块1001，监测当前时刻是否满足任务触发条件；当监测到满足任务触发条件时，从所述第一区块链节点包含的多个服务器中选取服务器。
图11为本申请实施例提供的一种业务共识的装置示意图，具体包括：
获取模块1101，获取预处理块；
共识模块1102，根据自身对应的业务存储器中存储的各业务请求，对所述预处理块进行业务共识。
所述共识模块1102，对所述预处理块进行共识校验，得到校验结果；接收共识网络中其他区块链节点发送的各校验结果，并将接收到的各校验结果存储在自身对应的业务存储器中；从所述业务存储器中获取各校验结果，并通过获取到的各校验结果，对所述预处理块进行业务共识。
图12为本申请实施例提供的一种业务共识的装置示意图，具体包括：
获取模块1201，针对共识网络中的每个区块链节点，获取该区块链节点包含的多个服务器的地址，每个区块链节点包含有多个服务器以及至少一个业务存储器；
发送模块1202，将获取到的该区块链节点包含的多个服务器的地址发送至共识网络中其他区块链节点以及客户端存储。
所述装置还包括：
通知模块1203，针对共识网络中的每个区块链节点，根据获取到的该区块链节点包含的多个服务器的地址，向该区块链节点包含的多个服务器发送心跳检测消息；
针对该区块链节点包含的每个服务器，当经过设定时间后未接收到该服务 器根据所述心跳检测消息返回的应答消息时，则确定该服务器下线，并通知所述客户端以及共识网络中其他区块链节点将存储的该服务器的地址删除。
本申请实施例提供一种业务共识的方法及装置，该方法中第一区块链节点中包含有多个服务器，第一区块链节点可通过包含的多个服务器接收从客户端发送的业务请求并存储，以及通过多个服务器中的服务器从该第一区块链节点包含的业务存储器中捞取至少一个业务请求，得到预处理块，并将预处理块通过该服务器发送至共识网络的各第二区块链节点中，以通过各第二区块链节点对该预处理块进行业务共识。由于在第一区块链节点包含的多个服务器中，只要有一个服务器可用，即能保证该第一区块链节点可用，从而极大的提高了第一区块链节点在共识网络中的稳定性。不仅如此，由于第一区块链节点中包含的每个服务器均可接收用户通过客户端发送的业务请求，并且每个服务器均可向共识网络中的各第二区块链节点发起业务共识，从而极大的提高了区块链业务的业务处理效率。
在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 (48)

  1. 一种业务受理的方法，其特征在于，包括：
    第一区块链节点通过自身包含的一个服务器接收客户端发送的业务请求，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
    将所述业务请求存储在自身包含的业务存储器中；
    将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  2. 如权利要求1所述的方法，其特征在于，第一区块链节点通过自身包含的一个服务器接收客户端发送的业务请求之前，所述方法还包括：
    当所述第一区块链节点中的服务器上线时，则将上线的服务器的地址发送至注册中心，以使所述注册中心将所述地址发送至客户端以及共识网络中的各第二区块链节点。
  3. 如权利要求1所述的方法，其特征在于，将所述业务请求发送给共识网络中的各第二区块链节点之前，所述方法还包括：
    针对每个第二区块链节点，所述第一区块链节点从注册中心中获取该第二区块链节点包含的多个服务器的地址。
  4. 如权利要求3所述的方法，其特征在于，将所述业务请求发送给共识网络中的各第二区块链节点，具体包括：
    针对每个第二区块链节点，从获取的该第二区块链节点包含的多个服务器的地址中选取地址；
    将所述业务请求发送至选取的地址所对应的服务器中。
  5. 如权利要求1所述的方法，其特征在于，将所述业务请求存储在自身包含的业务存储器中，具体包括：
    对所述业务请求进行合法验证；
    当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业 务存储器中。
  6. 如权利要求5所述的方法，其特征在于，所述方法还包括：
    当确定所述业务请求未通过所述合法验证时，则不对所述业务请求进行存储。
  7. 一种业务受理的方法，其特征在于，包括：
    第二区块链节点通过自身包含的一个服务器接收第一区块链节点发送的业务请求，所述第二区块链节点包含有多个服务器以及至少一个业务存储器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
    将所述业务请求存储在自身包含的业务存储器中。
  8. 如权利要求7所述的方法，其特征在于，第二区块链节点通过自身包含的一个服务器接收第一区块链节点发送的业务请求之前，所述方法还包括：
    当所述第二区块链节点中的服务器上线时，则将上线的服务器的地址发送至注册中心，以使所述注册中心将所述地址发送至所述第一区块链节点、客户端以及共识网络中其他第二区块链节点中。
  9. 如权利要求7所述的方法，其特征在于，将所述业务请求存储在自身包含的业务存储器中，具体包括：
    对所述业务请求进行合法验证；
    当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业务存储器中。
  10. 如权利要求9所述的方法，其特征在于，所述方法还包括：
    当确定所述业务请求未通过所述合法验证时，则不对所述业务请求进行存储。
  11. 一种业务受理的方法，其特征在于，包括：
    客户端接收用户输入的业务信息；
    根据所述业务信息，生成相应的业务请求；
    将所述业务请求发送至第一区块链节点包含的一个服务器，以使所述第一 区块链节点将接收到的所述业务请求存储在第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，所述第一区块链节点包含有多个服务器以及至少一个业务存储器，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  12. 如权利要求11所述的方法，其特征在于，将所述业务请求发送至第一区块链节点包含的一个服务器，具体包括：
    从注册中心中获取所述第一区块链节点包含的多个服务器的地址；
    从获取的所述第一区块链节点包含的多个服务器的地址中选取地址，并将所述业务请求发送至选取的地址所对应的服务器中。
  13. 如权利要求12所述的方法，其特征在于，所述方法还包括：
    当接收到所述注册中心针对某一服务器发送的下线通知时，则将该服务器的地址进行删除。
  14. 一种业务共识的方法，其特征在于，每个区块链节点包含有多个服务器以及至少一个业务存储器，所述方法包括：
    第一区块链节点从自身包含的多个服务器中选取服务器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
    通过选取出的服务器从自身包含的业务存储器中捞取至少一个业务请求；
    通过选取出的服务器将所述至少一个业务请求打包成预处理块，并将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  15. 如权利要求14所述的方法，其特征在于，所述第一区块链节点以及第二区块链节点还包含定时任务触发器；
    第一区块链节点从自身包含的多个服务器中选取服务器，具体包括：
    通过所述定时任务触发器监测当前时刻是否满足任务触发条件；
    当监测到满足任务触发条件时，通过所述定时任务触发器从所述第一区块 链节点包含的多个服务器中选取服务器。
  16. 如权利要求14所述的方法，其特征在于，将所述预处理块发送至共识网络中的各第二区块链节点之前，所述方法还包括：
    针对每个第二区块链节点，所述第一区块链节点从注册中心中获取该第二区块链节点包含的多个服务器的地址。
  17. 如权利要求16所述的方法，其特征在于，将所述预处理块发送至共识网络中的各第二区块链节点，具体包括：
    针对每个第二区块链节点，从获取到的该第二区块链节点包含的多个服务器的地址中选取地址；
    通过选取出的服务器将所述预处理块发送至选取的地址所对应的服务器中，以使选取的地址所对应的服务器对接收到的所述预处理块进行业务共识。
  18. 一种业务共识的方法，其特征在于，包括：
    区块链节点通过自身包含的第一服务器获取预处理块，所述区块链节点包含有多个服务器以及至少一个业务存储器；
    根据自身包含的业务存储器中存储的各业务请求，通过所述第一服务器对所述预处理块进行业务共识。
  19. 如权利要求18所述的方法，其特征在于，根据自身包含的业务存储器中存储的各业务请求，对所述预处理块进行业务共识，具体包括：
    通过自身包含的第一服务器对所述预处理块进行共识校验，得到校验结果；
    将所述校验结果存储在自身包含的业务存储器中，并将所述校验结果发送至共识网络中的其他区块链节点；
    通过自身包含的第二服务器接收共识网络中其他区块链节点发送的各校验结果，并将接收到的各校验结果存储在自身包含的业务存储器中；
    通过所述第一服务器从所述业务存储器中获取各校验结果，并通过获取到的各校验结果，对所述预处理块进行业务共识。
  20. 如权利要求19所述的方法，其特征在于，所述第一服务器和第二服 务器为同一服务器，或者，所述第一服务器和第二服务器为不同的服务器；
    所述第二服务器为一个服务器，或者，所述第二服务器为多个服务器。
  21. 一种业务受理的方法，其特征在于，包括：
    针对共识网络中的每个区块链节点，注册中心获取该区块链节点包含的多个服务器的地址，每个区块链节点包含有多个服务器以及至少一个业务存储器；
    将获取到的该区块链节点包含的多个服务器的地址发送至共识网络中其他区块链节点以及客户端存储。
  22. 如权利要求21所述的方法，其特征在于，所述方法还包括：
    针对共识网络中的每个区块链节点，根据获取到的该区块链节点包含的多个服务器的地址，向该区块链节点包含的多个服务器发送心跳检测消息；
    针对该区块链节点包含的每个服务器，当经过设定时间后未接收到该服务器根据所述心跳检测消息返回的应答消息时，则确定该服务器下线，并通知所述客户端以及共识网络中其他区块链节点将存储的该服务器的地址删除。
  23. 一种业务受理的装置，其特征在于，包括：
    接收模块，接收客户端发送的业务请求；
    存储模块，将所述业务请求存储在自身对应的业务存储器中；
    发送模块，将所述业务请求发送给共识网络中的各第二区块链节点，以使所述各第二区块链节点接收到所述业务请求后，将所述业务请求存储在自身包含的业务存储器中，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  24. 如权利要求23所述的装置，其特征在于，所述装置还包括：
    注册模块，当确定所述装置上线时，则将所述装置的地址发送至注册中心，以使所述注册中心将所述地址发送至客户端以及共识网络中的各第二区块链节点。
  25. 如权利要求23所述的装置，其特征在于，所述装置还包括：
    获取模块，针对每个第二区块链节点，所述装置从注册中心中获取该第二 区块链节点包含的多个服务器的地址。
  26. 如权利要求25所述的装置，其特征在于，所述发送模块，针对每个第二区块链节点，从获取的该第二区块链节点包含的多个服务器的地址中选取地址；将所述业务请求发送至选取的地址所对应的服务器中。
  27. 如权利要求23所述的装置，其特征在于，所述存储模块，对所述业务请求进行合法验证；当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业务存储器中。
  28. 如权利要求27所述的装置，其特征在于，所述存储模块，当确定所述业务请求未通过所述合法验证时，则不对所述业务请求进行存储。
  29. 如权利要求23～28任一所述的装置，其特征在于，区块链节点中包含有多个所述装置。
  30. 一种业务受理的装置，其特征在于，包括：
    接收请求模块，接收第一区块链节点发送的业务请求，所述第一区块链节点包含有多个服务器以及至少一个业务存储器；
    请求存储模块，将所述业务请求存储在自身对应的业务存储器中。
  31. 如权利要求30所述的装置，其特征在于，所述装置还包括：
    注册模块，当确定所述装置上线时，则将所述装置的地址发送注册中心，以使所述注册中心将所述地址发送至所述第一区块链节点、客户端以及共识网络中其他第二区块链节点中。
  32. 如权利要求30所述的装置，其特征在于，所述请求存储模块，对所述业务请求进行合法验证；当确定所述业务请求通过所述合法验证时，将所述业务请求存储在所述业务存储器中。
  33. 如权利要求32所述的装置，其特征在于，所述请求存储模块，当确定所述业务请求未通过所述合法验证时，则不对所述业务请求进行存储。
  34. 如权利要求30～33任一所述的装置，其特征在于，区块链节点中包含有多个所述装置。
  35. 一种业务受理的装置，其特征在于，包括：
    接收信息模块，接收用户输入的业务信息；
    请求生成模块，根据所述业务信息，生成相应的业务请求；
    发送模块，将所述业务请求发送至第一区块链节点包含的一个服务器，以使所述第一区块链节点将接收到的所述业务请求存储在第一区块链节点包含的业务存储器中，并将所述业务请求发送给共识网络中的各第二区块链节点，所述第一区块链节点包含有多个服务器以及至少一个业务存储器，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  36. 如权利要求35所述的装置，其特征在于，所述发送模块，从注册中心中获取所述第一区块链节点包含的多个服务器的地址；从获取的所述第一区块链节点包含的多个服务器的地址中选取地址，并将所述业务请求发送至选取的地址所对应的服务器中。
  37. 如权利要求36所述的装置，其特征在于，所述装置还包括：
    删除模块，当接收到所述注册中心针对某一服务器发送的下线通知时，则将该服务器的地址进行删除。
  38. 一种业务共识的装置，其特征在于，包括：
    请求捞取模块，从自身对应的业务存储器中捞取至少一个业务请求；
    发送模块，将所述至少一个业务请求打包成预处理块，并将所述预处理块发送至共识网络中的各第二区块链节点，以使所述各第二区块链节点对所述预处理块进行业务共识，所述第二区块链节点包含有多个服务器以及至少一个业务存储器。
  39. 如权利要求38所述的装置，其特征在于，所述装置还包括：
    获取地址模块，针对每个第二区块链节点，所述装置从注册中心中获取该第二区块链节点包含的多个服务器的地址。
  40. 如权利要求39所述的装置，其特征在于，所述发送模块，针对每个第二区块链节点，从获取到的该第二区块链节点包含的多个服务器的地址中选 取地址；将所述预处理块发送至选取的地址所对应的服务器中，以使选取的地址所对应的服务器对接收到的所述预处理块进行业务共识。
  41. 如权利要求38～40任一所述的装置，其特征在于，区块链节点中包含有多个所述装置。
  42. 一种业务共识的装置，其特征在于，包括：
    选取模块，从第一区块链节点包含的多个服务器中选取服务器，所述第一区块链节点包含有多个服务器以及至少一个业务存储器。
  43. 如权利要求42所述的装置，其特征在于，所述选取模块，监测当前时刻是否满足任务触发条件；当监测到满足任务触发条件时，从所述第一区块链节点包含的多个服务器中选取服务器。
  44. 一种业务共识的装置，其特征在于，包括：
    获取模块，获取预处理块；
    共识模块，根据自身对应的业务存储器中存储的各业务请求，对所述预处理块进行业务共识。
  45. 如权利要求44所述的装置，其特征在于，所述共识模块，对所述预处理块进行共识校验，得到校验结果；接收共识网络中其他区块链节点发送的各校验结果，并将接收到的各校验结果存储在自身对应的业务存储器中；从所述业务存储器中获取各校验结果，并通过获取到的各校验结果，对所述预处理块进行业务共识。
  46. 如权利要求45所述的装置，其特征在于，区块链节点包含有多个所述装置。
  47. 一种业务受理的装置，其特征在于，包括：
    获取模块，针对共识网络中的每个区块链节点，获取该区块链节点包含的多个服务器的地址，每个区块链节点包含有多个服务器以及至少一个业务存储器；
    发送模块，将获取到的该区块链节点包含的多个服务器的地址发送至共识 网络中其他区块链节点以及客户端存储。
  48. 如权利要求47所述的装置，其特征在于，所述装置还包括：
    通知模块，针对共识网络中的每个区块链节点，根据获取到的该区块链节点包含的多个服务器的地址，向该区块链节点包含的多个服务器发送心跳检测消息；
    针对该区块链节点包含的每个服务器，当经过设定时间后未接收到该服务器根据所述心跳检测消息返回的应答消息时，则确定该服务器下线，并通知所述客户端以及共识网络中其他区块链节点将存储的该服务器的地址删除。
PCT/CN2018/080461 2017-03-28 2018-03-26 一种业务受理及共识的方法及装置 WO2018177239A1 (zh)

Priority Applications (14)

Application Number Priority Date Filing Date Title
MX2019007812A MX2019007812A (es) 2017-03-28 2018-03-26 Metodo y dispositivo de procesamiento y consenso de servicio.
CA3048737A CA3048737C (en) 2017-03-28 2018-03-26 Service processing and consensus method and device
MYPI2019003674A MY194387A (en) 2017-03-28 2018-03-26 Service processing and consensus method and device
RU2019119888A RU2735096C1 (ru) 2017-03-28 2018-03-26 Способ и устройство обработки услуг и консенсуса
KR1020197018692A KR102152556B1 (ko) 2017-03-28 2018-03-26 서비스 프로세싱 및 합의 방법 및 디바이스
EP18775664.8A EP3547648B1 (en) 2017-03-28 2018-03-26 Service processing and consensus method and device
AU2018243075A AU2018243075B2 (en) 2017-03-28 2018-03-26 Service processing and consensus method and device
JP2019535947A JP6773912B2 (ja) 2017-03-28 2018-03-26 サービス処理およびコンセンサスの方法およびデバイス
BR112019013204-0A BR112019013204B1 (pt) 2017-03-28 2018-03-26 Método para processamento de serviços
ZA2019/04230A ZA201904230B (en) 2017-03-28 2019-06-27 Service processing and consensus method and device
PH12019501538A PH12019501538B1 (en) 2017-03-28 2019-06-28 Service processing and consensus method and device
US16/516,483 US10681175B2 (en) 2017-03-28 2019-07-19 Multi-server node service processing and consensus method and device
US16/882,057 US11057493B2 (en) 2017-03-28 2020-05-22 Multi-server node service processing and consensus method and device
US17/367,137 US11943317B2 (en) 2017-03-28 2021-07-02 Multi-server node service processing and consensus method and device based on heartbeat detection messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710191462.X 2017-03-28
CN201710191462.XA CN107395659B (zh) 2017-03-28 2017-03-28 一种业务受理及共识的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/516,483 Continuation US10681175B2 (en) 2017-03-28 2019-07-19 Multi-server node service processing and consensus method and device

Publications (1)

Publication Number Publication Date
WO2018177239A1 true WO2018177239A1 (zh) 2018-10-04

Family

ID=60338363

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/080461 WO2018177239A1 (zh) 2017-03-28 2018-03-26 一种业务受理及共识的方法及装置

Country Status (15)

Country Link
US (3) US10681175B2 (zh)
EP (1) EP3547648B1 (zh)
JP (1) JP6773912B2 (zh)
KR (1) KR102152556B1 (zh)
CN (2) CN107395659B (zh)
AU (1) AU2018243075B2 (zh)
BR (1) BR112019013204B1 (zh)
CA (1) CA3048737C (zh)
MX (1) MX2019007812A (zh)
MY (1) MY194387A (zh)
PH (1) PH12019501538B1 (zh)
RU (1) RU2735096C1 (zh)
TW (1) TWI686709B (zh)
WO (1) WO2018177239A1 (zh)
ZA (1) ZA201904230B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110135194A (zh) * 2019-05-20 2019-08-16 北京邮电大学 一种基于区块链的工业互联网数字对象的管理方法
EP3691223A1 (en) * 2019-01-31 2020-08-05 Fujitsu Limited Communication device and communication method used in distributed network
CN112131313A (zh) * 2020-09-16 2020-12-25 浙江工商大学 一种基于区块链的加油数据管理系统及其方法
CN112215608A (zh) * 2019-01-18 2021-01-12 创新先进技术有限公司 数据处理方法和装置
CN114866615A (zh) * 2022-05-24 2022-08-05 深圳点宽网络科技有限公司 基于区块链的服务调用方法、装置、系统及电子设备
CN116260707A (zh) * 2023-05-15 2023-06-13 安徽中科晶格技术有限公司 基于共识的区块链节点灾备方法、装置、设备及存储介质

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10419225B2 (en) 2017-01-30 2019-09-17 Factom, Inc. Validating documents via blockchain
US10411897B2 (en) 2017-02-17 2019-09-10 Factom, Inc. Secret sharing via blockchains
US10817873B2 (en) 2017-03-22 2020-10-27 Factom, Inc. Auditing of electronic documents
CN107395659B (zh) 2017-03-28 2021-08-24 创新先进技术有限公司 一种业务受理及共识的方法及装置
CN108009824A (zh) * 2017-11-28 2018-05-08 北京博晨技术有限公司 数据共识方法、装置及电子设备
US10873625B2 (en) * 2018-02-26 2020-12-22 International Business Machines Corpora ! Ion Service management for the infrastructure of blockchain networks
CN108537525B (zh) 2018-03-09 2020-06-09 阿里巴巴集团控股有限公司 一种共识验证方法、装置及设备
CN108769150B (zh) * 2018-05-14 2021-11-12 百度在线网络技术（北京）有限公司 区块链网络的数据处理方法、装置、集群节点和存储介质
CN108683738B (zh) * 2018-05-16 2020-08-14 腾讯科技（深圳）有限公司 图数据处理方法和图数据的计算任务发布方法
US11170366B2 (en) 2018-05-18 2021-11-09 Inveniam Capital Partners, Inc. Private blockchain services
US11134120B2 (en) * 2018-05-18 2021-09-28 Inveniam Capital Partners, Inc. Load balancing in blockchain environments
CN108965379B (zh) * 2018-05-29 2021-03-16 张迅 资源调度装置及方法
US11328290B2 (en) 2018-08-06 2022-05-10 Inveniam Capital Partners, Inc. Stable cryptocurrency coinage
US20200042982A1 (en) 2018-08-06 2020-02-06 Factom Digital Contracts in Blockchain Environments
CN109192287A (zh) * 2018-08-21 2019-01-11 中国联合网络通信集团有限公司 基于区块链的医院挂号方法及装置
CN109257427B (zh) * 2018-09-26 2021-04-02 网宿科技股份有限公司 一种基于区块链的业务处理方法及系统
CN109547530B (zh) * 2018-10-17 2021-07-27 北京瑞卓喜投科技发展有限公司 区域共识方法、系统及设备
CN109286632B (zh) * 2018-10-25 2021-01-15 中国信息通信研究院 一种基于区块链的大数据授权存证方法和系统
CN110020945B (zh) * 2018-11-27 2020-10-30 创新先进技术有限公司 一种基于多个区块链网络的数据读取方法及系统
CN111224793B (zh) * 2018-11-27 2021-06-01 华为技术有限公司 数据存储方法、装置、计算机设备及可读存储介质
CN111899104B (zh) * 2018-11-27 2023-12-01 创新先进技术有限公司 一种业务执行方法及装置
CN110060153B (zh) 2018-11-27 2020-11-17 创新先进技术有限公司 一种基于多个区块链网络的数据存证方法及系统
CN110060152B (zh) 2018-11-27 2020-10-30 创新先进技术有限公司 一种基于多个区块链网络的数据读取方法及系统
US10735464B2 (en) * 2018-12-29 2020-08-04 Alibaba Group Holding Limited System and method for detecting replay attack
US11283634B2 (en) 2018-12-29 2022-03-22 Advanced New Technologies Co., Ltd. System and method for detecting replay attack
JP6905059B2 (ja) 2018-12-29 2021-07-21 アドバンスド ニュー テクノロジーズ カンパニー リミテッド リプレイ攻撃の検出のためのシステム及び方法
CN109831425B (zh) * 2019-01-25 2022-02-15 中国联合网络通信集团有限公司 区块链共识方法、装置、设备及计算机可读存储介质
CN110061856A (zh) * 2019-03-07 2019-07-26 阿里巴巴集团控股有限公司 一种基于区块链的通信方法、装置及电子设备
CN110162570B (zh) * 2019-04-17 2021-03-05 创新先进技术有限公司 区块链数据的分次获取方法和装置
CN112181474B (zh) * 2019-07-04 2022-05-20 北京新唐思创教育科技有限公司 区块链业务处理方法、电子设备及计算机存储介质
CN110633323B (zh) * 2019-09-16 2023-10-20 腾讯科技（深圳）有限公司 业务数据存储方法、装置、存储介质和计算机设备
WO2021089312A1 (en) * 2019-11-04 2021-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Methods providing v2x application server registration
CN111030846A (zh) * 2019-11-18 2020-04-17 杭州趣链科技有限公司 一种基于区块链的数据上链异常重试方法
CN110933166B (zh) * 2019-11-27 2022-08-12 中国联合网络通信集团有限公司 一种共识平台、终端、节点和路径选择方法
US11343075B2 (en) 2020-01-17 2022-05-24 Inveniam Capital Partners, Inc. RAM hashing in blockchain environments
CN111506584B (zh) * 2020-03-26 2023-07-25 金蝶软件（中国）有限公司 基于区块链的业务数据处理方法、装置和计算机设备
CN111464356B (zh) * 2020-04-01 2021-11-05 腾讯科技（深圳）有限公司 一种区块共识周期切换方法、装置及计算机设备
CN111522876B (zh) * 2020-04-07 2024-02-20 金蝶软件（中国）有限公司 区块链共识方法、装置和计算机设备、及区块链节点
CN111625593B (zh) * 2020-04-21 2023-09-08 金蝶软件（中国）有限公司 基于区块链的数据处理方法、装置、计算机设备
CN111524010B (zh) * 2020-05-06 2023-06-02 杭州复杂美科技有限公司 平行链共识方法、设备和存储介质
CN111614468B (zh) * 2020-05-24 2022-08-26 济南欣格信息科技有限公司 一种区块链共识方法及系统
CN111786952B (zh) * 2020-05-29 2023-03-17 中国银联股份有限公司 区块链系统的共识方法、装置、设备及介质
KR102416337B1 (ko) * 2020-06-02 2022-07-05 (주)세정아이앤씨 블록체인을 관리하기 위한 장치, 방법, 시스템 및 컴퓨터 판독가능 저장 매체
CN111709803B (zh) * 2020-06-12 2023-09-05 北京思特奇信息技术股份有限公司 一种防止越权办理业务的方法和系统
CN111522822A (zh) 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备
CN111934997B (zh) * 2020-09-25 2021-01-12 支付宝(杭州)信息技术有限公司 消息传输方法及装置
US11615074B2 (en) 2020-10-01 2023-03-28 Bank Of America Corporation System and methods for intelligent path selection of enhanced distributed processors
CN112416731B (zh) * 2020-12-02 2021-07-30 腾讯科技（深圳）有限公司 应用于区块链系统的稳定性监测方法及装置
US11784872B1 (en) * 2021-05-07 2023-10-10 T-Mobile Usa, Inc. Suppressing messages to an out-of-service server
US11843503B1 (en) 2021-05-07 2023-12-12 T-Mobile Usa, Inc. Providing out-of-service notifications regarding a server
CN113315826B (zh) * 2021-05-24 2023-03-24 网易（杭州）网络有限公司 区块链的管理方法、装置、管理服务节点及存储介质
CN113282570B (zh) * 2021-05-25 2022-06-28 杭州复杂美科技有限公司 区块链节点配置方法、计算机设备和存储介质
CN114419717A (zh) * 2022-01-27 2022-04-29 睿云联(厦门)网络通讯技术有限公司 一种终端设备的人脸检测、识别加速方法及系统
CN114844896B (zh) * 2022-05-07 2023-07-04 深圳嘉业产业发展有限公司 一种基于区块链的资源共享方法及系统
CN115396122B (zh) * 2022-10-27 2023-04-25 聚梦创新(北京)软件技术有限公司 消息处理方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170031676A1 (en) * 2015-07-27 2017-02-02 Deja Vu Security, Llc Blockchain computer data distribution
CN106384236A (zh) * 2016-08-31 2017-02-08 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN106385319A (zh) * 2016-09-29 2017-02-08 江苏通付盾科技有限公司 区块链网络中信息的验证方法及系统
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
CN107395659A (zh) * 2017-03-28 2017-11-24 阿里巴巴集团控股有限公司 一种业务受理及共识的方法及装置

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886023B1 (en) * 2000-01-21 2011-02-08 Cisco Technology, Inc. Method and apparatus for a minimalist approach to implementing server selection
AU2003243512A1 (en) * 2003-06-11 2005-01-28 Web Office, Inc. Multi-node network having common routing table
US20050050227A1 (en) * 2003-07-03 2005-03-03 Cascade Basic Research Corp. Method and system for peer-to-peer directory services
WO2005062989A2 (en) * 2003-12-23 2005-07-14 Wachovia Corporation Authentication system for networked computer applications
CN101123565B (zh) * 2007-07-30 2011-07-13 中兴通讯股份有限公司 P2p系统及用于该系统的资源查询方法
US8631134B2 (en) * 2008-07-30 2014-01-14 Visa U.S.A. Inc. Network architecture for secure data communications
US8843630B1 (en) * 2008-08-27 2014-09-23 Amazon Technologies, Inc. Decentralized request routing
US9032240B2 (en) * 2009-02-24 2015-05-12 Hewlett-Packard Development Company, L.P. Method and system for providing high availability SCTP applications
CN101635726B (zh) * 2009-08-26 2012-07-04 中兴通讯股份有限公司 C/s架构中服务端和客户端的业务执行方法及系统
US20130067095A1 (en) * 2011-09-09 2013-03-14 Microsoft Corporation Smb2 scaleout
US20130110781A1 (en) * 2011-10-31 2013-05-02 Wojciech Golab Server replication and transaction commitment
US10454997B2 (en) 2012-09-07 2019-10-22 Avigilon Corporation Distributed physical security system
US20140337478A1 (en) * 2013-05-07 2014-11-13 Social Communications Company Peer-to-peer network communications
US9519925B2 (en) 2013-08-01 2016-12-13 Omnibazaar, Inc. Decentralized internet shopping marketplaces
US10263836B2 (en) * 2014-03-24 2019-04-16 Microsoft Technology Licensing, Llc Identifying troubleshooting options for resolving network failures
US10409827B2 (en) * 2014-10-31 2019-09-10 21, Inc. Digital currency mining circuitry having shared processing logic
US10262161B1 (en) * 2014-12-22 2019-04-16 Amazon Technologies, Inc. Secure execution and transformation techniques for computing executables
US10484168B2 (en) * 2015-03-02 2019-11-19 Dell Products L.P. Methods and systems for obfuscating data and computations defined in a secure distributed transaction ledger
US20170048209A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
KR101637854B1 (ko) * 2015-10-16 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 공인인증서 발급시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 발급방법 및 블록체인을 기반으로 하는 공인인증서 인증시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 인증방법
CN105488665A (zh) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 一种去中心化的交易方法
CN105450757A (zh) * 2015-12-02 2016-03-30 联动优势电子商务有限公司 一种服务管理方法及系统
CN113159948A (zh) 2016-01-24 2021-07-23 杭州复杂美科技有限公司 区块链撮合交易所
KR101637868B1 (ko) * 2016-02-22 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
CN106022681A (zh) 2016-05-13 2016-10-12 杭州云象网络技术有限公司 一种基于区块链的物流追踪方法
CN106060036B (zh) * 2016-05-26 2019-07-16 布比（北京）网络技术有限公司 去中心化共识方法及装置
US10713731B2 (en) * 2016-07-22 2020-07-14 Nec Corporation Method for secure ledger distribution and computer system using secure distributed ledger technology
CN106327173A (zh) * 2016-08-22 2017-01-11 布比（北京）网络技术有限公司 网络支付方法及装置
KR101781583B1 (ko) * 2016-08-31 2017-09-27 서강대학교산학협력단 블록체인을 기반으로 한 파일 관리/검색 시스템 및 파일 관리/검색 방법
CN106446067B (zh) * 2016-09-06 2020-02-18 联动优势科技有限公司 一种获取交易数据的方法和装置
CN106357644B (zh) * 2016-09-21 2019-07-12 江苏通付盾科技有限公司 基于区块链网络的身份认证方法、系统及服务器
US11128603B2 (en) * 2016-09-30 2021-09-21 Nec Corporation Method and system for providing a transaction forwarding service in blockchain implementations
CN106534273B (zh) * 2016-10-31 2022-04-15 中金云金融（北京）大数据科技股份有限公司 区块链元数据存储系统及其存储方法与检索方法
CN108075956B (zh) * 2016-11-16 2020-05-22 新华三技术有限公司 一种数据处理方法和装置
EP3331217A1 (en) * 2016-12-02 2018-06-06 HOB GmbH & Co. KG Method for connecting a client to a server in a communication system
CN106982203B (zh) * 2017-01-06 2020-05-22 中国银联股份有限公司 基于区块链技术的鲁棒的atm网络系统及其信息处理方法
CN111614655A (zh) * 2017-03-24 2020-09-01 创新先进技术有限公司 一种共识校验的方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170031676A1 (en) * 2015-07-27 2017-02-02 Deja Vu Security, Llc Blockchain computer data distribution
CN106384236A (zh) * 2016-08-31 2017-02-08 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN106385319A (zh) * 2016-09-29 2017-02-08 江苏通付盾科技有限公司 区块链网络中信息的验证方法及系统
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
CN107395659A (zh) * 2017-03-28 2017-11-24 阿里巴巴集团控股有限公司 一种业务受理及共识的方法及装置

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112215608A (zh) * 2019-01-18 2021-01-12 创新先进技术有限公司 数据处理方法和装置
EP3859647A4 (en) * 2019-01-18 2021-11-24 Advanced New Technologies Co., Ltd. METHOD AND DEVICE FOR GENERATING A BLOCKCHAIN TRANSACTION
US11283627B2 (en) 2019-01-18 2022-03-22 Advanced New Technologies Co., Ltd. Method and apparatus for generating blockchain transaction
US11895248B2 (en) 2019-01-18 2024-02-06 Advanced New Technologies Co., Ltd. Method and apparatus for generating blockchain transaction
EP3691223A1 (en) * 2019-01-31 2020-08-05 Fujitsu Limited Communication device and communication method used in distributed network
CN110135194A (zh) * 2019-05-20 2019-08-16 北京邮电大学 一种基于区块链的工业互联网数字对象的管理方法
CN112131313A (zh) * 2020-09-16 2020-12-25 浙江工商大学 一种基于区块链的加油数据管理系统及其方法
CN112131313B (zh) * 2020-09-16 2024-04-09 浙江工商大学 一种基于区块链的加油数据管理系统及其方法
CN114866615A (zh) * 2022-05-24 2022-08-05 深圳点宽网络科技有限公司 基于区块链的服务调用方法、装置、系统及电子设备
CN116260707A (zh) * 2023-05-15 2023-06-13 安徽中科晶格技术有限公司 基于共识的区块链节点灾备方法、装置、设备及存储介质
CN116260707B (zh) * 2023-05-15 2023-10-10 安徽中科晶格技术有限公司 基于共识的区块链节点灾备方法、装置、设备及存储介质

Also Published As

Publication number Publication date
AU2018243075B2 (en) 2020-06-18
EP3547648A4 (en) 2020-01-08
CN113766035B (zh) 2023-05-23
US11943317B2 (en) 2024-03-26
US10681175B2 (en) 2020-06-09
TWI686709B (zh) 2020-03-01
TW201837734A (zh) 2018-10-16
MY194387A (en) 2022-11-30
CA3048737A1 (en) 2018-10-04
JP6773912B2 (ja) 2020-10-21
US20210337045A1 (en) 2021-10-28
MX2019007812A (es) 2019-09-05
KR20190093598A (ko) 2019-08-09
CN107395659B (zh) 2021-08-24
BR112019013204A2 (pt) 2019-12-10
BR112019013204B1 (pt) 2022-04-19
CA3048737C (en) 2022-07-12
PH12019501538A1 (en) 2020-03-16
US20190342422A1 (en) 2019-11-07
EP3547648A1 (en) 2019-10-02
US11057493B2 (en) 2021-07-06
CN107395659A (zh) 2017-11-24
US20200287987A1 (en) 2020-09-10
KR102152556B1 (ko) 2020-09-07
AU2018243075A1 (en) 2019-07-11
EP3547648B1 (en) 2021-07-07
CN113766035A (zh) 2021-12-07
RU2735096C1 (ru) 2020-10-28
JP2020508594A (ja) 2020-03-19
ZA201904230B (en) 2021-05-26
PH12019501538B1 (en) 2020-03-16

Similar Documents

Publication Publication Date Title
WO2018177239A1 (zh) 一种业务受理及共识的方法及装置
EP3547170B1 (en) Blockchain-based consensus method and device
TWI685764B (zh) 共識校驗的方法及裝置
US10789085B2 (en) Selectively providing virtual machine through actual measurement of efficiency of power usage
WO2018161901A1 (zh) 一种共识方法及装置
US10554388B2 (en) Service execution method and device
US11563805B2 (en) Method, apparatus, client terminal, and server for data processing
WO2018233630A1 (zh) 故障发现
WO2019144809A1 (zh) 一种服务更新方法及装置、系统
US11106488B2 (en) Blockchain read/write data processing method, apparatus, and server

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3048737

Country of ref document: CA

Ref document number: 20197018692

Country of ref document: KR

Kind code of ref document: A

Ref document number: 2019535947

Country of ref document: JP

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112019013204

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2018775664

Country of ref document: EP

Effective date: 20190624

ENP Entry into the national phase

Ref document number: 2018243075

Country of ref document: AU

Date of ref document: 20180326

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

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20190625