CN107395353B

CN107395353B - block chain consensus method and device

Info

Publication number: CN107395353B
Application number: CN201710271900.3A
Authority: CN
Inventors: 陈忻
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2017-04-24
Filing date: 2017-04-24
Publication date: 2020-01-31
Anticipated expiration: 2037-04-24
Also published as: CN107395353A

Abstract

The application discloses block chain consensus method and device, after a consensus node receives service data to be stored sent by a service acceptance platform, a preprocessing block can be generated according to the service data to be stored, when the consensus node is a leader node, the preprocessing block can be sent to each next node for consensus check after the consensus check of the preprocessing block is passed, and when the consensus node is not the leader node, the preprocessing block is sent to the leader node.

Description

block chain consensus method and device

Technical Field

The present application relates to the field of information technology, and in particular, to a method and an apparatus for identifying kinds of block chains.

Background

With the development of information technology, the block chain technology has become a technology of great interest due to its advantages such as openness, non-tamper property, and decentralization. Due to the decentralized feature of the existing blockchain technology, before the service executed in the blockchain is stored in the blockchain (i.e., uplink), service data (e.g., a result of processing the service) corresponding to the service also needs to be identified by each node in the blockchain.

The block chain consensus method adopted in the existing block chain technology, such as workload certification, rights and interests certification, and the use of a Byzantine Fault Tolerance algorithm (PBFT), still has the problem of complex consensus process, for example, PBFT requires three-stage consensus, while for a alliance chain or a block chain with lower Fault Tolerance requirements, the complex consensus method is not required, and block chain consensus methods with high efficiency are required.

Disclosure of Invention

The embodiment of the application provides block chain consensus methods for improving the block chain consensus efficiency.

The embodiment of the application provides block chain consensus devices for improving the block chain consensus efficiency.

The embodiment of the application adopts the following technical scheme:

A blockchain consensus method, comprising:

the consensus node receives the service data to be stored sent by the service acceptance platform;

generating a preprocessing block according to the service data to be stored;

if the consensus node is the leader node, performing consensus verification on the preprocessing block, and after the verification is passed, sending the preprocessing block to each subordinate node for consensus verification;

and if the consensus node is not the leader node, sending the preprocessing block to the leader node for consensus verification, so that after the consensus verification of the preprocessing block is passed by the leader node, sending the preprocessing block to each subordinate node for consensus verification.

A blockchain consensus device, comprising:

the receiving module is used for receiving the service data to be stored sent by the service acceptance platform;

the generating module generates a preprocessing block according to the service data to be stored;

if the device is a leader node, a verification sending module is used for carrying out consensus verification on the preprocessing blocks and sending the preprocessing blocks to each subordinate node for carrying out consensus verification after the verification is passed;

and if the device is not the leader node, a verification sending module sends the preprocessing block to the leader node for consensus verification, so that the leader node sends the preprocessing block to each subordinate node for consensus verification after passing the consensus verification of the preprocessing block.

The above-mentioned at least technical scheme that this application embodiment adopted can reach following beneficial effect:

after the consensus node receives the service data to be stored sent by the service acceptance platform, a preprocessing block can be generated according to the service data to be stored, when the consensus node is a leader node, the preprocessing block can be directly subjected to consensus check, after the check is passed, the preprocessing block is sent to each subordinate node for consensus check, when the consensus node is not the leader node, the preprocessing block is sent to the leader node for consensus check, so that after the check is passed, the preprocessing block is sent to each subordinate node for consensus check.

Drawings

The accompanying drawings, which are incorporated herein and constitute part of this application and are included to provide a further understanding of the application, section of the application, illustrate embodiments of the application and together with the description serve to explain the application and not to limit the application.

Fig. 1 illustrates an blockchain consensus process according to an embodiment of the present disclosure;

fig. 2 is a schematic diagram of common nodes in a block chain according to an embodiment of the present disclosure;

fig. 3 is a block structure diagram according to an embodiment of the present disclosure;

fig. 4 is a schematic diagram of a leader node receiving a plurality of preprocessing blocks with the same block height according to an embodiment of the present application;

fig. 5 is another service processing procedures provided in the embodiment of the present application;

fig. 6 is a schematic structural diagram of block chain consensus devices according to an embodiment of the present disclosure;

fig. 7 is a schematic structural diagram of another kinds of service processing devices provided in the embodiment of the present application.

Detailed Description

For purposes of clarity, technical solutions and advantages of the present application, the present application will be described in detail and in full with reference to specific embodiments of the present application and accompanying drawings.

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 another kinds of service processing procedures provided in this embodiment, which may specifically include the following steps:

s101: and the consensus node receives the service data to be stored sent by the service acceptance platform.

In this embodiment of the application, the service accepting platform may be configured to receive a project creation request sent by a project initiator, create a corresponding service project, and when the service project is in a running state, receive a service processing request of a user for the service project, and perform service processing according to the service project and the service processing request.

The business acceptance platform can be a crowd funding platform, the crowd funding platform can receive a crowd funding project creation request sent by a funder and create a corresponding crowd funding project, and can also receive a crowd funding confirmation request sent by a investor, and the crowd funding confirmation request can be a crowd funding confirmation request for the crowd funding project in a funding state. The method and the device continue the following description by taking the example that the crowd funding platform receives the crowd funding project creation request.

In this embodiment, a plurality of consensus nodes may exist in the block chain network, and each consensus node may be a node belonging to different crowd-funding platforms, for example, a crowd-funding platform a and a crowd-funding platform B cooperate to form a crowd-funding alliance, where if the crowd-funding platform a has 2 terminals for receiving service data to be stored, the crowd-funding platform a has 2 consensus nodes, and if the crowd-funding platform B has 1 terminal for receiving service data to be stored, the crowd-funding platform B has 1 consensus node, as shown in fig. 2. It should be noted that, in this embodiment of the application, the to-be-stored business data may be the to-be-stored business data generated by the business acceptance platform (e.g., crowd funding platform) in the business processing process shown in fig. 3 and including the business processing data and the project identifier.

Fig. 2 is a schematic diagram of common recognition nodes in a block chain according to an embodiment of the present disclosure, where different common recognition nodes belong to different crowd funding platforms, and it can be seen that a node a, a node B, and a node c belong to a node of a crowd funding platform a, and a node d and a node e belong to a node of a crowd funding platform B, but the nodes are all common recognition nodes in the block chain network, and may all receive service data to be stored and have a permission to initiate a common recognition.

Therefore, in the embodiment of the application, each consensus node in the block chain network may receive the service data to be stored, and the consensus nodes belonging to different crowd-funding platforms may generally receive only the service data to be stored sent by the crowd-funding platform to which the consensus node belongs.

For the crowd funding platform, the crowd funding platform can be used for propagating crowd funding projects through a channel of the crowd funding platform, can also be used for receiving a crowd funding approval request of a investor through the channel of the crowd funding platform, and can be used for conducting transaction with the investor according to the crowd funding approval request, and corresponding crowd funding shares can be obtained by paying corresponding funds with the investor. Wherein, the channels that crowd funded the platform commonly used include: APP pushed by the crowd-funding platform, web pages of the crowd-funding platform and other channels established by the crowd-funding platform, or the crowd funding platform can also cooperate with a social platform of a third party to promote crowd funding projects of the crowd funding platform through channels of the social platform, and the stock transaction of the crowd-funding project can be carried out through a third-party platform, and the like, the application is used for publicizing the crowd-funding project on the crowd-funding platform, and how to obtain the investment of the following investors is not limited, each crowd-funding platform only needs to determine corresponding business data to be stored according to the transaction business with the following investors and send the business data to a consensus node corresponding to the crowd-funding platform, and then the consensus node is passed through, business data to be stored corresponding to the transaction business between the crowd funding platform and the investor can be used as data of the block chain to be recorded in accounts of all consensus nodes in the block chain network.

In addition, since in the embodiment of the present application, the blockchain is mainly used to solve the problem of co-operation of the crowd-funding platforms, each consensus node in the blockchain network may be considered to belong to a crowd-funding platform (of course, there may be a plurality of crowd-funding platforms as described above), so in the present application, the blockchain may be considered to be a federation blockchain, and each consensus node corresponding to a crowd-funding platform may be considered to be a federation member in the federation blockchain, and has an authority (e.g., viewing, searching, consensus, etc.) to operate in the blockchain network.

, since the blockchain is a federation blockchain, when joining the blockchain network, each consensus node in the blockchain network can broadcast node information of the consensus node into the blockchain network, wherein the node information can be signed by a crowd-funded platform corresponding to the consensus node, so that each consensus node in the blockchain network determines the authenticity of the node information of the consensus node.

It should be noted that the consensus node may be a terminal, such as a device like a mobile phone, a personal computer/tablet computer, or the consensus node may also be a server, and the server may be a server corresponding to the consensus node, and the server may be an individual devices, or a system composed of multiple devices, as long as the device can be used as a consensus node of the blockchain network to receive service data to be stored sent by a crowd funding platform corresponding to the consensus node, and has a right to initiate consensus in the blockchain network, and this application does not limit what specific device of the consensus node is.

S102: and generating a preprocessing block according to the service data to be stored.

In this embodiment, when the consensus node determines that consensus is initiated by the consensus node after receiving the service data to be stored in step S201, the consensus node may create pre-processing blocks to be consensus and write the service data to be stored received in step S201 into the pre-processing blocks.

Since the business processing process involved in the embodiment of the application can be a crowd funding process of crowd funding projects, and the frequency of crowd funding projects by investors in the crowd funding project funding process is generally low relative to the transaction frequency of a transaction platform, the consensus mechanism can be that after any consensus nodes in the block chain network receive business data to be stored, consensus is initiated according to the business data to be stored.

In addition, since the crowd-funding platform in the prior art has a condition that a plurality of tenants jointly rent crowd-funding platforms, wherein each tenant can be regarded as crowd-funding companies which operate independently, a condition that the plurality of crowd-funding companies rent crowd-funding platforms to carry out crowd-funding occurs.

, the business data to be stored may include information such as information of investors, share of credit, amount of credit, crowd funding project of credit, time of credit, etc. since crowd funding platforms may simultaneously develop a plurality of crowd funding projects, the consensus node may receive business data to be stored of different credit projects, it is necessary to determine data such as information of crowd funding projects corresponding to the business data to be stored in the business data to be stored.

Specifically, the pre-processing block created by the consensus node may further write node information of the consensus node itself into the pre-processing block, in addition to the service data to be stored. As described in step S101, the node information may include information of the consensus node and a crowd-funding platform corresponding to the consensus node.

Meanwhile, in order to keep the flexibility of the data recorded in the blockchain, the preprocessing blockchain can reserve specified extension fields, so that the address of the intelligent contract can be written in the extension fields when an intelligent contract is configured in the blockchain later, of course, whether the extension fields are needed in the preprocessing blocks specifically, and the size of the storage space occupied by the extension fields (i.e. the capacity of the extension fields) can be determined by each crowd sourcing platform which creates the blockchain according to the needs of actual applications, which is not limited in the present application.

Fig. 3 is a block structure diagram according to an embodiment of the present disclosure. Wherein the block height is used to indicate the sequential position of the pre-processed block in the blockchain after the pre-processed block is chained, e.g., the block height 175 indicates that the pre-processed block is the 175 th block in the blockchain after the pre-processed block is stored as a block in the blockchain. In addition, the header hash value is a hash value determined by the consensus node according to the data in the pre-processing block, and can be used for other consensus nodes in the blockchain network to determine whether the data in the block is missing or tampered in the transmission process. The block also contains contents such as node information and service processing data.

, the blockchain may be a federation blockchain, and the consensus nodes in the blockchain network may communicate via a private network, thereby avoiding communication via a public network such as the internet, and the like, and may ensure security during data transmission, and each consensus node does not need to sign data (e.g., a blockabstract) in the pre-processing block.

Of course, if the blockchain network uses the public network, the preprocessing block may include at least signatures as described above.

S103: and if the consensus node is the leader node, performing consensus verification on the preprocessing block, and after the verification is passed, sending the preprocessing block to each subordinate node for consensus verification.

In this embodiment, after the consensus node creates the pre-processing block, the pre-processing block needs to be broadcast to other consensus nodes in the blockchain for consensus, and the consensus node may determine a leader node from the consensus nodes in the blockchain network according to a distributed protocol pre-configured for the blockchain, so as to subsequently send the pre-processing block to the leader node for consensus.

In this embodiment, since the blockchain may be regarded as a federation blockchain, the blockchain may determine, using a distributed protocol used by a distributed architecture, a node performing a specific service, i.e., a leader node, and may then synchronize, by the leader node, the pre-processing block of the consensus node to other consensus nodes in the blockchain.

In addition, the distributed protocol may specifically be a Raft protocol, in the Raft protocol, each node in the distributed network may be divided into a leader node (leader node) and a subordinate node (follower node), the leader node has an authority to send heartbeat information to the subordinate node in the distributed network, and the subordinate node in the distributed network may update, after receiving the heartbeat information sent by the leader node, content such as an information log local to the subordinate node, of the heartbeat information. In addition, when a service is initiated by the subordinate node, the subordinate node may transmit the service to the leader node, and be processed by the leader node, or be distributed to other subordinate nodes for processing.

Therefore, in the block chain network provided in the embodiment of the present application, each common node may also be divided into a leader node and a subordinate node, where the subordinate node is a common node that does not have a right to send heartbeat information, and the leader node is a common node that has a right to broadcast heartbeat information.

Step , in this embodiment of the present application, when the distributed protocol is a Raft protocol, since a leader node in the Raft protocol needs to send heartbeat information to each node in the network, when determining the leader node in the blockchain network, the consensus node may determine the leader node through the received heartbeat information, and if the consensus node does not receive the heartbeat information sent by the leader node in a time period corresponding to the heartbeat information, the consensus node may wait for other consensus nodes to initiate election, receive a voting request sent by a candidate node, and select a next appointed leader node by responding to the voting request.

Specifically, when the consensus node is a leader node, the leader node may perform consensus check on the pre-processing block generated in step S102. The leader node can verify the data in the preprocessing block according to the head hash value of the preprocessing block and judge whether the data in the preprocessing block is tampered or lost in the transmission process.

If the leader node verifies the data in the preprocessing block, the leader node can determine that the consensus verification of the preprocessing block passes, and the leader node can store the data of the preprocessing block locally and update the data corresponding to the block chain maintained by the leader node.

, after determining that the consensus check of the pre-processing block passes, the leader node may further send the pre-processing block to other consensus nodes in the blockchain network through heartbeat information, so that the other consensus nodes respectively repeat the verification process of the leader node on the content of the pre-processing block, and if the verification on the content of the pre-processing block also passes, the other consensus nodes in the blockchain network may also update the data corresponding to the self-maintained blockchain according to the data of the pre-processing block.

Of course, in the above process, if the leader node fails to verify the content in the preprocessing block, the leader node will refuse to update the data of the block chain maintained by the leader node, and will not synchronize the preprocessing block to other nodes identified in the block chain network, and if the other nodes identified in the block chain network fail to verify the preprocessing block sent by the leader node, will not update the data of the block chain maintained by the leader node.

S104: and if the consensus node is not the leader node, sending the preprocessing block to the leader node for consensus verification, so that after the consensus verification of the preprocessing block is passed by the leader node, sending the preprocessing block to each subordinate node for consensus verification.

In the embodiment of the present application, if the consensus node is not the leader node. After determining the leader node in the blockchain network, the consensus node may send the pre-processing block generated by the consensus node in step S102 to the leader node for verification, so that the leader node synchronizes the pre-processing block to other consensus nodes in the blockchain network after passing the consensus check on the pre-processing block.

After receiving the preprocessing block sent by the leader node, other common identification nodes in the blockchain network can also verify the content of the preprocessing block, store the data in the preprocessing block locally after the verification is passed, and update the data corresponding to the blockchain.

Specifically, in this embodiment of the present application, since the blockchain network may adopt a Raft protocol to select consensus nodes as the leader node during consensus, the consensus node may send the pre-processing block to the leader node, and synchronize the pre-processing block to other consensus nodes in the blockchain network.

After that, the leader node may check the data in the pre-processing block according to the head hash value of the pre-processing block, and determine whether the data in the pre-processing block is tampered or missing during transmission, and the leader node may further determine whether the node is a consensus node in the block chain network and whether the node information matches any of the consensus nodes stored locally by the leader node according to the node information in the pre-processing block.

If the leader node verifies the data in the preprocessing block, and the node information also can prove that the consensus node is a consensus node in the block chain network, the leader node can determine that the consensus node of the preprocessing block passes verification, and the leader node can store the data of the preprocessing block locally and update the data corresponding to the block chain maintained by the leader node.

It should be noted that, since it is impossible for each consensus node to be both a subordinate node and a leader node, step S103 and step S104 of the present application are two parallel steps, and for each consensus node, step S103 and step S104 can only be selected to be performed at .

The common identification node in the block chain network receives the to-be-stored service data sent by the service acceptance platform, generates a preprocessing block according to the to-be-stored service data, directly performs common identification check on the preprocessing block when the common identification node is a leader node, and sends the preprocessing block to each subordinate node for common identification check after the check is passed, and sends the preprocessing block to the leader node for common identification check when the common identification node is not a leader node, so that the leader node sends the preprocessing block to each subordinate node for common identification check after the check is passed.

In the present embodiment, since the preprocessed blocks are subjected to consensus check according to the Raft protocol, if a defective node exists in the consensus nodes, for example, an consensus node is bad and an erroneous preprocessed block is stored, the consensus node can be regarded as a defective node.

If the bad node is the leader node, then, because each subordinate node needs to perform consensus check on the pre-processing block, even if the leader node broadcasts an erroneous pre-processing block (whether the pre-processing block is sent to the leader node by any consensus node or created by the leader node), each subordinate node will not pass the consensus check on the pre-processing block, and will not store the pre-processing block.

If the bad node is a subordinate node, the subordinate node cannot complete the storage of the wrong preprocessing block because the content which can be stored by the subordinate node must be transmitted by the leader node. Even if the defective node stores the wrong pre-processing block, since each subordinate node also needs to perform consensus check on the pre-processing block, the defective node still cannot store the wrong pre-processing block in each consensus node, and thus the block chain cannot be tampered with.

, in step S102 of this embodiment of the present application, the consensus node may also create the pre-processing block according to each to-be-stored service data when the received to-be-stored service data reaches a preset number, increase the number of stored data in each pre-processing blocks, and reduce the frequency of performing consensus.

Further , in this embodiment of the present application, different crowd sourcing platforms may use their own APPs to initiate crowd sourcing projects, and the codings of APPs of different crowd sourcing platforms may differ, and at the same time, the used codings may also differ, so when each consensus node in the block chain network receives the service data to be stored, the service data to be stored may conform to a reading rule of the APP of the crowd sourcing platform that sends the consensus node, and for different crowd sourcing platforms corresponding to other consensus nodes in the block chain network, the data format of the service data to be stored may not be in a readable data format, so as to facilitate operations such as data exchange between subsequent crowd sourcing platforms and possible procedural data analysis.

Specifically, after the common node receives the service data to be stored in step S101, before the common node writes the service data to be stored into the preprocessing block in step S102, the common node may further determine whether the format of the service data to be stored is a specified format, if so, the format conversion is not performed, and if not, the format of the service data to be stored is converted into the specified format according to a preset data format. Wherein the specified format may be a JSON format. Of course, the specified format may also be negotiated and determined by each crowd-sourcing platform according to the needs in actual application, as long as after the service data to be stored is written into the preprocessing block, the preprocessing block may be removed from the specific application format as a Flat File (Flat File), so that the data in the preprocessing block may be migrated to different applications for data processing.

In addition, if the blockchain is in a mode of receiving times of service data to be stored and creating preprocessing blocks, the service data to be stored can be replaced by the creation time of the preprocessing blocks without carrying the certification time.

It should be noted that the execution subject of each step of the method provided in the embodiment of the present application may be the same device, or the method may also use different devices as the execution subject, for example, the execution subject of step S101 and step S102 may be device 1, the execution subject of step S103 may be device 2, for example, the execution subject of step S101 may be device 1, and the execution subject of step S102 and step S103 may be device 2, and so on.

Further , in this embodiment, when a new consensus node is added to the blockchain network, a crowd sourcing platform corresponding to the newly added consensus node configures node information for the newly added consensus node according to the settings of the blockchain, and sends the node information to a leader node in the blockchain network, where the leader node synchronizes the node information of the newly added consensus node to each consensus node in the blockchain network after passing the verification of the node information, and each consensus node only needs to store the node information of the newly added consensus node without verifying the node information again.

Further , when a crowd funding project is good in quality, so that more popular crowd funding projects and investors all initiate a request for accepting funding for the crowd funding project, each common recognition node in the block chain network may receive business data to be stored corresponding to a trust transaction initiated by different investors before receiving two heartbeat data of the leader node, and at this time, the leader node may receive two preprocessing blocks with the same block height, and at this time, the leader node may determine, according to a preset judgment logic, that preprocessing blocks are firstly verified and synchronized, and that preprocessing blocks are secondly verified and synchronized.

Specifically, when the leader node receives different preprocessed blocks with the same block height, the leader node may first determine the creation time corresponding to each preprocessed block with the same block height.

And then determining sowing sequence of each preprocessing block according to the corresponding creation time sequence of each preprocessing block with the same block height, determining the head hash value of the preprocessing block which is firstly sown at as the hash value of the parent block of the preprocessing block which is subsequently sown at , and updating the hash value of the parent block of the preprocessing block which is subsequently sown at .

Finally, the leader node may check pre-processed blocks by in the order of play, and may be broadcast to other consensus nodes of the blockchain.

In addition, when the creation time of the preprocessing blocks with the same block height is the same, the leader node can also determine playing sequence according to the size sequence of the head hash values of the preprocessing blocks, or the leader node can also determine playing sequence by adopting random ordering.

Further , since there is a case that the block check fails, in this embodiment, when the leader node receives a plurality of pre-processing blocks with the same block height, the contents of each pre-processing block may be checked first, and after the check is completed, it is determined whether there is a need for sorting (i.e., whether there are a plurality of pre-processing blocks with the same block height), and if there is a need for sorting, sorting is performed.

Fig. 4 is a schematic diagram of a leader node receiving a plurality of preprocessed blocks with the same block height, where a block x and a block y both use a block z as a parent block, and the leader node compares the creation time of the block x and the creation time of the block y, and sees that the creation time of the block x is earlier (the timestamp value is smaller), then the leader node can determine to check and broadcast the block x first, then check the block y and broadcast order.

In addition, in the embodiment of the application, in order to facilitate the monitoring of the crowd-funded project corresponding to the project identifier by the common identification node using the block chain technology, when the pre-processing block is created, the common identification node may determine a block corresponding to the project identifier and stored for the latest times according to the project identifier and determine a total financing amount accumulated for the crowd-funded project, and then may add and calculate the total financing amount of the crowd-funded project after the current time of the finance (the business processing data is the business processing data corresponding to the finance request) according to the financing amount in the current business processing data and record the total financing amount in the pre-processing block.

Therefore, the accumulated crowd funding amount of the crowd funding project is recorded in the preprocessing block, so that when the state of the crowd funding project is monitored through the block chain, the total funding amount recorded in the recently stored block corresponding to the project identification can be inquired, and the increase of the operation cost caused by monitoring the crowd funding project when the data are processed through the shared memory storage business can be avoided.

, since there is a case that a bad crowd-funding platform makes a false crowd-funding request to increase the influence of the crowd-funding platform by making a false business volume in the prior art, in the embodiment of the present application, when the business data to be stored is stored by using the block-chain technique, since the common identification nodes (e.g., the leader node and the subordinate nodes) also need to perform common identification check on the business data to be stored, the business data to be stored can be checked by the common identification nodes, and since the common identification nodes do not store the preprocessing blocks corresponding to the business data to be stored when the common identification check fails, if there is a bad crowd-funding platform making the false crowd-funding request in the crowd-funding platform, the bad business data to be stored will not pass the common identification check, thereby fundamentally preventing the bad crowd-funding platform from making the false business volume by using the false crowd-funding information.

Specifically, in the embodiment of the present application, when performing consensus verification, the consensus node may check specific contents of the data in the pre-processing block, in addition to processing to match the data in the pre-processing block and the block hash value. The business corresponding to the credit approval request can be regarded as a transaction business, that is, a share of a crowd funded item is bought by paying an investor, and various methods for verifying transaction contents exist in the prior art, so that the application is not particularly limited to this.

Since all the consensus nodes operate independently, even if a small number of consensus nodes are controlled by a bad crowd-funding platform, through consensus verification, most of the consensus nodes correspond to the good crowd-funding platform, and the block chain stored by the consensus nodes controlled by the bad crowd-funding platform cannot be received by other consensus nodes, so that the bad crowd-funding platform is difficult to record false information in the block chain, and the possibility of the bad crowd-funding platform being bad is reduced.

In addition, the block chain consensus process provided in the embodiment of the present application may enable a financer to manage funds raised on a crowd-funded project identified by the same project through multiple crowd-funded platforms through ledgers, and reduce damage and loss of the ledger due to device security problems or device hardware problems, and the like.

It should be noted that the execution subject of each step of the method provided in the embodiment of the present application may be the same device, or the method may also use different devices as the execution subject, for example, the execution subject of step S201 and step S202 may be device 1, and the execution subject of step S203 may be device 2, or for example, the execution subject of step S201 may be device 1, and the execution subject of step S202 and step S203 may be device 2, and so on.

In addition, as shown in fig. 5, the service processing process provided in the embodiment of the present application may specifically include the following steps:

s201: the business acceptance platform receives the project creation request.

In addition, in the embodiment of the application, in order to enable the crowd-funding project to be operated across crowd-funding platforms (that is, a financing party can finance crowd-funding projects through different crowd-funding platforms, and different crowd-funding platforms can also accept a request for approving crowd-funding projects of the same crowd-funding projects through respective channels), the crowd-funding platform and other crowd-funding platforms can jointly form a business alliance, that is, a crowd-funding alliance.

In the embodiment of the application, the crowd-funding platform can communicate crowd-funding projects with other crowd-funding platforms in the crowd-funding alliance subsequently through the crowd-funding alliance to fund crowd-funding projects through different crowd-funding platforms.

It should be noted that, in this embodiment of the application, the crowd-funding platform issues a crowd-funding item, that is, the crowd-funding platform issues item information corresponding to the crowd-funding item (for example, the crowd-funding platform brings the crowd-funding item on line), so that the crowd-funding item is in a funding state, and the crowd-funding platform may further receive a research request initiated by a investor for the crowd-funding item in the funding state. When the crowd-funding project is finished, the crowd-funding project is in a finished state, and the crowd-funding platform can refuse to execute a research confirming request initiated by the crowd-funding project.

In addition, in an embodiment of the present disclosure, the crowd-funding platform may be a platform for a crowd-funding party to accept a crowd-funding project of a funding party, where the crowd-funding platform may be operated by individual crowd-funding parties, and the crowd-funding party may receive a crowd-funding project creation request of the funding party through the crowd-funding platform.

Therefore, in this embodiment of the application, each crowd-funding party may be regarded as a tenant in a crowd-funding platform where the crowd-funding party is located, and each crowd-funding party on the crowd-funding platform may serve as an independent individual on the crowd-funding platform, and may respectively receive a crowd-funding item creation request, perform an audit on the crowd-funding item, assist the crowd-funding party in initiating the crowd-funding item, fund the crowd-funding item with an investor, and the like, that is, each crowd-funding party on the crowd-funding platform may operate the crowd-funding item through the crowd-funding platform. The crowd funding parties on the crowd funding platform can operate incompletely same crowd funding projects, and the specific selection of the operation of the crowd funding projects can be determined by the staff of the crowd funding parties, and the application is not limited.

Of course, the execution process of the crowd-funding service of the crowd-funding party (e.g., creating the crowd-funding project, receiving the request for crowd-funding, etc.) may be performed by the crowd-funding platform, so that if the following description is not specifically provided, the crowd-funding platform in the present application may be regarded as a crowd-funding party in the crowd-funding platform, and the crowd-funding platform executes the service and sends information, which may be regarded as a crowd-funding party in the crowd-funding platform executing the service and sending information through the crowd-funding platform.

And S202, creating a service project according to the project creating request and determining the project identifier of the service project.

In an embodiment of the application, after the crowd-funding platform receives a crowd-funding project creation request, the crowd-funding platform may create a corresponding business project (e.g., a crowd-funding project) according to the crowd-funding project creation request, and may further determine a project identifier of the crowd-funding project.

The crowd funding platform can receive crowd funding project creation requests of a funding party through a channel of the crowd funding platform, publicize the created crowd funding projects, and receive crowd funding confirmation requests of investors through the channel of the crowd funding platform. Generally, in the prior art, channels commonly used by crowd funding platforms include: APP pushed out by the crowd-funding platform, webpage of the crowd-funding platform and the like are channels established by the crowd-funding platform, or the crowd-funding platform can also cooperate with a social platform of a third party, crowd-funding items of the crowd-funding platform are publicized through the channels of the social platform, and trading of shares of the crowd-funding items can also be conducted through the third party platform, and the application does not limit the situation.

In step S101 of this embodiment of the present application, the crowd funding platform may receive a crowd funding project creation request sent by a client, where the client may be an APP used by the expert for crowd funding related services on the crowd funding platform, a browser application, or the like, which is not limited in this application.

Therefore, after the crowd-funding platform receives the crowd-funding project creation request, specifically in this embodiment of the present application, the crowd-funding platform may return a project template to a client that sends the crowd-funding project creation request, so that the client returns project information and a distribution range according to the project template, the crowd-funding platform may create a corresponding crowd-funding project according to the project information, and the crowd-funding platform may further create a project identifier corresponding to the crowd-funding project, so that when other crowd-funding platforms in the crowd-funding alliance subsequently create a corresponding crowd-funding project according to the crowd-funding project creation request, the crowd-funding project corresponding to the project identifier is created, so that crowd-funding projects created by the crowd-funding platforms corresponding to crowd-funding project creation requests all correspond to the project identifier of the crowd-funding project .

In addition, in this embodiment of the application, when the crowd-funding platform returns the project template to the client, the project template may be a project template to be filled in with attribute content, and is used for enabling a financer to return project information and a distribution range according to the project template through the client. The project information is information required by the crowd-funding platform when the crowd-funding platform creates the crowd-funding project corresponding to the crowd-funding project creation request, and the release range is information required by the financing party to finance on the crowd-funding platforms.

For example, the project template may include: the crowd funding project template comprises a crowd funding project name, crowd funding project duration (such as crowd funding starting time and crowd funding ending time), information of a financing party, a crowd funding target amount, a release range and the like, and of course, the field to which the crowd funding project belongs and the specific content of the crowd funding project can also be included in the project template. Crowd funding target crowd and the like. For example, the crowd funding template may be as shown in table 1.

Table 1 is a schematic diagram of the project template returned to the client by the crowd-funding platform according to the embodiment of the present application.

TABLE 1

The attribute content is information that needs to be provided by a funding party to the crowd funding platform, and of course, specific template data of the project template can be determined by the crowd funding platform according to actual needs.

In addition, since in the embodiment of the present application, the crowd funding item may be a crowd funding item published across platforms, the publishing range may be used as necessary information. The publishing range in the project template may include platform identifiers of other crowd-funding platforms in the crowd-funding alliance, and thus, a financing party may select, through the client, corresponding platform identifiers in the publishing range in the project template, so that the financing party may select which financing platforms to publish the crowd-funding project on, and then the crowd-funding platform may determine that the crowd-funding project creation request needs to be subsequently sent to those crowd-funding platforms according to the publishing range returned by the financing party through the client. And the financing party can select 'yes' or 'no' to the project template to indicate whether the crowd-funding project needs to be published on the crowd-funding platform corresponding to the platform identifier. Of course, table 1 is only an illustration of the project template in the embodiment of the present application, and specifically, what form the project template is sent to the client may be configured by the crowd sourcing platform according to the needs of the actual application (for example, in the form of a questionnaire or in the form of a telephone communication), which is not limited in the present application.

It should be noted that, in the project template, information except for the release range may be regarded as project information, the crowd funding platform may adopt the same method as in the prior art, and a worker may audit the crowd funding project according to the project information (e.g., whether crowd funding can be implemented or not, whether crowd funding has been developed or not), and after the audit is passed, create a corresponding business project.

Of course, in the prior art, in the process of creating the crowd funding project, a worker who passes through the crowd funding platform may need to cooperate with a worker of the funding party to determine details of the crowd funding project, and then distribute the crowd funding project. In the embodiment of the application, a process of creating the crowd funding project by the crowd funding platform according to the project information may be the same as a process of creating the crowd funding project in the prior art.

S203: and sending the project creating request and the project identifier to other service accepting platforms, so that the other service accepting platforms create the service project corresponding to the project identifier according to the project creating request.

In this embodiment of the application, after the crowd-funding platform creates the crowd-funding item, according to platform identifiers of other crowd-funding platforms included in the distribution range, the crowd-funding platform may send item information corresponding to the crowd-funding item creation request and the item identifier to other crowd-funding platforms corresponding to the platform identifier, so that the other crowd-funding platforms create the crowd-funding item corresponding to the item identifier according to the crowd-funding item information.

Specifically, the crowd-funding platform may determine, according to the distribution range returned by the client in step S102, platform identifiers of other crowd-funding platforms included in the distribution range, then decrease the item information corresponding to the crowd-funding item creation request and the item identifier determined in step S102, and send the item information and the item identifier to the other crowd-funding platforms corresponding to the platform identifier.

In addition, in order to enable the crowd-funding platform and other crowd-funding platforms to simultaneously fund the crowd-funding project (for example, accept the approval of the crowd-funding project by the investor), the crowd-funding platform may further establish a corresponding relationship between the service processing data and the project identifier of the crowd-funding project, and store the service processing data in the shared memory of the crowd-funding platform and other crowd-funding platforms.

Specifically, the shared memory may be a database, and the crowd-funding platform and the other crowd-funding platforms have an authority to access the database, and the crowd-funding platform and the other crowd-funding platforms may store the service processing data, the item identifier, and the established correspondence in the database.

The crowd-funding platform, or other crowd-funding platform, may then determine, based on the project identifier, business process data associated with the project identifier by accessing the database. And determining the total amount raised by the crowd funding project corresponding to the project identification by summing the credit amounts in the service processing data.

, the crowd-funding platform may determine an end condition of the crowd-funding project (e.g., whether a target amount is funded, whether an end time of the crowd-funding project is reached, etc.) based on project information of the crowd-funding project, and the crowd-funding platform or other crowd-funding platforms may monitor whether the crowd-funding project is ended based on the service processing data corresponding to the project identifier stored in the shared memory (e.g., a database) and the end condition, and if the crowd-funding project is ended, may stop accepting the request for confirming the crowd-funding project, and if not, may continue accepting the request for confirming the crowd-funding project.

In the embodiment of the application, after a crowd-funding project is created, each crowd-funding platform needs to monitor the operation state of the crowd-funding project (for example, whether the crowd-funding project is finished, the amount of crowd-funding funds, and the like) and provide the operation state to a crowd-funding platform, and business processing data corresponding to a crowd-funding project approval request are stored in the shared memory (for example, a database).

Moreover, if the shared memory is attacked by hackers or the device is in trouble (such as downtime), the process of issuing the crowd funding project and the process of accepting the confirmation funding request of each crowd funding platform will be affected, so that the flow of business processing is delayed, the business fails, the business needs to be restarted, the resource waste is caused, the data stored in the shared memory is lost, the executed crowd funding project fails, and the direct loss of each crowd funding platform is caused.

In this embodiment, each crowd-funding platform in the crowd-funding alliance may store the service processing data by using a blockchain technology, so as to reduce the loss caused by the problem of the shared memory by using the decentralized feature of the blockchain technology, and may determine, by using the feature of the blockchain technology, that the recorded information is not removable, and every time the service processing data is stored in the blockchain, each common identification node needs to perform common identification check, so that each common identification node may determine data such as a funding amount accumulated corresponding to the item identifier, thereby reducing resource waste caused by monitoring the crowd-funding item.

Specifically, the crowd funding platform may generate to-be-stored service data including the service processing data and the project identifier, and then send the to-be-stored service data to a consensus node corresponding to the service acceptance platform, so that the consensus node performs consensus check on the to-be-stored service data, and writes the to-be-stored service data into a block chain after the consensus check passes. The specific process may be the block chain consensus process shown in fig. 1 provided in the embodiments, and will not be described in detail herein.

By storing the business processing data in the block chain, each crowd-funding platform can monitor the state of the crowd-funding item only according to the block chain, and due to the non-tampering property of the block chain technology and the decentralization characteristic, the business processing data stored by each crowd-funding platform is higher in authenticity (can be stored only through the consensus check of the consensus nodes), and the condition that the whole crowd-funding item data is lost due to the problem of the single consensus node is avoided.

Based on the above-mentioned service processing process, it can be seen that the service acceptance platform (e.g., crowd-funding platform) may create a crowd-funding project according to a crowd-funding project creation request after receiving a project creation request (e.g., crowd-funding project creation request), determine a project identifier of the crowd-funding project, then send the crowd-funding project creation request and the project identifier to other service acceptance platforms, so that the other service acceptance platforms create a crowd-funding project corresponding to the project identifier according to the crowd-funding project creation request, and further so that a plurality of crowd-funding platforms may create crowd-funding projects having the same project identifier according to the crowd-funding project creation request, and upon accepting a service processing request (e.g., recognizing the crowd-funding project request) for the crowd-funding project, may establish a correspondence between service processing data after service processing and the project identifier of the crowd-funding project and store the business processing data in the shared memory, so that a plurality of the crowd-funding projects may be distinguished by the crowd-funding platform through the service processing data stored in the shared memory, and the operation platform may provide a high efficiency for the crowd-funding project monitoring platform.

The crowd-funding project management method has the advantages that the crowd-funding projects only comprise crowd-funding projects, so that fund management of a financing party on crowd-funding projects is simpler than that of the prior art, fund management is not needed to be conducted respectively, the factors of crowd-funding project financing failure are reduced, and the cost of the financing party on the crowd-funding project operation management is reduced.

In addition, in the embodiment of the application, if the financing party only needs to publish the crowd funding project through the crowd funding platform, the publishing range returned by the client may not include the identifier of the crowd funding platform. In addition, since it may also happen that the sponsor does not need to publish the crowd-funding project through the crowd-funding platform, in the embodiment of the present application, the publishing range in the project template in the step S202 may include a platform identifier for receiving the crowd-funding platform (i.e., a platform identifier for each crowd-funding platform in the crowd-funding alliance). If the release range in the project template includes the platform id of the crowd-funding platform, but the release range returned by the client does not include the platform id of the crowd-funding platform, the crowd-funding platform may determine that the funding party does not need to release the crowd-funding project on the crowd-funding platform, and the crowd-funding platform may cancel the crowd-funding project created in step S202.

, after the crowd-funding platform creates the crowd-funding project, the crowd-funding platform may publish the crowd-funding project through various channels of the crowd-funding platform as described in step S201, and then the crowd-funding platform may accept a business processing request (i.e., a bid approval request) for the crowd-funding project after publishing the crowd-funding project.

Specifically, when the crowd-funding platform receives a crowd-funding request for the crowd-funding project, the crowd-funding platform can perform business processing according to the crowd-funding project and the crowd-funding request, and determine business processing data. Wherein, the service processing data may include: the specific business processing data also comprises information of which can be negotiated and determined by various crowd-funding platforms in the crowd-funding alliance in advance, or a worker with the crowd-funding platform determines according to the needs of actual business.

Further, , in the embodiment of the application, the crowd-funding platform may generate the item identifier by using a rule agreed by the crowd-funding alliance in advance when determining the item identifier of the business item, so that each crowd-funding platform in the crowd-funding alliance may generate the item identifier of the system for a request of creating crowd-funding items, and meanwhile, the item identifier of the system is also convenient for each crowd-funding platform, and information of the crowd-funding item corresponding to the item identifier is determined through the item identifier.

For example, the client determines the top 4 of the item identifier according to the crowd-funded item name in the item information, the top 4 of the pinyin initial of the crowd-funded item name may be used as the top 4 of the item identifier, when the english item name is encountered, the top 4 of the english abbreviation may be used as the top 4 of the item identifier, and so on, assuming that the name of crowd-funded items is called "science and love life" and the crowd-funded target amount is 100 ten thousand yuan, the item name may be "jiik" plus "1000000", that is, "ik ji 1000000".

Of course, the above is only an example provided in the embodiment of the present application, and the rules how to determine the project names may be agreed by the crowd-funding platforms in the crowd-funding alliance, and the present application is not limited specifically.

In addition, in this embodiment of the application, the application is not specifically limited to the business logic of each crowd-funding platform, and each crowd-funding platform may have an independent business logic, that is, in step S202 of this embodiment of the application, how the crowd-funding platform performs business processing is not limited to this application. Different crowd funding platforms can adopt different service logics to perform service processing and create service projects. Meanwhile, when the crowd funding platforms receive the trust request, the crowd funding platforms can adopt self business logic to process business and determine business processing data.

Further , in this embodiment, each crowd sourcing platform may store the generated to-be-stored service data including the service processing data and the item identifier by using a blockchain technique when storing the service data, and at the same time, in step S202 of this application, there may be multiple tenants in the crowd sourcing platform, that is, multiple crowd sourcing parties, so that, in order to make sure that the service processing data is sent by the tenant in the crowd sourcing platform, the crowd sourcing platform may also carry the tenant information of the to-be-stored service data in the to-be-stored service data when generating the to-be-stored service data, send the to-be-stored service data to the consensus node, so that the consensus node performs consensus check on the tenant information as the node information of the node, and after the consensus check passes, write the to-be-stored service data and the tenant information into a blockchain.

Specifically, a tenant in the service acceptance platform (e.g., a crowd funding platform) may receive the project creation request, and when generating the service data to be stored, carry tenant information of the tenant in the service data to be stored, and send the tenant information to a common recognition node corresponding to the service acceptance platform through the service acceptance platform. The subsequent implementation of the consensus node can then refer to the blockchain consensus process shown in fig. 1.

It should be noted that, in the embodiment of the present application, execution subjects of the steps of the above method may be the same devices, or different devices may also be used as the execution subjects of the method, for example, the execution subject of step S201 and step S202 may be device 1, the execution subject of step S203 may be device 2, for example, the execution subject of step S201 may be device 1, and the execution subject of step S202 and step S203 may be device 2, and so on.

Based on the blockchain consensus method shown in fig. 1, the embodiment of the present application further provides a schematic structural diagram of kinds of blockchain consensus devices, as shown in fig. 6.

Fig. 6 is a schematic structural diagram of types of service processing devices provided in an embodiment of the present application, including:

a receiving module 401, configured to receive service data to be stored, sent by a service acceptance platform, where the service data to be stored is sent by the service acceptance platform through the apparatus according to any of claims 17 to 19;

a generating module 402, configured to generate a preprocessing block according to the to-be-stored service data;

if the device is a leader node, a verification sending module 403 performs consensus verification on the preprocessing block, and sends the preprocessing block to each subordinate node for consensus verification after the verification is passed;

if the device is not a leader node, the verification sending module 403 sends the preprocessing block to the leader node for consensus verification, so that the leader node sends the preprocessing block to each subordinate node for consensus verification after passing the consensus verification on the preprocessing block.

The leader node is selected by all the consensus nodes through a Raft distributed protocol.

The check sending module 403, after passing the consensus check on the pre-processing block, stores the pre-processing block in the block chain corresponding to the apparatus.

The generating module 402 converts the format of the received service data to be stored into a specified format before generating a preprocessing block according to the service data to be stored, where the specified format includes a JSON format.

The device further comprises:

a sorting and sending module 404, configured to, when the service processing apparatus itself is a leader node, if more than two pre-processing blocks having the same block height and passing the consensus check of the consensus node themselves are received, determine broadcast orders of the pre-processing blocks according to the creation time sequence or the size sequence of the head hash values of the pre-processing blocks, determine the head hash value of the pre-processing block for each pre-processing block in sequence according to the broadcast order, update the hash value of the parent block of the next pre-processing blocks to the head hash value, and broadcast -by- the pre-processing blocks to the next subordinate nodes for consensus according to the broadcast order.

The service acceptance platform is a crowd funding platform, and the service data to be stored comprises: the business acceptance platform generates chip approval information according to a chip approval request aiming at a chip approval project and a project mark of the chip approval project.

The service acceptance platforms are multiple, each common identification node corresponds to or more service acceptance platforms, and each common identification node corresponds to the same service acceptance platform or different service acceptance platforms.

Specifically, the service processing apparatuses shown in fig. 7 may be located in a consensus node, which may be devices alone or a system of multiple devices.

Based on the service processing method shown in fig. 5, the embodiment of the present application further provides a schematic structural diagram of service processing apparatuses, as shown in fig. 7.

Fig. 7 is a schematic structural diagram of types of service processing devices provided in an embodiment of the present application, including:

a receiving module 301, which receives a project creation request;

a determining module 302, configured to create a service item according to the item creation request, and determine an item identifier of the service item;

the sending module 303 sends the project creation request and the project identifier to another service accepting platform, so that the other service accepting platform creates a service project corresponding to the project identifier according to the project creation request.

The determining module 302 is configured to return a project template to a client that sends the project request, so that the client returns project information and a release range according to the project template, and creates a service project according to the project information; the sending module 303 sends the item information and the item identifier corresponding to the item creation request to other service acceptance platforms corresponding to the platform identifier according to the platform identifiers of the other service acceptance platforms included in the distribution range.

When the receiving module 301 receives a service processing request for the service item, the apparatus further includes:

the storage module 304 performs service processing according to the service processing request, determines service processing data, establishes a corresponding relationship between the service processing data and the project identifier, and stores the service processing data in a shared memory of the service acceptance platform and the other service acceptance platforms.

The device further comprises:

the monitoring module 305 determines an end condition of the service item according to the item information of the service item, and monitors whether the service item is ended according to the service processing data corresponding to the item identifier and stored in the shared memory and the end condition.

The storage module 304 generates to-be-stored service data including the service processing data and the project identifier, sends the to-be-stored service data to a consensus node corresponding to the service acceptance platform, so that the consensus node performs consensus check on the to-be-stored service data, and writes the to-be-stored service data into a block chain after the consensus check is passed.

The business acceptance platform is a crowd funding platform, the project creation request is a crowd funding project creation request, the business project is a crowd funding project, and the business processing request is a credit funding request.

The project information at least includes: the crowd funding method comprises the steps of crowd funding target amount, crowd funding starting time, crowd funding ending time and information of a financing party.

Specifically, the service processing devices shown in fig. 7 may be located in a server of the service acceptance platform, and the server may be a single equipment or a system composed of multiple pieces of equipment.

In the 90 th generation of 20 th century, improvements to technologies can be clearly distinguished as Hardware improvements (for example, improvements to Circuit structures such as diodes, transistors, switches, and the like) or software improvements (improvements to method flow), however, as technology develops, many of the method flow improvements today can be considered as direct improvements to Hardware Circuit structures, designers almost all obtain corresponding Hardware Circuit structures by Programming the improved method flow into Hardware circuits, therefore, it cannot be said that the improvements to method flow cannot be realized by Hardware entity modules, for example, Programmable Logic Devices (PLDs) (for example, Field Programmable arrays (FPGAs)) are such integrated circuits whose Logic functions are determined by user Programming devices, designers themselves program digital systems "integrated" on chips without the need of many kinds of integrated Circuit manufacturers to design and manufacture integrated circuits, and the integrated circuits are easily developed by Hardware Programming languages (Hardware Programming Language), and the integrated circuits are not written by Hardware Programming languages such as Hardware Logic devices, Hardware Programming languages such as Hardware Programming languages, Hardware compiling languages, software programs, Hardware programs, software programs, Hardware programs, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software, Hardware, software.

A controller may be implemented in any suitable manner, for example, in the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic , switches, Application Specific Integrated Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, microcontrollers 625D, Atmel AT91SAM, Microchip PIC18F26K20, and silicon Labs C8051F320, which may also be implemented as part of the control logic of a memory . in addition to implementing a controller in pure computer readable program code, one skilled in the art will also recognize that such controllers may be fully programmed with method steps to cause the controller to implement the same functions as various hardware components within logic , switches, Application Specific Integrated circuits, programmable logic controllers, embedded microcontrollers, etc. accordingly, such controllers may be considered as hardware components for implementing the various functions of an apparatus, or even as hardware components within an apparatus.

The systems, apparatuses, modules or units illustrated in the above embodiments may be embodied as a computer chip or entity, or as an article of manufacture with some functionality exemplary implementing devices are computers.

For convenience of description, the above devices are described as being functionally separated into various units, it is understood that the functions of the units may be implemented in the same or more software and/or hardware when implementing the present application.

Furthermore, the present invention may take the form of a computer program product embodied on or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

It is to be understood that each flow and/or block in the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions which can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagram flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In typical configurations, a computing device includes or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises the series of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Moreover, the present application may take the form of a computer program product embodied on or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer , generally including routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1, kinds of block chain consensus method, the method comprising:

generating a preprocessing block according to the service data to be stored;

and if the consensus node is not the leader node, sending the preprocessing block to the leader node for consensus verification, so that the leader node sends the preprocessing block to each subordinate node for consensus verification after passing the consensus verification of the preprocessing block.

2. The method of claim 1, wherein the leader node is selected by each consensus node via a Raft distributed protocol.

3. The method of claim 2, further comprising:

and for each consensus node, after the consensus node passes the consensus check on the preprocessing block, storing the preprocessing block in the block chain corresponding to the consensus node.

4. The method of claim 1, before generating a pre-processing block according to the service data to be stored, the method further comprising:

and the consensus node converts the format of the received service data to be stored into a specified format, wherein the specified format comprises a JSON format.

5. The method of claim 1, further comprising:

when the consensus node is a leader node, if more than two preprocessing blocks which have the same block height and pass the consensus verification of the consensus node are received, determining playing sequence of the preprocessing blocks according to the creation time sequence of the preprocessing blocks or the size sequence of the head hash value;

according to the playing sequence, sequentially aiming at each preprocessing block, determining a head hash value of the preprocessing block, and updating the hash value of the parent block of the next preprocessing blocks into the head hash value;

and according to the broadcasting sequence, broadcasting the preprocessing blocks to the subordinate nodes for consensus.

6. The method of any of claims 1 to 5, , wherein the business acceptance platform is a crowd funding platform;

the service data to be stored comprises: the business acceptance platform generates chip approval information according to a chip approval request aiming at a chip approval project and a project mark of the chip approval project.

7. The method of claim 6, wherein a plurality of service acceptance platforms exist, and each consensus node corresponds to or more service acceptance platforms;

each common identification node corresponds to the same service acceptance platform or different service acceptance platforms.

The block chain consensus device of the 8 th kinds includes:

9. The apparatus of claim 8, the leader node is selected by each consensus node through a Raft distributed protocol.

10. The apparatus of claim 8, wherein the check sending module stores the pre-processed block in a corresponding blockchain of the apparatus after the co-recognition check on the pre-processed block passes.

11. The apparatus of claim 8, wherein the generating module converts a format of the received service data to be stored into a specified format before generating a pre-processing block according to the service data to be stored, wherein the specified format includes a JSON format.

12. The apparatus of claim 8, wherein the apparatus further comprises:

a sequencing and sending module, configured to, when the service processing apparatus itself is a leader node, if more than two pre-processing blocks with the same block height and passing the consensus check of the consensus node themselves are received, determine an broadcast sequence of each pre-processing block according to a creation time sequence or a size sequence of a header hash value of each pre-processing block, determine the header hash value of each pre-processing block for each pre-processing block in sequence according to the broadcast sequence, update the hash value of a parent block of a next pre-processing blocks to the header hash value, and broadcast -by- each pre-processing block to each next node for consensus according to the broadcast sequence.

13. The apparatus of any one of claims 8 to 12, , wherein the business acceptance platform is a crowd funding platform, and the business data to be stored includes a crowd funding information generated by the business acceptance platform according to a crowd funding request for a crowd funding project, and a project identifier of the crowd funding project.

14. The apparatus according to claim 13, wherein there are a plurality of service acceptance platforms, and each common identification node corresponds to or more service acceptance platforms, and each common identification node corresponds to the same service acceptance platform or different service acceptance platforms.