CN109981679B

CN109981679B - Method and apparatus for performing transactions in a blockchain network

Info

Publication number: CN109981679B
Application number: CN201910276160.1A
Authority: CN
Inventors: 刘辉
Original assignee: Shanghai Dianrong Information Technology Co ltd
Current assignee: Shanghai Dianrong Information Technology Co ltd
Priority date: 2019-04-08
Filing date: 2019-04-08
Publication date: 2021-08-10
Anticipated expiration: 2039-04-08
Also published as: CN109981679A

Abstract

Embodiments of the present disclosure relate to methods and apparatus for performing transactions in a blockchain network. The method comprises the following steps: receiving a transaction request from a client, the transaction request sent to a plurality of endorsement nodes, associated with an application intelligence contract and relating to access to an external data source; simulating and executing an application intelligent contract; executing a system intelligence contract during simulated execution of an application intelligence contract to generate a first simulated execution result for a transaction, comprising: sending an access request to an agent node outside the blockchain network, receiving a request result and a signature of the request result from the agent node, and updating a read set of the first simulation execution result according to the request result and the signature; and returning the first simulation execution result to the client. Embodiments of the present disclosure provide a scheme to support multiple endorsement nodes in a blockchain to access the same external data source, enabling the execution of transactions to be ensured by consistency of read sets generated at the multiple endorsement nodes that are related to the external data source.

Description

Method and apparatus for performing transactions in a blockchain network

Technical Field

Embodiments of the present disclosure relate generally to the field of information technology, and more particularly, to a method, apparatus, and computer-readable storage medium for performing transactions in a blockchain network.

Background

Blockchains are intelligent peer-to-peer networks that use distributed databases to identify, disseminate, and document information, also known as value internet. The block chain has the technical advantages of decentralization, tamper resistance, data consistency storage, transparent and traceable process and the like, and is considered to have wide application prospects in numerous fields of finance, credit investigation, internet of things, economic trade settlement, asset management and the like.

An intelligent contract is a computer protocol intended to propagate, verify, or execute contracts in an informational manner that can be represented as a computer program that runs exactly on a blockchain. Users carry out transactions, share data, establish trust by using intelligent contracts, and ensure that the data is transparently traceable and tamperproof in the whole process of storage, reading and execution by the characteristics of the blockchain technology.

In a blockchain, one way is to complete the blockchain transaction by invoking an intelligent contract. In some cases, execution of the smart contracts may rely on data sources outside of the blockchain. In this case, the existing solution is that the intelligent contract directly calls an Oracle service, which gets data from the real world and then returns the result to the intelligent contract. However, in a scenario where, for example, a transaction requires multiple participating endorsements to execute, when multiple endorsement nodes simultaneously access the same external data source, it is not ensured that each returns a consistent result, resulting in failure of the transaction due to failure of consistency verification.

Accordingly, there is a need for an improved method of performing transactions in a blockchain network.

Disclosure of Invention

In general, embodiments of the present disclosure provide methods, apparatuses, and computer-readable storage media for performing transactions in a blockchain network to at least partially address the above and other potential problems of the prior art.

In a first aspect of embodiments of the present disclosure, there is provided a method for performing transactions in a blockchain network, the method comprising:

receiving a transaction request from a client, the transaction request sent by the client to a plurality of endorsement nodes of the blockchain network, the transaction request associated with an application intelligence contract and the transaction request relating to access to a data source located outside of the blockchain network;

simulating execution of the application intelligence contract;

returning the first simulation execution result to the client;

wherein said executing a system intelligence contract during simulated execution of said application intelligence contract to generate a first simulated execution result for said transaction comprises the substeps of:

sending an access request to a proxy node located outside the blockchain network;

receiving a request result corresponding to the access request from the proxy node and a signature of the request result by the proxy node, the request result being certified by the proxy node from the data source; and

updating the read set of the first simulation execution result according to the request result and the signature of the proxy node on the request result.

In a second aspect of embodiments of the present disclosure, there is provided an apparatus for performing transactions in a blockchain network, the apparatus comprising:

a processor; and

a memory for storing instructions that, when executed, cause the processor to perform the steps of:

receiving a transaction request from a client, the transaction request sent by the client to a plurality of endorsement nodes of a blockchain network, the transaction request associated with an application intelligence contract and the transaction request relating to access to a data source located outside of the blockchain network;

simulating execution of the application intelligence contract;

executing a system intelligent contract during simulated execution of the application intelligent contract to generate a first simulated execution result of the transaction;

returning the first simulation execution result to the client;

In a third aspect of embodiments of the present disclosure, there is provided a method for performing transactions in a blockchain network, the method comprising:

receiving, at an agent node located outside of a blockchain network, a plurality of access requests from a plurality of endorsement nodes of the blockchain network, respectively, to access a data source located outside of the blockchain network, the plurality of access requests corresponding to a same transaction request received at the plurality of endorsement nodes;

the proxy node obtaining, by a predictive-machine service located outside the blockchain network, request results corresponding to the plurality of access requests and attestation information generated by the predictive-machine service;

using the attestation information to verify whether the request results are trustworthy from the data source;

generating a signature of the request result using a private key of the proxy node if verified as authentic;

returning the request result and the signature of the agent node on the request result to the plurality of endorsement nodes for updating a read set of a plurality of simulated execution results respectively corresponding to the same transaction request.

In a fourth aspect of embodiments of the present disclosure, there is provided an apparatus for performing transactions in a blockchain network, the apparatus comprising:

a processor; and

In a fifth aspect of embodiments of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium comprises computer-executable instructions that, when run in an apparatus, cause the apparatus to perform the methods described according to the first and third aspects of embodiments of the present disclosure.

Embodiments of the present disclosure provide a scheme to support multiple endorsement nodes in a blockchain to access the same out-of-chain data source, enabling the execution of transactions to be ensured by consistency of read sets generated at the multiple endorsement nodes that are related to the external data source.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements, and wherein:

fig. 1 shows a schematic diagram of an exemplary environment 100 including a blockchain network and clients, in which exemplary environment 100 a method according to an embodiment of the present disclosure may be implemented;

fig. 2 shows a schematic diagram of an exemplary blockchain node 200, in accordance with embodiments of the present disclosure;

FIG. 3 depicts a flowchart of an example method 300 of performing a transaction in a blockchain network, according to an embodiment of the disclosure;

FIG. 4 illustrates a flow diagram of an exemplary method 400 of performing transactions in a blockchain network in accordance with an embodiment of the present disclosure;

fig. 5 illustrates a schematic diagram of an example apparatus 500 to perform transactions in a blockchain network in accordance with an embodiment of the present disclosure;

fig. 6 illustrates one specific example 600 of a method of performing a transaction in a blockchain network according to an embodiment of the present disclosure; and

fig. 7 illustrates an exemplary implementation 700 of the specific example 600 according to fig. 6.

Detailed Description

Embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that the same reference numerals may be used in the drawings for similar components or functional elements. The accompanying drawings are only intended to illustrate embodiments of the present disclosure. Alternative embodiments will become apparent to those skilled in the art from the following description without departing from the spirit and scope of the disclosure.

As used herein, the term "include" and its various variants are to be understood as open-ended terms, which mean "including, but not limited to. The term "based on" may be understood as "based at least in part on". The term "one embodiment" may be understood as "at least one embodiment". The term "another embodiment" may be understood as "at least one other embodiment". The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

For convenience of description, some terms appearing in the present disclosure are explained below, and it is to be understood that the terms used in the present application should be interpreted as having a meaning that is consistent with their meaning in the context of the present specification and the relevant art.

The term "Peer node" in the present disclosure refers to an accounting node in the blockchain network, and is responsible for checksum storage of the blockchain data. Meanwhile, on the Peer node, an intelligent contract can be installed and executed, and the read-write operation is carried out on the account book.

The term "order node" in the present disclosure refers to a sort of ordering node in the blockchain network, which may also be referred to as a consensus node, and provides common services for all channels in the blockchain network, and assembles the ordered transactions into blocks. The Orderer node runs independently of the Peer node, and is designed to support consensus algorithms.

The term "commit node" in the present disclosure refers to a commit node in a block chain network, and the commit node is a subclass of Peer nodes and is responsible for checking the ordered transactions of the order node, selecting a legal transaction to execute, and writing the legal transaction into a storage.

The term "Endorser node" in the present disclosure refers to an endorsement node in a blockchain network, and the Endorser node is a subclass of Peer nodes and is responsible for checking whether a certain transaction is legal or not and is willing to sign endorsements for the transaction.

The term "channel" in this disclosure refers to a private "subnet" of communications between two or more specific network members built on a blockchain network, each channel having its own independent ledger, enabling isolation and confidentiality of data. The channel private ledger is shared with all nodes participating in the channel, and the transactants must pass the channel's relevant verification before interacting with the ledger.

The terms "Read Set" and "Write Set" in this disclosure are generated during the simulation of a transaction on the Endorser node. The read set contains at least one unique Key (unique Key) and a corresponding version that the transaction reads during simulation. The write set includes at least one unique Key overwritten by the transaction and the corresponding new value. The Committer node can utilize the read set part to check the validity of the transaction and the write set part to update the version and the value of Key.

The term "world state" in this disclosure refers to a collection of variables that contain the results of the execution of a transaction.

The term "Transaction request" in this disclosure refers to a request to perform a function on a blockchain, also referred to as a "Transaction request" or a "Transaction Proposal".

The term "trusted computing environment" (or trusted execution environment) "in this disclosure refers to a secure area provided on a computing device (e.g., a smartphone, a tablet, a set-top box, a smart television, etc.) that can guarantee the security, confidentiality, and integrity of code and data loaded inside the environment. The trusted computing environment provides an isolated execution environment that is protected from malware attacks and to which privileged or non-privileged software cannot access, and provides security features including: isolated execution, integrity of trusted applications, confidentiality of trusted data, secure storage, and the like. For example, a Secure environment created by Software Guard Extensions (SGX) or Secure Encrypted Virtualization (SEV) at the processor level may be understood as a trusted computing environment. It should be understood that a trusted computing environment may also include a secure environment formed by similar techniques.

Intelligent contracts are business logic code that runs on block chain nodes (e.g., Peer nodes) and are the cornerstone used to build decentralized applications. The running of the intelligent contract requires certain resources, and usually the intelligent contract runs in a sandbox, which refers to the running environment of the intelligent contract. The operating environment may be completely isolated or partially isolated. For example, a sandbox may be an intelligent contract container or a virtual machine.

In this disclosure, an "application intelligence contract" refers to an intelligence contract that may be used for a number of users or transactions between users on a blockchain, and a "system intelligence contract" refers to an intelligence contract in a blockchain that may be used to access a predictive engine service to obtain data from an external data source.

In blockchains such as Fabric, one way is to complete the blockchain transaction by calling an intelligent contract. Illustratively, the procedure is as follows: the transaction initiator (e.g. client) collects the signed transaction simulation result through the Endorser node, and signs and sends the signed transaction simulation result to the Orderer node. The Orderer node generates a block after collecting a certain number of transactions, and then sends the block to the Committer node. The Committer node validates the transactions in the block one by one. After the validation is passed, the world state is then updated according to the transaction. As previously described, in some cases, execution of the smart contracts may rely on data sources outside of the blockchain. In this case, the existing solution is that the intelligent contract directly calls the predictive machine service, which obtains data from the real world and then returns the result to the intelligent contract. For example, for a smart contract involving trading of commodities between different currencies, it is necessary to convert the price of commodities in renminbi to trading prices in other currencies and then write the price information as part of the trading data into the ledger, so the smart contract requires that the current exchange rate of renminbi for other currencies be obtained from a data source outside the blockchain. However, return data that directly invokes the prolog service via the smart contract is not sent to the Orderer node for ordering out of the block as part of the transaction simulation results (i.e., part of the read set). Therefore, in a scenario where, for example, a transaction requires multiple party endorsements to execute, when multiple endosser nodes simultaneously access the same external data source, it is not guaranteed that each returns a consistent result. If the intelligent contract relies on the return result of the preplan service to calculate, and then the calculation result is written into the ledger, the write sets in the transaction simulation generated by the plurality of Endorser nodes are necessarily inconsistent, so that the transaction fails because the transaction cannot pass the consistency verification.

One way to solve the above problem is to let the endosser node of one of the participants access the talker service, and then the nodes of the other participants passively accept the result and submit the ledger. However, this method has the following drawbacks: 1) in the existing blockchain mechanism, other nodes cannot verify that the calculation result is indeed a result obtained based on trusted external data, because the return data directly calling the prolog service through the intelligent contract is not sent to the Orderer node to sort out blocks as part of the transaction simulation result (i.e. part of the read set); 2) many such business scenarios cannot be met, for example, the fulfillment of a transaction does require multiple participating endorsements; 3) if the Endorser node is maliciously attacked, it will happen that the data of the whole ledger is tampered or damaged.

In view of this, the embodiments of the present disclosure provide a solution for supporting multiple endorsement nodes to access the same external data source in a blockchain, which enables a transaction to be executed in a situation that multiple participating endorsements are required. Embodiments of the present disclosure may be applied in different types of blockchain networks. Blockchains are generally classified into three types, public, alliance, and private, according to their participants. The public chain is open to the outside, and the user can access the block chain network and the block data without any authorization to initiate various transactions. The alliance chain limits only the members in the alliance to participate, and the operation authority on the block chain is determined according to the relevant rules customized by the alliance. The private chain is generally used in a private organization, and the operation authority on the block chain is executed according to the self-regulation of the private organization. Embodiments of the present disclosure describe the techniques of the present disclosure with a federation chain as an example, but it should be understood that embodiments of the present disclosure may also be applicable to other types of blockchains.

Fig. 1 shows a schematic diagram of an exemplary environment 100 including a blockchain network 120 and a client 110, on which exemplary environment 100 a method according to embodiments of the present disclosure may be implemented. The blockchain network 120 includes a plurality of

Orderer nodes

131, 132 and a plurality of

Peer nodes

141, 142, 143, 151, 152, 153. Due to the decentralized, distributed nature of the blockchain technology, the blockchain nodes may exchange information with each other over various communication media. Illustratively, the Orderer node is responsible for collecting transactions, ordering and packaging the transactions to generate new blocks, thereby ensuring data consistency on each Peer node. The Peer node is a main body participating in the transaction, represents each member participating in the chain, and is responsible for storing complete account book data and executing intelligent contracts in the link of consensus. The client 110 may be connected to a Peer node, which the user accesses through the client 110 to initiate a transaction over the blockchain network 120.

Illustratively, some of the Peer nodes may be an enrerer node connected to an Orderer node, or may be a commit node connected to an Orderer node, or may be both an enrerer node and a commit node, wherein the enrerer node is responsible for checking whether a certain transaction is legal and willing to sign an endorsement, and the commit node is responsible for checking ordered transactions of the Orderer node, selecting legal transactions to execute and write to storage. For example, the

Peer nodes

141, 151, 152 may act as Endorser nodes and be communicatively coupled with

Orderer nodes

131 and 132 and have an intelligent contract deployed, the

Peer nodes

141, 151, 152 may act as Committer nodes and be communicatively coupled with

Orderer nodes

131 and 132, or all of the

Peer nodes

141 and 151 and 153 may be Committer nodes.

Further,

Peer node

141 and 143 can form organization 140 and

Peer node

151 and 153 can form organization 150, where the organization represents a set of member nodes that possess a common trusted certificate.

Organizations

140 and 150 may form a federation, which represents a collection of organizations in the context of a federation chain, in a structural form. For example,

organizations

140 and 150 may join the same channel for data communication, and install or deploy an intelligent contract at some Peer nodes and instantiate the intelligent contract into the channel, then those Peer nodes become the Endorser nodes of the intelligent contract on the channel. For example, smart contracts may be deployed at Peer node 141 of organization 140 and Peer node 151 of organization 150.

As shown in fig. 1, exemplary environment 100 also includes a proxy node 160, a predictive player service 170, and a data source 180 that are located outside blockchain network 120. Proxy node 160 may be communicatively coupled with one or more Peer nodes to obtain data from data source 180 through talker service 170 and return data to Peer nodes in response to access requests from Peer nodes to data source 180. Unlike existing ways of accessing data outside of the chain, Peer nodes do not directly access the prolog service 170, but rather access the prolog service 170 through the proxy node 160 to enable consistent results to be returned when multiple Peer nodes access the same data source, as described below. For example, the predictive machine service 170 may be implemented by tlsnottary (such as Oraclize) or SGX (Software Guard Extensions) (such as Town provider) technology or other suitable technology, such that the proxy node 160 can verify that the request result is indeed from the external data source 180 based on the attestation information received from the predictive machine service 170 generated by the predictive machine service 170. For example, data source 180 may include data obtained from address information, such as data obtained from a database via a URL (uniform resource locator), data obtained via a search engine, data from other blockchains (e.g., blockchains different from the blockchain in which intelligent contract 201 is applied), or data obtained in any other manner.

It should be understood that the blockchain network, clients, and blockchain network nodes in fig. 1 are illustrative only and not limiting, and may be any number. In addition, any number of intelligent contracts may be deployed at a Peer node. It is to be appreciated that for ease of describing embodiments of the present disclosure, other types of nodes of the known blockchain network 120 are not specifically shown and described so as not to unnecessarily obscure aspects of the embodiments of the present disclosure.

Fig. 2 shows a schematic diagram of an exemplary blockchain node 200, in accordance with embodiments of the present disclosure. Blockchain node 200 may be an example of an Endorser node among the Peer nodes of blockchain network 120 of fig. 1. As shown in fig. 2, application intelligence contracts 201 and system intelligence contracts 202 may be run at block link points 200 by, for example, an intelligence contract running engine. It is to be understood that for ease of describing embodiments of the present disclosure, other components and processes of the known blockchain node 200 are not specifically shown and described so as to not unnecessarily obscure aspects of the embodiments of the present disclosure.

Application intelligence contracts 201 may provide various functionality for application to finance, credit investigation, the internet of things, economic trade settlement, asset management, etc., and system intelligence contracts 202 are used to access external data sources (e.g., data sources 180 of FIG. 1) through predictive-machine services (e.g., predictive-machine services 170 of FIG. 1). In addition, the number of smart contracts in FIG. 2 is merely illustrative and not limiting, and can be any number. Application intelligence contracts 201 may be placed to run in, for example, a sandbox (e.g., a container or a virtual machine), and system intelligence contracts 202 may be embedded within the system, for example, deployed at block chain nodes 200. For example, application intelligence contracts 201 running in a sandbox may call system intelligence contracts 202 through an interface to access external data sources. For example, a call to system intelligence contract 202 may be embedded in application intelligence contract 201.

Fig. 3 illustrates a flow diagram of an exemplary method 300 of performing transactions in a blockchain network in accordance with an embodiment of the present disclosure. The method 300 may be implemented in the exemplary environment 100 of fig. 1. The method 300 may be performed by an endosser node (such as Peer node 141) in the Peer node of FIG. 1 or the blockchain node 200 of FIG. 2. The method 300 will be described below with reference to fig. 1-3. As shown in the flow chart, the method 300 may include the steps of:

step 301: a transaction request is received from a client, the transaction request sent by the client to a plurality of endorsement nodes of a blockchain network, the transaction request associated with an application intelligence contract and the transaction request relating to access to a data source located outside of the blockchain. For example, a user sends a transaction request to a plurality of

Peer nodes

141, 151, 152 (as Endorser nodes) of blockchain network 120 via client 110, the transaction request being associated with an application intelligence contract (e.g., application intelligence contract 201 of FIG. 2) and requiring data to be obtained from a data source 180 located outside blockchain network 120. The transaction request is received from the client at each of the plurality of

Peer nodes

141, 151, 152 (e.g., Peer node 151).

Step 302: and simulating to execute the application intelligent contract. For example, execution of an associated application intelligence contract may be simulated at Peer node 151 based on the transaction request.

Step 303: executing the system intelligent contract in the process of simulating and executing the application intelligent contract to generate a first simulation execution result of the transaction. For example, at Peer node 151, execution of an associated application intelligence contract may be simulated based on a transaction request, and since data is required to be retrieved from external data source 180, in simulating execution of the application intelligence contract, data may be retrieved from data source 180 by invoking and executing a system intelligence contract (e.g., system intelligence contract 202 of FIG. 2) to generate a first simulated execution result for the transaction. For example, an application intelligence contract running in a sandbox may invoke and execute a system intelligence contract through an interface to access data source 180.

Step 303 further comprises the sub-steps of: in sub-step 303-1, sending an access request to a proxy node located outside the blockchain network; in sub-step 303-2, receiving a request result corresponding to the access request from the agent node and a signature of the request result by the agent node, the request result being certified by the agent node from the data source; and in sub-step 303-3, updating the read set of the first simulation execution result based on the request result and the signature of the proxy node on the request result. For example, in executing a system intelligence contract, data is obtained from a data source 180 through interactions between the system intelligence contract and agent nodes 160 located outside of blockchain network 120, and the interaction process may include: the system intelligence contract sends an access request to the proxy node 160 and receives a request result corresponding to the access request from the proxy node 160 and a signature of the request result by the proxy node 160 that is certified from the data source by the proxy node 160. For example, the proxy node 160 may send a service request to the predictive-speaker service 170 after receiving the access request (e.g., send the service request according to an access address of the data source, or the service request includes an access address of the data source, etc.), which in turn, the predictive-speaker service 170 may send a data request to the data source 180 based on the received service request to obtain a data result from the data source 180 and return the data result from the data source 180 to the predictive-speaker service 170. Subsequently, the talker service 170 may generate attestation information to attest that the data result is trustworthy from the data source 180 and return the attestation information and the request result (e.g., data result, etc.) to the proxy node 160, the proxy node 170 may use the attestation information to verify whether the request result is trustworthy from the data source 180, and in the case of verifying to be trustworthy, the proxy node 170 may sign the request result using its private key and return the request result and the signature to the system intelligence contract, such that the public key of the proxy node 170 may be used at the Peer node 151 to check whether the request result (e.g., the public key of the proxy node 170 may be obtained by the Peer node 151) was generated by the proxy node 170 and verify the integrity of the request result. Subsequently, at Peer node 151, the read set of first simulation execution results is updated based on the request results and the signature of the request results by proxy node 170. Unlike the prior art blockchain technique in which the return data of the prolog service directly invoked by the smart contract is not sent to the order node for sorting out the blocks as part of the result of the simulated execution (i.e., part of the read set), in the above sub-step of this step 303, the request result returned from the external data source will be used to update part of the result of the simulated execution (i.e., part of the read set) to be sent to the order node for sorting out the blocks, so that multiple nodes can verify that the computation result is indeed a result based on trusted external data, and can verify the consistency of the read set to ensure the execution of the transaction.

Step 304: and returning the first simulation execution result to the client. For example, at Peer node 151, the first simulation execution results are returned to client 110.

In some embodiments, the access request may include request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information is used to identify the access request and is recorded in the channel ledger. The access request may include request identification information that is recorded in the channel ledger to uniquely identify the access request (e.g., ensure global uniqueness such that multiple access requests related to the same transaction request are consistent). The access request may also include an access address of the data source, such that the proxy node 160 (and the predictive engine service 170) may retrieve data from the data source according to the access address, such as by a URL (uniform resource locator) from a database, by a link address of a search engine, from other blockchains outside the blockchain network 120 (e.g., a blockchain different from the blockchain in which the intelligent contract 201 is applied), and so forth. The access request may also include an endorsement policy such that the broker node 160 may aggregate multiple access requests, for example, determine whether endorsement nodes of other participating parties (e.g., organizations) send the same access requests to the data sources according to the endorsement policy, so as to invoke the predictive machine service 170 according to the access requests (e.g., access addresses of the data sources it includes, etc.) after receiving the access requests of all endorsement nodes or at least the access requests that satisfy the endorsement node requirements (e.g., specific endorsement nodes, number, combinations thereof, etc.) specified by the endorsement policy to ensure consistency of returned request results.

In some embodiments, updating the read set of first simulation execution results based on the request results and the signature of the request results by the proxy node may include: generating a record, the type of the record being an out-of-chain type, wherein the record may include but is not limited to: request identification information, an access address of a data source, a request result and a signature of the proxy node on the request result; and writing the record to a read set of first simulation execution results. For example, the proxy node 170 may generate a record for the request result and write the record into a read set of the first simulation execution result. For example, the record may be stored in the form of a Key-Value (Value) pair, the Key of the record being the request identification information, the Value being the access address of the data source, the request result, the signature of the request result by the proxy node 160, etc., and the Key-Value type (i.e., the record type) being an off-chain type to distinguish it from other types of records (e.g., an on-chain type of record that records on-chain data). By writing a record based on the result of the request into the read set that simulates the result of the execution, execution of the transaction can be ensured by verifying the consistency of the records in the read set.

In some embodiments, the method 300 may further include: receiving a block comprising a transaction, the transaction comprising a plurality of simulated execution results corresponding to transaction requests from a plurality of endorsement nodes, respectively; verifying a plurality of read sets in the transaction, wherein the plurality of read sets respectively correspond to a plurality of simulation execution results; in the case of passing the verification, the world state is updated from a plurality of write sets in the transaction, the plurality of write sets respectively corresponding to the plurality of simulation execution results. For example, the client 110 encapsulates the multiple simulated execution results (which include the corresponding multiple read sets) received from the

multiple Peer nodes

141, 151, and 152 in one transaction and sends the transaction to the Orderer node 131, the Orderer node 131 orders and packages the transactions to generate blocks after receiving several transactions, and then sends the blocks to the Peer node 151 (as a Committer node) in the blockchain network 120, the Peer node 151 determines the validity of the transaction by verifying the multiple read sets of the transaction after receiving the transaction including the transaction corresponding to the transaction request, and executes the transaction when the transaction is valid, i.e., updates the world state according to the multiple write sets of the transaction.

In some embodiments, validating multiple read sets in a transaction may include: reading a record of one of a plurality of read sets; verifying a signature of a proxy node included in the record in the one read set and corresponding records of other read sets of the plurality of read sets if the type of the record is an out-of-chain type, and verifying whether the record in the one read set is completely consistent with the rest of the records included in the corresponding records of the other read sets of the plurality of read sets, or verifying the corresponding records of the plurality of read sets based on a world state if the type of the record is not an out-of-chain type. In this step, the validity of the transaction is verified differently depending on the type of record in the read set of the transaction: for records of the out-of-chain type, it is necessary to verify whether the signature of the proxy node in the record of each endorsement node (e.g., verified using the public key of the proxy node) is valid to check whether the request result is generated by the proxy node and verify the integrity of the request result, and to verify whether other parts in the record of each endorsement node are completely consistent (e.g., request identification information included in the record, access address of the data source, request result, etc.); for records of the non-off-chain type, then the corresponding record in the multiple read sets may be verified based on the world state, e.g., by comparing the version of the unique key in the record to the version of the corresponding key in the world state, similar to the processing in existing blockchain techniques.

In some embodiments, the method 300 may further include: verifying a signature of a sender of the transaction; and verifying whether the endorsement signature and the endorsement signature quantity of the transaction meet the requirements of the endorsement policy. For example, the Peer node 151 verifies whether the signature of the sender of the transaction is legitimate, verifies the endorsement signature of the transaction and whether the number of endorsement signatures meets the requirements of the signature policy (e.g., whether a certain number of endorsement signatures are obtained, whether the endorsement signatures come from a specified Endorser node, etc.).

In some embodiments, the method 300 may further include: the system intelligence contract is deployed prior to invoking the system intelligence contract. For example, the system intelligence contract is deployed at

multiple Peer nodes

141, 151, 152 prior to invocation.

Through the embodiment of the present disclosure described in fig. 3, a scheme is provided for supporting multiple endorsement nodes in a blockchain to access the same out-of-chain data source, so that the execution of a transaction can be ensured through the consistency of read sets related to the external data source generated at the multiple endorsement nodes.

Fig. 4 illustrates a flow diagram of an exemplary method 400 of performing transactions in a blockchain network in accordance with an embodiment of the present disclosure. The method 400 may be implemented in the exemplary environment 100 of fig. 1. The method 400 may be performed by the proxy node 160 of fig. 1. The method 400 will be described below with reference to fig. 1, 2, and 4. As shown in the flow chart, the method 400 may include the steps of:

step 401: at an agent node located outside of the blockchain network, a plurality of access requests to access a data source located outside of the blockchain network are respectively received from a plurality of endorsement nodes of the blockchain network, the plurality of access requests corresponding to the same transaction request received at the plurality of endorsement nodes. For example, a user sends a transaction request to a plurality of

Peer nodes

141, 151, 152 (as the Endorser nodes) of the blockchain network 120 via the client 110, the transaction request being associated with an application intelligence contract (e.g., application intelligence contract 201 of fig. 2) and requiring data to be obtained from a data source 180 located outside the blockchain network 120. Upon receiving the transaction request, the plurality of

Peer nodes

141, 151, 152 invoke and execute a system intelligence contract (e.g., system intelligence contract 202 of FIG. 2) in a process that simulates execution of an application intelligence contract. The plurality of

Peer nodes

141, 151, 152 send a plurality of access requests corresponding to the same transaction request to a proxy node 160 located outside the blockchain network 120 to access the data source 180 in executing the system intelligence contract. At the proxy node 160, the plurality of access requests are received from a plurality of

Peer nodes

141, 151, 152.

Step 402: the proxy node obtains request results corresponding to the plurality of access requests and attestation information generated by the predictive-machine service through a predictive-machine service located outside the blockchain network. For example, proxy node 160 sends a service request to predictive-machine service 170 after receiving the multiple access requests (or one or more of them) (e.g., sends the service request according to an access address of the data source, or the service request includes an access address of the data source, etc.), and in turn predictive-machine service 170 may send a data request to data source 180 based on the received service request to obtain a data result from data source 180 and return the data result from data source 180 to predictive-machine service 170. The predictive engine service 170 may then generate attestation information to attest that the data results are trustworthy from the data source 180 and return the attestation information and request results (e.g., data results, etc.) to the proxy node 160.

Step 403: the attestation information is used to verify whether the request results are trustworthy from the data source. For example, the proxy node 170 may use the attestation information to verify whether the request results are trustworthy from the data source 180.

Step 404: in case of verification as authentic, the private key of the proxy node is used to generate a signature on the request result. For example, in the case of verification as trusted, the proxy node 170 may sign the request result using its private key.

Step 405: and returning the request result and the signature of the proxy node on the request result to the endorsement nodes for updating the read sets of the simulation execution results respectively corresponding to the same transaction request. For example, in the case of verifying as trusted, the proxy node 160 returns the request results and signatures to the plurality of

Peer nodes

141, 151, 152 (e.g., system intelligence contracts running at the Peer nodes) so that the request results can be verified at the plurality of

Peer nodes

141, 151, 152 using the public key of the proxy node 170 (e.g., the public key of the proxy node 170 can be obtained by the plurality of

Peer nodes

141, 151, 152).

In some embodiments, each of the plurality of access requests may include request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information is to identify the access request and is recorded in the channel ledger. The access request may include request identification information that is recorded in the channel ledger to uniquely identify the access request (e.g., ensure global uniqueness such that multiple access requests related to the same transaction request are consistent). The access request may also include an access address of the data source, such that the proxy node 160 (and the predictive engine service 170) may retrieve data from the data source according to the access address, such as by a URL (uniform resource locator) from a database, by a link address of a search engine, from other blockchains outside the blockchain network 120 (e.g., a blockchain different from the blockchain in which the intelligent contract 201 is applied), and so forth. The access request may also include an endorsement policy such that the proxy node 160 may aggregate multiple access requests, e.g., determine whether there are any endorsement nodes of other parties (e.g., organizations) sending the same access requests to the data source according to the endorsement policy, so as to invoke the predictive machine service 170 according to the access request (e.g., the access address of the data source it includes, etc.) to ensure consistency of returned request results after receiving access requests of all endorsement nodes or one or more endorsement nodes that at least meet the endorsement node requirements (specific endorsement nodes, number, combinations thereof, etc.) specified by the endorsement policy.

In some embodiments, the proxy node may be implemented by a BaaS (Blockchain as a Service) platform that manages a Blockchain network. For example, the proxy node 160 may be implemented by a BaaS platform (not shown) that manages the blockchain network 120.

In some embodiments, the proxy node may run in a trusted computing environment. For example, by running the proxy node 160 in a trusted computing environment, an isolated execution environment may be provided that is protected from malware, making it inaccessible to privileged or non-privileged software. For example, the security services of such trusted computing environments may be readily implemented or upgraded via hardware-level (e.g., processor such as a Central Processing Unit (CPU), etc.) security techniques.

By the embodiment of the present disclosure described by fig. 4, a scheme is provided for supporting multiple endorsement nodes to access the same out-of-chain data source in a blockchain, so that consistency of data returned to the multiple endorsement nodes for requests of the multiple endorsement nodes to an external data source can be ensured by a proxy node, so as to ensure execution of a transaction through consistency of read sets related to the external data source generated at the multiple endorsement nodes.

Fig. 5 illustrates a schematic diagram of an example apparatus 500 for performing transactions in a blockchain network, in accordance with an embodiment of the present disclosure. The apparatus 500 may comprise: a memory 501 and a processor 502 coupled to the memory 501. The memory 501 is used to store instructions, and the processor 502 is configured to implement one or more actions or steps of the various methods described herein (e.g., the method 300 of fig. 3, the method 400 of fig. 4, and the specific example 600 of fig. 6) based on the instructions stored by the memory 501.

The memory 501 may include volatile memory and nonvolatile memory such as rom (read only memory), ram (random access memory), removable disk, magnetic disk, optical disk, and usb disk. Processor 502 may be a Central Processing Unit (CPU), microcontroller, Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA) or other programmable logic device, or one or more integrated circuits configured to implement embodiments of the present disclosure.

To better convey the concepts of the present disclosure, the following description is presented in conjunction with a specific example.

Fig. 6 illustrates one specific example 600 of a method of performing a transaction in a blockchain network according to an embodiment of the present disclosure. The example 600 shows a client 601,

Peer nodes

602 and 603 of a blockchain network, a proxy node 604 located outside of the blockchain network, an external predictive machine service 605, and an external data source 606. In this example 600, a user sends a transaction request to Peer nodes 602 and 603 (as the Endorser nodes) via client 601 for initiating a transaction, the transaction request being associated with an application intelligence contract 611 and involving access to an external data source 606. At each

Peer node

602, 603, in simulating execution of the application intelligence contract 611, a system intelligence contract 612 is invoked and executed to access an external data source 606 to obtain data. Each system intelligence contract 612 sends an access request to external proxy node 604 to obtain data from external data source 606 via external predictive engine service 605. System intelligence contract 612 at each

Peer node

602 and 603, upon receiving a request result corresponding to the access request, updates the read set of simulation execution results with the request result, and then each

Peer node

602 and 603 returns a corresponding simulation execution result to client 601. The specific example 600 of fig. 6 will be described below in conjunction with fig. 7.

Fig. 7 illustrates an exemplary implementation 700 of the specific example 600 according to fig. 6. In addition to those shown in FIG. 6, the Orderer node 607 and Committer node 608 of the blockchain network are included in FIG. 7. As shown in process 700 of fig. 7, a user sends a transaction request 610 to the

enrors nodes

602 and 603 through the client 601 in order to initiate a transaction, the transaction request 610 being associated with an application intelligence contract 611 and involving access to an external data source 606, and then invokes and executes a system intelligence contract 612 to access the external data source 606 in simulating execution of the application intelligence contract 611.

At the enrberser node 602, system intelligence contract 612 sends a first access request 615 to the proxy node 604, and at the enrberser node 603, system intelligence contract 612 sends a second access request 620 to the proxy node 604. Each of the first and second access requests 615, 620 may include, but is not limited to: the request identification information, the access address of the external data source 606, and the endorsement policy. The request identification information may be used to identify the access request and recorded in the channel ledger, and the access requests corresponding to the same transaction request may have the same request identification information.

The agent node 604 may aggregate multiple access requests, for example, determine whether any other enrser nodes (e.g., organizations) send the same access request to the data source according to the endorsement policy, so as to invoke the predictive service 605 according to the access request (e.g., the access address of the external data source included therein, etc.) after receiving the access requests of all the enrser nodes or one or more enrser nodes that at least satisfy the requirements (specific enrser nodes, number, combination thereof, etc.) of the enrser nodes specified by the endorsement policy. For example, the proxy node 604 sends a service request 625 to the external predictive player service 605 after aggregating the first and second access requests 615, 620 (e.g., sending the service request 625 based on the access address of the external data source 606, or the service request 625 including the access address of the external data source 606, etc.).

In turn, the predictive-speaker service 170 may send a data request 630 to the external data source 606 based on the received service request 625 and return a data result 635 corresponding to the data request 630 from the external data source 180 to the external predictive-speaker service 605. The external predictive engine service 605 generates request results (which include data results, etc.) and attestation information (which may be used to prove that the request results are indeed from the external data source 606)640 and returns the request results and attestation information 640 to the proxy node 604.

The proxy node 604 may use the attestation information to verify that the request results are trustable from the external data source 606, and if verified (i.e., if verified to be authentic), the proxy node 604 processes the request results using its private key to generate signature information that may be used to check whether the request results were generated by the proxy node 604 to verify the integrity of the request results, and returns the request results and signature information 645 to the system intelligence contracts 612 at the

Endorser nodes

602 and 603, respectively.

Subsequently, at each

Endorser node

602, 603, system intelligence contract 612 may update the read sets of first simulation execution results 650 and second simulation execution results 655, respectively, with request results and signature information 645. For example, system intelligence contract 612 generates a record for the request result and signature information 645, writes the record into a read set of the simulation execution result, and for example, the record may be stored in the form of a Key-Value (Value) pair, where the Key-Value type (i.e., record type) is an out-of-chain type, the Key of the record is request identification information, and the Value is an access address of external data source 606, the request result, signature information generated by proxy node 604 for the request result, and so on. Then, each of the

Endorser nodes

602, 603 returns the first and second simulation execution results 650, 655 (endorsed), respectively, to the client 601.

After the client 601 receives the first and second simulated execution results 650, 655 from the

Endorser nodes

602 and 603, the client 601 encapsulates the simulated execution results in a transaction 660 and sends the transaction 660 to the Orderer node 607. The Orderer node 607 generates block 665 after collecting a certain number of transactions (or a timeout), and then sends block 665 to the Committer node 608 for transaction validation.

For example, the Committer node 608 may be the Endorser nodes 602 and/or 603. Taking the example where the Committer node 608 is the Endorser node 602, the Endorser node 602 reads the transactions 660 included in the block 665 and verifies the read sets corresponding to the first and second simulated execution results 650, 660 in the transactions 660. Verifying the multiple read sets in transaction 660 may include verifying the records in each read set, if the type of record is found to be an out-of-chain type, the public key of agent node 604, for example, may be used to verify the signature information of agent node 604 for the record and to verify whether the rest of the record for each read set is completely consistent, or if the type of the record is found not to be an out-of-chain type, the record in each read set may be verified based on the world state (i.e., to verify whether the version of each unique key in the list of unique keys in the read set is the same as the version of the corresponding key in the world state) as in existing logic. If each record in the read set is validated, then transaction 660 is marked as valid and the world state is updated using multiple write sets of transactions, otherwise transaction 660 is invalid and the world state is not updated.

In some examples, the proxy node 604 in fig. 6 and 7 may be implemented by a BaaS platform (not shown) that manages a blockchain network. In some examples, the broker node 604 may operate in a trusted computing environment, thereby providing an isolated execution environment that is protected from attacks by malware, making the environment inaccessible to privileged or non-privileged software.

Furthermore, it should be understood that the number of the Endorser nodes in fig. 6 and 7 is merely for illustration and not for limiting the disclosure, and embodiments of the disclosure are equally applicable to scenarios with more than two Endorser nodes.

In contrast to the prior art, according to the example 600 of fig. 6 and the example implementation of fig. 7, a scheme is provided that supports multiple endorsement nodes in a blockchain to access the same out-of-chain data source, such that execution of a transaction can be ensured by consistency of read sets generated at the multiple endorsement nodes in relation to an external data source.

In general, the various example embodiments of this disclosure may be implemented in hardware or special purpose circuits, software, firmware, logic or any combination thereof. Certain aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

By way of example, the various illustrative logical blocks, modules, and circuits described in connection with the disclosure may be implemented or performed with a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

By way of example, embodiments of the disclosure may be described in the context of machine-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or divided between program modules as described. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed facility, program modules may be located in both local and remote memory storage media.

Computer program code for implementing the methods of the present disclosure may be written in one or more programming languages. These computer program codes may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the computer or other programmable data processing apparatus, cause the functions/acts specified in the flowchart and/or block diagram block or blocks to be performed. The program code may execute entirely on the computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or entirely on the remote computer or server.

In the context of this disclosure, a machine-readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More detailed examples of a machine-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a RAM, a ROM, an erasable programmable read-only memory (EPROM or flash memory), an optical storage device, a magnetic storage device, or any suitable combination thereof.

Additionally, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking or parallel processing may be beneficial. Likewise, while the above discussion contains certain specific implementation details, this should not be construed as limiting the scope of any invention or claims, but rather as describing particular embodiments that may be directed to particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although embodiments of the present disclosure have been described with reference to several particular embodiments, it should be understood that embodiments of the present disclosure are not limited to the particular embodiments disclosed. The embodiments of the disclosure are intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

Claims

1. A method for performing transactions in a blockchain network, the method comprising:

simulating execution of the application intelligence contract;

returning the first simulation execution result to the client;

sending an access request to a proxy node located outside the blockchain network, wherein the proxy node obtains a request result corresponding to the access request and attestation information generated by a talker service located outside the blockchain network through the talker service;

2. The method of claim 1, wherein the access request comprises request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information identifies the access request and is recorded in a channel ledger.

3. The method of claim 2, wherein updating the read set of the first simulation execution results based on the request results and the signature of the request results by the broker node comprises:

generating a record, wherein the type of the record is an off-chain type, and the record comprises the following items: the request identification information, the access address of the data source, the request result and the signature of the proxy node on the request result; and

writing the record to a read set of the first simulation execution results.

4. The method of claim 1, further comprising:

receiving a block comprising the transaction, the transaction comprising a plurality of simulated execution results corresponding to the transaction request from the plurality of endorsement nodes, respectively;

validating a plurality of read sets in the transaction, the plurality of read sets respectively corresponding to the plurality of simulated execution results;

and in the case of passing the verification, updating the world state according to a plurality of write sets in the transaction, wherein the plurality of write sets respectively correspond to the plurality of simulation execution results.

5. An apparatus for performing transactions in a blockchain network, the apparatus comprising:

a processor; and

simulating execution of the application intelligence contract;

returning the first simulation execution result to the client;

6. The apparatus of claim 5, wherein the access request comprises request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information is used to identify the access request and is recorded in a channel ledger.

7. The apparatus of claim 6, wherein updating the read set of the first simulation execution results based on the request results and the signature of the request results by the broker node comprises:

writing the record to a read set of the first simulation execution results.

8. The apparatus of claim 5, wherein the instructions, when executed, further cause the processor to:

9. A method for performing transactions in a blockchain network, the method comprising:

10. The method of claim 9, each of the plurality of access requests comprising request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information identifies the access request and is recorded in a channel ledger.

11. The method of claim 9, wherein the proxy node is implemented by a BaaS platform that manages the blockchain network.

12. The method of claim 9, wherein the proxy node operates in a trusted computing environment.

13. An apparatus for performing transactions in a blockchain network, the apparatus comprising:

a processor; and

14. The apparatus of claim 13, each of the plurality of access requests comprising request identification information, an access address of the data source, and an endorsement policy, wherein the request identification information identifies the access request and is recorded in a channel ledger.

15. The apparatus of claim 13, wherein the proxy node is implemented by a BaaS platform that manages the blockchain network.

16. The apparatus of claim 13, wherein the proxy node operates in a trusted computing environment.

17. A computer-readable storage medium comprising computer-executable instructions that, when executed in an apparatus, cause the apparatus to perform a method for performing transactions in a blockchain network according to any one of claims 1-4 or 9-12.