KR20200088827A - Blockchain-based smart contract calling method and device, electronic device - Google Patents

Abstract

Implementations of the present specification disclose blockchain-based smart contract call processing. In one implementation, a target transaction is received that includes the call data used to initiate the call of the smart contract, where at least a portion of the call data is a data digest of the target data stored in a third-party storage system interconnected with the blockchain. It includes. Target data corresponding to the data digest is queried from the third-party storage system. Verification of content against target data is performed by determining whether the execution condition is satisfied. In response to determining that verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the target transaction. After the smart contract calculation is completed, the calculation results are stored in the blockchain's distributed database.

Description

Blockchain-based smart contract calling method and device, electronic device

Cross reference to related applications

This application claims priority to Chinese Patent Application No. 201810681249.1, filed June 27, 2018, which is hereby incorporated by reference in its entirety.

Technology field

One or more implementations of the present specification relate to the field of blockchain technologies, and in particular, to a method and apparatus for blockchain-based smart contract invocation, and an electronic device.

Blockchain technology, also referred to as distributed ledger technology, is the latest technology in which several computing devices jointly participate in "accounting" to maintain a complete distributed database. Blockchain technology is characterized by decentralization and transparency, and each computing device can record data in a database, and data can be rapidly synchronized between computing devices. Accordingly, blockchain technology has been widely applied in many technical fields.

The present specification provides a blockchain-based smart contract calling method, comprising: receiving a target transaction used to initiate a call of a smart contract, where the target transaction includes the call data, and the call At least a portion of the data includes a data digest of target data stored in a third-party storage system interconnected with the blockchain; Querying target data corresponding to a data digest from a third-party storage system, and performing content verification on the target data; And when the verification of the target data is successful, calling the smart contract to perform smart contract calculation on the call data in the target transaction, and storing the calculation result in the distributed database of the blockchain after the smart contract calculation is completed. do.

Optionally, the third-party storage system stores the mapping relationship between the target data and the data digest of the target data; Querying the target data corresponding to the data digest from the third-party storage system: Initiating a query to the third-party storage system by using the data digest as a query index to query the target data corresponding to the data digest. Steps.

Optionally, performing content verification on the target data includes: calculating a data digest of the target data based on a predetermined digest algorithm; Determining whether the calculated data digest matches the data digest of the target data in the target transaction; And if the calculated data digest matches the data digest of the target data in the target transaction, determining that verification of the target data is successful.

Optionally, the third-party storage system includes a centralized content addressable storage (CAS) system or a distributed CAS system.

Optionally, the blockchain is any member blockchain in a consortium blockchain that includes several member blockchains.

Optionally, the third-party storage system is another member blockchain having a cross-chain data reference relationship with the blockchain in the consortium blockchain.

The present specification further provides a blockchain-based smart contract calling device, which comprises: a receiving module, configured to receive a target transaction used to initiate a call of the smart contract, wherein the target transaction includes the calling data, and the calling At least a portion of the data includes a data digest of target data stored in a third-party storage system interconnected with the blockchain; A query module configured to query target data corresponding to a data digest from a third-party storage system and perform content verification on the target data; And when the verification of the target data is successful, a smart contract is called to perform smart contract calculation on the call data in the target transaction, and a call configured to store the calculation result in the distributed database of the blockchain after the smart contract calculation is completed. Includes modules.

Optionally, the third-party storage system stores the mapping relationship between the target data and the data digest of the target data; The query module is configured to initiate a query to a third-party storage system by using the data digest as a query index, to query target data corresponding to the data digest.

Optionally, the query module: calculates a data digest of the target data based on a predetermined digest algorithm; Determine whether the calculated data digest matches the data digest of the target data in the target transaction; If the calculated data digest matches the data digest of the target data in the target transaction, it is further configured to determine that verification of the target data is successful.

Optionally, the third party storage system includes a centralized content addressable storage (CAS) system or a distributed CAS system.

Optionally, the blockchain is any member blockchain in a consortium blockchain that includes several member blockchains.

Optionally, the third-party storage system is another member blockchain having a cross-chain data reference relationship with the blockchain in the consortium blockchain.

The present specification further provides an electronic device, the electronic device comprising: a processor; And a memory configured to store machine executable instructions, wherein by reading and executing machine executable instructions stored in memory and corresponding to control logic of a blockchain based smart contract call, the processor: Receiving a target transaction used to initiate, wherein the target transaction includes call data, and at least a portion of the call data includes a data digest of target data stored in a third-party storage system interconnected with the blockchain; Query target data corresponding to a data digest from a third-party storage system, and perform content verification on the target data; When verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the target transaction, and after the smart contract calculation is completed, it is configured to store the calculation results in the distributed database of the blockchain.

According to the previous implementations, the transaction used to initiate the call of the smart contract includes a data digest of the target data stored in the third-party storage system, and the node device receiving the transaction in the blockchain is based on the data digest. Query the corresponding target data from a third-party storage system, perform content verification on the target data, and call the smart contract to perform smart contract calculation on the call data in the transaction after the verification of the target data is successful Then, after the smart contract calculation is completed, the calculation result can be stored in the distributed database of the blockchain. As such, the target data stored in the third-party storage system interconnected with the blockchain is referred to as call data in the transaction used to initiate the call of the smart contract, blocking the original content of the target data stored in the third-party storage system. Blockchain data storage redundancy caused by synchronization with each node device in the chain can be mitigated.

1 is a flow chart illustrating a method for invoking a smart contract based on a blockchain, according to an exemplary implementation.
2 is a schematic structural diagram illustrating a consortium blockchain, according to an example implementation.
3 is a schematic structural diagram illustrating an electronic device, according to an example implementation.
Fig. 4 is a block diagram illustrating a blockchain-based smart contract calling device according to an exemplary implementation.

In the conventional smart contract calling process of the blockchain, the call data required to call the smart contract (i.e., call parameters input to the smart contract) is typically stored in the blockchain's distributed database (i.e., the blockchain ledger). Data content generated from data content and stored in an external memory cannot be referenced. Accordingly, when each node device in the blockchain network calls a smart contract, the call data used for smart contract calculation is typically generated from the chain, thereby forming a "closed data usage loop".

However, this specification discloses a technical solution in which unalterable data content stored on a third-party storage platform is referred to as transaction content when a smart contract is invoked, in order to resolve the "closed data usage loop" of the blockchain. Aim.

During implementation, the blockchain can be interconnected with a third-party storage system in advance, and the third-party storage system can pre-store several pieces of immutable data content that can be referenced in a smart contract deployed on the blockchain.

When initiating a call to the smart contract, a member user accessing the blockchain adds a data digest of the data content stored in the third-party storage system to the transaction used to initiate the call of the smart contract, and the third party Data contents stored in the storage system can be referred to as call data.

Upon receiving the transaction posted by the member user, the node device in the blockchain initiates a query to the third-party storage system based on the data digest, querying the data content corresponding to the data digest, and identifying data Content verification can be performed on the content. When content verification is successful, the node device calls the smart contract to declare the smart contract program declared in the smart contract, performs smart contract calculation on the complete call data in the transaction, and after the smart contract calculation is completed, the blockchain The calculation results can be stored in a distributed database.

In the previous implementation, the transaction used to initiate the invocation of the smart contract includes a data digest of target data stored in a third-party storage system, where the node device receiving the transaction in the blockchain is based on the data digest. Query the corresponding target data from the child storage system, perform content verification on the target data, and after successful verification on the target data, call the smart contract to perform smart contract calculation on the call data in the transaction, After the smart contract calculation is completed, the calculation results can be stored in the blockchain's distributed database. As such, the target data stored in the third-party storage system interconnected with the blockchain is referred to as call data in the transaction used to initiate the call of the smart contract, blocking the original content of the target data stored in the third-party storage system. The redundancy of blockchain data storage caused by synchronization with each node device in the chain can be mitigated.

The following describes this specification by using implementations in relation to application scenarios.

Referring to FIG. 1, FIG. 1 illustrates a method for calling a smart contract based on a blockchain according to an implementation of the present specification. This method is applied to a node device in a blockchain, and includes the following steps.

Step 102: Receive the target transaction used to initiate the call of the smart contract, where the target transaction includes the call data, and at least a portion of the call data is of target data stored in a third-party storage system interconnected with the blockchain. Includes data digest.

Step 104: Query target data corresponding to the data digest from the third-party storage system, and perform content verification on the target data.

Step 106: If the verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the target transaction, and the calculation result is stored in the distributed database of the blockchain after the smart contract calculation is completed.

The blockchain described herein may include any type of blockchain network in which immutable data content stored in a third-party storage system interconnected with the blockchain can be referred to as call data by a supported smart contract. Can.

For example, in one scenario, the blockchain may be any member blockchain in a consortium blockchain that includes several member blockchains. In the consortium blockchain, data content stored in other member blockchains can be referred to as call data across the chains by each smart contract supported by each member blockchain.

The third party storage system includes a content addressable storage (CAS) platform that provides a reliable data storage service for the blockchain. Content addressability means that addressing is performed based on data content instead of data storage offset in the storage system.

On the CAS platform, the data digest of the stored data content can be used as a query index of the original data content, and the mapping relationship between the query index and the original data content is stored, so that the data query party uses the data digest as the query index to make the CAS platform From the corresponding original data content can be queried.

For example, in one implementation, the data digest can be a hash value obtained by performing a hash calculation on data content. The data query party may use the hash value as a query index to query the original data content corresponding to the hash value from the CAS platform.

In practical applications, the third party storage system may include a conventional centralized content addressable storage (CAS) system, or may include a decentralized distributed CAS system.

For example, in one scenario, the blockchain may be any member blockchain in a consortium blockchain that includes several member blockchains. Additionally, a third-party storage system may be a distributed system, such as an object storage service (OSS) architecture, that can be deployed on a consortium blockchain and interconnected with each member blockchain on the consortium blockchain. Can.

Alternatively, in another example, in the consortium blockchain, another member blockchain with a cross-chain data reference relationship with the blockchain is used as a third-party storage system interconnected with the blockchain, crossing between member blockchains Chain data references can be implemented. In other words, the third-party storage system may be another blockchain having a cross-chain reference relationship with the blockchain. The technical solutions of the present specification are consortium blockchains in which the blockchain includes several member blockchains, in relation to "disposition of a third-party storage system", "reference of call data", and "calling and executing smart contracts". It is explained in detail below by using the example, which is a member blockchain in.

(1) Arrangement of third party storage systems

In this specification, the operator can pre-establish a consortium blockchain that includes several member blockchains. In the consortium blockchain, each member blockchain is a consortium member of the consortium blockchain. The preceding blockchain may be any member blockchain in the consortium blockchain.

Operators of the consortium blockchain can further deploy third-party storage systems on the consortium blockchain. The third party storage system is interconnected with each member blockchain in the consortium blockchain, and provides a reliable data storage service for each member blockchain.

For example, a third-party storage system can provide a consistently reliable API access interface for each member blockchain, so that each member blockchain in the consortium blockchain accesses the API access interface. It can be interconnected with a storage system.

During the deployment of a third party storage system to the consortium blockchain, a global third party storage system may be deployed for the consortium blockchain, or an independent third party storage system for each member blockchain in the consortium blockchain It can be placed. Implementations are not limited in this specification.

In the present specification, the third-party storage system may be a CAS system supporting content addressability. In practical applications, the third-party storage system can be a conventional centralized CAS system or a distributed CAS system.

The distributed CAS system may include a conventional centralized distributed system and a decentralized distributed system.

In the illustrated implementation, the third-party storage system may be a centralized distributed system based on an OSS architecture that is disposed on the consortium blockchain and can be interconnected with each member blockchain on the consortium blockchain.

In another illustrated implementation, the third party storage system can be a decentralized distributed system. During implementation, other member blockchains in the consortium blockchain that have a cross-chain data reference relationship with the blockchain can be used as a third-party storage system interconnected with the blockchain. In other words, any member blockchain in the consortium blockchain can be used as a third-party storage system interconnected with other member blockchains to implement cross-chain data references.

For example, in one scenario, the operator can establish a consortium blockchain based on actual service requirements and assign different service roles to member blockchains in the consortium blockchain. Specifically, the consortium blockchain can correspond to a complete service process, and each member blockchain can correspond to one subprocess of the complete service process.

The consortium blockchain established by the operator based on the service requirement "online housing rental transaction" is used as an example, and each member blockchain forming the consortium blockchain includes "transaction chain", "authentication chain", and "data Chain”. The "transaction chain", "authentication chain", and "data chain" may separately correspond to one subprocess of the service process of "online home rental transaction". For example, "data chain" is used to maintain real-name data of home rental users; "Authentication chain" is used to complete real estate authentication for each user's home rental; The "transaction chain" is used to complete online home rental transactions.

Thereafter, the operator can establish a consortium blockchain as a topology diagram of a Directed Acyclic Graph (DAG) topology at the service level based on a unidirectional cross-chain data reference relationship between member blockchains.

It is worth noting that the one-way cross-chain data reference relationship between member blockchains typically depends on actual service requirements and is not limited in this specification.

For example, referring to FIG. 2, FIG. 2 is a schematic diagram illustrating a consortium blockchain of the DAG structure shown in one example.

As shown in Fig. 2, the consortium blockchain established by the operator based on the service requirement "online housing rental transaction" is still used as an example, and each of the member blockchains forming the consortium blockchain is a "transaction chain". , "Authentication Chain", and "Data Chain". The "data chain" is used to maintain the real-name data of the home rental user, and the user can store the real-name data in the distributed database of the "data chain" by posting transactions to the "data chain". "Authentication chain" refers to the user's real-name data posted on the "data chain", is used to complete real-name authentication for real estate rental by user, the user completes real-name authentication by posting a transaction in the "authentication chain", Real-time authentication results can be posted in a distributed database of "authentication chains." The "transaction chain" is used to refer to the actual authentication result per user posted in the "authentication chain", so that the user completes the online home rental transaction by posting the transaction in the "transaction chain", and the distributed database of the "authentication chain" You can post the transaction results in

Another member blockchain that has a cross-chain data reference relationship with any target member blockchain in the consortium blockchain is used as a distributed storage platform interconnected with the target member blockchain.

Cross-chain data references between member blockchains can be implemented at the service level.

Additionally, when the member blockchain used as a third-party storage system calls and executes a smart contract in which it is deployed, the target data stored in the third-party storage system is referenced in the call data used for smart contract calculation, The original content of the referenced target data no longer needs to be synchronized with each node device in the target member blockchain, and the target member blockchain no longer needs to store the original content of the referenced target data.

Accordingly, the target member blockchain no longer establishes additional data association between the original content of the target data stored in the target member blockchain and the referenced target data synchronized from the member blockchain used as a third party storage system. There is no need to set up, and by using only the data digest of the referenced target data, data association between the referenced target data in two different blockchains is implemented, thereby allowing the member blockchain to be used as a third party storage system. From the point of view of service semantics by the stored referenced target data, it is possible to ensure that the target data referenced in the smart contract placed on the target member blockchain matches.

(2) Reference of call data

In the present specification, a user who needs to access the consortium blockchain can perform user registration in advance on the consortium blockchain to obtain a pair of public and private keys returned by the consortium blockchain. After registration is completed, the consortium blockchain can create a corresponding account object for the user.

Users who have completed registration access each member blockchain by using the API interface provided by each member blockchain on the consortium blockchain, and signed transactions based on the private key held for each member blockchain By posting, you can call smart contracts placed on each member blockchain.

The "transaction chain" in the consortium blockchain shown in Fig. 2 is used as an example. The operator of the consortium blockchain can post the smart contract used to complete the online rental home accounting, in the "transaction chain", and the user can post the transaction in the "transaction chain", triggering the call of the smart contract , You can complete the online housing rental transaction accounting.

The detailed process in which the operator of the consortium blockchain places smart contracts on the consortium blockchain is omitted here for simplicity. Those skilled in the art can refer to related technical records when implementing the technical solutions described herein.

For example, multiple members who have access to the consortium blockchain jointly negotiate smart contracts and declare smart contract programs developed in smart contracts (e.g. program code related to some functions that can be called). Later, the smart contract can be published on the consortium blockchain, so that the node device on the consortium blockchain performs consensus processing, and after the consensus is achieved, records the smart contract in the distributed database of the consortium blockchain and Save to complete the deployment of the smart contract.

In the present specification, an operator of the consortium blockchain can develop client software (eg, APP) for member users who have access to the consortium blockchain, and member users are supported by the consortium blockchain by using client software By assembling transaction data based on the standardized transaction format, and calling the API interface provided by each member blockchain, publish the assembled transaction data on the target member blockchain in the consortium blockchain specified by the member user. , It can initiate the call of the smart contract placed on the target member blockchain.

Transaction data assembled by the member user by using the client software may include call data provided by the member user, and the call data is used as a call parameter input to the smart contract. At least a portion of the call data can be replaced with a data digest.

In the illustrated implementation, when a member user assembles transaction data that needs to be executed on the target member blockchain by using the client software, the member user, by using the client software, provides call data that needs to be included in the transaction. You can write The client software can parse the call data created by the member user to determine whether the data stored in the third-party storage system interconnected with the target member blockchain is present in the call data created by the member user. It is possible to determine whether data stored in the third-party storage system is referenced in the call data created by the member user.

When data stored in the third-party storage system is present in the call data created by the member user, a data digest (i.e., query index) corresponding to the call data can be queried from the third-party storage system, or a third party The data digest can be recalculated for the transaction content based on the same data digest algorithm supported by the storage system, and the data digest can then be written in a standard transaction format.

For example, during implementation, the data digest field used to contain the call data can be extended to the standard transaction format supported by the consortium blockchain. When assembling transactional data in a standard transactional format, the client software can fill all data digests of reference data stored in a third-party storage system into a data digest field.

(3) Calling and executing smart contracts

In this specification, after receiving a transaction posted by a member user based on a private key, the node device in the target member blockchain first identifies the user's identity based on the public key corresponding to the private key held by the user. Identity authentication may be performed.

For example, in practical applications, the user can sign a transaction initiated based on the private key held, and the node device in the blockchain signs based on the public key corresponding to the private key held by the user. Can authenticate. If the signature authentication succeeds, the user's identity authentication succeeds.

After the identity authentication is successful, the node device can initiate consensus processing for the transaction in the target member blockchain, and after the consensus is achieved, the transaction can be recorded and stored in the distributed database of the target member blockchain. Once the transaction has been successfully recorded and stored in the target member blockchain's distributed database, calls to the smart contract can be subsequently triggered based on the transaction recorded in the distributed database to execute the smart contract program declared in the smart contract. have.

For example, during implementation, stringent triggering execution conditions are typically predetermined for a smart contract program in a smart contract. The smart contract periodically checks whether the transaction currently recorded in the distributed database satisfies the execution condition, adds the transaction stored in the distributed database to the transaction queue to be verified, and executes the transaction queue to be verified. Consensus processing can be performed. If consensus is achieved, the execution of the smart contract program declared in the smart contract can be triggered.

It is worth noting that the consensus algorithm used when consensus processing is performed for transactions on the target member blockchain is not limited in this specification. The consensus algorithms supported by member blockchains can be the same or different. For example, the consortium blockchain can use a mainstream consensus algorithm such as PBFT, or the consortium blockchain can independently develop consensus algorithms.

In the present specification, when a call of a smart contract is triggered based on a transaction to execute a smart contract program declared in the smart contract, the smart contract first parses the call data included in the transaction, to the call data included in the transaction. You can decide whether there is a data digest or not.

For example, the node device, through parsing, determines whether the data digest field extended from the standard transaction format and used to include transaction content is a null value, thereby digesting the data in the transaction content included in the transaction. You can decide whether there is.

When there is a data digest in the call data included in the transaction, data content stored in the third-party storage system is referred to in some call data in the transaction. In such a case, in order to obtain the complete call data included in the transaction, the smart contract can query the target data corresponding to the data digest from a third-party storage system interconnected with the target member blockchain.

During implementation, the smart contract can establish a query request, add a data digest to the query request by using the data digest as a query index, and then submit the query request to a third-party storage system. After receiving the query request, the third-party storage system reads the query index from the query request, and then, based on the query index, examines mapping relationships between the locally stored data content and the data digest, corresponding to the query index The target data can be queried and the identified target data can be returned to the smart contract.

It is worth noting that the third-party storage system may be another member blockchain having a cross-chain reference relationship with the target member blockchain. Accordingly, query requests established by smart contracts can be broadcast to node devices in other member blockchains used as third party storage systems.

In practical applications, different query results may be obtained after a smart contract sends a query request to node devices in another member blockchain, due to differences between consensus algorithms used in different member blockchains.

For example, consensus algorithms used in blockchains can be generally classified into two types based on distributed consistency. Distributed consistency means that data stored on all node devices in the blockchain are completely identical after consensus is achieved by using the consensus algorithm.

The first type of consensus algorithm is a consensus algorithm that can guarantee distributed consistency of each node device. For example, a fault tolerance mechanism is used to achieve consensus in the PBFT consensus algorithm, so that the data stored by each node device is exactly the same after consensus is achieved.

The second type of consensus algorithm is a consensus algorithm that cannot guarantee distributed consistency of each node device. For example, a competition-based ledger mechanism is used to reach consensus in PoS or PoW consensus algorithms. As a result, it cannot be guaranteed that the data stored by each node device after the agreement is achieved is the same. The PoW consensus algorithm is used as an example. A node device that has obtained ledger authority through workload calculation may only store data of blocks proposed by the node device, and consequently, block data stored locally by the node devices may be different.

Accordingly, once the consensus algorithm used by another member blockchain used as a third-party storage system is the second type of consensus algorithm described above, some node devices cannot identify the related data locally, but other node devices It is possible that smart contracts can be identified after sending a query request to each node device in a different member blockchain.

In one scenario, if the consensus algorithm used by another member blockchain used as a third-party storage system is the first type of consensus algorithm described above, the smart contract may use a query client software that also supports the consensus algorithm. , By performing data query on other member blockchains, it is possible to obtain the result of the consistency query.

The PBFT consensus algorithm is used as an example. It is assumed that the number of node devices in another member blockchain used as a third-party storage system is 3f+1. If the same query result returned by f+1 node devices is received after the smart contract transmits a query request to node devices in another member blockchain separately by using the query client software, the query result is It can be considered as the result of the final query.

In one scenario, if the consensus algorithm used by another member blockchain used as a third-party storage system is the second type of consensus algorithm described above, then a stable and reliable node device as a query node in another member blockchain Needs to be specified. The smart contract may send a query request to the query node and search data stored locally by the query node for related data.

In other words, in such a scenario, data stored locally by the query node is the result of a match to the data referencing party, and only data stored locally by the query node will be referenced by smart contracts deployed on other member blockchains. Can be considered as possible.

In practical applications, it is worth noting that the query request may include some auxiliary query parameters, in addition to the data digest used as a query index, to quickly identify target data corresponding to the data digest. .

For example, a third-party storage system interconnected with a target member blockchain is another member blockchain having a cross-chain data reference relationship with the target member blockchain. Referenced data content and corresponding data digests stored in other member blockchains used as third party storage systems are typically stored in a distributed database on the blockchain in the form of blocks. Accordingly, for ease of query, the query request may further include auxiliary query parameters such as a block number and a sequence number of a member blockchain in which the data digest is located.

In the present specification, after the smart contract identifies the target data corresponding to the data digest included in the received transaction from the third-party storage system interconnected with the target member blockchain, the call of the smart contract is initiated, in the smart contract You can run the declared smart contract program and perform smart contract calculation on complete call data included in the transaction.

First, the smart contract may perform content verification on the identified target data in order to correct that the identified target data matches data content corresponding to the data digest included in the transaction.

During implementation, the smart contract recalculates the data digest of the identified target data, and then matches the data digest contained in the received transaction with the recalculated data digest so that the recalculated data digest is included in the received transaction. You can decide whether it matches the data digest.

If they match, content verification for the identified target data is successful, and the transaction is a valid transaction. The smart contract can acquire complete call data included in the transaction, use the complete call parameters as input parameters of the smart contract program declared in the smart contract, and input the parameters into the smart contract program for smart contract calculation.

If they do not match, content verification against the identified target data fails. In such a case, the referenced target data of the original stored in the third-party storage system may be modified and updated due to system unreliability. As a result, the transaction is an invalid transaction, and the process that called the smart contract can be terminated immediately.

When the smart contract recalculates the data digest of the identified target data, the data structure of the target data, the encoding method for the target data, and the digest algorithm used all need to match those of the third-party storage system, so that the node It is worth noting that the device and the third-party storage system ensure that the same calculation result can be obtained when performing data digest calculation on the same target data.

In this specification, after the complete call data included in the transaction is used as an input parameter and entered into the smart contract program declared in the smart contract to complete the smart contract calculation, the execution of the transaction is completed, and the calculation result of the smart contract calculation ( That is, the execution result of the transaction) may be additionally stored in the distributed database of the target member blockchain.

The information recorded in the blockchain's distributed database typically includes transaction logs and transaction status.

The transaction log is used to store the transaction log, contains blocks (blocks) connected in series in the order of occurrence, and is a transaction record in a distributed database. After consensus on the transaction is achieved, the transaction can be recorded and stored in the corresponding block of the transaction log.

The transaction state is used to store status changes caused by the execution of transactions recorded in the distributed database. For example, a blockchain typically includes many small objects (eg, account object, contract object, and asset object). Whenever a transaction is recorded in the blockchain's distributed database, the status associated with the transaction is updated synchronously after the execution of the transaction is completed. An online transfer transaction submitted to the blockchain is used as an example. After the transaction is executed by calling the related smart contract, the balance of the account object associated with the current transfer is synchronously updated.

In such a case, after completing the smart contract calculation for the complete call data included in the transaction, the smart contract additionally stores the calculation result of the smart contract calculation in the transaction state, thereby changing the status change of the related object caused by the transaction. Can be updated. Online transfer transactions submitted to the blockchain are still used as an example. After completing the smart contract calculation for the complete call data included in the transaction, the smart contract can update the balance of the account object related to the current transfer in the transaction state.

In the previous implementation, the transaction used to initiate the invocation of the smart contract includes a data digest of target data stored in a third-party storage system, where the node device receiving the transaction in the blockchain is based on the data digest. The corresponding target data may be queried from the child storage system, and content verification may be performed on the target data. After the verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the transaction, and the calculation result is stored in the distributed database of the blockchain after the smart contract calculation is completed. As such, the target data stored in the third-party storage system interconnected with the blockchain is referred to as call data in the transaction used to initiate the call of the smart contract, blocking the original content of the target data stored in the third-party storage system. The redundancy of blockchain data storage caused by synchronization with each node device in the chain can be mitigated.

For example, a third-party storage system interconnected with a target blockchain is another blockchain having a cross-chain data reference relationship with the blockchain. It is assumed that another blockchain includes 5 node devices, and the target blockchain includes 50 node devices. If the referenced data content stored in the other blockchain is still synchronized with the target blockchain, the referenced data content needs to be synchronized separately from the 50 nodes in the target blockchain, so the referenced data content in the target blockchain A large amount of redundancy results. However, if the target blockchain only stores the data digest of the referenced data content, other blockchains do not need to synchronize the referenced data content separately with 50 node devices. In this way, data storage redundancy in the target blockchain can be significantly reduced.

Corresponding to the method implementation, this specification further provides an implementation of a blockchain-based smart contract calling device. In the present specification, an implementation of a blockchain-based smart contract calling device can be applied to an electronic device. The device implementation can be implemented by software, hardware, or a combination of hardware and software. Software implementation is used as an example. As a logical apparatus, an apparatus is formed by reading a corresponding computer program instruction from a nonvolatile memory to a memory of an electronic device by a processor of an electronic device in which the apparatus is located. In terms of hardware, as shown in FIG. 3, FIG. 3 is a diagram illustrating a hardware structure of an electronic device in which a blockchain-based smart contract calling device is located, according to the present specification. In addition to the processor, memory, network interface, and non-volatile memory shown in FIG. 3, the electronic device in which the apparatus is located in this implementation may typically include other hardware based on the actual functionality of the electronic device. Details are omitted for simplicity.

4 is a block diagram illustrating a blockchain-based smart contract calling device according to an exemplary implementation of the present specification.

Referring to FIG. 4, the blockchain-based smart contract calling device 40 may be applied to the electronic device shown in FIG. 3, and includes a receiving module 401, a query module 402, and a calling module 403 .

The receiving module 401 is configured to receive the target transaction used to initiate the call of the smart contract, where the target transaction includes the call data, and at least a portion of the call data is stored by a third party interconnected with the blockchain Contains a data digest of target data stored in the system.

The query module 402 is configured to query target data corresponding to a data digest from a third-party storage system, and to perform content verification on the target data.

The calling module 403: When the verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the target transaction, and after the smart contract calculation is completed, the calculation result in the distributed database of the blockchain It is configured to store.

In this implementation, the third-party storage system stores the mapping relationship between the target data and the data digest of the target data.

The query module 402 is configured to initiate a query to a third-party storage system by using the data digest as a query index, to query target data corresponding to the data digest.

In this implementation, the query module 402: calculates a data digest of the target data based on a predetermined digest algorithm; Determine whether the calculated data digest matches the data digest of the target data in the target transaction; If the calculated data digest matches the data digest of the target data in the target transaction, it is further configured to determine that verification of the target data is successful.

In this implementation, the third-party storage system comprises a centralized content addressable storage (CAS) system or a distributed CAS system.

In this implementation, the blockchain is any member blockchain in a consortium blockchain that includes several member blockchains.

In this implementation, the third-party storage system is another member blockchain having a cross-chain data reference relationship with the blockchain in the consortium blockchain.

For the process of implementation of the functions and roles of modules in the device, references can be made to the implementation process of corresponding steps in the preceding method. Details are omitted here for simplicity.

Since the device implementation basically corresponds to the method implementation, reference may be made to some descriptions in the method implementation for related parts. The device implementation described above is merely an example. Modules described as separate parts may or may not be physically separated, and parts displayed as modules may or may not be physical modules, or may be located in one location, or multiple networks It can be distributed on modules. Some or all of the modules may be selected based on actual requirements to achieve the goals of the solutions herein. Those skilled in the art can understand and implement the implementations herein without creative efforts.

The system, apparatus, or module illustrated in the previous implementations can be implemented by using a computer chip or entity, or by using a product having a specific function. A typical implementation device is a computer, and the form of the computer is a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email receiving and sending device, game console , A tablet computer, a wearable device, or any combination of these devices.

Corresponding to the previous method implementation, this specification further provides one implementation of the electronic device. The electronic device includes a processor and memory configured to store machine-executable instructions. The processor and memory are typically connected to each other by using an internal bus. In another possible implementation, the device can further include an external interface, such that the device can communicate with other devices or components.

In this implementation, by reading and executing machine-executable instructions stored in memory and corresponding to the control logic of the blockchain-based smart contract call, the processor: receives the target transaction used to initiate the call of the smart contract-where The target transaction includes call data, and at least a portion of the call data includes a data digest of target data stored in a third-party storage system interconnected with the blockchain; Query target data corresponding to a data digest from a third-party storage system, and perform content verification on the target data; When verification of the target data is successful, the smart contract is called to perform smart contract calculation on the call data in the target transaction, and after the smart contract calculation is completed, it is configured to store the calculation results in the distributed database of the blockchain.

In this implementation, the third-party storage system stores the mapping relationship between the target data and the data digest of the target data.

By reading and executing machine-executable instructions stored in memory and corresponding to the control logic of a blockchain-based smart contract call, the processor: initiates a query to a third-party storage system by using a data digest as a query index, thereby It is configured to query target data corresponding to the digest.

In this implementation, by reading and executing machine-executable instructions stored in memory and corresponding to control logic of a blockchain-based smart contract call, the processor: calculates a data digest of the target data based on a predetermined digest algorithm; Determine whether the calculated data digest matches the data digest of the target data in the target transaction; If the calculated data digest matches the data digest of the target data in the target transaction, it is configured to determine that verification of the target data is successful.

Those skilled in the art can readily grasp other implementations of the present specification after contemplating the present specification and carrying out the present disclosure herein. This specification is intended to cover any variations, uses, or adaptations of this specification, and these variations, uses, or adaptations follow the general principles of this specification and are not disclosed in the art of this specification. Includes techniques or common knowledge. The specification and implementations are to be considered as examples only, and the true scope and spirit of the specification is indicated by the following claims.

It should be understood that the present specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from the scope of the present disclosure. The scope of this specification is limited only by the appended claims.

The preceding descriptions are merely preferred implementations of this specification and are not intended to limit the specification. Any modification, equivalent replacement, or improvement made without departing from the spirit and principles of this specification should fall within the protection scope of this specification.

The embodiments and operations described herein can be implemented with a digital electronic circuitry, with computer software, firmware, or hardware including the structures disclosed herein, or a combination of one or more of these. The operations may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources. A data processing apparatus, computer, or computing device is an apparatus for processing data, including, for example, a programmable processor, a computer, a system on a chip, or a number of the foregoing, or combinations thereof , Devices, and machines. The device may be a special purpose logic circuit, such as a central processing unit (CPU), field programmable gate array (FPGA) or application-specific integrated circuit (ASIC) ). The device may also generate code that creates an execution environment for the computer program in question, for example, code constituting the processor firmware, protocol stack, database management system, operating system (eg, an operating system or a combination of operating systems), Cross-platform runtime environment, a virtual machine, or a combination of one or more of these. The device and execution environment can realize various computing model infrastructures such as web services, distributed computing and grid computing infrastructures.

A computer program (eg, also known as a program, software, software application, software module, software unit, script, or code) is any that includes compiled or interpreted languages, declarative or procedural languages. It can be written in a programming language in the form of, and it can be placed in any form including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A program can be part of a file that holds other programs or data (eg, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or multiple adjusted files (eg For example, one or more modules, subprograms, or files that store parts of code). A computer program can be located on one site or distributed across multiple sites and running on multiple computers or interconnected by a communication network.

Processors for the execution of a computer program include, by way of example, both general purpose and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, the processor will receive instructions and data from read-only memory or random access memory, or both. Essential elements of a computer are a processor for performing actions in accordance with instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, or operatively coupled to receive data from or transmit data to them, or both. . The computer can be embedded in another device, such as a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver, or a portable storage device. Devices suitable for storing computer program instructions and data include non-volatile memory, media and memory devices, including, for example, semiconductor memory devices, magnetic disks, and magneto-optical disks. The processor and memory may be supplemented or included in special purpose logic circuitry.

Mobile devices include handsets, user equipment (radio frequency) (UE), mobile phones (eg, smartphones), tablets, wearable devices (eg, smart watches and smart glasses), the human body Implanted devices (eg, biosensors, cochlear implants), or other types of mobile devices. Mobile devices can communicate with various communication networks (described below) wirelessly (eg, using radio frequency (RF) signals). Mobile devices can include sensors to determine characteristics of the mobile device's current environment. Sensors are cameras, microphones, proximity sensors, GPS sensors, motion sensors, accelerometers, ambient light sensors, moisture sensors, gyroscopes, compasses, barometers, fingerprint sensors, face recognition systems , RF sensors (eg, Wi-Fi and cellular radios), thermal sensors, or other types of sensors. For example, cameras may include front or rear facing cameras with movable or fixed lenses, flash, image sensor, and image processor. The camera may be a megapixel camera capable of capturing details for face and/or iris recognition. The camera may form a face recognition system with authentication information and data processors stored in memory or accessed remotely. A face recognition system or one or more sensors, such as microphones, motion sensors, accelerometers, GPS sensors, or RF sensors, can be used for user authentication.

To provide interaction with a user, embodiments may include a display device and an input device, such as a liquid crystal display (LCD) or organic light-emitting diode (LCD) for displaying information to the user. ) (OLED)/virtual-reality (VR)/augmented-reality (AR) display, and a touch screen, keyboard, and pointing device that allow the user to provide input to the computer It can be implemented on a computer. Other types of devices can also be used to provide interaction with the user; For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; Input from the user may be received in any form, including acoustic, voice, or tactile input. Additionally, the computer sends documents to the device used by the user and receives documents from the device; For example, it may interact with the user by sending web pages to a web browser on the user's client device in response to requests received from the web browser.

Embodiments may be implemented using any form or medium of wired or wireless digital data communication (or combinations thereof), for example, computing devices interconnected by a communication network. Examples of interconnected devices are clients and servers that are generally remote from each other, typically interacting through a communication network. The client, for example, the mobile device, may perform the transactions themselves with or through the server, for example, to perform, or authorize, purchase, sale, payment, offer, transfer, or loan transactions. . Such transactions may be in real time, so actions and responses are close in time; For example, an individual perceives that actions and responses occur substantially simultaneously, and the time difference for a response following an individual's action is less than 1 millisecond (ms) or less than 1 second (s), or the response There is no intentional delay considering the processing limitations of the system.

Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN), and a wide area network ( WAN). The communication network may include all or part of the Internet, other communication networks, or a combination of communication networks. Information on a communication network according to various protocols and standards, including Long Term Evolution (LTE), 5G, IEEE 802, Internet Protocol (IP), or other protocols or combinations of protocols Can be sent. The communication network may transmit voice, video, biometric, or authentication data, or other information between connected computing devices.

Features described as separate implementations may be implemented in combination in a single implementation, while features described as single implementation may be implemented in multiple implementations, separately, or in any suitable subcombination. Operations described and claimed in a particular order should not be understood as requiring that a particular order, or all illustrated operations, be performed (some operations may be arbitrary). Where appropriate, multitasking or parallel processing (or a combination of multitasking and parallel processing) can be performed.

Claims (13)

In the method for blockchain-based smart contract invocation,
Receiving a target transaction used to initiate a call to a smart contract, wherein the target transaction includes call data, and at least a portion of the call data is a third-party storage system interconnected with a blockchain ( Includes data digest of target data stored in a third-party storage system);
Querying target data corresponding to the data digest from the third-party storage system;
Performing verification of the content for the target data by determining whether an execution condition is satisfied;
In response to determining that verification of the target data is successful, invoking the smart contract to perform smart contract calculation on the call data in the target transaction; And
Storing the calculation result in the distributed database of the blockchain after the smart contract calculation is completed
Including, blockchain-based smart contract calling method. According to claim 1,
The third-party storage system is to store a mapping relationship between the target data and the data digest of the target data, a blockchain-based smart contract calling method. According to claim 2,
Querying target data corresponding to the data digest from the third-party storage system includes:
And querying the third-party storage system by using the data digest as a query index to query target data corresponding to the data digest. According to claim 1,
The step of performing the verification of the content for the target data is:
Calculating a data digest of the target data based on a predetermined digest algorithm;
Determining whether the calculated data digest matches a data digest of the target data in the target transaction; And
In response to determining that the calculated data digest matches the data digest of the target data in the target transaction, determining that verification of the target data is successful
Including, blockchain-based smart contract calling method. According to claim 1,
The third party storage system comprises a centralized content addressable storage (CAS) system or a distributed CAS system. According to claim 1,
The blockchain is a member blockchain in a consortium blockchain that includes a plurality of member blockchains, a method for calling a smart contract based on a blockchain. The method of claim 6,
The third-party storage system is a blockchain-based smart contract calling method, which is another member blockchain having a cross-chain data reference relationship with the blockchain in the consortium blockchain. According to claim 1,
The third-party storage system comprises a centralized content addressable storage system, or a decentralized distributed system, a blockchain-based smart contract calling method. The method of claim 8,
The third-party storage system is a blockchain-based smart contract calling method that is disposed on the blockchain and includes a distributed system interconnected with each member of the blockchain according to an object storage service architecture. According to claim 1,
The method further comprising performing consensus processing for the target transaction in a transaction queue. The method of claim 10,
The step of performing the consensus processing is based on a consensus algorithm, a method for calling a smart contract based on a blockchain. The method of claim 11,
The consensus algorithm includes a practical Byzantine Fault Tolerance algorithm, a method for calling a smart contract based on a blockchain. In the device for the blockchain-based smart contract call,
A blockchain-based smart contract calling device, comprising a plurality of modules configured to perform the method of claim 1.

Images