WO2023160094A1

WO2023160094A1 - Blockchain-based transaction verification method and apparatus, and electronic device

Info

Publication number: WO2023160094A1
Application number: PCT/CN2022/135627
Authority: WO
Inventors: 卓海振
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-02-25
Filing date: 2022-11-30
Publication date: 2023-08-31
Also published as: CN114529415A

Abstract

Provided in the embodiments of the present description are a blockchain-based transaction verification method and apparatus, and an electronic device. The method comprises: receiving a transaction sent by a client, wherein the transaction comprises a cryptographic proof, which is acquired by the client from a node device in a blockchain, which node device does not participate in consensus, the cryptographic proof being used for proving that a target account related to the transaction, and state data of the target account, are included in a blockchain ledger of the blockchain; performing legitimacy validation on the transaction, wherein the legitimacy validation comprises validating the cryptographic proof on the basis of a cryptographic algorithm; and if the legitimacy validation is passed, executing the transaction, and after other nodes in the blockchain, which participate in consensus, reach a consensus regarding an execution result of the transaction, sending the transaction and the execution result of the transaction to the node device in the blockchain, which node device does not participate in consensus, and storing the transaction and the execution result of the transaction in the blockchain ledger.

Description

Blockchain-based transaction verification method, device, and electronic equipment

This application claims the priority of the Chinese patent application submitted to the China Patent Office on February 25, 2022, with the application number 202210179227.1, and the title of the invention is "Blockchain-based transaction verification method and device, electronic equipment", the entire content of which is passed References are incorporated in this application.

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a blockchain-based transaction verification method and device, and electronic equipment.

Background technique

In the existing blockchain, the bookkeeping node needs to verify the legality of the transaction before packing the transaction into the block. Only when the transaction is legal can it be packed into the block.

The verification of legitimacy is mainly based on the state data in the blockchain ledger. Therefore, each node device participating in the transaction consensus needs to maintain the full amount of state data in the blockchain ledger locally.

However, as the business increases, state data will continue to increase in the blockchain ledger, and the increase in state data will not only continue to occupy storage space, but also reduce the verification efficiency of node devices participating in the consensus.

Contents of the invention

The embodiments of this specification provide a method, device, and electronic equipment for improving information security.

According to the first aspect of the embodiments of this specification, a blockchain-based transaction verification method is provided, the method is applied to node devices participating in consensus in the blockchain, and the blockchain ledger of the blockchain is stored in the The node device in the above block chain that does not participate in the consensus; the method includes:

Receiving the transaction sent by the client; wherein, the transaction includes that the client obtains from a node device that does not participate in the consensus in the block chain, and is used to prove the target account and the target account related to the transaction Cryptographic proof that the state data of the said blockchain is contained in the blockchain ledger of said blockchain;

Carry out legality verification for the transaction; wherein, the legality verification includes verifying the cryptographic proof based on a cryptographic algorithm;

If the legality check is passed, execute the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, the transaction and the execution result of the transaction will be It is sent to a node device in the blockchain that does not participate in the consensus, and stored in the blockchain ledger.

According to the second aspect of the embodiment of this specification, a blockchain-based transaction verification device is provided, the device is applied to a node device participating in the consensus in the blockchain, and the blockchain ledger of the blockchain is stored in the The node device in the blockchain that does not participate in the consensus; the device includes:

The receiving unit receives the transaction sent by the client; wherein, the transaction includes that the client obtains from a node device in the block chain that does not participate in the consensus, and is used to prove the target account and the transaction related to the transaction. Cryptographic proof that the state data of the target account is included in the blockchain ledger of the blockchain;

A verification unit is configured to verify the legality of the transaction; wherein the legality verification includes verifying the cryptographic proof based on a cryptographic algorithm;

The processing unit, if the validity check is passed, executes the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, transfers the transaction and the transaction The execution results are sent to the node devices in the blockchain that do not participate in the consensus, and stored in the blockchain ledger.

According to a third aspect of the embodiments of this specification, there is provided an electronic device, including:

processor;

memory for storing processor-executable instructions;

Wherein, the processor is configured as any one of the above blockchain-based transaction verification methods.

The embodiment of this specification provides a blockchain-based transaction verification scheme, which verifies the legitimacy of transactions through cryptographic commitments and cryptographic proofs corresponding to blockchain ledgers. Since the cryptographic proof is not based on the account status of the account, the node devices participating in the consensus in the blockchain do not need to store the account status of the full account in the blockchain ledger, thus solving the verification of the node devices participating in the consensus due to too much account status data The problem of low efficiency.

Description of drawings

Fig. 1 is a schematic diagram of the architecture of the block chain system provided by an exemplary embodiment;

Fig. 2 is a schematic diagram of multi-party interaction provided by an exemplary embodiment;

Fig. 3 is a flowchart of a blockchain-based transaction verification method provided by an exemplary embodiment;

Fig. 4 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

Fig. 5 is a block diagram of a blockchain-based transaction verification device provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Due to the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and fast data synchronization between computing devices, blockchain technology has been widely used in many fields. to apply.

In general, blockchains can generally be divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there can be a combination of the above types, such as private chain + alliance chain, alliance chain + public chain, etc.

Among them, the public chain has the highest degree of decentralization. Participants joining the public chain (also known as nodes in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each node can freely join or exit the network and perform related operations.

On the contrary, the private chain, the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for internal use by specific institutions.

The alliance chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity or organization; nodes join the network through authorization and form an alliance of stakeholders to jointly maintain the operation of the blockchain.

Based on the basic characteristics of the blockchain, the blockchain is usually composed of several blocks. Time stamps corresponding to the creation time of the block are respectively recorded in these blocks, and all blocks form a time-ordered data chain in strict accordance with the time stamps recorded in the block.

Existing blockchains need to rely on a Merkle tree (called a state tree or a state database) composed of the state (state) data of all accounts in the blockchain (hereinafter referred to as account states) for consensus on transactions.

Each node device participating in the consensus (hereinafter referred to as the consensus node) will carry out the simulated execution of the transaction during the consensus. The simulated execution here means that the consensus node executes the transaction but does not record the account status after execution to the state tree. That is, simulation execution does not affect the world state.

During the transaction simulation execution process, a read-write set will be generated; the read set contains the latest account status required for transaction execution read by the consensus node locally, and the write set contains the updated account status during the simulation execution process.

Consensus nodes can verify whether the account status required for the transaction is consistent through the read set, and the write set is used to verify whether the account status after execution is consistent. When the read and write sets are consistent, the accounting node can package the transaction into the block and update the state of the world based on the write set.

Based on the above verification process, in the existing transaction verification method based on state data, each consensus node needs to maintain the full amount of state data in the blockchain ledger locally, which requires a large amount of storage space. Especially for multi-version status (historical status data + latest status data), even if the existing blockchain account has not changed, the storage space will continue to increase (a large amount of historical status data causes status data to expand). The ever-increasing state data will not only continue to occupy storage space, but also reduce the verification efficiency of consensus nodes.

Based on the above problems, this specification aims to provide a stateless transaction verification scheme. The legitimacy of the transaction is no longer verified based on state data, but the legitimacy of the transaction is verified based on cryptographic commitments and cryptographic proofs. Since there is no need for state data to participate in the verification, the node devices participating in the consensus do not need to store the full amount of state data in the blockchain ledger locally; thus, the node devices participating in the consensus can be lightweighted to free up storage space and improve the verification of the node devices participating in the consensus efficiency.

Please refer to FIG. 1, which is a schematic diagram of the architecture of a blockchain system provided by an exemplary embodiment. The blockchain system can include at least one node device that does not participate in the consensus (the non-consensus node shown in Figure 1), and a number of node devices that participate in the consensus (the 4 consensus nodes shown in Figure 1). chain, and the client corresponding to the blockchain.

Wherein, the non-consensus node stores the full amount of state data in the blockchain ledger of the block chain (hereinafter, the full amount of state data is referred to as the state database for short). The state database is used to record all accounts in the blockchain and the latest state data of the accounts. The non-consensus node can provide the client with the latest state data and cryptographic proof required for the transaction.

Before publishing the transaction, the client needs to obtain the latest state data and cryptographic proof required for the transaction from the non-consensus node; and then send the transaction, the latest state data and cryptographic proof involved in the transaction to the consensus node of the blockchain .

If there are multiple non-consensus nodes, the optimal non-consensus node can be routed for the client according to the preset strategy (such as load balancing strategy, minimum delay strategy), so that the client can obtain from the optimal non-consensus node data.

Among them, the consensus node that receives and responds to the transaction sent by the client can verify the cryptographic proof provided by the client based on the local cryptographic commitment to determine whether the latest state data is true.

The other consensus nodes are used for consensus on the transaction and transaction results synchronized by the consensus node that responds to the transaction.

In this specification, the blockchain account books of the blockchain are no longer stored in the consensus nodes, that is, the consensus nodes no longer store the state database of the blockchain locally, but the blocks of the blockchain are maintained by special non-consensus nodes. A full state database in the chain ledger. Improve verification efficiency by lightweight consensus nodes.

The cryptographic algorithm in this specification may include a vector commitment (Vector commitment) algorithm, a polynomial algorithm, and the like.

When the cryptography algorithm is the Vector commitment algorithm, the cryptography commitment includes enciphering all blockchain accounts recorded in the full amount of blockchain ledgers and the account states corresponding to all blockchain accounts based on the Vector commitment algorithm Correspondingly, the cryptographic proof includes the proof obtained by performing cryptographic calculation based on the Vector commitment algorithm for the target account recorded in the full amount of blockchain ledger and the state data corresponding to the target account value.

The stateless (Stateless) transaction verification scheme provided by this specification is further introduced below in conjunction with FIG. 2-FIG. 4 , which is applicable to the blockchain system in FIG. 1 .

Please refer to the schematic diagram of multi-party interaction described in FIG. 2 , the multi-party corresponds to the client, non-consensus node, and consensus node in FIG. 1 . The steps in the schematic diagram include at least:

Step 310: the client sends the transaction to be published to the non-consensus nodes of the blockchain.

Step 320: The non-consensus node receives the transaction sent by the client.

Step 322: The non-consensus node queries the account status of the target account related to the transaction from the locally stored blockchain ledger.

In this specification, the blockchain ledger records all accounts in the blockchain and the latest account status of the account.

In an embodiment, the account status may refer to the value of the Balance field of the user account.

Step 324: The non-consensus node obtains the locally stored cryptographic commitment.

Wherein, the cryptographic commitment is the latest cryptographic commitment synchronized by the consensus node of the block chain (detailed in the subsequent steps); the cryptographic commitment is all blocks recorded in the block chain ledger of the block chain Commitment to the authenticity of the chain account and the account state corresponding to the blockchain account.

Step 326: The non-consensus node calculates the queried account status and cryptographic commitment based on a cryptographic algorithm, and obtains a cryptographic proof.

Calculate the account status and cryptographic commitment of the queried target account based on the cryptographic algorithm, and obtain the target account related to the transaction and the account status of the target account included in the blockchain area Cryptographic proofs in blockchain ledgers.

Step 328: The non-consensus node returns the account status and cryptographic proof of the target account related to the transaction to the client.

Step 330: The client receives the account status and cryptographic proof of the target account returned by the non-consensus node.

Step 332: The client sends the transaction, the account status of the target account related to the transaction, and cryptographic proof to the blockchain in the form of a blockchain transaction.

That is to say, in this manual, before sending the transaction to the blockchain, the client needs to obtain the account status and cryptographic proof of the target account related to the transaction from the non-consensus node of the blockchain.

Step 340: The consensus node receives the transaction sent by the client; wherein, the transaction includes that the client obtains from a non-consensus node (ie, a node device that does not participate in the consensus) in the blockchain, and is used to prove The target account associated with the transaction and the account status of the target account are included in the cryptographic proof of the blockchain ledger of the blockchain.

Step 342: The consensus node checks the validity of the transaction.

Wherein, the legality check may include checking the cryptographic proof based on a cryptographic algorithm; it may also include checking the validity of the data format of the transaction, and it may also check the account status related to the transaction. Perform legality checks, etc.

In an exemplary embodiment, the consensus node maintains a cryptographic commitment corresponding to the blockchain ledger; wherein, the cryptographic commitment is recorded in the blockchain ledger A commitment to the authenticity of all blockchain accounts and the account states corresponding to said all blockchain accounts.

Correspondingly, the verification of the cryptographic proof based on the cryptographic algorithm includes:

Calculate the cryptographic proof based on a cryptographic algorithm to obtain a cryptographic commitment;

Determine whether the calculated cryptographic commitment is the same as the cryptographic commitment corresponding to the blockchain account book locally maintained by the node device participating in the consensus;

If they are the same, it is determined that the legality verification for the transaction is passed.

In this example, the cryptographic proof sent by the client is calculated based on the cryptographic algorithm, and it is determined whether the calculated cryptographic commitment is consistent with the cryptographic commitment maintained by the consensus node.

Here, consensus nodes and non-consensus nodes use the same cryptographic algorithm.

Since the cryptographic proof is calculated based on the cryptographic algorithm for the cryptographic commitment and the account status of the target account; that is, the cryptographic algorithm (cryptographic commitment + account status) → cryptographic proof.

When the consensus node obtains the account status and cryptographic proof of the target account sent by the client, using the same cryptographic algorithm, it can reverse the cryptographic commitment when the non-consensus node generates the cryptographic proof; that is, the password Cryptographic commitment algorithm (cryptographic proof + account status) → cryptographic commitment.

By comparing the cryptographic commitment stored locally with the calculation result (the deduced cryptographic commitment), it can be determined whether the account status of the target account sent by the client is true.

Since the cryptographic commitment stored locally by the consensus node is exactly the same as the cryptographic commitment stored locally by the non-consensus node, if the cryptographic commitment is consistent with the calculation result, it means that the cryptographic proof and account status are credible. If they are inconsistent, it means that the cryptographic proof sent by the client and the account status of the target account have been tampered with.

By applying this example, it can be determined whether the cryptographic proof sent by the client and the account status of the target account have been tampered with. Only when they have not been tampered with can it be determined that the transaction has passed the legality verification.

In an exemplary embodiment, the transaction further includes the latest account status of the target account obtained by the client from a node device that does not participate in the consensus in the blockchain;

The legality check also includes:

Check whether the latest account state corresponding to the target account is the same as the latest account state corresponding to the target account maintained by a non-consensus node (ie, a node device that does not participate in the consensus) in the blockchain;

In this example, the consensus node can interact with the non-consensus node to determine whether the latest account status corresponding to the target account sent by the client is the same as the latest account status corresponding to the target account maintained by the non-consensus node.

Since the latest account status sent by the client is obtained from a non-consensus node, under normal circumstances, the latest account status of the target account should be consistent; if not, it means that the latest account status sent by the client has been tampered of.

By applying this example, it can be determined whether the latest account status of the target account sent by the client has been tampered with. Only when it has not been tampered with can it be determined that the transaction has passed the legality check.

In an exemplary embodiment, the legality check also includes:

Synchronize the latest account status of the target account in the transaction to the non-consensus node in the block chain, so that the non-consensus node can target the target account and the latest account status of the target account based on a cryptographic algorithm. Account status is calculated to obtain cryptographic proof;

Obtain the cryptographic proof calculated by the non-consensus node, and determine whether the cryptographic proof is the same as the cryptographic proof in the transaction;

In this example, the latest account status of the target account sent by the client is calculated based on a cryptographic algorithm, and it is determined whether the calculated cryptographic proof is consistent with the cryptographic proof sent by the client.

Since the cryptographic proof is calculated based on the cryptographic algorithm for the cryptographic commitment and the latest account status of the target account; that is, the cryptographic algorithm (cryptographic commitment + account status) → cryptographic proof.

In the case where the consensus node obtains the latest account status and cryptographic proof of the target account sent by the client, the non-consensus node makes the cryptographic commitment locally maintained by the non-consensus node and the target account sent by the client based on the cryptographic algorithm. The calculation result of the latest account status is the cryptographic proof.

By comparing the cryptographic proof sent by the client with the calculation result (the non-consensus node calculates the cryptographic commitment), it can be determined whether the latest account status and cryptographic proof sent by the client are true.

If the cryptographic proof sent by the client is consistent with the calculation result, it means that the cryptographic proof and the latest account status are credible. If not, it means that the cryptographic proof and the latest account status sent by the client have been tampered with.

By applying this example, it can be determined whether the cryptographic proof and the latest account status sent by the client have been tampered with, and only when it has not been tampered with can it be determined that the transaction has passed the legality check.

Step 344: The consensus node executes the transaction if the validity check is passed.

Since the legitimacy check has passed, the transaction can be executed, and the transaction of this round of bookkeeping is packaged into the latest block; and the latest block is appended to the end of the original blockchain, thus completing the blockchain Bookkeeping process.

In an exemplary embodiment, the execution of the transaction may include:

calculating an updated account status of the target account based on the latest account status of the target account; and,

calculating an updated cryptographic commitment based on the updated account state and a locally maintained cryptographic commitment corresponding to the blockchain ledger;

Correspondingly, the execution result of the transaction includes the updated account status and the updated cryptographic commitment.

In this example, due to the consensus node executing the transaction sent by the client, the account status of the target account involved in the transaction has changed, and due to the change of the account status, the blockchain ledger has also changed; All blockchain accounts recorded in the blockchain ledger and the cryptographic commitments of the authenticity commitments of the account states corresponding to all the blockchain accounts also need to be updated.

Specifically, based on a cryptographic algorithm, the updated account status and the locally maintained cryptographic commitment are calculated to obtain an updated cryptographic commitment; that is, the cryptographic algorithm (cryptographic commitment (old) + latest account status) = The latest cryptography promises.

Step 346: After the consensus node reaches a consensus on the execution result of the transaction with other consensus nodes in the blockchain, send the transaction and the execution result of the transaction to the non-consensus node in the blockchain node to store in the blockchain ledger.

Since consensus nodes do not store account status, but are stored by non-consensus nodes, consensus nodes need to synchronize the latest account status to non-consensus nodes. That is, the consensus node synchronizes the updated cryptographic commitment and the updated account status to the non-consensus node.

Step 352: The non-consensus node receives the execution result of the transaction synchronized by the consensus node. Wherein, the execution result includes the updated account status and the updated cryptographic commitment.

Step 354: After the non-consensus node reaches a consensus on the execution result of the transaction with other consensus nodes, update the maintained cryptographic commitment based on the updated cryptographic commitment.

The non-consensus node modifies the locally stored cryptographic commitment to the updated vector commitment; modifies the account state of the target account in the local blockchain ledger to the updated account state.

In this way, non-consensus nodes can update the latest account status of the target account in the locally maintained blockchain ledger, as well as update the latest cryptographic commitments.

Through the above steps, the transaction can be executed after it is determined that the transaction is legal, and the cryptographic commitment and account status stored by the non-consensus node are updated after the transaction is executed to prepare for the next round of verification.

In this example, the legitimacy of the transaction is no longer verified based on the account status data, but the legitimacy of the transaction is verified through the cryptographic commitment and cryptographic proof corresponding to the blockchain ledger. Since the cryptographic proof is not based on the account status of the account, the node devices participating in the consensus in the blockchain do not need to store the account status of the full account in the blockchain ledger, thus solving the verification of the node devices participating in the consensus due to too much account status data The problem of low efficiency.

The following describes an embodiment of the method in which the node device participating in the consensus is the main body of this specification in conjunction with FIG. 3. The blockchain ledger of the blockchain is stored at the node device that does not participate in the consensus in the blockchain. The method includes:

Step 410: Receive the transaction sent by the client; wherein, the transaction includes that the client obtains from a node device that does not participate in the consensus in the block chain, and is used to prove the target account and the transaction related to the transaction. The state data of the target account is contained in the cryptographic proof in the blockchain ledger of the blockchain.

Step 420: Perform a legality check on the transaction; wherein, the legality check includes checking the cryptographic proof based on a cryptographic algorithm.

Step 430: If the legality check passes, execute the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, post the transaction and the transaction The execution results are sent to the node devices in the blockchain that do not participate in the consensus, and stored in the blockchain ledger.

This embodiment may correspond to the foregoing FIG. 2 , and details of specific steps may also refer to the foregoing embodiment in FIG. 2 .

In an exemplary embodiment, the node device participating in the consensus maintains a cryptographic commitment corresponding to the blockchain ledger; wherein, the cryptographic commitment is a blockchain ledger for the blockchain Commitment to the authenticity of all blockchain accounts recorded in and the account status corresponding to all blockchain accounts;

The verification of the cryptographic proof based on a cryptographic algorithm includes:

Determine whether the calculated cryptographic commitment is the same as the cryptographic commitment corresponding to the blockchain ledger locally maintained by the node device participating in the consensus;

The legality check also includes:

Verifying whether the latest account status corresponding to the target account is the same as the latest account status corresponding to the target account maintained by other node devices in the blockchain that do not participate in the consensus;

In an exemplary embodiment, the legality check also includes:

Synchronize the latest account status data of the target account in the transaction to other node devices in the blockchain that do not participate in the consensus, so that the other node devices can target the target account and the target account based on a cryptographic algorithm. Calculate the latest account status data of the target account to obtain cryptographic proof;

Obtain the cryptographic proof calculated by the other node device, and determine whether the cryptographic proof is the same as the cryptographic proof in the transaction;

In an exemplary embodiment, the aforementioned execution of the transaction includes:

In an exemplary embodiment, the method also includes:

After reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the blockchain, the maintained cryptographic commitment is updated based on the updated cryptographic commitment.

In this embodiment, non-consensus nodes can update the maintained cryptographic commitment based on the updated cryptographic commitment after other nodes participating in the consensus reach a consensus on the execution result of the transaction.

In an exemplary embodiment, the cryptographic algorithm includes a Vector commitment algorithm;

The cryptographic commitment includes the commitment value obtained by cryptographic calculation based on the Vector commitment algorithm for all blockchain accounts recorded in the full blockchain ledger and the account states corresponding to all blockchain accounts; correspondingly, The cryptographic proof includes a proof value obtained by cryptographically calculating the target account and the state data corresponding to the target account recorded in the full blockchain ledger based on the Vector commitment algorithm.

In an exemplary embodiment, the block chain includes a consortium chain.

The embodiment of this specification provides a blockchain-based transaction verification scheme to realize a stateless alliance chain architecture design. The legitimacy of the transaction is verified through the cryptographic commitment and cryptographic proof corresponding to the blockchain ledger. Since the cryptographic proof is not based on the account status of the account, the node devices participating in the consensus in the blockchain do not need to store the account status of the full account in the blockchain ledger, thus solving the verification of the node devices participating in the consensus due to too much account status data The problem of low efficiency.

Corresponding to the above method embodiments, this specification also provides an embodiment of a blockchain-based transaction verification device.

The embodiment of the blockchain-based transaction verification device in this specification can be applied to electronic equipment. The device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the electronic device where it is located.

From the perspective of hardware, as shown in Figure 4, it is a hardware structure diagram of the electronic device where the blockchain-based transaction verification device in this specification is located, except for the processor, memory, network interface, and non- In addition to the volatile memory, the electronic device where the device in the embodiment is located usually may also include other hardware according to the actual function of the electronic device, which will not be repeated here.

Fig. 5 is a block diagram of a blockchain-based transaction verification device shown in an exemplary embodiment of this specification. The block chain-based transaction verification device can be applied to the electronic device shown in Figure 4 above, and corresponds to the method embodiment shown in Figure 3 above, and the device includes:

The device is applied to node devices participating in the consensus in the block chain, and the block chain ledger of the block chain is stored at the node device not participating in the consensus in the block chain; the device includes:

The receiving unit 510 is configured to receive a transaction sent by the client; wherein, the transaction includes that the client obtains from a node device in the block chain that does not participate in the consensus, and is used to prove the target account and transaction related to the transaction. The state data of the target account is included in the cryptographic proof in the blockchain ledger of the blockchain;

The verification unit 520 is configured to perform a legality verification on the transaction; wherein, the legality verification includes verifying the cryptographic proof based on a cryptographic algorithm;

The processing unit 530, if the validity check is passed, executes the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, transfers the transaction and the The execution result of the transaction is sent to the node device in the blockchain that does not participate in the consensus, and stored in the blockchain ledger.

In an exemplary embodiment, the consensus node maintains a cryptographic commitment corresponding to the blockchain ledger; wherein, the cryptographic commitment is recorded in the blockchain ledger A commitment to the authenticity of all blockchain accounts and the account status corresponding to said all blockchain accounts;

Determine whether the calculated cryptographic commitment is the same as the cryptographic commitment corresponding to the blockchain ledger locally maintained by the consensus node;

The legality check also includes:

In an exemplary embodiment, the legality check also includes:

Synchronize the latest account status of the target account in the transaction to other node devices in the blockchain that do not participate in the consensus, so that the other node devices can target the target account and the target account based on cryptographic algorithms. The latest account status of the target account is calculated to obtain cryptographic proof;

In an exemplary embodiment, the execution of the transaction in the processing unit 530 includes:

In an exemplary embodiment, the device also includes:

The updating unit is configured to update the maintained cryptographic commitment based on the updated cryptographic commitment after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain.

In an exemplary embodiment, the block chain includes a consortium chain.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible, or may be advantageous, in certain implementations.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of the present specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A block chain-based transaction verification method, the method is applied to a node device participating in consensus in the block chain, and the block chain ledger of the block chain is stored in the node device not participating in the consensus in the block chain at; the method includes:

Receiving the transaction sent by the client; wherein, the transaction includes that the client obtains from a node device that does not participate in the consensus in the block chain, and is used to prove the target account and the target account related to the transaction Cryptographic proof that the state data of the said blockchain is contained in the blockchain ledger of said blockchain;

Carry out legality verification for the transaction; wherein, the legality verification includes verifying the cryptographic proof based on a cryptographic algorithm;

If the legality check is passed, execute the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, the transaction and the execution result of the transaction will be It is sent to a node device in the blockchain that does not participate in the consensus, and stored in the blockchain ledger.
According to the method according to claim 1, the node device participating in the consensus maintains a cryptographic commitment corresponding to the blockchain ledger; wherein, the cryptographic commitment is a blockchain ledger for the blockchain Commitment to the authenticity of all blockchain accounts recorded in and the account status corresponding to all blockchain accounts;

The verification of the cryptographic proof based on a cryptographic algorithm includes:

Calculate the cryptographic proof based on a cryptographic algorithm to obtain a cryptographic commitment;

Determine whether the calculated cryptographic commitment is the same as the cryptographic commitment corresponding to the blockchain account book locally maintained by the node device participating in the consensus;

If they are the same, it is determined that the legality verification for the transaction is passed.
According to the method according to claim 2, the transaction further includes the latest account status of the target account obtained by the client from a node device that does not participate in the consensus in the blockchain;

The legality check also includes:

Verifying whether the latest account status corresponding to the target account is the same as the latest account status corresponding to the target account maintained by other node devices in the blockchain that do not participate in the consensus;

If they are the same, it is determined that the legality verification for the transaction is passed.
The method according to claim 3, said legality check further comprising:

Synchronize the latest account status of the target account in the transaction to other node devices in the blockchain that do not participate in the consensus, so that the other node devices can target the target account and the target account based on cryptographic algorithms. The latest account status of the target account is calculated to obtain cryptographic proof;

Obtain the cryptographic proof calculated by the other node device, and determine whether the cryptographic proof is the same as the cryptographic proof in the transaction;

If they are the same, it is determined that the legality verification for the transaction is passed.
The method of claim 1, performing said transaction comprising:

calculating an updated account status of the target account based on the latest account status of the target account; and,

calculating an updated cryptographic commitment based on the updated account state and a locally maintained cryptographic commitment corresponding to the blockchain ledger;

Correspondingly, the execution result of the transaction includes the updated account status and the updated cryptographic commitment.
The method according to claim 5, said method further comprising:

After reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the blockchain, the maintained cryptographic commitment is updated based on the updated cryptographic commitment.
The method according to claim 2, the cryptographic algorithm comprises a Vector commitment algorithm;

The cryptographic commitment includes the commitment value obtained by cryptographic calculation based on the Vector commitment algorithm for all blockchain accounts recorded in the full blockchain ledger and the account states corresponding to all blockchain accounts; correspondingly, The cryptographic proof includes a proof value obtained by cryptographically calculating the target account and the state data corresponding to the target account recorded in the full blockchain ledger based on the Vector commitment algorithm.
The method of claim 1, said blockchain comprising a consortium chain.
A block chain-based transaction verification device, the device is applied to a node device that participates in consensus in the block chain, and the block chain ledger of the block chain is stored in the node device that does not participate in the consensus in the block chain place; said device includes:

The receiving unit receives the transaction sent by the client; wherein, the transaction includes that the client obtains from a node device in the block chain that does not participate in the consensus, and is used to prove the target account and the transaction related to the transaction. Cryptographic proof that the state data of the target account is included in the blockchain ledger of the blockchain;

A verification unit is configured to verify the legality of the transaction; wherein the legality verification includes verifying the cryptographic proof based on a cryptographic algorithm;

The processing unit, if the validity check is passed, executes the transaction, and after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain, transfers the transaction and the transaction The execution results are sent to the node devices in the blockchain that do not participate in the consensus, and stored in the blockchain ledger.
According to the device according to claim 9, the node device participating in the consensus maintains a cryptographic commitment corresponding to the blockchain ledger; wherein, the cryptographic commitment is a blockchain ledger for the blockchain Commitment to the authenticity of all blockchain accounts recorded in and the account status corresponding to all blockchain accounts;

The verification of the cryptographic proof based on a cryptographic algorithm includes:

Calculate the cryptographic proof based on a cryptographic algorithm to obtain a cryptographic commitment;

Determine whether the calculated cryptographic commitment is the same as the cryptographic commitment corresponding to the blockchain account book locally maintained by the node device participating in the consensus;

If they are the same, it is determined that the legality verification for the transaction is passed.
According to the device according to claim 10, the transaction further includes the latest account status of the target account obtained by the client from a node device that does not participate in the consensus in the blockchain;

The legality check also includes:

Verifying whether the latest account status corresponding to the target account is the same as the latest account status corresponding to the target account maintained by other node devices in the blockchain that do not participate in the consensus;

If they are the same, it is determined that the legality verification for the transaction is passed.
The device according to claim 11, said legality check further comprising:

Synchronize the latest account status of the target account in the transaction to other node devices in the blockchain that do not participate in the consensus, so that the other node devices can target the target account and the target account based on cryptographic algorithms. The latest account status of the target account is calculated to obtain cryptographic proof;

Obtain the cryptographic proof calculated by the other node device, and determine whether the cryptographic proof is the same as the cryptographic proof in the transaction;

If they are the same, it is determined that the legality verification for the transaction is passed.
The apparatus according to claim 9, said execution of said transaction in said processing unit comprising:

calculating an updated account status of the target account based on the latest account status of the target account; and,

calculating an updated cryptographic commitment based on the updated account state and a locally maintained cryptographic commitment corresponding to the blockchain ledger;

Correspondingly, the execution result of the transaction includes the updated account status and the updated cryptographic commitment.
The apparatus of claim 13, further comprising:

The updating unit is configured to update the maintained cryptographic commitment based on the updated cryptographic commitment after reaching a consensus on the execution result of the transaction with other nodes participating in the consensus in the block chain.
The device according to claim 10, said cryptographic algorithm comprising a Vector commitment algorithm;

The cryptographic commitment includes the commitment value obtained by cryptographic calculation based on the Vector commitment algorithm for all blockchain accounts recorded in the full blockchain ledger and the account states corresponding to all blockchain accounts; correspondingly, The cryptographic proof includes a proof value obtained by cryptographically calculating the target account and the state data corresponding to the target account recorded in the full blockchain ledger based on the Vector commitment algorithm.
The apparatus of claim 9, the blockchain comprising a consortium chain.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-8 by running the executable instruction.