CN110766550B

CN110766550B - Asset query method and device based on block chain and electronic equipment

Info

Publication number: CN110766550B
Application number: CN201910838763.6A
Authority: CN
Inventors: 祁鹏涛; 周徽; 陆旭明; 陈锐发
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-09-05
Filing date: 2019-09-05
Publication date: 2021-06-22
Anticipated expiration: 2039-09-05
Also published as: CN110766550A; WO2021042818A1

Abstract

One or more embodiments of the present specification provide an asset query method and apparatus based on a block chain, and an electronic device, which are applied to a node device in which a trusted execution environment is installed in the block chain; the block chain stores asset issuing transactions including asset information issued to the block chain by an investment manager; the asset issuance transaction is pre-encrypted; the method comprises the following steps: receiving a calling transaction which is sent by a client and comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user and aims at a target intelligent contract deployed on a blockchain; wherein the contract code of the target intelligent contract is encrypted in advance; in response to the invoking transaction, decrypting the contract code of the target intelligent contract in the trusted execution environment, executing the decrypted contract code in the trusted execution environment, and determining whether the asset query user has a viewing right of the target asset issuing transaction; if yes, the target asset release transaction decrypted in the trusted execution environment is returned to the client.

Description

Asset query method and device based on block chain and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to an asset query method and apparatus based on a blockchain, and an electronic device.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

The specification provides an asset query method based on a block chain, which is applied to node equipment in the block chain, wherein the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the method comprises the following steps:

receiving a calling transaction sent by a client and aiming at a target intelligent contract deployed on the blockchain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

in response to the invoking transaction, decrypting contract code of the target intelligent contract in the trusted execution environment, and executing the decrypted contract code in the trusted execution environment to determine whether the asset querying user has viewing permission for the target asset issuing transaction;

and if the asset query user is determined to have the viewing permission of the target asset issuing transaction, returning the target asset issuing transaction decrypted in the trusted execution environment to the client.

Optionally, the blockchain stores asset issuance transactions issued to the blockchain by a plurality of investment managers; wherein the transaction formats of the asset issuing transactions issued to the blockchain by different investment managers are different.

Optionally, the assets released by the investment manager in the blockchain include:

a base asset; and securitizing assets issued using as value support a pool of base assets created based on base assets issued in the blockchain.

Optionally, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.

Optionally, the asset issuance transaction further comprises the asset related participant users issued by the investment manager in the blockchain;

the determining whether the asset querying user has viewing rights for the target asset publication transaction includes:

decrypting the target asset issuance transaction in the trusted execution environment and determining whether the asset querying user matches a participant user in the target asset issuance transaction; if so, determining whether the asset querying user has viewing rights for the target asset publication transaction.

Optionally, returning the target asset release transaction decrypted in the trusted execution environment to the client includes:

and encrypting the target asset issuing transaction decrypted in the trusted execution environment based on the public key of the asset query user, and returning the encrypted target asset issuing transaction to the client, so that the client decrypts the encrypted target asset issuing transaction based on the private key of the asset query user to obtain the original content of the target asset issuing transaction.

Optionally, a decryption key for decrypting the contract code of the target smart contract and the asset issuance transaction is stored in the trusted execution environment; wherein a decryption key stored in the trusted execution environment is prohibited from being derived from the trusted execution environment.

Optionally, the encryption scheme adopted for the contract code of the target intelligent contract includes any one of the following encryption schemes: a symmetric encryption mode, an asymmetric encryption mode, a mode of combining symmetric encryption and asymmetric encryption.

Optionally, the symmetric encryption is combined with the asymmetric encryption, and the method includes: digital envelope encryption mode.

Optionally, the trusted execution environment comprises an Intel SGX.

The specification also provides an asset query method based on the block chain, which is applied to node equipment in the block chain, wherein the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the method comprises the following steps:

if the asset inquiring user is determined to have the viewing permission of the target asset issuing transaction, encrypting a decryption key of the target asset issuing transaction stored in the trusted execution environment based on a public key of the asset inquiring user, returning the encrypted decryption key to the client side, so that the client side decrypts the encrypted decryption key based on a private key of the asset inquiring user, and decrypts the target asset issuing transaction based on the decrypted decryption key to obtain the original content of the target asset issuing transaction.

The present specification also provides an asset query apparatus based on a block chain, where the apparatus is applied to a node device in the block chain, and the node device is equipped with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the device comprises:

the receiving module is used for receiving a calling transaction which is sent by a client and aims at a target intelligent contract deployed on the block chain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

a determining module, configured to decrypt the contract code of the target intelligent contract in the trusted execution environment in response to the invoking transaction, execute the decrypted contract code in the trusted execution environment, and determine whether the asset querying user has a viewing right of the target asset issuing transaction;

and the return module is used for returning the decrypted target asset issuing transaction in the trusted execution environment to the client if the asset query user is determined to have the viewing permission of the target asset issuing transaction.

the determination module:

Optionally, the return module:

Optionally, the trusted execution environment comprises an Intel SGX.

and the return module is used for encrypting a decryption key of the target asset issuing transaction stored in the trusted execution environment based on the public key of the asset inquiring user and returning the encrypted decryption key to the client if the asset inquiring user is determined to have the viewing permission of the target asset issuing transaction, so that the client decrypts the encrypted decryption key based on the private key of the asset inquiring user and decrypts the target asset issuing transaction based on the decrypted decryption key to obtain the original content of the target asset issuing transaction.

This specification also proposes an electronic device including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of the above method by executing the executable instructions.

The present specification also proposes a computer-readable storage medium having stored thereon computer instructions, characterized in that the instructions, when executed by a processor, implement the steps of the above-mentioned method.

In the above technical solution, a client may send a call transaction for a target intelligent contract that is deployed on the blockchain and encrypted in advance, so that a node device in the blockchain decrypts a contract code of the target intelligent contract in a hosted trusted execution environment in response to the call transaction, executes the decrypted contract code in the trusted execution environment, and determines whether an asset query user has a view permission of a target asset issuance transaction corresponding to a transaction identifier in the call transaction; if so, returning the target asset release transaction decrypted in the trusted execution environment to the client. In this way, the asset issuing transaction issued to the blockchain by different investment managers can be subjected to data isolation, namely only participant users related to the asset issuing transaction are allowed to inquire the asset issuing transaction; in addition, data security may be ensured by decrypting contract code of the smart contract, as well as asset issuance transactions, in the trusted execution environment.

Drawings

FIG. 1 is a schematic diagram of a creation flow of an intelligent contract shown herein;

FIG. 2 is a schematic diagram illustrating the call flow of an intelligent contract shown in this specification;

FIG. 3 is a schematic diagram of the creation and invocation flow of an intelligent contract shown in the present specification;

FIG. 4 is a schematic diagram of a blockchain-based asset securitization system shown in an exemplary embodiment of the present description;

FIG. 5 is a flow chart diagram illustrating a blockchain-based asset query method in an exemplary embodiment of the present description;

FIG. 6 is a flow diagram illustrating another blockchain-based asset query method in an exemplary embodiment of the present description;

fig. 7 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of the present specification;

FIG. 8 is a block diagram of a blockchain-based asset querying device in accordance with an exemplary embodiment of the present specification;

fig. 9 is a block diagram of another blockchain-based asset querying device in accordance with an exemplary embodiment of the present specification.

Detailed Description

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

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.

Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.

Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.

A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.

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

The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.

The consensus algorithm supported in the blockchain may include:

the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

In the field of blockchain, an important concept is Account (Account); taking an ether house as an example, the ether house generally divides an account into an external account and a contract account; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract). Of course, for some blockchain items derived from the ethernet-based architecture (such as ant blockchains), the account types supported by the blockchain may be further expanded, and are not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

Taking etherhouses as an example, the structure of an account usually includes fields such as Balance, Nonce, Code and Storage. Wherein:

a Balance field for maintaining the current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;

a Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.

A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account. The storage content of the contract account is usually constructed into a data structure of an MPT (Merkle Patricia Trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.

Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.

For most blockchain items, a Merkle tree is typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. Taking etherhouses as an example, the etherhouses use MPT tree (a Merkle tree variation) as a data organization form for organizing and managing important data such as account status, transaction information, and the like.

The Etherhouse designs three MPT trees, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree, aiming at data needing to be stored and maintained in a block chain. In addition to the above three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.

An MPT state tree, which is an MPT tree organized by account state data of all accounts in a blockchain; an MPT transaction tree, which is an MPT tree organized by transaction (transaction) data in a blockchain; the MPT receipt tree is organized into transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are eventually added to the block header of the corresponding block.

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.

It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;

for example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.

After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is completed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a Smart contract (Smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.

After Bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, each node can execute the Transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.

After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.

As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.

As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 4, the From field of the transaction is used To record the address of the account initiating the invocation of the smart contract, the To field is used To record the address of the invoked smart contract, and the Data field of the transaction is used To record the method and parameters of the invocation of the smart contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed block link point (e.g., node 1 in fig. 2).

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.

Conventional blockchain projects, represented by etherhouses, typically support conversion of real-world currency into virtual tokens that can be circulated through the chain in order to effect a "value transfer" over the blockchain.

In the blockchain field, for some blockchain items derived from the ethernet-based architecture (such as ant blockchains), the function of converting real-world currency into virtual tokens that can circulate on the chains is generally no longer supported; instead, in these blockchain projects, some non-monetary attributes of the physical assets in the real world may be converted into virtual assets that can be circulated over the blockchain.

It should be noted that converting an entity asset having a non-monetary attribute in the real world into a virtual asset on a blockchain generally refers to a process of "anchoring" the entity asset and a virtual asset on the blockchain to serve as a value support for the virtual assets, and further generating a virtual asset on the blockchain which is matched with the value of the entity asset and can be circulated between blockchain accounts on the blockchain.

In the implementation process, the account types supported by the blockchain can be expanded, and an asset account (also called an asset object) is expanded on the basis of the account types supported by the blockchain; for example, an asset account can be expanded on the basis of an external account and a contract account supported by an Ethernet; the expanded asset account is a virtual asset which can support the real-world non-monetary property of the physical asset as value and can be circulated between the blockchain accounts.

For users accessing such a blockchain, in addition to completing the creation of user accounts and intelligent contracts on the blockchain, a virtual asset matched with the entity asset value of non-monetary attributes of the real world is created on the blockchain, and circulation is performed on the blockchain;

for example, a user may convert physical assets of non-monetary attributes, such as real estate, stocks, loan contracts, notes, accounts receivable, etc., held to value-matched virtual assets for circulation over a blockchain.

The above asset account may be maintained by a structure, specifically, the account status of the account may be maintained by a structure. The content of the structure of the asset account may be the same as that of the ether house, and may be designed based on actual requirements;

in one implementation, for example, the content of the structure body of the asset account is the same as that of an ethernet bay, the structure body of the asset account may also include the fields of Balance, Nonce, Code, and Storage described above.

It should be noted that, in an ethernet, the Balance field is usually used to maintain the current account Balance of the account; for the block chain project derived based on the ethernet framework, since it may not support the conversion of real-world currency into virtual tokens that can be circulated on the chain, in such block chains, the meaning of the Balance field may be extended, and the Balance of the account is no longer represented, but is used to maintain the address information of the asset account corresponding to the "virtual asset" held by the account. In practical application, address information of asset accounts corresponding to multiple virtual assets can be maintained in the Balance field.

In this case, the external account, the contract account, and the asset account shown above can hold the virtual asset by adding address information of the asset account corresponding to the "virtual asset" that needs to be held in the Balance field. That is, in addition to the external account and the contract account, the asset account itself may hold the virtual asset.

For an asset account, Nonce, the field value of the Code field may or may not be null; and the field value of the Storage field may no longer be a null value; the Storage field may be used to maintain the asset status of the "virtual asset" corresponding to the asset account. The specific manner of maintaining the asset state of the "virtual asset" corresponding to the asset account in the Storage field can be flexibly designed based on requirements, and is not described in detail.

In the blockchain project derived based on the framework of the EtherFang, a user can create a virtual asset on the blockchain that matches the value of the real-world non-monetary attribute physical asset by the implementation shown below:

in one implementation, the transaction types supported by the blockchain may be extended to extend a transaction for creating virtual assets; for example, the types of transactions supported by the etherhouse typically include normal transfer transactions, transactions to create smart contracts, and transactions to invoke smart contracts, and a transaction to create virtual assets may be expanded based on the above three types of transactions.

In this case, a user may create a virtual asset for the user by issuing a transaction into the blockchain network by the client, which is performed by a node device in the blockchain in the local EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.

In another implementation, intelligent contracts for creating virtual assets may also be deployed on blockchains; the process of deploying the intelligent contract for creating the virtual asset is not described in detail.

In this case, the user may create a virtual asset for the user by issuing a transaction for invoking the intelligent contract into the blockchain network by the client, executing the transaction in the local EVM by the node device in the blockchain, and running a contract code associated with the intelligent contract in the EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.

Of course, for some blockchain items derived based on the ethernet framework, if the blockchain items also support the function of converting real-world currency into virtual tokens that can circulate on the chain, some non-currency property entity assets in the real world can still be converted into a form of virtual tokens that can circulate on the blockchain, and the virtual tokens circulate on the blockchain, which is not described in detail in this specification.

In a cross-chain scenario, multiple blockchains may implement cross-chain docking through cross-chain relays.

The cross-link relay can be respectively connected with the block chains through the bridging interfaces, and the cross-link data synchronization among the block chains is completed based on the realized data carrying logic.

The chain-crossing technology used for realizing the chain-crossing relay is not particularly limited in this specification; for example, in practical applications, a plurality of block chains can be connected by a chain-crossing mechanism such as side chain technology, notary technology, and the like.

After a plurality of block chains are connected in a butt joint mode through cross-chain relays, data on other block chains can be read and authenticated between the block chains, and intelligent contracts deployed on other block chains can be called through the cross-chain relays.

The intelligent contract deployed on the block chain can use the data stored on the block chain, and can also use the data on the data entity outside the chain through an Oracle prediction machine, so as to realize the data interaction between the intelligent contract and the data entity of the real world. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.

Unlike cross-link relays, the function of the Oracle;

that is, the cross-link relay is used to connect two blockchains, and the Oracle ora.

Referring to fig. 4, fig. 4 is a schematic diagram of a blockchain-based asset securitization system in accordance with an exemplary embodiment of the present disclosure.

The Asset securitization refers to a process of taking cash flow generated in the future of a basic Asset as repayment support, carrying out credit enhancement through structured design, and issuing Asset-Backed Securities (ABS) on the basis; it is a financing form that issues tradeable securities in favor of a particular portfolio of assets or a particular cash flow.

In summary, the basic process of securitization financing in one complete transaction generally includes: the initiator (i.e., the original beneficiary) may sell the securitable base asset to the investment manager, or may actively purchase the securitable base asset by the investment manager; then the investment manager can collect the basic Assets into a basic asset Pool (Assets Pool), and then issues securities financing in the financial market by taking cash flow generated by the basic asset Pool as repayment support; finally, the cash flow generated by the underlying asset pool can be utilized to liquidate the issued securities.

The investment manager may be a Special Purpose organization (SPV), among others.

In the block chain-based asset securitization system as shown in fig. 4, the original rights beneficiary can publish the basic assets held by the original rights beneficiary to the block chain for credentialing, and the investment manager can purchase the basic assets from the original rights beneficiary and aggregate the basic assets credentialed in the block chain into a basic asset pool, i.e., create a basic asset pool based on the basic assets.

Alternatively, the investment manager may issue the basic assets purchased from the original beneficiary to the blockchain for storage and assemble the basic assets stored in the blockchain into the basic asset pool, i.e., create the basic asset pool based on the basic assets.

Referring to the aforementioned process of persisting evidence-keeping data in the blockchain, the investment manager may construct the underlying asset into an asset issuance transaction according to a standard transaction format, and issue the asset issuance transaction to the blockchain for evidence-keeping.

In particular, the investment manager may enable the creation of a pool of base assets based on the base assets by invoking intelligent contracts deployed on the blockchain. In this case, the base asset pool may be a collection of identifications of several screened base assets generated by the intelligent contract. The set may be stored in an account Storage space (e.g., Storage field) of the contract account corresponding to the intelligent contract or in an account Storage space of the blockchain account of the investment manager.

Subsequently, the investment manager may issue securitized assets on the blockchain with the underlying pool of assets as a value support, i.e., with future cash flows generated by the underlying pool of assets as reimbursement support.

Wherein the underlying assets may be underlying debt assets (e.g., accounts receivable); the securitized asset may be ABS (e.g., bond or fund); the investment manager supports the basic asset pool as a value in the process of issuing the securitized assets on the blockchain, and may refer to the process of creating the virtual assets on the blockchain, which is not described herein again.

Similarly, referring to the aforementioned process of persisting the credentialing data in the blockchain, the investment manager may construct the securitized asset into an asset issuance transaction according to a standard transaction format, and issue the asset issuance transaction to the blockchain for credentialing, so as to implement issuance of the securitized asset on the blockchain.

Wherein, the transaction format may include asset participant information such as original rights beneficiary, investment manager, asset service organization, custody, supervision, rating organization, law, audit, etc., that is, an asset issuance transaction constructed based on the above-mentioned base asset or the above-mentioned securitized asset may include, in addition to the corresponding asset information issued by the investment manager in the blockchain, the corresponding asset participant information issued by the investment manager in the blockchain, such as: for a certain basic asset, the data in the asset publishing transaction constructed based on the basic asset can comprise original rights beneficiaries, investment managers and other asset participants of the basic asset; for a securitized asset, the data in the asset issuance transaction constructed based on the securitized asset may include asset participants of the securitized asset, such as an investment manager, custody, supervision, etc.

In practice, asset distribution transactions issued to the blockchain by multiple investment managers may be stored on the blockchain. The transaction format of the asset issuing transaction issued to the blockchain by different investment managers can be different according to actual conditions.

The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.

In terms of addressing privacy, a Trusted Execution Environment (TEE) is another approach. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code.

In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and AMD PSP (Platform Security Processor).

In a traditional solution combining a blockchain and a TEE, in order to realize privacy protection, an intelligent contract is wholly taken as data needing privacy protection to be called and executed in the TEE, and all contract states are stored on the blockchain in an encrypted mode.

Referring to fig. 5, fig. 5 is a flowchart illustrating a blockchain-based asset querying method according to an exemplary embodiment of the present disclosure. The block chain-based asset query method can be applied to the block chain-based asset securitization system shown in fig. 4 as an electronic device added to the block chain as a node device; the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a Personal Digital Assistants (PDAs), and the like, which is not limited in this specification. The asset query method based on the block chain can comprise the following steps:

step 502, receiving a call transaction sent by a client for a target intelligent contract deployed on the blockchain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

step 504, in response to the invoking transaction, decrypting the contract code of the target intelligent contract in the trusted execution environment, executing the decrypted contract code in the trusted execution environment, and determining whether the asset querying user has a viewing right of the target asset issuing transaction;

step 506, if it is determined that the asset querying user has the viewing right of the target asset publishing transaction, returning the target asset publishing transaction decrypted in the trusted execution environment to the client.

In this embodiment, the node device in the blockchain may be equipped with a trusted execution environment, and the trusted execution environment may specifically be a trusted execution environment that is based on a security extension of CPU hardware and is completely isolated from the outside.

Trusted execution environments were first the concept proposed by Global Platform to address the secure isolation of resources on mobile devices, providing trusted secure execution environments for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest.

Along with the rapid development of the internet, the security requirement is higher and higher, and more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center. The concept of TEE has also been developed and expanded at a high rate. The concept now referred to as TEE has been a more generalized TEE than the concept originally proposed. For example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which have gained wide acceptance in the industry. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the current TEE technology introduces a remote attestation mechanism which is endorsed by a hardware manufacturer (mainly a CPU manufacturer) and ensures that a user can verify the TEE state through a digital signature technology. Meanwhile, only the safety requirement which cannot be met by the safety resource isolation is provided, and further data privacy protection is also provided. Commercial TEE including Intel SGX, AMD SEV also provide memory encryption techniques, limiting trusted hardware within the CPU, with the data of the bus and memory being ciphertext to prevent snooping by malicious users. For example, TEE technology such as intel's software protection extensions (SGX) isolates code execution, remote attestation, secure configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.

In an embodiment shown, taking the above-mentioned trusted execution environment as an Intel SGX as an example, the SGX provides an enclosure (also called enclave), i.e., an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the above-mentioned node device as an example, the CPU supporting the SGX may allocate a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) in the memory by using a newly added processor instruction, and encrypt data therein by using an Encryption engine mee (memory Encryption engine) in the CPU.

The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. In practical application, the private data can be encrypted and then transmitted to the enclosure in a ciphertext form, and the corresponding secret key is transmitted to the enclosure through remote certification. Then, the operation is performed by using the data under the encryption protection of the CPU, and the result is returned in a ciphertext form. In this mode, not only can the powerful calculation be utilized, but also data leakage is not worried about.

In this case, the node device may load the deployed virtual machine into the enclosure provided by the SGX technology. After the contract code of the target intelligent contract is decrypted based on the extracted decryption key to obtain the plaintext contract code of the target intelligent contract, the node device may allocate a part of the area EPC in the memory by using a processor instruction newly added in the CPU, and encrypt and store the plaintext contract code obtained by decryption in the EPC through an encryption engine MEE in the CPU. The encrypted content in the EPC enters the CPU and is decrypted into plaintext. And in the CPU, the operation is carried out on the plain text code, and the execution process of the code is completed.

On the other hand, after the user writes the contract code of the intelligent contract, a creating transaction for creating the intelligent contract is constructed on the client based on the contract code of the intelligent contract, and the transaction is sent to the block link point device which is in butt joint with the client.

For example, in implementation, if a user writes contract code of an intelligent contract in a high-level language, the client may further compile the contract code via a compiler to generate byte codes that can be deployed on a blockchain, then "package" a creation transaction for creating the intelligent contract based on the byte codes of the intelligent contract generated by compilation, and send the transaction to a blockchain node device interfaced with the client.

It should be noted that, in order to ensure the privacy of the contract code written by the user, the client may encrypt the written contract code by using the key.

For example, during implementation, the client may directly encrypt the whole created transaction; or, only the byte code itself of the intelligent contract carried in the established transaction may be encrypted; the specific encryption method can be flexibly selected by those skilled in the art when the technical scheme disclosed in the specification is implemented.

The encryption mode used when encrypting the contract code can adopt symmetric encryption or asymmetric encryption.

For example, the Encryption Algorithm used for symmetric Encryption may be DES Algorithm (Data Encryption Standard), 3DES Algorithm (Triple DES), TDEA Algorithm (Triple Data Encryption Algorithm), Blowfish Algorithm, RC5 Algorithm, IDEA Algorithm (International Data Encryption Algorithm), and the like. The algorithm used for asymmetric encryption may be RSA algorithm, Elgamal algorithm, knapsack algorithm, Rabin algorithm, D-H algorithm (Diffie-Hellman algorithm), ECC algorithm (Elliptic Curve encryption algorithm), etc.

In addition, the encryption mode adopted when the contract code is encrypted can also adopt a mode of combining symmetric encryption and asymmetric encryption. This encryption is generally referred to as Digital Envelope (Digital Envelope) encryption.

For example, the client encrypts the contract code by using a symmetric encryption algorithm, that is, encrypts the contract code by using a private key of the symmetric encryption algorithm, and then encrypts a private key used in the symmetric encryption algorithm by using a public key of the asymmetric encryption algorithm. Namely, the contract code is encrypted by using a secret key of a symmetric encryption algorithm; and further encrypting the key used when encrypting the contract code by using the key of the asymmetric encryption algorithm.

In the trusted execution environment described above, a decryption key corresponding to a contract code of an encrypted smart contract stored in a distributed ledger of a blockchain may be stored and maintained. For example, in practical applications, a key generation algorithm may be installed in the trusted execution environment, and when a user successfully creates a contract account corresponding to a smart contract in a blockchain, the node device may invoke the installed key generation algorithm in the trusted execution environment to create a root key for the contract account.

If an asymmetric encryption mode is adopted, the root key comprises a public and private key pair; the public key is used for encrypting the contract code and is held by a user; the private key is stored in the trusted execution environment and is used for decrypting the encrypted contract code; if symmetric encryption is used, the root key includes only one key for encrypting and decrypting the contract code.

The specific type of the key generation algorithm and the specific implementation process for creating the root key based on the key generation algorithm are not described in detail in this specification.

In yet another aspect, asset distribution transactions issued to the blockchain by the investment manager may also be pre-encrypted.

In this embodiment, if a user needs to query a certain asset issuing transaction stored on the blockchain, the user (referred to as an asset querying user) may construct a calling transaction for an intelligent contract (referred to as a target intelligent contract) which is encrypted in advance through a client, and issue the calling transaction to the blockchain for storage by the client.

The calling transaction may include a transaction identifier (for example, a transaction storage address) of an asset issuing transaction (referred to as a target asset issuing transaction) queried by the asset query user, so that when the node device in the block chain receives the calling transaction, the node device determines the asset issuing transaction which needs to be queried by the asset query user based on the transaction identifier in the calling transaction, and then may query the asset issuing transaction by invoking the target intelligent contract.

Referring to the aforementioned process of persisting the evidence data in the blockchain, the node device in the blockchain may receive the call transaction and perform consensus processing on the call transaction. After agreement is reached, the node devices in the blockchain may package the call transaction into a block in which persistent storage is performed.

For the call transaction packed into the block, the node device in the block chain may execute the call transaction, that is, may decrypt, in the installed trusted execution environment, the contract code of the target smart contract in response to the call transaction, and execute the decrypted contract code in the trusted execution environment.

In practical applications, the process of executing the call transaction in the trusted execution environment may be specifically completed by a virtual machine deployed in the trusted execution environment; that is, the virtual machine deployed in the trusted execution environment is the execution subject of the call transaction; for example, taking an ethernet house as an example, a node device usually performs transactions through an on-board ethernet house Virtual Machine (EVM).

Specifically, after receiving the call transaction sent by the client, the node device in the blockchain may still check whether the transaction is valid, whether the format is correct, whether the signature of the transaction is legal, and the like, and execute the call transaction in the trusted execution environment after all the checks and verifications are passed.

Before executing the call transaction in the trusted execution environment, the function type of the transaction can be confirmed first; when the transaction is confirmed to be a calling transaction for calling the intelligent contract, the encrypted contract code of the target intelligent contract stored in the distributed ledger of the block chain can be further acquired, and the acquired encrypted contract code of the target intelligent contract is sent to the trusted execution environment and executed in the trusted execution environment.

The trusted execution environment may determine whether the asset querying user has viewing permissions for the target asset issuance transaction based on the execution result of the decrypted contract code.

In one illustrated embodiment, because the target asset publication transaction may include corresponding asset participant information (i.e., participant users associated with the asset), the target asset publication transaction may be decrypted in the trusted execution environment and a determination may be made as to whether the asset querying user matches the participant user in the target asset publication transaction. If the asset query user matches a participant user in the target asset publication transaction, it may be determined whether the asset query user has viewing rights for the target asset publication transaction.

After determining that the asset querying user has the viewing right of the target asset publishing transaction, the node device in the blockchain may return the target asset publishing transaction decrypted in the trusted execution environment to the client, so that the asset querying user may view the target asset publishing transaction through the client.

In one illustrated embodiment, the node device in the blockchain may encrypt the target asset issuance transaction decrypted in the trusted execution environment based on the public key of the asset querying user, and return the encrypted target asset issuance transaction to the client. When receiving the encrypted target asset issuing transaction, the client may decrypt the encrypted target asset issuing transaction based on the private key of the asset querying user to obtain the original content of the target asset issuing transaction.

It should be noted that a decryption key for decrypting the contract code of the target smart contract and the asset issuance transaction may be stored by the trusted execution environment; wherein a decryption key stored in the trusted execution environment is prohibited from being derived from the trusted execution environment.

Referring to fig. 6, fig. 6 is a flowchart illustrating another method for querying a blockchain-based asset according to an exemplary embodiment of the present disclosure. The block chain-based asset query method can be applied to the block chain-based asset securitization system shown in fig. 4 as an electronic device added to the block chain as a node device; the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a Personal Digital Assistants (PDAs), and the like, which is not limited in this specification. The asset query method based on the block chain can comprise the following steps:

step 602, receiving a call transaction sent by a client for a target intelligent contract deployed on the blockchain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

step 604, in response to the invoking transaction, decrypting the contract code of the target intelligent contract in the trusted execution environment, executing the decrypted contract code in the trusted execution environment, and determining whether the asset querying user has a viewing right of the target asset issuing transaction;

step 606, if it is determined that the asset querying user has the view permission of the target asset issuing transaction, encrypting the decryption key of the target asset issuing transaction stored in the trusted execution environment based on the public key of the asset querying user, and returning the encrypted decryption key to the client, so that the client decrypts the encrypted decryption key based on the private key of the asset querying user, and decrypts the target asset issuing transaction based on the decrypted decryption key, thereby obtaining the original content of the target asset issuing transaction.

In this embodiment, after determining that the asset querying user has the viewing right of the target asset issuing transaction, the node device in the blockchain may encrypt a decryption key of the target asset issuing transaction stored in the trusted execution environment based on the public key of the asset querying user, and return the encrypted decryption key to the client. When receiving the encrypted decryption key, the client may decrypt the encrypted decryption key based on the private key of the asset querying user, and further decrypt the target asset issuance transaction based on the decrypted decryption key, so as to obtain the original content of the target asset issuance transaction.

The specific implementation method of each step in this embodiment may refer to the embodiment shown in fig. 5, and this description is not repeated here.

In the above technical solution, a client may send a call transaction for a target intelligent contract that is deployed on the blockchain and encrypted in advance, so that a node device in the blockchain decrypts a contract code of the target intelligent contract in a hosted trusted execution environment in response to the call transaction, executes the decrypted contract code in the trusted execution environment, and determines whether an asset query user has a view permission of a target asset issuance transaction corresponding to a transaction identifier in the call transaction; if so, returning the encrypted decryption key in the trusted execution environment to the client, so that the client decrypts the original content of the target asset publishing transaction based on the decryption key. In this way, the asset issuing transaction issued to the blockchain by different investment managers can be subjected to data isolation, namely only participant users related to the asset issuing transaction are allowed to inquire the asset issuing transaction; in addition, data security may be ensured by decrypting contract code of the smart contract, as well as asset issuance transactions, in the trusted execution environment.

In correspondence with the foregoing embodiments of the blockchain-based asset querying method, the present specification also provides embodiments of a blockchain-based asset querying device.

The embodiment of the asset query device based on the block chain can be applied to the electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 7, a hardware structure diagram of an electronic device where an asset query device based on a block chain is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 7, the electronic device where the device is located in the embodiment may also include other hardware according to an actual function of the asset query based on the block chain, which is not described again.

Referring to fig. 8, fig. 8 is a block diagram of an asset query device based on a block chain according to an exemplary embodiment of the present disclosure. The blockchain-based asset querying device 80 may be applied to the electronic device shown in fig. 7, which may join the blockchain as a node device. It should be noted that the node device in the block chain is equipped with a trusted execution environment; the block chain stores the asset issuing transaction issued to the block chain by the investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuance transaction is pre-encrypted. The block chain based asset query device 80 may include:

a receiving module 801, configured to receive a call transaction sent by a client for a target intelligent contract deployed on the blockchain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

a determining module 802, configured to decrypt the contract code of the target intelligent contract in the trusted execution environment in response to the invoking transaction, execute the decrypted contract code in the trusted execution environment, and determine whether the asset querying user has a viewing right of the target asset issuing transaction;

the returning module 803, if it is determined that the asset querying user has the viewing right of the target asset publishing transaction, returns the target asset publishing transaction decrypted in the trusted execution environment to the client.

In this embodiment, asset distribution transactions issued to the blockchain by a plurality of investment managers are stored on the blockchain; wherein the transaction formats of the asset issuing transactions issued to the blockchain by different investment managers are different.

In this embodiment, the assets issued by the investment manager in the blockchain include:

In this embodiment, the securitized assets are bonds or funds; the underlying assets are underlying debt assets.

In this embodiment, the asset issuance transaction further includes the asset related participant users issued by the investment manager in the blockchain;

the determination module 802:

In this embodiment, the returning module 803:

In this embodiment, the trusted execution environment stores therein a decryption key for decrypting the contract code of the target smart contract and the asset issuance transaction; wherein a decryption key stored in the trusted execution environment is prohibited from being derived from the trusted execution environment.

In this embodiment, the encryption method adopted for the contract code of the target intelligent contract includes any one of the following encryption methods: a symmetric encryption mode, an asymmetric encryption mode, a mode of combining symmetric encryption and asymmetric encryption.

In this embodiment, the combination of symmetric encryption and asymmetric encryption includes: digital envelope encryption mode.

In this embodiment, the trusted execution environment includes an Intel SGX.

Referring to fig. 9, fig. 9 is a block diagram of another block chain-based asset query device according to an exemplary embodiment of the present disclosure. The blockchain-based asset lookup apparatus 90 may be applied to an electronic device shown in fig. 7, which may be added to the blockchain as a node device. It should be noted that the node device in the block chain is equipped with a trusted execution environment; the block chain stores the asset issuing transaction issued to the block chain by the investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuance transaction is pre-encrypted. The block chain based asset query device 90 may comprise:

a receiving module 901, configured to receive a call transaction sent by a client for a target intelligent contract deployed on the blockchain; the calling transaction comprises a transaction identifier of a target asset issuing transaction inquired by an asset inquiry user; the contract codes of the target intelligent contracts stored in the block chain are encrypted in advance;

a determining module 902, configured to decrypt the contract code of the target intelligent contract in the trusted execution environment in response to the invoking transaction, execute the decrypted contract code in the trusted execution environment, and determine whether the asset querying user has a viewing right of the target asset issuing transaction;

a returning module 903, configured to encrypt a decryption key of the target asset issuing transaction stored in the trusted execution environment based on a public key of the asset querying user if it is determined that the asset querying user has the viewing permission of the target asset issuing transaction, and return the encrypted decryption key to the client, so that the client decrypts the encrypted decryption key based on a private key of the asset querying user and decrypts the target asset issuing transaction based on the decrypted decryption key to obtain an original content of the target asset issuing transaction.

The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

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

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. An asset query method based on a block chain is applied to node equipment in the block chain, and the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the method comprises the following steps:

2. The method of claim 1, said blockchain having stored thereon asset distribution transactions distributed to said blockchain by a plurality of investment managers; wherein the transaction formats of the asset issuing transactions issued to the blockchain by different investment managers are different.

3. The method of claim 1, the investment manager publishing assets in the blockchain comprising:

4. The method of claim 3, the securitized asset being a bond or fund; the underlying assets are underlying debt assets.

5. The method of claim 1, the asset issuance transaction further comprising an asset related participant user issued by the investment manager in the blockchain;

6. The method of claim 1, the returning the target asset post-decryption transaction in the trusted execution environment to the client, comprising:

7. The method of claim 1, the trusted execution environment having stored therein a decryption key that decrypts contract code of the target smart contract and the asset issuance transaction; wherein a decryption key stored in the trusted execution environment is prohibited from being derived from the trusted execution environment.

8. The method of claim 7, wherein the encryption employed for the contract code of the target intelligent contract comprises any one of the following: a symmetric encryption mode, an asymmetric encryption mode, a mode of combining symmetric encryption and asymmetric encryption.

9. The method of claim 8, the symmetric encryption in combination with the asymmetric encryption, comprising: digital envelope encryption mode.

10. The method of claim 1, the trusted execution environment comprising an Intel SGX.

11. An asset query method based on a block chain is applied to node equipment in the block chain, and the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the method comprises the following steps:

12. An asset query device based on a block chain is applied to node equipment in the block chain, and the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the device comprises:

13. The apparatus of claim 12, said blockchain having stored thereon asset distribution transactions distributed thereto by a plurality of investment managers; wherein the transaction formats of the asset issuing transactions issued to the blockchain by different investment managers are different.

14. The apparatus of claim 12, said investment manager publishing assets in said blockchain comprising:

15. The apparatus of claim 14, the securitized asset being a bond or fund; the underlying assets are underlying debt assets.

16. The apparatus of claim 12, said asset issuance transaction further comprising an asset related participant user issued by said investment manager in said blockchain;

the determination module:

17. The apparatus of claim 12, the return module to:

18. The apparatus of claim 12, the trusted execution environment having stored therein a decryption key that decrypts contract code of the target smart contract and the asset issuance transaction; wherein a decryption key stored in the trusted execution environment is prohibited from being derived from the trusted execution environment.

19. The apparatus of claim 18, wherein the encryption employed for the contract code of the target intelligent contract comprises any one of the following: a symmetric encryption mode, an asymmetric encryption mode, a mode of combining symmetric encryption and asymmetric encryption.

20. The apparatus of claim 19, the symmetric encryption in combination with the asymmetric encryption, comprising: digital envelope encryption mode.

21. The apparatus of claim 12, the trusted execution environment comprising an Intel SGX.

22. An asset query device based on a block chain is applied to node equipment in the block chain, and the node equipment is loaded with a trusted execution environment; the block chain is stored with asset issuing transactions issued to the block chain by an investment manager; wherein the asset issuance transaction includes asset information issued by the investment manager in the blockchain; the asset issuing transaction is encrypted in advance; the device comprises:

23. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of the method of any one of claims 1 to 10 by executing the executable instructions.

24. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the steps of the method of claim 11 by executing the executable instructions.

25. A computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, carry out the steps of the method according to any one of claims 1 to 10.

26. A computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, perform the steps of the method of claim 11.