WO2022242457A1 - 一种交易验证方法、装置、设备及存储介质 - Google Patents

一种交易验证方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2022242457A1
WO2022242457A1 PCT/CN2022/090859 CN2022090859W WO2022242457A1 WO 2022242457 A1 WO2022242457 A1 WO 2022242457A1 CN 2022090859 W CN2022090859 W CN 2022090859W WO 2022242457 A1 WO2022242457 A1 WO 2022242457A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
transaction
node
state
verified
Prior art date
Application number
PCT/CN2022/090859
Other languages
English (en)
French (fr)
Inventor
冯浩铭
屠海涛
何立宝
陈秋平
陈家宝
任鹏
周水平
赵勇
王鹤
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to EP22803781.8A priority Critical patent/EP4216131A4/en
Publication of WO2022242457A1 publication Critical patent/WO2022242457A1/zh
Priority to US18/071,934 priority patent/US20230090296A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This application relates to the field of block chain technology, especially transaction verification.
  • a block producing node in a blockchain network when a block producing node in a blockchain network generates a new block, it needs to collect unconfirmed transactions propagated in the blockchain network, and then execute the transaction services corresponding to the collected transactions one by one to obtain Transaction execution result.
  • the block producing node in the process of executing the transaction business, the block producing node needs to obtain in advance from the block chain of the block chain network the block from the genesis block to the current latest block (that is, the block with the largest generation time stamp). All status data of the transaction is used to verify the legality of the transaction. For example, when the block producing node executes the asset transfer business corresponding to a transaction, it needs to judge whether the asset transfer party has enough credit.
  • Embodiments of the present application provide a transaction verification method, device, device, and storage medium, which can speed up the start-up time of block producing nodes.
  • Embodiments of the present application provide a transaction verification method on the one hand, the method is executed by a block producing node in the blockchain network, and the block producing node is a lightweight node in the blockchain network, including:
  • the transaction to be verified sent by the user node in the blockchain network and the transaction verification information corresponding to the transaction to be verified;
  • the transaction verification information is determined by the full number of nodes in the blockchain network after executing the transaction business corresponding to the transaction to be verified ;
  • the transaction verification information includes the state read set, the state write set, the initial transaction execution result, and the block ID;
  • the block ID is used to point to the target block with the largest generation timestamp on the full block chain of the full node; and the target
  • the first block header of the block contains the block identifier;
  • the block header chain of the lightweight node find the block header that matches the block identifier in the first block header, and use the found block header as the second block header, based on the first state snapshot in the second block header , verify the state read set and state write set, and obtain the first verification result of the transaction to be verified;
  • the transaction service is executed based on the state read set, and the target transaction execution result corresponding to the transaction service and the status data to be written are obtained;
  • the validity of the transaction to be verified is verified.
  • the embodiment of the present application provides a transaction verification method, which is executed by all nodes in the blockchain network, including:
  • the block with the largest generation time stamp is used as the target block, and the target block's Block header as the first block header;
  • the block producing node in the network based on the first state snapshot in the second block header in the block header chain, checks the validity of the transaction to be verified; the second block header is the block ID matching block ID in the block header chain Block header; the block producing node is a lightweight node in the blockchain network.
  • an embodiment of the present application provides a transaction verification device, including:
  • the transaction acquisition module is used to obtain the transaction to be verified sent by the user node in the blockchain network and the transaction verification information corresponding to the transaction to be verified; Determined after transaction business; transaction verification information includes state read set, state write set, initial transaction execution result and block ID; block ID is used to point to the node with the largest generation time stamp on the full block chain The target block; and the first block header of the target block contains a block identifier;
  • the set verification module is used to search for the block header matching the block identifier in the first block header in the block header chain of the lightweight node, and use the found block header as the second block header, based on the second block header
  • the first state snapshot in the block header is used to verify the state read set and state write set to obtain the first verification result of the transaction to be verified;
  • the target execution result determination module is used to execute the transaction business based on the state reading set when the first verification result indicates that the verification is successful, and obtain the target transaction execution result corresponding to the transaction business and the status data to be written;
  • the legality verification module is used to verify the legality of the transaction to be verified based on the initial transaction execution result, the target transaction execution result, the state writing set and the state data to be written.
  • an embodiment of the present application provides a transaction verification device, including:
  • the target block determination module is used to use the block with the largest generation time stamp as the target block on the full block chain of the full node when obtaining the transaction to be verified associated with the user node in the block chain network block, and use the block header of the target block as the first block header;
  • the initial execution result determination module is used to obtain the Merkel Patricia tree in the target block, based on the Merkel Patricia tree in the target block, execute the transaction business corresponding to the transaction to be verified, and obtain the transaction business Corresponding initial transaction execution results, status read collection and status write collection;
  • the verification information determination module is used to obtain the block identification in the first block header, and use the initial transaction execution result, state reading set, state writing set and block identification as the transaction verification information corresponding to the transaction to be verified; transaction verification The information is used to indicate the block producing node in the blockchain network, based on the first state snapshot in the second block header in the block header chain, to verify the validity of the transaction to be verified; the second block header is the same as in the block header chain The block identifier matches the block header; the block producing node is a lightweight node in the blockchain network.
  • An embodiment of the present application provides a computer device, including: a processor and a memory;
  • the processor is connected to the memory, wherein the memory is used to store a computer program, and when the computer program is executed by the processor, the computer device is made to execute the method provided by the embodiment of the present application.
  • Embodiments of the present application provide, on the one hand, a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and the computer program is adapted to be loaded and executed by a processor, so that a computer device having the processor executes the present application.
  • An embodiment of the present application provides a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the method provided by the embodiment of the present application.
  • the block producing node in the blockchain network receives the transaction to be verified sent by the user node in the blockchain network
  • receives the transaction to be verified sent by the user node in the blockchain network
  • the transaction verification information determined by the full number of nodes in the blockchain network after executing the transaction business corresponding to the transaction to be verified will be received together.
  • the transaction verification information here may include the initial transaction execution result corresponding to the transaction business, a state read set, a state write set, and a block identifier.
  • the block identification can be used to point to the target block with the largest generation time stamp on the full block chain of the full node, and the first block header of the target block contains the block identification.
  • the block producing node does not need to spend a lot of time synchronizing all the state data from the genesis block of the full blockchain to the target block, but directly searches the block header chain of the block producing node that is related to the block. Then, based on the first state snapshot of the second block header and the transaction verification information, the validity verification of the transaction to be verified is performed, which can improve the efficiency of the legality verification and reduce the output.
  • the operating burden of the block node greatly speeds up the startup time of the block node.
  • Fig. 1 is a schematic diagram of a block chain network structure provided by the embodiment of the present application.
  • FIG. 2 is a schematic diagram of a scenario for data interaction provided by an embodiment of the present application
  • Fig. 3 is a schematic flow diagram of a transaction verification method provided by an embodiment of the present application.
  • Fig. 4 is a schematic diagram of a scenario of verifying transaction signature information provided by the embodiment of the present application.
  • Fig. 5 is a schematic structural diagram of a Merkle Patricia tree provided by the embodiment of the present application.
  • Fig. 6 is a schematic diagram of a first existence proof of first state data provided by an embodiment of the present application.
  • Fig. 7 is a schematic diagram of a modifiable proof of the second state data provided by the embodiment of the present application.
  • Fig. 8 is a schematic flow diagram of a transaction verification method provided by an embodiment of the present application.
  • Fig. 9 is a schematic flow diagram of a transaction verification method provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a scenario for generating a block to be processed provided by an embodiment of the present application.
  • Fig. 11 is a schematic structural diagram of a transaction verification device provided by an embodiment of the present application.
  • Fig. 12 is a schematic structural diagram of a transaction verification device provided by an embodiment of the present application.
  • Fig. 13 is a schematic diagram of a computer device provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a data processing system provided by an embodiment of the present application.
  • FIG. 1 is a schematic diagram of a blockchain network structure provided by an embodiment of the present application.
  • the blockchain network structure shown in FIG. 1 can be applied to a blockchain system, and the blockchain system can be a distributed system formed by connecting multiple blockchain nodes through network communication.
  • all blockchain nodes can establish point-to-point or peer-to-peer (P2P for short) connections with each other to form a P2P network (that is, the blockchain network shown in Figure 1).
  • P2P peer-to-peer
  • the blockchain node here can be any form of computer equipment connected to the blockchain network, for example, the computer equipment can be a user terminal connected to the blockchain network, or a user terminal connected to the blockchain network
  • the server in the blockchain network the specific form of the blockchain node is not limited here.
  • the user terminal here may include intelligent terminals with data processing functions such as smart phones, tablet computers, notebook computers, and desktop computers.
  • the user terminal can be installed with a target application (i.e., an application client), and when the application client is running in the user terminal, it can communicate with other blockchain nodes in the blockchain network shown in Figure 1 above. Data interaction.
  • the application client may include social client, multimedia client (for example, video client), entertainment client (for example, game client), education client, live broadcast client and other application clients.
  • the application client can be an independent client, or an embedded sub-client integrated in a certain client (for example, a social client, an educational client, and a multimedia client, etc.), which is not limited here .
  • the server here can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications , middleware services, domain name services, security services, CDN, and cloud servers for basic cloud computing services such as big data and artificial intelligence platforms.
  • the blockchain network may include three types of blockchain nodes, specifically including full nodes, block producing nodes, and user nodes.
  • the full node refers to the blockchain node used to store complete block data.
  • the blockchain of the full node can be called the full blockchain.
  • Each block in the full blockchain Each block can include a block header and a block body.
  • the block header may include a state snapshot for judging the integrity of the state data, the block identifier of the current block (for example, block height or block hash value), the parent block hash value, and the generated timestamp etc.
  • the block body may include a Merkle Patricia Tree (MPT for short), and the leaf nodes (ie data nodes) in the Merkle Patricia tree may store specific state data. This means that the full blockchain of the full node needs to retain the complete state data of all accounts.
  • MPT Merkle Patricia Tree
  • the block producing node in the embodiment of the present application refers to a block chain node used to generate a new block header.
  • the block producing node can be a lightweight node (Simplified Payment Verification, referred to as SPV node).
  • the lightweight node here refers to the blockchain node used to store the block header information in the block data without storing the complete block data.
  • the embodiment of the present application may refer to the block chain of the block producing node as a block header chain (ie, a lightweight block chain), and the block header chain may be a chain structure formed by connecting multiple blocks head to tail. This means that the block header chain of the block producing node can retain a state snapshot for judging the integrity of the state data, without the need to retain the complete state data of all accounts.
  • the user node in the embodiment of this application refers to a blockchain node deployed on the user side and controlled by the user. It can be understood that the user node can be separately deployed on a certain computer device, and is used to assemble transactions to be verified (for example, transaction 1) for the user.
  • the user node can interact with the full amount of nodes in the blockchain network (the full amount of nodes are deployed on different computer devices from the user nodes). For example, the user node can send the transaction 1 to the full-scale node, so that the full-scale node simulates the execution of the transaction business corresponding to the transaction 1, and receives the transaction verification information obtained by the full-scale node after executing the transaction business corresponding to the transaction 1.
  • the user node can also interact with block producers in the blockchain network.
  • the user node can send the transaction verification information sent by the full node and the transaction to be verified (that is, transaction 1) assembled by the user node itself to the block generating node, so that the block generating node based on the received transaction verification information. Transaction 1 is verified for legality.
  • the user node can also be co-deployed on the same computer device as all the nodes in the blockchain network. This means that the user node will have the node function of the full node, that is, store the complete block data.
  • the user node After the user node assembles the transaction to be verified (for example, transaction 2) for the user, it can directly execute the transaction service corresponding to the transaction 2, so as to obtain the transaction verification information corresponding to the transaction 2. At this time, the user node can directly send the transaction 2 and the transaction verification information corresponding to the transaction 2 to the block generating node, so that the block generating node can verify the validity of the transaction 2 based on the received transaction verification information.
  • the block producing node in the embodiment of the present application when the block producing node in the embodiment of the present application receives the transaction to be verified sent by the user node in the blockchain network, it can also receive the transaction verification information corresponding to the transaction to be verified. Therefore, when the block node verifies the validity of the transaction to be verified, it is not necessary to obtain all the state data stored in the full blockchain, but to verify the validity of the transaction to be verified according to the received verification information of the transaction to be verified. test.
  • the transaction verification information here may include the state read set, the state write set, the initial transaction execution result, and the block identifier.
  • the block identifier is used to point to the target block with the largest generation time stamp on the full blockchain of the full node, and the first block header of the target block contains the block identifier. Therefore, the following checks can be included in the process of verifying the transaction to be verified: first, when the block producing node can find the block header (that is, the second block header) that matches the block identifier in the block header chain, it can obtain The first state snapshot in the second block header can then verify the two sets (ie state read set and state write set) in the transaction verification information based on the first state snapshot to obtain the first verification result.
  • the block producing node can execute the transaction business corresponding to the transaction to be verified based on the state read set, and obtain the target transaction execution result and the state data to be written. Then, the block producing node can verify the validity of the transaction to be verified based on the initial transaction execution result, the target transaction execution result, the state writing set, and the state data to be written. This means that the block producing node does not need to spend time reading all the status data on the full block chain, but directly checks the validity of the transaction to be verified according to the received transaction verification information, so that the block producing node is relieved.
  • the operating burden which in turn greatly speeds up the start-up time of the block-producing nodes.
  • FIG. 2 is a schematic diagram of a data interaction scenario provided by an embodiment of the present application.
  • the user node 20A may be a user node in the blockchain network shown in FIG. 1 above, and the user node 20A may be used to assemble transactions to be verified for the user.
  • the full node 20B in the embodiment of the present application may be a full node in the blockchain network shown in FIG. 1 above, and the full node 20B may store complete state data of all accounts.
  • the block producing node 20C in the embodiment of the present application may be a block producing node in the blockchain network shown in FIG. A lightweight node for legality verification.
  • the transactions to be verified in this embodiment of the application may include but not limited to asset transfer transactions (for example, transactions in business scenarios such as mortgage, loan, virtual asset circulation, etc.) and contract signing transactions.
  • the virtual assets here may refer to game coins, game diamonds, game equipment and electronic bills, etc.
  • the user for example, user 1 corresponding to the user node 20A has 10 game coins in the account balance, when the user 1 needs to transfer a certain virtual asset (for example, 3 game coins)
  • user 1 can perform a trigger operation on the user node 20A, so that user node 20A can respond to the trigger operation and assemble a transaction for the user 1 (for example, as shown in FIG. 2 transaction shown 2x).
  • the trigger operation here may include contact operations such as click and long press, and may also include non-contact operations such as voice and gesture, which will not be limited here.
  • the user node 20A can take the transaction 2x as a transaction to be verified, and then can send the transaction 2x to the full node 20B shown in FIG. 2, so that the full node 20B can execute the transaction business corresponding to the transaction 2x,
  • the transaction verification information corresponding to the transaction 2x (for example, the transaction verification information 2y shown in FIG. 2 ) is obtained.
  • the full blockchain of the full node 20B may be the blockchain 2a shown in FIG. 2, and the blockchain 2a may include multiple blocks with complete block data. Taking a block as an example, it may specifically include block 1g, block 2g, ..., block 99g, and block 100g, and this block 1g may be called the genesis block of the blockchain 2a.
  • each block in the blockchain 2a may include a block header and a block body, for example, a block 1g may include a block header 1 and a block body.
  • the full node 20B when the full node 20B receives the transaction 2x, it can use the block with the largest generation timestamp (for example, the block 100g shown in FIG. 2 ) as the target on the block chain 2a block, and the block header 100 in the block 100g can be used as the first block header. Further, the full node 20B can obtain the Merkel Patricia tree in the block 100g (for example, the Merkel Patricia tree 2m shown in FIG. 2 ), based on the Merkel Patricia tree Tree 2m simulates and executes the transaction business corresponding to the transaction 2x to obtain the transaction execution result corresponding to the transaction business (that is, the initial transaction execution result), the state read set and the state write set.
  • the Merkel Patricia tree in the block 100g for example, the Merkel Patricia tree 2m shown in FIG. 2
  • the Merkel Patricia tree Tree 2m simulates and executes the transaction business corresponding to the transaction 2x to obtain the transaction execution result corresponding to the transaction business (that is, the initial transaction execution result), the state read set and the state write set.
  • the full node 20B can obtain the block identifier in the first block header, and then can use the initial transaction execution result, state read set, state write set and block identifier as the transaction verification information corresponding to the transaction 2x 2y.
  • the block identifier here may refer to the block height of the target block (eg, block 100g ), or may refer to the block hash value of the target block, which is not limited here.
  • the full node 20B can return the transaction verification information 2y to the user node 20A. Further, the user node 20A can send the transaction 2x generated by itself and the transaction verification information 2y returned by the full node 20B to the block generating node 20C shown in FIG. 2y checks the legality of transaction 2x to determine the legality of transaction 2x.
  • the lightweight block chain (that is, the block head chain) of the block producing node 20C can be the block head chain 2b shown in FIG.
  • the embodiment may take 100 block headers as an example, which may specifically include block header 1, block header 2, . . . , block header 99, and block header 100. Each block header may include a state snapshot for judging the integrity of all state data of the current block.
  • the block producing node 20C when it receives the transaction 2x and the transaction verification information 2y sent by the user node 20A, it can search the block header chain 2b shown in FIG.
  • the block identifier matches the block header (for example, the block header 100 in the block header chain 2b), and the found block header is used as the second block header, and then can be based on the state snapshot in the second block header (that is, the first A state snapshot), to verify the state read set and state write set in the transaction verification information 2y, to obtain the first verification result of the transaction 2x, to determine whether the transaction business corresponding to the transaction 2x can be obtained by the block node 20C execution.
  • the block generating node 20C can determine that the transaction service corresponding to the transaction 2x cannot be executed by the block generating node 20C, that is, the transaction 2x is not legal.
  • the block generating node 20C may determine that the transaction business corresponding to the transaction 2x can be executed, and at this time, the block generating node 20C may read the set based on the state, Execute the transaction business corresponding to the transaction 2x, and obtain the target transaction execution result corresponding to the transaction business and the status data to be written (for example, 7 game coins). Further, the block producing node 20C can continue to verify the validity of the transaction 2x according to the initial transaction execution result, the status write set, the target transaction execution result and the status data to be written.
  • the block producing node 20C can determine that the transaction 2x is legal.
  • the block producing node 20C can determine that the transaction 2x is not legal.
  • the block producing node 20C in the embodiment of this application verifies the transaction 2x, it does not need to synchronize the state data of all accounts from the blockchain 2a, but according to the received transaction verification information 2y (that is, the full node 20B in When the transaction 2x is received, the transaction verification information obtained after simulating the execution of the transaction business corresponding to the transaction 2x) is directly verified for the legality of the transaction 2x, so that the operating burden of the block generating node 20C is reduced, and the block generation is greatly accelerated Startup time of node 20C.
  • the received transaction verification information 2y that is, the full node 20B in
  • the transaction verification information obtained after simulating the execution of the transaction business corresponding to the transaction 2x is directly verified for the legality of the transaction 2x, so that the operating burden of the block generating node 20C is reduced, and the block generation is greatly accelerated Startup time of node 20C.
  • the block producing node in the blockchain network performs the legality verification of the transaction to be verified for specific implementation methods, which can refer to the following embodiments corresponding to Fig. 3-Fig. 10 .
  • FIG. 3 is a schematic flowchart of a transaction verification method provided by an embodiment of the present application.
  • the method can be executed by a block producing node in the blockchain network.
  • the block producing node can be a user terminal connected to the blockchain network, or a user terminal connected to the blockchain network.
  • the server in is not limited here.
  • this embodiment of the present application takes the method executed by the user terminal as an example for illustration, and the method may at least include the following S101-S104:
  • the block producing node in the blockchain network can obtain the transaction to be verified sent by the user node in the blockchain network and the transaction verification information corresponding to the transaction to be verified.
  • the transaction to be verified here may be a transaction generated by the user node in response to a user's trigger operation (for example, a click operation).
  • the transaction verification information here can be the verification information obtained after the full number of nodes in the blockchain network receive the transaction to be verified sent by the user node and execute the transaction business corresponding to the transaction to be verified.
  • the user node and the full amount of nodes here may be co-deployed on the same computer device, or may be deployed on different computer devices, which will not be limited here.
  • the embodiment of the present application can take the situation that the user node and the full node are deployed on different computer devices as an example to illustrate the validity verification of the transaction information to be verified by the block producing node.
  • the user corresponding to the user node in the blockchain network may perform a trigger operation (for example, a click operation) for a certain transaction service.
  • the transaction service may be a service of transferring the electronic bill of the first user to another user (eg, the second user).
  • the user node can respond to the trigger operation to generate a transaction to be verified for broadcasting to the blockchain network.
  • the user node can sign the transaction to be verified based on the user's private key (that is, the private key of the first user) , to get the transaction signature information of the transaction to be verified.
  • the user node can send the transaction to be verified and transaction signature information to all nodes in the blockchain network. It should be understood that when the full node obtains the transaction signature information corresponding to the transaction to be verified, it can obtain the user public key corresponding to the user private key (that is, the public key of the first user), and then can sign the transaction information based on the user public key Signature verification is carried out to obtain the result of the signature verification.
  • FIG. 4 is a schematic diagram of a scenario of verifying transaction signature information provided by an embodiment of the present application.
  • the user node 40A in the embodiment of the present application may be a blockchain node controlled by a user in the blockchain network.
  • the user node 40A may be the user node 20A shown in FIG. 2 above.
  • the full node 40B in the embodiment of the present application may be a blockchain node in the blockchain network capable of storing complete block data.
  • the full node 40B may be the full node 20B shown in FIG. 2 above.
  • the user node 40A shown in FIG. 4 responds to the trigger operation of the user (for example, user 1) corresponding to the user node 40A, it can generate a transaction to be verified for broadcasting to the block chain network (for example, FIG. 4 Transaction shown 4x).
  • the user node 40A can sign the transaction 4x based on the user private key of the user 1, and obtain the transaction signature information corresponding to the transaction 4x.
  • the user node 40A can obtain the hash calculation rule for the transaction to be verified, and the hash calculation rule can be a combination of the user node 40A and other block nodes in the block chain network (for example, full nodes) 40B) A digest algorithm agreed in advance.
  • the user node 40A can perform hash calculation on the transaction 4x based on the hash calculation rule to obtain summary information (for example, summary information h) of the transaction 4x.
  • summary information for example, summary information h
  • the summary information of the transaction 4x determined by the user node 40A may be referred to as first summary information.
  • the user node 40A may sign the first summary information based on the user private key of the user 1, so as to obtain the transaction signature information shown in FIG. 4 .
  • the user node 40A can send the transaction 4x and the transaction signature information to the full amount node 40B shown in FIG. Key), verify the transaction signature information, and get the verification result.
  • the full node 40B can obtain the user public key of user 1, and then can verify the transaction signature information based on the user public key, and obtain the first summary information of the transaction 4x.
  • the full node 40B can also obtain the same hash calculation rules as the user node 40A, and perform hash calculation on the transaction 4x, so as to obtain the summary information (for example, summary information H) of the transaction 4x.
  • the summary information of the transaction 4x determined by the full node 40B may be referred to as the second summary information.
  • the full node 40B can compare the first summary information with the second summary information to obtain a signature verification result to determine whether the transaction 4x has been tampered with. It can be understood that if the first summary information is different from the second summary information, the full node 40B may determine that the signature verification result indicates that the signature verification fails. Optionally, if the first summary information is the same as the second summary information, the full node 40B can determine that the signature verification result indicates that the signature verification is successful, which means that the transaction 4x has not been tampered with, and the transaction 4x is indeed issued by the user node 40A sent.
  • the full amount of nodes in the embodiment of the present application can obtain the block with the largest generation time stamp on the full block chain of the full amount of nodes (for example, the block shown in Figure 2 Block 100g) in the block chain 2a, and then the obtained block can be used as the target block, and the block header of the target block can be used as the first block header. Further, the full node can obtain the Merkle Patricia tree in the target block, and based on the acquired Merkle Patricia tree, execute the transaction business corresponding to the transaction to be verified, so as to determine the transaction to be verified The transaction verification information corresponding to the information.
  • a state snapshot for judging the integrity of the state data is reserved.
  • the state snapshot of a certain block header can represent the fixed length of all state data of the corresponding block. If the state data of the current block changes, the state snapshot will change accordingly, so that all state data can be judged integrity.
  • the state data here represents the state data of the current blockchain network.
  • the state data here can include a user's account balance, unconfirmed transactions that have been issued; the code of a contract, the value of its internal storage items; some consensus mechanism Operation related data, etc.
  • each block in the full blockchain may include block header information and block body information.
  • Block header information can include state snapshots
  • block body information can include Merkle Patricia trees.
  • the Merkle Patricia tree can have the following functions: store key-value key-value pair data of any length, provide a mechanism for quickly calculating the hash identifier of the maintained data set, provide a mechanism for fast state rollback, And provide a proof method called Merkle proof to expand lightweight nodes and realize simple payment verification.
  • the Merkel Patricia tree is a tree structure for organizing data, including three types of nodes: data nodes, extension nodes, and branch nodes.
  • data node here refers to the leaf node of the tree structure, which appears at the bottom of the MPT and is used to store specific state data
  • extended node here refers to the parent node with one child node, which can contain a string of any length (key), and a hash pointer pointing to the child node
  • the branch node here refers to the parent node with 1 to 16 child nodes, there is a hash value array with a capacity of 16, and the characters in the 16 positions in the array They correspond to 0-9, a-f in hexadecimal, and may be used as hash pointers to point to a child node.
  • index relationship from child nodes to parent nodes may be referred to as the first node index relationship, for example, the bottom-up index relationship indicated in the Merkel Patricia tree.
  • index relationship from a parent node to a child node may also be referred to as a second node index relationship, for example, a top-down index relationship indicated in a Merkel Patricia tree.
  • FIG. 5 is a schematic structural diagram of a Merkel Patricia tree provided by an embodiment of the present application.
  • the Merkel Patricia tree 5m in the embodiment of the present application may be a Merkel Patricia tree stored in a certain block of all blockchains in the blockchain network.
  • the Merkel Patricia tree 5m can be the Merkel Patricia tree in the target block obtained by all nodes (for example, in the block 100g of the block chain 2a shown in Figure 2 above Merkel Patricia tree 2m).
  • Table 1 is the status data associated with the current blockchain network provided by the embodiment of this application. As shown in Table 1:
  • each state data is stored in the form of (key, value) key-value pairs.
  • the key shown in Table 1 refers to the key character string of the state data, and the value refers to the specific value of the state data.
  • the number of state data in the embodiment of the present application may include multiple, here, three are taken as an example, and may specifically include state data 1, state data 2, and state data 3.
  • the key string of the status data 1 can be "ab567cd", and the specific value of the status data 1 can be 100; the key string of the status data 2 can be "abc1235", and the specific value of the status data 2 can be It can be fenghm; the key string of the status data 3 can be "abc12b5", and the specific value of the status data 3 can be 12.34.
  • the Merkel Patricia tree 5m may include a tree root node (for example, an extended node 10Z), intermediate nodes (for example, a branch node 10F, an extended node 20Z, an extended node 30Z, a branch node 20F, extension node 40Z and extension node 50Z) and leaf nodes (eg, data node 10S, data node 20S, and data node 30S).
  • a tree root node for example, an extended node 10Z
  • intermediate nodes for example, a branch node 10F, an extended node 20Z, an extended node 30Z, a branch node 20F, extension node 40Z and extension node 50Z
  • leaf nodes eg, data node 10S, data node 20S, and data node 30S.
  • the root hash value of the root node of the Merkel Patricia tree 5m can be used as a state snapshot of the block where the Merkel Patricia tree 5m is located.
  • the Merkel Patricia tree 5m is the Merkel Patricia tree 2m stored in the block 100g of the blockchain 2a shown in Figure 2 above
  • the root hash value can be used as The state snapshot of the block header 100 in the block 100g shown in FIG. 2 can be used to judge the integrity of all state data in the block 100g shown in FIG. 2 .
  • the state snapshot of the block header 100 that is, the second block header
  • the block header chain 2b shown in FIG. 2 can also be the root hash value of the Merkel Patricia tree 5m.
  • the hash pointer of each node in the Merkel Patricia tree 5m can be used to point to the child node hash value of the corresponding child node.
  • the extended node 10Z may include a character string of any length (for example, "ab") and a hash pointer for pointing to a child node.
  • the hash pointer can be used to point to a child node of the extended node 10Z (for example, the branch node 10F shown in FIG. 5 ).
  • the key string in each state data shown in Table 1 above can correspond to a real node path from the root node in the Merkle Patricia tree 5m to the corresponding data node.
  • the node path 1 associated with the data node 10S can be: the hash pointer of the extended node 10Z points to the branch node 10F, and the branch node 10F
  • the node path 2 associated with the data node 20S can be: the hash pointer of the extended node 10Z points to the branch node 10F, and the hash pointer in the branch node 10F
  • the hash pointer of the character "c" points to the extension node 30Z
  • the hash pointer of the extension node 30Z points to the branch node 20F
  • the hash pointer of the character "3" in the branch node 20F points to the extension node 40Z
  • the extension node 40Z The hash pointer points to the data node 20S.
  • the node path 3 associated with the data node 30S can be: the hash pointer of the extended node 10Z points to the branch node 10F, and the hash pointer in the branch node 10F
  • the hash pointer of the character "c" points to the extension node 30Z
  • the hash pointer of the extension node 30Z points to the branch node 20F
  • the hash pointer of the character "b" in the branch node 20F points to the extension node 50Z
  • the extension node 50Z The hash pointer points to the data node 20S.
  • the full amount of nodes in the embodiment of the present application can obtain the Merkel Patricia tree in the target block, and then execute the transaction corresponding to the transaction to be verified based on the obtained Merkel Patricia tree Business, get the initial transaction execution result, state read set and state write set corresponding to the transaction business.
  • the full amount of nodes can obtain the Merkel Patricia tree in the target block, and use the obtained Merkel Patricia tree as the tree to be processed, and then can obtain the Merkel Patricia tree from the tree to be processed
  • the status data associated with the transaction to be verified is read, and the read status data is used as the first status data.
  • the full node can execute the transaction business corresponding to the transaction to be verified based on the first state data, so as to obtain the initial transaction execution result corresponding to the transaction business, and in the process of executing the transaction business, record the simulated writing into the target block For the state data of the next block, the recorded state data is used as the second state data.
  • the initial transaction execution result here may be a transaction execution result such as successful transaction execution or transaction execution failure.
  • the transaction service corresponding to the transaction to be verified received by the full amount of nodes is: from the account of the user (for example, user 1) corresponding to the user node in the blockchain network, to another user (for example, user 2 ) to transfer 10 game coins
  • the first state data read by the full amount of nodes can be the state data 1 stored by the data node 10S in the Merkel Patricia tree 5m shown in FIG. ), that is, there are 100 game coins in the account balance of user 1.
  • the state data recorded by the full node that needs to be written into the next block of the target block can be 90, This means that after the transaction business is simulated by the full number of nodes, the account balance of user 1 still includes 90 game coins.
  • the full amount of nodes can collect the first proof of existence of the first state data based on the tree to be processed, and then can generate a state reading set based on the first proof of existence, and then can generate a state reading set based on the first proof of existence. Take the set.
  • the number of first state data associated with the transaction to be verified read may include one or more. Based on this, the full-scale node may collect all first status data based on Proof of security, generate a set of state reads.
  • the full amount of nodes can use the Merkel Patricia tree 5m shown in Figure 5 above as the tree to be processed, and then can be found in the Merkel Patricia tree 5m for storing the first A data node for state data (eg, data node 10S for state data 1 of 100).
  • the full number of nodes can obtain the node path (for example, node path 1) associated with the data node 10S based on the Merkel Patricia tree 5m.
  • the node path may include a data node 10S, an extended node 20Z, a branch node 10F, and an extended node 10Z.
  • the full amount of nodes can use the obtained node path as the first existence proof of the first state data, and here you can refer to FIG. 6 together.
  • FIG. 6 is a kind of first state data provided by the embodiment of the present application
  • a schematic diagram of the first existence proof of .
  • the proof of existence 6p shown in FIG. 6 is the first proof of existence of the first state data collected by all nodes in the blockchain network.
  • the full number of nodes in the embodiment of the present application can also collect the modifiable proof and the second existence proof of the second state data based on the tree to be processed, and then can generate a state based on the modifiable proof and the second existence proof Write collection.
  • the full node before inserting the second state data into the tree to be processed, the full node can obtain the key character string associated with the second state data, and then can obtain the second state data based on the key character string modifiable proof of .
  • the full amount of nodes before inserting the second state data into the tree to be processed, can obtain the key character string associated with the second state data, and then can obtain the index relationship of the second node indicated by the tree to be processed (for example, from top-down index relationship).
  • the full number of nodes may traverse from the root node of the tree to search for characters having the same prefix as the key character string based on the second node index relationship.
  • the full node can obtain the character string to be processed based on all the characters found, obtain the existence certificate associated with the character string to be processed, and use the obtained certificate of existence as the modifiable certificate of the second state data .
  • the tree to be processed determined by the full amount of nodes can be the Merkel Patricia tree 5m shown in Figure 5, and the second state data is inserted into the Merkel Patricia tree 5m Before, the full amount of nodes can obtain the key character string associated with the second state data (for example, 90), and then can obtain the second node index relationship indicated by the Merkel Patricia tree 5m (for example, top-to-bottom under the index relationship). Further, based on the second node index relationship, the full number of nodes can traverse from the tree root node (for example, the extended node 10Z shown in FIG. 5 ) to search for characters with the same prefix as the key character string. At this point, the full node can obtain the character string to be processed based on all the found characters.
  • the tree root node for example, the extended node 10Z shown in FIG. 5
  • the full amount of nodes can be found in the Merkel Patricia tree 5m shown in Fig. All matched characters, that is, the character string to be processed determined by the full node (for example, character string 1 to be processed) is "ab567cd”. At this time, the full amount of nodes can obtain the nodes associated with the characters in the character string 1 to be processed, that is, the expansion node 10Z for storing the character "ab", the branch node 10F for storing the character "5", and the node for storing the character "5".
  • the extended node 20Z storing the character "67cd" and the data node 10S indicated by the hash pointer of the extended node 20Z.
  • the full node can directly use the proof of existence of the data node 10S (for example, the proof of existence 6p shown in Figure 6 above) as the proof of existence associated with the character string 1 to be processed, and then can use The proof of existence associated with character string 1 is processed as a modifiable proof of the second state data.
  • the full amount of nodes can be found in the Merkel Patricia tree 5m shown in Figure 5 and key Part of the characters that match the character string, that is, the character string to be processed determined by the full node (for example, character string 2 to be processed) is "abc".
  • the full amount of nodes can obtain the nodes associated with the characters in the character string 2 to be processed, that is, the expansion node 10Z for storing the character "ab” and the branch node 10F for storing the character "c”.
  • FIG. 7 is a schematic diagram of a modifiable proof of the second-state data provided by the embodiment of the present application.
  • the modifiable proof 7q shown in FIG. 7 is the modifiable proof of the second state data collected by all nodes in the blockchain network.
  • the full node can obtain the existence proof of the second state data, and then can use the existence proof of the second state data as the second existence proof.
  • the full node can generate a state writing set based on the modifiable proof and the second proof of existence.
  • the full node can also obtain the block identifier in the first block header of the target block, and then can execute the initial transaction execution result obtained by executing the transaction business, the generated state read set and state write set, and obtain The received block ID is used as the transaction verification information corresponding to the transaction to be verified. Further, the full node can send the transaction verification information to the user node in the blockchain network, so that the user node can send the transaction verification information and the transaction to be verified to the block chain network node. Among them, it can be understood that the user node can also send the transaction signature information to the block node, so that the block node can verify the signature of the transaction to be verified, so as to effectively ensure the security and authenticity of the transaction to be verified. .
  • S102 in the block header chain of the lightweight node, search for the block header that matches the block identifier in the first block header, and use the found block header as the second block header, based on the first block header in the second block header
  • the state snapshot verifies the state read set and state write set to obtain the first verification result of the transaction to be verified.
  • the state read set and state write set are generated by all nodes in the blockchain network based on the Merkel Patricia tree in the target block.
  • the block producing node in the blockchain network can search the block header chain of the lightweight node that matches the block identifier in the first block header. block header, and then the found block header can be used as the second block header, and the state snapshot in the second block header can be used as the first state snapshot.
  • the block producing node can also obtain the first existence proof of the first state data from the state reading set included in the transaction verification information, and then can verify the first existence proof based on the first state snapshot. verification to obtain the first proof verification result.
  • the first state data here may be the state data associated with the transactions to be verified read by all nodes on the Merkel Patricia tree of the target block.
  • the block producing node can also obtain the modifiable proof of the second state data from the state writing set included in the transaction verification information, and then verify the modifiable proof based on the first state snapshot to obtain the second Prove the verification result.
  • the second state data here may be the state data of the next block that is simulated to be written into the target block recorded by the full amount of nodes during the process of executing the transaction business.
  • the block producing node may determine the first verification result of the transaction to be verified based on the first proof verification result and the second proof verification result.
  • the block producing node 20C in the embodiment of the present application can obtain the block identifier in the first block header (that is, the block header 100 in the block 100g of the block chain 2a) from the block header chain 2b The matching block header, and then the obtained block header can be used as the second block header (that is, the block header 100 in the block header chain 2b). Further, the block producing node 20C may obtain the state snapshot in the second block header, and use the obtained state snapshot as the first state snapshot.
  • the block producing node in the blockchain network can obtain the first existence proof of the first state data from the state reading set.
  • the first proof of existence may be a node path associated with the first state data obtained by all nodes from the Merkel Patricia tree in the target block.
  • the node path can contain leaf nodes and tree root nodes.
  • the block producing node can obtain the first node index relationship (for example, a bottom-up index relationship) indicated by the node path, and then can use the leaf node as a child node based on the first node index relationship, and the leaf node
  • the previous node of the node is used as the parent node of the child node, and then the hash value of the child node of the child node can be compared with the hash pointer of the parent node, so as to obtain the initial comparison result. If the initial comparison result indicates that the comparison is successful, the block producing node can update the child node and the parent node based on the index relationship of the first node until the updated parent node is the root node of the tree, and the first existence proof node can be obtained.
  • the initial comparison result indicates that the comparison is successful
  • the block producing node can also compare the root hash value of the tree root node with the first state snapshot to obtain the second comparison result of the first proof of existence, and then based on the first comparison result and the second comparison result to obtain the first proof verification result.
  • the block generating node in the embodiment of the present application can first traverse and compare the hash value of the child node and the hash pointer of the parent node, and then compare the root hash value of the tree root node with the first state snapshot.
  • the block producing node can also first compare the root hash value of the tree root node with the first state snapshot, and then traverse and compare the hash value of the child node with the hash pointer of the parent node, which will not be compared here
  • the order of precedence is limited.
  • the first existence proof of the first state data obtained by the block producing node in the blockchain network from the state reading set may be the existence proof 6p shown in FIG. 6 .
  • the existence proof 6p can be the node path associated with the first state data (for example, 100) obtained by all nodes from the Merkel Patricia tree in the target block, and the node path here can include leaf A node (for example, a data node 10S for storing the first state data), an intermediate node (for example, an extended node 20Z and a branch node 10F), and a tree root node (for example, an extended node 10Z).
  • the block producing node in the embodiment of the present application can use the data node 10S as a child node based on the first node index relationship indicated by the node path, and use the previous node of the data node 10S (ie, the extended node 20Z) as a parent node. Further, the block producing node can obtain the node hash value of the data node 10S, and use the node hash value of the data node 10S as the child node hash value. At this time, the block producing node can compare the node hash value of the data node 10S with the hash pointer (for example, 0x936e . . . ) of the extension node 20Z, so as to obtain the initial comparison result.
  • the hash pointer for example, 0x936e . . .
  • the block producing node can determine that the initial comparison result indicates that the comparison failed. At this time, the block producing node can directly determine that the transaction to be verified does not have legality.
  • the block generating node can determine that the initial comparison result indicates that the comparison is successful. At this time, the block generating node can be based on the first node The index relationship updates the child nodes as well as the parent nodes.
  • the block producing node can take the extended node 20Z as a new child node (ie, the first updated child node), and take the previous node of the extended node 20Z (for example, the branch node 10F) as the parent of the first updated child node node (that is, the first updated parent node), and then compare the node hash value of the extended node 20Z with the hash pointer (for example, 0xa15c...) of the character "5" in the branch node 10F to obtain a new initial comparison Result (that is, the result of the first update comparison).
  • the block producing node can continue to update the child node and the parent node, that is, the branch node 10F will be the latest child node (ie, the second updated child node), and the previous node of the branch node 10F will be (for example, the extended node 10Z) as the parent node of the second updated child node (that is, the second updated parent node), and then the node hash value of the branch node 10F can be combined with the hash pointer of the extended node 10Z (for example, 0x5f90... ) for comparison to obtain the latest initial comparison result (ie, the second updated comparison result).
  • the branch node 10F will be the latest child node (ie, the second updated child node)
  • the previous node of the branch node 10F will be (for example, the extended node 10Z) as the parent node of the second updated child node (that is, the second updated parent node)
  • the node hash value of the branch node 10F can be combined with the hash
  • the block producing node can end the update, and then the latest initial comparison result can be used as This presence demonstrates the first alignment of 6p.
  • the block producing node can obtain the node hash value of the extended node 10Z (that is, the tree root hash value), compare the node hash value of the extended node 10Z with the first state snapshot, and obtain the existence proof 6p The result of the second comparison.
  • the block producing node can determine that the first verification result indicates that If the verification fails, at this time, the block producing node can directly determine that the transaction to be verified is not legal.
  • the block producing node may determine that the first proof verification result indicates that the verification success.
  • the block producing node can continue to write the set of states included in the transaction verification information to obtain the modifiable proof of the second state data, and then verify the modifiable proof based on the first state snapshot to obtain the second 2. Prove the verification result.
  • the specific implementation manner for the block producing node to determine the second proof verification result can refer to the above-mentioned specific implementation manner for determining the first proof verification result, and details will not be repeated here.
  • the block producing node may determine the first verification result of the transaction to be verified based on the first proof verification result and the second proof verification result. It should be understood that when the first proof verification result indicates verification failure, or the second proof verification result indicates verification failure, the block producing node may determine that the first verification result of the transaction to be verified indicates verification failure, at this time , the block producing node can determine that the transaction to be verified is not legal. Optionally, when both the first proof verification result and the second proof verification result indicate that the verification is successful, the block producing node may determine that the first verification result of the transaction to be verified indicates that the verification is successful, and then execute the following S103. Continue to perform legal transactions on transactions to be verified.
  • the block producing node can obtain the first state data from the first proof of existence in the state reading set, and then execute the transaction based on the first state data business to obtain the transaction execution result corresponding to the transaction business.
  • the transaction execution result obtained after the block producing node executes the transaction service may be referred to as the target transaction execution result.
  • the block producing node may record the status data of the next block that needs to be written into the target block during the process of executing the transaction service.
  • the state data recorded by the block producing node that needs to be written into the next block of the target block may be referred to as state data to be written.
  • the block producing node can execute the transaction business corresponding to the transaction to be verified based on the first state data (for example, 100) in the state reading set, so as to obtain the target transaction execution result.
  • the state data of the next block that needs to be written into the target block recorded by the block producing node during the execution of the transaction business may be 90. This means that after the block node executes the transaction corresponding to the transaction to be verified, the account balance of user 1 will be updated from 100 game coins to 90 game coins.
  • the block producing node can compare the initial transaction execution result with the target transaction execution result to obtain a third comparison result.
  • the block producing node can also obtain the second existence proof of the second state data from the state writing set, and then can verify the second existence proof based on the first state snapshot in the second block header. test.
  • the block producing node can compare the second state data with the state data to be written to obtain a fourth comparison result.
  • the block producing node can obtain a second verification result of the transaction to be verified based on the third comparison result and the fourth comparison result, and perform a legality verification of the transaction to be verified based on the second verification result.
  • the block producing node in the embodiment of the present application can first compare the execution result of the initial transaction and the execution result of the target transaction, and then verify the second proof of existence and compare the second state data with the state data to be written. Wherein, if the third comparison result indicates that the initial transaction execution result is inconsistent with the target transaction execution result, the block producing node may determine that the third comparison result indicates that the comparison fails, that is, the transaction to be verified is not legal. Optionally, if the third comparison result indicates that the execution result of the initial transaction is consistent with the execution result of the target transaction, the block producing node may determine that the third comparison result indicates that the comparison is successful, and then continue to base the first state snapshot on the The state is written to a second proof of existence in the set for verification.
  • the specific implementation manner of verifying the second proof of existence by the block producing node can refer to the specific implementation manner of verifying the first proof of existence above, and details will not be repeated here.
  • the block producing node can determine that the transaction to be verified is not legal. It should be understood that when the verification of the second proof of existence is successful, the block producing node can continue to compare the second state data in the second proof of existence with the state data to be written recorded by the block producing node, so that the first Four comparison results. If the fourth comparison result indicates that the second state data is inconsistent with the state data to be written, the block generating node determines that the comparison of the fourth comparison result fails.
  • the block generating node can determine the second verification of the transaction to be verified The result indicates that the verification failed, that is, the transaction to be verified is not legal.
  • the block generating node may determine that the fourth comparison result indicates that the comparison is successful. Based on this, the block generating node may determine that the pending The second verification result of the verified transaction indicates that the verification is successful, that is, the transaction to be verified is legal.
  • the block producing node can first verify the second existence certificate and compare the second state data with the state data to be written, and then compare the initial transaction execution result with the target transaction execution result.
  • the order of comparison will not be limited here.
  • the full amount of nodes in the embodiment of the application obtains the transaction to be verified sent by the user node, it can execute the transaction business corresponding to the transaction to be verified based on the target block in the full block chain, and then can execute the transaction business
  • the resulting initial transaction execution result, state read set, state write set, and the block identifier of the target block are used as the transaction verification information of the transaction to be verified.
  • the block producing node in the blockchain network receives the transaction to be verified, it will also obtain the transaction verification information determined by the full number of nodes.
  • the block producing node does not need to spend time to synchronize all state data from the genesis block of the full blockchain, but directly obtains the second block that matches the block ID from the block header chain of the block producing node block header, and according to the first state snapshot of the second block header and transaction verification information, quickly verify the validity of the transaction to be verified, so as to improve the efficiency of legality verification and reduce the operating burden of the block node, so that Greatly speed up the startup time of block producers.
  • the block producing node in the embodiment of this application is a lightweight node in the blockchain network, the block producing node does not need to retain the complete block data, but the block header formed by connecting the block headers end to end Part of the data on the chain can be verified for transactions to be verified, which can greatly reduce the consumption of storage space.
  • FIG. 8 is a schematic flowchart of a transaction verification method provided by an embodiment of the present application.
  • this method can be jointly executed by user nodes, full nodes, and block producing nodes in the blockchain network.
  • the user node can be a blockchain node controlled by the user in the blockchain network, for example, The user node may be the user node 20A shown in FIG. 2 above.
  • the full node in the embodiment of the present application may be a blockchain node in the blockchain network that has the function of storing complete block data.
  • the full node may be the full node 20B shown in FIG. 2 above.
  • the block producing node may be a lightweight node in the blockchain network, for example, the block producing node may be the block producing node 20C shown in FIG. 2 above.
  • the method may at least include the following S201-S209:
  • the user node will send the transaction to be verified assembled by the user to the full node;
  • the full amount of nodes obtains the Merkel Patricia tree in the target block, executes the transaction business corresponding to the transaction to be verified based on the Merkle Patricia tree in the target block, and obtains the initial transaction corresponding to the transaction business Execution result, state read collection and state write collection;
  • the full amount of nodes obtain the block identifier in the first block header, and use the initial transaction execution result, state read set, state write set and block identifier as the transaction verification information corresponding to the transaction to be verified;
  • the full node sends the transaction verification information to the user node
  • the block producing node searches for the block header that matches the block identifier in the first block header, and uses the found block header as the second block header, based on the block header in the second block header.
  • the first state snapshot of verify the state read set and state write set, and obtain the first verification result of the transaction to be verified;
  • the block producing node executes the transaction business based on the state read set, and obtains the target transaction execution result corresponding to the transaction business and the status data to be written;
  • the block producing node checks the validity of the transaction to be verified based on the initial transaction execution result, the target transaction execution result, the state writing set, and the state data to be written.
  • FIG. 9 is a schematic flowchart of a transaction verification method provided by an embodiment of the present application.
  • this method can be jointly executed by the user node, the full node and the block producing node in the blockchain network, and the user node can be a blockchain node controlled by the user in the blockchain network, for example,
  • the user node may be the user node 20A shown in FIG. 2 above.
  • the full node in the embodiment of the present application may be a blockchain node in the blockchain network that has the function of storing complete block data.
  • the full node may be the full node 20B shown in FIG. 2 above.
  • the block producing node may be a lightweight node in the blockchain network, for example, the block producing node may be the block producing node 20C shown in FIG. 2 above.
  • the user node in the embodiment of this application can execute S91 when the user executes the trigger operation associated with the transaction to be verified, assemble the transaction to be verified for the user, and then send the transaction to be verified to the full amount of nodes .
  • the full node when the full node receives the transaction to be verified, it can execute S92, and execute the transaction to be verified based on the target block (that is, the block with the largest generation time stamp) on the full block chain of the full node Corresponding transaction business, to obtain the transaction execution result corresponding to the transaction business (that is, the initial transaction execution result), the state reading set and the state writing set, and then the first block header of the target block (for example, as shown in Figure 2
  • the block identifier, the initial transaction execution result, the state read set and the state write set in the block header 100) of the block 100g are used as the transaction verification information of the transaction to be verified, and then the transaction verification information can be sent to the user node.
  • the user node receives the transaction verification information, it
  • the block producing node When the block producing node receives the transaction to be verified and the transaction verification information, it can execute S94 to obtain the block header matching the block identification of the first block header from the block header chain of the block producing node (that is, the second block header ), and then based on the state snapshot (ie, the first state snapshot) in the second block header (for example, the block header 100 in the block header chain 2b shown in FIG. 2 ), the state reading in the transaction verification information can be verified The set and state are written into the set to obtain the first verification result.
  • the state snapshot ie, the first state snapshot
  • the block producing node can execute S95 to read the first state data in the set based on the state, execute the transaction business, and obtain The target transaction execution result and record all the data that needs to be written (that is, the status data to be written), and then based on the initial transaction execution result and status in the transaction verification information, the set can be written, and the target transaction execution result obtained after executing the transaction business and the status data to be written, and verify the validity of the transactions to be verified.
  • the specific implementation manner of verifying the validity of the transaction to be verified in the embodiment of the present application please refer to the description of S101-S104 in the embodiment corresponding to FIG. 3 above, which will not be repeated here.
  • the block producing node may execute S96 to generate a new state snapshot (ie, a second state snapshot) associated with the second state data based on the second state data in the state writing set. Further, the block producing node may execute S97 to generate a new block header (that is, a block header to be processed) based on the transaction to be verified, the execution result of the target transaction, and the second state snapshot. Wherein, the pending block header can be used as the next block header of the second block header on the block header chain.
  • a new state snapshot ie, a second state snapshot
  • the block producing node may execute S97 to generate a new block header (that is, a block header to be processed) based on the transaction to be verified, the execution result of the target transaction, and the second state snapshot.
  • the pending block header can be used as the next block header of the second block header on the block header chain.
  • the block producing node can write the pending block header into the block header chain, and after successfully writing the pending block header into the block header chain, it can send the pending block header to the full node, so that the full amount
  • the node executes S98, based on the transaction in the block header to be processed (the transaction to be verified with legality), re-executes the corresponding transaction business, generates a new block (that is, the block to be processed), and then the block to be processed can be The block is written into the full blockchain as the next block of the target block on the full blockchain.
  • FIG. 10 is a schematic diagram of a scenario for generating blocks to be processed according to an embodiment of the present application.
  • the full node 100B in the embodiment of the present application can be a blockchain node in the blockchain network that has the function of saving complete block data, for example, the full node 100B can be the Full node 20B.
  • the block producing node 100C may be a lightweight node in the blockchain network, for example, the block producing node 100C may be the block producing node 20C shown in FIG. 2 above.
  • the block header chain of the block producing node 100C in the embodiment of the present application may be the block header chain 10 b shown in FIG. 10 .
  • the block header 100 in the block header chain 10b may be the second block header determined by the block producing node 100C based on the block identifier in the transaction verification information corresponding to the transaction to be verified, and the second block header may include the first State snapshot.
  • the block header 101 in the block header chain 10b may be a new block header (i.e., a block header to be processed) generated when the block producing node 100C determines that the transaction to be verified is legal, and the block header 101 may include the first block header. Two state snapshots.
  • the block producing node 100C can write the state from the transaction verification information into the set, and obtain the second state data recorded by the full node 100B after simulating the execution of the transaction corresponding to the transaction to be verified. Further, the block producing node 100C may generate a new state snapshot (ie, a second state snapshot) associated with the second state data based on the second state data.
  • a new state snapshot ie, a second state snapshot
  • the block producing node 100C can package the transaction to be verified, the execution result of the target transaction, and the second state snapshot, so as to obtain a new block header (that is, the block header to be processed), and then use the block header to be processed as The next block header of the block header 100 (that is, the block header 101 ), so as to write the block header 101 into the block header chain 10 b shown in FIG. 10 .
  • the block producing node 100C can send the block header 101 to the full node 100B shown in FIG. 10 .
  • the block producing node 100C can first obtain the node public key of the full number of nodes 100B, and encrypt the block header 101, so as to obtain encrypted data information, and then, Send the encrypted data information to all nodes 100B.
  • the full node 100B When the full node 100B receives the encrypted data information, it can decrypt the encrypted data information based on the node private key of the full node 100B, so as to obtain the block header 101 generated by the block producing node 100C. At this time, the full node 100B can obtain the transaction to be verified in the block header 101, and then re-execute the transaction business corresponding to the transaction to be verified to generate a new block (ie, a block to be processed). As shown in FIG. 10 , the blockchain 10a may be the full blockchain of the full node 100B, and the block 100g in the blockchain 10a may be the target block determined by the full node 100B.
  • the full node 100B can record the state data (that is, the target state data) that needs to be written into the block to be processed, and then based on the target state data, the The Merkel Patricia tree in block 100g (that is, the tree to be processed) is updated to obtain a new Merkel Patricia tree (that is, the target Merkel Patricia tree), and based on this Target Merkle Patricia tree, generating pending blocks. It should be understood that after the full node 100B generates the block to be processed, it can use the block to be processed as the next block of the block 100g (that is, the block 101g shown in FIG. 10 ), so that the block to be processed can be successfully processed. Write to blockchain 10a. Wherein, the generation time stamp in the block 101g is used to update the maximum generation time stamp on the block chain 10a.
  • the full amount of nodes in the embodiment of the application obtains the transaction to be verified sent by the user node, it can execute the transaction business corresponding to the transaction to be verified based on the target block in the full block chain, and then can execute the transaction business
  • the resulting initial transaction execution result, state read set, state write set, and the block identifier of the target block are used as the transaction verification information of the transaction to be verified.
  • the block producing node in the blockchain network receives the transaction to be verified, it will also obtain the transaction verification information determined by the full number of nodes.
  • the block producing node does not need to spend time to synchronize all state data from the genesis block of the full blockchain, but directly according to the first state snapshot of the second block header in the block header chain of the block producing node, And transaction verification information to determine the legitimacy of the transaction to be verified, so as to reduce the operating burden of the block node, so that the startup time of the block node is greatly accelerated.
  • the block producing node in the embodiment of this application is a lightweight node in the blockchain network, the block producing node does not need to retain the complete block data, but the block header formed by connecting the block headers end to end Part of the data on the chain can be verified for transactions to be verified, which can greatly reduce the consumption of storage space.
  • the block producing node When the block producing node verifies that the transaction to be verified is legal, it can also generate a new block header (that is, the block header to be processed) based on the transaction to be verified, and send the new block header to the full amount of nodes, so that the full amount of nodes can be based on the new
  • the block header generates a new block, and then the legal transaction to be verified can be successfully written to the full block chain.
  • FIG. 11 is a schematic structural diagram of a transaction verification device provided by an embodiment of the present application.
  • the transaction verification device 1 can be a computer program (including program code) running in a computer device, for example, the transaction verification device 1 is an application software; the transaction verification device 1 can be used to implement the method provided by the embodiment of the present application corresponding steps in .
  • the transaction verification device 1 can run on a block producing node in the blockchain network, and the block producing node can be a lightweight node in the blockchain network, for example, the block producing node can be the above-mentioned The block producing node 20C in the embodiment corresponding to FIG. 2 .
  • the transaction verification device 1 may include: a transaction acquisition module 10, a set verification module 20, a target execution result determination module 30, a legality verification module 40, a state snapshot generation module 50, a pending block header generation module 60, and a pending area A block header writing module 70 , an encryption processing module 80 and an encrypted data information sending module 90 .
  • the transaction acquisition module 10 is used to obtain the transaction to be verified sent by the user node in the block chain network and the transaction verification information corresponding to the transaction to be verified; the transaction verification information is executed by the full number of nodes in the block chain network. Determined after the corresponding transaction business; transaction verification information includes state read set, state write set, initial transaction execution result, and block ID; block ID is used to point to the full amount of nodes on the full block chain with the maximum generation time stamped target block; and the first block header of the target block contains the block identifier;
  • the set verification module 20 is used to search for a block header matching the block identifier in the first block header in the block header chain of the lightweight node, and use the found block header as the second block header, based on the first block header.
  • the first state snapshot in the second block header verifies the state read set and the state write set to obtain the first verification result of the transaction to be verified.
  • the state read set and state write set are generated by full nodes based on the Merkel Patricia tree in the target block;
  • the set verification module 20 includes: a state snapshot acquisition unit 201 , a read set check unit 202 , a write set check unit 203 and a check result determination unit 204 .
  • the state snapshot acquisition unit 201 is configured to search for a block header that matches the block identifier in the first block header from the block header chain of the lightweight node, and use the found block header as the second block header, and set The state snapshot in the second block header is used as the first state snapshot;
  • the read set verification unit 202 is configured to obtain the first existence proof of the first state data from the state read set, and verify the first existence proof based on the first state snapshot to obtain the first proof verification verification results; the first state data is the state data associated with the transaction to be verified read by the full amount of nodes on the Merkle Patricia tree in the target block.
  • the read set verification unit 202 includes: a certificate acquisition subunit 2021, an initial comparison result determination subunit 2022, a first comparison result determination subunit 2023, a second comparison result determination subunit 2024 and a verification result Determine the subunit 2025 .
  • the certificate acquisition subunit 2021 is used to obtain the first existence certificate of the first state data from the state reading set; the first existence certificate is obtained from the Merkel Patricia tree in the target block for all nodes
  • the node path associated with the first state data is reached; the node path includes a leaf node and a tree root node; the leaf node is used to store the first state data;
  • the initial comparison result determination subunit 2022 is configured to use the leaf node as a child node based on the first node index relationship indicated by the node path, and use the previous node of the leaf node as the parent node corresponding to the child node, and use the child node Compare the hash value of the child node with the hash pointer of the parent node to get the initial comparison result;
  • the first comparison result determining subunit 2023 is used to update the child node and the parent node based on the first node index relationship until the updated parent node is the root node of the tree if the initial comparison result indicates that the comparison is successful.
  • the second comparison result determining subunit 2024 is used to compare the tree root hash value of the root node with the first state snapshot to obtain the second comparison result of the first existence certificate;
  • the verification result determination subunit 2025 is configured to obtain a first proof verification result based on the first comparison result and the second comparison result.
  • the specific implementation of the certification acquisition subunit 2021, the initial comparison result determination subunit 2022, the first comparison result determination subunit 2023, the second comparison result determination subunit 2024 and the verification result determination subunit 2025 can be Refer to the description of the first proof verification result in the above-mentioned embodiment corresponding to FIG. 3 , and details will not be repeated here.
  • the write set verification unit 203 is used to obtain the modifiable proof of the second state data from the state write set, and verify the modifiable proof based on the first state snapshot to obtain the second proof verification result;
  • the second state data is the state data of the next block that is simulated and written into the target block recorded by the full amount of nodes in the process of executing the transaction business;
  • the verification result determination unit 204 is configured to determine the first verification result of the transaction to be verified based on the first proof verification result and the second proof verification result.
  • the specific implementation manners of the state snapshot acquisition unit 201, the read collection verification unit 202, the write collection verification unit 203 and the verification result determination unit 204 can refer to the description of S102 in the above-mentioned embodiment corresponding to FIG. 3 , No further details will be given here.
  • the target execution result determining module 30 is configured to execute the transaction business based on the state reading set when the first verification result indicates that the verification is successful, and obtain the target transaction execution result corresponding to the transaction business and the state data to be written;
  • the legitimacy verification module 40 is used to verify the legitimacy of the transaction to be verified based on the initial transaction execution result, the target transaction execution result, the state writing set and the state data to be written.
  • the legality verification module 40 includes: a transaction execution result comparison unit 401 , a certificate verification unit 402 , a state data comparison unit 403 and a legality verification unit 404 .
  • the transaction execution result comparison unit 401 is configured to compare the initial transaction execution result with the target transaction execution result to obtain a third comparison result
  • the proof verification unit 402 is configured to obtain the second existence proof of the second state data from the state writing set, and verify the second existence proof based on the first state snapshot;
  • a state data comparison unit 403, configured to compare the second state data with the state data to be written when the verification is successful, to obtain a fourth comparison result
  • the legitimacy verification unit 404 is configured to obtain a second verification result of the transaction to be verified based on the third comparison result and the fourth comparison result, and perform a legality verification of the transaction to be verified based on the second verification result .
  • the specific implementation of the transaction execution result comparison unit 401, the proof verification unit 402, the state data comparison unit 403 and the legality verification unit 404 can refer to the description of S104 in the embodiment corresponding to the above-mentioned FIG. 3, here No further description will be given.
  • the state snapshot generation module 50 is configured to generate a second state snapshot associated with the second state data based on the second state data in the state write set when determining that the transaction to be verified is legal;
  • the block header generation module 60 to be processed is used to generate a block header to be processed based on the transaction to be verified, the target transaction execution result and the second state snapshot; the block header to be processed is used as the next block header of the second block header;
  • the pending block header writing module 70 is used for writing the pending block header into the block header chain.
  • the encryption processing module 80 is used to obtain the node public key of the full amount of nodes after the block header to be processed is successfully written into the block header chain, and perform encryption processing on the block header to be processed to obtain encrypted data information;
  • the encrypted data information sending module 90 is used to send the encrypted data information to the full amount of nodes, so that the full amount of nodes can decrypt the encrypted data information based on the node private key of the full amount of nodes, and obtain the block header to be processed; Instructing the full amount of nodes to generate the block to be processed corresponding to the head of the block to be processed; the block to be processed is used as the next block of the target block on the full block chain.
  • the transaction acquisition module 10 the collection verification module 20, the target execution result determination module 30, the legality verification module 40, the state snapshot generation module 50, the pending block header generation module 60, and the pending block header writing module 70
  • the encryption processing module 80 and the encrypted data information sending module 90 reference may be made to the description of S101-S104 in the above embodiment corresponding to FIG. 3 , and details will not be repeated here.
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • FIG. 12 is a schematic structural diagram of a transaction verification device provided by an embodiment of the present application.
  • the transaction verification device 2 can be a computer program (including program code) running in the computer equipment, for example, the transaction verification device 2 is an application software; the transaction verification device 2 can be used to implement the method provided by the embodiment of the present application corresponding steps in .
  • the transaction verification device 2 can run on a full-scale node in the blockchain network, and the full-scale node can be the full-scale node 20B in the above-mentioned embodiment corresponding to FIG. 2 .
  • the transaction verification device 2 may include: a target block determination module 100 , an initial execution result determination module 200 and a verification information determination module 300 .
  • the target block determination module 100 is configured to use the block with the largest generation time stamp on the full block chain of the full block nodes as The target block, and the block header of the target block is used as the first block header.
  • the target block determination module 100 includes: a signature information receiving unit 1001 , a signature information verification unit 1002 and a target block determination unit 1003 .
  • the signature information receiving unit 1001 is used to receive the transaction signature information corresponding to the transaction to be verified sent by the user node in the blockchain network; the transaction signature information is obtained by the user node after signing the transaction to be verified based on the user's private key ;
  • the signature information verification unit 1002 is used to obtain the user public key corresponding to the user private key, and verify the transaction signature information based on the user public key to obtain a verification result;
  • the target block determination unit 1003 is configured to obtain a block with the largest generation time stamp on the full block chain of all nodes when the signature verification result indicates that the signature verification is successful, and use the obtained block as the target block , and take the block header of the target block as the first block header.
  • the specific implementation of the signature information receiving unit 1001, the signature information verification unit 1002 and the target block determination unit 1003 can refer to the description of S202 in the above embodiment corresponding to FIG. 8, and will not be repeated here.
  • the initial execution result determination module 200 is used to obtain the Merkel Patricia tree in the target block, execute the transaction business corresponding to the transaction to be verified based on the Merkel Patricia tree in the target block, and obtain The initial transaction execution result, state read set and state write set corresponding to the transaction business.
  • the initial execution result determination module 200 includes: a first state data determination unit 2001 , a second state data determination unit 2002 , a read set generation unit 2003 and a write set generation unit 2004 .
  • the first state data determination unit 2001 is used to acquire the Merkel Patricia tree in the target block, and use the acquired Merkel Patricia tree as the tree to be processed, and read from the tree to be processed
  • the status data associated with the transaction to be verified, the read status data is used as the first status data
  • the second state data determination unit 2002 is configured to execute the transaction business corresponding to the transaction to be verified based on the first state data, obtain the initial transaction execution result corresponding to the transaction business, and record the simulated write target in the process of executing the transaction business The status data of the next block of the block, the recorded status data is used as the second status data;
  • the read set generation unit 2003 is configured to collect a first existence proof of the first state data based on the tree to be processed, and generate a state read set based on the first existence proof;
  • the writing set generating unit 2004 is configured to collect the modifiable proof and the second existence proof of the second state data based on the tree to be processed, and generate a state writing set based on the modifiable proof and the second existence proof.
  • the writing set generating unit 2004 includes: a modifiable proof acquiring subunit 20041 , an existence proof acquiring subunit 20042 and a writing set generating subunit 20043 .
  • the modifiable certificate obtaining subunit 20041 is used to obtain the key string associated with the second state data before inserting the second state data into the tree to be processed, and obtain the modifiable certificate of the second state data based on the key string .
  • the tree to be processed includes the root node of the tree
  • the modifiable certificate acquisition subunit 20041 is also used for:
  • a character string to be processed is obtained, an existence proof associated with the character string to be processed is obtained, and the obtained existence proof is used as a modifiable proof of the second state data.
  • the existence certificate obtaining subunit 20042 is used to obtain the existence certificate of the second state data after inserting the second state data into the tree to be processed, and use the existence certificate of the second state data as the second existence certificate;
  • the writing set generation subunit 20043 is configured to generate a state writing set based on the modifiable proof and the second existence proof.
  • the specific implementation of the modifiable proof acquisition subunit 20041, the existence proof acquisition subunit 20042 and the write set generation subunit 20043 can refer to the description of the state write set in the above-mentioned embodiment corresponding to FIG. 3 , here No further details will be given.
  • the specific implementation of the first state data determination unit 2001, the second state data determination unit 2002, the read set generation unit 2003 and the write set generation unit 2004 can refer to the description of S208 in the embodiment corresponding to FIG. 8 above. , which will not be repeated here.
  • the verification information determination module 300 is used to obtain the block identifier in the first block header, and use the initial transaction execution result, state read set, state write set and block identifier as the transaction verification information corresponding to the transaction to be verified;
  • the transaction verification information is used to indicate the block producing node in the blockchain network, based on the first status snapshot in the second block header in the block header chain, to verify the validity of the transaction to be verified;
  • the second block header is the block header chain
  • the block producing node is a lightweight node in the blockchain network.
  • the specific implementation manners of the target block determination module 100, the initial execution result determination module 200 and the verification information determination module 300 can refer to the description of S201-S209 in the embodiment corresponding to FIG. 8 above, and will not be repeated here. .
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • FIG. 13 is a schematic diagram of a computer device provided by an embodiment of the present application.
  • the computer device 3000 may be the block producing node 20C in the embodiment corresponding to Figure 2 above, and the computer device 3000 may include: at least one processor 3001, such as a CPU, at least one network interface 3004, and a user interface 3003 , memory 3005, at least one communication bus 3002.
  • the communication bus 3002 is used to realize connection and communication between these components.
  • the user interface 3003 may include a display screen (Display) and a keyboard (Keyboard), and the network interface 3004 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).
  • the memory 3005 can be a high-speed RAM memory, or a non-volatile memory, such as at least one disk memory.
  • the storage 3005 may optionally also be at least one storage device located far away from the aforementioned processor 3001 .
  • the memory 3005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 3004 is mainly used for network communication; the user interface 3003 is mainly used to provide an input interface for the user; and the processor 3001 can be used to call the device control stored in the memory 3005 application.
  • the computer device 3000 described in the embodiment of the present application can execute the description of the transaction verification method in the previous embodiment corresponding to FIG. 3 or FIG. 8 , and can also execute the transaction verification method in the previous embodiment corresponding to FIG. 11
  • the description of the transaction verification device 2 in the device 1 or the embodiment corresponding to FIG. 12 will not be repeated here.
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium is stored with the above-mentioned transaction verification device 1 or transaction verification device 2.
  • program, and the computer program includes program instructions.
  • the processor executes the program instructions, it can execute the description of the transaction verification method in the embodiment corresponding to FIG. 3 or FIG. 8 above, so details will not be repeated here.
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • program instructions may be deployed to execute on one computing device, or on multiple computing devices located at one site, or, alternatively, on multiple computing devices distributed across multiple sites and interconnected by a communication network
  • program instructions may be deployed to execute on one computing device, or on multiple computing devices located at one site, or, alternatively, on multiple computing devices distributed across multiple sites and interconnected by a communication network
  • multiple computing devices distributed in multiple locations and interconnected by a communication network can form a blockchain system.
  • One aspect of the present application provides a computer program product or computer program, the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the description of the transaction verification method in the embodiment corresponding to Figure 3 or Figure 8 above, here No longer.
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • FIG. 14 is a schematic structural diagram of a data processing system provided by an embodiment of the present application.
  • the data processing system 3 may include a data processing device 1a and a data processing device 2a.
  • the data processing device 1a may be the transaction verification device 1 in the above-mentioned embodiment corresponding to FIG. , which will not be repeated here.
  • the data processing device 2a may be the transaction verification device 2 in the above-mentioned embodiment corresponding to FIG. 12. It can be understood that the data processing device 2a may be integrated into the full node 20B in the above-mentioned embodiment corresponding to FIG. 2. Therefore, No further details will be given here. In addition, the description of the beneficial effect of adopting the same method will not be repeated here.
  • the technical details not disclosed in the embodiments of the data processing system involved in this application please refer to the description of the method embodiments of this application.
  • the above programs can be stored in a computer-readable storage medium. During execution, it may include the processes of the embodiments of the above-mentioned methods.
  • the storage medium mentioned above may be a magnetic disk, an optical disk, a read-only memory (Read-Only Memory, ROM) or a random access memory (Random Access Memory, RAM), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例公开了一种交易验证方法、装置、设备及存储介质，该方法包括：区块链网络中的出块节点获取用户节点发送的待验证交易以及待验证交易对应的交易验证信息；在区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果；在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到目标交易执行结果以及待写入状态数据；基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。采用本申请实施例，可以加快出块节点的启动时间。

Description

一种交易验证方法、装置、设备及存储介质
本申请要求于2021年05月18日提交中国专利局、申请号为202110537182.6、申请名称为“一种交易验证方法、装置、设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域，尤其涉及交易验证。
背景技术
应当理解，区块链网络中的出块节点在生成新区块时，需要收集在该区块链网络中传播的未确认的交易，进而可以逐个执行收集到的交易所对应的交易业务，以得到交易执行结果。其中，出块节点在执行交易业务的过程中，需要从该区块链网络的区块链中，事先获取从创世区块至当前最新区块(即具有最大生成时间戳的区块)中的所有状态数据，以此来对该交易进行合法性校验。例如，出块节点在执行某交易对应的资产转移业务时，需要判断资产转移方是否有足够的额度。此时，该出块节点需要花费较长的时间来读取区块链上的所有状态数据，以至于降低了合法性校验的效率。这样，在区块链上的区块越来越多的情况下，针对于同一个状态数据而言，该状态数据的读取或者写入操作所需要消耗的资源开销将会不断上升，从而造成出块节点的运行负担过重，进而导致该出块节点的启动时间较长。
发明内容
本申请实施例提供一种交易验证方法、装置、设备及存储介质，可以加快出块节点的启动时间。
本申请实施例一方面提供一种交易验证方法，该方法由区块链网络中的出块节点执行，出块节点为区块链网络中的轻量节点，包括：
获取区块链网络中的用户节点发送的待验证交易以及待验证交易对应的交易验证信息；交易验证信息是由区块链网络中的全量节点在执行待验证交易对应的交易业务后所确定的；交易验证信息包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识；区块标识用于指向全量节点的全量区块链上具有最大生成时间戳的目标区块；且目标区块的第一区块头中包含区块标识；
在轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果；
在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到交易业务对应的目标交易执行结果以及待写入状态数据；
基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。
本申请实施例一方面提供一种交易验证方法，该方法由区块链网络中的全量节点执行，包括：
在获取到与区块链网络中的用户节点相关联的待验证交易时，在全量节点的全量区块 链上，将具有最大生成时间戳的区块作为目标区块，且将目标区块的区块头作为第一区块头；
获取目标区块中的默克尔帕特里夏树，基于目标区块中的默克尔帕特里夏树，执行待验证交易对应的交易业务，得到交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合；
获取第一区块头中的区块标识，将初始交易执行结果、状态读取集合、状态写入集合以及区块标识，作为待验证交易对应的交易验证信息；交易验证信息用于指示区块链网络中的出块节点，基于区块头链中的第二区块头中的第一状态快照，对待验证交易进行合法性校验；第二区块头为区块头链中与区块标识相匹配的区块头；出块节点为区块链网络中的轻量节点。
本申请实施例一方面提供一种交易验证装置，包括：
交易获取模块，用于获取区块链网络中的用户节点发送的待验证交易以及待验证交易对应的交易验证信息；交易验证信息是由区块链网络中的全量节点在执行待验证交易对应的交易业务后所确定的；交易验证信息包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识；区块标识用于指向全量节点的全量区块链上具有最大生成时间戳的目标区块；且目标区块的第一区块头中包含区块标识；
集合校验模块，用于在轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果；
目标执行结果确定模块，用于在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到交易业务对应的目标交易执行结果以及待写入状态数据；
合法性校验模块，用于基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。
本申请实施例一方面提供一种交易验证装置，包括：
目标区块确定模块，用于在获取到与区块链网络中的用户节点相关联的待验证交易时，在全量节点的全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将目标区块的区块头作为第一区块头；
初始执行结果确定模块，用于获取目标区块中的默克尔帕特里夏树，基于目标区块中的默克尔帕特里夏树，执行待验证交易对应的交易业务，得到交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合；
验证信息确定模块，用于获取第一区块头中的区块标识，将初始交易执行结果、状态读取集合、状态写入集合以及区块标识，作为待验证交易对应的交易验证信息；交易验证信息用于指示区块链网络中的出块节点，基于区块头链中的第二区块头中的第一状态快照，对待验证交易进行合法性校验；第二区块头为区块头链中与区块标识相匹配的区块头；出块节点为区块链网络中的轻量节点。
本申请实施例一方面提供了一种计算机设备，包括：处理器和存储器；
处理器与存储器相连，其中，存储器用于存储计算机程序，计算机程序被处理器执行 时，使得该计算机设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有该处理器的计算机设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的方法。
在本申请实施例中，区块链网络中的出块节点(即该区块链网络中的轻量节点)在接收到该区块链网络中的用户节点发送的待验证交易的同时，还会一并接收到该区块链网络中的全量节点在执行该待验证交易对应的交易业务后所确定的交易验证信息。其中，这里的交易验证信息可以包括该交易业务对应的初始交易执行结果、状态读取集合、状态写入集合以及区块标识。其中，区块标识可以用于指向全量节点的全量区块链上具有最大生成时间戳的目标区块，且该目标区块的第一区块头中包含该区块标识。基于此，该出块节点无需花费大量的时间，同步从全量区块链的创世区块至目标区块中的所有状态数据，而是直接从出块节点的区块头链中查找与该区块标识相匹配的第二区块头，然后基于该第二区块头的第一状态快照以及交易验证信息，对待验证交易进行合法性校验，从而可以提升合法性校验的效率，进而减轻了出块节点的运行负担，以至于大大加快了出块节点的启动时间。
附图说明
图1是本申请实施例提供的一种区块链网络结构的示意图；
图2是本申请实施例提供的一种进行数据交互的场景示意图；
图3是本申请实施例提供的一种交易验证方法的流程示意图；
图4是本申请实施例提供的一种对交易签名信息进行验签的场景示意图；
图5是本申请实施例提供的一种默克尔帕特里夏树的结构示意图；
图6是本申请实施例提供的一种第一状态数据的第一存在性证明的示意图；
图7是本申请实施例提供的一种第二状态数据的可修改证明的示意图；
图8是本申请实施例提供的一种交易验证方法的流程示意图；
图9是本申请实施例提供的一种交易验证方法的流程示意图；
图10是本申请实施例提供的一种生成待处理区块的场景示意图；
图11是本申请实施例提供的一种交易验证装置的结构示意图；
图12是本申请实施例提供的一种交易验证装置的结构示意图；
图13是本申请实施例提供的一种计算机设备的示意图；
图14是本申请实施例提供的一种数据处理系统的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本 申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参见图1，图1是本申请实施例提供的一种区块链网络结构的示意图。图1所示的区块链网络结构可以应用于区块链系统，该区块链系统可以是由多个区块链节点通过网络通信的形式连接形成的分布式系统。换言之，所有区块链节点之间可以相互建立点对点或者端对端(peer to peer，简称P2P)连接，以形成P2P网络(即图1所示的区块链网络)。
其中，这里的区块链节点可以为接入该区块链网络中的任意形式的计算机设备，比如，该计算机设备可以为接入该区块链网络中的用户终端，也可以为接入该区块链网络中的服务器，这里对区块链节点的具体形式不做限定。可以理解的是，这里的用户终端可以包括智能手机、平板电脑、笔记本电脑、桌上型电脑等具有数据处理功能的智能终端。该用户终端中可以安装有目标应用(即应用客户端)，当该应用客户端运行于用户终端中时，可以与上述图1所示的区块链网络中的其他区块链节点之间进行数据交互。其中，该应用客户端可以包含社交客户端、多媒体客户端(例如，视频客户端)、娱乐客户端(例如，游戏客户端)、教育客户端、直播客户端等应用客户端。其中，该应用客户端可以为独立的客户端，也可以为集成在某客户端(例如，社交客户端、教育客户端以及多媒体客户端等)中的嵌入式子客户端，在此不做限定。这里的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。
如图1所示，该区块链网络中可以包括三种类型的区块链节点，具体可以包括全量节点、出块节点以及用户节点。其中，全量节点是指用于存储完整区块数据的区块链节点，本申请实施例可以将该全量节点的区块链称之为全量区块链，该全量区块链中的每个区块均可以包括区块头以及区块体。其中，该区块头中可以包括用于判断状态数据的完整性的状态快照、当前区块的区块标识(例如，区块块高或者区块哈希值)、父区块哈希值以及生成时间戳等。该区块体中可以包括默克尔帕特里夏树(Merkle Patricia Tree，简称MPT)，该默克尔帕特里夏树中的叶子节点(即数据节点)中可以存储有具体的状态数据。这意味着该全量节点的全量区块链需要保留所有账户的完整的状态数据。
应当理解，本申请实施例中的出块节点是指用于生成新区块头的区块链节点，为了大大减少存储空间的消耗，该出块节点可以为区块链网络中的轻量节点(Simplified Payment Verification，简称SPV节点)。这里的轻量节点是指用于存储区块数据中的区块头信息，而不需要存储完整区块数据的区块链节点。换言之，本申请实施例可以将出块节点的区块链称之为区块头链(即轻量区块链)，该区块头链可以为由多个区块头首尾连接而成的链型结构。这意味着该出块节点的区块头链可以保留用于判断状态数据的完整性的状态快照，而不需要保留所有账户的完整的状态数据。
其中，本申请实施例中的用户节点是指部署在用户侧，由用户控制的区块链节点。可以理解的是，该用户节点可以单独部署在某一个计算机设备，用于为用户组装待验证交易(例如，交易1)。该用户节点可以与区块链网络中的全量节点(该全量节点部署在与用户 节点不同的计算机设备上)进行交互。例如，用户节点可以将该交易1发送至全量节点，以使全量节点模拟执行该交易1对应的交易业务，且接收该全量节点在执行该交易1对应的交易业务之后得到的交易验证信息。此外，该用户节点还可以与区块链网络中的出块节点进行交互。例如，该用户节点可以将全量节点发送的交易验证信息以及用户节点自身组装的待验证交易(即交易1)一并发送至出块节点，以使出块节点基于接收到的交易验证信息对该交易1进行合法性校验。可选的，该用户节点还可以和该区块链网络中的全量节点共同部署在同一个计算机设备。这意味着该用户节点将会具备全量节点所具备的节点功能，即存储完整区块数据。因此，用户节点在为用户组装待验证交易(例如，交易2)之后，可以直接执行该交易2对应的交易业务，以得到该交易2对应的交易验证信息。此时，该用户节点可以直接将交易2和交易2对应的交易验证信息一并发送至出块节点，以使出块节点基于接收到的交易验证信息对该交易2进行合法性校验。
由此可见，本申请实施例中的出块节点在接收到区块链网络中的用户节点发送的待验证交易时，可以一并接收到该待验证交易对应的交易验证信息。因此，在出块节点对待验证交易进行合法性校验时，无需获取存储在全量区块链的所有状态数据，而是根据接收到的该待交易验证信息，对该待验证交易进行合法性校验。其中，这里的交易验证信息可以包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识。该区块标识用于指向全量节点的全量区块链上的具有最大生成时间戳的目标区块，该目标区块的第一区块头中包含该区块标识。因此，在对待验证交易进行校验的过程中可以包括以下校验：首先出块节点可以在区块头链中查找到与区块标识相匹配的区块头(即第二区块头)时，可以获取第二区块头中的第一状态快照，进而可以基于该第一状态快照校验交易验证信息中的两个集合(即状态读取集合和状态写入集合)，得到第一校验结果。在第一校验结果指示校验成功时，出块节点可以基于状态读取集合执行待验证交易对应的交易业务，得到目标交易执行结果和待写入状态数据。然后，该出块节点可以基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。这意味着出块节点不需要花费时间来读取全量区块链上的所有状态数据，而是直接根据接收到的交易验证信息，对待验证交易进行合法性校验，以至于减轻了出块节点的运行负担，进而大大加快了出块节点的启动时间。
为便于理解，进一步地，请参见图2，图2是本申请实施例提供的一种进行数据交互的场景示意图。如图2所示，用户节点20A可以为上述图1所示的区块链网络中的用户节点，该用户节点20A可以用于为用户组装待验证交易。本申请实施例中的全量节点20B可以为上述图1所示的区块链网络中的全量节点，该全量节点20B可以存储有所有账户的完整的状态数据。本申请实施例中的出块节点20C可以为上述图1所示的区块链网络中的出块节点，该出块节点20C可以为能够收集当前区块链网络中的待验证交易，以进行合法性校验的轻量节点。
应当理解，本申请实施例中的待验证交易可以包括但不限于资产转移交易(例如，抵押、借贷、虚拟资产流转等业务场景下的交易)以及合同签订交易。其中，这里的虚拟资产可以是指游戏币、游戏钻石、游戏装备以及电子票据等。例如，在虚拟资产流转场景中， 用户节点20A对应的用户(例如，用户1)的账户余额中有10个游戏币，当该用户1需要将某笔虚拟资产(例如，3个游戏币)转移到另一用户(例如，用户2)的账户上时，用户1可以针对该用户节点20A执行触发操作，以使用户节点20A可以响应该触发操作，为该用户1组装交易(例如，图2所示的交易2x)。其中，这里的触发操作可以包括点击、长按等接触性操作，也可以包括语音、手势等非接触性操作，这里将不对其进行限定。
进一步地，该用户节点20A可以将该交易2x作为待验证交易，进而可以将该交易2x发送至图2所示的全量节点20B，以使该全量节点20B可以执行该交易2x对应的交易业务，从而得到该交易2x对应的交易验证信息(例如，图2所示的交易验证信息2y)。其中，该全量节点20B的全量区块链可以为图2所示的区块链2a，该区块链2a中可以包括多个具有完整区块数据的区块，本申请实施例可以以100个区块为例，具体可以包括区块1g、区块2g、…、区块99g以及区块100g，该区块1g可以称之为该区块链2a的创世区块。其中，区块链2a中的每个区块均可以包括区块头和区块体，例如，区块1g中可以包括区块头1和区块体。
其中，可以理解的是，该全量节点20B在接收到该交易2x时，可以在区块链2a上，将具有最大生成时间戳的区块(例如，图2所示的区块100g)作为目标区块，进而可以将该区块100g中的区块头100作为第一区块头。进一步地，该全量节点20B可以获取区块100g中的默克尔帕特里夏树(例如，图2所示的默克尔帕特里夏树2m)，基于该默克尔帕特里夏树2m，模拟执行交易2x对应的交易业务，以得到该交易业务对应的交易执行结果(即初始交易执行结果)，状态读取集合以及状态写入集合。此时，该全量节点20B可以获取第一区块头中的区块标识，进而可以将初始交易执行结果、状态读取集合、状态写入集合以及区块标识，作为该交易2x对应的交易验证信息2y。其中，这里的区块标识可以是指该目标区块(例如，区块100g)的区块块高，也可以是指该目标区块的区块哈希值，在此不做限定。
应当理解，该全量节点20B可以将交易验证信息2y返回至该用户节点20A。进一步地，该用户节点20A可以将自身生成的交易2x和全量节点20B返回的交易验证信息2y一并发送至图2所示的出块节点20C，以使该出块节点20C基于该交易验证信息2y对交易2x进行合法性校验，从而可以确定交易2x的合法性。其中，该出块节点20C的轻量区块链(即区块头链)可以为图2所示的区块头链2b，该区块头链2b是由多个区块头首尾相连而构成的，本申请实施例可以以100个区块头为例，具体可以包括区块头1、区块头2、…、区块头99以及区块头100。每个区块头中均可以包括用于判断当前区块的所有状态数据的完整性的状态快照。
其中，可以理解的是，出块节点20C在接收到用户节点20A发送的交易2x和交易验证信息2y时，可以在图2所示的区块头链2b中，查找与该第一区块头中的区块标识相匹配的区块头(例如，区块头链2b中的区块头100)，且将查找到的区块头作为第二区块头，进而可以基于该第二区块头中的状态快照(即第一状态快照)，对交易验证信息2y中的状态读取集合以及状态写入集合进行校验，得到交易2x的第一校验结果，以确定该交易2x对应的交易业务能否被出块节点20C执行。在第一校验结果指示校验失败时，该出块节点20C可以确定该交易2x对应的交易业务无法被出块节点20C执行，即该交易2x不具备合法性。可选的，在第一校验结果指示校验成功时，该出块节点20C可以确定该交易2x对应的交易业务能够被执行，此时，该出块节点20C可以基于该状态读取集合，执行交易2x对应的交易业务，得到该交易 业务对应的目标交易执行结果以及待写入状态数据(例如，7个游戏币)。进一步地，该出块节点20C可以根据初始交易执行结果、状态写入集合、目标交易执行结果和待写入状态数据，对交易2x继续进行合法性校验。
其中，若初始交易执行结果与目标交易执行结果一致，状态写入集合中的第二状态数据的存在性证明(即第二存在性证明)合法，且第二状态数据与待写入状态数据一致，则该出块节点20C可以确定交易2x具备合法性。可选的，若初始交易执行结果与目标交易执行结果不一致，或者状态写入集合中的第二状态数据的第二存在性证明不合法，或者第二状态数据与待写入状态数据不一致，则该出块节点20C可以确定该交易2x不具备合法性。
由此可见，本申请实施例中的出块节点20C在校验交易2x时，无需从区块链2a上同步所有账户的状态数据，而是根据接收到交易验证信息2y(即全量节点20B在接收到交易2x时，模拟执行交易2x对应的交易业务后得到的交易验证信息)，直接对交易2x进行合法性校验，以至于减轻了出块节点20C的运行负担，进而大大加快了出块节点20C的启动时间。
其中，区块链网络中的出块节点基于获取到的交易验证信息，对待验证交易进行合法性校验的具体实现方式可以参见下述图3-图10所对应的实施例。
进一步地，请参见图3，图3是本申请实施例提供的一种交易验证方法的流程示意图。如图3所示，该方法可以由区块链网络中的出块节点执行，该出块节点可以为接入至该区块链网络的用户终端，也可以为接入至该区块链网络中的服务器，在此不做限定。为便于理解，本申请实施例以该方法由用户终端执行为例进行说明，该方法至少可以包括以下S101-S104：
S101，获取区块链网络中的用户节点发送的待验证交易以及待验证交易对应的交易验证信息。
具体地，区块链网络中的出块节点可以获取到该区块链网络中的用户节点发送的待验证交易以及待验证交易对应的交易验证信息。其中，这里的待验证交易可以为用户节点在响应用户的触发操作(例如，点击操作)时所生成的交易。这里的交易验证信息可以为区块链网络中的全量节点在接收到用户节点发送的待验证交易时，执行该待验证交易对应的交易业务后所得到的验证信息。其中，这里的用户节点与全量节点可以共同部署在同一计算机设备，也可以部署在不同的计算机设备，这里将不对其进行限定。本申请实施例可以以用户节点和全量节点部署在不同的计算机设备这种情况为例，用以阐述出块节点对待验证交易信息的合法性校验。
可以理解的是，区块链网络中的用户节点对应的用户(例如，第一用户)可以针对某一交易业务，执行触发操作(例如，点击操作)。比如，该交易业务可以为将第一用户的电子票据转移至另一用户(例如，第二用户)的业务。此时，该用户节点可以响应该触发操作，以生成用于广播至区块链网络的待验证交易。与此同时，为了有效保证待验证交易在区块链网络传输时的真实性和安全性，该用户节点可以基于用户私钥(即第一用户的私钥)，对该待验证交易进行签名处理，得到该待验证交易的交易签名信息。进一步地，该用户节点可以将该待验证交易以及交易签名信息一并发送至该区块链网络中的全量节点。应当理解，全量节点在获取到该待验证交易对应的交易签名信息时，可以获取用户私钥对应的用 户公钥(即第一用户的公钥)，进而可以基于该用户公钥对交易签名信息进行验签，以得到验签结果。
为便于理解，进一步地，请参见图4，图4是本申请实施例提供的一种对交易签名信息进行验签的场景示意图。如图4所示，本申请实施例中的用户节点40A可以为区块链网络中的由用户控制的区块链节点，例如，该用户节点40A可以为上述图2所示的用户节点20A。本申请实施例中的全量节点40B可以为区块链网络中的具有保存完整区块数据功能的区块链节点，例如，该全量节点40B可以为上述图2所示的全量节点20B。
应当理解，图4所示的用户节点40A在响应用户节点40A对应的用户(例如，用户1)的触发操作时，可以生成用于广播至区块链网络中的待验证交易(例如，图4所示的交易4x)。此时，该用户节点40A可以基于该用户1的用户私钥，对该交易4x进行签名处理，得到该交易4x对应的交易签名信息。其中，可以理解的是，该用户节点40A可以获取针对待验证交易的哈希计算规则，该哈希计算规则可以为该用户节点40A与区块链网络中的其他区块节点(例如，全量节点40B)提前约定好的摘要算法。因此，该用户节点40A可以基于该哈希计算规则对该交易4x进行哈希计算，以得到交易4x的摘要信息(例如，摘要信息h)。其中，本申请实施例可以将用户节点40A确定的交易4x的摘要信息称之为第一摘要信息。进一步地，该用户节点40A可以基于该用户1的用户私钥，对该第一摘要信息进行签名处理，从而可以得到图4所示的交易签名信息。
进一步地，该用户节点40A可以将交易4x和交易签名信息一并发送至图4所示的全量节点40B，以使该全量节点40B基于用户私钥对应的用户公钥(即用户1的用户公钥)，对交易签名信息进行验签，得到验签结果。其中，可以理解的是，全量节点40B可以获取用户1的用户公钥，进而可以基于该用户公钥对交易签名信息进行验签，得到交易4x的第一摘要信息。与此同时，该全量节点40B还可以获取与用户节点40A相同的哈希计算规则，对交易4x进行哈希计算，从而可以得到该交易4x的摘要信息(例如，摘要信息H)。其中，本申请实施例可以将全量节点40B确定的交易4x的摘要信息称之为第二摘要信息。
此时，该全量节点40B可以将第一摘要信息与第二摘要信息进行比对，得到验签结果，以确定该交易4x是否被篡改。可以理解的是，若第一摘要信息与第二摘要信息不相同，则该全量节点40B可以确定验签结果指示验签失败。可选的，若第一摘要信息与第二摘要信息相同，则该全量节点40B可以确定验签结果指示验签成功，这意味着交易4x未发生篡改，且该交易4x确实是由用户节点40A发送的。
应当理解，在验签结果指示验签成功时，本申请实施例中的全量节点可以在全量节点的全量区块链上，获取具有最大生成时间戳的区块(例如，图2所示的区块链2a中的区块100g)，进而可以将获取到的区块作为目标区块，且将该目标区块的区块头作为第一区块头。进一步地，该全量节点可以获取该目标区块中的默克尔帕特里夏树，基于获取到的默克尔帕特里夏树，执行待验证交易对应的交易业务，以确定待验证交易信息对应的交易验证信息。
其中，本申请实施例中的出块节点的区块头链(即轻量区块链)的区块头中，保留有用于判断状态数据的完整性的状态快照。可以理解的是，某一区块头的状态快照可以表示 对应区块的所有状态数据的固定长度，若当前区块的状态数据发生变化，则状态快照会随之变化，以此可以判断所有状态数据的完整性。这里的状态数据即代表了当前区块链网络的状态数据。比如，对于以太坊区块链网络而言，这里的状态数据可以包括某个用户的账户余额、已经发出的未确认交易；某个合约的代码、其内部的存储项的值；一些与共识机制运行相关的数据等。
本申请实施例中的全量节点存储的全量区块链的区块中，不仅保留有用于判断状态数据的完整性的状态快照，还保留有所有账户的完整的状态数据。可以理解的是，该全量区块链中的每个区块均可以包括区块头信息以及区块体信息。区块头信息可以包括状态快照，区块体信息可以包括默克尔帕特里夏树。默克尔帕特里夏树可以具有以下功能：存储任意长度的key-value键值对数据、提供一种快速计算所维护数据集哈希标识的机制、提供一种快速状态回滚的机制、以及提供一种称为默克尔证明的证明方法，进行轻量节点的扩展，实现简单支付验证。
其中，默克尔帕特里夏树(即MPT)是一种组织数据的树形结构，包括数据节点、拓展节点以及分支节点这三种类型的节点。应当理解，这里的数据节点是指树形结构的叶子节点，出现在MPT底部，用于存储具体的状态数据；这里的拓展节点是指具有一个子节点的父节点，可以包含一个任意长度字符串(key)，和一个指向子节点的哈希指针；这里的分支节点是指具有1至16个子节点的父节点，有一个容量为16的哈希值数组，数组中的这16个位置的字符分别对应16进制下的0-9，a-f，并且分别有可能作为哈希指针而指向一个子节点。这16个字符具体可以包括字符“0”，字符“1”，字符“2”，字符“3”，字符“4”，字符“5”，字符“6”，字符“7”，字符“8”，字符“9”，字符“a”，字符“b”，字符“c”，字符“d”，字符“e”以及字符“f”。应当理解，本申请实施例可以将子节点指向父节点的索引关系称之为第一节点索引关系，例如，默克尔帕特里夏树中所指示的自底向上的索引关系。本申请实施例还可以将父节点指向子节点的索引关系称之为第二节点索引关系，例如，默克尔帕特里夏树中所指示的自顶向下的索引关系。
为便于理解，进一步地，请参见图5，图5是本申请实施例提供的一种默克尔帕特里夏树的结构示意图。如图5所示，本申请实施例中的默克尔帕特里夏树5m可以为区块链网络中的全量区块链的某一区块所存储的默克尔帕特里夏树。例如，该默克尔帕特里夏树5m可以为全量节点获取到的目标区块中的默克尔帕特里夏树(例如，上述图2所示的区块链2a的区块100g中的默克尔帕特里夏树2m)。
为便于理解，进一步地，请参见表1，表1是本申请实施例提供一种与当前区块链网络相关联的状态数据。如表1所示：
表1
  key value
状态数据1 ab567cd 100
状态数据2 abc1235 fenghm
状态数据3 abc12b5 12.34
其中，每个状态数据均是以(key，value)键值对的方式进行存储。表1所示的key是指状态数据的关键字符串，value是指状态数据的具体值。本申请实施例中的状态数据的数量可以包括多个，这里以3个为例，具体可以包括状态数据1、状态数据2以及状态数据3。比如，该状态数据1的关键字符串可以为“ab567cd”，且该状态数据1的具体值可以为100；该状态数据2的关键字符串可以为“abc1235”，且该状态数据2的具体值可以为fenghm；该状态数据3的关键字符串可以为“abc12b5”，且该状态数据3的具体值可以为12.34。
可以理解的是，本申请实施例中的全量节点可以对上述表1所示的状态数据进行组织，从而构建如图5所示的默克尔帕特里夏树5m。如图5所示，该默克尔帕特里夏树5m可以包括树根节点(例如，拓展节点10Z)、中间节点(例如，分支节点10F、拓展节点20Z、拓展节点30Z、分支节点20F、拓展节点40Z以及拓展节点50Z)和叶子节点(例如，数据节点10S、数据节点20S以及数据节点30S)。
其中，该默克尔帕特里夏树5m的树根节点的树根哈希值可以作为该默克尔帕特里夏树5m所在区块的状态快照。比如，若该默克尔帕特里夏树5m为上述图2所示的区块链2a的区块100g中存储的默克尔帕特里夏树2m，则该树根哈希值可以作为图2所示的区块100g中的区块头100的状态快照，该状态快照可以用于判断图2所示的区块100g中的所有状态数据的完整性。基于此，图2所示的区块头链2b中的区块头100(即第二区块头)的状态快照也可以为该默克尔帕特里夏树5m的树根哈希值。
应当理解，该默克尔帕特里夏树5m中的每个节点的哈希指针均可以用于指向对应子节点的子节点哈希值。例如，该拓展节点10Z中可以包括一个任意长度的字符串(例如，“ab”)、以及一个用于指向子节点的哈希指针。其中，该哈希指针可以用于指向该拓展节点10Z的子节点(例如，图5所示的分支节点10F)。基于此，上述表1所示的每个状态数据中的关键字符串可以对应一条从默克尔帕特里夏树5m中的树根节点到相应数据节点的真实节点路径。
其中，对于用于存储状态数据1(例如，100)的数据节点10S而言，与该数据节点10S相关联的节点路径1可以为：拓展节点10Z的哈希指针指向分支节点10F，分支节点10F中的字符“5”的哈希指针指向拓展节点20Z；该拓展节点20Z的哈希指针指向数据节点10S。
对于用于存储状态数据2(例如，fenghm)的数据节点20S而言，与该数据节点20S相关联的节点路径2可以为：拓展节点10Z的哈希指针指向分支节点10F，分支节点10F中的字符“c”的哈希指针指向拓展节点30Z；该拓展节点30Z的哈希指针指向分支节点20F；该分支节点20F中的字符“3”的哈希指针指向拓展节点40Z；该拓展节点40Z的哈希指针指向数据节点20S。
对于用于存储状态数据3(例如，12.34)的数据节点30S而言，与该数据节点30S相关 联的节点路径3可以为：拓展节点10Z的哈希指针指向分支节点10F，分支节点10F中的字符“c”的哈希指针指向拓展节点30Z；该拓展节点30Z的哈希指针指向分支节点20F；该分支节点20F中的字符“b”的哈希指针指向拓展节点50Z；该拓展节点50Z的哈希指针指向数据节点20S。
应当理解，本申请实施例中的全量节点可以获取目标区块中的默克尔帕特里夏树，进而可以基于获取到的默克尔帕特里夏树，执行该待验证交易对应的交易业务，得到该交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合。
其中，可以理解的是，该全量节点可以获取目标区块中的默克尔帕特里夏树，将获取到的默克尔帕特里夏树作为待处理树，进而可以从该待处理树中，读取与待验证交易相关联的状态数据，且将读取到的状态数据作为第一状态数据。进一步地，该全量节点可以基于该第一状态数据，执行待验证交易对应的交易业务，以得到交易业务对应的初始交易执行结果，且在执行交易业务的过程中，记录模拟写入目标区块的下一区块的状态数据，将记录到的状态数据作为第二状态数据。其中，这里的初始交易执行结果可以为交易执行成功或者交易执行失败这种交易执行结果。
比如，若全量节点接收到的该待验证交易所对应的交易业务为：从区块链网络中的用户节点对应的用户(例如，用户1)的账户中，向另一用户(例如，用户2)转移10个游戏币，那么，该全量节点读取的第一状态数据可以为图5所示的默克尔帕特里夏树5m中的数据节点10S所存储的状态数据1(例如，100)，即用户1的账户余额中有100个游戏币。该全量节点在基于这100个游戏币执行待验证交易对应的交易业务的过程中，记录到的需要写入目标区块的下一区块的状态数据(即第二状态数据)可以为90，这意味着全量节点模拟执行交易业务后，用户1的账户余额中还包括90个游戏币。
进一步地，该全量节点可以基于该待处理树，收集第一状态数据的第一存在性证明，进而可以基于第一存在性证明生成状态读取集合，进而可以基于第一存在性证明生成状态读取集合。应当理解，全量节点在执行交易业务时，读取到的与该待验证交易相关联的第一状态数据的数量可以包括一个或者多个，基于此，全量节点可以基于收集到的所有第一存在性证明，生成状态读取集合。
如图5所示，该全量节点可以将上述图5所示的默克尔帕特里夏树5m作为待处理树，进而可以在默克尔帕特里夏树5m中查找到用于存储第一状态数据的数据节点(例如，用于100这一状态数据1的数据节点10S)。此时，该全量节点可以基于默克尔帕特里夏树5m，获取与数据节点10S相关联的节点路径(例如，节点路径1)。其中，该节点路径可以包括数据节点10S、拓展节点20Z、分支节点10F以及拓展节点10Z。进一步地，该全量节点可以将获取到的节点路径作为该第一状态数据的第一存在性证明，此处可以一并参见图6，图6是本申请实施例提供的一种第一状态数据的第一存在性证明的示意图。其中，图6所示的存在性证明6p即为区块链网络中的全量节点所收集到的第一状态数据的第一存在性证明。
与此同时，本申请实施例中的全量节点还可以基于待处理树，收集该第二状态数据的可修改证明和第二存在性证明，进而可以基于可修改证明和第二存在性证明生成状态写入集合。
其中，可以理解的是，在将该第二状态数据插入到待处理树之前，该全量节点可以获取与该第二状态数据相关联的关键字符串，进而可以基于关键字符串获取第二状态数据的可修改证明。换言之，在将第二状态数据插入到待处理树之前，该全量节点可以获取与第二状态数据相关联的关键字符串，进而可以获取待处理树所指示的第二节点索引关系(例如，自顶向下的索引关系)。进一步地，该全量节点可以基于该第二节点索引关系，从树根节点开始遍历查找与关键字符串具有相同前缀的字符。此时，该全量节点可以基于查找到的所有字符，得到待处理字符串，获取与待处理字符串相关联的存在性证明，且将获取到的存在性证明作为第二状态数据的可修改证明。
如图5所示，该全量节点确定的待处理树可以为图5所示的默克尔帕特里夏树5m，在将该第二状态数据插入到该默克尔帕特里夏树5m之前，该全量节点可以获取与第二状态数据(例如，90)相关联的关键字符串，进而可以获取默克尔帕特里夏树5m所指示的第二节点索引关系(例如，自顶向下的索引关系)。进一步地，该全量节点可以基于该第二节点索引关系，从树根节点(例如，图5所示的拓展节点10Z)开始遍历查找与关键字符串具有相同前缀的字符。此时，该全量节点可以基于查找到的所有字符，得到待处理字符串。
例如，若该第二状态数据(例如，90)的关键字符串为“ab567cd”，则该全量节点在图5所示的默克尔帕特里夏树5m中，可以查找到与关键字符串相匹配的所有字符，即该全量节点确定的待处理字符串(例如，待处理字符串1)为“ab567cd”。此时，该全量节点可以获取与该待处理字符串1中的字符相关联的节点，即用于存储字符“ab”的拓展节点10Z、用于存储字符“5”的分支节点10F、用于存储字符“67cd”的拓展节点20Z、以及该拓展节点20Z的哈希指针所指示的数据节点10S。换言之，该全量节点可以直接将数据节点10S的存在性证明(例如，上述图6所示的存在性证明6p)作为与该待处理字符串1相关联的存在性证明，进而可以将与该待处理字符串1相关联的存在性证明作为该第二状态数据的可修改证明。
可选的，若该第二状态数据(例如，90)的关键字符串为“abc5678”，则该全量节点在图5所示的默克尔帕特里夏树5m中，可以查找到与关键字符串相匹配的部分字符，即该全量节点确定的待处理字符串(例如，待处理字符串2)为“abc”。此时，该全量节点可以获取与该待处理字符串2中的字符相关联的节点，即用于存储字符“ab”的拓展节点10Z和用于存储字符“c”的分支节点10F。进一步地，该全量节点可以基于获取到的这两个节点，得到与该待处理字符串2相关联的存在性证明，进而可以将与该待处理字符串2相关联的存在性证明作为该第二状态数据的可修改证明，此处可以一并参见图7，图7是本申请实施例提供的一种第二状态数据的可修改证明的示意图。其中，图7所示的可修改证明7q即为区块链网络中的全量节点所收集到的第二状态数据的可修改证明。
进一步地，在将第二状态数据插入到待处理树之后，该全量节点可以获取第二状态数据的存在性证明，进而可以将第二状态数据的存在性证明作为第二存在性证明。其中，全量节点获取第二状态数据的第二存在性证明的具体实施方式，可以参见上述获取第一状态数据的第一存在性证明的具体实施方式，这里将不再继续进行赘述。此时，该全量节点可以基于可修改证明和第二存在性证明，生成状态写入集合。
应当理解，该全量节点还可以获取目标区块的第一区块头中的区块标识，进而可以将执行交易业务得到的初始交易执行结果、生成的状态读取集合和状态写入集合、以及获取到的区块标识，作为待验证交易对应的交易验证信息。进一步地，该全量节点可以将该交易验证信息发送至区块链网络中的用户节点，以使该用户节点可以将该交易验证信息以及待验证交易一并发送至区块链网络中的出块节点。其中，可以理解的是，该用户节点还可以将交易签名信息也发送至出块节点，以使出块节点对待验证交易进行验签，从而可以有效确保待验证交易传输时的安全性和真实性。
S102，在轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果。
其中，状态读取集合和状态写入集合是区块链网络中的全量节点基于目标区块中的默克尔帕特里夏树所生成的。具体地，该区块链网络中的出块节点(即区块链网络中的轻量节点)可以从该轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，进而可以将查找到的区块头作为第二区块头，且将第二区块头中的状态快照作为第一状态快照。与此同时，该出块节点还可以从交易验证信息包括的状态读取集合中，获取第一状态数据的第一存在性证明，进而可以基于第一状态快照，对第一存在性证明进行校验，以得到第一证明校验结果。其中，这里的第一状态数据可以为全量节点在目标区块的默克尔帕特里夏树上，读取到的与待验证交易相关联的状态数据。此外，该出块节点还可以从交易验证信息包括的状态写入集合中，获取第二状态数据的可修改证明，进而可以基于第一状态快照，对可修改证明进行校验，以得到第二证明校验结果。其中，这里的第二状态数据可以为全量节点在执行交易业务的过程中，记录到的模拟写入目标区块的下一区块的状态数据。进一步地，该出块节点可以基于第一证明校验结果和第二证明校验结果，确定待验证交易的第一校验结果。
如图2所示，本申请实施例中的出块节点20C可以从区块头链2b中获取与第一区块头(即区块链2a的区块100g中的区块头100)中的区块标识相匹配的区块头，进而可以将获取到的区块头作为第二区块头(即区块头链2b中的区块头100)。进一步地，该出块节点20C可以获取第二区块头中的状态快照，且将获取到的状态快照作为第一状态快照。
应当理解，区块链网络中的出块节点可以从状态读取集合中获取第一状态数据的第一存在性证明。其中，该第一存在性证明可以为全量节点从目标区块中的默克尔帕特里夏树中，获取到的与第一状态数据相关联的节点路径。该节点路径可以包含叶子节点和树根节点。进一步地，该出块节点可以获取节点路径所指示的第一节点索引关系(例如，自底向上的索引关系)，进而可以基于该第一节点索引关系，将叶子节点作为子节点，且将叶子节点的上一节点作为该子节点的父节点，进而可以将子节点的子节点哈希值与父节点的哈希指针进行比对，从而可以得到初始比对结果。若初始比对结果指示比对成功，则该出块节点可以基于第一节点索引关系，更新子节点以及父节点，直到更新后的父节点为树根节点时，得到第一存在性证明的第一比对结果。与此同时，该出块节点还可以将树根节点的树根哈希值与第一状态快照进行比对，得到第一存在性证明的第二比对结果，进而可以基于 第一比对结果和第二比对结果，得到第一证明校验结果。其中，本申请实施例中的出块节点可以先遍历比对子节点哈希值与父节点的哈希指针，再比对树根节点的树根哈希值与第一状态快照。可选的，该出块节点还可以先比对树根节点的树根哈希值与第一状态快照，再遍历比对子节点哈希值与父节点的哈希指针，这里将不对比对的先后顺序进行限定。
如图6所示，区块链网络中的出块节点从状态读取集合中获取到的第一状态数据的第一存在性证明可以为图6所示的存在性证明6p。其中，存在性证明6p可以为全量节点从目标区块中的默克尔帕特里夏树中，获取到的与第一状态数据(例如，100)相关联的节点路径，这里的节点路径可以包括叶子节点(例如，用于存储第一状态数据的数据节点10S)、中间节点(例如，拓展节点20Z以及分支节点10F)、树根节点(例如，拓展节点10Z)。
本申请实施例中的出块节点可以基于该节点路径指示的第一节点索引关系，将数据节点10S作为子节点，且将数据节点10S的上一节点(即拓展节点20Z)作为父节点。进一步地，该出块节点可以获取数据节点10S的节点哈希值，且将该数据节点10S的节点哈希值作为子节点哈希值。此时，该出块节点可以将数据节点10S的节点哈希值与拓展节点20Z的哈希指针(例如，0x936e…)进行比对，从而可以得到初始比对结果。
若数据节点10S的节点哈希值与拓展节点20Z的哈希指针不一致，则出块节点可以确定初始比对结果指示比对失败，此时，该出块节点可以直接确定该待验证交易不具备合法性。
可选的，若数据节点10S的节点哈希值与拓展节点20Z的哈希指针一致，则出块节点可以确定初始比对结果指示比对成功，此时，该出块节点可以基于第一节点索引关系更新子节点以及父节点。换言之，该出块节点可以将拓展节点20Z作为新的子节点(即第一更新子节点)，且将拓展节点20Z的上一节点(例如，分支节点10F)作为该第一更新子节点的父节点(即第一更新父节点)，进而可以将拓展节点20Z的节点哈希值与分支节点10F中字符“5”的哈希指针(例如，0xa15c…)进行比对，得到新的初始比对结果(即第一更新比对结果)。在新的初始比对结果指示成功时，该出块节点可以继续更新子节点和父节点，即将分支节点10F作为最新的子节点(即第二更新子节点)，将分支节点10F的上一节点(例如，拓展节点10Z)作为该第二更新子节点的父节点(即第二更新父节点)，进而可以将分支节点10F的节点哈希值与拓展节点10Z的哈希指针(例如，0x5f90…)进行比对，得到最新的初始比对结果(即第二更新比对结果)。可以理解的是，当第二更新父节点为拓展节点10Z(即默克尔帕特里夏树的树根节点)时，该出块节点可以结束更新，进而可以将最新的初始比对结果作为该存在性证明6p的第一比对结果。
进一步地，该出块节点可以获取拓展节点10Z的节点哈希值(即树根哈希值)，将该拓展节点10Z的节点哈希值与第一状态快照进行比对，得到存在性证明6p的第二比对结果。
可以理解的是，若第一比对结果指示比对失败，且第二比对结果指示树根哈希值与第一状态快照不一致，则该出块节点可以确定第一证明校验结果指示校验失败，此时，该出块节点可以直接确定该待验证交易不具备合法性。可选的，若第一比对结果指示比对成功，且第二比对结果指示树根哈希值与第一状态快照一致，则该出块节点可以确定第一证明校验结果指示校验成功。此时，该出块节点可以继续从交易验证信息包括的状态写入集合中，获取第二状态数据的可修改证明，进而可以基于第一状态快照，对可修改证明进行校验， 以得到第二证明校验结果。其中，该出块节点确定第二证明校验结果的具体实施方式可以参见上述确定第一证明校验结果的具体实施方式，这里将不再继续进行赘述。
此时，该出块节点可以基于第一证明校验结果和第二证明校验结果，确定待验证交易的第一校验结果。应当理解，在第一证明校验结果指示校验失败，或者第二证明校验结果指示校验失败时，该出块节点可以确定待验证交易的第一校验结果指示校验失败，此时，该出块节点可以确定该待验证交易不具备合法性。可选的，在第一证明校验结果和第二证明校验结果均指示校验成功时，该出块节点可以确定待验证交易的第一校验结果指示校验成功，进而可以执行下述S103，继续对待验证交易进行合法性交易。
S103，在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到交易业务对应的目标交易执行结果以及待写入状态数据。
具体地，在第一校验结果指示校验成功时，出块节点可以从状态读取集合中的第一存在性证明中获取第一状态数据，进而可以基于该第一状态数据，执行该交易业务，以得到交易业务对应的交易执行结果。此时，本申请实施例可以将出块节点执行交易业务后得到的交易执行结果称之为目标交易执行结果。应当理解，该出块节点可以在执行交易业务的过程中，记录需要写入目标区块的下一区块的状态数据。其中，本申请实施例可以将出块节点记录的需要写入目标区块的下一区块的状态数据称之为待写入状态数据。
比如，若出块节点接收到的用户节点发送的待验证交易所对应的交易业务为：从区块链网络中的用户节点对应的用户(例如，用户1)的账户中，向另一用户(例如，用户2)转移10个游戏币，那么，该出块节点可以基于状态读取集合中的第一状态数据(例如，100)，执行该待验证交易对应的交易业务，以得到目标交易执行结果。此外，该出块节点在交易业务执行的过程中记录到的需要写入目标区块的下一区块的状态数据可以为90。这意味着在出块节点执行待验证交易对应的交易业务之后，用户1的账户余额将由100个游戏币更新为90个游戏币。
S104，基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。
具体地，该出块节点可以将初始交易执行结果和目标交易执行结果进行比对，得到第三比对结果。与此同时，该出块节点还可以从状态写入集合中获取第二状态数据的第二存在性证明，进而可以基于第二区块头中的第一状态快照，对第二存在性证明进行校验。在校验成功时，该出块节点可以将第二状态数据与待写入状态数据进行比对，得到第四比对结果。此时，该出块节点可以基于第三比对结果和第四比对结果，得到待验证交易的第二校验结果，且基于第二校验结果，对待验证交易进行合法性校验。
可以理解的是，本申请实施例中的出块节点可以先比对初始交易执行结果和目标交易执行结果，再校验第二存在性证明以及比对第二状态数据和待写入状态数据。其中，若第三比对结果指示初始交易执行结果与目标交易执行结果不一致，则出块节点可以确定第三比对结果指示比对失败，即待验证交易不具备合法性。可选的，若第三比对结果指示初始交易执行结果和目标交易执行结果一致，则该出块节点可以确定第三比对结果指示比对成功，进而可以继续基于第一状态快照，对该状态写入集合中的第二存在性证明进行校验。 其中，出块节点校验第二存在性证明的具体实施方式可以参见上述校验第一存在性证明的具体实施方式，这里将不再继续进行赘述。在第二存在性证明校验失败时，该出块节点可以确定待验证交易不具备合法性。应当理解，在第二存在性证明校验成功时，该出块节点可以继续比对第二存在性证明中的第二状态数据与出块节点记录到的待写入状态数据，从而可以得到第四比对结果。若第四比对结果指示第二状态数据与待写入状态数据不一致，则出块节点确定第四比对结果比对失败，基于此，该出块节点可以确定待验证交易的第二校验结果指示校验失败，即待验证交易不具备合法性。可选的，若第四比对结果指示第二状态数据与待写入状态数据一致，则该出块节点可以确定第四比对结果指示比对成功，基于此，该出块节点可以确定待验证交易的第二校验结果指示校验成功，即待验证交易具备合法性。
其中，该出块节点还可以先校验第二存在性证明以及比对第二状态数据和待写入状态数据，再比对初始交易执行结果和目标交易执行结果。这里将不对比对顺序进行限定。
由此可见，本申请实施例中的全量节点在获取到用户节点发送的待验证交易时，可以基于全量区块链中目标区块，执行待验证交易对应的交易业务，进而可以将执行交易业务后得到的初始交易执行结果、状态读取集合、状态写入集合以及目标区块的区块标识作为该待验证交易的交易验证信息。在区块链网络中的出块节点接收到待验证交易的同时，会一并获取全量节点确定的交易验证信息。基于此，该出块节点无需花费时间，从全量区块链的创世区块开始同步所有状态数据，而是直接从出块节点的区块头链中获取与区块标识相匹配的第二区块头，并根据第二区块头的第一状态快照以及交易验证信息，快速对待验证交易进行合法性校验，从而可以提升合法性校验的效率，进而可以减轻出块节点的运行负担，以至于大大加快了出块节点的启动时间。此外，由于本申请实施例中的出块节点为区块链网络中的轻量节点，因此，该出块节点不需要保留完整的区块数据，而是保留区块头首尾相连而构成的区块头链上的部分数据，即可对待验证交易进行验证，从而可以大大较少了存储空间的消耗。
进一步地，请参见图8，图8是本申请实施例提供的一种交易验证方法的流程示意图。如图8所示，该方法可以由区块链网络中的用户节点、全量节点以及出块节点共同执行，该用户节点可以为区块链网络中的由用户控制的区块链节点，例如，该用户节点可以为上述图2所示的用户节点20A。本申请实施例中的全量节点可以为区块链网络中的具有保存完整区块数据功能的区块链节点，例如，该全量节点可以为上述图2所示的全量节点20B。该出块节点可以为区块链网络中的轻量节点，例如，该出块节点可以为上述图2所示的出块节点20C。该方法至少可以包括以下S201-S209：
S201，用户节点将为用户组装的待验证交易发送至全量节点；
S202，全量节点在获取到与区块链网络中的用户节点相关联的待验证交易时，在全量节点的全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将目标区块的区块头作为第一区块头；
S203，全量节点获取目标区块中的默克尔帕特里夏树，基于目标区块中的默克尔帕特里夏树，执行待验证交易对应的交易业务，得到交易业务对应的初始交易执行结果、状态 读取集合以及状态写入集合；
S204，全量节点获取第一区块头中的区块标识，将初始交易执行结果、状态读取集合、状态写入集合以及区块标识，作为待验证交易对应的交易验证信息；
S205，全量节点将交易验证信息发送至用户节点；
S206，用户节点在接收到交易验证信息时，将交易验证信息和待验证信息发送至出块节点；
S207，出块节点在轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果；
S208，出块节点在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到交易业务对应的目标交易执行结果以及待写入状态数据；
S209，出块节点基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。
其中，该S201-S209的具体实施方式可参见上述图3所对应实施例中对S101-S104的描述，这里将不再赘述。
为便于理解，进一步地，请参见图9，图9是本申请实施例提供的一种交易验证方法的流程示意图。如图9所示，该方法可以由区块链网络中的用户节点、全量节点以及出块节点共同执行，该用户节点可以为区块链网络中的由用户控制的区块链节点，例如，该用户节点可以为上述图2所示的用户节点20A。本申请实施例中的全量节点可以为区块链网络中的具有保存完整区块数据功能的区块链节点，例如，该全量节点可以为上述图2所示的全量节点20B。该出块节点可以为区块链网络中的轻量节点，例如，该出块节点可以为上述图2所示的出块节点20C。
如图9所示，本申请实施例中的用户节点可以在用户执行与待验证交易相关联的触发操作时，执行S91，为用户组装待验证交易，进而可以将该待验证交易发送至全量节点。可以理解的是，该全量节点在接收到待验证交易时，可以执行S92，基于全量节点的全量区块链上的目标区块(即具有最大生成时间戳的区块)，执行该待验证交易对应的交易业务，以得到交易业务对应的交易执行结果(即初始交易执行结果)、状态读取集合以及状态写入集合，进而可以将目标区块的第一区块头(例如，图2所示的区块100g的区块头100)中的区块标识、初始交易执行结果、状态读取集合以及状态写入集合作为待验证交易的交易验证信息，进而可以将该交易验证信息发送至用户节点。用户节点在接收到交易验证信息时，可以执行S93，将交易验证信息以及待验证交易一并转发至出块节点。
出块节点在接收到待验证交易和交易验证信息时，可以执行S94，从出块节点的区块头链中，获取与第一区块头的区块标识相匹配的区块头(即第二区块头)，进而可以基于该第二区块头(例如，图2所示的区块头链2b中的区块头100)中的状态快照(即第一状态快照)，校验交易验证信息中的状态读取集合和状态写入集合，得到第一校验结果，在第一校验结果指示校验成功时，出块节点可以执行S95，基于状态读取集合中的第一状态数据，执行交易业务，得到目标交易执行结果以及记录所有需要写入的数据(即待写入状态数据)，进而 可以基于交易验证信息中的初始交易执行结果和状态写入集合、以及执行交易业务后得到的目标交易执行结果和待写入状态数据，对待验证交易进行合法性校验。其中，本申请实施例中对待验证交易进行合法性校验的具体实施方式可以参见上述图3所对应实施例中对S101-S104的描述，这里将不再赘述。
在待验证交易具备合法性时，出块节点可以执行S96，基于状态写入集合中的第二状态数据，生成与该第二状态数据相关联的新的状态快照(即第二状态快照)。进一步地，该出块节点可以执行S97，基于待验证交易、目标交易执行结果以及第二状态快照，生成新的区块头(即待处理区块头)。其中，该待处理区块头可以用于作为区块头链上的第二区块头的下一区块头。此时，该出块节点可以将待处理区块头写入区块头链，且在将该待处理区块头成功写入至区块头链后，可以将待处理区块头发送至全量节点，以使全量节点执行S98，基于该待处理区块头中的交易(已经确定具备合法性的待验证交易)，重新执行对应交易业务，生成新的区块(即待处理区块)，进而可以将待处理区块作为全量区块链上的目标区块的下一区块，以写入全量区块链中。
为便于理解，进一步地，请参见图10，图10是本申请实施例提供的一种生成待处理区块的场景示意图。如图10所示，本申请实施例中的全量节点100B可以为区块链网络中的具有保存完整区块数据功能的区块链节点，例如，该全量节点100B可以为上述图2所示的全量节点20B。该出块节点100C可以为区块链网络中的轻量节点，例如，该出块节点100C可以为上述图2所示的出块节点20C。
如图10所示，本申请实施例中的出块节点100C的区块头链可以为图10所示的区块头链10b。其中，该区块头链10b中的区块头100可以为该出块节点100C基于待验证交易对应的交易验证信息中的区块标识所确定的第二区块头，该第二区块头可以包括第一状态快照。该区块头链10b中的区块头101可以为该出块节点100C在确定该待验证交易具备合法性时所生成的新的区块头(即待处理区块头)，该区块头101中可以包括第二状态快照。
其中，可以理解的是，该出块节点100C可以从交易验证信息中的状态写入集合，获取全量节点100B在模拟执行该待验证交易对应的交易业务之后所记录的第二状态数据。进一步地，该出块节点100C可以基于该第二状态数据，生成与该第二状态数据相关联的新的状态快照(即第二状态快照)。此时，该出块节点100C可以对待验证交易、目标交易执行结果以及第二状态快照进行打包处理，从而可以得到新的区块头(即待处理区块头)，进而可以将该待处理区块头作为区块头100的下一区块头(即区块头101)，以将该区块头101写入至图10所示的区块头链10b。
应当理解，在出块节点100C将区块头101成功写入至图10所示的区块头链10b之后，该出块节点100C可以将该区块头101发送至图10所示的全量节点100B。其中，为了有效确保待处理区块头在数据传输时的安全性，该出块节点100C可以先获取全量节点100B的节点公钥，对区块头101进行加密处理，从而可以得到加密数据信息，然后，将该加密数据信息发送至全量节点100B。
全量节点100B在接收到该加密数据信息时，可以基于全量节点100B的节点私钥，对该加密数据信息进行解密处理，从而可以得到出块节点100C生成的区块头101。此时，该全量 节点100B可以获取区块头101中的待验证交易，进而可以重新执行该待验证交易对应的交易业务，以生成新的区块(即待处理区块)。如图10所示，区块链10a可以为该全量节点100B的全量区块链，该区块链10a中的区块100g可以为全量节点100B确定的目标区块。
其中，该全量节点100B在重新执行该待验证交易对应的交易业务的过程中，可以记录需要写入至待处理区块的状态数据(即目标状态数据)，进而可以基于该目标状态数据，对区块100g中的默克尔帕特里夏树(即待处理树)进行更新，以得到新的默克尔帕特里夏树(即目标默克尔帕特里夏树)，且基于该目标默克尔帕特里夏树，生成待处理区块。应当理解，全量节点100B在生成待处理区块后，可以将该待处理区块作为区块100g的下一区块(即图10所示的区块101g)，以将该待处理区块成功写入至区块链10a。其中，该区块101g中的生成时间戳用于更新该区块链10a上具有最大生成时间戳。
由此可见，本申请实施例中的全量节点在获取到用户节点发送的待验证交易时，可以基于全量区块链中目标区块，执行待验证交易对应的交易业务，进而可以将执行交易业务后得到的初始交易执行结果、状态读取集合、状态写入集合以及目标区块的区块标识作为该待验证交易的交易验证信息。在区块链网络中的出块节点接收到待验证交易的同时，会一并获取全量节点确定的交易验证信息。基于此，该出块节点无需花费时间，从全量区块链的创世区块开始同步所有状态数据，而是直接根据出块节点的区块头链中的第二区块头的第一状态快照，以及交易验证信息，确定待验证交易的合法性，从而可以减轻出块节点的运行负担，以至于大大加快了出块节点的启动时间。此外，由于本申请实施例中的出块节点为区块链网络中的轻量节点，因此，该出块节点不需要保留完整的区块数据，而是保留区块头首尾相连而构成的区块头链上的部分数据，即可对待验证交易进行验证，从而可以大大较少了存储空间的消耗。在出块节点验证待验证交易具备合法性时，还可以基于该待验证交易生成新的区块头(即待处理区块头)，且将新的区块头发送至全量节点，以使全量节点基于新的区块头生成新的区块，进而可以将具备合法性的该待验证交易成功写入至全量区块链。
进一步地，请参见图11，图11是本申请实施例提供的一种交易验证装置的结构示意图。该交易验证装置1可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如，该交易验证装置1为一个应用软件；该交易验证装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图11所示，该交易验证装置1可以运行于区块链网络中的出块节点，该出块节点可以为该区块链网络中的轻量节点，例如，该出块节点可以为上述图2所对应实施例中的出块节点20C。该交易验证装置1可以包括：交易获取模块10，集合校验模块20，目标执行结果确定模块30，合法性校验模块40，状态快照生成模块50，待处理区块头生成模块60，待处理区块头写入模块70，加密处理模块80以及加密数据信息发送模块90。
该交易获取模块10，用于获取区块链网络中的用户节点发送的待验证交易以及待验证交易对应的交易验证信息；交易验证信息是由区块链网络中的全量节点在执行待验证交易对应的交易业务后所确定的；交易验证信息包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识；区块标识用于指向全量节点的全量区块链上具有最大生成时间戳的目标区块；且目标区块的第一区块头中包含区块标识；
该集合校验模块20，用于在轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于第二区块头中的第一状态快照，对状态读取集合以及状态写入集合进行校验，得到待验证交易的第一校验结果。
其中，状态读取集合和状态写入集合是全量节点基于目标区块中的默克尔帕特里夏树所生成的；
该集合校验模块20包括：状态快照获取单元201，读取集合校验单元202，写入集合校验单元203以及校验结果确定单元204。
该状态快照获取单元201，用于从轻量节点的区块头链中，查找与第一区块头中的区块标识相匹配的区块头，将查找到的区块头作为第二区块头，且将第二区块头中的状态快照作为第一状态快照；
该读取集合校验单元202，用于从状态读取集合中获取第一状态数据的第一存在性证明，基于第一状态快照，对第一存在性证明进行校验，得到第一证明校验结果；第一状态数据为全量节点在目标区块中的默克尔帕特里夏树上读取到的与待验证交易相关联的状态数据。
其中，该读取集合校验单元202包括：证明获取子单元2021，初始比对结果确定子单元2022，第一比对结果确定子单元2023，第二比对结果确定子单元2024以及校验结果确定子单元2025。
该证明获取子单元2021，用于从状态读取集合中获取第一状态数据的第一存在性证明；第一存在性证明为全量节点从目标区块中的默克尔帕特里夏树中，获取到的与第一状态数据相关联的节点路径；节点路径包含叶子节点和树根节点；叶子节点用于存储第一状态数据；
该初始比对结果确定子单元2022，用于基于节点路径所指示的第一节点索引关系，将叶子节点作为子节点，且将叶子节点的上一节点作为子节点对应的父节点，将子节点的子节点哈希值与父节点的哈希指针进行比对，得到初始比对结果；
该第一比对结果确定子单元2023，用于若初始比对结果指示比对成功，则基于第一节点索引关系更新子节点以及父节点，直到更新后的父节点为树根节点时，得到第一存在性证明的第一比对结果；
该第二比对结果确定子单元2024，用于将树根节点的树根哈希值与第一状态快照进行比对，得到第一存在性证明的第二比对结果；
该校验结果确定子单元2025，用于基于第一比对结果和第二比对结果，得到第一证明校验结果。
其中，该证明获取子单元2021，初始比对结果确定子单元2022，第一比对结果确定子单元2023，第二比对结果确定子单元2024以及校验结果确定子单元2025的具体实现方式可以参见上述图3所对应实施例中对第一证明校验结果的描述，这里将不再继续进行赘述。
该写入集合校验单元203，用于从状态写入集合中获取第二状态数据的可修改证明，基于第一状态快照，对可修改证明进行校验，得到第二证明校验结果；第二状态数据为全量节点在执行交易业务的过程中记录到的模拟写入目标区块的下一区块的状态数据；
该校验结果确定单元204，用于基于第一证明校验结果和第二证明校验结果，确定待验 证交易的第一校验结果。
其中，该状态快照获取单元201，读取集合校验单元202，写入集合校验单元203以及校验结果确定单元204的具体实现方式可以参见上述图3所对应实施例中对S102的描述，这里将不再继续进行赘述。
该目标执行结果确定模块30，用于在第一校验结果指示校验成功时，基于状态读取集合执行交易业务，得到交易业务对应的目标交易执行结果以及待写入状态数据；
该合法性校验模块40，用于基于初始交易执行结果、目标交易执行结果、状态写入集合以及待写入状态数据，对待验证交易进行合法性校验。
其中，该合法性校验模块40包括：交易执行结果比对单元401，证明校验单元402，状态数据比对单元403以及合法性校验单元404。
该交易执行结果比对单元401，用于将初始交易执行结果和目标交易执行结果进行比对，得到第三比对结果；
该证明校验单元402，用于从状态写入集合中获取第二状态数据的第二存在性证明，基于第一状态快照，对第二存在性证明进行校验；
状态数据比对单元403，用于在校验成功时，将第二状态数据与待写入状态数据进行比对，得到第四比对结果；
该合法性校验单元404，用于基于第三比对结果和第四比对结果，得到待验证交易的第二校验结果，且基于第二校验结果，对待验证交易进行合法性校验。
其中，该交易执行结果比对单元401，证明校验单元402，状态数据比对单元403以及合法性校验单元404的具体实现方式可以参见上述图3所对应实施例中对S104的描述，这里将不再继续进行赘述。
该状态快照生成模块50，用于在确定待验证交易具备合法性时，基于状态写入集合中的第二状态数据，生成与第二状态数据相关联的第二状态快照；
该待处理区块头生成模块60，用于基于待验证交易、目标交易执行结果以及第二状态快照，生成待处理区块头；待处理区块头用于作为第二区块头的下一区块头；
该待处理区块头写入模块70，用于将待处理区块头写入区块头链。
该加密处理模块80，用于在将待处理区块头成功写入区块头链后，获取全量节点的节点公钥，对待处理区块头进行加密处理，得到加密数据信息；
该加密数据信息发送模块90，用于将加密数据信息发送至全量节点，以使全量节点基于全量节点的节点私钥，对加密数据信息进行解密处理，得到待处理区块头；待处理区块头用于指示全量节点生成待处理区块头对应的待处理区块；待处理区块用于作为全量区块链上的目标区块的下一区块。
其中，该交易获取模块10，集合校验模块20，目标执行结果确定模块30，合法性校验模块40，状态快照生成模块50，待处理区块头生成模块60，待处理区块头写入模块70，加密处理模块80以及加密数据信息发送模块90的具体实现方式可以参见上述图3所对应实施例中对S101-S104的描述，这里将不再继续进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
进一步地，请参见图12，图12是本申请实施例提供的一种交易验证装置的结构示意图。该交易验证装置2可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如，该交易验证装置2为一个应用软件；该交易验证装置2可以用于执行本申请实施例提供的方法中的相应步骤。如图12所示，该交易验证装置2可以运行于区块链网络中的全量节点，该全量节点可以为上述图2所对应实施例中的全量节点20B。该交易验证装置2可以包括：目标区块确定模块100，初始执行结果确定模块200以及验证信息确定模块300。
该目标区块确定模块100，用于在获取到与区块链网络中的用户节点相关联的待验证交易时，在全量节点的全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将目标区块的区块头作为第一区块头。
其中，目标区块确定模块100包括：签名信息接收单元1001，签名信息验签单元1002以及目标区块确定单元1003。
该签名信息接收单元1001，用于接收区块链网络中的用户节点发送的待验证交易对应的交易签名信息；交易签名信息为用户节点基于用户私钥，对待验证交易进行签名处理后所得到的；
该签名信息验签单元1002，用于获取用户私钥对应的用户公钥，基于用户公钥对交易签名信息进行验签，得到验签结果；
该目标区块确定单元1003，用于在验签结果指示验签成功时，在全量节点的全量区块链上，获取具有最大生成时间戳的区块，将获取到的区块作为目标区块，且将目标区块的区块头作为第一区块头。
其中，该签名信息接收单元1001，签名信息验签单元1002以及目标区块确定单元1003的具体实现方式可以参见上述图8所对应实施例中对S202的描述，这里将不再继续进行赘述。
该初始执行结果确定模块200，用于获取目标区块中的默克尔帕特里夏树，基于目标区块中的默克尔帕特里夏树，执行待验证交易对应的交易业务，得到交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合。
其中，初始执行结果确定模块200包括：第一状态数据确定单元2001，第二状态数据确定单元2002，读取集合生成单元2003以及写入集合生成单元2004。
该第一状态数据确定单元2001，用于获取目标区块中的默克尔帕特里夏树，将获取到的默克尔帕特里夏树作为待处理树，从待处理树中读取与待验证交易相关联的状态数据，将读取到的状态数据作为第一状态数据；
该第二状态数据确定单元2002，用于基于第一状态数据，执行待验证交易对应的交易业务，得到交易业务对应的初始交易执行结果，且在执行交易业务的过程中，记录模拟写入目标区块的下一区块的状态数据，将记录到的状态数据作为第二状态数据；
该读取集合生成单元2003，用于基于待处理树，收集第一状态数据的第一存在性证明，基于第一存在性证明生成状态读取集合；
该写入集合生成单元2004，用于基于待处理树，收集第二状态数据的可修改证明和第二存在性证明，基于可修改证明和第二存在性证明生成状态写入集合。
其中，该写入集合生成单元2004包括：可修改证明获取子单元20041，存在性证明获取 子单元20042以及写入集合生成子单元20043。
该可修改证明获取子单元20041，用于在将第二状态数据插入到待处理树之前，获取与第二状态数据相关联的关键字符串，基于关键字符串获取第二状态数据的可修改证明。
其中，待处理树包含树根节点；
该可修改证明获取子单元20041还用于：
在将第二状态数据插入到待处理树之前，获取与第二状态数据相关联的关键字符串；
获取待处理树所指示的第二节点索引关系，基于第二节点索引关系，从树根节点开始遍历查找与关键字符串具有相同前缀的字符；
基于查找到的所有字符，得到待处理字符串，获取与待处理字符串相关联的存在性证明，且将获取到的存在性证明作为第二状态数据的可修改证明。
该存在性证明获取子单元20042，用于在将第二状态数据插入到待处理树之后，获取第二状态数据的存在性证明，将第二状态数据的存在性证明作为第二存在性证明；
该写入集合生成子单元20043，用于基于可修改证明和第二存在性证明，生成状态写入集合。
其中，该可修改证明获取子单元20041，存在性证明获取子单元20042以及写入集合生成子单元20043的具体实现方式可以参见上述图3所对应实施例中对状态写入集合的描述，这里将不再继续进行赘述。
其中，该第一状态数据确定单元2001，第二状态数据确定单元2002，读取集合生成单元2003以及写入集合生成单元2004的具体实现方式可以参见上述图8所对应实施例中对S208的描述，这里将不再继续进行赘述。
该验证信息确定模块300，用于获取第一区块头中的区块标识，将初始交易执行结果、状态读取集合、状态写入集合以及区块标识，作为待验证交易对应的交易验证信息；交易验证信息用于指示区块链网络中的出块节点，基于区块头链中的第二区块头中的第一状态快照，对待验证交易进行合法性校验；第二区块头为区块头链中与区块标识相匹配的区块头；出块节点为区块链网络中的轻量节点。
其中，该目标区块确定模块100，初始执行结果确定模块200以及验证信息确定模块300的具体实现方式可以参见上述图8所对应实施例中对S201-S209的描述，这里将不再继续进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
进一步地，请参见图13，图13是本申请实施例提供的一种计算机设备的示意图。如图13所示，该计算机设备3000可以为上述图2对应实施例中的出块节点20C，该计算机设备3000可以包括：至少一个处理器3001，例如CPU，至少一个网络接口3004，用户接口3003，存储器3005，至少一个通信总线3002。其中，通信总线3002用于实现这些组件之间的连接通信。其中，用户接口3003可以包括显示屏(Display)、键盘(Keyboard)，网络接口3004可选地可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器3005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储3005可选地还可以是至少一个位于远离前述处理器3001的存储装置。如图13所示，作为一种计算机存储介质的存储器3005可以包括操作系统、网络通信模块、用户接口模块以及 设备控制应用程序。
在图13所示的计算机设备3000中，网络接口3004主要用于进行网络通信；而用户接口3003主要用于为用户提供输入的接口；而处理器3001可以用于调用存储器3005中存储的设备控制应用程序。
应当理解，本申请实施例中所描述的计算机设备3000可执行前文图3或者图8所对应实施例中对该交易验证方法的描述，也可执行前文图11所对应实施例中对该交易验证装置1或者图12所对应实施例中对该交易验证装置2的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且该计算机可读存储介质中存储有前文提及的交易验证装置1或者交易验证装置2所执行的计算机程序，且该计算机程序包括程序指令，当该处理器执行该程序指令时，能够执行前文图3或者图8所对应实施例中对该交易验证方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行，分布在多个地点且通过通信网络互连的多个计算设备可以组成区块链系统。
本申请一方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备可执行前文图3或者图8所对应实施例中对交易验证方法的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
进一步的，请参见图14，图14是本申请实施例提供的一种数据处理系统的结构示意图。该数据处理系统3可以包含数据处理装置1a和数据处理装置2a。其中，数据处理装置1a可以为上述图11所对应实施例中的交易验证装置1，可以理解的是，该数据处理装置1a可以集成在上述图2所对应实施例中的出块节点20C，因此，这里将不再进行赘述。其中，数据处理装置2a可以为上述图12所对应实施例中的交易验证装置2，可以理解的是，该数据处理装置2a可以集成在上述图2所对应实施例中的全量节点20B，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的数据处理系统实施例中未披露的技术细节，请参照本申请方法实施例的描述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (16)

  1. 一种交易验证方法，所述方法由区块链网络中的出块节点执行，所述出块节点为所述区块链网络中的轻量节点，包括：
    获取所述区块链网络中的用户节点发送的待验证交易以及所述待验证交易对应的交易验证信息；所述交易验证信息是由所述区块链网络中的全量节点在执行所述待验证交易对应的交易业务后所确定的；所述交易验证信息包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识；所述区块标识用于指向所述全量节点的全量区块链上具有最大生成时间戳的目标区块；且所述目标区块的第一区块头中包含所述区块标识；
    在所述轻量节点的区块头链中，查找与所述第一区块头中的所述区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于所述第二区块头中的第一状态快照，对所述状态读取集合以及所述状态写入集合进行校验，得到所述待验证交易的第一校验结果；
    在所述第一校验结果指示校验成功时，基于所述状态读取集合执行所述交易业务，得到所述交易业务对应的目标交易执行结果以及待写入状态数据；
    基于所述初始交易执行结果、所述目标交易执行结果、所述状态写入集合以及所述待写入状态数据，对所述待验证交易进行合法性校验。
  2. 根据权利要求1所述的方法，所述状态读取集合和所述状态写入集合是所述全量节点基于所述目标区块中的默克尔帕特里夏树所生成的；
    所述在所述轻量节点的区块头链中，查找与所述第一区块头中的所述区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于所述第二区块头中的第一状态快照，对所述状态读取集合以及所述状态写入集合进行校验，得到所述待验证交易的第一校验结果，包括：
    从所述轻量节点的区块头链中，查找与所述第一区块头中的所述区块标识相匹配的区块头，将查找到的区块头作为第二区块头，且将所述第二区块头中的状态快照作为第一状态快照；
    从所述状态读取集合中获取第一状态数据的第一存在性证明，基于所述第一状态快照，对所述第一存在性证明进行校验，得到第一证明校验结果；所述第一状态数据为所述全量节点在所述目标区块中的默克尔帕特里夏树上读取到的与所述待验证交易相关联的状态数据；
    从所述状态写入集合中获取第二状态数据的可修改证明，基于所述第一状态快照，对所述可修改证明进行校验，得到第二证明校验结果；所述第二状态数据为所述全量节点在执行所述交易业务的过程中记录到的模拟写入所述目标区块的下一区块的状态数据；
    基于所述第一证明校验结果和所述第二证明校验结果，确定所述待验证交易的第一校验结果。
  3. 根据权利要求2所述的方法，所述从所述状态读取集合中获取第一状态数据的第一存在性证明，基于所述第一状态快照，对所述第一存在性证明进行校验，得到第一证明校验结果，包括：
    从所述状态读取集合中获取第一状态数据的第一存在性证明；所述第一存在性证明为 所述全量节点从所述目标区块中的默克尔帕特里夏树中，获取到的与所述第一状态数据相关联的节点路径；所述节点路径包含叶子节点和树根节点；所述叶子节点用于存储所述第一状态数据；
    基于所述节点路径所指示的第一节点索引关系，将所述叶子节点作为子节点，且将所述叶子节点的上一节点作为所述子节点对应的父节点，将所述子节点的子节点哈希值与所述父节点的哈希指针进行比对，得到初始比对结果；
    若所述初始比对结果指示比对成功，则基于所述第一节点索引关系更新所述子节点以及所述父节点，直到更新后的父节点为所述树根节点时，得到所述第一存在性证明的第一比对结果；
    将所述树根节点的树根哈希值与所述第一状态快照进行比对，得到所述第一存在性证明的第二比对结果；
    基于所述第一比对结果和所述第二比对结果，得到第一证明校验结果。
  4. 根据权利要求1所述的方法，所述基于所述初始交易执行结果、所述目标交易执行结果、所述状态写入集合以及所述待写入状态数据，对所述待验证交易进行合法性校验，包括：
    将所述初始交易执行结果和所述目标交易执行结果进行比对，得到第三比对结果；
    从所述状态写入集合中获取第二状态数据的第二存在性证明，基于所述第一状态快照，对所述第二存在性证明进行校验；
    在校验成功时，将所述第二状态数据与所述待写入状态数据进行比对，得到第四比对结果；
    基于所述第三比对结果和所述第四比对结果，得到所述待验证交易的第二校验结果，且基于所述第二校验结果，对所述待验证交易进行合法性校验。
  5. 根据权利要求1所述的方法，所述方法还包括：
    在确定所述待验证交易具备合法性时，基于所述状态写入集合中的第二状态数据，生成与所述第二状态数据相关联的第二状态快照；
    基于所述待验证交易、所述目标交易执行结果以及所述第二状态快照，生成待处理区块头；所述待处理区块头用于作为所述第二区块头的下一区块头；
    将所述待处理区块头写入所述区块头链。
  6. 根据权利要求5所述的方法，所述方法还包括：
    在将所述待处理区块头成功写入所述区块头链后，获取所述全量节点的节点公钥，对所述待处理区块头进行加密处理，得到加密数据信息；
    将所述加密数据信息发送至所述全量节点，以使所述全量节点基于所述全量节点的节点私钥，对所述加密数据信息进行解密处理，得到所述待处理区块头；所述待处理区块头用于指示所述全量节点生成所述待处理区块头对应的待处理区块；所述待处理区块用于作为所述全量区块链上的所述目标区块的下一区块。
  7. 一种交易验证方法，所述方法由区块链网络中的全量节点执行，包括：
    在获取到与所述区块链网络中的用户节点相关联的待验证交易时，在所述全量节点的 全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将所述目标区块的区块头作为第一区块头；
    获取所述目标区块中的默克尔帕特里夏树，基于所述目标区块中的默克尔帕特里夏树，执行所述待验证交易对应的交易业务，得到所述交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合；
    获取所述第一区块头中的区块标识，将所述初始交易执行结果、所述状态读取集合、所述状态写入集合以及所述区块标识，作为所述待验证交易对应的交易验证信息；所述交易验证信息用于指示所述区块链网络中的出块节点，基于区块头链中的第二区块头中的第一状态快照，对所述待验证交易进行合法性校验；所述第二区块头为所述区块头链中与所述区块标识相匹配的区块头；所述出块节点为所述区块链网络中的轻量节点。
  8. 根据权利要求7所述的方法，所述在获取到与所述区块链网络中的用户节点相关联的待验证交易时，在所述全量节点的全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将所述目标区块的区块头作为第一区块头，包括：
    接收所述区块链网络中的用户节点发送的待验证交易对应的交易签名信息；所述交易签名信息为所述用户节点基于用户私钥，对所述待验证交易进行签名处理后所得到的；
    获取所述用户私钥对应的用户公钥，基于所述用户公钥对所述交易签名信息进行验签，得到验签结果；
    在所述验签结果指示验签成功时，在所述全量节点的全量区块链上，获取具有最大生成时间戳的区块，将获取到的区块作为目标区块，且将所述目标区块的区块头作为第一区块头。
  9. 根据权利要求7所述的方法，所述获取所述目标区块中的默克尔帕特里夏树，基于所述目标区块中的默克尔帕特里夏树，执行所述待验证交易对应的交易业务，得到所述交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合，包括：
    获取所述目标区块中的默克尔帕特里夏树，将获取到的默克尔帕特里夏树作为待处理树，从所述待处理树中读取与所述待验证交易相关联的状态数据，将读取到的状态数据作为第一状态数据；
    基于所述第一状态数据，执行所述待验证交易对应的交易业务，得到所述交易业务对应的初始交易执行结果，且在执行所述交易业务的过程中，记录模拟写入所述目标区块的下一区块的状态数据，将记录到的状态数据作为第二状态数据；
    基于所述待处理树，收集所述第一状态数据的第一存在性证明，基于所述第一存在性证明生成状态读取集合；
    基于所述待处理树，收集所述第二状态数据的可修改证明和第二存在性证明，基于所述可修改证明和所述第二存在性证明生成状态写入集合。
  10. 根据权利要求9所述的方法，所述基于所述待处理树，收集所述第二状态数据的可修改证明和第二存在性证明，基于所述可修改证明和所述第二存在性证明生成状态写入集合，包括：
    在将所述第二状态数据插入到所述待处理树之前，获取与所述第二状态数据相关联的 关键字符串，基于所述关键字符串获取所述第二状态数据的可修改证明；
    在将所述第二状态数据插入到所述待处理树之后，获取所述第二状态数据的存在性证明，将所述第二状态数据的存在性证明作为第二存在性证明；
    基于所述可修改证明和所述第二存在性证明，生成状态写入集合。
  11. 根据权利要求10所述的方法，所述待处理树包含树根节点；
    所述在将所述第二状态数据插入到所述待处理树之前，获取与所述第二状态数据相关联的关键字符串，基于所述关键字符串获取所述第二状态数据的可修改证明，包括：
    在将所述第二状态数据插入到所述待处理树之前，获取与所述第二状态数据相关联的关键字符串；
    获取所述待处理树所指示的第二节点索引关系，基于所述第二节点索引关系，从所述树根节点开始遍历查找与所述关键字符串具有相同前缀的字符；
    基于查找到的所有字符，得到待处理字符串，获取与所述待处理字符串相关联的存在性证明，且将获取到的存在性证明作为所述第二状态数据的可修改证明。
  12. 一种交易验证装置，包括：
    交易获取模块，用于获取区块链网络中的用户节点发送的待验证交易以及所述待验证交易对应的交易验证信息；所述交易验证信息是由所述区块链网络中的全量节点在执行所述待验证交易对应的交易业务后所确定的；所述交易验证信息包括状态读取集合、状态写入集合、初始交易执行结果以及区块标识；所述区块标识用于指向所述全量节点的全量区块链上具有最大生成时间戳的目标区块；且所述目标区块的第一区块头中包含所述区块标识；
    集合校验模块，用于在轻量节点的区块头链中，查找与所述第一区块头中的所述区块标识相匹配的区块头，将查找到的区块头作为第二区块头，基于所述第二区块头中的第一状态快照，对所述状态读取集合以及所述状态写入集合进行校验，得到所述待验证交易的第一校验结果；
    目标结果执行确定模块，用于在所述第一校验结果指示校验成功时，基于所述状态读取集合执行所述交易业务，得到所述交易业务对应的目标交易执行结果以及待写入状态数据；
    合法性校验模块，用于基于所述初始交易执行结果、所述目标交易执行结果、所述状态写入集合以及所述待写入状态数据，对所述待验证交易进行合法性校验。
  13. 一种交易验证装置，包括：
    目标区块确定模块，用于在获取到与区块链网络中的用户节点相关联的待验证交易时，在全量节点的全量区块链上，将具有最大生成时间戳的区块作为目标区块，且将所述目标区块的区块头作为第一区块头；
    初始执行结果确定模块，用于获取所述目标区块中的默克尔帕特里夏树，基于所述目标区块中的默克尔帕特里夏树，执行所述待验证交易对应的交易业务，得到所述交易业务对应的初始交易执行结果、状态读取集合以及状态写入集合；
    验证信息确定模块，用于获取所述第一区块头中的区块标识，将所述初始交易执行结果、所述状态读取集合、所述状态写入集合以及所述区块标识，作为所述待验证交易对应的交易验证信息；所述交易验证信息用于指示所述区块链网络中的出块节点，基于区块头链中的第二区块头中的第一状态快照，对所述待验证交易进行合法性校验；所述第二区块头为所述区块头链中与所述区块标识相匹配的区块头；所述出块节点为所述区块链网络中的轻量节点。
  14. 一种计算机设备，包括：处理器和存储器；
    所述处理器与存储器相连，其中，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1-6任一项所述的方法，或者，执行权利要求7-11任一项所述的方法。
  15. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-6任一项所述的方法，或者，执行权利要求7-11任一项所述的方法。
  16. 一种包括指令的计算机程序产品，当其在计算机上运行时，使得所述计算机执行权利要求1-6任一项所述的方法，或者，执行权利要求7-11任一项所述的方法。
PCT/CN2022/090859 2021-05-18 2022-05-05 一种交易验证方法、装置、设备及存储介质 WO2022242457A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22803781.8A EP4216131A4 (en) 2021-05-18 2022-05-05 TRANSACTION VERIFICATION METHOD AND APPARATUS, DEVICE AND STORAGE MEDIUM
US18/071,934 US20230090296A1 (en) 2021-05-18 2022-11-30 Transaction verification of a transaction based on a blockchain network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110537182.6 2021-05-18
CN202110537182.6A CN112967065B (zh) 2021-05-18 2021-05-18 一种交易验证方法、装置、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/071,934 Continuation US20230090296A1 (en) 2021-05-18 2022-11-30 Transaction verification of a transaction based on a blockchain network

Publications (1)

Publication Number Publication Date
WO2022242457A1 true WO2022242457A1 (zh) 2022-11-24

Family

ID=76279773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090859 WO2022242457A1 (zh) 2021-05-18 2022-05-05 一种交易验证方法、装置、设备及存储介质

Country Status (4)

Country Link
US (1) US20230090296A1 (zh)
EP (1) EP4216131A4 (zh)
CN (2) CN113435896B (zh)
WO (1) WO2022242457A1 (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113874898A (zh) * 2019-02-15 2021-12-31 区块链控股有限公司 用于通过区块链网络实现转账的计算机实现的系统和方法
CN113435896B (zh) * 2021-05-18 2022-05-31 腾讯科技（深圳）有限公司 一种交易验证方法、装置、设备及存储介质
CN113704271A (zh) * 2021-09-03 2021-11-26 杭州复杂美科技有限公司 默克尔树生成方法、非法节点识别方法、设备和存储介质
CN113505138B (zh) * 2021-09-06 2021-12-21 支付宝(杭州)信息技术有限公司 区块链系统中状态证明及执行区块的方法及装置
CN113570466B (zh) * 2021-09-24 2021-11-30 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置以及可读存储介质
CN114124497A (zh) * 2021-11-12 2022-03-01 中国银行股份有限公司 一种数据校验系统和方法
CN116579731A (zh) * 2023-03-31 2023-08-11 南京三次方信息科技有限公司 一种具有个人信息保护功能的区块链系统
CN117670330B (zh) * 2024-02-01 2024-05-24 中国信息通信研究院 基于区块链的交易处理方法和装置、电子设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110060064A (zh) * 2019-04-26 2019-07-26 深圳市网心科技有限公司 一种交易信息验证方法及相关装置
US20190295049A1 (en) * 2018-03-22 2019-09-26 NEC Laboratories Europe GmbH System and method for secure transaction verification in a distributed ledger system
CN111159293A (zh) * 2019-12-25 2020-05-15 杭州加密矩阵科技有限公司 一种基于轻节点技术的跨链信息验证方法
CN112085504A (zh) * 2020-11-16 2020-12-15 腾讯科技（深圳）有限公司 一种数据处理方法、装置、计算机设备及存储介质
CN112967065A (zh) * 2021-05-18 2021-06-15 腾讯科技（深圳）有限公司 一种交易验证方法、装置、设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108288156B (zh) * 2018-01-04 2020-08-14 杭州复杂美科技有限公司 一种区块链交易的存储及排队方法
CN108446969A (zh) * 2018-03-29 2018-08-24 张文昌 一种基于区块链的统一的公共交通记账与交易系统
US20190354518A1 (en) * 2018-05-01 2019-11-21 Michael Zochowski Chain mesh network for decentralized transaction systems
CN109150972B (zh) * 2018-07-17 2021-07-23 湖南宸瀚信息科技有限责任公司 一种双层分片的高效区块链的共识机制的工作方法
CN108681900A (zh) * 2018-07-18 2018-10-19 众安信息技术服务有限公司 轻节点验证交易的方法
WO2020096132A1 (ko) * 2018-11-07 2020-05-14 주식회사 컴퍼니위 화이트코인거래중개모듈·aos형 블록체인모듈로 이루어진 거래이력추적형 화이트코인 거래형성 장치 및 방법
CN110009334B (zh) * 2018-11-07 2020-04-28 阿里巴巴集团控股有限公司 一种构建梅克尔树、简单支付验证方法及装置
SG11201908944WA (en) * 2019-03-04 2019-10-30 Alibaba Group Holding Ltd Constructing blockchain world state merkle patricia trie subtree
CN112612856B (zh) * 2019-07-09 2024-03-29 创新先进技术有限公司 基于区块链的数据处理方法和装置
SG11202001989WA (en) * 2019-07-11 2020-04-29 Alibaba Group Holding Ltd Shared blockchain data storage
CN111010284B (zh) * 2019-12-20 2022-12-13 深圳市迅雷网络技术有限公司 一种待共识区块的处理方法、相关装置及区块链系统
CN111242617B (zh) * 2020-01-02 2022-05-10 支付宝(杭州)信息技术有限公司 用于执行交易正确性验证的方法及装置
CN112561700A (zh) * 2020-12-14 2021-03-26 长沙理工大学 区块链中交易数据的存储方法、验证方法、及区块链系统
CN112396423B (zh) * 2021-01-20 2021-04-13 腾讯科技（深圳）有限公司 一种交易数据处理方法、装置、设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190295049A1 (en) * 2018-03-22 2019-09-26 NEC Laboratories Europe GmbH System and method for secure transaction verification in a distributed ledger system
CN110060064A (zh) * 2019-04-26 2019-07-26 深圳市网心科技有限公司 一种交易信息验证方法及相关装置
CN111159293A (zh) * 2019-12-25 2020-05-15 杭州加密矩阵科技有限公司 一种基于轻节点技术的跨链信息验证方法
CN112085504A (zh) * 2020-11-16 2020-12-15 腾讯科技（深圳）有限公司 一种数据处理方法、装置、计算机设备及存储介质
CN112967065A (zh) * 2021-05-18 2021-06-15 腾讯科技（深圳）有限公司 一种交易验证方法、装置、设备及存储介质
CN113435896A (zh) * 2021-05-18 2021-09-24 腾讯科技（深圳）有限公司 一种交易验证方法、装置、设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4216131A4 *

Also Published As

Publication number Publication date
EP4216131A1 (en) 2023-07-26
CN113435896B (zh) 2022-05-31
US20230090296A1 (en) 2023-03-23
CN112967065B (zh) 2021-07-13
CN112967065A (zh) 2021-06-15
EP4216131A4 (en) 2024-04-17
CN113435896A (zh) 2021-09-24

Similar Documents

Publication Publication Date Title
WO2022242457A1 (zh) 一种交易验证方法、装置、设备及存储介质
US20210027289A1 (en) Asset transaction method, storage medium, and computer device
TWI721691B (zh) 用於隔離儲存在由區塊鏈網路維護的區塊鏈上的資料的電腦實現的方法、裝置及系統
KR102277289B1 (ko) 블록체인 월드 스테이트 머클 패트리샤 트리 서브트리 구성
CN110800255B (zh) 更新区块链世界状态默克尔帕特里夏字典树子树
EP3438903B1 (en) Hierarchical network system, and node and program used in same
US11556516B2 (en) Distributed blockchain data storage under account model
US11301452B2 (en) Storing and verification of derivative work data on blockchain with original work data
US11526488B2 (en) Distributed blockchain data storage under account model
CN108985100B (zh) 基于区块链的元素安全性证明方法、装置、设备和介质
JP7477576B2 (ja) ブロックチェーンネットワークにおける整合性のある分散型メモリプールのための方法及びシステム
WO2022121538A1 (zh) 基于区块链的数据同步方法、系统及相关设备
WO2023045620A1 (zh) 一种交易数据处理方法、装置、计算机设备以及存储介质
JP7157348B2 (ja) ブロックチェーンシステム、承認端末、スマートコントラクト登録方法、および、スマートコントラクト登録プログラム
EP4379556A1 (en) Blockchain-based data processing method, and device and computer-readable storage medium
US20230177505A1 (en) Transaction Verification Method and Apparatus
CN111226209A (zh) 在基于区块链的系统中执行映射迭代
JP2023513848A (ja) ブロックチェーンに関連するサービスのプラットフォームのための計算サービス
CN114358776A (zh) 基于fisco bcos与ipfs的物联网溯源方法、及其相关设备
US20240045849A1 (en) Data processing method and apparatus, device, and medium
CN110889040B (zh) 用于推送信息的方法和装置
US20240163118A1 (en) Blockchain-based data processing method, device, and readable storage medium
WO2024098862A1 (zh) 一种基于区块链的数据处理方法、装置、设备及介质
US20230353393A1 (en) Blockchain-based methods and apparatuses for processing data, devices and readable storage mediums
US20230254155A1 (en) Registration terminal, verification terminal, management system and program

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22803781

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022803781

Country of ref document: EP

Effective date: 20230419

NENP Non-entry into the national phase

Ref country code: DE