EP3678346A1 - Blockchain smart contract verification method and apparatus, and storage medium - Google Patents
Blockchain smart contract verification method and apparatus, and storage medium Download PDFInfo
- Publication number
- EP3678346A1 EP3678346A1 EP19863164.0A EP19863164A EP3678346A1 EP 3678346 A1 EP3678346 A1 EP 3678346A1 EP 19863164 A EP19863164 A EP 19863164A EP 3678346 A1 EP3678346 A1 EP 3678346A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- block
- root node
- node
- tree
- smart contracts
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000012795 verification Methods 0.000 title claims abstract description 75
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000004590 computer program Methods 0.000 claims description 5
- 238000004891 communication Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 101001028722 Chironex fleckeri Toxin CfTX-B Proteins 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
Images
Classifications
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- 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/3236—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 using cryptographic hash functions
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9027—Trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
- H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
- H04L9/0836—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
-
- 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/3236—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 using cryptographic hash functions
- H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- 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
- the present application relates to the field of information technology, and in particular, to a method and apparatus for verifying smart contracts in a blockchain, and a computer readable storage medium.
- a blockchain network usually includes a large number of full nodes, which maintain the account book data of a complete blockchain. Complete data of each block will be synchronized to these full nodes in real time, thus the validity of the block may be determined correctly.
- Some lightweight nodes may also exist in the blockchain network, such as mobile phone clients. Because of their limited storage space, they cannot store all the historical block data. In addition, the bandwidth of the mobile client is limited, and the traffic cost is high. When the block size is large and the block output speed is fast, it is unrealistic to synchronize the complete data of each block to the mobile client in real time. On the other hand, due to the weak hardware capability of lightweight nodes, it is too expensive to repeatedly execute smart contracts locally to verify whether the execution results of the smart contracts are consistent with a block synchronized from the blockchain.
- a method and apparatus for verifying smart contracts in a blockchain, and a computer readable storage medium are provided according to embodiments of the present application, so as to solve one or more technical problems in the existing technology.
- a method for verifying smart contracts in a blockchain includes: acquiring block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; verifying the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; verifying the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; and determining that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass.
- the verifying the root node of the first Merkle tree and the transaction identifications includes: constructing a third Merkle tree using the transaction identifications in the transaction list, and calculating a root node of the third Merkle tree; comparing whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determining that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- the verifying the root node of the second Merkle tree and the execution results of the smart contracts includes: constructing a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculating a root node of the fourth Merkle tree; comparing whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determining that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- the method before verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, the method further includes: acquiring the block head information of the designated block from the first node and a second node in the blockchain network, respectively; comparing whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determining the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verifying whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- an apparatus for verifying smart contracts in a blockchain includes: an acquiring unit, configured to acquire block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; a first verification unit, configured to verify the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; a second verification unit, configured to verify the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; a third verification unit, configured to verify whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; and a determination unit, configured to determine that the execution results of the smart contracts are
- the first verification unit is further configured to: construct a third Merkle tree using the transaction identifications in the transaction list, and calculate a root node of the third Merkle tree; compare whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determine that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- the second verification unit is further configured to: construct a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculate a root node of the fourth Merkle tree; compare whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determine that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- the apparatus further includes a fourth verification unit, configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verify whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- a fourth verification unit configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the
- the apparatus structurally includes a processor and a memory, wherein the memory is configured to store programs which support the apparatus to execute the above method, and the processor is configured to execute the programs stored in the memory.
- the apparatus may further include a communication interface through which the apparatus communicates with other devices or communication networks.
- an apparatus for verifying smart contracts in a blockchain includes: one or more processors; a storage device configured to store one or more programs; wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement any of the above methods described in the first aspect.
- a non-volatile computer readable storage medium which stores a computer program, wherein the program, when executed by a processor, causes the processor to implement any of the above methods described in the first aspect.
- FIG. 1 shows a flow chart of a method for verifying smart contracts in a blockchain according to an embodiment of the present application.
- the method includes: S110, acquiring block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; S120, verifying the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; S130, verifying the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; S140, verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; S150, determining that the execution results of the smart contracts are valid, if the first verification result
- a Merkle tree is an important data structure of a blockchain, which can quickly summarize block data and verify the existence and integrity of the block data.
- the Merkel tree usually contains an underlying (transaction) database of a block body, a root hash value (i.e. a Merkle root) of a block head, and all branches from the underlying block data to the root hash value.
- the operation process of the Merkle tree is generally to group and hash data of the block body, then insert the generated new hash values into the Merkle tree, and operate recursively until only one root hash value is finally left and recorded as the Merkle root of the block head.
- the most common Merkel tree is a binary Merkel tree used in Bitcoin. Each hash node in the binary Merkel tree always contains two adjacent data blocks or two hash values.
- a method for helping a lightweight node determine the validity of execution results of smart contracts in a blockchain network is provided according to an embodiment of the present application.
- the verification method according to the embodiment of the application includes:
- S120 and S130 can be interchanged. Alternatively, in another embodiment, S120 and S130 can be performed in parallel.
- the embodiment of the application can be applied to any lightweight node using the blockchain technology, and the lightweight node includes but is not limited to a mobile client device.
- FIG. 2 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown in FIG. 2 , specific implementation steps of the embodiment of the present application are as follows.
- the leaf nodes at the bottom of the first Merkel tree consist of all the transaction identifications of Unspent Transaction Output (UTXO) contained in the block.
- the transaction identifications are obtained by hashing the transaction contents, but the execution results of the smart contracts are not included in the transaction contents.
- the leaf nodes at the bottom of the second Merkel tree consist of the execution results of all the smart contracts contained in the block. If a transaction involves the execution of a smart contract, the execution result of the smart contract will be stored in a new field. These new fields make up a Merkel tree.
- the execution result of a smart contract involved in each transaction consists of two parts as follows.
- FIG. 3 shows a flow chart of calculating the second Merkel tree by a full node in a method for verifying smart contracts in a blockchain according to another embodiment of the present application.
- State-key indicates the state and key data corresponding to the execution result of a smart contract.
- Key state snapshots when Smart Contract has been Invoked represents a snapshot of the state and key data corresponding to the execution result generated after the execution of the smart contract.
- State-key 1 and state-key2 are hashed respectively, to get two leaf nodes hash L-LEAF. Then the two leaf nodes hash L-LEAF are hashed to get a branch node hash X-BRANCH.
- hash X-BRANCH and hash Y-BRANCH are hashed to generate the root node of the Merkel tree in the above v-1, i.e. "State DB Merkle root when Smart Contract has been Invoked-Tx B (the database of the Merkel tree root value after the execution of a smart contract B)".
- Smart Contract Invoke Result indicates the execution result of the smart contract.
- Smart Contract Invoke Response - TX B indicates the execution result of the smart contract B.
- Hash 4- LEAF Smart Contract Invoke Response - Tx B
- Hash 3-LEAF Hash 4- LEAF and Hash 3-LEAF are hashed to get a branch node "Hash 6 - BRANCH (Hash of smart contract result - Tx B, i.e. the hash value of the execution result of the smart contract B)”.
- a block head and a transaction list of a designated block is acquired by data synchronization through a first node randomly selected from a blockchain network or designated by a user.
- X is used to indicate the designated block, and partial information of the block X is obtained in this step, including: block head, UTXO transaction list (including transaction ids, execution results of smart contracts involved in transactions, etc.).
- the first node is a full node in the blockchain network.
- FIG. 4 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application.
- S140 verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure
- S 115 is executed. As shown in FIG.
- S115 specifically may include: S410, acquiring the block head information of the designated block from the first node and a second node in the blockchain network, respectively; S420, comparing whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; S430, determining the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; S440, verifying whether the identification of the previous block of designated block is in the pre-stored block head chain structure, in the case that the designated block is determined to be valid.
- S115 may specifically include the steps as follows.
- the second node is then randomly selected from the blockchain network or designated by the user for query.
- the query condition is the block id contained in the head of the block X obtained in S110.
- the block head Z corresponding to the block X is queried in the second node.
- the second node is a full node in the blockchain network.
- FIG. 5 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application.
- S120 verifying the root node of the first Merkle tree and the transaction identifications, may specifically include: S210, constructing a third Merkle tree using the transaction identifications in the transaction list, and calculating a root node of the third Merkle tree; S220, comparing whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; S230, determining that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- the block head of the block X matches the transaction id list thereof is verified.
- the transaction ids form a Merkel tree, i.e. the third Merkel tree, and its final Merkel tree root is calculated. Then it is compared whether the calculated root of the third Merkel tree is consistent with the root node hash of the first Merkel tree contained in the block head. If they are consistent, it indicates that the block head of the check block X matches the transaction id list, that is, the root node of the first Merkel tree matches the transaction ids, and the verification of the root node of the first Merkel tree and the transaction id is passed.
- FIG. 6 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application.
- S130 verifying the root node of the second Merkle tree and the execution results of the smart contracts, may specifically include: S310, constructing a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculating a root node of the fourth Merkle tree; S320, comparing whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; S330, determining that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- the block head of the check block X matches the smart contract execution result list thereof is verified.
- the execution results of the smart contracts form a Merkel tree, i.e. the fourth Merkel tree, and its final Merkel tree root is calculated. Then it is compared whether the calculated root of the fourth Merkel tree is consistent with the root node of the second Merkel tree contained in the block head. If they are consistent, the block head of block X matches the smart contract execution result list, that is, the root node of the second Merkel tree matches the execution results of the smart contracts, and the verification of the root node of the second Merkel tree and the execution results of the smart contracts is passed.
- S140 it is determined whether the previous block id contained in the block head of block X is in a locally maintained block head chain structure.
- the execution results of the smart contracts are determined to be valid, if verifications of S115, S120, S130 and S140 above are passed. If in the last verification step S140, it is determined that the previous block id contained in the block head of the block X is in the locally maintained block head chain structure, then the real and effective block head of the block X is saved to a locally maintained block head chain database.
- S115 is an execution step that may be omitted. In a scenario where the response time for verification is relatively high, S115 may not be executed.
- S115, S120, and S130 may be executed interchangeably.
- S115, S120, and S130 may be executed in parallel.
- S140 is performed after these three steps are completed.
- FIG. 7 shows a flow chart of verifying the validity on a lightweight node of a method for verifying smart contracts in a blockchain according to another embodiment of the present application.
- the specific implementation steps of a method for verifying smart contracts in a blockchain are as follows.
- the above technical solutions has the following advantages or beneficial effects: it not required to download or store the complete block information, nor is it required to repeat the execution of the smart contracts locally on a lightweight client, which can help the lightweight node determine the validity of the execution results of the smart contracts in the blockchain network, thereby saving system resources and improving the execution efficiency.
- FIG. 8 shows a structural block diagram of an apparatus for verifying smart contracts in a blockchain according to an embodiment of the present application.
- the apparatus includes: an acquiring unit 100, configured to acquire block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; a first verification unit 200, configured to verify the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; a second verification unit 300, configured to verify the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; a third verification unit 400, configured to verify whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; a determination
- the first verification unit 200 is further configured to: construct a third Merkle tree using the transaction identifications in the transaction list, and calculate a root node of the third Merkle tree; compare whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determine that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- the second verification unit 300 is further configured to: construct a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculate a root node of the fourth Merkle tree; compare whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determine that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- FIG. 9 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application.
- the apparatus further includes a fourth verification unit 600, configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verify whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in the case that the designated block is determined to be valid.
- a fourth verification unit 600 configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the
- the apparatus structurally includes a processor and a memory, wherein the memory is configured to store programs which support the apparatus to execute the above method, and the processor is configured to execute the programs stored in the memory.
- the apparatus may further include a communication interface through which the apparatus communicates with other devices or communication networks.
- FIG. 10 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application.
- the apparatus includes: a memory 101 and a processor 102.
- the memory 101 stores a computer program executable on the processor 102.
- the processor 102 executes the computer program, the above method in any of the foregoing embodiments is implemented.
- the number of the memory 101 and the processor 102 may be one or more.
- the apparatus further includes a communication interface 103 configured to communicate and exchange data with external devices.
- the memory 101 may include a high-speed RAM memory and may also include a non-volatile memory, such as at least one magnetic disk memory.
- the bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like.
- ISA Industry Standard Architecture
- PCI Peripheral Component Interconnect
- EISA Extended Industry Standard Architecture
- the bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one bold line is shown in FIG. 10 , but it does not mean that there is only one bus or one type of bus.
- the memory 101, the processor 102, and the communication interface 103 may implement mutual communication through an internal interface.
- a non-volatile computer readable storage medium which stores a computer program, wherein the program, when executed by a processor, causes the processor to implement any of the above methods.
- first and second are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, features defining “first” and “second” may explicitly or implicitly include at least one of the features. In the description of the present application, "a plurality of” means two or more, unless expressly restricted otherwise.
- Any process or method description in a flowchart or otherwise described herein can be understood as a module, fragment, or portion of code that includes one or more executable instructions for implementing a particular logical function or step of a process.
- the scope of the preferred embodiments of the present application includes additional implementations in which the functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order according to the functions involved. It is understood by those skilled in the art to which the embodiments of the present application pertain.
- Logic and/or steps represented in a flowchart or otherwise described herein, for example, a sequenced list of executable instructions that may be considered to implement a logical function, may be embodied in any computer-readable medium, for use by or in combination with an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or another system that can fetch and execute instructions from an instruction execution system, apparatus, or device) or equipment
- a "computer-readable medium” may be any device that may contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device.
- the computer-readable media include the following: electrical connections (electronic devices) having one or more wires, a portable computer disk cartridge (magnetic device), random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber devices, and portable read only memory (CDROM).
- the computer-readable medium may even be paper or other suitable medium upon which the program may be printed, as it may be read, for example, by optical scanning of the paper or other medium, followed by editing, interpretation or, where appropriate, process otherwise to electronically obtain the program, which is then stored in a computer memory.
- functional units in the embodiments of the present application may be integrated in one processing module, or each of the units may exist alone physically, or two or more units may be integrated in one module.
- the above-mentioned integrated module may be implemented in the form of hardware or in the form of software functional module.
- the integrated module When the integrated module is implemented in the form of a software functional module and is sold or used as an independent product, the integrated module may also be stored in a computer-readable storage medium.
- the storage medium may be a read only memory, a magnetic disk, an optical disk, or the like.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Databases & Information Systems (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Power Engineering (AREA)
- Data Mining & Analysis (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- This application claims priority to Chinese Patent Application No.
201811101341.2 - The present application relates to the field of information technology, and in particular, to a method and apparatus for verifying smart contracts in a blockchain, and a computer readable storage medium.
- A blockchain network usually includes a large number of full nodes, which maintain the account book data of a complete blockchain. Complete data of each block will be synchronized to these full nodes in real time, thus the validity of the block may be determined correctly.
- Some lightweight nodes may also exist in the blockchain network, such as mobile phone clients. Because of their limited storage space, they cannot store all the historical block data. In addition, the bandwidth of the mobile client is limited, and the traffic cost is high. When the block size is large and the block output speed is fast, it is unrealistic to synchronize the complete data of each block to the mobile client in real time. On the other hand, due to the weak hardware capability of lightweight nodes, it is too expensive to repeatedly execute smart contracts locally to verify whether the execution results of the smart contracts are consistent with a block synchronized from the blockchain.
- At present, there are lightweight node technologies in the market, but it is impossible to effectively verify the execution results of smart contracts on a lightweight node without repeatedly executing the smart contracts.
- A method and apparatus for verifying smart contracts in a blockchain, and a computer readable storage medium are provided according to embodiments of the present application, so as to solve one or more technical problems in the existing technology.
- In a first aspect, a method for verifying smart contracts in a blockchain is provided according to an embodiment of the present application, which includes: acquiring block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; verifying the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; verifying the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; and determining that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass.
- In an embodiment, the verifying the root node of the first Merkle tree and the transaction identifications, includes: constructing a third Merkle tree using the transaction identifications in the transaction list, and calculating a root node of the third Merkle tree; comparing whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determining that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- In an embodiment, the verifying the root node of the second Merkle tree and the execution results of the smart contracts, includes: constructing a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculating a root node of the fourth Merkle tree; comparing whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determining that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- In an embodiment, before verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, the method further includes: acquiring the block head information of the designated block from the first node and a second node in the blockchain network, respectively; comparing whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determining the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verifying whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- In a second aspect, an apparatus for verifying smart contracts in a blockchain is provided according to an embodiment of the present application, which includes: an acquiring unit, configured to acquire block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; a first verification unit, configured to verify the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; a second verification unit, configured to verify the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; a third verification unit, configured to verify whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; and a determination unit, configured to determine that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass.
- In an embodiment, the first verification unit is further configured to: construct a third Merkle tree using the transaction identifications in the transaction list, and calculate a root node of the third Merkle tree; compare whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determine that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- In an embodiment, the second verification unit is further configured to: construct a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculate a root node of the fourth Merkle tree; compare whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determine that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- In an embodiment, the apparatus further includes a fourth verification unit, configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verify whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- In a possible design, the apparatus structurally includes a processor and a memory, wherein the memory is configured to store programs which support the apparatus to execute the above method, and the processor is configured to execute the programs stored in the memory. The apparatus may further include a communication interface through which the apparatus communicates with other devices or communication networks.
- In a third aspect, an apparatus for verifying smart contracts in a blockchain is provided according to an embodiment of the present application, which includes: one or more processors; a storage device configured to store one or more programs; wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement any of the above methods described in the first aspect.
- In a fourth aspect, a non-volatile computer readable storage medium is provided according to an embodiment of the application, which stores a computer program, wherein the program, when executed by a processor, causes the processor to implement any of the above methods described in the first aspect.
- The above technical solutions have the following advantages or beneficial effects: it is not required to download or store the complete block information, nor is it required to repeatedly execute smart contracts locally on a lightweight client, which can help the lightweight node to determine the validity of the execution results of the smart contracts in the blockchain network, thereby saving system resources and improving the execution efficiency.
- The above summary is for the purpose of the specification only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features of the present application will be readily understood by reference to the drawings and the following detailed description.
- In the drawings, unless otherwise designated, identical reference numerals will be used throughout the drawings to refer to identical or similar parts or elements. The drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in accordance with the present application and are not to be considered as limiting the scope of the present application.
-
FIG. 1 shows a flow chart of a method for verifying smart contracts in a blockchain according to an embodiment of the present application. -
FIG. 2 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 3 shows a flow chart of calculating a second Merkel tree by a full node in a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 4 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 5 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 6 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 7 shows a flow chart of verifying the validity on a lightweight node of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 8 shows a structural block diagram of an apparatus for verifying smart contracts in a blockchain according to an embodiment of the present application. -
FIG. 9 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application. -
FIG. 10 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application. - In the following, only certain exemplary embodiments are briefly described. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present application. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive.
-
FIG. 1 shows a flow chart of a method for verifying smart contracts in a blockchain according to an embodiment of the present application. As shown inFIG. 1 , the method includes: S110, acquiring block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; S120, verifying the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; S130, verifying the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; S140, verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; S150, determining that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass. Leaf nodes of the first Merkel tree consist of all the transaction identifications of the designated block, and leaf nodes of the second Merkel tree consist of all the execution results of the smart contracts of the designated block. - A Merkle tree is an important data structure of a blockchain, which can quickly summarize block data and verify the existence and integrity of the block data. The Merkel tree usually contains an underlying (transaction) database of a block body, a root hash value (i.e. a Merkle root) of a block head, and all branches from the underlying block data to the root hash value. The operation process of the Merkle tree is generally to group and hash data of the block body, then insert the generated new hash values into the Merkle tree, and operate recursively until only one root hash value is finally left and recorded as the Merkle root of the block head. The most common Merkel tree is a binary Merkel tree used in Bitcoin. Each hash node in the binary Merkel tree always contains two adjacent data blocks or two hash values.
- There are some lightweight nodes in the blockchain network, such as mobile clients. The storage space of lightweight nodes is limited and the hardware capability is weak. It is necessary to seek a feasible method to verify the validity of the execution results of the smart contracts on a lightweight node, newly synchronized from the network. A method for helping a lightweight node determine the validity of execution results of smart contracts in a blockchain network is provided according to an embodiment of the present application. The verification method according to the embodiment of the application includes:
- S120, verifying whether the root node of the first Merkel tree in the block head information matches the transaction identifications in the transaction list;
- S130, verifying whether the root node of the second Merkel tree in the block head information matches the execution results of the smart contracts in the transaction list; and
- S140, verifying whether the identification of the previous block of the designated block in the block head information is in the pre-stored block head chain structure.
- The performance sequence of S120 and S130 can be interchanged. Alternatively, in another embodiment, S120 and S130 can be performed in parallel.
- The embodiment of the application can be applied to any lightweight node using the blockchain technology, and the lightweight node includes but is not limited to a mobile client device.
-
FIG. 2 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG. 2 , specific implementation steps of the embodiment of the present application are as follows. - In S105, the chain data structure of the block head is maintained locally.
- A. The block head contains the following data:
- i. a block head identification (id);
- ii. a previous block id;
- iii. a root node hash (hash value) of the first Merkle tree;
- iv. a root node hash of the second Merkle tree.
- B. Each block head points to the block head of the previous block, thus maintaining the chain data structure. The previous block identification pointed to by the block head of the genesis block is 0.
- The leaf nodes at the bottom of the first Merkel tree consist of all the transaction identifications of Unspent Transaction Output (UTXO) contained in the block. The transaction identifications are obtained by hashing the transaction contents, but the execution results of the smart contracts are not included in the transaction contents.
- The leaf nodes at the bottom of the second Merkel tree consist of the execution results of all the smart contracts contained in the block. If a transaction involves the execution of a smart contract, the execution result of the smart contract will be stored in a new field. These new fields make up a Merkel tree.
- The execution result of a smart contract involved in each transaction consists of two parts as follows.
- v-1. The root node of a Merkle tree. Every time a virtual machine (VM) executes a smart contract involved in a transaction, it will modify a data structure storing the data content of the smart contract. All the data make up this Merkel tree.
- v-2. The execution result generated after the execution of the smart contract involved in this transaction.
-
FIG. 3 shows a flow chart of calculating the second Merkel tree by a full node in a method for verifying smart contracts in a blockchain according to another embodiment of the present application. InFIG.3 , State-key indicates the state and key data corresponding to the execution result of a smart contract. "Key state snapshots when Smart Contract has been Invoked" represents a snapshot of the state and key data corresponding to the execution result generated after the execution of the smart contract. State-key 1 and state-key2 are hashed respectively, to get two leaf nodes hash L-LEAF. Then the two leaf nodes hash L-LEAF are hashed to get a branch node hash X-BRANCH. Then two branch nodes, hash X-BRANCH and hash Y-BRANCH, are hashed to generate the root node of the Merkel tree in the above v-1, i.e. "State DB Merkle root when Smart Contract has been Invoked-Tx B (the database of the Merkel tree root value after the execution of a smart contract B)". "Smart Contract Invoke Result" indicates the execution result of the smart contract. "Smart Contract Invoke Response - TX B" indicates the execution result of the smart contract B. "State DB Merkle root when Smart Contract has been Invoked-Tx B" is hashed to get Hash 4- LEAF, "Smart Contract Invoke Response - Tx B" is hashed to get Hash 3-LEAF, then Hash 4- LEAF and Hash 3-LEAF are hashed to get a branch node "Hash 6 - BRANCH (Hash of smart contract result - Tx B, i.e. the hash value of the execution result of the smart contract B)". Finally, Hash 6-BRANCH and "Hash 5 - BRANCH (Hash of smart contract result - Tx A, i.e. the hash value of the execution result of a smart contract A)" are hashed to get the root node "Hash 7 -Root (Hash of Branches, i.e. the hash value of the branch)". "Merkle Tree used for Generating Root" indicates a Merkle tree for generating a root node. - In S110, a block head and a transaction list of a designated block is acquired by data synchronization through a first node randomly selected from a blockchain network or designated by a user. X is used to indicate the designated block, and partial information of the block X is obtained in this step, including: block head, UTXO transaction list (including transaction ids, execution results of smart contracts involved in transactions, etc.). The first node is a full node in the blockchain network.
- In S115, whether data obtained from the first node and a second node are consistent is compared.
-
FIG. 4 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG. 2 , before S140, verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure,S 115 is executed. As shown inFIG. 4 , S115 specifically may include: S410, acquiring the block head information of the designated block from the first node and a second node in the blockchain network, respectively; S420, comparing whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; S430, determining the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; S440, verifying whether the identification of the previous block of designated block is in the pre-stored block head chain structure, in the case that the designated block is determined to be valid. - In an example, S115 may specifically include the steps as follows.
- The second node is then randomly selected from the blockchain network or designated by the user for query. The query condition is the block id contained in the head of the block X obtained in S110. Then, according to the target block id, the block head Z corresponding to the block X is queried in the second node. The second node is a full node in the blockchain network.
- It is compared whether the tree root of the first Merkel tree, the tree root of the second Merkel tree, and the previous block id match the information of the block head Z obtained from the second node. It means the block X is true and valid, if they match.
-
FIG. 5 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG.5 , in a possible embodiment, S120, verifying the root node of the first Merkle tree and the transaction identifications, may specifically include: S210, constructing a third Merkle tree using the transaction identifications in the transaction list, and calculating a root node of the third Merkle tree; S220, comparing whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; S230, determining that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree. - Specifically, whether the block head of the block X matches the transaction id list thereof is verified. The transaction ids form a Merkel tree, i.e. the third Merkel tree, and its final Merkel tree root is calculated. Then it is compared whether the calculated root of the third Merkel tree is consistent with the root node hash of the first Merkel tree contained in the block head. If they are consistent, it indicates that the block head of the check block X matches the transaction id list, that is, the root node of the first Merkel tree matches the transaction ids, and the verification of the root node of the first Merkel tree and the transaction id is passed.
-
FIG. 6 shows a flow chart of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG. 6 , in a possible embodiment, S130, verifying the root node of the second Merkle tree and the execution results of the smart contracts, may specifically include: S310, constructing a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculating a root node of the fourth Merkle tree; S320, comparing whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; S330, determining that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree. - Specifically, whether the block head of the check block X matches the smart contract execution result list thereof is verified. The execution results of the smart contracts form a Merkel tree, i.e. the fourth Merkel tree, and its final Merkel tree root is calculated. Then it is compared whether the calculated root of the fourth Merkel tree is consistent with the root node of the second Merkel tree contained in the block head. If they are consistent, the block head of block X matches the smart contract execution result list, that is, the root node of the second Merkel tree matches the execution results of the smart contracts, and the verification of the root node of the second Merkel tree and the execution results of the smart contracts is passed.
- In S140, it is determined whether the previous block id contained in the block head of block X is in a locally maintained block head chain structure.
- In S150, the execution results of the smart contracts are determined to be valid, if verifications of S115, S120, S130 and S140 above are passed. If in the last verification step S140, it is determined that the previous block id contained in the block head of the block X is in the locally maintained block head chain structure, then the real and effective block head of the block X is saved to a locally maintained block head chain database.
- In above steps, S115 is an execution step that may be omitted. In a scenario where the response time for verification is relatively high, S115 may not be executed.
- In addition, S115, S120, and S130 may be executed interchangeably. Alternatively, in another embodiment, S115, S120, and S130 may be executed in parallel. S140 is performed after these three steps are completed.
-
FIG. 7 shows a flow chart of verifying the validity on a lightweight node of a method for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG.7 , in an example, the specific implementation steps of a method for verifying smart contracts in a blockchain are as follows. - 1. A lightweight node synchronizes the head (including 2 Merkel trees), and the transaction id list, the smart contract execution result list of the latest block from a
full node 1. - 2. The validity of the block is verified. The specific steps of verification may include the above S115, S120, S130 and S140.
- 3. The block head of the same block is queried in a
full node 2, and it is compared whether two Merkel tree roots, and the previous block id pointed to are consistent with the data synchronized from thefull node 1. The specific steps of the comparison may include the above step S115. - 4. The transaction id list and the execution results of the smart contracts are verified.
- 4.1 It is determined whether the transaction (tx) ID list matches the first Merkel tree root of the block head, for example, pure payment transactions are verified.
- 4.2 It is determined whether the smart contract execution result list matches the second Merkel tree root of the block head, for example, transactions involving the smart contracts are verified.
- If all the above steps are verified successfully, a new real effective block head is stored.
- The above technical solutions has the following advantages or beneficial effects: it not required to download or store the complete block information, nor is it required to repeat the execution of the smart contracts locally on a lightweight client, which can help the lightweight node determine the validity of the execution results of the smart contracts in the blockchain network, thereby saving system resources and improving the execution efficiency.
-
FIG. 8 shows a structural block diagram of an apparatus for verifying smart contracts in a blockchain according to an embodiment of the present application. As shown inFIG. 8 , the apparatus includes: an acquiringunit 100, configured to acquire block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list includes transaction identifications and execution results of the smart contracts; and the block head information includes: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block; afirst verification unit 200, configured to verify the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result; asecond verification unit 300, configured to verify the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result; athird verification unit 400, configured to verify whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; adetermination unit 500, configured to: determining determine that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass. The leaf nodes of the first Merkel tree consist of all the transaction identifications of the designated block, and the leaf nodes of the second Merkel tree consist of all the execution results of the smart contracts of the designated block. - In an embodiment, the
first verification unit 200 is further configured to: construct a third Merkle tree using the transaction identifications in the transaction list, and calculate a root node of the third Merkle tree; compare whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; and determine that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree. - In an embodiment, the
second verification unit 300 is further configured to: construct a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculate a root node of the fourth Merkle tree; compare whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; and determine that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree. -
FIG. 9 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG. 9 , in an embodiment, the apparatus further includes afourth verification unit 600, configured to: acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively; compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; and verify whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in the case that the designated block is determined to be valid. - The functions of units in the apparatus may refer to the relevant description of the above method, which will not be described here anymore.
- In a possible design, the apparatus structurally includes a processor and a memory, wherein the memory is configured to store programs which support the apparatus to execute the above method, and the processor is configured to execute the programs stored in the memory. The apparatus may further include a communication interface through which the apparatus communicates with other devices or communication networks.
-
FIG. 10 shows a structural block diagram for an apparatus for verifying smart contracts in a blockchain according to another embodiment of the present application. As shown inFIG. 10 , the apparatus includes: amemory 101 and aprocessor 102. Thememory 101 stores a computer program executable on theprocessor 102. When theprocessor 102 executes the computer program, the above method in any of the foregoing embodiments is implemented. The number of thememory 101 and theprocessor 102 may be one or more. - The apparatus further includes a
communication interface 103 configured to communicate and exchange data with external devices. - The
memory 101 may include a high-speed RAM memory and may also include a non-volatile memory, such as at least one magnetic disk memory. - If the
memory 101, theprocessor 102, and thecommunication interface 103 are implemented independently, thememory 101, theprocessor 102, and thecommunication interface 103 may be connected to each other through a bus and communicate with one another. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one bold line is shown inFIG. 10 , but it does not mean that there is only one bus or one type of bus. - Optionally, in a specific implementation, if the
memory 101, theprocessor 102, and thecommunication interface 103 are integrated on one chip, thememory 101, theprocessor 102, and thecommunication interface 103 may implement mutual communication through an internal interface. - In another aspect, a non-volatile computer readable storage medium is provided according to an embodiment of the application, which stores a computer program, wherein the program, when executed by a processor, causes the processor to implement any of the above methods.
- In the description of the specification, the description of the terms "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" and the like means the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more of the embodiments or examples. In addition, different embodiments or examples described in this specification and features of different embodiments or examples may be incorporated and combined by those skilled in the art without mutual contradiction.
- In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, features defining "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present application, "a plurality of" means two or more, unless expressly restricted otherwise.
- Any process or method description in a flowchart or otherwise described herein can be understood as a module, fragment, or portion of code that includes one or more executable instructions for implementing a particular logical function or step of a process. And, the scope of the preferred embodiments of the present application includes additional implementations in which the functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order according to the functions involved. It is understood by those skilled in the art to which the embodiments of the present application pertain.
- Logic and/or steps represented in a flowchart or otherwise described herein, for example, a sequenced list of executable instructions that may be considered to implement a logical function, may be embodied in any computer-readable medium, for use by or in combination with an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or another system that can fetch and execute instructions from an instruction execution system, apparatus, or device) or equipment For the purposes of this specification, a "computer-readable medium" may be any device that may contain, store, communicate, propagate, or transport a program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (not a non-exhaustive list) of the computer-readable media include the following: electrical connections (electronic devices) having one or more wires, a portable computer disk cartridge (magnetic device), random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber devices, and portable read only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium upon which the program may be printed, as it may be read, for example, by optical scanning of the paper or other medium, followed by editing, interpretation or, where appropriate, process otherwise to electronically obtain the program, which is then stored in a computer memory.
- It should be understood that various portions of the present application may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, they may be implemented using any one or a combination of the following techniques well known in the art: discrete logic circuits having logic gate circuits for implementing logic functions on data signals, application specific integrated circuits with suitable combinational logic gate circuits, programmable gate arrays (PGA), field programmable gate arrays (FPGAs), and the like.
- Those skilled in the art may understand that all or some of the steps carried in the methods in the foregoing embodiments may be implemented by a program instructing relevant hardware. The program may be stored in a computer-readable storage medium, and when executed, one of the steps of the method embodiment or a combination thereof is included.
- In addition, functional units in the embodiments of the present application may be integrated in one processing module, or each of the units may exist alone physically, or two or more units may be integrated in one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of software functional module. When the integrated module is implemented in the form of a software functional module and is sold or used as an independent product, the integrated module may also be stored in a computer-readable storage medium. The storage medium may be a read only memory, a magnetic disk, an optical disk, or the like.
- The foregoing descriptions are merely specific embodiments of the present application, but not intended to limit the protection scope of the present application. Those skilled in the art may easily conceive of various changes or modifications within the technical scope disclosed herein, all these should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims (10)
- A method for verifying smart contracts in a blockchain, comprising:acquiring block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list comprises transaction identifications and execution results of the smart contracts; and the block head information comprises: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block;verifying the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result;verifying the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result;verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; anddetermining that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass.
- The method according to claim 1, wherein the verifying the root node of the first Merkle tree and the transaction identifications, comprises:constructing a third Merkle tree using the transaction identifications in the transaction list, and calculating a root node of the third Merkle tree;comparing whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; anddetermining that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- The method according to claim 1, wherein the verifying the root node of the second Merkle tree and the execution results of the smart contracts, comprises:constructing a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculating a root node of the fourth Merkle tree;comparing whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; anddetermining that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- The method according to any one of claims 1-3, wherein before verifying whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, the method further comprises:acquiring the block head information of the designated block from the first node and a second node in the blockchain network, respectively;comparing whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node;determining the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; andverifying whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- An apparatus for verifying smart contracts in a blockchain, comprising:an acquiring unit, configured to acquire block head information and a transaction list of a designated block from a first node in a blockchain network, wherein the transaction list comprises transaction identifications and execution results of the smart contracts; and the block head information comprises: a root node of a first Merkle tree, a root node of a second Merkle tree, and an identification of a previous block of the designated block;a first verification unit, configured to verify the root node of the first Merkle tree and the transaction identifications, to obtain a first verification result;a second verification unit, configured to verify the root node of the second Merkle tree and the execution results of the smart contracts, to obtain a second verification result;a third verification unit, configured to verify whether the identification of the previous block of the designated block is in a pre-stored block head chain structure, to obtain a third verification result; anda determination unit, configured to determine that the execution results of the smart contracts are valid, if the first verification result, the second verification result and the third verification result are all pass.
- The apparatus according to claim 5, wherein the first verification unit is further configured to:construct a third Merkle tree using the transaction identifications in the transaction list, and calculate a root node of the third Merkle tree;compare whether the root node of the third Merkel tree is consistent with the root node of the first Merkel tree; anddetermine that a verification of the root node of the first Merkle tree and the transaction identifications is passed, if the root node of the third Merkel tree is consistent with the root node of the first Merkel tree.
- The apparatus according to claim 5, wherein the second verification unit is further configured to:construct a fourth Merkle tree using the execution results of the smart contracts in the transaction list, and calculate a root node of the fourth Merkle tree;compare whether the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree; anddetermine that a verification of the root node of the second Merkle tree and the execution results of the smart contracts is passed, if the root node of the fourth Merkel tree is consistent with the root node of the second Merkel tree.
- The apparatus according to any one of claims 5-7, further comprising a fourth verification unit, configured to:acquire the block head information of the designated block from the first node and a second node in the blockchain network, respectively;compare whether the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node;determine the designated block is valid, if the block head information of the designated block in the first node is consistent with the block head information of the designated block in the second node; andverify whether the identification of the previous block of the designated block is in the pre-stored block head chain structure, in a case that the designated block is determined to be valid.
- An apparatus for verifying smart contracts in a blockchain, comprising:one or more processors; anda storage device configured to store one or more programs, whereinthe one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method according to any one of claims 1 to 4.
- A non-volatile computer readable storage medium storing a computer program, wherein the program, when executed by a processor, causes the processor to implement the method according to any one of claims 1 to 4.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811101341.2A CN109345388B (en) | 2018-09-20 | 2018-09-20 | Block chain intelligent contract verification method and device and storage medium |
PCT/CN2019/091475 WO2020057196A1 (en) | 2018-09-20 | 2019-06-17 | Blockchain smart contract verification method and apparatus, and storage medium |
Publications (3)
Publication Number | Publication Date |
---|---|
EP3678346A1 true EP3678346A1 (en) | 2020-07-08 |
EP3678346A4 EP3678346A4 (en) | 2021-09-29 |
EP3678346B1 EP3678346B1 (en) | 2022-09-07 |
Family
ID=65305888
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP19863164.0A Active EP3678346B1 (en) | 2018-09-20 | 2019-06-17 | Blockchain smart contract verification method and apparatus, and storage medium |
Country Status (6)
Country | Link |
---|---|
US (1) | US20200412526A1 (en) |
EP (1) | EP3678346B1 (en) |
JP (1) | JP7018517B2 (en) |
KR (1) | KR102431459B1 (en) |
CN (1) | CN109345388B (en) |
WO (1) | WO2020057196A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111884807A (en) * | 2020-07-13 | 2020-11-03 | 腾讯科技(深圳)有限公司 | Article reservation method, apparatus, device and medium based on block chain |
CN113259135A (en) * | 2021-07-06 | 2021-08-13 | 常州市建筑科学研究院集团股份有限公司 | Lightweight blockchain communication authentication device and method for detecting data tamper |
CN113657900A (en) * | 2021-07-13 | 2021-11-16 | 中国人民银行数字货币研究所 | Cross-chain transaction verification method and system and cross-chain transaction system |
WO2022087834A1 (en) * | 2020-10-27 | 2022-05-05 | Alipay (Hangzhou) Information Technology Co., Ltd. | Blockchain system having efficient world state data structures |
WO2023148042A1 (en) * | 2022-02-07 | 2023-08-10 | Nchain Licensing Ag | Blockchain based privacy enhanced outsourced data storage |
Families Citing this family (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109345388B (en) * | 2018-09-20 | 2020-09-08 | 百度在线网络技术(北京)有限公司 | Block chain intelligent contract verification method and device and storage medium |
SG11201908551QA (en) * | 2019-03-04 | 2019-10-30 | Alibaba Group Holding Ltd | Methods and devices for performing off-chain testing on smart contract |
CN111695991B (en) * | 2019-03-14 | 2024-02-06 | 北京沃东天骏信息技术有限公司 | Block-based contract processing method and device, block chain node and storage medium |
CN110335131B (en) * | 2019-06-04 | 2023-12-05 | 创新先进技术有限公司 | Financial risk control method and device based on similarity matching of trees |
CN110798509B (en) * | 2019-07-15 | 2021-09-17 | 腾讯科技(深圳)有限公司 | Block data synchronization method, device, medium and electronic equipment |
CN110336677B (en) * | 2019-07-15 | 2022-02-11 | 杭州复杂美科技有限公司 | Block packing and broadcasting method and system, equipment and storage medium |
CN111368003B (en) * | 2020-03-06 | 2020-10-16 | 安徽中科智链信息科技有限公司 | Management method of multi-chain anchoring data |
CN111159750B (en) * | 2020-04-07 | 2021-02-05 | 南京邮电大学 | Automobile maintenance data storage method based on alliance chain |
CN111432027B (en) * | 2020-04-14 | 2023-04-14 | 杭州复杂美科技有限公司 | Parallel chain block synchronization method, device and storage medium |
CN111523896B (en) * | 2020-05-06 | 2023-05-30 | 杭州复杂美科技有限公司 | Attack prevention method, apparatus and storage medium |
CN111915301B (en) * | 2020-08-05 | 2022-08-26 | 腾讯科技(深圳)有限公司 | Data processing method and device based on block chain, electronic equipment and readable medium |
CN112037055B (en) * | 2020-08-17 | 2023-05-05 | 成都质数斯达克科技有限公司 | Transaction processing method, device, electronic equipment and readable storage medium |
CN112085504B (en) * | 2020-11-16 | 2021-02-09 | 腾讯科技(深圳)有限公司 | Data processing method and device, computer equipment and storage medium |
CN112769894B (en) * | 2020-12-17 | 2022-05-17 | 国网浙江省电力有限公司信息通信分公司 | Equipment authentication method based on block chain Merkle tree verification |
CN112948350B (en) * | 2021-02-02 | 2023-08-01 | 中央财经大学 | Distributed ledger model cold data archiving and migration storage method based on MPT verification |
CN113220795B (en) * | 2021-02-19 | 2022-06-24 | 腾讯科技(深圳)有限公司 | Data processing method, device, equipment and medium based on distributed storage |
CN113282798B (en) * | 2021-05-07 | 2022-03-25 | 广州中国科学院计算机网络信息中心 | Meckel tree-based method and system for verifying version of identification resource |
CN113592645B (en) * | 2021-07-02 | 2023-11-14 | 中国人民银行数字货币研究所 | Data verification method and device |
CN114327759A (en) * | 2021-07-06 | 2022-04-12 | 支付宝(杭州)信息技术有限公司 | Processing method and device of block chain data |
CN113542396B (en) * | 2021-07-13 | 2024-03-08 | 华润数字科技有限公司 | Block chain storage and communication method, system and related components thereof |
CN113362068B (en) * | 2021-08-10 | 2022-03-29 | 北京连琪科技有限公司 | Method for verifying block chain state transfer by light node |
CN113626532B (en) * | 2021-09-03 | 2023-11-24 | 杭州复杂美科技有限公司 | Illegal node identification method, anti-cheating method, computer device and storage medium |
CN113704271A (en) * | 2021-09-03 | 2021-11-26 | 杭州复杂美科技有限公司 | Mercker tree generation method, illegal node identification method, equipment and storage medium |
CN114153849A (en) * | 2021-12-02 | 2022-03-08 | 深圳前海微众银行股份有限公司 | Data generation and verification method and device for block chain |
CN114401091B (en) * | 2021-12-16 | 2023-10-24 | 北京航空航天大学 | Device cross-domain authentication management method and device based on block chain |
GB2615752B (en) * | 2022-02-15 | 2024-04-24 | Nchain Licensing Ag | Attesting to membership of a set |
CN116028990B (en) * | 2023-03-30 | 2023-07-18 | 中国科学技术大学 | Anti-tampering privacy protection log auditing method based on blockchain |
CN116308368B (en) * | 2023-05-24 | 2023-07-18 | 国网区块链科技(北京)有限公司 | Relay block chain cross-chain data secure storage method and device and related equipment |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107145768B (en) * | 2016-03-01 | 2021-02-12 | 华为技术有限公司 | Copyright management method and system |
US10810583B2 (en) * | 2016-04-29 | 2020-10-20 | Digital Asset Holdings | Digital asset modeling |
US10447478B2 (en) * | 2016-06-06 | 2019-10-15 | Microsoft Technology Licensing, Llc | Cryptographic applications for a blockchain system |
WO2018026727A1 (en) * | 2016-08-01 | 2018-02-08 | Cryptowerk Corp. | Computer-implemented method and system of tamper-evident recording of a plurality of service data items |
KR101849917B1 (en) * | 2016-10-13 | 2018-05-31 | 주식회사 코인플러그 | Method for providing certificate service based on smart contract and server using the same |
US10554746B2 (en) * | 2016-11-14 | 2020-02-04 | International Business Machines Corporation | Decentralized immutable storage blockchain configuration |
WO2018119930A1 (en) * | 2016-12-29 | 2018-07-05 | 深圳前海达闼云端智能科技有限公司 | Transaction verification processing method, apparatus and node device |
CN107025559B (en) * | 2017-01-26 | 2020-09-18 | 创新先进技术有限公司 | Service processing method and device |
CN107040582B (en) * | 2017-02-17 | 2020-08-14 | 创新先进技术有限公司 | Data processing method and device |
CN111614655A (en) * | 2017-03-24 | 2020-09-01 | 创新先进技术有限公司 | Consensus checking method and device |
CN106899412A (en) * | 2017-03-30 | 2017-06-27 | 北京链银博科技有限责任公司 | A kind of block chain method for secret protection, apparatus and system |
EP4191494A1 (en) * | 2017-05-26 | 2023-06-07 | nChain Licensing AG | Blockchain state confirmation |
US11055703B2 (en) * | 2017-06-19 | 2021-07-06 | Hitachi, Ltd. | Smart contract lifecycle management |
US11281644B2 (en) * | 2017-07-28 | 2022-03-22 | Hitachi, Ltd. | Blockchain logging of data from multiple systems |
US11416942B1 (en) * | 2017-09-06 | 2022-08-16 | State Farm Mutual Automobile Insurance Company | Using a distributed ledger to determine fault in subrogation |
US20190253256A1 (en) * | 2018-02-13 | 2019-08-15 | Texas Precious Metals LLC | Tracking and verifying authenticity of an asset via a distributed ledger |
US10904009B2 (en) * | 2018-05-30 | 2021-01-26 | International Business Machines Corporation | Blockchain implementing delta storage |
US11334439B2 (en) * | 2018-08-29 | 2022-05-17 | International Business Machines Corporation | Checkpointing for increasing efficiency of a blockchain |
CN109345388B (en) * | 2018-09-20 | 2020-09-08 | 百度在线网络技术(北京)有限公司 | Block chain intelligent contract verification method and device and storage medium |
-
2018
- 2018-09-20 CN CN201811101341.2A patent/CN109345388B/en active Active
-
2019
- 2019-06-17 JP JP2020544505A patent/JP7018517B2/en active Active
- 2019-06-17 EP EP19863164.0A patent/EP3678346B1/en active Active
- 2019-06-17 US US16/969,752 patent/US20200412526A1/en not_active Abandoned
- 2019-06-17 WO PCT/CN2019/091475 patent/WO2020057196A1/en active Application Filing
- 2019-06-17 KR KR1020207019610A patent/KR102431459B1/en active IP Right Grant
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111884807A (en) * | 2020-07-13 | 2020-11-03 | 腾讯科技(深圳)有限公司 | Article reservation method, apparatus, device and medium based on block chain |
CN111884807B (en) * | 2020-07-13 | 2021-10-26 | 腾讯科技(深圳)有限公司 | Article reservation method, apparatus, device and medium based on block chain |
WO2022087834A1 (en) * | 2020-10-27 | 2022-05-05 | Alipay (Hangzhou) Information Technology Co., Ltd. | Blockchain system having efficient world state data structures |
CN113259135A (en) * | 2021-07-06 | 2021-08-13 | 常州市建筑科学研究院集团股份有限公司 | Lightweight blockchain communication authentication device and method for detecting data tamper |
CN113259135B (en) * | 2021-07-06 | 2022-01-21 | 常州市建筑科学研究院集团股份有限公司 | Lightweight blockchain communication authentication device and method for detecting data tamper |
CN113657900A (en) * | 2021-07-13 | 2021-11-16 | 中国人民银行数字货币研究所 | Cross-chain transaction verification method and system and cross-chain transaction system |
CN113657900B (en) * | 2021-07-13 | 2024-03-22 | 中国人民银行数字货币研究所 | Cross-chain transaction verification method and system and cross-chain transaction system |
WO2023148042A1 (en) * | 2022-02-07 | 2023-08-10 | Nchain Licensing Ag | Blockchain based privacy enhanced outsourced data storage |
Also Published As
Publication number | Publication date |
---|---|
US20200412526A1 (en) | 2020-12-31 |
KR20200095540A (en) | 2020-08-10 |
WO2020057196A1 (en) | 2020-03-26 |
EP3678346B1 (en) | 2022-09-07 |
EP3678346A4 (en) | 2021-09-29 |
CN109345388B (en) | 2020-09-08 |
KR102431459B1 (en) | 2022-08-11 |
JP7018517B2 (en) | 2022-02-10 |
JP2021515311A (en) | 2021-06-17 |
CN109345388A (en) | 2019-02-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3678346B1 (en) | Blockchain smart contract verification method and apparatus, and storage medium | |
CN109034809B (en) | Block chain generation method and device, block chain node and storage medium | |
CN109242500B (en) | Block chain transaction validity verification method and device and storage medium | |
US20210049715A1 (en) | Blockchain-based data procesing method, apparatus, and electronic device | |
CN107679863B (en) | Block chain system and method for quickly verifying block | |
CN111008201B (en) | Method and apparatus for parallel modification and reading of state trees | |
CN109255056B (en) | Data reference processing method, device, equipment and storage medium of block chain | |
CN111444196B (en) | Method, device and equipment for generating Hash of global state in block chain type account book | |
WO2020220251A1 (en) | Data processing method for blockchain system and block generating method | |
CN109885614B (en) | Data synchronization method and device | |
CN112037058B (en) | Data verification method, device and storage medium | |
CN109446208A (en) | A kind of date storage method, computer readable storage medium and server | |
CN109189859B (en) | Node initialization method and device in block chain network | |
CN110659905A (en) | Transaction verification method, device, terminal equipment and storage medium | |
WO2023184052A1 (en) | Data processing method, blockchain node and blockchain system | |
CN115237444A (en) | Concurrent control method, device and equipment based on version number and storage medium | |
CN117539925A (en) | Data processing method, device, medium and equipment | |
CN110928923A (en) | Data storage method and system based on block chain | |
CN112579591A (en) | Data verification method and device, electronic equipment and computer readable storage medium | |
CN111339089B (en) | Data storage and acquisition method and device applied to blockchain | |
CN111147477B (en) | Verification method and device based on block chain network | |
CN113342647A (en) | Test data generation method and device | |
CN111737260A (en) | Method and system for checking data copying consistency | |
CN109165208A (en) | It is a kind of for loading data into the method and system in database | |
CN115250231B (en) | Application configuration method and device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20200331 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20210827 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: G06Q 40/04 20120101ALI20210823BHEP Ipc: H04L 29/06 20060101AFI20210823BHEP |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602019019438 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0029060000 Ipc: G06F0016901000 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04L 9/32 20060101ALI20220328BHEP Ipc: G06Q 40/00 20120101ALI20220328BHEP Ipc: G06Q 30/06 20120101ALI20220328BHEP Ipc: G06F 16/901 20190101AFI20220328BHEP |
|
INTG | Intention to grant announced |
Effective date: 20220421 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP Ref country code: AT Ref legal event code: REF Ref document number: 1517659 Country of ref document: AT Kind code of ref document: T Effective date: 20220915 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602019019438 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG9D |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20220907 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20221207 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1517659 Country of ref document: AT Kind code of ref document: T Effective date: 20220907 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20221208 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20230109 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20230107 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602019019438 Country of ref document: DE |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230526 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: IT Payment date: 20230526 Year of fee payment: 5 Ref country code: FR Payment date: 20230523 Year of fee payment: 5 |
|
26N | No opposition filed |
Effective date: 20230608 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: CH Payment date: 20230702 Year of fee payment: 5 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20220907 |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20230630 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230617 |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: MM4A |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230617 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230617 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230617 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20230630 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20240606 Year of fee payment: 6 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20240604 Year of fee payment: 6 |