WO2018214835A1

WO2018214835A1 - Block chain service acceptance and consensus method and device

Info

Publication number: WO2018214835A1
Application number: PCT/CN2018/087603
Authority: WO
Inventors: 唐强
Original assignee: 阿里巴巴集团控股有限公司; 唐强
Priority date: 2017-05-22
Filing date: 2018-05-21
Publication date: 2018-11-29
Also published as: TWI679547B; US10938577B2; US20190327097A1; CN107395665A; KR102204256B1; EP3886403B1; PH12019501563A1; MY194420A; ES2876943T3; TW201901478A; EP3550803A4; JP2020512610A; SG10202101555QA; CN107395665B; SG11201906166YA; PL3550803T3; KR20190092483A; EP3550803B1; EP3550803A1; JP6949118B2

Abstract

Disclosed are a block chain service acceptance and consensus method and device. A consensus node comprises a first application, a second application, and a database, and the database is used for storing service data processed by the first application and the second application in order to reduce cache pressure of the consensus node. Hence, based on the method provided by embodiments of the invention, as long as the consensus node determines service data corresponding to a service request, the service data can be stored into the database to wait for being sent to other consensus nodes, so that an occupancy rate of the cache of the consensus node is low, the number of services which can be processed by the consensus node in unit time is increased, and efficiency of carrying out consensus verification on the consensus node and processing the service request can be improved.

Description

Blockchain business acceptance and business consensus method and device

Technical field

The present application relates to the field of information technology, and in particular, to a blockchain service acceptance and business consensus method and apparatus.

Background technique

With the development of information technology, blockchain technology, as an emerging technology, has become a key technology because of its openness, inability to modify, and decentralization.

In the existing blockchain technology, each consensus node in the blockchain network can accept the service request sent by the client. Taking a consensus node as an example, when the consensus node receives the service request, it can first determine the corresponding service data according to the service request. The consensus node can then broadcast the business data to other consensus nodes. After the consensus node receives the pre-processing block sent by other consensus nodes, the pre-processing can be quickly verified by consensus, and the pre-processing block can be stored after the verification is passed.

After the service node receives the service request, the consensus node generally stores the service data corresponding to the service request in the cache of the consensus node. After the subsequent verification of the service data is passed, the service data is released from the cache. Similarly, the service data sent by other consensus nodes can also be stored in the cache and released after passing the consensus check.

For the consensus node, the data that is not stored in the blockchain is temporarily stored in the cache of the consensus node. When the consensus check is performed, the number of service data that can be verified is limited by the cache capacity of the consensus node. The efficiency of consensus verification is limited. Moreover, when the cache space of the consensus node is insufficient, the consensus node is also difficult to process the received service request.

Summary of the invention

The embodiment of the present application provides a blockchain service acceptance and service consensus method, which is used to solve the problem of low efficiency of service execution in the existing blockchain technology.

The embodiment of the present application provides a blockchain service acceptance and service consensus device, which is used to solve the problem of low efficiency of service execution in the existing blockchain technology.

The embodiments of the present application adopt the following technical solutions:

A blockchain service acceptance method includes a first application, a second application, and a database, including:

Receiving, by the first application, a service request sent by the client, and determining corresponding service data to be sent according to the service request;

The first application stores the service data to be sent in the database;

When the preset condition is met, the second application or the first application sends the service data to be sent from the database to other consensus node storage.

A blockchain business consensus method, the first consensus node includes a first application, a second application, and a first database, including:

The first application receives consensus data and stores it in the first database;

The second application extracts the consensus data from the first database, and performs consensus verification;

The second application adds the verification result to the consensus data and stores it to the first database, and sends the verification result to other consensus nodes to continue the consensus check.

A blockchain service receiving device includes a device, a second application, and a database, and the device includes:

The receiving module receives the service request sent by the client, and determines corresponding service data to be sent according to the service request;

a storage module, where the service data to be sent is stored in the database;

When the preset condition is met, the second application or the sending module sends the service data to be sent from the database to other consensus node storage.

A blockchain service consensus device, the first consensus node includes a receiving module, a processing sending module, and a first database, and the device includes:

The receiving module receives consensus data and stores it in the first database;

The processing sending module extracts the consensus data from the first database, and performs consensus verification;

The processing sending module adds the verification result to the consensus data and stores the result to the first database, and sends the verification result to other consensus nodes to continue the consensus verification.

The above at least one technical solution adopted by the embodiment of the present application can achieve the following beneficial effects:

The first application, the second application, and the database exist in the consensus node. The database is used to store the business data processed by the first application and the second application, so as to reduce the cache pressure of the consensus node. It can be seen that, by using the method provided by the embodiment of the present application, since the consensus node only needs to determine the service data corresponding to the service request, the service data can be stored in the database and waiting to be sent to other consensus nodes, so the cache occupancy rate of the consensus node is compared. low. The number of services that the consensus node can process in a unit time is increased, thereby improving the efficiency of the consensus node for performing consensus verification and processing the service request.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the present application, and are intended to be a part of this application. In the drawing:

FIG. 1 is a blockchain service acceptance process according to an embodiment of the present application;

FIG. 2 is a blockchain business consensus process according to an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a blockchain service receiving apparatus according to an embodiment of the present disclosure;

FIG. 4 is a schematic structural diagram of a blockchain service consensus apparatus according to an embodiment of the present disclosure.

detailed description

The technical solutions of the present application will be clearly and completely described in the following with reference to the specific embodiments of the present application and the corresponding drawings. It is apparent that the described embodiments are only a part of the embodiments of the present application, and not all of them. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

FIG. 1 is a blockchain consensus process according to an embodiment of the present disclosure. The consensus node includes a first application, a second application, and a database, and specifically includes the following steps:

S101: The first application receives a service request sent by the client, and determines corresponding service data to be sent according to the service request.

In the embodiment of the present application, for each consensus node in the blockchain network, the consensus node may include one or more blockchain applications and a database. The blockchain application can accept the service request and perform consensus verification on the pre-processing block, and the database is used to store the service data determined by the blockchain application (for example, the data generated during the consensus verification process is generated after the service request is accepted). Data, etc.).

Further, the user usually needs to send an instruction or request through the client. Subsequently, the consensus node can receive the service request sent by the client and perform subsequent steps according to the service request.

The consensus node can receive the service request sent by multiple clients, and perform service processing according to each service request. The consensus node can be a terminal, such as a mobile phone, a tablet, a personal computer, or the like. The consensus node may also be a server, and the server may be a single device or a system composed of multiple devices, for example, a distributed server. This application does not specifically limit the specific node of the consensus node.

Specifically, when the consensus node receives the service request, the first application installed in the consensus node may receive the service request. And in the subsequent step, the first application determines the corresponding business logic according to the service request, and allocates the thread to execute the service. Certainly, the application installed in the consensus node may also have multiple (for example, the second application), and each application may separately receive the service request sent by different clients, and perform subsequent operations separately. For convenience of description, in the embodiment of the present application, only the first application and the second application are included in the consensus node as an example, but there is no limitation that there are more applications in the consensus node.

Further, the consensus node may also be a system composed of multiple devices, and each device correspondingly installs a blockchain application, and each device may separately receive service requests sent by different clients through the installed blockchain application, and independently Follow up.

In addition, regardless of whether multiple applications are installed in the consensus node or composed of multiple devices, the consensus node can be regarded as a node that accepts service requests and can initiate consensus in the blockchain network. How the specific consensus nodes are constructed can be configured as needed. For example, when the operating pressure of the consensus node is large and there are often business requests queued for processing, more applications or more devices can be configured for the consensus node.

Further, in the embodiment of the present application, after the first application applies the service processing to the received service request, the service processing result may be used as the service data. Moreover, since the service data has not been sent to other consensus nodes, the first application may also determine that the status of the service data is a pending status. The service data and its corresponding pending status are stored in a database.

Alternatively, the first application may add an identifier to be sent for the service data after determining the service data. The service data to which the identifier to be sent is added is stored in the database as the service data to be sent. The second application may determine, according to the identifier to be sent, the service data as the service data to be sent.

The present application does not limit the manner in which the consensus node determines the status of the service data. As long as each application or each device in the consensus node can determine the state of the stored service data when accessing the database.

For example, if the user wants to conduct a transaction service, the service request sent by the user may carry the identity information of the transaction parties, the transaction amount, and the account information of the paying party. The first application of the consensus node can determine and create a corresponding transaction service according to the data carried in the service request. After determining the service data, the first application adds an identifier to be sent for the service data.

The to-be-sent identifier may also be added to the service data as a service attribute in the service data, for example, the structure of the service data shown in Table 1.

业务属性Business attribute	内容content
业务标识Business identifier	在区块链中的唯一标识Unique identifier in the blockchain
版本version	业务创建时区块链版本标识Service creation blockchain version identifier
时间戳Timestamp	业务创建时的时间戳Timestamp when the business was created
业务信息Business information	业务的具体内容Specific content of the business
状态标识Status identifier	待发送的标识ID to be sent

Table 1

The status identifier in the structure diagram of the service data shown in Table 1 may be added to the service data by the first application of the consensus node. Through the status identifier, any application in the consensus node can determine that the current status of the service data is the pending status. Then, when the service data is operated, according to the status identifier, it may be determined that the service data needs to be sent to other consensus nodes.

Certainly, the content of the service data specifically included in the embodiment of the present application, and the specific attributes included in the service attribute are not specifically limited.

S102: The first application stores the service data to be sent in the database.

In the embodiment of the present application, the service data process to be sent determined in step S101 depends on the cache of the consensus node, so the service data is also stored in the cache. Thus, the first application can also dump the business data to the database in the consensus node to free up the cache space for performing other services.

Specifically, the database may be a storage device used by the consensus node for storing data, and may be a storage device using a non-volatile memory. Of course, the database and the consensus node may be located in the same device (for example, the database may be located in the hard disk of the personal computer), or may be located in a different device (for example, an external mobile hard disk), which is not specifically limited in this application.

In addition, when multiple blockchain applications are installed in the consensus node, each application can separately receive service requests sent by different clients. The respective determined business data is stored in the database. The database can be regarded as a database shared by each application, and each application can have the right to access the database. That is to say, the second application can also determine the service data to be transmitted and store it in the database.

Further, since the consensus node may be a system composed of multiple devices, in the step S101, when the consensus node is a system composed of multiple devices, each device of the consensus node can access the database, and the database is in the database. The consensus node can be regarded as a storage device shared by each device.

Therefore, the first application of the consensus node stores the service data to be sent in the database, and releases the cache space occupied by the service data for performing other services. This consensus node can accept more service requests without increasing the hardware configuration of the consensus node.

S103: When the preset condition is met, the second application or the first application sends the service data to be sent from the database to other consensus node storage.

In the embodiment of the present application, after the first application of the consensus node stores the service data to be sent in the database, the first application of the consensus node may continue to receive the service request sent by other clients. And performing the same operations as step S101 and step S102 (the second application of the same consensus node can also perform the same operations of step S101 and step S102 simultaneously). Therefore, the database corresponding to the consensus node can store a plurality of service data to be sent. In order for other consensus nodes to perform consensus verification normally, the service data stored in the database of the consensus node also needs to be sent to other consensus nodes for storage.

Therefore, in the embodiment of the present application, when the pre-condition is met, the first or second application of the consensus node may also retrieve the service data to be sent from the database and send it to other consensus nodes for storage, so that other consensus nodes may follow the consensus. check. And, for each service data to be sent, after the service data to be sent is sent, the service data to be sent may also be updated as the sent service data.

Specifically, at least one of the first application or the second application in the consensus node may determine whether the preset condition has been met according to the current state of the consensus node. If yes, the first application and/or the second application fetches the service data to be sent and sends, and if not, does not fetch.

The current state of the consensus node meets the preset condition when the number of the service data to be sent stored in the database of the consensus node reaches a preset threshold. Or, according to the sending period of the consensus node, when the specified time arrives, it is determined that the preset condition is met, that is, the service data to be sent in the data is periodically retrieved, and the like.

Of course, the preset conditions can also be set according to actual needs. For example, the preset conditions may also change with time factors and business volume. When the time is night (eg, 4:00 to 4 o'clock), the interval between fishing data is increased, and when the traffic increases, the fishing amount is reduced. The time interval of the service data and the like are not specifically limited in this application.

In addition, when the first application or the second application is capturing the service data to be sent, all the service data to be sent in the database corresponding to the consensus node may be extracted and sent. A specified number of service data to be sent may also be retrieved, which is not specifically limited in this application. Further, the above conditions may be used alternatively or in any combination.

Further, when the first application or the second application extracts the service data to be sent from the database, the service data to be sent may be retrieved according to the chronological order of the service data to be sent. The collected business data to be sent is sent to other consensus nodes in the order of retrieval. Specifically, the consensus node may retrieve and send each service data to be sent one by one, or may collect and package each service data to be sent, and then send it to other consensus nodes.

Further, the first application or the second application may further update the sent service data to be sent to each sent service data.

For example, after the first application retrieves the service data F from the database and sends it, the status corresponding to the service data F in the database may be updated to the sent status. Alternatively, the status identifier in the service attribute of the service data F is updated to the sent identifier. That is to say, the first application can update the status identifier of the service data F when the service data F is called.

Of course, due to problems such as network delay or device failure, service data transmission failure may occur. Therefore, in the embodiment of the present application, the first application or the second application may also update the status identifier of the service data according to the response information when receiving the response information for the sent service data returned by the other consensus node. Which method is specifically adopted is not specifically limited in this application.

Based on the blockchain service acceptance method shown in FIG. 1, it can be seen that the consensus node can include the first application, the second application, and the database. The database is used to store the business data processed by the first application and the second application, so as to reduce the buffer pressure of the consensus node. The consensus node can continue to receive service requests and accept services even while waiting for the consensus phase, without causing service waiting due to insufficient cache space. At the same time, since the business data is stored in the database, the consensus node can expand the number of installed applications as needed. The consensus node can receive and process more service requests at the same time, and improve the working efficiency of the consensus node. Moreover, when the preset condition is met, the first or second application in the consensus node may be used to retrieve the service data to be sent stored in the database, and send the data to the other consensus node for storage. It can be seen that, by the method provided by the present application, the operating efficiency of the consensus node is no longer limited by the cache size. Moreover, since each application in the consensus node can accept the service request and send the service data, the consensus node can send the service data to be sent through some applications, and the other part applies the service request, and the consensus node is used for the consensus check and the service. The efficiency of requesting processing.

In addition, in the embodiment of the present application, when the first or second application sends the service data to be sent, the status of the service data may be updated to the sent status, so that the service data received and stored by other consensus nodes is The status has been sent. Therefore, when other consensus nodes perform consensus verification according to the service data, the service data sent by the first or second application is not missed.

Further, in the embodiment of the present application, after receiving the service data sent by other consensus nodes, the first application may also check the service data to be sent according to the hash value of the service data and the specific content of the service data. And after the verification is passed, the business data is stored in the database.

Further, in step S101 of the present application, as in the prior art, the consensus node can verify the data required for performing the service processing carried in the service request when determining the service request. Then, after the verification is passed, operations such as subsequent creation of services and business processing are continued. Specifically, the verification process and the implementation details may be consistent with the prior art, and details are not described herein again.

In addition, in the embodiment of the present application, after determining the service data to be sent, the consensus node may return response information corresponding to the service request to the client, so that the client determines that the consensus node has accepted the service request. It should be noted that when the consensus node determines the service data according to the service request, it can be regarded as the consensus node accepting the service request.

It should be noted that the execution bodies of the steps of the method provided by the embodiment of the present application may all be the same device, or the method may also be performed by different devices. For example, the execution body of step S101 and step S102 may be device 1, and the execution body of step S103 may be device 2; for example, the execution body of step S101 may be device 1, and the execution body of step S102 and step S103 may be device 2 ;and many more.

Based on the blockchain service acceptance method shown in FIG. 1, the embodiment of the present application further provides a method for the blockchain service consensus, as shown in FIG. 2 .

2 is a process of a blockchain service consensus process according to an embodiment of the present disclosure, where the first consensus node includes a first application, a second application, and a first database, and specifically includes the following steps:

S201: The first application receives consensus data and stores it in the first database.

In the embodiment of the present application, similar to the consensus node described in the blockchain service acceptance process shown in FIG. 1, the first consensus node includes a first application, a second application, and a first database. Moreover, more applications may be included in the first consensus node, which is not limited in this application. For the convenience of the following description, the first application and the second application are taken as an example in the embodiment of the present application.

Generally, each consensus node in the blockchain network can determine the consensus node that initiates the consensus according to the consensus mechanism of the blockchain. Thus, the first application of the first consensus node can receive the consensus data and store the consensus data in the first database.

In addition, in some consensus algorithms, the consensus node may determine whether to store consensus data according to the verification results of other consensus nodes. For example, in some consensus algorithms, for each consensus node, the consensus node needs to determine whether more than 50% of the consensus node check results in the consensus node of the entire network pass, and if so, the consensus node stores the pre-processing Block, if no, it is not stored.

Therefore, the verification result can also be regarded as a kind of consensus data, and the consensus data in the present application may include: data that needs to be subjected to consensus verification (usually fast preprocessing) and corresponding verification result.

Of course, regardless of the form of consensus data received by the first application, the first application can store the consensus data in the first database.

S202: The second application extracts the consensus data from the first database, and performs consensus verification.

In the embodiment of the present application, the second application may extract consensus data from the first database and verify the consensus data for subsequent operations.

Specifically, the second application may obtain consensus data (specifically, a pre-processing block) from the first database, and service data of the sent status in the first database, and perform consensus prediction on the consensus data according to the service data of the sent status. Check and determine the verification result.

S203: The second application adds the verification result to the consensus data and stores the result to the first database, and sends the verification result to other consensus nodes to continue the consensus verification.

In the embodiment of the present application, after the second application determines the verification result, the verification result may be stored in the first database and sent to other consensus nodes to continue the consensus verification. The order in which the second application stores and transmits the verification data is not limited in this application.

In addition, in step S201 to step S203 of the embodiment of the present application, the consensus mechanism of the blockchain may be a practical Byzantine Fault Tolerance (PBFT), and the consensus nodes in the blockchain network may be according to the formula: ID/M, determines the master node in each consensus node, and the master node initiates a consensus. For each consensus node, the consensus node may first determine the current period (ie, View) of the consensus node, and the View ID represents the identifier of the current period determined by the consensus node. Usually the period is identified by a number between 0 and M-1, and M is the total number of consensus nodes in the blockchain network.

Specifically, the second consensus node is the main node and a consensus is initiated, and the first consensus node is a consensus check of the slave node as an example. The second consensus node includes a third application, a fourth application, and a second database. The third application creates a pre-processing block based on the service data of the sent status in the second database, and stores the pre-processed block in the second database. The fourth application extracts the pre-processing block from the second database and sends it to each consensus node except the second consensus node.

First, the third application of the second consensus node can determine that the second consensus node is the master node by using the current View ID. Then, the third application may extract, from the second database, each sent service data that needs to be consensus according to a pre-set consensus condition. The preset consensus condition may be set according to requirements, and the application does not specifically limit this. For example, the business data for which consensus is selected is selected in chronological order, or each transmitted service data that satisfies the capacity is selected according to the capacity of the pre-processing block, and the like.

Secondly, the third application can create a corresponding pre-processing block according to each of the sent service data. For example, determining the order in which the service data has been sent in the pre-processing block, determining the header hash value of the pre-processing block by Merkle trees, and the like. Specifically, in the embodiment of the present application, the process of creating a pre-processing block may be the same as the prior art, which is not specifically limited in this application.

Thirdly, the third application can determine the Per-Perpared information corresponding to the pre-processing block according to the first stage of the PBFT three-phase protocol, in the same manner as the prior art, wherein the format of the Per-Perpared information Can be <Per-Perpared, v, n, d>, where v represents the number of the current View ID, n represents the identity of the pre-processing block, and d is the digest of the pre-processing block. After the third application can sign the Per-Perpared information, the Per-Perpared information and the pre-processing block are stored in the second database.

From time to time, the fourth application can extract Per-Perpared information and pre-processing blocks from the database and send them to the consensus nodes except the second consensus node. So that other consensus nodes check the Per-Perpared information. Then, as described in step S201, the first application may receive the Per-Perpared information and the pre-processing block as consensus data, and store it in the first database.

Then, as described in step S202, the second application may retrieve consensus data from the first database (eg, the second application may retrieve Per-Perpared information and pre-processing blocks) and perform consensus verification. Specifically, the second application may verify the signature of the Per-Perpared information, and determine that the Per-Perpared information is sent by the second consensus node. The digest of the Per-Perpared information is also verified according to the service data in the pre-processing block, and the digest correspondence in the pre-processing block and the Per-Perpared information is determined. At the same time, it is also possible to judge whether the n in the Per-Perpared information meets the preset water mark, and whether the v in the Per-Perpared information is consistent with the v at which the first consensus node is currently located.

Since the consensus node for the Per-Perpared information check is determined in the PBFT, the next phase (ie, the second phase) will be automatically executed, so the Per-Perpared information can be obtained after the second application verifies the Per-Perpared information. The pre-processing block and the received response information are stored in the first database, and preparation information (Perpared information) is created as a verification result. The format of the Perpared information can be <Perpared, v, n, d, i>, where i is the identity of the consensus node that created the Perpared information. Thus, the second application can also store the Perpared information in the first database.

The second application can then send the Perpared information to other consensus nodes to continue the consensus check. Moreover, other consensus nodes that verify the Per-Perpared information can also broadcast the Perpared information created by itself and then broadcast it. Thus, each consensus node in the blockchain network can receive the Perpared information sent by the consensus node that verifies the Per-Perpared information, and for each consensus node, the consensus node can receive the other The Perpared information sent by the consensus node is stored in its own database.

Therefore, in the embodiment of the present application, the first application of the first consensus node may again receive the verification result sent by other consensus nodes (that is, the Perpared information sent by other consensus nodes), and store it in the first database. The second application may verify the v, n, signature, and digest of each Perpared information stored in the first database. When the second application determines that the number of pieces of Perpared information stored in the first database stored by the verification is greater than or equal to a preset number, the next stage (ie, the third stage) is automatically executed. The preset number is the same as the prior art, and is determined by the PBFT calculation for the consensus node, and is not described herein again.

Thereafter, in the third phase of the three-phase protocol, when the second application determines to perform the third phase, confirmation information (Commit information) may be created, and Commit information may be sent to other consensus nodes. Similarly, the third or fourth application of the second consensus node may also send Commit information when determining to perform the third phase. The first application may receive Commit information sent by other consensus nodes and store it in the first database. The Commit information format may be <Commit, v, n, D, i>, where D is a summary of the pre-processing block created by the consensus node.

Finally, the second application may verify the v, n, signature, and digest of the Commit information sent by the other consensus nodes stored in the first database, and determine the pre-determination when it is determined that the Commit information of the verification is greater than or equal to the preset quantity. The processing block passes the consensus check.

Wherein, for each consensus node in the blockchain network, the consensus node in each phase of the three-phase protocol receives data from other consensus nodes, creates information, and the like, and generates data during consensus verification. Stored in the database corresponding to the consensus node.

Of course, it should be noted that in the embodiment of the present application, the steps performed by the second application may be performed by the first application, and vice versa. Similarly, the steps performed by the third application can also be performed by the fourth application, and vice versa.

In addition, for each consensus node, since the consensus nodes need to send and receive information of other consensus nodes during the execution of the three-phase protocol, and the information may be transmitted through the network, network delay may occur, so in the three-phase protocol At each stage, each consensus node can wait for a period of time to receive information. Thus, during the execution of the three-phase protocol, the consensus node can store the created and received information in the database first. At the end of each phase of the waiting time, based on the information stored in the database, determine whether to proceed to the next stage.

Further, in the embodiment of the present application, in the first phase of the three-phase protocol (that is, the phase of Per-Perpared), the second consensus node (ie, the master node) that initiates the consensus may preprocess the block, and preprocess The hash values of the service data in the block are sent to the consensus nodes of the second consensus node, and the consensus nodes that receive the Per-Perpared information can create a pre-processing block according to the hash value of each service data. And compare and verify with the pre-processing block sent by the master node.

Further, in the embodiment of the present application, for each consensus node, the consensus node is consistent with the prior art when performing consensus verification, and the consensus nodes may also perform verification according to the consensus condition and the consensus node, ie, It is determined whether the primary node sends each service data as service data that can perform consensus verification. If yes, the subsequent consensus verification is continued, and if not, the consensus verification is stopped.

Based on the blockchain service consensus method shown in FIG. 2, the first consensus node includes a first application, a second application, and a first database. When the consensus is performed, the first application receives the consensus data and stores the data in the first database. The second application retrieves the consensus data from the first database and performs consensus verification. The second application adds the verification result to the consensus data and stores it to the first database, and sends the verification result to other consensus nodes to continue the consensus. check. The third application of the second consensus node that initiates the consensus creates the pre-processing block as the consensus data is stored in the second data according to the sent service data stored in the second database, and the fourth application obtains the consensus from the second database. The data is sent to each consensus node other than the second consensus node. It can be seen that, in the embodiment of the present application, the consensus node can use the three-phase protocol of the PBFT to implement the consensus, and store the data generated in each stage in the database, reduce the cache occupancy rate during the consensus check, and improve the cache utilization. This improves the efficiency of the consensus node for consensus checking and processing of business requests.

It should be noted that the execution bodies of the steps of the method provided by the embodiment of the present application may all be the same device, or the method may also be performed by different devices. For example, the execution body of step S201 and step S202 may be device 1, and the execution body of step S203 may be device 2; for example, the execution body of step S201 may be device 1, and the execution body of step S202 and step S203 may be device 2 ;and many more.

Based on the blockchain service receiving method shown in FIG. 1, the embodiment of the present application further provides a blockchain service receiving device, as shown in FIG.

FIG. 3 is a schematic structural diagram of a blockchain service receiving apparatus according to an embodiment of the present disclosure, where the consensus node includes the device, a second application, and a database, and the device includes:

The receiving module 301 receives a service request sent by the client, and determines corresponding service data to be sent according to the service request;

The storage module 302 stores the service data to be sent in the database;

When the preset condition is met, the second application or sending module 303 extracts the service data to be sent from the database and sends it to other consensus node storage.

The storage module 302 determines that the status of the service data to be sent is a to-be-sent state, and stores the service data and its corresponding to-be-sent status in the storage module.

When the specified time arrives, it is determined that the preset condition is satisfied.

The sending module 303 extracts a specified number of service data to be sent from the database.

The device also includes:

The update module 304 updates the status of the transmitted service data in the database to the sent status.

Specifically, the blockchain service receiving device may be located in the consensus node, and the consensus node may be a terminal. For example, mobile phones, tablets, personal computers and other equipment. Alternatively, the consensus node can also be a server. For example, a single server, or a system consisting of multiple servers.

Based on the blockchain service consensus method shown in FIG. 2, the embodiment of the present application further provides a blockchain service consensus device, as shown in FIG. 4 .

4 is a schematic structural diagram of a blockchain service consensus device according to an embodiment of the present disclosure. The first consensus node includes a first application, the device, and a first database, where the device includes:

The receiving module 401 receives the consensus data and stores it in the first database;

The verification module 402: extracts the consensus data from the first database, and performs consensus verification;

The storage sending module 403 adds the verification result to the consensus data and stores it to the first database, and sends the verification result to other consensus nodes to continue the consensus verification.

The receiving module 401 receives the consensus data sent by other consensus nodes, or receives the verification result sent by other consensus nodes, as the consensus data.

The verification module 402 extracts the consensus data and the service data of the sent status in the first database from the first database, and performs consensus on the consensus data according to the service data of the sent status. Check and determine the verification result.

The second consensus node includes a third application, a fourth application, and a second database. Before the receiving module 401 receives the consensus data, the third application determines the consensus data according to the service data of the sent state in the second database. And stored in the second database, the fourth application extracts the consensus data from the second database, and sends the consensus data to each consensus node except the second consensus node.

The consensus check uses the Byzantine fault tolerance algorithm PBFT.

Specifically, a blockchain service receiving apparatus as shown in FIG. 4 may be located in a consensus node, and the consensus node may be a terminal. For example, mobile phones, tablets, personal computers and other equipment. Alternatively, the consensus node can also be a server. For example, a single server, or a system consisting of multiple servers.

In the 1990s, improvements to a technology could clearly distinguish between hardware improvements (eg, improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (for process flow improvements). However, as technology advances, many of today's method flow improvements can be seen as direct improvements in hardware circuit architecture. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented by hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. Designers program themselves to "integrate" a digital system on a single PLD without having to ask the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, today, instead of manually making integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in programming development, but before compiling The original code has to be written in a specific programming language. This is called the Hardware Description Language (HDL). HDL is not the only one, but there are many kinds, such as 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), etc., are currently the most commonly used VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be apparent to those skilled in the art that the hardware flow for implementing the logic method flow can be easily obtained by simply programming the method flow into the integrated circuit with a few hardware description languages.

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. In the form of logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, 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. Those skilled in the art will also appreciate that in addition to implementing the controller in purely computer readable program code, the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding. The form of a microcontroller or the like to achieve the same function. 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. Or even 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. Specifically, 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.

For the convenience of description, the above devices are described separately by function into various units. Of course, the functions of each unit may be implemented in the same software or software and/or hardware when implementing the present application.

Those skilled in the art will appreciate that 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.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

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.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and 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. 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. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It is also to be understood that the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, Other elements not explicitly listed, or elements that are inherent to such a process, method, commodity, or equipment. An element defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device including the element.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, 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. Moreover, 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. Generally, 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. In a distributed computing environment, program modules can be located in both local and remote computer storage media including storage devices.

The various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

The above description is only an embodiment of the present application and is not intended to limit the application. Various changes and modifications can be made to the present application by those skilled in the art. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the present application are intended to be included within the scope of the appended claims.

Claims

A blockchain service acceptance method includes a first application, a second application, and a database, and the method includes:

Receiving, by the first application, a service request sent by the client, and determining corresponding service data to be sent according to the service request;

The first application stores the service data to be sent in the database;

When the preset condition is met, the second application or the first application sends the service data to be sent from the database to other consensus node storage.
The method of claim 1, before the first application stores the service data to be sent in the database, the method further includes:

Determining, by the first application, a state of the service data to be sent as a to-be-sent state;

The service data and its corresponding to-be-sent status are stored in the database.
The method of claim 1, wherein the predetermined condition is met, specifically comprising:

When the specified time arrives, it is determined that the preset condition is satisfied.
The method of claim 1, the method for extracting service data to be sent from the database, specifically comprising:

A specified amount of business data to be sent is retrieved from the database.
The method of claim 1 wherein the method further comprises:

The status of the transmitted service data in the database is updated to the sent status.
A blockchain service consensus method includes a first application, a second application, and a first database, where the method includes:

The first application receives consensus data and stores it in the first database;

The second application extracts the consensus data from the first database, and performs consensus verification;

The second application adds the verification result to the consensus data and stores it to the first database, and sends the verification result to other consensus nodes to continue the consensus check.
The method of claim 6, wherein the determining, by the first application, the consensus data comprises:

The first application receives consensus data sent by other consensus nodes; or

The first application receives the verification result sent by other consensus nodes as the consensus data.
The method of claim 6, wherein the second application extracts the consensus data from the first database and performs consensus verification, which specifically includes:

The second application extracts the consensus data and the service data of the sent status in the first database from the first database;

Performing consensus verification on the consensus data according to the service data of the sent status, and determining a verification result.
The method according to claim 6, wherein the second consensus node includes a third application, a fourth application, and a second database;

Before the first application receives the consensus data, the method further includes:

The third application determines the consensus data according to the service data of the sent status in the second database, and stores the data in the second database;

The fourth application extracts the consensus data from the second database and sends the consensus data to the consensus nodes except the second consensus node.
The method according to any one of claims 6 to 9, wherein the consensus check uses a Byzantine fault tolerance algorithm PBFT.
A blockchain service receiving device includes a device, a second application, and a database, and the device includes:

The receiving module receives the service request sent by the client, and determines corresponding service data to be sent according to the service request;

a storage module, where the service data to be sent is stored in the database;

When the preset condition is met, the second application or the sending module sends the service data to be sent from the database to other consensus node storage.
The device of claim 11, wherein the storage module determines that the status of the service data to be sent is a to-be-sent state, and stores the service data and its corresponding to-be-sent status in the storage module.
The apparatus according to claim 11, wherein when the specified time arrives, it is determined that the predetermined condition is satisfied.
The apparatus of claim 11, said transmitting module extracting a specified amount of service data to be transmitted from said database.
The device of claim 11 further comprising:

The update module updates the status of the sent service data in the database to the sent status.
A blockchain service consensus device includes a first application, the device, and a first database, where the device includes:

Receiving module, receiving consensus data, and storing in the first database;

a verification module, extracting the consensus data from the first database, and performing consensus verification;

The storage module adds a verification result to the consensus data and stores the result to the first database, and sends the verification result to other consensus nodes to continue the consensus verification.
The apparatus according to claim 16, wherein the receiving module receives the consensus data sent by the other consensus nodes, or receives the verification result sent by the other consensus nodes as the consensus data.
The apparatus according to claim 16, wherein the verification module extracts the consensus data and the service data of the transmitted state in the first database from the first database, and according to the service data of the sent status Consensus verification is performed on the consensus data, and the verification result is determined.
The apparatus according to claim 16, wherein the second consensus node includes a third application, a fourth application, and a second database, and before the receiving module receives the consensus data, the third application is sent according to the second database Status data, determining consensus data, and storing in the second database, the fourth application extracting the consensus data from the second database and transmitting to each of the second consensus nodes Consensus node.
The apparatus according to any one of claims 16 to 19, wherein the consensus check uses a Byzantine fault tolerance algorithm PBFT.