[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2022206210A1 - 基于区块链的资产管理 - Google Patents

基于区块链的资产管理 Download PDF

Info

Publication number
WO2022206210A1
WO2022206210A1 PCT/CN2022/076793 CN2022076793W WO2022206210A1 WO 2022206210 A1 WO2022206210 A1 WO 2022206210A1 CN 2022076793 W CN2022076793 W CN 2022076793W WO 2022206210 A1 WO2022206210 A1 WO 2022206210A1
Authority
WO
WIPO (PCT)
Prior art keywords
asset
blockchain
type
target
operator
Prior art date
Application number
PCT/CN2022/076793
Other languages
English (en)
French (fr)
Inventor
李艳鹏
陆旭明
周知远
郭学鹏
赵文强
Original Assignee
支付宝(杭州)信息技术有限公司
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2022206210A1 publication Critical patent/WO2022206210A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain-based asset management method, apparatus, and electronic device.
  • This specification proposes a blockchain-based asset management method, the method is applied to node devices in the blockchain, and the operator of the blockchain defines an asset type and an asset format corresponding to the asset type;
  • the asset management party accessing the blockchain deploys a first smart contract related to assets on the blockchain; the method includes: receiving a first contract sent by an asset creator connected to the asset management party Invoke transaction, the first contract invocation transaction includes the type identifier of the target asset type; in response to the first contract invocation transaction, invoke the first acquisition logic in the first smart contract to acquire the asset management party's location
  • the asset model defined in the blockchain and corresponding to the target asset type indicated by the type identifier, the asset model includes asset creation information corresponding to the target asset type; After the asset model corresponding to the asset type, the creation logic in the first smart contract is further invoked, based on the asset format defined by the blockchain operator and corresponding to the target asset type, and the obtained asset format corresponding to the target asset type.
  • the operator defines the target asset type and the asset format corresponding to the target asset type in the native code of the blockchain; the blockchain-based operator defines The asset format corresponding to the target asset type, and the acquired asset creation information in the asset model corresponding to the target asset type, creating a standardized blockchain asset in the blockchain includes: obtaining all the assets.
  • the asset format corresponding to the target asset type defined by the operator in the native code of the blockchain; the asset format corresponding to the target asset type defined by the operator of the blockchain, and obtaining The obtained asset creation information in the asset model corresponding to the target asset type creates a standardized blockchain asset in the blockchain.
  • the centralized server corresponding to the operator maintains the target asset type defined by the operator and the asset format corresponding to the target asset type; the blockchain-based operator The defined asset format corresponding to the target asset type, and the acquired asset creation information in the asset model corresponding to the target asset type, create standardized blockchain assets in the blockchain, including: The asset format corresponding to the target asset type defined by the operator and maintained by the centralized server is obtained through an Oracle oracle; the asset format corresponding to the target asset type defined by the operator based on the blockchain , and the acquired asset creation information in the asset model corresponding to the target asset type, and create standardized blockchain assets in the blockchain.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle state tree of the blockchain in the form of key-value pairs .
  • the asset format includes several asset attribute fields; the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields; the asset creation information includes The verification rules for the attribute values corresponding to the several asset attribute fields; the asset format defined by the blockchain-based operator and corresponding to the target asset type, and the obtained asset format corresponding to the target asset type
  • the asset creation information in the asset model creating standardized blockchain assets in the blockchain, including: based on the verification rules in the asset model, the assets submitted by the asset creator and the several asset attributes
  • the attribute value corresponding to the field is verified; if the verification is passed, further based on the asset format defined by the operator of the blockchain and corresponding to the target asset type, and the attribute value, in the blockchain Create standardized blockchain assets in .
  • the asset creation information includes a state machine corresponding to the blockchain asset; the method further includes: after creating a standardized blockchain asset in the blockchain, based on the asset model The state machine of , updates the asset state corresponding to the blockchain asset.
  • the method further includes: receiving a second contract invocation transaction sent by an asset transfer party docked by the asset management party, where the second contract invocation transaction includes the asset identifier of the blockchain asset;
  • the second contract invokes the transaction, invokes the second acquisition logic in the first smart contract, acquires the blockchain asset stored in the blockchain and corresponds to the asset identifier, and obtains the asset identifier corresponding to the asset identifier.
  • the transfer logic in the smart contract is further invoked to transfer the acquired blockchain assets corresponding to the asset identifiers.
  • the target asset type and the asset format corresponding to the target asset type defined by the operator of the blockchain include: the target asset defined by the operator of the blockchain based on a general programming language type and the asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general programming language An asset model corresponding to the target asset type defined in the blockchain.
  • the general-purpose programming language includes a general-purpose declarative programming language.
  • the general-purpose declarative programming language includes a domain-specific language.
  • the operator includes a blockchain service platform;
  • the asset management party includes a financial institution accessing the blockchain service platform;
  • the asset creator includes a user who is provided with asset services by the financial institution client.
  • This specification also proposes a blockchain-based asset management method.
  • the method is applied to a node device in a blockchain, and the operator of the blockchain deploys the first asset-related asset on the blockchain.
  • Two smart contracts the second smart contract maintains the asset type defined by the operator and the asset format corresponding to the asset type; the asset management party accessing the blockchain deploys on the blockchain the first smart contract related to the asset; the method includes: receiving a first contract invocation transaction sent by an asset creator docked by the asset management party, the first contract invocation transaction including the type identifier of the target asset type; responding Invoke a transaction in the first contract, call the first acquisition logic in the first smart contract, and acquire the target asset type defined by the asset manager in the blockchain and indicated by the type identifier
  • the asset model includes asset creation information corresponding to the target asset type; and, after acquiring the asset model corresponding to the target asset type, further send the contract to the second smart contract.
  • the inter-contract invocation message includes the acquired asset creation information in the asset model corresponding to the target asset type, so as to invoke the creation logic in the second smart contract, based on the The asset format corresponding to the target asset type, and the asset creation information, create a standardized blockchain asset in the blockchain, and return the created asset identifier of the blockchain asset to the first.
  • a smart contract is the acquired asset creation information in the asset model corresponding to the target asset type, so as to invoke the creation logic in the second smart contract, based on the The asset format corresponding to the target asset type, and the asset creation information, create a standardized blockchain asset in the blockchain, and return the created asset identifier of the blockchain asset to the first.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle storage tree of the second smart contract in the form of key-value pairs middle.
  • the asset format includes several asset attribute fields; the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields; the asset creation information includes The verification rules for the attribute values corresponding to the several asset attribute fields; the asset format defined by the blockchain-based operator and corresponding to the target asset type, and the obtained asset format corresponding to the target asset type
  • the asset creation information in the asset model creating standardized blockchain assets in the blockchain, including: based on the verification rules in the asset model, the assets submitted by the asset creator and the several asset attributes
  • the attribute value corresponding to the field is verified; if the verification is passed, further based on the asset format defined by the operator of the blockchain and corresponding to the target asset type, and the attribute value, in the blockchain Create standardized blockchain assets in .
  • the asset creation information includes a state machine corresponding to the blockchain asset; the method further includes: after creating a standardized blockchain asset in the blockchain, based on the asset model The state machine of , updates the asset state corresponding to the blockchain asset.
  • the method further includes: receiving a second contract invocation transaction sent by an asset transfer party docked by the asset management party, where the second contract invocation transaction includes the asset identifier of the blockchain asset;
  • the second contract invokes the transaction, invokes the second acquisition logic in the first smart contract, acquires the blockchain asset stored in the blockchain and corresponds to the asset identifier, and obtains the asset identifier corresponding to the asset identifier.
  • the transfer logic in the smart contract is further invoked to transfer the acquired blockchain assets corresponding to the asset identifiers.
  • the target asset type and the asset format corresponding to the target asset type defined by the operator of the blockchain include: the target asset defined by the operator of the blockchain based on a general programming language type and the asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general programming language An asset model corresponding to the target asset type defined in the blockchain.
  • the general-purpose programming language includes a general-purpose declarative programming language.
  • the general-purpose declarative programming language includes a domain-specific language.
  • the operator includes a blockchain service platform;
  • the asset management party includes a financial institution accessing the blockchain service platform;
  • the asset creator includes a user who is provided with asset services by the financial institution client.
  • This specification also proposes a blockchain-based asset management device, the device is applied to node devices in the blockchain, and the operator of the blockchain defines an asset type and an asset format corresponding to the asset type ;
  • the asset management party accessing the blockchain deploys a first smart contract related to assets on the blockchain;
  • the device includes: a first receiving module that receives the asset creation docked by the asset management party
  • the first contract invocation transaction sent by the party, the first contract invocation transaction includes the type identifier of the target asset type;
  • the acquisition module in response to the first contract invocation transaction, invokes the first acquisition logic in the first smart contract , acquiring the asset model defined in the blockchain by the asset management party and corresponding to the target asset type indicated by the type identifier, where the asset model includes asset creation information corresponding to the target asset type;
  • the creation module after acquiring the asset model corresponding to the target asset type, further calls the creation logic in the first smart contract, based on the target asset type defined by the operator of the blockchain and the target asset type The corresponding
  • the operator defines the target asset type and the asset format corresponding to the target asset type in the native code of the blockchain; the creation module: obtains the The asset format corresponding to the target asset type defined in the native code of the blockchain; the asset format corresponding to the target asset type defined by the operator of the blockchain, and the obtained asset format corresponding to the target asset type
  • the asset creation information in the asset model corresponding to the asset type creates standardized blockchain assets in the blockchain.
  • the centralized server corresponding to the operator maintains the target asset type defined by the operator and the asset format corresponding to the target asset type; the creation module obtains the target asset type through an Oracle oracle machine.
  • the asset creation information in the asset model corresponding to the target asset type is created, and standardized blockchain assets are created in the blockchain.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle state tree of the blockchain in the form of key-value pairs .
  • the asset format includes several asset attribute fields;
  • the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields;
  • the asset creation information includes The verification rules for the attribute values corresponding to the several asset attribute fields;
  • the creation module based on the verification rules in the asset model, the attribute values submitted by the asset creator and corresponding to the several asset attribute fields Verification; if the verification passes, further create a standardized block in the blockchain based on the asset format corresponding to the target asset type defined by the operator of the blockchain and the attribute value chain assets.
  • the asset creation information includes a state machine corresponding to the blockchain asset; the creation module: after creating a standardized blockchain asset in the blockchain, based on the A state machine that updates the asset state corresponding to the blockchain asset.
  • the device further includes: a second receiving module for receiving a second contract invocation transaction sent by an asset transfer party docked by the asset management party, where the second contract invocation transaction includes the assets of the blockchain asset
  • the transfer module in response to the second contract invoking a transaction, invokes the second acquisition logic in the first smart contract to acquire the blockchain asset stored in the blockchain and corresponding to the asset identifier, and After acquiring the blockchain asset corresponding to the asset identifier, the transfer logic in the smart contract is further invoked to perform asset transfer on the acquired blockchain asset corresponding to the asset identifier.
  • the target asset type and the asset format corresponding to the target asset type defined by the operator of the blockchain include: the target asset defined by the operator of the blockchain based on a general programming language type and the asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general programming language An asset model corresponding to the target asset type defined in the blockchain.
  • the general-purpose programming language includes a general-purpose declarative programming language.
  • the general-purpose declarative programming language includes a domain-specific language.
  • the operator includes a blockchain service platform;
  • the asset management party includes a financial institution accessing the blockchain service platform;
  • the asset creator includes a user who is provided with asset services by the financial institution client.
  • This specification also proposes a blockchain-based asset management device, the device is applied to node equipment in the blockchain, and the operator of the blockchain deploys the first asset-related asset on the blockchain.
  • Two smart contracts the second smart contract maintains the asset type defined by the operator and the asset format corresponding to the asset type; the asset management party accessing the blockchain deploys on the blockchain
  • a first smart contract related to an asset is obtained; the device includes: a first receiving module that receives a first contract invocation transaction sent by an asset creator connected to the asset management party, where the first contract invocation transaction includes a target asset type The type identifier; the acquisition module, in response to the first contract invoking transaction, invokes the first acquisition logic in the first smart contract to acquire the asset management party and the type defined in the blockchain.
  • the asset model includes asset creation information corresponding to the target asset type; and the creation module, after acquiring the asset model corresponding to the target asset type, Further send an inter-contract call message to the second smart contract, where the inter-contract call message includes the acquired asset creation information in the asset model corresponding to the target asset type to call the second smart contract.
  • Creation logic based on the asset format defined by the operator and corresponding to the target asset type, and the asset creation information, create a standardized blockchain asset in the blockchain, and use the created zone
  • the asset identifier of the blockchain asset is returned to the first smart contract.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle storage tree of the second smart contract in the form of key-value pairs middle.
  • the asset format includes several asset attribute fields;
  • the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields;
  • the asset creation information includes The verification rules for the attribute values corresponding to the several asset attribute fields;
  • the creation module based on the verification rules in the asset model, the attribute values submitted by the asset creator and corresponding to the several asset attribute fields Verification; if the verification passes, further create a standardized block in the blockchain based on the asset format corresponding to the target asset type defined by the operator of the blockchain and the attribute value chain assets.
  • the asset creation information includes a state machine corresponding to the blockchain asset; the creation module: after creating a standardized blockchain asset in the blockchain, based on the A state machine that updates the asset state corresponding to the blockchain asset.
  • the device further includes: a second receiving module for receiving a second contract invocation transaction sent by an asset transfer party docked by the asset management party, where the second contract invocation transaction includes the assets of the blockchain asset
  • the transfer module in response to the second contract invoking a transaction, invokes the second acquisition logic in the first smart contract to acquire the blockchain asset stored in the blockchain and corresponding to the asset identifier, and After acquiring the blockchain asset corresponding to the asset identifier, the transfer logic in the smart contract is further invoked to perform asset transfer on the acquired blockchain asset corresponding to the asset identifier.
  • the target asset type and the asset format corresponding to the target asset type defined by the operator of the blockchain include: the target asset defined by the operator of the blockchain based on a general programming language type and the asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general programming language An asset model corresponding to the target asset type defined in the blockchain.
  • the general-purpose programming language includes a general-purpose declarative programming language.
  • the general-purpose declarative programming language includes a domain-specific language.
  • the operator includes a blockchain service platform;
  • the asset management party includes a financial institution accessing the blockchain service platform;
  • the asset creator includes a user who is provided with asset services by the financial institution client.
  • This specification also proposes an electronic device, comprising: a processor; and a memory for storing instructions executable by the processor, and the processor implements the steps of the above method by running the executable instructions.
  • This specification also proposes a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, implement the steps of the above method.
  • the operator of the blockchain can define the target asset type and the asset format corresponding to the target asset type; the node device in the blockchain can receive a message sent by the asset creator connected to the asset management party.
  • the first contract calls the transaction
  • the first acquisition logic in the first smart contract is invoked to acquire the asset model defined by the asset manager in the blockchain corresponding to the target asset type, and further call the first acquisition logic.
  • the creation logic in the smart contract is based on the asset format corresponding to the target asset type defined by the operator of the blockchain, and the acquired asset creation information in the asset model corresponding to the target asset type.
  • Standardized blockchain assets are created in the chain; since the operator of the above-mentioned blockchain defines the asset type and the asset format corresponding to the asset type, all asset managers accessing the above-mentioned blockchain are in the blockchain.
  • the asset model corresponding to the asset type defined in all instructs the creation of blockchain assets according to the asset format corresponding to the asset type. Therefore, for the asset creator connected with any of the asset managers, these asset creation
  • the asset format of the blockchain asset corresponding to the asset type created by the party on the blockchain is the same, and the asset format corresponding to the asset type is defined by the operator of the blockchain.
  • Standardized blockchain assets are created in the blockchain, thereby facilitating the circulation of the created blockchain assets on the blockchain.
  • FIG. 1 is a schematic diagram of a network environment related to the blockchain shown in this specification
  • FIG. 2 is a flowchart of a blockchain-based asset management method shown in an exemplary embodiment of this specification
  • FIG. 3 is a flowchart of another blockchain-based asset management method shown in an exemplary embodiment of this specification.
  • FIG. 4 is a schematic diagram of a state machine shown in an exemplary embodiment of the present specification.
  • FIG. 5 is a hardware structure diagram of an electronic device where a blockchain-based asset management device is located according to an exemplary embodiment of this specification;
  • FIG. 6 is a block diagram of a blockchain-based asset management device shown in an exemplary embodiment of the present specification
  • FIG. 7 is a block diagram of another blockchain-based asset management apparatus shown in an exemplary embodiment of the present specification.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or fewer steps than described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.
  • FIG. 1 is a schematic diagram of a network environment related to the blockchain shown in this specification.
  • a client-side computing device 101 a server-side 102, and at least one blockchain system may be included; for example, a blockchain system 103, a blockchain system 104, and a blockchain system 105.
  • the client-side computing device 101 may include various types of client-side computing devices; for example, the client-side terminal device may include, for example, a PC terminal device, a mobile terminal device, an Other forms of smart devices with certain computing capabilities, and so on.
  • the client-side terminal device may include, for example, a PC terminal device, a mobile terminal device, an Other forms of smart devices with certain computing capabilities, and so on.
  • client-side computing device 101 does not mean that all the client-side computing devices therein are in the same communication network, but is merely a general term for these client-side computing devices.
  • At least part of the computing devices in the client-side terminal device 101 may be coupled to the server side 102 through various communication networks; for example, the device 1 and device 2 shown in FIG. 1 and the server side 102 coupled.
  • terminal devices in the client-side terminal device 101 may not be coupled with the server-side 102, but directly coupled to the blockchain system as blockchain nodes through various communication networks; for example, The device 4 shown in Figure 1 can be coupled to the blockchain system as a blockchain node.
  • the above-mentioned communication network may include wired and/or wireless communication networks; for example, it may be a local area network (Local Area Network, LAN), a wide area network (LAN) implemented based on a wired access network provided by an operator or a wireless access network (such as a mobile cellular network). Wide Area Network, WAN), the Internet, or a combination thereof.
  • LAN Local Area Network
  • LAN wide area network
  • WAN Wide Area Network
  • the Internet or a combination thereof.
  • the client-side computing device 101 may further include one or more user-side servers; for example, the device 5 shown in FIG. 1 . At least part of the computing devices in the client-side terminal device 101 may be coupled to the user-side server, and the user-side server may be further coupled to the above-mentioned server 102; for example, the device 1 and the device shown in FIG. 1 2 is coupled to the device 5, and the device 5 is further coupled to the server side 102.
  • the above-mentioned user-side server may be implemented by a service entity that has built a user account system; the above-mentioned service entity may include an operating entity of a service carrier that provides various online and/or offline services for users; the above-mentioned
  • the service carrier may include a service carrier in the form of software, and may also include a service carrier in the form of hardware.
  • the above-mentioned service carrier may include various client software for providing online Internet services; for example, a website, a webpage, an APP, and the like.
  • the above service carrier may also include various smart devices deployed offline and capable of providing offline services; for example, smart express cabinets deployed in residential areas, office areas, and public places.
  • the above-mentioned operating entities may include operators corresponding to the above-mentioned service carriers; for example, the above-mentioned operating entities may include individuals, organizations, companies, and enterprises that operate and manage the above-mentioned service carriers, and so on.
  • the server side 102 may also be coupled to one or more blockchain systems through various communication networks; for example, the server side 102 shown in FIG. 1 may be respectively coupled to the blockchain system 103 , Blockchain System 104 and Blockchain System 105, etc.
  • each blockchain system may maintain one or more blockchains (eg, public blockchains, private blockchains, consortium blockchains, etc.) or multiple blockchain nodes of multiple blockchains; for example, blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, blockchain node 4 as shown in Figure 1 Node i, etc. can jointly host one or more blockchains.
  • Cross-chain data access can also be performed between the blockchains included in each blockchain system and between the various blockchain systems.
  • blockchain nodes may include full nodes and light nodes.
  • the full node can download the blockchain transactions contained in each block in the blockchain in full, and can perform consensus verification on the blockchain transactions contained in each blockchain according to the blockchain consensus algorithm on board. .
  • the light node can not download the complete blockchain, but can only download the block header data of each block in the blockchain, and use the data contained in the block header as the verification root to verify the blockchain. authenticity of the transaction. Light nodes can attach to full nodes to access more features of the blockchain.
  • each blockchain node in the blockchain system 103 shown in FIG. 1 can serve as a full node; and the device 4 shown in FIG. 1 that is directly coupled to the blockchain system can serve as a light node , attached to each full node in the blockchain system 103 .
  • the blockchain node may be a physical device or a virtual device implemented in a server or server cluster; for example, the blockchain node device may be a physical host in a server cluster, or It is a virtual machine created after virtualizing the hardware resources carried by a server or server cluster based on virtualization technology.
  • Each blockchain node can be coupled together through various types of communication methods (such as TCP/IP) to form a network to carry one or more blockchains.
  • the server side 102 may include a BaaS platform (also referred to as a BaaS cloud) for providing blockchain services (BaaS, Blockchain as a Service).
  • the BaaS platform can target client-side computing devices coupled to the BaaS platform by providing pre-written software for activities that take place on the blockchain, such as subscriptions and notifications, user authentication, database management, and remote updates.
  • Simple and easy to use, one-click deployment, fast verification, flexible and customizable blockchain services which can accelerate the development, testing, and launch of blockchain business applications, and help the implementation of blockchain business application scenarios in various industries.
  • software such as MQ (Message Queue, message queue) services can be provided with the BaaS platform; client-side computing devices coupled with the BaaS platform can subscribe to the blockchain system coupled with the BaaS platform
  • MQ Message Queue, message queue
  • the smart contract deployed on a certain blockchain in the middle of the world generates contract events on the blockchain after the execution is triggered; the BaaS platform can monitor the events generated on the blockchain after the smart contract is triggered and executed, and then based on the MQ
  • the software related to the service adds the contract event to the message queue in the form of a notification message, so that the client-side computing device subscribed to the message queue can obtain the notification related to the above-mentioned contract event.
  • the BaaS platform can also provide enterprise-level platform services based on blockchain technology to help enterprise-level customers build a secure and stable blockchain environment and easily manage the deployment, operation, and maintenance of blockchains and development.
  • the BaaS platform can implement rich security policies and multi-tenant isolation environments based on cloud technology, provide advanced security protection based on chip encryption technology, and provide end-to-end services that can be quickly expanded without interruption based on highly reliable data storage.
  • high-availability services on the client side in another example, enhanced management capabilities to help customers build enterprise-grade blockchain network environments; and native support for standard blockchain applications and data, such as Hyperledger Fabric and Enterprise Ethereum-Quorum's mainstream open source blockchain technology to build an open and inclusive technology ecosystem.
  • Blockchains are generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • the most decentralized is the public chain.
  • the public chain is represented by Bitcoin and Ethereum.
  • Participants who join the public chain (also called nodes in the blockchain) can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc. .
  • each node can freely join or leave the network and perform related operations.
  • the private chain is on the contrary, the write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization.
  • a private chain can be a weakly centralized system with strict restrictions on nodes and a small number of nodes.
  • This type of blockchain is more suitable for internal use within a specific institution.
  • the consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization".
  • Each node in the alliance chain usually has a corresponding entity or organization; the node joins the network through authorization and forms a stakeholder alliance to jointly maintain the operation of the blockchain.
  • the blockchain is usually composed of several blocks. Timestamps corresponding to the creation time of the blocks are respectively recorded in these blocks, and all blocks form a time-ordered data chain strictly according to the timestamps recorded in the blocks.
  • the real data generated in the physical world it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain, and the node devices in the blockchain will perform consensus processing on the received transactions , and after reaching a consensus, the node device in the blockchain as the accounting node will package the transaction into the block and store the certificate persistently in the blockchain.
  • the consensus algorithms supported in the blockchain may include: the first type of consensus algorithm, a consensus algorithm in which node devices need to compete for the accounting rights of each round of accounting cycles, such as Proof of Work (POW), Consensus algorithms such as Proof of Stake (POS) and Delegated Proof of Stake (DPOS); the second type of consensus algorithm elects billing nodes for each round of billing cycle in advance (no need to compete for billing rights) Consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT) and other consensus algorithms.
  • PW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • the second type of consensus algorithm elects billing nodes for each round of billing cycle in advance (no need to compete for billing rights)
  • Consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT) and other consensus algorithms.
  • all node devices competing for the right to bookkeeping can execute the transaction after receiving the transaction.
  • One of the node devices competing for the accounting right may win in the process of competing for the accounting right in this round and become an accounting node.
  • the accounting node can package the received transaction with other transactions 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.
  • the node equipment with accounting rights has been negotiated before this round of accounting. Therefore, after the node device receives the transaction, if it is not the accounting node of the current round, it can send the transaction to the accounting node.
  • the transaction may be executed during or before the process of packaging the transaction with other transactions to generate the latest block.
  • the accounting node After the accounting node generates the latest block, it can send the latest block or the block header of the latest block to other node devices for consensus.
  • the accounting node of this round can package the received transaction to generate the latest block, and use the generated latest block or the latest block
  • the block header is sent to other node devices for consensus verification. If other node devices receive the latest block or the block header of the latest block and verify that there is no problem, the latest block can be appended to the end of the original blockchain, thereby completing the blockchain accounting process. In the process of verifying the new block or block header sent by the accounting node, other nodes can also execute the transactions contained in the block.
  • Smart contracts deployed on the blockchain can usually only refer to the data content stored on the blockchain; in practical applications, for some complex business scenarios based on smart contract technology, smart contracts may also need to refer to some off-chain external data on the data entity.
  • the smart contract deployed on the blockchain can use the Oracle oracle to refer to the data on the data entity outside the chain, thereby realizing the data interaction between the smart contract and the real-world data entity.
  • the data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.
  • cross-chain relay is used to connect the two blockchains
  • Oracle oracle is used to connect the blockchain and the data entities outside the chain to realize the data interaction between the blockchain and the real world.
  • an oracle smart contract corresponding to the oracle on the blockchain.
  • the oracle smart contract is used to maintain the oracle sent to External data of smart contracts on the blockchain; for example, external data sent by an oracle to a smart contract on the blockchain, can be stored in the account storage space of the oracle smart contract.
  • the external data required by the target smart contract can be read from the account storage space of the oracle smart contract to complete the calling process of the smart contract.
  • the oracle When the oracle sends external data to the smart contract on the blockchain, it can send it actively or passively.
  • the data entity outside the chain can send the external data that needs to be provided to the target smart contract to the above-mentioned oracle smart contract after signing with the private key of the oracle machine;
  • the signed external data is sent to the above-mentioned oracle smart contract;
  • the above-mentioned oracle smart contract can maintain the oracle's CA certificate.
  • After receiving the external data sent by the data entity outside the chain it can be used to maintain the CA certificate.
  • the public key of the oracle machine, the signature of the external data is verified, and after the verification is passed, the external data sent by the data entity outside the chain is stored in the account storage space of the oracle smart contract.
  • the oracle smart contract can use the event mechanism of the smart contract to interact with the above oracle, and the above oracle sends the external data required by the target smart contract to the account storage space of the oracle smart contract.
  • the target smart contract on the blockchain when the target smart contract on the blockchain is called, if the external data required by the target smart contract is not read from the account storage space of the oracle smart contract, the oracle smart contract , an external data acquisition event can be generated, and the external data acquisition event can be recorded in the transaction log of the transaction calling the smart contract, and the transaction log can be stored in the storage space of the node device; and the above-mentioned oracle machine can monitor The transaction log generated by the oracle smart contract stored in the storage space of the node device, and after monitoring the external data acquisition event in the transaction log, in response to the monitored external data acquisition event, the above target smart contract required. External data, sent to the above oracle smart contract.
  • converting non-monetary physical assets in the real world into virtual assets on the blockchain usually refers to "anchoring" the physical assets with virtual assets on the blockchain as these virtual assets.
  • the user can create a virtual asset on the blockchain that matches the value of the real-world non-monetary physical asset and circulate it on the blockchain; for example, the Users can convert non-monetary physical assets, such as real estate, stocks, loan contracts, bills and accounts receivable, into virtual assets with matching value and circulate on the blockchain.
  • non-monetary physical assets such as real estate, stocks, loan contracts, bills and accounts receivable
  • FIG. 2 is a flowchart of a blockchain-based asset management method shown in an exemplary embodiment of this specification.
  • the above-mentioned blockchain-based asset management method can be applied to node devices in the blockchain; the method may include the following steps: Step 202: Receive the asset creation docked by the asset management party The first contract invocation transaction sent by the party, the first contract invocation transaction includes the type identifier of the target asset type; Step 204, in response to the first contract invocation transaction, invoke the first acquisition logic in the first smart contract , acquiring the asset model defined in the blockchain by the asset management party and corresponding to the target asset type indicated by the type identifier, where the asset model includes asset creation information corresponding to the target asset type; And, in step 206, after acquiring the asset model corresponding to the target asset type, further call the creation logic in the first smart contract, based on the target asset type defined by the blockchain operator and the target asset type The corresponding asset format, and the acquired asset creation information in the asset model corresponding to the target asset type, create standardized blockchain assets in the blockchain.
  • the operator of the blockchain can define one or more asset types, and asset formats corresponding to each asset type respectively.
  • the asset management party can access the above-mentioned blockchain in advance, and can establish a communication connection with the node equipment in the blockchain; subsequently, asset-related smart contracts (called the first and second) can be deployed on the blockchain. a smart contract).
  • the asset creator connected with the asset management party can publish the contract invocation transaction for invoking the first smart contract (referred to as the first contract invocation transaction) to the blockchain.
  • the first contract invocation transaction may include a type identifier of a certain asset type (called a target asset type) defined by the operator of the blockchain.
  • the node device in the above-mentioned blockchain when the node device in the above-mentioned blockchain receives the above-mentioned first contract invocation transaction, in response to the first contract invocation transaction, the node device in the above-mentioned first smart contract can invoke the acquisition logic (referred to as the first contract invocation transaction).
  • acquisition logic to acquire the asset model defined by the asset manager in the blockchain and corresponding to the target asset type (ie, the asset type indicated by the type identifier in the first contract invocation transaction).
  • the asset model may include asset creation information corresponding to the target asset type.
  • the blockchain asset to be created corresponding to the target asset type can be used as an object.
  • the asset model is the class used to create the blockchain asset corresponding to the target asset type. That is, the asset model is an instance of the blockchain asset corresponding to the target asset type.
  • the creation logic in the first smart contract can be further invoked, based on the asset format defined by the operator of the blockchain and corresponding to the target asset type, and the obtained asset model corresponding to the target asset type.
  • Asset creation information creating a blockchain asset corresponding to the target asset type in the blockchain (that is, the aforementioned virtual asset that can be circulated on the blockchain).
  • a hash value may also be calculated for the created blockchain asset, and the calculated hash value may be used as an asset identifier of the blockchain asset.
  • the operator of the above-mentioned blockchain may include a blockchain service platform; the above-mentioned asset manager may include a financial institution accessing the blockchain service platform; the above-mentioned asset creator may include the financial institution.
  • the above-mentioned blockchain operator, the above-mentioned asset manager, and the above-mentioned asset creator may refer to the same entity, for example: all three may be a financial institution or an individual; or, they may also refer to the same entity. on behalf of a different entity; this specification does not limit this.
  • the above-mentioned blockchain may include the blockchain system 103 in the network environment; the node devices in the blockchain may include the blockchain nodes 1, 1 and 1 in the blockchain system 103 Block chain node 2, block chain node 3, block chain node 4, block chain node i, etc.; the block chain service platform as the operator of the above block chain may include the server 102 in the network environment , that is, the electronic device corresponding to the blockchain service platform can be the server 102 in the network environment; in order to ensure the data security of the above-mentioned blockchain and facilitate the management and maintenance of the blockchain, as the above-mentioned asset management
  • the financial institution of the other party usually does not directly establish a communication connection with the node device in the blockchain, but accesses the blockchain by establishing a communication connection with the blockchain service platform; in this case, the financial institution The institution may include Device 1, Device 2, Device 3 or Device 5 in the client-side computing device 101 in the network environment, that is, the electronic device corresponding to the financial institution
  • the electronic device corresponding to the financial institution is device 5
  • the electronic device corresponding to the user client can be device 1 or device 2
  • the user client may be a user client that establishes a communication connection with Device 1, Device 2, or Device 3.
  • FIG. 3 is a flowchart of another blockchain-based asset management method shown in an exemplary embodiment of this specification.
  • the above-mentioned blockchain-based asset management method can be applied to node devices in the blockchain; the method may include the following steps: Step 302: Receive the asset creation docked by the asset management party The first contract invocation transaction sent by the party, the first contract invocation transaction includes the type identifier of the target asset type; Step 304, in response to the first contract invocation transaction, invoke the first acquisition logic in the first smart contract , acquiring the asset model defined in the blockchain by the asset management party and corresponding to the target asset type indicated by the type identifier, where the asset model includes asset creation information corresponding to the target asset type; And, in step 306, after acquiring the asset model corresponding to the target asset type, further send an inter-contract call message to the second smart contract, where the inter-contract call message includes the acquired asset model and the target asset type The asset creation information in the corresponding asset model is used to invoke the creation logic in the second smart contract, based on the asset format and the asset creation information corresponding to the target asset type defined by the
  • the operator of the blockchain can define one or more asset types and asset formats corresponding to each asset type, and deploy a smart contract (called the second smart contracts).
  • the second smart contract may include the contract code related to the asset; specifically, the contract code of the second smart contract may include the contract code corresponding to the creation logic; in practical applications, by running the second smart contract
  • the contract code corresponding to the creation logic can realize the creation logic and create the blockchain asset corresponding to the target asset type in the blockchain; in addition, the second smart contract can maintain the above-mentioned blockchain operator defined The asset type and the asset format corresponding to that asset type.
  • the asset management party can access the above-mentioned blockchain in advance, that is, it can establish a communication connection with the node equipment in the blockchain; and then deploy the asset-related smart contract (called the first part of the blockchain) on the blockchain. a smart contract).
  • the asset creator connected with the asset management party can publish the contract invocation transaction for invoking the first smart contract (referred to as the first contract invocation transaction) to the blockchain.
  • the first contract invocation transaction may include a type identifier of a certain asset type (called a target asset type) defined by the operator of the blockchain.
  • the node device in the above-mentioned blockchain when the node device in the above-mentioned blockchain receives the above-mentioned first contract invocation transaction, in response to the first contract invocation transaction, the node device in the above-mentioned first smart contract can invoke the acquisition logic (referred to as the first contract invocation transaction).
  • acquisition logic to acquire the asset model defined by the asset manager in the blockchain and corresponding to the target asset type (ie, the asset type indicated by the type identifier in the first contract invocation transaction).
  • the asset model may include asset creation information corresponding to the target asset type.
  • the blockchain asset to be created corresponding to the target asset type can be used as an object.
  • the asset model is the class used to create the blockchain asset corresponding to the target asset type. That is, the asset model is an instance of the blockchain asset corresponding to the target asset type.
  • an inter-contract call message may be further sent to the above-mentioned second smart contract, and the inter-contract call message may include the obtained asset model corresponding to the above-mentioned target asset type by calling the first acquisition logic in the first smart contract.
  • asset creation information by sending the inter-contract call message to the second smart contract, the creation logic in the second smart contract can be invoked, based on the asset format defined by the blockchain operator and corresponding to the target asset type , and the acquired asset creation information in the asset model corresponding to the target asset type, and create a blockchain asset corresponding to the target asset type in the blockchain (that is, the aforementioned assets that can be circulated on the blockchain). virtual assets).
  • the created asset identifier of the blockchain asset can also be returned to the first smart contract; specifically, a hash value can be calculated for the created blockchain asset, and the calculated hash value can be used as The asset identifier of the blockchain asset is returned to the first smart contract.
  • the operator of the above-mentioned blockchain may include a blockchain service platform; the above-mentioned asset manager may include a financial institution accessing the blockchain service platform; the above-mentioned asset creator may include the financial institution.
  • the above-mentioned blockchain operator, the above-mentioned asset manager, and the above-mentioned asset creator may refer to the same entity, for example: all three may be a financial institution or an individual; or, they may also refer to the same entity. on behalf of a different entity; this specification does not limit this.
  • the above-mentioned blockchain may include the blockchain system 103 in the network environment; the node devices in the blockchain may include the blockchain nodes 1, 1 and 1 in the blockchain system 103 Block chain node 2, block chain node 3, block chain node 4, block chain node i, etc.; the block chain service platform as the operator of the above block chain may include the server 102 in the network environment , that is, the electronic device corresponding to the blockchain service platform can be the server 102 in the network environment; in order to ensure the data security of the above-mentioned blockchain and facilitate the management and maintenance of the blockchain, as the above-mentioned asset management
  • the financial institution of the other party usually does not directly establish a communication connection with the node device in the blockchain, but accesses the blockchain by establishing a communication connection with the blockchain service platform; in this case, the financial institution The institution may include Device 1, Device 2, Device 3 or Device 5 in the client-side computing device 101 in the network environment, that is, the electronic device corresponding to the financial institution
  • the electronic device corresponding to the financial institution is device 5
  • the electronic device corresponding to the user client can be device 1 or device 2
  • the user client may be a user client that establishes a communication connection with Device 1, Device 2, or Device 3.
  • the creation of the target asset type in the above blockchain in this embodiment corresponds to the target asset type.
  • the process of the blockchain asset is explained.
  • the blockchain operator can define one or more asset types, and asset formats corresponding to each asset type.
  • the operator of the aforementioned blockchain may deploy a smart contract (referred to as a third smart contract) on the blockchain.
  • a smart contract referred to as a third smart contract
  • the third smart contract may include the contract code corresponding to the deposit logic; in practical applications, by running the contract code corresponding to the deposit logic in the third smart contract, the deposit logic can be realized, and the data can be stored in the The certificate is stored in the blockchain.
  • the operator of the above-mentioned blockchain can pre-define one or more asset types and asset formats corresponding to each asset type, and package the asset type and the asset format corresponding to the asset type into a A contract invocation transaction (referred to as a third contract invocation transaction), the third contract invocation transaction is used to invoke the depository logic in the above-mentioned third smart contract. Subsequently, the operator of the blockchain can publish the third contract invocation transaction to the blockchain.
  • the node device in the above-mentioned blockchain When the node device in the above-mentioned blockchain receives the above-mentioned third contract invocation transaction, in response to the third contract invocation transaction, it can invoke the certificate storage logic in the above-mentioned third smart contract, and the third contract can invoke the transaction in the transaction.
  • the above asset type and the asset format corresponding to the asset type are stored in the blockchain; that is, the asset type defined by the operator of the above blockchain and the asset format corresponding to the asset type are realized. , which is stored in the blockchain.
  • the asset type defined by the operator of the blockchain and the asset format corresponding to the asset type can be stored in the account storage space of the third smart contract.
  • the asset type defined by the operator of the blockchain and the asset format corresponding to the asset type can be stored in the Storage field of the third smart contract.
  • Smart contracts usually use Merkle trees or data structures based on Merkle trees to store and maintain data.
  • the data in Merkle trees (called Merkle storage trees) are usually stored in the form of key-value pairs. That is, the asset type and the asset format corresponding to the asset type can be saved in the Merkle storage tree in the Storage field of the third smart contract in the form of a key-value key-value pair.
  • the operator of the above-mentioned blockchain may write one or more asset types and asset formats corresponding to each asset type into the native code of the blockchain, so as to realize the The asset type and the asset format corresponding to the asset type are stored in the blockchain.
  • Merkle state trees Usually stored in the form of key-value key-value pairs. That is, in one embodiment, the above-mentioned asset type and the asset format corresponding to the asset type can be saved in the Merkle state tree of the above-mentioned blockchain in the form of a key-value key-value pair; In the form of key-value key-value pairs, the asset model is saved to the Merkle state tree of the above blockchain.
  • the hash value of the asset model can be used as the key, and the asset model itself can be used as the value to save the Merkle tree (the Merkle tree or block in the Storage field of the smart contract) for storing the data of the blockchain. the Merkle state of the chain).
  • the operator of the above-mentioned blockchain may define one or more asset types in a centralized server corresponding to the operator, and asset formats corresponding to each asset type, and the central server
  • the blockchain server maintains one or more asset types defined by the operator of the blockchain, and the asset formats corresponding to each asset type; that is, the asset type and the asset format corresponding to the asset type are not saved in the in the blockchain.
  • the operator of the blockchain can define the asset type and the asset corresponding to the asset type based on a general programming language Format.
  • the general-purpose programming language may include a general-purpose declarative programming language; further, the general-purpose declarative programming language may include a domain-specific language (domain-specific language, DSL). That is, the general programming language may specifically include a domain-specific language; using the domain-specific language to perform definitions of asset types and asset formats can improve code development efficiency and reduce programming workload.
  • DSL domain-specific language
  • the operator of the above blockchain can define asset types such as "property", “stock” and “accounts receivable”; and, the asset format corresponding to the "property” asset type, and the Asset formats such as the corresponding asset format and the asset format corresponding to the "Accounts Receivable” asset type.
  • the asset format may include: several asset attribute fields; and a data structure used when assembling attribute values corresponding to the several asset attribute fields into a blockchain asset.
  • the asset attribute fields of the asset may include: on-chain identifier, off-chain identifier, asset type , amount, validity end date, financial institution, receivable and payable, etc.; in this case, the "Accounts Receivable” asset type can be defined using a declarative programming language as shown below, as well as the “Accounts Receivable” asset type
  • “StandardAR” is the type identifier of the "accounts receivable” asset type; the "idOnChain” field represents the on-chain identifier, the “idOffChain” field represents the off-chain identifier, the “assetType” field represents the asset type, and the “amount” field represents the amount , the "validDateUntil” field indicates the end date of the validity period, the "financeEnterprise” field indicates the financial institution, the “receivablesEnterpsie” field indicates the receivable party, and the “payableEnterpsie” field indicates the payable party; “idOnChain”, “idOffChain”, “assetType”, “financeEnterprise” , “receivablesEnterpsie” and “payableEnterpsie” are fields of type string, “amount” is a field of type long, and “validDateUntil” is a field of type date.
  • the asset management party can access the above-mentioned blockchain in advance, that is, it can establish a communication connection with the node device in the blockchain; and subsequently deploy a smart contract (called a smart contract) on the blockchain. for the fourth smart contract).
  • a smart contract a smart contract
  • the fourth smart contract may include contract code corresponding to the storage logic; in practical applications, by running the contract code corresponding to the storage logic in the fourth smart contract, the storage logic can be implemented, and the data can be stored in the The certificate is stored in the blockchain.
  • the above-mentioned asset management party may pre-define an asset model corresponding to a certain asset type (called a target asset type) defined by the operator of the above-mentioned blockchain, and package the asset model into a contract invocation transaction ( referred to as the fourth contract invocation transaction), the asset model may include asset creation information corresponding to the target asset type; the fourth contract invocation transaction is used to invoke the proof logic in the above-mentioned fourth smart contract. Subsequently, the operator of the blockchain can publish the fourth contract invocation transaction to the blockchain.
  • the node device in the above-mentioned blockchain When the node device in the above-mentioned blockchain receives the above-mentioned fourth contract invocation transaction, in response to the fourth contract invocation transaction, it can invoke the certificate storage logic in the above-mentioned fourth smart contract to invoke the fourth contract in the transaction.
  • the above asset model is stored in the blockchain; that is, the asset model defined by the asset management party and corresponding to the above target asset type is stored in the blockchain.
  • the asset model defined by the asset manager can be stored in the account storage space of the fourth smart contract.
  • the asset type defined by the operator of the blockchain and the asset format corresponding to the asset type can be stored in the Storage field of the fourth smart contract.
  • Smart contracts usually use Merkle trees or data structures based on Merkle trees to store and maintain data.
  • the data in Merkle storage trees are usually stored in the form of key-value pairs. That is, the asset type and the asset format corresponding to the asset type can be saved in the Merkle storage tree in the Storage field of the fourth smart contract in the form of a key-value key-value pair.
  • an asset model corresponding to the asset type can be defined by the above-mentioned asset management party.
  • one asset type can correspond to multiple asset models; these asset models can be defined by different asset managers.
  • the asset model may include asset creation information corresponding to the asset type; in this case, the asset creation information may be based on the asset type and the asset format corresponding to the asset type , and create a blockchain asset corresponding to the asset type in the above blockchain.
  • the above asset creation information may include: verification rules for attribute values corresponding to several asset attribute fields; state machines corresponding to the blockchain assets to be created; and the like.
  • the asset creator may submit attribute values corresponding to several asset attribute fields in the asset format corresponding to the asset type; First, according to the verification rules in the asset creation information above, verify the attribute values corresponding to these asset attribute fields submitted by the asset creator; The attribute values submitted by the asset creator are assembled, so that the assembled attribute values corresponding to these asset attribute fields can be used as the blockchain assets created in the blockchain; , update the state corresponding to the created blockchain asset, and store the blockchain asset in association with the state of the blockchain asset.
  • an asset model corresponding to the "Accounts Receivable” asset type can be defined using a declarative programming language:
  • “StandardAR” is the type identifier of the “Accounts Receivable” asset type
  • “stdAr” is the model identifier of the asset model
  • “STD-FUNCTIONALITY” indicates that when creating a blockchain asset based on the asset model, use the aforementioned and All asset attribute fields in the asset format corresponding to the "accounts receivable” asset type; that is, the created blockchain asset corresponding to the "accounts receivable” asset type contains attributes corresponding to all the above asset attribute fields value
  • the "VALIDATION” part indicates the validation rules for attribute values corresponding to all the above asset attribute fields
  • the "STATE-MACHINE” part indicates the state machine corresponding to the blockchain asset to be created.
  • the state machine corresponding to the blockchain asset to be created in the asset model corresponding to the "accounts receivable” asset type includes: “NULL” means stateless; After the block chain asset, the state of the block chain asset is set to the "READY” state; after the block chain asset is confirmed (CONFIRM), the state of the block chain asset is switched from the "READY” state to the "READY” state.
  • CONFIRMED state
  • the settlement (SETTLE) of the blockchain asset switch the state of the blockchain asset from the “CONFIRMED” state to the "PARTIAL_SETTLE” state, or keep the state of the blockchain asset in " PARTIAL_SETTLE” state
  • the blockchain asset is mortgaged (MORTGAGE)
  • the state of the blockchain asset is switched from the "CONFIRMED” state to the "BACKED” state, or the state of the blockchain asset is changed from "PARTIAL_SETTLED” " state is switched to "BACKED” state
  • the blockchain asset is cleared (CLEAR)
  • the state of the blockchain asset is switched from “BACKED” state to "CLEARED” state.
  • the above-mentioned blockchain may include the blockchain system 103 in the network environment; the node devices in the blockchain may include the blockchain nodes 1, 1 and 1 in the blockchain system 103 The blockchain node 2, the blockchain node 3, the blockchain node 4, the blockchain node i, etc.; the above-mentioned blockchain operator may include the server 102 in the network environment; the above-mentioned asset management party may include the Device 5 in client-side computing device 101 in a network environment.
  • the operator of the above-mentioned blockchain can define one or more asset types through the server 102, and asset formats corresponding to each asset type respectively, and the server 102 corresponds to the asset type and the asset type.
  • the asset format of the above-mentioned third contract invocation transaction is packaged into the above-mentioned third contract invocation transaction, and the third contract invocation transaction is published to the blockchain system 103, and the third contract invocation transaction is used to invoke the above-mentioned third smart contract.
  • the node device in the blockchain system 103 When the node device in the blockchain system 103 receives the third contract invocation transaction, it can respond to the third contract invocation transaction, invoke the proof logic in the third smart contract, and invoke the third contract in the transaction.
  • the above asset type and the asset format corresponding to the asset type are stored in the blockchain.
  • the server 102 can package the asset type defined by the operator of the blockchain and the asset format corresponding to the target asset type into a The above-mentioned third contract invocation transaction, and publishes the third contract invocation transaction to the blockchain system 103; in this case, the node device in the blockchain system 103 that has established a communication connection with the server 102 can receive it first to the third contract invocation transaction, and then send the third contract invocation transaction to other node devices in the blockchain system 103 . Each node device such as blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, and blockchain node i in the blockchain system 103 receives the third contract invocation transaction.
  • consensus processing can be performed on the third contract invocation transaction, and after reaching a consensus, the third contract invocation transaction is packaged into a block, and the certificate is persistently stored in the blockchain system 103 .
  • the node device in the blockchain system 103 can respond to the third contract invocation transaction and run the contract code corresponding to the deposit logic in the third smart contract to realize
  • the above-mentioned asset type and the asset format corresponding to the asset type in the third contract call transaction are stored in the blockchain.
  • the operator of the above-mentioned blockchain can write one or more asset types and asset formats corresponding to each asset type into the native code of the blockchain through the server 102 to realize The asset type and the asset format corresponding to the asset type are stored in the blockchain.
  • the server 102 can serve as a centralized server corresponding to the operator of the above-mentioned blockchain; that is, the operator of the blockchain can define one or more asset types through the server 102, and The asset format corresponding to each asset type, and the asset type and the asset format corresponding to the asset type are maintained by the server 102 .
  • the centralized server corresponding to the operator of the blockchain may also be a centralized server coupled to the server side 102;
  • One or more asset types and asset formats corresponding to each asset type are defined in the centralized server, and the asset type and the asset format corresponding to the asset type are maintained by the centralized server.
  • the above-mentioned asset management party can access the blockchain system 103 through the device 5 in the client-side computing device 101 in advance; subsequently, through the device 5, the asset model that will be used to define the asset model corresponding to the above-mentioned target asset type can be defined, and the The asset model is packaged into the above-mentioned fourth contract invocation transaction and published to the blockchain system 103 , and the fourth contract invocation transaction is used to invoke the proof logic in the above-mentioned fourth smart contract.
  • the node device in the blockchain system 103 When the node device in the blockchain system 103 receives the fourth contract invocation transaction, in response to the fourth contract invocation transaction, it can invoke the deposit logic in the fourth smart contract, and call the fourth contract in the transaction.
  • the above asset model is stored in the blockchain.
  • the device 5 in the client-side computing device 101 can send the certificate request initiated by the asset manager (the certificate request includes the The asset model corresponding to the above target asset type defined by the party) is sent to the server side 102, and the server side 102 packages the certificate deposit request into the above-mentioned fourth contract invocation transaction, and publishes the fourth contract invocation transaction to the blockchain.
  • System 103 in this case, the node device in the blockchain system 103 that has established a communication connection with the server 102 can first receive the fourth contract invocation transaction, and then send the fourth contract invocation transaction to the block Other node devices in the chain system 103 .
  • Each node device such as the blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, and blockchain node i in the blockchain system 103 receives the fourth contract invocation transaction.
  • consensus processing can be performed on the fourth contract invocation transaction, and after reaching a consensus, the fourth contract invocation transaction is packaged into a block, and the certificate is persistently stored in the blockchain system 103 .
  • the node device in the blockchain system 103 can respond to the fourth contract invocation transaction and run the contract code corresponding to the proof logic in the above-mentioned fourth smart contract to realize
  • the fourth contract is called to the above asset model in the transaction, and the certificate is stored in the blockchain.
  • the above-mentioned asset management party accessing the above-mentioned blockchain can deploy a smart contract (referred to as a first smart contract) on the above-mentioned blockchain.
  • a smart contract referred to as a first smart contract
  • the first smart contract may include contract code related to assets; specifically, the contract code of the first smart contract may include contract code corresponding to the acquisition logic (referred to as the first acquisition logic), and corresponding to the creation logic
  • the contract code of , etc. in practical applications, by running the contract code corresponding to the first acquisition logic in the first smart contract, the first acquisition logic can be implemented to acquire the asset management party defined in the blockchain.
  • the above-mentioned fourth smart contract and the above-mentioned first smart contract may be the same smart contract; that is, the contract code of the smart contract may include either the contract code corresponding to the deposit logic, or the contract code corresponding to the first smart contract.
  • the contract code corresponding to the logic and the contract code corresponding to the creation logic in this case, the asset model defined by the above-mentioned asset manager in the above-mentioned blockchain and corresponding to the above-mentioned target asset type can be stored in the account of the smart contract In the storage space, by running the contract code corresponding to the first acquisition logic in the smart contract, the asset model can be read from the account storage space of the smart contract.
  • the above-mentioned fourth smart contract and the above-mentioned first smart contract may be two different smart contracts; in this case, the asset model defined in the above-mentioned blockchain by the above-mentioned asset management party and corresponding to the above-mentioned target asset type may be It is stored in the account storage space of the fourth smart contract. By running the contract code corresponding to the first acquisition logic in the first smart contract, the asset model can be read from the account storage space of the fourth smart contract. .
  • the asset creator connected with the above-mentioned asset management party can publish the contract invocation transaction (referred to as the first contract invocation transaction) for invoking the above-mentioned first smart contract to the above-mentioned blockchain.
  • the first contract invocation transaction may include the above-mentioned type identifier of the target asset type.
  • the node device in the above-mentioned blockchain When the node device in the above-mentioned blockchain receives the above-mentioned first contract invocation transaction, in response to the first contract invocation transaction, it can invoke the first acquisition logic in the above-mentioned first smart contract to acquire the asset management party in this area.
  • the asset model defined in the blockchain and corresponding to the target asset type ie, the asset type indicated by the type identifier in the first contract invocation transaction
  • the asset model may include asset creation information corresponding to the target asset type.
  • the creation logic in the first smart contract can be further invoked, based on the The asset format corresponding to the target asset type, and the acquired asset creation information in the asset model corresponding to the target asset type, create a blockchain asset corresponding to the target asset type in the blockchain (that is, the aforementioned can virtual assets circulating on the blockchain).
  • a hash value may also be calculated for the created blockchain asset, and the calculated hash value may be used as an asset identifier of the blockchain asset.
  • the operator of the above-mentioned blockchain may write one or more asset types and asset formats corresponding to each asset type into the native code of the blockchain.
  • the node device in the above-mentioned blockchain can further call the creation logic in the above-mentioned first smart contract to obtain the above-mentioned target asset defined by the operator of the above-mentioned blockchain in the native code of the above-mentioned blockchain and the above-mentioned target asset
  • the asset format corresponding to the type subsequently, the asset creation can be based on the target asset type defined by the operator of the blockchain and the asset in the asset model corresponding to the target asset type defined by the asset manager in the blockchain information, create a blockchain asset corresponding to the target asset type in the blockchain; in addition, you can also calculate the hash value for the created blockchain asset, and use the calculated hash value as the blockchain asset asset identification.
  • the operator of the above-mentioned blockchain may maintain one or more asset types on a centralized server corresponding to the operator, and asset formats corresponding to each asset type respectively.
  • the node device in the above-mentioned blockchain can further call the creation logic in the above-mentioned first smart contract, and obtain the operator maintained by the centralized server corresponding to the operator of the above-mentioned blockchain through the Oracle oracle machine.
  • the defined asset format corresponding to the above target asset type subsequently, it can be based on the target asset type defined by the operator of the blockchain, and the asset management party defined in the blockchain corresponding to the target asset type.
  • Asset creation information in the asset model create a blockchain asset corresponding to the target asset type in the blockchain; in addition, you can also calculate the hash value for the created blockchain asset, and use the calculated hash value.
  • the asset identifier of the blockchain asset As the asset identifier of the blockchain asset.
  • the asset management party accessing the blockchain can deploy the first smart contract on the blockchain; and the operator of the blockchain can deploy the blockchain on the blockchain Smart contracts (called second smart contracts).
  • the second smart contract may include the contract code related to the asset; specifically, the contract code of the second smart contract may include the contract code corresponding to the creation logic; in practical applications, by running the second smart contract
  • the contract code corresponding to the creation logic can realize the creation logic and create the blockchain asset corresponding to the target asset type in the blockchain; in addition, the second smart contract can maintain the above-mentioned blockchain operator defined The above target asset type and the asset format corresponding to the target asset type.
  • the above-mentioned third smart contract and the above-mentioned second smart contract may be the same smart contract; that is, the contract code of the smart contract may include either the contract code corresponding to the deposit logic or the creation logic.
  • the corresponding contract code in this case, the above-mentioned target asset type defined by the operator of the above-mentioned blockchain, and the asset format corresponding to the target asset type, can be stored in the account storage space of the smart contract, by running
  • the contract code corresponding to the creation logic in the smart contract can read the asset model from the account storage space of the smart contract.
  • the above-mentioned third smart contract and the above-mentioned second smart contract may be two different smart contracts; in this case, the above-mentioned target asset type defined by the operator of the above-mentioned blockchain, and the corresponding target asset type
  • the asset format which can be stored in the account storage space of the third smart contract, can be read from the account storage space of the third smart contract by running the contract code corresponding to the creation logic in the second smart contract.
  • the target asset type, and the asset format corresponding to that target asset type can be read from the account storage space of the third smart contract by running the contract code corresponding to the creation logic in the second smart contract.
  • an inter-contract call message may be sent to the second smart contract, and the inter-contract call message It can include the asset creation information in the asset model corresponding to the target asset type obtained by calling the first acquisition logic in the first smart contract; by sending the inter-contract call message to the second smart contract, it can be called
  • the creation logic in the second smart contract is based on the asset format corresponding to the target asset type defined by the blockchain operator, and the acquired asset creation information in the asset model corresponding to the target asset type.
  • a blockchain asset corresponding to the target asset type (that is, the aforementioned virtual asset that can be circulated on the blockchain) is created in the blockchain.
  • the created asset identifier of the blockchain asset can also be returned to the first smart contract; specifically, a hash value can be calculated for the created blockchain asset, and the calculated hash value can be used as The asset identifier of the blockchain asset is returned to the first smart contract.
  • the asset creator docked with the device 5 as the asset manager may include device 1 or device 2 in the client-side computing device 101 in the network environment.
  • the above-mentioned asset manager can deploy the above-mentioned first smart contract related to the asset in the blockchain system 103 through the device 5 in advance; the above-mentioned asset creator can call the above-mentioned first contract through the device 1 that has established a communication connection with the device 5. Published to the blockchain system 103.
  • the first contract invocation transaction may include the type identifier of the above-mentioned target asset type.
  • the node device in the blockchain system 103 When the node device in the blockchain system 103 receives the above-mentioned first contract invocation transaction, in response to the first contract invocation transaction, it can invoke the first acquisition logic in the above-mentioned first smart contract to acquire the above-mentioned asset management party in the above-mentioned.
  • the asset model defined in the blockchain and corresponding to the above target asset type, the asset model may include asset creation information corresponding to the target asset type.
  • the operator of the above-mentioned blockchain can deploy the above-mentioned second smart contract related to assets in the blockchain system 103 through the server 102 in advance; the second smart contract can maintain the operator of the blockchain.
  • an inter-contract call message may be sent to the second smart contract, and the inter-contract call message may include the acquired asset management party.
  • the asset creation information in the asset model corresponding to the above-mentioned target asset type defined in the blockchain system 103 is used to invoke the creation logic in the second smart contract, based on the target asset type defined by the operator of the above-mentioned blockchain , and the asset creation information in the inter-contract call message, create a blockchain asset corresponding to the target asset type in the blockchain system 103; in addition, the hash value can also be calculated for the created blockchain asset, and The calculated hash value is used as the asset identifier of the blockchain asset and returned to the first smart contract.
  • the operator of the above-mentioned blockchain can write one or more asset types and asset formats corresponding to each asset type into the native code of the blockchain system 103 in advance through the server 102 .
  • the creation logic in the first smart contract can be further invoked to obtain the data of the blockchain operator in the blockchain system 103.
  • the asset format defined in the native code corresponding to the above target asset type, based on the target asset type defined by the operator of the blockchain, and the target asset type defined in the blockchain system 103 by the above asset manager For the asset creation information in the corresponding asset model, a blockchain asset corresponding to the target asset type is created in the blockchain system 103; in addition, the hash value can also be calculated for the created blockchain asset, and the calculated The hash value is used as the asset identifier of the blockchain asset.
  • the operator of the above-mentioned blockchain may store one or more asset types defined in advance and the asset formats corresponding to each asset type in the server 102 .
  • the creation logic in the first smart contract can be further invoked to obtain the data corresponding to the operator of the blockchain through the Oracle oracle.
  • the asset format corresponding to the target asset type defined by the operator and maintained by the centralized server is based on the target asset type defined by the operator of the blockchain, and the asset management party defined in the blockchain system 103.
  • the asset creation information in the asset model corresponding to the target asset type creates a blockchain asset corresponding to the target asset type in the blockchain system 103; in addition, a hash value can also be calculated for the created blockchain asset , and use the calculated hash value as the asset identifier of the blockchain asset.
  • the asset format corresponding to a certain asset type defined in the above-mentioned blockchain by the operator of the above-mentioned blockchain may include: several asset attribute fields of the asset type;
  • the asset creation information in the asset model corresponding to the asset type defined in the blockchain may include: verification rules for attribute values corresponding to the above-mentioned several asset attribute fields; the above-mentioned first contract initiated by the above-mentioned asset creator
  • the invoking transaction may include: attribute values submitted by the asset creator and corresponding to the above-mentioned several asset attribute fields.
  • the verification rule for the attribute values corresponding to the above-mentioned several asset attribute fields is to verify the attribute values corresponding to these asset attribute fields submitted by the above-mentioned asset creator; format, and assemble the attribute values submitted by the asset creator, so that the assembled attribute values corresponding to these asset attribute fields can be used as the blockchain assets created in the blockchain.
  • the asset model indicates the use of the asset format corresponding to the "Accounts Receivable” asset type. All the asset attribute fields of the blockchain asset are created; but in practical applications, the asset model can also instruct the use of some asset attribute fields to create blockchain assets; this specification does not limit this.
  • the asset creation information in the asset model corresponding to the asset type defined by the asset management party in the blockchain may include: a state corresponding to the blockchain asset to be created machine.
  • the created blockchain can be updated and created according to the state machine corresponding to the blockchain asset to be created in the above-mentioned asset model
  • the state corresponding to the asset is stored in association with the state of the blockchain asset.
  • the asset creation information in the asset model corresponding to the asset type defined by the asset management party in the above-mentioned blockchain may include: verification rules for attribute values corresponding to the above-mentioned several asset attribute fields; And, the state machine corresponding to the blockchain asset to be created.
  • the attribute values corresponding to these asset attribute fields submitted by the above-mentioned asset creator may be verified first according to the verification rules for the attribute values corresponding to the above-mentioned several asset attribute fields in the above-mentioned asset model; After the verification is passed, the attribute values submitted by the asset creator can be assembled according to the asset format corresponding to the asset type, so that the assembled attribute values corresponding to these asset attribute fields can be used as the block chain. Afterwards, the state corresponding to the blockchain asset to be created can be updated according to the state machine corresponding to the blockchain asset to be created in the asset model, and the blockchain asset Associated storage with the state of the blockchain asset.
  • an asset creation transaction that creates an asset corresponding to the "Accounts Receivable” asset type can be constructed using a declarative programming language as follows:
  • “StandardAR” is the type identifier of the “Accounts Receivable” asset type
  • “stdAr” is the model identifier of the asset model.
  • the node device in the above blockchain can respond to the asset creation transaction and execute the asset creation transaction in the local virtual machine to run the native code of the blockchain corresponding to the asset creation transaction.
  • the verification rules in the asset model corresponding to the "Accounts receivable” asset type verify the attribute values corresponding to the asset attribute fields in the asset creation transaction; Check whether the attribute value corresponding to the "amount” (that is, balance) field in the asset creation transaction is greater than 0; and, according to the "VALID_DATE_UNTIL:RULE_GREATER_THAN_30" verification rule, verify the asset creation transaction and That is, whether the interval between the attribute value corresponding to the validity period end date) field and the current date is greater than 30.
  • a transaction can be created based on the asset for several asset attribute fields in the asset format corresponding to the "Accounts Receivable” asset type used in the asset model corresponding to the "Accounts Receivable” asset type.
  • the attribute values corresponding to these asset attribute fields contained in the , and the asset format corresponding to the "Accounts Receivable” asset type create a blockchain asset corresponding to the "Accounts Receivable” asset type in this blockchain.
  • the asset attribute fields used in the asset model corresponding to the "Accounts Receivable” asset type include all asset attribute fields in the asset format corresponding to the "Accounts Receivable” asset type, namely on-chain identification, off-chain identification, asset Type, Amount, Validity End Date, Financial Institution, Receivable, and Payable; attribute values corresponding to these asset attribute fields include: "12345”, “12345”, “StandardAR”, 10000000, "2021.01.01", “ Enterprise A”, “Enterprise B", “Enterprise C”.
  • the blockchain asset created in the blockchain can be The state is set to the "READY" state.
  • the asset transfer party connected with the above-mentioned asset management party can publish the contract invocation transaction (referred to as the second contract invocation transaction) for invoking the above-mentioned first smart contract to the above-mentioned blockchain.
  • the contract invocation transaction referred to as the second contract invocation transaction
  • the second contract invocation transaction may include the asset identifier of the blockchain asset to be transferred.
  • the node device in the above-mentioned blockchain When the node device in the above-mentioned blockchain receives the above-mentioned second contract invocation transaction, in response to the second contract invocation transaction, it can invoke the acquisition logic (referred to as the second acquisition logic) in the above-mentioned first smart contract to acquire the second contract invocation transaction.
  • the blockchain asset can be transferred from the account of the payer to the account of the receivable.
  • the operator of the blockchain can define the target asset type and the asset format corresponding to the target asset type; the node device in the blockchain can receive a message sent by the asset creator connected to the asset management party.
  • the first contract calls the transaction
  • the first acquisition logic in the first smart contract is invoked to acquire the asset model defined by the asset manager in the blockchain corresponding to the target asset type, and further call the first acquisition logic.
  • the creation logic in the smart contract is based on the asset format corresponding to the target asset type defined by the operator of the blockchain, and the acquired asset creation information in the asset model corresponding to the target asset type.
  • Standardized blockchain assets are created in the chain; since the operator of the above-mentioned blockchain defines the asset type and the asset format corresponding to the asset type, all asset managers accessing the above-mentioned blockchain are in the blockchain.
  • the asset model corresponding to the asset type defined in all instructs the creation of blockchain assets according to the asset format corresponding to the asset type. Therefore, for the asset creator connected with any of the asset managers, these asset creation
  • the asset format of the blockchain asset corresponding to the asset type created by the party on the blockchain is the same, and the asset format corresponding to the asset type is defined by the operator of the blockchain.
  • Standardized blockchain assets are created in the blockchain, thereby facilitating the circulation of the created blockchain assets on the blockchain.
  • this specification also provides an embodiment of a blockchain-based asset management apparatus.
  • the embodiments of the blockchain-based asset management apparatus in this specification can be applied to electronic devices.
  • the apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware.
  • Taking software implementation as an example as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
  • this specification is a hardware structure diagram of the electronic equipment where the blockchain-based asset management device is located, except for the processor, memory, network interface, and non-volatile hardware shown in Figure 5
  • the electronic device in which the apparatus in the embodiment is located usually may also include other hardware according to the actual function of the blockchain-based asset management, which will not be repeated here.
  • FIG. 6 is a block diagram of a blockchain-based asset management apparatus according to an exemplary embodiment of this specification.
  • the blockchain-based asset management apparatus 60 can be applied to an electronic device as shown in FIG. 5 , and the electronic device can be used as a node device in a blockchain.
  • the operator of the blockchain defines an asset type and a The asset format corresponding to the asset type; the asset management party accessing the blockchain deploys the first smart contract related to the asset on the blockchain; the blockchain-based asset management device 60 may include: The first receiving module 601 receives the first contract invocation transaction sent by the asset creator connected to the asset management party, where the first contract invocation transaction includes the type identifier of the target asset type; the acquiring module 602, in response to the first contract invocation transaction The contract invokes the transaction, invokes the first acquisition logic in the first smart contract, and acquires the asset model defined by the asset management party in the blockchain and corresponding to the target asset type indicated by the type identifier, The asset model includes asset creation information corresponding to the target asset type; and the creation module 603 further calls the creation logic in the first smart contract after acquiring the asset model corresponding to the target asset type , based on the asset format corresponding to the target asset type defined by the operator of the blockchain, and the acquired asset creation information in the asset model corresponding to the target asset type, in the blockchain Create
  • the operator defines the target asset type and the asset format corresponding to the target asset type in the native code of the blockchain; the creation module 603: obtain the operator The asset format corresponding to the target asset type defined in the native code of the blockchain; the asset format corresponding to the target asset type defined by the operator of the blockchain, and the obtained The asset creation information in the asset model corresponding to the target asset type creates standardized blockchain assets in the blockchain.
  • the centralized server corresponding to the operator maintains the target asset type defined by the operator and the asset format corresponding to the target asset type;
  • the creation module 603: predicting through Oracle The machine acquires the asset format corresponding to the target asset type defined by the operator maintained by the centralized server; the asset format corresponding to the target asset type defined by the operator based on the blockchain, and obtains The obtained asset creation information in the asset model corresponding to the target asset type creates a standardized blockchain asset in the blockchain.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle state of the blockchain in the form of key-value pairs in the tree.
  • the asset format includes several asset attribute fields;
  • the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields;
  • the asset creation information includes Verification rules for attribute values corresponding to the several asset attribute fields;
  • the creation module 603 based on the verification rules in the asset model The attribute value is verified; if the verification is passed, then based on the asset format corresponding to the target asset type defined by the operator of the blockchain, and the attribute value, a standardization is created in the blockchain. blockchain assets.
  • the asset creation information includes a state machine corresponding to the blockchain asset; the creation module 603: after creating a standardized blockchain asset in the blockchain, based on the asset The state machine in the model updates the asset state corresponding to the blockchain asset.
  • the apparatus 60 further includes: a second receiving module 604, configured to receive a second contract invocation transaction sent by an asset transfer party connected to the asset management party, where the second contract invocation transaction includes the block The asset identifier of the blockchain asset; the transfer module 605, in response to the second contract calling transaction, invokes the second acquisition logic in the first smart contract to acquire the area stored in the blockchain and corresponding to the asset identifier blockchain assets, and after acquiring the blockchain assets corresponding to the asset identifiers, further call the transfer logic in the smart contract to transfer the acquired blockchain assets corresponding to the asset identifiers .
  • a second receiving module 604 configured to receive a second contract invocation transaction sent by an asset transfer party connected to the asset management party, where the second contract invocation transaction includes the block The asset identifier of the blockchain asset
  • the transfer module 605 in response to the second contract calling transaction, invokes the second acquisition logic in the first smart contract to acquire the area stored in the blockchain and corresponding to the asset identifier blockchain assets, and after acquiring the blockchain assets corresponding to the asset
  • the target asset type and the asset format corresponding to the target asset type defined by the blockchain operator include: the blockchain operator defined based on a general programming language A target asset type and an asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general An asset model corresponding to the target asset type defined in the blockchain by a programming language.
  • the general-purpose programming language may include a general-purpose declarative programming language.
  • the general-purpose declarative programming language may include a domain-specific language.
  • the operator may include a blockchain service platform; the asset management party may include a financial institution accessing the blockchain service platform; the asset creator may include a user client provided by the financial institution with asset services end.
  • FIG. 7 is a block diagram of another blockchain-based asset management apparatus shown in an exemplary embodiment of this specification.
  • the blockchain-based asset management device 70 can be applied to an electronic device as shown in FIG. 5 , the electronic device can be used as a node device in a blockchain, and the operator of the blockchain is on the blockchain A second smart contract related to assets is deployed; the second smart contract maintains the asset type defined by the operator and the asset format corresponding to the asset type; the asset management party accessing the blockchain is in the A first smart contract related to assets is deployed on the blockchain; the blockchain-based asset management device 70 may include: a first receiving module 701 for receiving the first information sent by the asset creator connected by the asset management party.
  • a contract invocation transaction the first contract invocation transaction includes the type identifier of the target asset type; the acquisition module 702, in response to the first contract invocation transaction, invokes the first acquisition logic in the first smart contract to acquire the an asset model defined in the blockchain by the asset manager and corresponding to the target asset type indicated by the type identifier, where the asset model includes asset creation information corresponding to the target asset type; and, creating Module 703: After acquiring the asset model corresponding to the target asset type, further send an inter-contract call message to the second smart contract, where the inter-contract call message includes the acquired data corresponding to the target asset type.
  • the asset creation information in the asset model is used to invoke the creation logic in the second smart contract, based on the asset format defined by the operator and corresponding to the target asset type, and the asset creation information, in the area A standardized blockchain asset is created in the blockchain, and the created asset identifier of the blockchain asset is returned to the first smart contract.
  • the asset model; or, the target asset type and the asset format corresponding to the target asset type are stored in the Merkle storage tree of the second smart contract in the form of key-value pairs.
  • the asset format includes several asset attribute fields;
  • the first contract invocation transaction further includes attribute values submitted by the asset creator and corresponding to the several asset attribute fields;
  • the asset creation information includes Verification rules for the attribute values corresponding to the several asset attribute fields;
  • the creation module 703 based on the verification rules in the asset model The attribute value is verified; if the verification is passed, then based on the asset format corresponding to the target asset type defined by the operator of the blockchain, and the attribute value, a standardization is created in the blockchain. blockchain assets.
  • the asset creation information includes a state machine corresponding to the blockchain asset; the creation module 703: after creating a standardized blockchain asset in the blockchain, based on the asset The state machine in the model updates the asset state corresponding to the blockchain asset.
  • the apparatus 70 further includes: a second receiving module 704, configured to receive a second contract invocation transaction sent by an asset transfer party connected to the asset management party, where the second contract invocation transaction includes the block The asset identifier of the blockchain asset; the transfer module 705, in response to the second contract calling transaction, invokes the second acquisition logic in the first smart contract to acquire the area stored in the blockchain and corresponding to the asset identifier blockchain assets, and after acquiring the blockchain assets corresponding to the asset identifiers, further call the transfer logic in the smart contract to transfer the acquired blockchain assets corresponding to the asset identifiers .
  • a second receiving module 704 configured to receive a second contract invocation transaction sent by an asset transfer party connected to the asset management party, where the second contract invocation transaction includes the block The asset identifier of the blockchain asset
  • the transfer module 705 in response to the second contract calling transaction, invokes the second acquisition logic in the first smart contract to acquire the area stored in the blockchain and corresponding to the asset identifier blockchain assets, and after acquiring the blockchain assets corresponding to the asset
  • the target asset type and the asset format corresponding to the target asset type defined by the blockchain operator include: the blockchain operator defined based on a general programming language A target asset type and an asset format corresponding to the target asset type; the asset model defined by the asset manager in the blockchain and corresponding to the target asset type includes: the asset manager is based on the general An asset model corresponding to the target asset type defined in the blockchain by a programming language.
  • the general-purpose programming language may include a general-purpose declarative programming language.
  • the general-purpose declarative programming language may include a domain-specific language.
  • the operator may include a blockchain service platform; the asset manager includes a financial institution accessing the blockchain service platform; and the asset creator includes a user client provided by the financial institution with asset services.
  • a typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • Memory may include forms of non-persistent memory, random access memory (RAM) and/or non-volatile memory in computer readable media, such as read only memory (ROM) or flash memory (flash RAM).
  • Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology.
  • Information may be computer readable instructions, data structures, modules of programs, 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 Disc (DVD) or other optical storage, Magnetic tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
  • computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.
  • the term “and/or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items. It will be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word “if” as used herein can be interpreted as "at the time of" or "when” or “in response to determining.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本说明书一个或多个实施例提供一种基于区块链的资产管理方法、装置及电子设备，应用于区块链中的节点设备；区块链的运营方定义了资产类型和与资产类型对应的资产格式；资产管理方在区块链上部署了第一智能合约；该方法包括：接收资产创建方发送的第一合约调用交易；响应于第一合约调用交易，调用第一智能合约中的第一获取逻辑，获取资产管理方在区块链中定义的与目标资产类型对应的资产模型；在获取到与目标资产类型对应的资产模型后，进一步调用第一智能合约中的创建逻辑，基于与目标资产类型对应的资产格式，以及与目标资产类型对应的资产模型中的与目标资产类型对应的资产创建信息，在区块链中创建标准化的区块链资产。

Description

基于区块链的资产管理 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的资产管理方法、装置及电子设备。
背景技术
在实际应用中，可以将现实世界中的一些非货币属性的实体资产，转化成为能够在区块链上流通的虚拟资产。但是，由不同的金融机构发布至区块链的虚拟资产的资产格式通常互不相同，导致这些虚拟资产难以在不同的金融机构之间流通。
发明内容
本说明书提出一种基于区块链的资产管理方法，所述方法应用于区块链中的节点设备，所述区块链的运营方定义了资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述方法包括：接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，所述运营方在所述区块链的原生代码中定义了所述目标资产类型和与所述目标资产类型对应的资产格式；所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：获取所述运营方在所述区块链的原生代码中定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，与所述运营方对应的中心化服务器维护了所述运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：通过Oracle预言机获取所述中心化服务器维护的所述运营方定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述区块链的Merkle状态树中。
可选地，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
可选地，所述资产创建信息包括与所述区块链资产对应的状态机；所述方法还包括：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
可选地，所述方法还包括：接收所述资产管理方对接的资产转移方发送的第二合约 调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
可选地，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
可选地，所述通用编程语言包括通用的声明式编程语言。
可选地，所述通用的声明式编程语言包括领域特定语言。
可选地，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
本说明书还提出一种基于区块链的资产管理方法，所述方法应用于区块链中的节点设备，所述区块链的运营方在所述区块链上部署了与资产相关的第二智能合约；所述第二智能合约维护了所述运营方定义的资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述方法包括：接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式，以及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
可选地，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述第二智能合约的Merkle存储树中。
可选地，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
可选地，所述资产创建信息包括与所述区块链资产对应的状态机；所述方法还包括：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
可选地，所述方法还包括：接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
可选地，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
可选地，所述通用编程语言包括通用的声明式编程语言。
可选地，所述通用的声明式编程语言包括领域特定语言。
可选地，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
本说明书还提出一种基于区块链的资产管理装置，所述装置应用于区块链中的节点设备，所述区块链的运营方定义了资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述装置包括：第一接收模块，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；获取模块，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，创建模块，在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，所述运营方在所述区块链的原生代码中定义了所述目标资产类型和与所述目标资产类型对应的资产格式；所述创建模块：获取所述运营方在所述区块链的原生代码中定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，与所述运营方对应的中心化服务器维护了所述运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述创建模块通过Oracle预言机获取所述中心化服务器维护的所述运营方定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
可选地，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述区块链的Merkle状态树中。
可选地，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述创建模块：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
可选地，所述资产创建信息包括与所述区块链资产对应的状态机；所述创建模块：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
可选地，所述装置还包括：第二接收模块，接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；转移模块，响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
可选地，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
可选地，所述通用编程语言包括通用的声明式编程语言。
可选地，所述通用的声明式编程语言包括领域特定语言。
可选地，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
本说明书还提出一种基于区块链的资产管理装置，所述装置应用于区块链中的节点 设备，所述区块链的运营方在所述区块链上部署了与资产相关的第二智能合约；所述第二智能合约维护了所述运营方定义的资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述装置包括：第一接收模块，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；获取模块，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，创建模块，在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式，以及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
可选地，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述第二智能合约的Merkle存储树中。
可选地，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述创建模块：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
可选地，所述资产创建信息包括与所述区块链资产对应的状态机；所述创建模块：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
可选地，所述装置还包括：第二接收模块，接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；转移模块，响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
可选地，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
可选地，所述通用编程语言包括通用的声明式编程语言。
可选地，所述通用的声明式编程语言包括领域特定语言。
可选地，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
本说明书还提出一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器，所述处理器通过运行所述可执行指令以实现上述方法的步骤。
本说明书还提出一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现上述方法的步骤。
在上述技术方案中，可以由区块链的运营方定义目标资产类型和与该目标资产类型对应的资产格式；区块链中的节点设备可以在接收到与资产管理方对接的资产创建方发送的第一合约调用交易时，调用第一智能合约中的第一获取逻辑，获取该资产管理方在该区块链中的定义的与该目标资产类型对应的资产模型，并进一步调用该第一智能合约中的创建逻辑，基于该区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建标准化的区块链资产；由于上述区块链的运营方定义了资产类型，以及与该资产类型对应的资产格式，而接入上述区块链的所有资产管理方在该区块链中定义的与该资产类型对应的资产模型，都指示了按照与该资产类型对应的资产格式创建区块链资产，因此对于 与其中任一资产管理方对接的资产创建方而言，这些资产创建方在该区块链上创建的与该资产类型对应的区块链资产的资产格式相同，都是由该区块链的运营方定义的与该资产类型对应的资产格式；由此实现了在该区块链中创建标准化的区块链资产，从而便于创建的区块链资产在该区块链上流通。
附图说明
图1是本说明书示出的一种与区块链相关的网络环境的示意图；
图2是本说明书一示例性实施例示出的一种基于区块链的资产管理方法的流程图；
图3是本说明书一示例性实施例示出的另一种基于区块链的资产管理方法的流程图；
图4是本说明书一示例性实施例示出的一种状态机的示意图；
图5是本说明书一示例性实施例示出的一种基于区块链的资产管理装置所在电子设备的硬件结构图；
图6是本说明书一示例性实施例示出的一种基于区块链的资产管理装置的框图；
图7是本说明书一示例性实施例示出的另一种基于区块链的资产管理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
请参考图1，图1是本说明书示出的一种与区块链相关的网络环境的示意图。
在如图1所示的网络环境中，可以包括客户端侧计算设备101、服务器端102，以及至少一个区块链系统；例如，区块链系统103、区块链系统104和区块链系统105。
在一种实施方式中，客户端侧计算设备101，可以包括各种不同类型的客户端侧计算设备；例如，客户端侧终端设备可以包括诸如PC终端设备、移动终端设备、物联网设备，以及其它形式的具有一定的计算能力的智能设备，等等。
需要说明的是，客户端侧计算设备101并不表示其中的所有客户端侧计算设备在同一个通信网络中，而仅仅是对这些客户端侧计算设备的统称。
在一种实施方式中，客户端侧终端设备101中的至少部分计算设备，可以通过各种通信网络耦接到服务器端102；例如，图1中示出的设备1和设备2与服务器端102进行了耦接。
不难理解，客户端侧终端设备101中的部分终端设备，也可以不与服务器端102进行耦接，而是作为区块链节点通过各种通信网络直接耦接到区块链系统；例如，图1中示出的设备4，可以作为区块链节点耦接到区块链系统。
上述通信网络可以包括有线和/或无线通信网络；例如，可以是基于运营商提供的有线接入网络或者无线接入网络(比如移动蜂窝网络)实现的局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、因特网或其组合。
在一种实施方式中，客户端侧计算设备101，还可以包括一个或多个用户侧服务器；例如，图1中示出的设备5。客户端侧终端设备101中的至少部分计算设备，可以耦接到该用户侧服务器，而该用户侧服务器可以进一步与上述服务端102进行耦接；例如，图1中示出的设备1和设备2耦接到设备5，设备5进一步耦接服务器端102。
在一种实施方式中，上述用户侧服务器可以由搭建了用户账户体系的服务实体来实现；上述服务实体可以包括面向用户提供各种线上和/或线下服务的服务载体的运营实体；上述服务载体可以包括软件形式的服务载体，也可以包括硬件形式的服务载体。
在一种实施方式中，上述服务载体可以包括提供线上互联网服务的各种客户端软 件；例如，网站、网页、APP等。
在一种实施方式中，上述服务载体也可以包括部署在线下的，能够提供线下服务的各种智能设备；例如，部署在居住区、办公区、公共场所的智能快递柜。
相应的，上述运营实体可以包括上述服务载体对应的运营方；例如，上述运营实体可以包括对上述服务载体进行运营和管理的个人、组织、公司和企业，等等。
在一种实施方式中，服务器端102也可以通过各种通信网络耦接到一个或者多个区块链系统；例如，图1中示出的服务器端102可以分别耦接到区块链系统103、区块链系统104和区块链系统105，等等。
在一种实施方式中，每个区块链系统都可以维护一个或多个区块链(例如，公有区块链、私有区块链、联盟区块链等)，并包括用于承载上述一个或多个区块链的多个区块链节点；例如，如图1中示出的区块链节点1、区块链节点2、区块链节点3、区块链节点4、区块链节点i等可以共同承载一个或者多个区块链。各个区块链系统包含的区块链之间，以及各个区块链系统之间，还可以进行跨链的数据访问。
在一种实施方式中，区块链节点可以包括全节点和轻节点。全节点可以全量下载区块链中的每个区块所包含的区块链交易，并可以根据搭载的区块链共识算法，对每个区块链中所包含的区块链交易进行共识验证。
而轻节点可以不下载完整的区块链，而是可以只下载区块链中的每个区块的区块头数据，并将区块头所包含的数据作为验证根，用于以验证区块链交易的真实性。轻节点可以依附于全节点来访问区块链的更多功能。
例如，图1中示出的区块链系统103中的各个区块链节点都可以作为全节点；而图1中示出的直接耦接到区块链系统的设备4，就可以作为轻节点，依附于区块链系统103中的各个全节点。
在一种实施方式中，区块链节点可以是物理设备，也可以是在服务器或者服务器集群中实现的虚拟设备；例如，区块链节点设备可以是服务器集群中的一台物理主机，也可以是基于虚拟化技术对服务器或者服务器集群搭载的硬件资源进行虚拟化后，创建的虚拟机。每个区块链节点之间，可以通过各种类型的通信方法(比如TCP/IP)耦接在一起形成网络，来承载一个或者多个区块链。
在一种实施方式中，服务器端102可以包括用于提供区块链服务(BaaS，Blockchain as a Service)的BaaS平台(也称之为BaaS云)。BaaS平台可以通过为区块链上发生的活动(诸如订阅和通知、用户验证、数据库管理和远程更新)，提供预先编写的软件的方式，面向与BaaS平台耦接的客户端侧计算设备，提供简单易用，一键部署，快速验证，灵活可定制的区块链服务，进而可以加速区块链业务应用开发、测试、上线，助力各行业区块链商业应用场景的落地。
例如，在一个例子中，与BaaS平台可以提供诸如MQ(Message Queue，消息队列)服务之类的软件；与BaaS平台耦接的客户端侧计算设备，可以订阅BaaS平台耦接的区块链系统中某一区块链上部署的智能合约，在触发执行后在区块链上产生的合约事件；而BaaS平台可以监听该智能合约在触发执行后在区块链上产生的事件，再基于MQ服务相关的软件，将该合约事件以通知消息的形式添加到消息队列中，使得订阅该消息队列的客户端侧计算设备，能够得到与上述合约事件相关的通知。
在一种实施方式中，BaaS平台还可以提供基于区块链技术的企业级平台服务，以帮助企业级客户构建安全且稳定的区块链环境，并轻松管理区块链的部署、操作、维护和开发。例如，BaaS平台可以基于云技术实现丰富的安全策略和多租户的隔离环境、基于芯片加密技术来提供高级的安全保护、基于高度可靠的数据存储，提供可以快速扩展，而不会中断的端到端的高可用性服务；在另一个例子中，还可以提供增强的管理功能，以帮助客户构建企业级区块链网络环境；以及，还可以为标准区块链应用和数据提供本地支持，支持例如Hyperledger Fabric和Enterprise Ethereum-Quorum的主流开源区块链技术，以构建开放且包容的技术生态系统。
区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且，各节点可自由加入或者退出 网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；节点通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。
对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备对收到的交易进行共识处理，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。
其中，区块链中支持的共识算法可包括：第一类共识算法，节点设备需要争夺每一轮的记账周期的记账权的共识算法，例如工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法；第二类共识算法，预先为每一轮记账周期选举记账节点(无需争夺记账权)的共识算法，例如实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等共识算法。
在采用第一类共识算法的区块链网络中，争夺记账权的节点设备，都可以在接收到交易后执行该笔交易。争夺记账权的节点设备中可能有一个节点设备在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可将收到的交易与其它交易一起打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
在采用第二类共识算法的区块链网络中，具有记账权的节点设备在本轮记账前已经商定好。因此，节点设备在接收到交易后，如果自身不是本轮的记账节点，则可以将该交易发送至记账节点。对于本轮的记账节点，在将该交易与其它交易一起打包以生成最新区块的过程中或者之前，可以执行该交易。记账节点在生成最新区块后，可以将该最新区块或者该最新区块的区块头发送至其它节点设备进行共识。
如上所述，无论区块链采用以上示出的哪种共识算法，本轮的记账节点都可以将接收到的交易打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到最新区块或者该最新区块的区块头后，经验证没有问题，可以将该最新区块追加到原有的区块链末尾，从而完成区块链的记账过程。其它节点验证记账节点发来的新的区块或区块头的过程中，也可以执行该区块中的包含的交易。
区块链上部署的智能合约，通常只能引用区块链上存储的数据内容；而在实际应用中，对基于智能合约技术实现的一些复杂的业务场景，智能合约可能还需要引用一些链外的数据实体上的外部数据。
在这种场景下，区块链上部署的智能合约，可以通过Oracle预言机，来引用链外的数据实体上的数据，进而实现智能合约与真实世界的数据实体之间的数据交互。其中，链外的数据实体，可以包括诸如部署在链外的中心化的服务器或者数据中心，等等。
需要说明的是，跨链中继用于连接两个区块链，而Oracle预言机用于连接区块链与链外的数据实体，实现区块链与真实世界的数据交互。
在实际应用中，在为区块链上的智能合约部署预言机时，可以先在区块链上部署一个与预言机对应的预言机智能合约，该预言机智能合约用于维护预言机发给区块链上的智能合约的外部数据；例如，预言机发给区块链上的智能合约的外部数据，可以存储在预言机智能合约的账户存储空间中。
当区块链上的目标智能合约被调用时，可以从该预言机智能合约的账户存储空间中，来读取该目标智能合约所需的外部数据，来完成智能合约的调用过程。
预言机在向区块链上的智能合约发送外部数据时，可以采用主动发送的方式，也可以采用被动发送的方式。
链外的数据实体可将需要提供给目标智能合约的外部数据，利用预言机的私钥进行签名后，发送给上述预言机智能合约；例如，在时间时，可以采用周期性发送的方式，将签名后的上述外部数据发送给上述预言机智能合约；而在上述预言机智能合约可以维 护预言机的CA证书，在收到链外的数据实体发送的外部数据后，可以使用该CA证书中维护的该预言机的公钥，对该外部数据的签名进行验证，并在验证通过后，将链外的数据实体发送的外部数据在该预言机智能合约的账户存储空间中进行存储。
在另一种实现方式中，当区块链上的目标智能合约被调用时，如果从该预言机智能合约的账户存储空间中，并未读取到该目标智能合约所需的外部数据，此时该预言机智能合约，可以利用智能合约的事件机制，与上述预言机进行交互，并由上述预言机将该目标智能合约所需的外部数据，发送至该预言机智能合约的账户存储空间中。
例如，当区块链上的目标智能合约被调用时，如果从该预言机智能合约的账户存储空间中，并未读取到该目标智能合约所需的外部数据，此时该预言机智能合约，可以生成一个外部数据获取事件，并将该外部数据获取事件记录到调用该智能合约的那笔交易的交易日志中，并将该交易日志存储到节点设备的存储空间；而上述预言机可以监听节点设备的存储空间中存储的该预言机智能合约产生的交易日志，并在监听到交易日志中的外部数据获取事件后，响应监听到的该外部数据获取事件，将上述目标智能合约所需的外部数据，发送给上述预言机智能合约。
在实际应用中，可以将现实世界中的一些非货币属性的实体资产，转化成为能够在区块链上流通的虚拟资产。
需要说明的是，将现实世界中的非货币属性的实体资产转化为区块链上的虚拟资产，通常是指将该实体资产与区块链上的虚拟资产进行“锚定”，作为这些虚拟资产的价值支撑，进而在区块链上产生与实体资产的价值匹配，且能够在区块链上的区块链账户之间进行流通的虚拟资产的过程。
对于接入上述区块链的用户而言，该用户可以在区块链上创建一笔与现实世界的非货币属性的实体资产价值匹配的虚拟资产，在区块链上进行流通；例如，该用户可以将持有的房产、股票、贷款合同、票据和应收账款等非货币属性的实体资产，转换为价值匹配的虚拟资产在区块链上流通。
请参考图2，图2是本说明书一示例性实施例示出的一种基于区块链的资产管理方法的流程图。
结合如图1所示的网络环境，上述基于区块链的资产管理方法可以应用于区块链中的节点设备；该方法可以包括以下步骤：步骤202，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；步骤204，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，步骤206，在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
在本实施例中，一方面，区块链的运营方可定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式。另一方面，资产管理方可预先接入上述区块链，即可与该区块链中的节点设备建立通信连接；后续可以在该区块链上部署与资产相关的智能合约(称为第一智能合约)。
在本实施例中，与上述资产管理方对接的资产创建方可以将用于调用上述第一智能合约的合约调用交易(称为第一合约调用交易)发布至上述区块链。
其中，该第一合约调用交易可以包括该区块链的运营商定义的某个资产类型(称为目标资产类型)的类型标识。
在本实施例中，上述区块链中的节点设备在接收到上述第一合约调用交易时，可以响应于该第一合约调用交易，调用上述第一智能合约中的获取逻辑(称为第一获取逻辑)，获取上述资产管理方在上述区块链中定义的与上述目标资产类型(即该第一合约调用交易中的类型标识指示的资产类型)对应的资产模型。
其中，该资产模型可以包括与该目标资产类型对应的资产创建信息。在面向对象的编程过程中，可以将待创建的与该目标资产类型对应的区块链资产作为对象，此时该资产模型为用于创建与该目标资产类型对应的区块链资产的类，即该资产模型为与该目标资产类型对应的区块链资产的实例。
后续，可以进一步调用该第一智能合约中的创建逻辑，基于上述区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产(即前述能够在该区块链上流通的虚拟资产)。
除此之外，在一种实施方式中，还可以针对创建的上述区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
需要说明的是，由于上述区块链的运营方定义了资产类型，以及与该资产类型对应的资产格式，而接入上述区块链的所有资产管理方在该区块链中定义的与该资产类型对应的资产模型，都指示了按照与该资产类型对应的资产格式创建区块链资产，因此对于与其中任一资产管理方对接的资产创建方而言，这些资产创建方在该区块链上创建的与该资产类型对应的区块链资产的资产格式相同，都是由该区块链的运营方定义的与该资产类型对应的资产格式；在这种情况下，可以将在上述区块链中创建的上述区块链资产作为标准化的区块链资产。
在一种实施方式中，上述区块链的运营方可以包括区块链服务平台；上述资产管理方可以包括接入该区块链服务平台的金融机构；上述资产创建方可以包括由该金融机构提供资产服务的用户客户端。
在实际应用中，上述区块链的运营方、上述资产管理方和上述资产创建方可以指代同一实体，例如：这三者都可以是某家金融机构或某个个体；或者，也可以指代不同的实体；本说明书对此不作限制。
结合如图1所示的网络环境，上述区块链可以包括该网络环境中的区块链系统103；该区块链中的节点设备可以包括区块链系统103中的区块链节点1、区块链节点2、区块链节点3、区块链节点4和区块链节点i等；作为上述区块链的运营方的区块链服务平台，可以包括该网络环境中的服务器端102，即与该区块链服务平台对应的电子设备可以是该网络环境中的服务器端102；为了保障上述区块链的数据安全，并便于对该区块链进行管理和维护，作为上述资产管理方的金融机构，通常不会直接与该区块链中的节点设备建立通信连接，而是通过与区块链服务平台建立通信连接，接入该区块链；在这种情况下，该金融机构可以包括该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或者设备5，即与该金融机构对应的电子设备可以是该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或设备5；作为上述资产创建方的由上述金融机构提供资产服务的用户客户端，可以包括与该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或设备5建立通信连接的用户客户端；例如，假设与该金融机构对应的电子设备为设备5，则与该用户客户端对应的电子设备可以是设备1或设备2；假设与该金融机构对应的电子设备为设备1、设备2或设备3，则该用户客户端可以是与设备1、设备2或设备3建立通信连接的用户客户端。
请参考图3，图3是本说明书一示例性实施例示出的另一种基于区块链的资产管理方法的流程图。
结合如图1所示的网络环境，上述基于区块链的资产管理方法可应用于区块链中的节点设备；该方法可包括以下步骤：步骤302，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；步骤304，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，步骤306，在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
在本实施例中，一方面，区块链的运营方可以定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，并在该区块链上部署智能合约(称为第二智能合约)。
其中，该第二智能合约可以包括与资产相关的合约代码；具体地，该第二智能合约的合约代码可以包括与创建逻辑对应的合约代码；在实际应用中，通过运行该第二智能合约中与创建逻辑对应的合约代码，可以实现创建逻辑，在该区块链中创建与该目标 资产类型对应的区块链资产；此外，该第二智能合约可以维护上述区块链的运营方定义的资产类型和与该资产类型对应的资产格式。另一方面，资产管理方可预先接入上述区块链，即可以与该区块链中的节点设备建立通信连接；后续可在该区块链上部署与资产相关的智能合约(称为第一智能合约)。
在本实施例中，与上述资产管理方对接的资产创建方可以将用于调用上述第一智能合约的合约调用交易(称为第一合约调用交易)发布至上述区块链。该第一合约调用交易可包括该区块链的运营商定义的某个资产类型(称为目标资产类型)的类型标识。
在本实施例中，上述区块链中的节点设备在接收到上述第一合约调用交易时，可以响应于该第一合约调用交易，调用上述第一智能合约中的获取逻辑(称为第一获取逻辑)，获取上述资产管理方在上述区块链中定义的与上述目标资产类型(即该第一合约调用交易中的类型标识指示的资产类型)对应的资产模型。
其中，该资产模型可以包括与该目标资产类型对应的资产创建信息。在面向对象的编程过程中，可以将待创建的与该目标资产类型对应的区块链资产作为对象，此时该资产模型为用于创建与该目标资产类型对应的区块链资产的类，即该资产模型为与该目标资产类型对应的区块链资产的实例。
后续，可以进一步向上述第二智能合约发送合约间调用消息，该合约间调用消息可以包括通过调用该第一智能合约中的第一获取逻辑，获取到的与上述目标资产类型对应的资产模型中的资产创建信息；通过向该第二智能合约发送该合约间调用消息，可以调用该第二智能合约中的创建逻辑，基于上述区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产(即前述能够在该区块链上流通的虚拟资产)。
除此之外，还可以将创建的该区块链资产的资产标识返回至该第一智能合约；具体地，可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识，返回至该第一智能合约。
需要说明的是，由于上述区块链的运营方定义了资产类型，以及与该资产类型对应的资产格式，而接入上述区块链的所有资产管理方在该区块链中定义的与该资产类型对应的资产模型，都指示了按照与该资产类型对应的资产格式创建区块链资产，因此对于与其中任一资产管理方对接的资产创建方而言，这些资产创建方在该区块链上创建的与该资产类型对应的区块链资产的资产格式相同，都是由该区块链的运营方定义的与该资产类型对应的资产格式；在这种情况下，可以将在上述区块链中创建的上述区块链资产作为标准化的区块链资产。
在一种实施方式中，上述区块链的运营方可以包括区块链服务平台；上述资产管理方可以包括接入该区块链服务平台的金融机构；上述资产创建方可以包括由该金融机构提供资产服务的用户客户端。
在实际应用中，上述区块链的运营方、上述资产管理方和上述资产创建方可以指代同一实体，例如：这三者都可以是某家金融机构或某个个体；或者，也可以指代不同的实体；本说明书对此不作限制。
结合如图1所示的网络环境，上述区块链可以包括该网络环境中的区块链系统103；该区块链中的节点设备可以包括区块链系统103中的区块链节点1、区块链节点2、区块链节点3、区块链节点4和区块链节点i等；作为上述区块链的运营方的区块链服务平台，可以包括该网络环境中的服务器端102，即与该区块链服务平台对应的电子设备可以是该网络环境中的服务器端102；为了保障上述区块链的数据安全，并便于对该区块链进行管理和维护，作为上述资产管理方的金融机构，通常不会直接与该区块链中的节点设备建立通信连接，而是通过与区块链服务平台建立通信连接，接入该区块链；在这种情况下，该金融机构可以包括该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或者设备5，即与该金融机构对应的电子设备可以是该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或设备5；作为上述资产创建方的由上述金融机构提供资产服务的用户客户端，可以包括与该网络环境中的客户端侧计算设备101中的设备1、设备2、设备3或设备5建立通信连接的用户客户端；例如，假设与该金融机构对应的电子设备为设备5，则与该用户客户端对应的电子设备可以是设备1或设备2；假设与该金融机构对应的电子设备为设备1、设备2或设备3，则该用户客户端 可以是与设备1、设备2或设备3建立通信连接的用户客户端。
下面结合如图1所示的与区块链相关的网络环境，针对上述目标资产类型，从资产定义和资产创建两个方面，对本实施例中在上述区块链中创建与该目标资产类型对应的区块链资产的流程进行解释说明。
(1)资产定义
在本实施例中，区块链的运营方可以定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式。
在一种实施方式中，上述区块链的运营方可以在该区块链上部署智能合约(称为第三智能合约)。
其中，该第三智能合约可以包括与存证逻辑对应的合约代码；在实际应用中，通过运行该第三智能合约中的与存证逻辑对应的合约代码，可以实现存证逻辑，将数据在该区块链中进行存证。
在这种情况下，上述区块链的运营方可以预先定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，并将该资产类型和与该资产类型对应的资产格式打包成合约调用交易(称为第三合约调用交易)，该第三合约调用交易用于调用上述第三智能合约中的存证逻辑。后续，该区块链的运营方可以将该第三合约调用交易发布至该区块链。
上述区块链中的节点设备在接收到上述第三合约调用交易时，可以响应于该第三合约调用交易，调用上述第三智能合约中的存证逻辑，将该第三合约调用交易中的上述资产类型和与该资产类型对应的资产格式，在该区块链中进行存证；也即，实现了将上述区块链的运营方定义的资产类型，以及与该资产类型对应的资产格式，在该区块链中进行存证。
在实际应用中，上述区块链的运营方定义的资产类型，以及与该资产类型对应的资产格式，可以存储在上述第三智能合约的账户存储空间中。具体地，上述区块链的运营方定义的资产类型，以及与该资产类型对应的资产格式，可以存储在该第三智能合约的Storage字段中。智能合约通常会使用Merkle树或者基于Merkle树的数据结构来存储和维护数据，Merkle树(称为Merkle存储树)中的数据通常以key-value键值对的形式进行存储。也即，可以以key-value键值对的形式，将上述资产类型和与该资产类型对应的资产格式保存至该第三智能合约的Storage字段中的Merkle存储树中。
在另一种实施方式中，上述区块链的运营方可以将一个或多个资产类型，以及分别与各个资产类型对应的资产格式，写入至该区块链的原生代码，以实现将该资产类型和与该资产类型对应的资产格式保存在该区块链中。
在实际应用中，对于大多数区块链系统而言，这些区块链系统通常都会使用Merkle树或者基于Merkle树的数据结构来存储和维护数据，Merkle树(称为Merkle状态树)中的数据通常以key-value键值对的形式进行存储。也即，在一种实施方式中，可以以key-value键值对的形式，将上述资产类型和与该资产类型对应的资产格式保存至上述区块链的Merkle状态树中；或者，可以以key-value键值对的形式，将资产模型保存至上述区块链的Merkle状态树中。
举例来说，可以将资产模型的hash值作为key，并将该资产模型本身作为value，保存至用于存储该区块链的数据的Merkle树(智能合约的Storage字段中的Merkle树或区块链的Merkle状态)中。
在再一种实施方式中，上述区块链的运营方可以在与该运营方对应的中心化服务器中定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，并由该中心化服务器维护该区块链的运营方定义的一个或多个资产类型，以及分别与各个资产类型对应的资产格式；也即，未将该资产类型和与该资产类型对应的资产格式保存在该区块链中。
为了便于对上述资产类型和与该资产类型对应的资产格式进行解析，在一种实施方式中，上述区块链的运营方可以基于通用编程语言定义该资产类型，以及与该资产类型对应的资产格式。
其中，上述通用编程语言可以包括通用的声明式编程语言；进一步地，该通用的声明式编程语言可以包括领域特定语言(domain-specific languages，DSL)。也即，该通用编程语言具体可以包括领域特定语言；使用领域特定语言执行资产类型和资产格式 等的定义，可以提高代码开发效率，减少编程工作量。
举例来说，上述区块链的运营商可以定义“房产”、“股票”和“应收账款”等资产类型；以及，与“房产”资产类型对应的资产格式、与“股票”资产类型对应的资产格式和与“应收账款”资产类型对应的资产格式等资产格式。
其中，资产格式可以包括：若干资产属性字段；以及，将与若干资产属性字段对应的属性值组装成区块链资产时所采用的数据结构。具体地，以“应收账款”资产类型为例，对于与“应收账款”资产类型对应的资产而言，该资产的资产属性字段可以包括：链上标识、链下标识、资产类型、金额、有效期结束日期、金融机构、应收方和应付方等；在这种情况下，如下所示，可以使用声明式编程语言定义“应收账款”资产类型，以及与“应收账款”资产类型对应的资产格式：
define StandardAsset StandardAR{
String idOnChain；
String idOffChain；
String assetType；
Long amount；
Date validDateUntil；
String financeEnterprise；
String receivablesEnterpsie；
String payableEnterpsie；
}
其中，“StandardAR”为“应收账款”资产类型的类型标识；“idOnChain”字段表示链上标识，“idOffChain”字段表示链下标识，“assetType”字段表示资产类型，“amount”字段表示金额，“validDateUntil”字段表示有效期结束日期，“financeEnterprise”字段表示金融机构，“receivablesEnterpsie”字段表示应收方，“payableEnterpsie”字段表示应付方；“idOnChain”、“idOffChain”、“assetType”、“financeEnterprise”、“receivablesEnterpsie”和“payableEnterpsie”为string类型的字段，“amount”为long类型的字段，“validDateUntil”为date类型的字段。
进一步地，在一种实施方式中，资产管理方可以预先接入上述区块链，即可以与该区块链中的节点设备建立通信连接；后续可以在该区块链上部署智能合约(称为第四智能合约)。
其中，该第四智能合约可以包括与存证逻辑对应的合约代码；在实际应用中，通过运行该第四智能合约中的与存证逻辑对应的合约代码，可以实现存证逻辑，将数据在该区块链中进行存证。
在这种情况下，上述资产管理方可以预先定义与上述区块链的运营商定义的某个资产类型(称为目标资产类型)对应的资产模型，并将该资产模型打包成合约调用交易(称为第四合约调用交易)，该资产模型可以包括与该目标资产类型对应的资产创建信息；该第四合约调用交易用于调用上述第四智能合约中的存证逻辑。后续，该区块链的运营方可以将该第四合约调用交易发布至该区块链。
上述区块链中的节点设备在接收到上述第四合约调用交易时，可以响应于该第四合约调用交易，调用上述第四智能合约中的存证逻辑，将该第四合约调用交易中的上述资产模型，在该区块链中进行存证；也即，实现了将上述资产管理方定义的与上述目标资产类型对应的资产模型，在该区块链中进行存证。
在实际应用中，上述资产管理方定义的资产模型，可以存储在上述第四智能合约的账户存储空间中。具体地，上述区块链的运营方定义的资产类型，以及与该资产类型对应的资产格式，可以存储在该第四智能合约的Storage字段中。智能合约通常会使用Merkle树或者基于Merkle树的数据结构来存储和维护数据，Merkle存储树中的数据通常以key-value键值对的形式进行存储。也即，可以以key-value键值对的形式，将上述资产类型和与该资产类型对应的资产格式保存至该第四智能合约的Storage字段中的Merkle存储树中。
在实际应用中，针对上述区块链的运营方定义的任意一个资产类型，都可以由上述资产管理方定义与该资产类型对应的资产模型。
需要说明的是，一个资产类型可以与多个资产模型相对应；这些资产模型可以由不同的资产管理方定义。
对于与某个资产类型对应的资产模型而言，该资产模型可以包括与该资产类型对应的资产创建信息；在这种情况下，可以基于该资产创建信息，以及与该资产类型对应的资产格式，在上述区块链中创建与该资产类型对应的区块链资产。
在实际应用中，上述资产创建信息可以包括：针对与若干资产属性字段对应的属性值的校验规则；与待创建的区块链资产对应的状态机；等等。
具体地，在上述区块链中创建与上述资产类型对应的区块链资产时，可以由资产创建方提交与该资产类型对应的资产格式中的若干资产属性字段对应的属性值；后续，可以先按照上述资产创建信息中的校验规则，对该资产创建方提交的与这些资产属性字段对应的属性值进行校验；在校验通过之后，可以按照与该资产类型对应的资产格式，对该资产创建方提交的属性值进行组装，从而可以将组装后的与这些资产属性字段对应的属性值作为在该区块链中创建的区块链资产；此外，还可以按照该资产创建信息中的状态机，更新与创建的该区块链资产对应的状态，并将该区块链资产与该区块链资产的状态进行关联存储。
继续以前述“应收账款”资产类型为例，如下所示，可以使用声明式编程语言定义与“应收账款”资产类型对应的资产模型：
define StandardAsset StandardAR stdAr{
STD-FUNCTIONALITY；//
VALIDATION(AMOUNT:RULE_GREATER_THAN_ZERO,
VALID_DATE_UNTIL:RULE_GREATER_THAN_30)；//
STATE-MACHINE:
CREATE(NULL,READY)
CONFIRM(READY,CONFIRMED)
SETTLE(CONFIRMED,PARTIAL_SETTLE)
MORTGAGE(CONFIRMED,BACKED)
MORTGAGE(PARTIAL_SETTLED,BACKED)
CLEAR(BACKED,CLEARED)//
}
其中，“StandardAR”为“应收账款”资产类型的类型标识，“stdAr”为该资产模型的模型标识；“STD-FUNCTIONALITY”指示在基于该资产模型创建区块链资产时，使用前述与“应收账款”资产类型对应的资产格式中的所有资产属性字段；也即，创建的与“应收账款”资产类型对应的区块链资产中包含与上述所有资产属性字段对应的属性值；“VALIDATION”部分指示针对与上述所有资产属性字段对应的属性值的校验规则；“STATE-MACHINE”部分指示与待创建的区块链资产对应的状态机。
如图4所示，与“应收账款”资产类型对应的资产模型中的与待创建的区块链资产对应的状态机包括：“NULL”表示无状态；在创建(CREATE)了该区块链资产之后，将该区块链资产的状态设置为“READY”状态；在对该区块链资产进行确认(CONFIRM)之后，将该区块链资产的状态由“READY”状态切换至“CONFIRMED”状态；在对该区块链资产进行结算(SETTLE)之后，将该区块链资产的状态由“CONFIRMED”状态切换至“PARTIAL_SETTLE”状态，或者将该区块链资产的状态保持在“PARTIAL_SETTLE”状态；在对该区块链资产进行抵押(MORTGAGE)之后，将该区块链资产的状态由“CONFIRMED”状态切换至“BACKED”状态，或者将该区块链资产的状态由“PARTIAL_SETTLED”状态切换至“BACKED”状态；在对该区块链资产进行结清(CLEAR)之后，将该区块链资产的状态由“BACKED”状态切换至“CLEARED”状态。
结合如图1所示的网络环境，上述区块链可以包括该网络环境中的区块链系统103；该区块链中的节点设备可以包括区块链系统103中的区块链节点1、区块链节点2、区块链节点3、区块链节点4和区块链节点i等；上述区块链的运营方可以包括该网络环境中的服务器端102；上述资产管理方可以包括该网络环境中的客户端侧计算设备101中的设备5。
在一个例子中，上述区块链的运营方可以通过服务器端102定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，由服务器端102将该资产类型和与该资产类型对应的资产格式打包成上述第三合约调用交易，并将该第三合约调用交易发布至区块链系统103，该第三合约调用交易用于调用上述第三智能合约中的存证逻辑。
区块链系统103中的节点设备在接收到上述第三合约调用交易时，可以响应于该 第三合约调用交易，调用上述第三智能合约中的存证逻辑，将该第三合约调用交易中的上述资产类型和与该资产类型对应的资产格式，在该区块链中进行存证。
在具体实现时，参考前述在区块链中持久化存证数据的过程，服务器端102可以将上述区块链的运营方定义的上述资产类型，以及与该目标资产类型对应的资产格式打包成上述第三合约调用交易，并将该第三合约调用交易发布至区块链系统103；在这种情况下，与服务器端102建立了通信连接的区块链系统103中的节点设备可以先接收到该第三合约调用交易，再将该第三合约调用交易发送给区块链系统103中的其它节点设备。区块链系统103中的区块链节点1、区块链节点2、区块链节点3、区块链节点4和区块链节点i等各台节点设备在接收到该第三合约调用交易时，可以对该第三合约调用交易进行共识处理，并在达成共识之后，将该第三合约调用交易打包进区块，在区块链系统103中进行持久化存证。
针对打包进区块的上述第三合约调用交易，区块链系统103中的节点设备可以响应于该第三合约调用交易，运行上述第三智能合约中的与存证逻辑对应的合约代码，实现将该第三合约调用交易中的上述资产类型和与该资产类型对应的资产格式，在该区块链中进行存证。
在另一个例子中，上述区块链的运营方可以通过服务器端102将一个或多个资产类型，以及分别与各个资产类型对应的资产格式，写入至该区块链的原生代码，以实现将该资产类型和与该资产类型对应的资产格式保存在该区块链中。
在再一个例子中，服务器端102可以作为与上述区块链的运营方对应的中心化服务器；也即，该区块链的运营方可以通过服务器端102定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，并由服务器端102维护该资产类型和与该资产类型对应的资产格式。
或者，与该区块链的运营方对应的中心化服务器也可是与服务器端102耦接的中心化服务器；在这种情况下，该区块链的运营方可以通过服务器端102，在该中心化服务器中定义一个或多个资产类型，以及分别与各个资产类型对应的资产格式，并由该中心化服务器维护该资产类型和与该资产类型对应的资产格式。
上述资产管理方可以预先通过客户端侧计算设备101中的设备5接入区块链系统103；后续可以通过设备5定义与上述将用于定义与上述目标资产类型对应的资产模型，并将该资产模型打包成上述第四合约调用交易，发布至区块链系统103，该第四合约调用交易用于调用上述第四智能合约中的存证逻辑。
区块链系统103中的节点设备在接收到上述第四合约调用交易时，可以响应于该第四合约调用交易，调用上述第四智能合约中的存证逻辑，将该第四合约调用交易中的上述资产模型，在该区块链中进行存证。
在具体实现时，参考前述在区块链中持久化存证数据的过程，客户端侧计算设备101中的设备5可以将上述资产管理方发起的存证请求(该存证请求包括该资产管理方定义的与上述目标资产类型对应的资产模型)发送至服务器端102，由服务器端102将该存证请求打包成上述第四合约调用交易，并将该第四合约调用交易发布至区块链系统103；在这种情况下，与服务器端102建立了通信连接的区块链系统103中的节点设备可以先接收到该第四合约调用交易，再将该第四合约调用交易发送给区块链系统103中的其它节点设备。区块链系统103中的区块链节点1、区块链节点2、区块链节点3、区块链节点4和区块链节点i等各台节点设备在接收到该第四合约调用交易时，可以对该第四合约调用交易进行共识处理，并在达成共识之后，将该第四合约调用交易打包进区块，在区块链系统103中进行持久化存证。
针对打包进区块的上述第四合约调用交易，区块链系统103中的节点设备可以响应于该第四合约调用交易，运行上述第四智能合约中的与存证逻辑对应的合约代码，实现将该第四合约调用交易中的上述资产模型，在该区块链中进行存证。
(2)资产创建
在本实施例中，另一方面，接入上述区块链的上述资产管理方可以在该区块链上部署智能合约(称为第一智能合约)。
其中，该第一智能合约可以包括与资产相关的合约代码；具体地，该第一智能合约的合约代码可以包括与获取逻辑(称为第一获取逻辑)对应的合约代码，以及与创建逻辑对应的合约代码，等等；在实际应用中，通过运行该第一智能合约中与第一获取逻 辑对应的合约代码，可以实现第一获取逻辑，获取该资产管理方在该区块链中定义的与上述目标资产类型对应的资产模型；通过运行该第一智能合约中与创建逻辑对应的合约代码，可以实现创建逻辑，在该区块链中创建与该目标资产类型对应的区块链资产。
需要说明的是，上述第四智能合约和上述第一智能合约可以是同一个智能合约；也即，该智能合约的合约代码既可以包括与存证逻辑对应的合约代码，也可以包括与第一获取逻辑对应的合约代码和与创建逻辑对应的合约代码；在这种情况下，上述资产管理方在上述区块链中定义的与上述目标资产类型对应的资产模型可以存储在该智能合约的账户存储空间中，通过运行该智能合约中的与第一获取逻辑对应的合约代码，可以实现从该智能合约的账户存储空间中读取该资产模型。
或者，上述第四智能合约与上述第一智能合约可以是不同的两个智能合约；在这种情况下，上述资产管理方在上述区块链中定义的与上述目标资产类型对应的资产模型可以存储在该第四智能合约的账户存储空间中，通过运行该第一智能合约中的与第一获取逻辑对应的合约代码，可以实现从该第四智能合约的账户存储空间中读取该资产模型。
与上述资产管理方对接的资产创建方可将用于调用上述第一智能合约的合约调用交易(称为第一合约调用交易)发布至上述区块链。该第一合约调用交易可包括上述目标资产类型的类型标识。
上述区块链中的节点设备在接收到上述第一合约调用交易时，可响应于该第一合约调用交易，调用上述第一智能合约中的第一获取逻辑，获取上述资产管理方在该区块链中定义的与上述目标资产类型(即该第一合约调用交易中的类型标识指示的资产类型)对应的资产模型，该资产模型可以包括与该目标资产类型对应的资产创建信息。
在获取到上述资产管理方在上述区块链中定义的与上述目标资产类型对应的资产模型之后，可以进一步调用该第一智能合约中的创建逻辑，基于上述区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产(即前述能够在该区块链上流通的虚拟资产)。
除此之外，在一种实施方式中，还可以针对创建的上述区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
需要说明的是，由于上述区块链的运营方定义了资产类型，以及与该资产类型对应的资产格式，而接入上述区块链的所有资产管理方在该区块链中定义的与该资产类型对应的资产模型，都指示了按照与该资产类型对应的资产格式创建区块链资产，因此对于与其中任一资产管理方对接的资产创建方而言，这些资产创建方在该区块链上创建的与该资产类型对应的区块链资产的资产格式相同，都是由该区块链的运营方定义的与该资产类型对应的资产格式；在这种情况下，可以将在上述区块链中创建的上述区块链资产作为标准化的区块链资产。
在一种实施方式中，上述区块链的运营方可以将一个或多个资产类型，以及分别与各个资产类型对应的资产格式，写入至该区块链的原生代码。
在这种情况下，上述区块链中的节点设备可以进一步调用上述第一智能合约中的创建逻辑，获取上述区块链的运营方在上述区块链的原生代码中定义的与上述目标资产类型对应的资产格式；后续，可以基于该区块链的运营方定义的该目标资产类型，以及上述资产管理方在该区块链中定义的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产；此外，还可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
在另一种实施方式中，上述区块链的运营方可以在与该运营方对应的中心化服务器维护的一个或多个资产类型，以及分别与各个资产类型对应的资产格式。
在这种情况下，上述区块链中的节点设备可以进一步调用上述第一智能合约中的创建逻辑，通过Oracle预言机获取与上述区块链的运营方对应的中心化服务器维护的该运营方定义的与上述目标资产类型对应的资产格式；后续，可以基于该区块链的运营方定义的该目标资产类型，以及上述资产管理方在该区块链中定义的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产；此外，还可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
或者，在本实施例中，接入上述区块链的上述资产管理方可以在该区块链上部署 上述第一智能合约；并且，该区块链的运营方可以在该区块链上部署智能合约(称为第二智能合约)。
其中，该第二智能合约可以包括与资产相关的合约代码；具体地，该第二智能合约的合约代码可以包括与创建逻辑对应的合约代码；在实际应用中，通过运行该第二智能合约中与创建逻辑对应的合约代码，可以实现创建逻辑，在该区块链中创建与该目标资产类型对应的区块链资产；此外，该第二智能合约可以维护上述区块链的运营方定义的上述目标资产类型和与该目标资产类型对应的资产格式。
需要说明的是，上述第三智能合约和上述第二智能合约可以是同一个智能合约；也即，该智能合约的合约代码既可以包括与存证逻辑对应的合约代码，也可以包括与创建逻辑对应的合约代码；在这种情况下，上述区块链的运营方定义的上述目标资产类型，以及与该目标资产类型对应的资产格式，可以存储在该智能合约的账户存储空间中，通过运行该智能合约中的与创建逻辑对应的合约代码，可以实现从该智能合约的账户存储空间中读取该资产模型。
或者，上述第三智能合约与上述第二智能合约可以是不同的两个智能合约；在这种情况下，上述区块链的运营方定义的上述目标资产类型，以及与该目标资产类型对应的资产格式，可以存储在该第三智能合约的账户存储空间中，通过运行该第二智能合约中的与创建逻辑对应的合约代码，可以实现从该第三智能合约的账户存储空间中读取该目标资产类型，以及与该目标资产类型对应的资产格式。
在这种情况下，在获取到上述资产管理方在上述区块链中定义的与上述目标资产类型对应的资产模型之后，可向上述第二智能合约发送合约间调用消息，该合约间调用消息可以包括通过调用该第一智能合约中的第一获取逻辑，获取到的与上述目标资产类型对应的资产模型中的资产创建信息；通过向该第二智能合约发送该合约间调用消息，可以调用该第二智能合约中的创建逻辑，基于上述区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建与该目标资产类型对应的区块链资产(即前述能够在该区块链上流通的虚拟资产)。
除此之外，还可以将创建的该区块链资产的资产标识返回至该第一智能合约；具体地，可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识，返回至该第一智能合约。
结合如图1所示的网络环境，与作为上述资产管理方的设备5对接的上述资产创建方可以包括该网络环境中的客户端侧计算设备101中的设备1或设备2。
上述资产管理方可以预先通过设备5在区块链系统103中部署与资产相关的上述第一智能合约；上述资产创建方可以通过与设备5建立了通信连接的设备1将上述第一合约调用交易发布至区块链系统103。
其中，该第一合约调用交易可以包括上述目标资产类型的类型标识。
区块链系统103中的节点设备在接收到上述第一合约调用交易时，可以响应于该第一合约调用交易，调用上述第一智能合约中的第一获取逻辑，获取上述资产管理方在上述区块链中定义的与上述目标资产类型对应的资产模型，该资产模型可以包括与该目标资产类型对应的资产创建信息。
在一个例子中，上述区块链的运营方可以预先通过服务器端102在区块链系统103中部署与资产相关的上述第二智能合约；该第二智能合约可以维护该区块链的运营方定义的上述目标资产类型和与该目标资产类型对应的资产格式。
在通过调用上述第一智能合约中的第一获取逻辑，获取到了上述资产模型之后，可进一步向上述第二智能合约发送合约间调用消息，该合约间调用消息可包括获取到的上述资产管理方在区块链系统103中定义的与上述目标资产类型对应的资产模型中的资产创建信息，以调用该第二智能合约中的创建逻辑，基于上述区块链的运营方定义的该目标资产类型，以及该合约间调用消息中的资产创建信息，在区块链系统103中创建与该目标资产类型对应的区块链资产；此外，还可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识，返回至该第一智能合约。
在另一个例子中，上述区块链的运营方可预先通过服务器端102将一个或多个资产类型，以及分别与各个资产类型对应的资产格式，写入至区块链系统103的原生代码。
在通过调用上述第一智能合约中的第一获取逻辑，获取到了上述资产模型之后， 可以进一步调用该第一智能合约中的创建逻辑，获取上述区块链的运营方在区块链系统103的原生代码中定义的与上述目标资产类型对应的资产格式，并基于该区块链的运营方定义的该目标资产类型，以及上述资产管理方在区块链系统103中定义的与该目标资产类型对应的资产模型中的资产创建信息，在区块链系统103中创建与该目标资产类型对应的区块链资产；此外，还可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
在再一个例子中，上述区块链的运营方可以预先将定义的一个或多个资产类型，以及分别与各个资产类型对应的资产格式保存在服务器端102中。
在通过调用上述第一智能合约中的第一获取逻辑，获取到了上述资产模型之后，可以进一步调用该第一智能合约中的创建逻辑，通过Oracle预言机获取与上述区块链的运营方对应的中心化服务器维护的该运营方定义的与上述目标资产类型对应的资产格式，并基于该区块链的运营方定义的该目标资产类型，以及上述资产管理方在区块链系统103中定义的与该目标资产类型对应的资产模型中的资产创建信息，在区块链系统103中创建与该目标资产类型对应的区块链资产；此外，还可以针对创建的该区块链资产计算hash值，并将计算得到的hash值作为该区块链资产的资产标识。
在一种实施方式中，上述区块链的运营方在上述区块链中定义的与某个资产类型对应的资产格式，可以包括：该资产类型的若干资产属性字段；上述资产管理方在该区块链中定义的与该资产类型对应的资产模型中的资产创建信息，可以包括：针对与上述若干资产属性字段对应的属性值的校验规则；由上述资产创建方发起的上述第一合约调用交易，可以包括：该资产创建方提交的与上述若干资产属性字段对应的属性值。
在这种情况下，在基于上述资产模型中的资产创建信息，以及与上述目标资产类型对应的资产格式，在上述区块链中创建区块链资产时，可以先按照该资产模型中的针对与上述若干资产属性字段对应的属性值的校验规则，对上述资产创建方提交的与这些资产属性字段对应的属性值进行校验；在校验通过之后，可以按照与该资产类型对应的资产格式，对该资产创建方提交的属性值进行组装，从而可以将组装后的与这些资产属性字段对应的属性值作为在该区块链中创建的区块链资产。
结合前述与“应收账款”资产类型对应的资产格式，以及与“应收账款”资产类型对应的资产模型，该资产模型指示使用与“应收账款”资产类型对应的资产格式中的所有资产属性字段创建区块链资产；但在实际应用中，资产模型也可以指示使用部分资产属性字段创建区块链资产；本说明书对此不作限制。
在示出的一种实施方式中，上述资产管理方在上述区块链中定义的与上述资产类型对应的资产模型中的资产创建信息，可以包括：与待创建的区块链资产对应的状态机。
在这种情况下，在上述区块链中创建了标准化的区块链资产之后，可以按照上述资产模型中的与待创建的区块链资产对应的状态机，更新与创建的该区块链资产对应的状态，并将该区块链资产与该区块链资产的状态进行关联存储。
在实际应用中，上述资产管理方在上述区块链中定义的与上述资产类型对应的资产模型中的资产创建信息，可以包括：针对与上述若干资产属性字段对应的属性值的校验规则；以及，与待创建的区块链资产对应的状态机。
在这种情况下，可以先按照上述资产模型中的针对与上述若干资产属性字段对应的属性值的校验规则，对上述资产创建方提交的与这些资产属性字段对应的属性值进行校验；在校验通过之后，可以按照与该资产类型对应的资产格式，对该资产创建方提交的属性值进行组装，从而可以将组装后的与这些资产属性字段对应的属性值作为在该区块链中创建的区块链资产；后续，可以按照该资产模型中的与待创建的区块链资产对应的状态机，更新与创建的该区块链资产对应的状态，并将该区块链资产与该区块链资产的状态进行关联存储。
继续以前述“应收账款”资产类型为例，如下所示，可以使用声明式编程语言构建用于创建与“应收账款”资产类型对应的资产的资产创建交易：
CALL CREATE StandardAR stdAr{
String idOnChain＝“12345”；
String idOffChain＝“12345”；
String assetType＝“StandardAR”；
Long amount＝10000000；
Date validDateUntil＝“2021.01.01”；
String financeEnterprise＝“企业A”；
String receivablesEnterpsie＝“企业B”；
String payableEnterpsie＝“企业C”；
}
其中，“StandardAR”为“应收账款”资产类型的类型标识，“stdAr”为该资产模型的模型标识。
上述区块链中的节点设备可以响应于该资产创建交易，在本地的虚拟机中执行该资产创建交易，以运行与该资产创建交易对应的该区块链的原生代码，实现先按照与“应收账款”资产类型对应的资产模型中的校验规则对该资产创建交易中的与资产属性字段对应的属性值进行校验；例如，可以按照“AMOUNT:RULE_GREATER_THAN_ZERO”的校验规则，校验该资产创建交易中的与“amount”(即余额)字段对应的属性值是否大于0；并且，按照“VALID_DATE_UNTIL:RULE_GREATER_THAN_30”的校验规则，校验该资产创建交易中的与“validDateUntil”(即有效期结束日期)字段对应的属性值与当前日期之间的间隔天数是否大于30。
如果校验通过，则可以针对与“应收账款”资产类型对应的资产模型中，使用的与“应收账款”资产类型对应的资产格式中的若干资产属性字段，基于该资产创建交易中包含的与这些资产属性字段对应的属性值，以及与“应收账款”资产类型对应的资产格式，在该区块链中创建与“应收账款”资产类型对应区块链资产。与“应收账款”资产类型对应的资产模型中使用的资产属性字段包括与“应收账款”资产类型对应的资产格式中的所有资产属性字段，即链上标识、链下标识、资产类型、金额、有效期结束日期、金融机构、应收方和应付方；与这些资产属性字段对应的属性值包括：“12345”、“12345”、“StandardAR”、10000000、“2021.01.01”、“企业A”、“企业B”、“企业C”。
除此之外，按照与“应收账款”资产类型对应的资产模型中的与待创建的区块链资产对应的状态机，可以将在该区块链中创建的该区块链资产的状态设置为“READY”状态。
在一种实施方式中，与上述资产管理方对接的资产转移方可以将用于调用上述第一智能合约的合约调用交易(称为第二合约调用交易)发布至上述区块链。
其中，该第二合约调用交易可以包括待转移的区块链资产的资产标识。
上述区块链中的节点设备在接收到上述第二合约调用交易时，可以响应于该第二合约调用交易，调用上述第一智能合约中的获取逻辑(称为第二获取逻辑)，获取该区块链中保存的与该资产转移交易中的资产标识对应的区块链资产，并在获取到该区块链资产之后，进一步调用该智能合约中的转移逻辑，对获取到的该区块链资产进行转移。
举例来说，针对在上述区块链中创建的与“应收账款”资产类型对应的区块链资产，可以将该区块链资产从应付方账户中转移至应收方账户。
在上述技术方案中，可以由区块链的运营方定义目标资产类型和与该目标资产类型对应的资产格式；区块链中的节点设备可以在接收到与资产管理方对接的资产创建方发送的第一合约调用交易时，调用第一智能合约中的第一获取逻辑，获取该资产管理方在该区块链中的定义的与该目标资产类型对应的资产模型，并进一步调用该第一智能合约中的创建逻辑，基于该区块链的运营方定义的与该目标资产类型对应的资产格式，以及获取到的与该目标资产类型对应的资产模型中的资产创建信息，在该区块链中创建标准化的区块链资产；由于上述区块链的运营方定义了资产类型，以及与该资产类型对应的资产格式，而接入上述区块链的所有资产管理方在该区块链中定义的与该资产类型对应的资产模型，都指示了按照与该资产类型对应的资产格式创建区块链资产，因此对于与其中任一资产管理方对接的资产创建方而言，这些资产创建方在该区块链上创建的与该资产类型对应的区块链资产的资产格式相同，都是由该区块链的运营方定义的与该资产类型对应的资产格式；由此实现了在该区块链中创建标准化的区块链资产，从而便于创建的区块链资产在该区块链上流通。
与前述基于区块链的资产管理方法的实施例相对应，本说明书还提供了基于区块链的资产管理装置的实施例。
本说明书基于区块链的资产管理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应 的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本说明书基于区块链的资产管理装置所在电子设备的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该基于区块链的资产管理的实际功能，还可以包括其他硬件，对此不再赘述。
请参考图6，图6是本说明书一示例性实施例示出的一种基于区块链的资产管理装置的框图。该基于区块链的资产管理装置60可以应用于如图5所示的电子设备，该电子设备可以作为区块链中的节点设备，所述区块链的运营方定义了资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；该基于区块链的资产管理装置60可包括：第一接收模块601，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；获取模块602，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，创建模块603，在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
在本实施例中，所述运营方在所述区块链的原生代码中定义了所述目标资产类型和与所述目标资产类型对应的资产格式；所述创建模块603：获取所述运营方在所述区块链的原生代码中定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
在本实施例中，与所述运营方对应的中心化服务器维护了所述运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述创建模块603：通过Oracle预言机获取所述中心化服务器维护的所述运营方定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
在本实施例中，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述区块链的Merkle状态树中。
在本实施例中，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述创建模块603：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
在本实施例中，所述资产创建信息包括与所述区块链资产对应的状态机；所述创建模块603：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
在本实施例中，所述装置60还包括：第二接收模块604，接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；转移模块605，响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
在本实施例中，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
所述通用编程语言可包括通用的声明式编程语言。
所述通用的声明式编程语言可包括领域特定语言。
所述运营方可包括区块链服务平台；所述资产管理方可包括接入所述区块链服务平台的金融机构；所述资产创建方可包括由所述金融机构提供资产服务的用户客户端。
请参考图7，图7是本说明书一示例性实施例示出的另一种基于区块链的资产管理装置的框图。该基于区块链的资产管理装置70可以应用于如图5所示的电子设备，该电子设备可以作为区块链中的节点设备，所述区块链的运营方在所述区块链上部署了与资产相关的第二智能合约；所述第二智能合约维护了所述运营方定义的资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；该基于区块链的资产管理装置70可以包括：第一接收模块701，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；获取模块702，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，创建模块703，在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式，以及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述第二智能合约的Merkle存储树中。
在本实施例中，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；所述创建模块703：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
在本实施例中，所述资产创建信息包括与所述区块链资产对应的状态机；所述创建模块703：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
在本实施例中，所述装置70还包括：第二接收模块704，接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；转移模块705，响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
在本实施例中，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
所述通用编程语言可包括通用的声明式编程语言。
所述通用的声明式编程语言可包括领域特定语言。
所述运营方可包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现， 或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (28)

  1. 一种基于区块链的资产管理方法，所述方法应用于区块链中的节点设备，所述区块链的运营方定义了资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述方法包括：
    接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；
    响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，
    在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  2. 根据权利要求1所述的方法，所述运营方在所述区块链的原生代码中定义了所述目标资产类型和与所述目标资产类型对应的资产格式；
    所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：获取所述运营方在所述区块链的原生代码中定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  3. 根据权利要求1所述的方法，与所述运营方对应的中心化服务器维护了所述运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式；
    所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：通过Oracle预言机获取所述中心化服务器维护的所述运营方定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  4. 根据权利要求1-3任一所述的方法，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式，保存在所述区块链的Merkle状态树中。
  5. 一种基于区块链的资产管理方法，所述方法应用于区块链中的节点设备，所述区块链的运营方在所述区块链上部署了与资产相关的第二智能合约；所述第二智能合约维护了所述运营方定义的资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述方法包括：
    接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；
    响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，
    在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式，以及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
  6. 根据权利要求5所述的方法，所述资产模型；或者，所述目标资产类型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式保存在所述第二智能合约的Merkle存储树中。
  7. 根据权利要求1或5所述的方法，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；
    所述基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产，包括：基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
  8. 根据权利要求1或5所述的方法，所述资产创建信息包括与所述区块链资产对应的状态机；所述方法还包括：在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
  9. 根据权利要求1或5所述的方法，所述方法还包括：
    接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；
    响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
  10. 根据权利要求1或5所述的方法，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
  11. 根据权利要求10所述的方法，所述通用编程语言包括通用的声明式编程语言。
  12. 根据权利要求11所述的方法，所述通用的声明式编程语言包括领域特定语言。
  13. 根据权利要求1或5所述的方法，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
  14. 一种基于区块链的资产管理装置，所述装置应用于区块链中的节点设备，所述区块链的运营方定义了资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述装置包括：
    第一接收模块，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；
    获取模块，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，创建模块，在获取到与所述目标资产类型对应的资产模型后，进一步调用所述第一智能合约中的创建逻辑，基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  15. 根据权利要求14所述的装置，所述运营方在所述区块链的原生代码中定义了所述目标资产类型和与所述目标资产类型对应的资产格式；
    所述创建模块获取所述运营方在所述区块链的原生代码中定义的与所述目标资产类型对应的资产格式；基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  16. 根据权利要求14所述的装置，与所述运营方对应的中心化服务器维护了所述运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式；
    所述创建模块通过Oracle预言机获取所述中心化服务器维护的所述运营方定义的与所述目标资产类型对应的资产格式；
    基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及获取到的与所述目标资产类型对应的资产模型中的资产创建信息，在所述区块链中创建标准化的区块链资产。
  17. 根据权利要求14-16任一所述的装置，所述资产模型；或者，所述目标资产类 型和与所述目标资产类型对应的资产格式，以key-Value键值对的形式保存在所述区块链的Merkle状态树中。
  18. 一种基于区块链的资产管理装置，所述装置应用于区块链中的节点设备，所述区块链的运营方在所述区块链上部署了与资产相关的第二智能合约；所述第二智能合约维护了所述运营方定义的资产类型和与所述资产类型对应的资产格式；接入所述区块链的资产管理方在所述区块链上部署了与资产相关的第一智能合约；所述装置包括：
    第一接收模块，接收所述资产管理方对接的资产创建方发送的第一合约调用交易，所述第一合约调用交易包括目标资产类型的类型标识；
    获取模块，响应于所述第一合约调用交易，调用所述第一智能合约中的第一获取逻辑，获取所述资产管理方在所述区块链中定义的与所述类型标识指示的所述目标资产类型对应的资产模型，所述资产模型包括与所述目标资产类型对应的资产创建信息；以及，
    创建模块，在获取到与所述目标资产类型对应的资产模型后，进一步向所述第二智能合约发送合约间调用消息，所述合约间调用消息包括获取到的与所述目标资产类型对应的资产模型中的资产创建信息，以调用所述第二智能合约中的创建逻辑，基于所述运营方定义的与所述目标资产类型对应的资产格式，以及所述资产创建信息，在所述区块链中创建标准化的区块链资产，并将创建的所述区块链资产的资产标识返回至所述第一智能合约。
  19. 根据权利要求18所述的装置，所述资产模型、或者所述目标资产类型和所述目标资产类型对应的资产格式，以key-Value键值对的形式保存在所述第二智能合约的Merkle存储树中。
  20. 根据权利要求14或18所述的装置，所述资产格式包括若干资产属性字段；所述第一合约调用交易还包括所述资产创建方提交的与所述若干资产属性字段对应的属性值；所述资产创建信息包括针对与所述若干资产属性字段对应的属性值的校验规则；
    所述创建模块基于所述资产模型中的校验规则对所述资产创建方提交的与所述若干资产属性字段对应的属性值进行校验；如果校验通过，则进一步基于所述区块链的运营方定义的与所述目标资产类型对应的资产格式，以及所述属性值，在所述区块链中创建标准化的区块链资产。
  21. 根据权利要求14或18所述的装置，所述资产创建信息包括与所述区块链资产对应的状态机；
    所述创建模块在所述区块链中创建标准化的区块链资产之后，基于所述资产模型中的状态机，更新与所述区块链资产对应的资产状态。
  22. 根据权利要求14或18所述的装置，所述装置还包括：
    第二接收模块，接收所述资产管理方对接的资产转移方发送的第二合约调用交易，所述第二合约调用交易包括所述区块链资产的资产标识；
    转移模块，响应于所述第二合约调用交易，调用所述第一智能合约中的第二获取逻辑，获取所述区块链保存的与所述资产标识对应的区块链资产，并在获取到与所述资产标识对应的区块链资产后，进一步调用所述智能合约中的转移逻辑，对获取到的与所述资产标识对应的区块链资产进行资产转移。
  23. 根据权利要求14或18所述的装置，所述区块链的运营方定义的所述目标资产类型和与所述目标资产类型对应的资产格式包括：所述区块链的运营方基于通用编程语言定义的所述目标资产类型和与所述目标资产类型对应的资产格式；所述资产管理方在所述区块链中定义的与所述目标资产类型对应的资产模型包括：所述资产管理方基于所述通用编程语言在所述区块链中定义的与所述目标资产类型对应的资产模型。
  24. 根据权利要求23所述的装置，所述通用编程语言包括通用的声明式编程语言。
  25. 根据权利要求24所述的装置，所述通用的声明式编程语言包括领域特定语言。
  26. 根据权利要求14或18所述的装置，所述运营方包括区块链服务平台；所述资产管理方包括接入所述区块链服务平台的金融机构；所述资产创建方包括由所述金融机构提供资产服务的用户客户端。
  27. 一种电子设备，包括处理器和用于存储处理器可执行指令的存储器，所述处理器通过运行所述可执行指令以实现如权利要求1至13中任一项所述的方法。
  28. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1至13中任一项所述的方法。
PCT/CN2022/076793 2021-03-31 2022-02-18 基于区块链的资产管理 WO2022206210A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110349871.4 2021-03-31
CN202110349871.4A CN113095825B (zh) 2021-03-31 2021-03-31 基于区块链的资产管理方法、装置及电子设备

Publications (1)

Publication Number Publication Date
WO2022206210A1 true WO2022206210A1 (zh) 2022-10-06

Family

ID=76672066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/076793 WO2022206210A1 (zh) 2021-03-31 2022-02-18 基于区块链的资产管理

Country Status (2)

Country Link
CN (1) CN113095825B (zh)
WO (1) WO2022206210A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116070249A (zh) * 2023-03-07 2023-05-05 北京亚康万玮信息技术股份有限公司 资产数据智能监控管理系统及方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113095825B (zh) * 2021-03-31 2024-04-05 支付宝(杭州)信息技术有限公司 基于区块链的资产管理方法、装置及电子设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105976231A (zh) * 2016-06-24 2016-09-28 深圳前海微众银行股份有限公司 基于区块链智能合约的资产管理方法及节点
CN106815764A (zh) * 2017-01-18 2017-06-09 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种基于联盟链的数字资产的管理方法及系统
CN110147987A (zh) * 2019-05-23 2019-08-20 北京亿生生网络科技有限公司 基于区块链的动态资产管理方法及装置
WO2019161023A1 (en) * 2018-02-14 2019-08-22 Alibaba Group Holding Limited Asset management method and apparatus, and electronic device
CN111383118A (zh) * 2020-05-29 2020-07-07 支付宝(杭州)信息技术有限公司 基于区块链的资产管理方法、装置和电子设备
CN112308553A (zh) * 2020-09-16 2021-02-02 电子科技大学 一种基于区块链的数字资产分类管理方法
WO2021042810A1 (zh) * 2019-09-05 2021-03-11 创新先进技术有限公司 基于区块链的资产清偿方法及装置、电子设备
CN113095825A (zh) * 2021-03-31 2021-07-09 支付宝(杭州)信息技术有限公司 基于区块链的资产管理方法、装置及电子设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111383114A (zh) * 2020-03-13 2020-07-07 普洛斯科技(重庆)有限公司 基于区块链的资产信息管理方法和装置
CN111738738A (zh) * 2020-07-31 2020-10-02 支付宝(杭州)信息技术有限公司 基于区块链的生物资产对象管理方法及装置
CN111681017B (zh) * 2020-08-14 2020-12-11 支付宝(杭州)信息技术有限公司 基于区块链的货物批量验真方法及装置、电子设备

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105976231A (zh) * 2016-06-24 2016-09-28 深圳前海微众银行股份有限公司 基于区块链智能合约的资产管理方法及节点
CN106815764A (zh) * 2017-01-18 2017-06-09 中钞信用卡产业发展有限公司北京智能卡技术研究院 一种基于联盟链的数字资产的管理方法及系统
WO2019161023A1 (en) * 2018-02-14 2019-08-22 Alibaba Group Holding Limited Asset management method and apparatus, and electronic device
CN110147987A (zh) * 2019-05-23 2019-08-20 北京亿生生网络科技有限公司 基于区块链的动态资产管理方法及装置
WO2021042810A1 (zh) * 2019-09-05 2021-03-11 创新先进技术有限公司 基于区块链的资产清偿方法及装置、电子设备
CN111383118A (zh) * 2020-05-29 2020-07-07 支付宝(杭州)信息技术有限公司 基于区块链的资产管理方法、装置和电子设备
CN112308553A (zh) * 2020-09-16 2021-02-02 电子科技大学 一种基于区块链的数字资产分类管理方法
CN113095825A (zh) * 2021-03-31 2021-07-09 支付宝(杭州)信息技术有限公司 基于区块链的资产管理方法、装置及电子设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116070249A (zh) * 2023-03-07 2023-05-05 北京亚康万玮信息技术股份有限公司 资产数据智能监控管理系统及方法

Also Published As

Publication number Publication date
CN113095825A (zh) 2021-07-09
CN113095825B (zh) 2024-04-05

Similar Documents

Publication Publication Date Title
US11921682B2 (en) Extracting data from a blockchain network
US20220058186A1 (en) Dag based methods and systems of transaction processing in a distributed ledger
US11544254B2 (en) System and method for managing a blockchain cloud service
US11728992B2 (en) Cryptlet binding key graph
CN110458631B (zh) 基于区块链的票据号码分配方法、装置及电子设备
US20200089872A1 (en) Enclave pool shared key
WO2019010067A1 (en) PROOF OF BLOCK CHAIN POSSESSION, RESISTANCE TO FALSIFICATION, PROOF OF CHAIN POSSESSION
CN111213340A (zh) 选择用于密码功能的证明委托并使其安全
US11397919B1 (en) Electronic agreement data management architecture with blockchain distributed ledger
JP2023532959A (ja) 許可制ブロックチェーンのためのプライバシー保護アーキテクチャ
CN111327613B (zh) 分布式服务的权限控制方法、装置及计算机可读存储介质
WO2022206210A1 (zh) 基于区块链的资产管理
WO2022206209A1 (zh) 基于区块链的资产管理
Garcia Bringas et al. BlockChain platforms in financial services: current perspective
Yewale Study of blockchain-as-a-service systems with a case study of hyperledger fabric implementation on Kubernetes
CN110458541B (zh) 基于区块链的对象置换方法及装置
CN116451280A (zh) 基于区块链的资产管理方法和装置
CN112837043B (zh) 基于区块链的数据处理方法、装置及电子设备
CN113256414B (zh) 基于区块链的资产管理方法、装置及电子设备
CN113762939A (zh) 基于区块链的资产管理方法、装置及电子设备
US20240380604A1 (en) Blockchain operation authorization and verification
Fikri et al. A blockchain-based decentralized microservices: Minimal architecture for accounting
CN116383890A (zh) 基于区块链的资产管理方法和装置
CN115640321A (zh) 数据查询方法和装置
CN115525641A (zh) 一种数据处理方法、装置、计算机设备及存储介质

Legal Events

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

Ref document number: 22778395

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22778395

Country of ref document: EP

Kind code of ref document: A1