CN108985772B

CN108985772B - Block chain verification method, device, equipment and storage medium

Info

Publication number: CN108985772B
Application number: CN201810714971.0A
Authority: CN
Inventors: 邱俊炜
Original assignee: Shanghai Dajiaying Information Technology Co Ltd
Current assignee: Shanghai Dajiaying Information Technology Co Ltd
Priority date: 2018-07-02
Filing date: 2018-07-02
Publication date: 2022-03-18
Anticipated expiration: 2038-07-02
Also published as: CN108985772A

Abstract

The embodiment of the invention discloses a verification method, a device, equipment and a storage medium of a block chain, wherein the method comprises the following steps: the block verification node receives a to-be-verified block sent by the block generation node, wherein the block generation node is a node selected by a set consensus mechanism; the block verification node acquires financial transaction data in a block to be verified; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data; and the block verification node performs data verification on the financial transaction data in the block to be verified according to the historical data identification information of the financial transaction data. The technical scheme of the embodiment of the invention can effectively avoid adding error data into the block chain, thereby ensuring the validity of the data in the block chain network.

Description

Block chain verification method, device, equipment and storage medium

Technical Field

The embodiment of the invention relates to the technical field of block chains, in particular to a verification method, a verification device, verification equipment and a storage medium of a block chain.

Background

The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. In a distributed node system, nodes compete to obtain the right of current processing data to serve as block generation nodes; and the generated block is verified and confirmed by other nodes and then stored. The above-described operation mechanism makes it almost impossible for data recorded in a block chain to be tampered.

In the prior art, a blockchain mainly solves the trust and security problems of transactions, so that a significant characteristic is a distributed ledger. Specifically, at a node in the blockchain system, a transaction request within a certain time or a certain number of transaction requests are delivered to a current block generation node with an accounting right; the block generation node processes the transaction request, such as information conversion, format adjustment or code operation, to form ledger data, and then packs the ledger data to form a block; the block generation node sends the block to other nodes in the block chain system, and the other nodes carry out the same processing process to verify whether the block obtained by the processing result is consistent with the received block or not, if so, the block is approved and stored, otherwise, the block is not approved and discarded. The block generation nodes are mainly generated through a consensus algorithm, and the conventional consensus algorithm mainly comprises two categories of mining algorithms and non-mining consensus algorithms.

In the process of implementing the invention, the inventor finds that the prior art has the following defects:

in the non-mining consensus algorithm, if the source data has errors before joining the blockchain, the authenticity of the subsequent data is questioned, the storage space of the nodes is wasted, a large number of meaningless blocks are generated, and the problem of 'double flowers' is possibly caused.

Disclosure of Invention

Embodiments of the present invention provide a method, an apparatus, a device, and a storage medium for verifying a block chain, so as to effectively avoid a problem that erroneous data is added to the block chain, thereby ensuring validity of data in a block chain network.

In a first aspect, an embodiment of the present invention provides a method for verifying a block chain, including:

the block verification node receives a to-be-verified block sent by a block generation node, wherein the block generation node is a node selected by a set consensus mechanism;

the block verification node acquires financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data;

the block verification node performs data verification on the financial transaction data in the block to be verified according to the historical data identification information of the financial transaction data;

wherein the block verification node has stored therein latest historical financial transaction data.

In a second aspect, an embodiment of the present invention provides a method for verifying a block chain, including:

a block generation node generates a block to be verified and sends the block to be verified to a block verification node of a block chain network, wherein the block generation node is a node selected by a set consensus mechanism; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data; the block generation node acquires a block verification result of the block to be verified by the block verification node according to historical data identification information of financial transaction data in the block to be verified;

wherein all historical financial transaction data is stored in the block generation node.

In a third aspect, an embodiment of the present invention further provides a device for verifying a block chain, where the device is configured at a block verification node, and the device includes:

the system comprises a block receiving module, a block verification module and a block verification module, wherein the block receiving module is used for receiving a to-be-verified block sent by a block generating node, and the block generating node is a node selected by a set consensus mechanism;

the data acquisition module is used for acquiring financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data;

the data verification module is used for performing data verification on the financial transaction data in the to-be-verified block according to the historical data identification information of the financial transaction data;

In a fourth aspect, an embodiment of the present invention further provides a verification apparatus for a block chain, configured at a block generation node, including:

the block generation module is used for generating a block to be verified and sending the block to be verified to a block verification node of a block chain network, wherein the block generation node is a node selected by a set consensus mechanism; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data;

the result acquisition module is used for acquiring a block verification result of the block to be verified by the block verification node according to the historical data identification information of the financial transaction data in the block to be verified;

In a fifth aspect, an embodiment of the present invention further provides a computer device, where the computer device includes:

one or more processors;

storage means for storing one or more programs;

when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method for verifying a blockchain according to any of the first aspects.

In a sixth aspect, an embodiment of the present invention further provides a computer device, where the computer device includes:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of verifying a blockchain of any of the second aspects.

In a seventh aspect, an embodiment of the present invention further provides a computer storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the method for verifying a blockchain according to any of the first aspect.

In an eighth aspect, an embodiment of the present invention further provides a computer storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the method for verifying a blockchain according to any of the second aspects.

According to the embodiment of the invention, the to-be-verified block sent by the block generation node is received by the block verification node, the financial transaction data in the to-be-verified block is obtained, and the data verification is carried out on the financial transaction data in the to-be-verified block according to the historical data identification information of the financial transaction data. Because the latest historical transaction data is stored in the block verification node, and the historical data identification information can be used for indicating that the transaction data is associated with the historical transaction data, the problem of 'double flowers' in the existing block chain applying the non-mining consensus algorithm can be effectively solved, the situation that error data is added into the block chain is effectively avoided, and the validity of the data in the block chain network is further ensured.

Drawings

Fig. 1 is a flowchart of a verification method for a blockchain according to an embodiment of the present invention;

fig. 2 is a flowchart of a verification method for a blockchain according to a second embodiment of the present invention;

fig. 3 is a flowchart of a verification method for a blockchain according to a third embodiment of the present invention;

fig. 4 is a schematic diagram of an apparatus for verifying a block chain according to a fourth embodiment of the present invention;

fig. 5 is a schematic diagram of an apparatus for verifying a block chain according to a fifth embodiment of the present invention;

fig. 6 is a schematic structural diagram of a computer device according to a sixth embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention.

It should be further noted that, for the convenience of description, only some but not all of the relevant aspects of the present invention are shown in the drawings. Before discussing exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart may describe the operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently or simultaneously. In addition, the order of the operations may be re-arranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figure. The processes may correspond to methods, functions, procedures, subroutines, and the like.

Example one

Fig. 1 is a flowchart of a verification method for a blockchain according to an embodiment of the present invention, where the verification method is applicable to a case where a block verification node performs data verification on financial transaction data in a block to be verified, and the verification method may be executed by a verification apparatus for a blockchain, where the verification apparatus may be implemented by software and/or hardware, and may be generally integrated in a computer device, where the computer device may be a device that bears a blockchain node. Accordingly, as shown in fig. 1, the method comprises the following operations:

s110, the block verification node receives a to-be-verified block sent by a block generation node, wherein the block generation node is a node selected by setting a consensus mechanism.

The blockchain network may be a public chain or a federation chain. A blockchain network may comprise a base chain, i.e. a main chain, while side chains, sub chains or lightning networks may be comprised. The block verification node may be another blockchain network node participating in the verification process of the block generation node sending the block. The block generation node may be a node in the blockchain network that has block processing authority. The set consensus mechanism may be a non-mining consensus mechanism, such as PBFT (Practical Byzantine Fault Tolerance algorithm) or Raft algorithm.

In the embodiment of the present invention, the block generation node having the block processing permission may obtain the transaction request from the cache region of the blockchain network, process the transaction request, and perform encapsulation and packaging according to the transaction request and the obtained transaction data to generate the block to be verified. The transaction request may be a transaction request occurring within a period of time in the blockchain network or other pending request. The block generation node may transmit the block to be verified to the blockchain network, so that the block verification node verifies the block to be verified. Meanwhile, the block generation node can also participate in the verification process of the block to be verified.

S120, the block verification node acquires financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identifying information associated with the historical financial transaction data.

The financial transaction data includes, but is not limited to, a fund transaction, a equity transaction, a digital currency transaction, a fund transaction, and the like. The historical data identification information may be a number or identification or the like indicating the historical financial transaction with which the current financial transaction data is associated.

In the embodiment of the invention, when the block to be verified is verified by the block verification node, the historical data identification information in the financial transaction data in the block to be verified can be obtained firstly.

In an optional embodiment of the invention, the financial transaction data may include: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: at least one historical data identification information associated with the historical financial transaction data; the roll-out information includes: at least two types of roll-out accounts.

The data identification information is used to indicate a number or an identifier of the current financial transaction data, and may specifically be a character string including a node identifier, such as a0001, and of course, a random number may also be added to the number to avoid generating a repeated number, for example, the number may be Ar0001, where r is a random number, the number of bits of the random number may be set according to actual needs, the random number generated each time is different, and Ar in the number is only used as an identifier and is not counted, and counting is performed by using 0001 in the number as a starting number, for example, when r is 123, the counting range of the initial number a1230001 is a1230001-a 1239999. The embodiment of the invention does not limit the method and the form for realizing the numbering of the financial transaction data. Accordingly, the roll-out party information may be a roll-out account for the assets, equities, virtual currency, funds, etc. involved in the transaction, e.g., when B sells 1 thousand shares to a, the address in a for storing the bought 1 thousand shares may be used as a roll-out account. Accordingly, the transfer-in party information may be historical data identification information corresponding to historical financial transaction data associated with the current financial transaction data in the financial transaction data. For example, when B sells 1 thousand shares to a, the number corresponding to the financial transaction data last related to a and B may be used as transfer-in party information. It should be noted that, in the embodiment of the present invention, the transfer-out party information may include at least two different types of transfer-out accounts. Such as one of the transfer-out accounts may be used to store real assets and another transfer-out account may store virtual assets, such as stocks, funds or digital currency. Of course, different types of roll-out accounts may also store different types of virtual assets at the same time, which is not limited by the embodiment of the present invention.

In the embodiment of the present invention, the fused transaction data in the to-be-verified area may specifically include data identification information corresponding to the piece of financial transaction data, and may also include transfer-in party information and transfer-out party information corresponding to the piece of financial transaction data. In addition, the financial transaction data may include a particular amount of money involved in the transaction, such as 2-thousand RMB, or a corresponding amount of a virtual asset, such as 1 thousand shares of T stock, where T may represent the type of stock.

In an optional embodiment of the present invention, the transferring out of the account may comprise: an account of financial money circulating in the real world, and an account of a virtual transaction circulating in the virtual world, the virtual transaction may include: digital currency or virtual items.

Among them, the account of financial money circulating in the real world may be an account for storing real assets such as rmb, U.S. dollars, euro, or the like. The account of the virtual transaction circulated in the virtual world may be an account for storing the virtual transaction, wherein the virtual transaction may include digital currency or virtual items, the digital currency including but not limited to bitcoin, ledebur coin, dog coin, gold coin, fuyuan coin, or rembo coin, etc.; virtual items include, but are not limited to, stocks or funds, etc.

Optionally, in the embodiment of the present invention, the transfer-out account may correspond to two different types of accounts, respectively, one of the accounts may be used to store the real-time currency, and the other account may be used to store the virtual transaction items that are virtually circulated.

In an optional embodiment of the present invention, when the historical financial transaction data is the original financial transaction data, the historical financial transaction data may include: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information may include: a source of raw data.

Where the original financial transaction data may relate only to the original financial data, for example, in the original financial transaction data, the transfer-in party information may not include the historical data identifying information but may include the original data source information.

Illustratively, assuming T stock has 1 stock and 10 blocks, node A has 100 ten thousand RMB real assets, and node B also has 100 ten thousand RMB real assets. Of these, 100 thousands of data sources may be the original data sources corresponding to node a and node B. If node B bought 1 million shares of T stock, the original financial transaction record for node A may be { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a }; the original financial transaction record for the node B may be SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: address 2 of node B). Wherein, the IN field is used to identify original data source information, i.e. 100 ten thousand of original real assets, address 1 is the address of the virtual asset, and address 2 is the address of the real asset. If the historical financial transaction data is not the original data source information, the IN field is used for identifying the transfer-IN party information, and specifically can be historical data identification information. The information corresponding to the OUT field may be different types of roll-OUT accounts.

S130, the block verification node performs data verification on the financial transaction data in the to-be-verified block according to the historical data identification information of the financial transaction data.

In the embodiment of the invention, after the block verification node receives the block to be verified, the data verification can be carried out on the block to be verified according to the historical data identification information of the financial transaction data in the block to be verified. Meanwhile, the latest historical financial transaction data can be stored in the block verification node so as to provide verification basis for the financial transaction data needing to be verified. It should be noted that in the block-chain network, the "double-flower" problem is often generated due to network delay or other factors. Where "double flowers" may be the same data used to complete two different transactions. For example, a "double flower" may be the same fund for two different transactions. In the embodiment of the invention, each piece of financial transaction data only has unique data identification information corresponding to the financial transaction data, and the generation of the data identification information is associated with the transaction data of the historical financial transaction data. Therefore, the transaction data in the block to be verified is subjected to data verification according to the historical data identification information of the financial transaction data, so that error data can be effectively prevented from being added into the block chain network, and the problem of 'double flowers' is avoided.

According to the embodiment of the invention, the to-be-verified block sent by the block generation node is received by the block verification node, the financial transaction data in the to-be-verified block is obtained, and the data verification is carried out on the financial transaction data in the to-be-verified block according to the historical data identification information of the financial transaction data. Because all historical transaction data are stored in the block verification node, and the historical data identification information can be used for indicating that the transaction data are associated with the historical transaction data, the problem of 'double flowers' in the existing block chain applying the non-mining consensus algorithm can be effectively solved, the situation that error data are added into the block chain is effectively avoided, and the validity of the data in the block chain network is further ensured.

Example two

Fig. 2 is a flowchart of a verification method for a blockchain according to a second embodiment of the present invention, which is embodied based on the above-described embodiment, and in this embodiment, a specific implementation manner for respectively performing data verification on two types of roll-out accounts in financial transaction data is provided. Correspondingly, as shown in fig. 2, the method of the present embodiment may include:

s210, the block verification node receives a to-be-verified block sent by a block generation node, wherein the block generation node is a node selected by setting a consensus mechanism.

S220, the block verification node acquires financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identifying information associated with the historical financial transaction data.

And S230, the block verification node acquires historical transaction data associated with the currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifies the currently processed financial transaction data according to the verification data.

In the embodiment of the invention, when the block verification node verifies the currently processed financial transaction data, the block verification node can directly search the corresponding historical financial transaction data in the local database as verification data according to the historical data identification information extracted from the data content of the currently processed financial transaction data so as to realize the verification of the currently processed financial transaction data.

In an optional embodiment of the present invention, the data identification information may include: a number of financial transaction data; the historical data identification information may include: a number of historical financial transaction data. Accordingly, S230 may be further detailed into specific operations of S231-S234.

S231, the block verification node acquires historical financial transaction data corresponding to the serial number of the historical financial transaction data according to the serial number of the historical financial transaction data.

Specifically, the block verification node may search, according to the serial number of the historical financial transaction data included in the transfer party information in the currently processed financial transaction data, the corresponding historical financial transaction data in the local database as verification data, so as to verify the currently processed financial transaction data.

S232, the block verification node obtains all transfer-in lines respectively corresponding to all types of transfer-in accounts corresponding to the historical financial transaction data as total lines respectively corresponding to all types of transfer-out accounts of the currently processed financial transaction data.

Correspondingly, the block verification node can transfer all types corresponding to the historical financial transaction data corresponding to the serial number of the historical financial transaction data into the account and respectively correspond to all transferred-in lines, and the transferred-in lines serve as total lines respectively corresponding to all types of transferred-out accounts of the currently processed financial transaction data. It should be noted that different types of transfer-out accounts need to be calculated according to the types of the transfer-out accounts.

S233, the block verification node judges whether the sum of the transfer-out amount corresponding to each type of the transfer-out account in the currently processed financial transaction data is matched with the total amount corresponding to each type of the transfer-out account in the currently processed financial transaction data, if so, S234 is executed, otherwise, S260 is executed.

S234, the block verification node determines that the currently processed financial transaction data is verified.

Correspondingly, if the block verification node determines that the sum of the transfer-out amount corresponding to each type of transfer-out account in the currently processed financial transaction data is matched with the total amount corresponding to each type of transfer-out account in the currently processed financial transaction data, the currently processed financial transaction data is considered to pass the verification, and the subsequent operation can be continuously executed.

S240, the block verification node obtains a block verification result of the block to be verified according to a data verification result of financial transaction data in the block to be verified, and feeds the block verification result back to the block generation node, so that the block generation node determines whether the block to be verified passes verification.

The block verification result may include two forms of pass verification and fail verification.

In the embodiment of the invention, after the block verification node completes the data verification of all the financial transaction data in the block to be verified, the block verification result of whether the block to be verified passes the verification or not can be obtained. The block verification node transmits the obtained block verification result in the block chain network, and specifically, the block verification result can be fed back to the block generation node in a broadcast manner. After the block generation node receives the block verification result fed back by each block verification node, whether the block to be verified passes the verification can be determined according to the proportion of the passed verification in the area verification result.

It should be noted that, in the embodiment of the present invention, the block generation node may also verify the block to be verified, and obtain the block verification result.

And S250, if the block verification node receives the consensus pass response fed back by the block generation node, adding the block to be verified into a block chain, and updating the locally stored financial transaction data according to the financial transaction data in the block to be verified.

The consensus passing response may be a consensus result of the to-be-verified block determined by the block generation node according to the block verification result. For example, in the consensus algorithm based on Raft, when the verification passing ratio in the block verification result is greater than or equal to a set threshold, such as (f +1)/(2f +1), the block generation node may generate a consensus passing response indicating that the block to be verified passes the consensus.

In the embodiment of the invention, when the block verification node receives the consensus-passing response fed back by the block generation node, the block to be verified passes the consensus. At this time, the block verification node may add the verified block passing the consensus to the tail of the block chain to complete the uplink operation. Meanwhile, the block verification node may update the locally stored financial transaction data according to the financial transaction data in the block to be verified, specifically, the latest financial transaction data in the block to be verified may be stored in the local database.

And S260, if the block verification node receives the consensus failure response fed back by the block generation node, deleting the block to be verified.

Correspondingly, after the block generation node receives the block verification result fed back by each block verification node, if the to-be-verified block is determined to be not verified according to the proportion of passing verification in the area verification result, the consensus failing response can be transmitted in the block chain network, and the to-be-verified block is deleted. And if the consensus fed back by the block generation node is not passed through the response by the block verification node, the block to be verified is deleted if the consensus does not pass through the response, which indicates that the currently processed block to be verified does not pass through the consensus.

In a specific example, the block generation node may store the complete financial transaction record in its local database, and the other nodes are common nodes, that is, block verification nodes, and the block verification nodes may store the latest financial transaction record in their local databases. The financial transaction records already stored in the database may be used as input transaction records and the financial transaction records to be verified in the block may be used as output transaction records. The transaction total for each output transaction record must be consistent with the transaction total for the corresponding input transaction record, except that each output transaction record must be able to find the corresponding input transaction record in the local database.

Each node sends the financial transaction records of the node to a public transaction cache region, the block generation node takes out a plurality of financial transaction records from the public transaction cache region and puts the financial transaction records into a block to be verified, hash operation is carried out on the financial transaction records, the hash operation result is encrypted by using a private key of the node, the encrypted hash result is put into the block to be verified together, and then the block to be verified is broadcasted to all the nodes participating in consensus on a block chain. And the block generation node participates in verification, after receiving the block to be verified, the block verification node decrypts the encrypted hash result in the block to be verified by using the public key of the block generation node to obtain a decrypted hash result, then performs hash operation on a plurality of financial transaction records in the block to be verified, compares the hash result obtained by operation with the hash result decrypted in the block, and if the hash result is consistent with the hash result obtained by operation, the block to be verified is sent by the block generation node and is not tampered in the transmission process.

And after the block to be verified is received by the block verification node, the financial transaction data in the block to be verified is verified one by one. The block verification node can search an input transaction record corresponding to historical data identification information in the currently processed financial transaction data, and compares whether the total transaction amount in the input transaction record is consistent with the total transaction amount in the output transaction record, if so, the verification is passed. And if all the financial transaction records and the output transaction records in the block to be verified are verified to be passed, the block verification node returns a response of verification passing to the block generation node. And after the block generation node receives a certain proportion of responses that the verification passes, judging that the blocks to be verified pass the consensus. Then the block generating node broadcasts the consensus passing response in the block chain, and the block verifying node and the block generating node which receive the broadcast message add the block to be verified to the tail part of the block chain so as to complete the uplink operation. Meanwhile, each node in the block chain network can update the financial transaction records stored in the local database according to the financial transaction records in the to-be-verified block.

Specifically, the block chain has nodes a-C, the nodes B-C are block verification nodes, the node a is a block generation node, and the nodes a-C have their own local databases. Assume that T stock has 1 stock of 10 blocks, node A has 100 ten thousand RMBs, node B has 100 ten thousand RMBs, and node B has bought 1 ten thousand T stocks. Node a and node B each record a financial transaction { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a and SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: node B address 2 is sent to the common transaction buffer. Wherein, SN represents the number corresponding to the financial transaction record, IN represents the number corresponding to the historical financial transaction record (when the financial transaction record is the original financial transaction data, IN may represent the original asset information of the current financial transaction record), the number may be the specific transaction number corresponding to the roll-OUT account of the corresponding virtual asset, and OUT represents the transaction output object, i.e. the address field corresponding to the roll-OUT account. When the transaction record is generated, if the number of the historical financial transaction record does not exist, the node generates the number of the initial financial transaction record, namely, an initial value is given to the SN field, namely, A0001 and B0001 are given, and the original data source is reserved IN the IN field, namely, 100 ten thousand is given; the address 1 of the node A is used for representing the transfer-out account address corresponding to the real asset of the node A, and the address 2 of the node A is used for representing the transfer-out account address corresponding to the virtual asset of the node A. Similarly, address 1 of node B represents the transfer-out account address corresponding to the real asset of node B, and address 2 of node B is used to represent the transfer-out account address corresponding to the virtual asset of node B. It should be noted that the address 1 and the address 2 may be account names, and specifically may be random character strings. Accordingly, the above-mentioned financial transaction record means that node A currently has 100 million RMBs placed at node A's address 1. Node B also has 100 ten thousand RMBs, of which 10 ten thousand have purchased 1 ten thousand T shares, and is placed at node B's address 1, and the remaining 90 thousand RMBs are placed at node B's address 2.

Further, the block generation node a takes out the two financial transaction records from the public transaction cache area, performs hash operation on the multiple financial transaction records, encrypts the hash operation result by using a private key of the block generation node a, places the financial transaction record and the encrypted hash result into a block to be verified, and broadcasts the block to be verified to all the nodes participating in consensus on a block chain. After the block to be verified is received by the block verification nodes B and C, the encrypted hash result in the block to be verified is decrypted by using the public key of the block generation node A to obtain the decrypted hash result, then hash operation is carried out on the financial transaction record in the block to be verified, the hash result obtained by operation and the hash result decrypted in the block to be verified are compared, and if the hash result obtained by operation is consistent with the hash result obtained by operation, the block to be verified is sent by the block generation node and is not tampered in the transmission process.

Further, the nodes A-C detect the two financial transaction records, and if no serial number of the financial transaction data exists IN the IN field, the nodes A-C know that the received financial transaction record is the financial transaction source data. It should be noted that the financial transaction source data may be validated by setting a method, such as sending the financial transaction record to a third party authentication node for authentication. The node A-C verifies the two financial transaction source data, and the block verification node B-C feeds back a verification result of verification passing to the block generation node A. At this time, the block generation node A judges that the block to be verified passes the consensus according to the received verification result. In the case of passing consensus, the nodes a-C update the financial transaction records in the locally stored block to be verified based on the financial transaction records with initial numbers a0001 and B0001. That is, at this time, the local databases of nodes A-C each have a financial transaction record { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a and SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: address 2 of node B).

Accordingly, if node B has another financial transaction with node a in a subsequent time period and the stock price has not changed, node a and B may automatically count SNs and generate a new number, at which point node B sells 1 kt stock to node a and records the next financial transaction generated { SN: a0002, IN: a0001, B0001, amount: 2 kT stock, OUT: address 1 of node a, amount: 98 ten thousand, OUT: address 2 of node a; SN: b0002, IN: a0001, B0001, amount: 8 kilo T stock, OUT: address 1 of node B, amount: 92 ten thousand, OUT: node B address 2 is sent to the common transaction buffer. The financial transaction record means that the first transaction is the 2 kt stock purchased by node a from node B, placed at node a's address 1, with the remaining amount of 98 ten thousand at node a, placed at node a's address 2. The second transaction is for node B to transfer the remaining 8 kt shares to itself, at node B address 1, with a remaining amount of 92 ten thousand in node B, at node B address 2. The block generation node A takes the financial transaction record out of the public transaction cache area, processes the financial transaction record and then places the financial transaction record into a block for broadcasting, and the nodes A-C detect that the transaction source number exists IN the IN field of the financial transaction record, so that the financial transaction records with the numbers of A0001 and B0001 are found from the local database, namely the input transaction record. Nodes a-C calculate that the total amount of address 1 in the input transaction records, i.e., a0001 and B0001, is 1 ten thousand T stocks and the total amount of address 2 is 190 ten thousand. Meanwhile, the calculation output transaction records, namely 1 ten thousand of T stocks and 8 thousand of T stocks in the sum of 2 thousand of the address 1 in A0002 and B0002, are 1 ten thousand of T stocks, and 190 ten thousand of 92 ten thousand of the sum of 98 thousand of the address 2 are calculated. Comparing the two calculation results, finding that the transaction total amount of the two transfer accounts in the input transaction record is respectively corresponding to the transaction total amount of the two transfer accounts in the output transaction record, and then returning a response of passing the verification to the block generation node A. If the block generation node a receives verification passing responses larger than or equal to a certain proportion, the consensus is considered to pass, for example, verification passing responses of 2f +1 nodes are received in 3f +1 nodes of the PBFT, and verification passing responses of f +1 nodes are received in 2f +1 nodes of the Raft. After the consensus passes, the block generation node adds the block passing the consensus into the block chain, and broadcasts a consensus passing response to other block verification nodes. And the block verification node adds the blocks passing the consensus into the block chain according to the consensus response, updates the local database respectively and stores corresponding financial transaction records. It should be noted that the block generation node may store all financial transaction records, and the block verification node may store only the latest transaction record. That is, the financial transaction record stored in the database of the block generation node a at this time is { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a; SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: address 2 of node B; SN: a0002, IN: a0001, B0001, amount: 2 kT stock, OUT: address 1 of node a, amount: 98 ten thousand, OUT: address 2 of node a; SN: b0002, IN: a0001, B0001, amount: 8 kilo T stock, OUT: address 1 of node B, amount: 92 ten thousand, OUT: address 2 of node B, and the financial transaction record stored in the database of nodes B and C is SN: a0002, IN: a0001, B0001, amount: 2 kT stock, OUT: address 1 of node a, amount: 98 ten thousand, OUT: address 2 of node a; SN: b0002, IN: a0001, B0001, amount: 8 kilo T stock, OUT: address 1 of node B, amount: 92 ten thousand, OUT: address 2 of node B).

Nodes a and B then continue to automatically count SNs and generate new numbers, if the stock price changes at the next time point, 1 share of T stock is 20, while node B sells node a with two thousand T stocks and records the next financial transaction { SN: a0003, IN: a0002, B0002, amount: 4 kilo T stock, OUT: address 1 of node a, amount: 94 ten thousand, OUT: address 2 of node a; SN: b0003, IN: a0002, B0002, amount: 6 kilo T stock, OUT: address 1 of node B, amount: 96 ten thousand, OUT: node B address 2 is sent to the common transaction buffer. The financial transaction record means that the first transaction is the 2 kt stock purchased by node a from node B, placed at node a's address 1, with the remaining amount of 98 ten thousand at node a, placed at node a's address 2. The second transaction is for node B to transfer the remaining 8 kt shares to itself, at node B's address 1, for a remainder of 92 tens of thousands at node a, at node B's address 2. And the block generation node A takes the two financial transaction records out of the public transaction cache area for processing, generates a block to be verified and broadcasts the block. The block verification node B-C verifies the received financial transaction record IN the block to be verified, detects that the IN field of the financial transaction record has a transaction source number, then finds the financial transaction records with numbers a0002 and B0002, i.e. the input transaction records, from the local database, calculates the total amount of the address 1 IN the input transaction records, i.e. a0002 and B0002, as 1 ten thousand T stocks and the total amount of the address 2 as 190 ten thousand, calculates the total amount of the address 1 IN the corresponding output transaction records, i.e. a0003 and B0003, as 4 thousand plus 6 thousand T stocks, i.e. 1 ten thousand T stocks and the total amount of the address 2 as 94 ten thousand plus 96 ten thousand as 190 ten thousand IN the corresponding output transaction records. Comparing the two calculation results, finding that the transaction total amount of the two transferred accounts in the input transaction record is respectively corresponding to the transaction total amount of the two transferred accounts in the output transaction record, then returning a response of passing the verification to the block generation node A, and if the block generation node A receives the response of passing the verification in a certain proportion or more, considering that the common identification passes. And after the consensus passes, the block generation node adds the block into the block chain and broadcasts a consensus passing response to the block verification node. And the block verification node adds the blocks passing the consensus into the block chain according to the consensus response, updates the local database respectively and stores corresponding financial transaction records. That is, the financial transaction record stored in the local database of the block generation node a at this time is { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a; SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: address 2 of node B; SN: a0002, IN: a0001, B0001, amount: 2 kT stock, OUT: address 1 of node a, amount: 98 ten thousand, OUT: address 2 of node a; SN: b0002, IN: a0001, B0001, amount: 8 kilo T stock, OUT: address 1 of node B, amount: 92 ten thousand, OUT: address 2 of node B; SN: a0003, IN: a0002, B0002, amount: 4 kilo T stock, OUT: address 1 of node a, amount: 94 ten thousand, OUT: address 2 of node a; SN: b0003, IN: a0002, B0002, amount: 6 kilo T stock, OUT: address 1 of node B, amount: 96 ten thousand, OUT: address 2 of node B). The financial transaction records stored in the local databases of the block verification nodes B and C are { SN: a0003, IN: a0002, B0002, amount: 4 kilo T stock, OUT: address 1 of node a, amount: 94 ten thousand, OUT: address 2 of node a; SN: b0003, IN: a0002, B0002, amount: 6 kilo T stock, OUT: address 1 of node B, amount: 96 ten thousand, OUT: address 2 of node B).

In another specific example, there are nodes a-C in the blockchain, node a being a blockgenerating node, and nodes a-C all having their own local databases. Node B records a financial transaction record SN: a0002, IN: a0001, B0001, amount: 2 kT stock, OUT: address 1 of node a, amount: 98 ten thousand, OUT: address 2 of node a; SN: b0002, IN: a0001, B0001, amount: 9 kilo T stock, OUT: address 1 of node B, amount: 92 ten thousand, OUT: address 2 of node B is sent to the public transaction cache, that is, at this time, 1 ten thousand T stocks in node B make two transactions, node B transfers 1 thousand T stocks in 2 thousand T stocks paid out to its own account, nodes a-C calculate that the total amount of address 1 in input transaction records, i.e., a0001 and B0001, is 1 ten thousand T stocks, and the total amount of address 2 is 190 ten thousand. Meanwhile, the total amount of address 1 in the calculation output transaction records, namely A0002 and B0002, is 1 ten thousand (1 thousand) of stock, and the total amount of address 2 is 190 thousand. Comparing the two calculation results, finding that the transaction total amount of the two transferred accounts in the input transaction record is not corresponding to the transaction total amount of the two transferred accounts in the output transaction record, and then the block verification node B-C returns a response that the verification fails to pass to the block generation node A, at the moment, the block generation node A judges that the block to be verified does not pass the consensus according to the received verification result, and then the block generation node A sends the response that the consensus fails to pass to each block verification node B-C. And the block verification node B-C judges that the block to be verified does not pass the consensus according to the received consensus failing response, and each node in the block chain network abandons the block to be verified and executes the processes of block generation, verification and consensus again, thereby avoiding 'double flowers'.

It should be noted that, after the current block generation node fails, a new block generation node is selected by setting a common recognition mechanism, the failed block generation node may be converted into a block verification node, all financial transaction records are synchronized with the new block generation node, and the state of the historical financial transaction records in the database of the failed block generation node except the latest financial transaction record is invalid, and only the state of the latest financial transaction record is valid. The invalid block generation node can be converted into a block verification node, and when the block verification is carried out, the historical financial transaction number corresponding to the transaction source number is obtained in the local database only through the latest financial transaction record, so that the historical financial transaction record is prevented from being reused by the transaction node.

By adopting the technical scheme, the two types of transfer-out accounts in the financial transaction data are respectively subjected to data verification through the block verification node. After the block verification is passed, each node can update the locally stored financial transaction data according to the financial transaction data included in the block to be verified, and the problem of 'double flowers' in the existing block chain applying the non-mining consensus algorithm can be effectively solved, so that the error data is prevented from being added into the block chain, and the validity of the data in the block chain network is further ensured.

EXAMPLE III

Fig. 3 is a flowchart of a verification method for a block chain according to a third embodiment of the present invention, where this embodiment is applicable to a case where a block generation node obtains a verification result of a block to be verified, and the method may be executed by a verification apparatus for a block chain, where the apparatus may be implemented by software and/or hardware, and may be generally integrated in a computer device, and the computer device may be a device that bears a node of the block chain. Accordingly, as shown in fig. 3, the method includes the following operations:

s310, generating a to-be-verified block by a block generation node, and sending the to-be-verified block to a block verification node of a block chain network, wherein the block generation node is a node selected by a set consensus mechanism.

The to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data;

the blockchain network may be a public chain or a federation chain. The blockchain network may comprise a basic chain, i.e. a main chain, while side chains, sub-chains or lightning networks may be comprised. The block verification node may be another blockchain network node participating in the verification process of the block generation node sending the block. The block generation node may be a node in the blockchain network that has block processing authority. The set consensus mechanism may be a non-mining consensus mechanism such as the PBFT or Raft algorithm. Financial transaction data includes, but is not limited to, transactions of funds, equity, digital currency, and funds, among others. The historical data identification information may be a number or identification or the like indicating the historical financial transaction with which the current financial transaction data is associated.

In the embodiment of the invention, the block generation node with the block processing authority can acquire financial transaction data from a cache region of the block chain network, process the financial transaction data, package and package the financial transaction data and the acquired transaction data to generate the block to be verified, and transmit the block to be verified to the block chain network, so that the block to be verified is verified by the block verification node.

S320, the block generation node acquires a block verification result of the block to be verified by the block verification node according to the historical data identification information of the financial transaction data in the block to be verified.

Wherein the historical data identification information may be a number or identification or the like indicating the historical financial transaction associated with the current financial transaction data.

In the embodiment of the invention, after the block generation node sends the block to be verified to each block verification node, the block verification node verifies the received block to be verified to obtain a block verification result, and the block verification result is fed back to the block generation node. Correspondingly, the block verification node needs to verify the block to be verified according to the historical data identification information in the block to be verified.

According to the embodiment of the invention, the block to be verified is generated by the block generation node and sent to the block verification node of the block chain network, and the block verification result of the block to be verified by the block verification node according to the historical data identification information of the financial transaction data in the block to be verified is obtained, so that whether the block to be verified passes the consensus or not is judged according to the verification result. The block generation node is generated by a set consensus mechanism, wherein the set consensus does not comprise an ore excavation algorithm, the problem of 'double flowers' in the block chain applying the existing non-ore excavation consensus algorithm can be effectively solved, error data are prevented from being added into the block chain, and the validity of the data in the block chain network is further ensured.

In an optional embodiment of the present invention, may further include: the block generation node judges whether the block to be verified passes the verification of the block verification node according to the block verification result, if the block generation node determines that the block to be verified passes the consensus according to the block verification result, the block generation node updates the locally stored financial transaction data according to the financial transaction data in the block to be verified, and feeds back the consensus passing response to the block verification node; the consensus pass response is used for indicating the block verification node to add the block to be verified into a block chain; and meanwhile, the block generation node adds the block to be verified into a block chain through a response according to the consensus.

In the embodiment of the invention, after the block verification node completes the data verification of all the financial transaction data in the block to be verified, the block verification result of whether the block to be verified passes the verification or not can be obtained. The block verification node transmits the obtained block verification result in the block chain network, and specifically, the block verification result can be fed back to the block generation node in a broadcast manner. After the block generation node receives the block verification result fed back by each block verification node, whether the block to be verified passes the verification can be determined according to the proportion of the passed verification in the area verification result. If the block generation node determines that the block to be verified passes verification, the block to be verified may be added to the block chain, and the financial transaction data in the block to be verified updates the locally stored financial transaction data, specifically, the financial transaction data in the block to be verified may be added to the database. Meanwhile, the block generation node can also feed back the consensus passing response to the block verification node, and after receiving the consensus passing response fed back by the block generation node, the block verification node adds the block to be verified into the block chain and updates the locally stored financial transaction data according to the financial transaction data in the block to be verified.

In an optional embodiment of the invention, the financial transaction data comprises: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: at least one historical data identification information associated with the historical financial transaction data; the roll-out information includes: at least two types of roll-out accounts.

The data identification information is used to indicate a number, an identifier, or the like of the current financial transaction data, and may specifically be a character string including a node identifier, such as a0001, and of course, a random number may also be added to the number to avoid generating a duplicate number, for example, the number may be Ar0001, where r is a random number generated by the authentication node, the number of bits of the random number may be set according to actual needs, the random number generated each time is different, and Ar in the number is only used as an identifier and is not counted, and the number is counted by 0001 in the number, for example, when r is 123, the counting range of the initial number a1230001 is a1230001-a 1239999. The embodiment of the invention does not limit the method and the form for realizing the numbering of the financial transaction data. Accordingly, the roll-out party information may be a roll-out account for the assets, equities, virtual currency, funds, etc. involved in the transaction, e.g., when B sells 1 thousand shares to a, the address in a for storing the bought 1 thousand shares may be used as a roll-out account. Accordingly, the transfer-in party information may be historical data identification information corresponding to historical financial transaction data associated with the current financial transaction data in the financial transaction data. For example, when B sells 1 thousand shares to a, the number corresponding to the financial transaction data last related to a and B may be used as transfer-in party information. It should be noted that, in the embodiment of the present invention, the transfer-out party information may include at least two different types of transfer-out accounts. Such as one of the transfer-out accounts may be used to store real assets and another transfer-out account may store virtual assets, such as stocks, funds or digital currency. Of course, different types of roll-out accounts may also store different types of virtual assets at the same time, which is not limited by the embodiment of the present invention.

In an optional embodiment of the invention, the transferring out of the account comprises: an account of financial currency circulated in the real world, and an account of a virtual transaction circulated in the virtual world, the virtual transaction including: digital currency or virtual items.

In an optional embodiment of the invention, when the historical financial transaction data is original financial transaction data, the historical financial transaction data comprises: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: a source of raw data.

Illustratively, assuming T stock has 1 stock and 10 blocks, node A has 100 ten thousand RMB real assets, and node B also has 100 ten thousand RMB real assets. Of these, 100 thousands of data sources may be the original data sources corresponding to node a and node B. If node B bought 1 million shares of T stock, the original financial transaction record for node A may be { SN: a0001, IN: 100 ten thousand, quantity: 0, OUT: address 1 of node a, amount: 100 ten thousand, OUT: address 2 of node a }; the original financial transaction record for the node B may be SN: b0001, IN: 100 ten thousand, quantity: 1 ten thousand T stocks, OUT: address 1 of node B, amount: 90 ten thousand, OUT: address 2 of node B). Where the IN field is used to identify the original data source information, i.e., the original real asset, 100 million. If the historical financial transaction data is not the original data source information, the IN field is used for identifying the transfer-IN party information, and specifically can be historical data identification information. The information corresponding to the OUT field may be different types of roll-OUT accounts.

Example four

Fig. 4 is a schematic diagram of a block chain verification apparatus according to a fourth embodiment of the present invention, and as shown in fig. 4, the apparatus is configured at a block verification node, and specifically includes: a block receiving module 410, a data obtaining module 420 and a data verifying module 430, wherein:

a block receiving module 410, configured to receive a block to be verified sent by a block generating node, where the block generating node is a node selected by setting a consensus mechanism;

a data obtaining module 420, configured to obtain financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data;

the data verification module 430 is configured to perform data verification on the financial transaction data in the to-be-verified block according to the historical data identification information of the financial transaction data;

Optionally, the financial transaction data includes: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: at least one historical data identification information associated with the historical financial transaction data; the roll-out information includes: at least two types of roll-out accounts.

Optionally, the transferring out account includes: an account of financial currency circulated in the real world, and an account of a virtual transaction circulated in the virtual world, the virtual transaction including: digital currency or virtual items.

Optionally, the data verification module 430 is further configured to obtain historical transaction data associated with the currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verify the currently processed financial transaction data according to the verification data.

Optionally, the data identification information includes: a number of financial transaction data; the historical data identification information includes: a number of historical financial transaction data; the data verification module 330 is further configured to obtain historical financial transaction data corresponding to the number of the historical financial transaction data according to the number of the historical financial transaction data; acquiring all transfer-in limits corresponding to each type of transfer-in account corresponding to the historical financial transaction data as total limits corresponding to each type of transfer-out account of the currently processed financial transaction data; verifying whether the sum of the transfer-out amount respectively corresponding to each type of transfer-out account in the currently processed financial transaction data is matched with the total amount respectively corresponding to each type of transfer-out account in the currently processed financial transaction data; and if so, determining that the currently processed financial transaction data passes verification.

Optionally, the apparatus further comprises: the block adding module is used for obtaining a block verification result of the block to be verified according to a data verification result of financial transaction data in the block to be verified, and feeding the block verification result back to the block generating node so that the block generating node can determine whether the block to be verified passes verification; and if the consensus passing response fed back by the block generation node is received, adding the block to be verified into a block chain.

Optionally, when the historical financial transaction data is original financial transaction data, the historical financial transaction data includes: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: a source of raw data.

Optionally, the apparatus further comprises: and the data updating module is used for updating the locally stored financial transaction data according to the financial transaction data in the to-be-verified block if the consensus passing response fed back by the block generating node is received.

The verification device for the block chain can execute the verification method for the block chain provided by the first embodiment and the second embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to the block chain verification method provided in any embodiment of the present invention.

EXAMPLE five

Fig. 5 is a schematic diagram of a verification apparatus for a block chain according to a fifth embodiment of the present invention, as shown in fig. 5, the apparatus is configured at a block generation node, and specifically includes: a block generation module 510 and a result acquisition module 520, wherein:

a block generation module 510, configured to generate a block to be verified and send the block to a block verification node of a block chain network, where the block generation node is a node elected by setting a consensus mechanism; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data;

a result obtaining module 520, configured to obtain a block verification result obtained by verifying the to-be-verified block by the block verification node according to the historical data identification information of the financial transaction data in the to-be-verified block;

Optionally, the apparatus further comprises: the information updating and sending module is used for judging whether the block to be verified passes the verification of the block verification node according to the block verification result, if the block to be verified passes the consensus according to the block verification result, updating the locally stored financial transaction data according to the financial transaction data in the block to be verified, and feeding back the consensus passing response to the block verification node; the consensus pass response is used for indicating the block verification node to add the block to be verified into a block chain;

and the block adding module is used for adding the block to be verified into the block chain according to the consensus through response.

The verification device of the block chain can execute the verification method of the block chain provided by the third embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in this embodiment, reference may be made to the block chain verification method provided in any embodiment of the present invention.

EXAMPLE six

Fig. 6 is a schematic structural diagram of a computer device according to a sixth embodiment of the present invention. FIG. 6 illustrates a block diagram of a computer device 612 suitable for use in implementing embodiments of the present invention. The computer device 612 shown in fig. 6 is only an example and should not bring any limitations to the functionality or scope of use of embodiments of the present invention. Computer device 612 is typically a computing device that assumes the functionality of a node of the blockchain system.

As shown in fig. 6, the computer device 612 is in the form of a general purpose computing device. Components of computer device 612 may include, but are not limited to: one or more processors 616, a memory device 628, and a bus 618 that couples the various system components including the memory device 628 and the processors 616.

Bus 618 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

Computer device 612 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer device 612 and includes both volatile and nonvolatile media, removable and non-removable media.

Storage 628 may include computer system readable media in the form of volatile Memory, such as Random Access Memory (RAM) 630 and/or cache Memory 632. The computer device 612 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 634 may be used to read from or write to non-removable, nonvolatile magnetic media (not shown in FIG. 6, commonly referred to as a "hard disk drive"). Although not shown in FIG. 6, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a Compact disk-Read Only Memory (CD-ROM), a Digital Video disk (DVD-ROM), or other optical media) may be provided. In such cases, each drive may be connected to bus 618 by one or more data media interfaces. Storage device 628 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

A program 636 having a set (at least one) of program modules 626 may be stored, for example, in storage device 628, such program modules 626 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which examples or some combination thereof may include an implementation of a network environment. Program modules 626 generally perform the functions and/or methodologies of embodiments of the invention as described herein.

Computer device 612 may also communicate with one or more external devices 614 (e.g., keyboard, pointing device, camera, display 624, etc.), with one or more devices that enable a user to interact with computer device 612, and/or with any devices (e.g., network card, modem, etc.) that enable computer device 612 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interfaces 622. Further, computer device 612 may also communicate with one or more networks (e.g., a Local Area Network (LAN), Wide Area Network (WAN), and/or a public Network, such as the internet) via Network adapter 620. As shown, the network adapter 620 communicates with the other modules of the computer device 612 via the bus 618. It should be appreciated that although not shown, other hardware and/or software modules may be used in conjunction with the computer device 612, including but not limited to: microcode, device drivers, Redundant processing units, external disk drive Arrays, disk array (RAID) systems, tape drives, and data backup storage systems, to name a few.

The processor 616 executes various functional applications and data processing by executing programs stored in the storage device 628, for example, implementing the verification method of the block chain provided by any of the above embodiments of the present invention.

And receiving the to-be-verified block sent by the block generating node through the computer equipment, acquiring the financial transaction data in the to-be-verified block, and performing data verification on the financial transaction data in the to-be-verified block according to historical data identification information of the financial transaction data. Because the latest historical transaction data is stored in the block verification node, and the historical data identification information can be used for indicating that the transaction data is associated with the historical transaction data, the problem of 'double flowers' in the existing block chain applying the non-mining consensus algorithm can be effectively solved, the situation that error data is added into the block chain is effectively avoided, and the validity of the data in the block chain network is further ensured.

EXAMPLE seven

An embodiment of the present invention further provides a computer storage medium storing a computer program, which when executed by a computer processor is configured to execute the following block chain verification method of the present invention:

the block verification node receives a to-be-verified block sent by a block generation node, wherein the block generation node is a node selected by a set consensus mechanism; the block verification node acquires financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data; the block verification node performs data verification on the financial transaction data in the block to be verified according to the historical data identification information of the financial transaction data; wherein the block verification node has stored therein latest historical financial transaction data.

Alternatively, the following block chain verification method of the present invention is performed:

a block generation node generates a block to be verified and sends the block to be verified to a block verification node of a block chain network, wherein the block generation node is a node selected by a set consensus mechanism; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data; the block generation node acquires a block verification result of the block to be verified by the block verification node according to historical data identification information of financial transaction data in the block to be verified; wherein all historical financial transaction data is stored in the block generation node.

Further, the computer program is configured to perform the method for verifying a blockchain according to any of the above embodiments of the present invention when the computer program is executed by a computer processor.

Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM) or flash Memory), an optical fiber, a portable compact disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, Radio Frequency (RF), etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for verifying a blockchain, comprising:

the block verification node receives a to-be-verified block sent by a block generation node, wherein the block generation node is a node selected by a set consensus mechanism; the block verification node stores latest historical financial transaction data;

the block verification node acquires financial transaction data in the to-be-verified block; wherein the financial transaction data comprises: at least one historical data identification information associated with historical financial transaction data, the historical data identification information being generated in association with transaction data of the historical financial transaction data, each piece of financial transaction data having a unique historical data identification information corresponding thereto;

the block verification node acquires historical transaction data associated with the currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifies the currently processed financial transaction data according to the verification data; wherein the historical data identification information is a number or identification indicating the historical financial transaction associated with the current financial transaction data, and is used for indicating that the current financial transaction data is associated with the historical financial transaction data.

2. The method of claim 1, wherein the financial transaction data comprises: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: at least one historical data identification information associated with the historical financial transaction data; the roll-out information includes: at least two types of roll-out accounts.

3. The method of claim 2, wherein transferring out an account comprises: an account of financial currency circulated in the real world, and an account of a virtual transaction circulated in the virtual world, the virtual transaction including: digital currency or virtual items.

4. The method of claim 3, wherein the data identification information comprises: a number of financial transaction data; the historical data identification information includes: a number of historical financial transaction data;

the block verification node acquires historical transaction data associated with currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifies the currently processed financial transaction data according to the verification data, wherein the verification method comprises the following steps:

the block verification node acquires historical financial transaction data corresponding to the serial number of the historical financial transaction data according to the serial number of the historical financial transaction data;

the block verification node acquires all transfer-in lines respectively corresponding to all types of transfer-in accounts corresponding to the historical financial transaction data as total lines respectively corresponding to all types of transfer-out accounts of the currently processed financial transaction data;

the block verification node verifies whether the sum of the transfer-out amount corresponding to each type of transfer-out account in the currently processed financial transaction data is matched with the total amount corresponding to each type of transfer-out account in the currently processed financial transaction data;

if yes, the block verification node determines that the currently processed financial transaction data is verified.

5. The method of claim 1, further comprising:

the block verification node obtains a block verification result of the block to be verified according to a data verification result of financial transaction data in the block to be verified, and feeds the block verification result back to the block generation node, so that the block generation node determines whether the block to be verified passes verification;

and if the block verification node receives the consensus passing response fed back by the block generation node, adding the block to be verified into a block chain.

6. The method of claim 1,

when the historical financial transaction data is original financial transaction data, the historical financial transaction data comprises: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: a source of raw data.

7. The method of claim 5, further comprising:

and if the block verification node receives the consensus passing response fed back by the block generation node, updating the locally stored financial transaction data according to the financial transaction data in the block to be verified.

8. A method for verifying a blockchain, comprising:

a block generation node generates a block to be verified and sends the block to be verified to a block verification node of a block chain network, wherein the block generation node is a node selected by a set consensus mechanism; all historical financial transaction data are stored in the block generation node; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with the historical financial transaction data; the generation of the historical data identification information is associated with the transaction data of the historical financial transaction data, and each piece of financial transaction data has unique historical data identification information corresponding to the transaction data;

the block generation node acquires a block verification result of the block to be verified by the block verification node according to historical data identification information of financial transaction data in the block to be verified;

the block verification node acquires historical transaction data associated with currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifies the currently processed financial transaction data according to the verification data; the historical data identification information is a number or identification indicating a historical financial transaction associated with the current financial transaction data, indicating that the current financial transaction data is associated with the historical financial transaction data.

9. The method of claim 8, further comprising:

the block generation node judges whether the block to be verified passes the verification of the block verification node according to the block verification result, if the block generation node determines that the block to be verified passes the consensus according to the block verification result, the block generation node updates the locally stored financial transaction data according to the financial transaction data in the block to be verified, and feeds back the consensus passing response to the block verification node; the consensus pass response is used for indicating the block verification node to add the block to be verified into a block chain;

and meanwhile, the block generation node adds the block to be verified into a block chain through a response according to the consensus.

10. The method of claim 8, wherein the financial transaction data comprises: data identification information, transfer-in party information and transfer-out party information; the transfer-in party information comprises: at least one historical data identification information associated with the historical financial transaction data; the roll-out information includes: at least two types of roll-out accounts.

11. The method of claim 10, wherein transferring out an account comprises: an account of financial currency circulated in the real world, and an account of a virtual transaction circulated in the virtual world, the virtual transaction including: digital currency or virtual items.

12. The method of claim 11,

13. A blockchain verification device configured at a blockchain verification node, wherein latest historical financial transaction data is stored in the blockchain verification node, the blockchain verification device comprising:

the data acquisition module is used for acquiring financial transaction data in the to-be-verified block; the financial transaction data includes: at least one historical data identification information associated with the historical financial transaction data; generating historical data identification information, wherein the historical data identification information is associated with transaction data of the historical financial transaction data, and each piece of financial transaction data has unique historical data identification information corresponding to the transaction data;

the data verification module is used for acquiring historical transaction data related to the currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifying the currently processed financial transaction data according to the verification data; wherein the historical data identification information is a number or identification indicating the historical financial transaction associated with the current financial transaction data, and is used for indicating that the current financial transaction data is associated with the historical financial transaction data.

14. A blockchain verification device that is disposed at a blockchain generation node that is a node selected by setting a consensus mechanism and that stores all historical financial transaction data, the blockchain verification device comprising:

the block generation module is used for generating a block to be verified and sending the block to be verified to a block verification node of the block chain network; the to-be-verified area comprises financial transaction data, and the financial transaction data comprises: at least one historical data identification information associated with historical financial transaction data, the historical data identification information being generated in association with transaction data of the historical financial transaction data, each piece of financial transaction data having a unique historical data identification information corresponding thereto;

the block verification node acquires historical transaction data associated with currently processed financial transaction data as verification data according to the historical data identification information of the financial transaction data, and verifies the currently processed financial transaction data according to the verification data; the historical data identification information is a number or identification indicating a historical financial transaction associated with the current financial transaction data; the historical data identifying information is used to indicate that the current financial transaction data is associated with historical financial transaction data.

15. A computer device, the device comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement a method of validation of a blockchain as claimed in any one of claims 1 to 7.

16. A computer device, the device comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement a method of validation of a blockchain as claimed in any one of claims 8 to 12.

17. A computer storage medium on which a computer program is stored which, when being executed by a processor, carries out a method of verifying a blockchain according to any one of claims 1 to 7.

18. A computer storage medium on which a computer program is stored which, when being executed by a processor, carries out a method of verifying a blockchain according to any one of claims 8 to 12.