Disclosure of Invention
The present specification proposes an asset compensation method based on a block chain, the method being applied to a node device in the block chain, the method including:
receiving advance settlement trades which are periodically sent by a client in the storage period of the securitized assets and aim at the securitized assets; wherein the securitized asset is an asset issued on the blockchain that supports as value a pool of base assets created based on base assets that are credited in the blockchain;
in response to the early-clearing transaction, invoking early-clearing validation logic in intelligent contracts deployed on the blockchain to determine whether an asset default rate of base assets in the base asset pool reaches a preset threshold;
and if the asset default rate reaches the threshold value, further calling advanced liquidation logic in the intelligent contract, carrying out advanced liquidation processing on the securitized assets, and setting the securitized assets to be in an invalid state after liquidation is finished.
Optionally, the pre-liquidation of the securitized assets comprises:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
Optionally, the transferring of funds to investors of the securitized assets based on the liquidation results comprises:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
Optionally, the investment account is an escrow account opened at an escrow bank.
Optionally, the setting the securitized asset to an invalid state after the liquidation is over includes:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
Optionally, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
The present specification also provides an asset liquidation method based on a blockchain, which is applied to a node device in the blockchain, and the method includes:
receiving advanced liquidation transactions aiming at securitized assets triggered by a client when the asset default rate of the basic assets in the basic asset pool reaches a preset threshold value; wherein the base asset pool is an asset pool created based on base assets stored in the blockchain; the securitized assets are assets issued supporting the base pool of assets as value on the blockchain;
in response to the early-liquidation transaction, early-liquidation logic deployed in a smart contract on the blockchain is invoked to early-liquidate the securitized asset, and after liquidation is complete, the securitized asset is set to an invalid state.
Optionally, the pre-liquidation of the securitized assets comprises:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
Optionally, the transferring of funds to investors of the securitized assets based on the liquidation results comprises:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
Optionally, the investment account is an escrow account opened at an escrow bank.
Optionally, the setting the securitized asset to an invalid state after the liquidation is over includes:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
Optionally, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
The present specification also provides an asset liquidation apparatus based on a block chain, where the apparatus is applied to a node device in the block chain, and the apparatus includes:
the receiving module is used for receiving advance settlement trades which are periodically sent by the client in the storage period of the securitized assets and aim at the securitized assets; wherein the securitized asset is an asset issued on the blockchain that supports as value a pool of base assets created based on base assets that are credited in the blockchain;
the confirmation module is used for responding to the early-clearing transaction, calling early-clearing confirmation logic in the intelligent contract deployed on the blockchain and determining whether the asset default rate of the basic assets in the basic asset pool reaches a preset threshold value;
and the liquidation module is used for further calling advanced liquidation logic in the intelligent contract to carry out advanced liquidation processing on the securitized assets if the asset default rate reaches the threshold value, and setting the securitized assets to be in an invalid state after the liquidation is finished.
Optionally, the liquidation module:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
Optionally, the liquidation module:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
Optionally, the investment account is an escrow account opened at an escrow bank.
Optionally, the liquidation module:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
Optionally, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
The present specification also provides an asset liquidation apparatus based on a block chain, where the apparatus is applied to a node device in the block chain, and the apparatus includes:
the receiving module is used for receiving the advance settlement transaction aiming at the securitized assets, which is triggered when the assets default rate of the basic assets in the basic asset pool reaches the preset threshold value by the client; wherein the base asset pool is an asset pool created based on base assets stored in the blockchain; the securitized assets are assets issued supporting the base pool of assets as value on the blockchain;
and the liquidation module is used for responding to the advance liquidation transaction, calling advance liquidation logic in the intelligent contract deployed on the blockchain, carrying out advance liquidation processing on the securitized assets, and setting the securitized assets to be in an invalid state after the liquidation is finished.
Optionally, the liquidation module:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
Optionally, the liquidation module:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
Optionally, the investment account is an escrow account opened at an escrow bank.
Optionally, the liquidation module:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
Optionally, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
This specification also proposes an electronic device including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the steps of the above method by executing the executable instructions.
The present specification also proposes a computer-readable storage medium having stored thereon computer instructions, characterized in that the instructions, when executed by a processor, implement the steps of the above-mentioned method.
In the technical scheme, a pre-liquidation transaction for a securitized asset issued on a blockchain by a manager can be periodically sent by a client, an intelligent contract deployed on the blockchain is called by a node device in the blockchain in response to the pre-liquidation transaction, when the asset default rate of a basic asset in an asset pool supported by the value of the securitized asset is determined to reach a preset threshold value, the securitization asset is subjected to pre-liquidation processing, and after liquidation is finished, the securitized asset is set to be in an invalid state; alternatively, a pre-liquidation transaction for a securitized asset may be triggered by a client upon determining that an asset default rate of a base asset in an asset pool supported by a value of the securitized asset issued on a blockchain as a manager reaches a preset threshold, invoking, by a node device in the blockchain, an intelligent contract deployed on the blockchain to pre-liquidate the securitization in response to the pre-liquidation transaction, and setting the securitized asset to an invalid state after liquidation is finished. By adopting the mode, the securitized assets issued by the management party on the block chain can be cleared up in advance, so that the management party can stop damage in time when the basic assets in the asset pool are in default.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.
Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.
Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.
A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.
Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.
The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.
The consensus algorithm supported in the blockchain may include:
the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;
the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.
In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a latest block and send the generated latest block or a block header of the latest block to other node devices for consensus.
In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate the latest block. After generating the latest block, the accounting node may send the latest block or a block header of the latest block to other node devices for consensus.
As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may pack the received transaction to generate the latest block, and send the generated latest block or the block header of the latest block to other node devices for consensus verification. If no problem is verified after other node equipment receives the latest block or the block header of the latest block, the latest block can be added to the tail of the original block chain, so that the accounting process of the block chain is completed. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.
In the field of blockchain, an important concept is Account (Account); taking an ether house as an example, the ether house generally divides an account into an external account and a contract account; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract). Of course, for some blockchain items derived from the ethernet-based architecture (such as ant blockchains), the account types supported by the blockchain may be further expanded, and are not particularly limited in this specification.
For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.
Taking etherhouses as an example, the structure of an account usually includes fields such as Balance, Nonce, Code and Storage. Wherein:
a Balance field for maintaining the current account Balance of the account;
a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;
a Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.
A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account. The storage content of the contract account is usually constructed into a data structure of an MPT (MerklePatricia trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.
Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.
For most blockchain items, a Merkle tree is typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. Taking etherhouses as an example, the etherhouses use MPT tree (a Merkle tree variation) as a data organization form for organizing and managing important data such as account status, transaction information, and the like.
The Etherhouse designs three MPT trees, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree, aiming at data needing to be stored and maintained in a block chain. In addition to the above three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.
An MPT state tree, which is an MPT tree organized by account state data of all accounts in a blockchain; an MPT transaction tree, which is an MPT tree organized by transaction (transaction) data in a blockchain; the MPT receipt tree is organized into transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are eventually added to the block header of the corresponding block.
The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.
It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;
for example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.
After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.
That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is completed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.
In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a smart contract (Smartcontract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.
Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.
After Bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, each node can execute the Transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.
After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.
As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.
Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.
As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 4, the From field of the transaction is used To record the address of the account initiating the invocation of the smart contract, the To field is used To record the address of the invoked smart contract, and the Data field of the transaction is used To record the method and parameters of the invocation of the smart contract. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed block link point (e.g., node 1 in fig. 2).
The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.
A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.
Conventional blockchain projects, represented by etherhouses, typically support conversion of real-world currency into virtual tokens that can be circulated through the chain in order to effect a "value transfer" over the blockchain.
In the blockchain field, for some blockchain items derived from the ethernet-based architecture (such as ant blockchains), the function of converting real-world currency into virtual tokens that can circulate on the chains is generally no longer supported; instead, in these blockchain projects, some non-monetary attributes of the physical assets in the real world may be converted into virtual assets that can be circulated over the blockchain.
It should be noted that converting an entity asset having a non-monetary attribute in the real world into a virtual asset on a blockchain generally refers to a process of "anchoring" the entity asset and a virtual asset on the blockchain to serve as a value support for the virtual assets, and further generating a virtual asset on the blockchain which is matched with the value of the entity asset and can be circulated between blockchain accounts on the blockchain.
In the implementation process, the account types supported by the blockchain can be expanded, and an asset account (also called an asset object) is expanded on the basis of the account types supported by the blockchain; for example, an asset account can be expanded on the basis of an external account and a contract account supported by an Ethernet; the expanded asset account is a virtual asset which can support the real-world non-monetary property of the physical asset as value and can be circulated between the blockchain accounts.
For users accessing such a blockchain, in addition to completing the creation of user accounts and intelligent contracts on the blockchain, a virtual asset matched with the entity asset value of non-monetary attributes of the real world is created on the blockchain, and circulation is performed on the blockchain;
for example, a user may convert physical assets of non-monetary attributes, such as real estate, stocks, loan contracts, notes, accounts receivable, etc., held to value-matched virtual assets for circulation over a blockchain.
The above asset account may be maintained by a structure, specifically, the account status of the account may be maintained by a structure. The content of the structure of the asset account may be the same as that of the ether house, and may be designed based on actual requirements;
in one implementation, for example, the content of the structure body of the asset account is the same as that of an ethernet bay, the structure body of the asset account may also include the fields of Balance, Nonce, Code, and Storage described above.
It should be noted that, in an ethernet, the Balance field is usually used to maintain the current account Balance of the account; for the block chain project derived based on the ethernet framework, since it may not support the conversion of real-world currency into virtual tokens that can be circulated on the chain, in such block chains, the meaning of the Balance field may be extended, and the Balance of the account is no longer represented, but is used to maintain the address information of the asset account corresponding to the "virtual asset" held by the account. In practical application, address information of asset accounts corresponding to multiple virtual assets can be maintained in the Balance field.
In this case, the external account, the contract account, and the asset account shown above can hold the virtual asset by adding address information of the asset account corresponding to the "virtual asset" that needs to be held in the Balance field. That is, in addition to the external account and the contract account, the asset account itself may hold the virtual asset.
For an asset account, Nonce, the field value of the Code field may or may not be null; and the field value of the Storage field may no longer be a null value; the Storage field may be used to maintain the asset status of the "virtual asset" corresponding to the asset account. The specific manner of maintaining the asset state of the "virtual asset" corresponding to the asset account in the Storage field can be flexibly designed based on requirements, and is not described in detail.
In the blockchain project derived based on the framework of the EtherFang, a user can create a virtual asset on the blockchain that matches the value of the real-world non-monetary attribute physical asset by the implementation shown below:
in one implementation, the transaction types supported by the blockchain may be extended to extend a transaction for creating virtual assets; for example, the types of transactions supported by the etherhouse typically include normal transfer transactions, transactions to create smart contracts, and transactions to invoke smart contracts, and a transaction to create virtual assets may be expanded based on the above three types of transactions.
In this case, a user may create a virtual asset for the user by issuing a transaction into the blockchain network by the client, which is performed by a node device in the blockchain in the local EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.
In another implementation, intelligent contracts for creating virtual assets may also be deployed on blockchains; the process of deploying the intelligent contract for creating the virtual asset is not described in detail.
In this case, the user may create a virtual asset for the user by issuing a transaction for invoking the intelligent contract into the blockchain network by the client, executing the transaction in the local EVM by the node device in the blockchain, and running a contract code associated with the intelligent contract in the EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.
Of course, for some blockchain items derived based on the ethernet framework, if the blockchain items also support the function of converting real-world currency into virtual tokens that can circulate on the chain, some non-currency property entity assets in the real world can still be converted into a form of virtual tokens that can circulate on the blockchain, and the virtual tokens circulate on the blockchain, which is not described in detail in this specification.
In a cross-chain scenario, multiple blockchains may implement cross-chain docking through cross-chain relays.
The cross-link relay can be respectively connected with the block chains through the bridging interfaces, and the cross-link data synchronization among the block chains is completed based on the realized data carrying logic.
The chain-crossing technology used for realizing the chain-crossing relay is not particularly limited in this specification; for example, in practical applications, a plurality of block chains can be connected by a chain-crossing mechanism such as side chain technology, notary technology, and the like.
After a plurality of block chains are connected in a butt joint mode through cross-chain relays, data on other block chains can be read and authenticated between the block chains, and intelligent contracts deployed on other block chains can be called through the cross-chain relays.
The intelligent contract deployed on the block chain can use the data stored on the block chain, and can also use the data on the data entity outside the chain through an Oracle prediction machine, so as to realize the data interaction between the intelligent contract and the data entity of the real world. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.
Unlike cross-link relays, the function of the Oracle;
that is, the cross-link relay is used to connect two blockchains, and the Oracle ora.
Referring to fig. 4, fig. 4 is a schematic diagram of a blockchain-based asset securitization system in accordance with an exemplary embodiment of the present disclosure.
The Asset securitization refers to a process of taking cash flow generated in the future of a basic Asset as repayment support, carrying out credit enhancement through structured design, and issuing Asset-Backed Securities (ABS) on the basis; it is a financing form that issues tradeable securities in favor of a particular portfolio of assets or a particular cash flow.
In summary, the basic process of securitization financing in one complete transaction generally includes: the initiator (i.e., the original beneficiary) may sell the securitable base asset to the manager, or may actively purchase the securitable base asset by the manager; then the management party can collect the basic Assets into a basic asset Pool (Assets Pool), and issues securities financing on the financial market by taking cash flow generated by the basic asset Pool as repayment support; finally, the cash flow generated by the underlying asset pool can be utilized to liquidate the issued securities.
The administrator may be a Special Purpose organization (SPV).
In the block chain-based asset securitization system as shown in fig. 4, the original rights beneficiary can publish the basic assets held by the original rights beneficiary to the block chain for credentialing, and the management party can purchase the basic assets from the original rights beneficiary and assemble the basic assets credentialed in the block chain into a basic asset pool, i.e., create a basic asset pool based on the basic assets.
In particular, the administrator may enable the creation of a pool of base assets based on the base assets by invoking intelligent contracts deployed on the blockchain. In this case, the base asset pool may be a collection of identifications of several screened base assets generated by the intelligent contract. The set may be stored in an account Storage space (e.g., Storage field) of the contract account corresponding to the intelligent contract, or in an account Storage space of the blockchain account of the administrator.
Subsequently, the manager can issue securitized assets on the blockchain with the base pool of assets as a value support, i.e., future cash flows generated by the base pool of assets are paid back to issue securitized assets.
Wherein the underlying assets may be underlying debt assets (e.g., accounts receivable); the securitized asset may be ABS (e.g., bond or fund); the management party supports the process of issuing the securitized assets on the block chain by using the basic asset pool as a value, and may refer to the process of creating the virtual assets on the block chain, which is not described herein again.
The investor may purchase the securitized asset by paying an amount of funds to the administrator. The manager may make a second investment with funds paid by the investor to obtain a corresponding cash flow, which may be considered the cash flow generated by the underlying asset pool. On the other hand, the manager can pay the investor a certain amount of money from the cash flow as the profit obtained by purchasing the securitized asset, at a rate agreed in advance with the investor, by using the cash flow, to perform the settlement process.
For example, assuming that the amount of money paid by the investor to purchase the securitized asset issued by the manager is 10000 yuan, and the rate agreed by the manager and the investor for the securitized asset is 3.65% (annual rate of return), the manager may pay the investor 1 yuan per day as the profit obtained by the investor to purchase the securitized asset.
Referring to fig. 5, fig. 5 is a flowchart illustrating a block chain based asset compensation method according to an exemplary embodiment of the present disclosure. The block chain-based asset liquidation method can be applied to the electronic equipment added to the block chain as the node equipment in the block chain-based asset securitization system shown in FIG. 4; the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a Personal Digital Assistants (PDAs), and the like, which is not limited in this specification. The asset compensation method based on the block chain can comprise the following steps:
step 502, receiving advance settlement trades which are periodically sent by a client in the storage period of the securitized assets and aim at the securitized assets; wherein the securitized asset is an asset issued on the blockchain that supports as value a pool of base assets created based on base assets that are credited in the blockchain;
step 504, responding to the advance compensation transaction, calling advance compensation confirmation logic in the intelligent contract deployed on the blockchain, and determining whether the asset default rate of the basic assets in the basic asset pool reaches a preset threshold value;
step 506, if the asset default rate reaches the threshold, further invoking early-clearing logic in the intelligent contract to carry out early-clearing processing on the securitized asset, and after the clearing is finished, setting the securitized asset to be in an invalid state.
In practical applications, if the basic assets in the basic asset pool have default situations, for example: in this case, the manager can perform advance settlement in order to stop damage in time, in which case the receivable as the basic asset is not yet collected and posted.
In this embodiment, the client may be supported by the manager with the base asset pool as a value, and periodically construct a pre-payment transaction for the securitized asset during the lifetime of the securitized asset issued on the blockchain, and issue the pre-payment transaction to the blockchain for deposit.
The client may be a client used by the administrator, that is, a client running on an electronic device used by the administrator; alternatively, the client may be a client used by other related parties such as an investor, and the description is not limited thereto.
Referring to the aforementioned process of persisting the evidence data in the blockchain, the node device in the blockchain may receive the advance settlement transaction and perform consensus processing on the advance settlement transaction. After consensus is reached, the node devices in the blockchain may package the early-clearing transaction into blocks in which persistent storage is performed.
For the upfront liquidation transaction packaged into a blockchain, the node device in the blockchain can execute the upfront liquidation transaction, namely, the upfront liquidation confirmation logic declared in the intelligent contract deployed on the blockchain can be called to respond to the upfront liquidation transaction so as to carry out upfront liquidation confirmation on the securitized assets.
Wherein the upfront liquidation validation logic may be program code (e.g., program methods or functions available for invocation) declared in the intelligent contract relating to execution logic for upfront liquidation validation of the certified asset; the process of creating and invoking the intelligent contract may refer to the process of creating and invoking the intelligent contract, which is not described herein again.
In practical applications, the advance liquidation confirmation of the securitized assets can be realized by determining whether the asset default rate of the base assets in the base asset pool reaches a preset threshold value.
The threshold may be preset by a technician, or may be a default value, which is not limited in this specification.
For a certain basic asset in the basic asset pool, if the basic asset has a default condition, the client may construct a default transaction corresponding to the basic asset based on default data of the basic asset, and issue the default transaction to the blockchain for deposit.
Wherein the default data may include identification of the underlying asset, reason for default, date of default, etc.; the process of issuing the default transaction to the blockchain for saving the certificate can refer to the process of persisting the certificate saving data in the blockchain, and the description of the specification is omitted here.
For example, assuming that the latest collection date of a certain receivable in the base asset pool as a base asset is 20/8/2019, if the receivable is not received yet 21/8/2019, it can be determined that the receivable has a default. At this time, the client may construct a default transaction corresponding to the receivable account based on the data such as the identification of the receivable account, the reason of default (overdue not collected and checked out), and the default date (21/8/2019), and issue the default transaction to the blockchain for deposit.
In this case, it can be determined whether a default condition occurs in a base asset by looking up default data corresponding to the base asset in the blockchain, for example: based on the identification of the base asset, default data corresponding to the identification can be searched in the blockchain, and whether the default condition of the base asset occurs or not can be determined based on the search result. That is, if the default data corresponding to the basic asset is found in the block chain, it can be determined that the default condition occurs in the basic asset; accordingly, if default data corresponding to the base asset is not found in the blockchain, it may be determined that the base asset does not have a default.
In practical applications, the default status of each basic asset in the asset pool may also be stored in the account storage space of the contract account corresponding to the intelligent contract or the account storage space of the blockchain account of the management party, for example: and storing the corresponding relation between the identification of each basic asset in the asset pool and the default state. It should be noted that the default state is initially an unlawful state. Upon receiving a breach transaction corresponding to the base asset, the breach state can be updated to breached.
In this case, whether a default condition occurs in a base asset can be determined by querying a default status corresponding to the base asset. That is, if the default status corresponding to the base asset is default, it can be determined that the default status of the base asset occurs; accordingly, if the default status corresponding to the base asset is not default, it may be determined that the base asset is not subject to default.
For the base asset pool, the asset default rate of the base assets in the base asset pool may be a proportion of the base assets in the base asset pool where the default condition occurs to all the base assets, i.e., the asset default rate is the base assets where the default condition occurs divided by all the assets. If the asset default rate reaches the threshold, it may be deemed that advance liquidation of the securitized asset is required; accordingly, if the asset default rate does not meet the threshold, then it may be deemed unnecessary to liquidate the securitized asset in advance.
For example, assuming that the threshold is 10%, the base asset pool includes 20 base assets; further assuming that a default occurs in 2 of the base assets, the threshold value is reached because the asset default rate of the base assets in the base asset pool is 2 ÷ 20 × 100% ═ 10%, and thus it can be considered that the securitized assets need to be cleared in advance.
After determining that advance liquidation of the securitized asset is required, the node device in the blockchain may further invoke advance liquidation logic in the intelligent contract to advance liquidate the securitized asset and set the securitized asset to an invalid state after liquidation is completed.
The upfront liquidation logic may be program code (e.g., some program methods or functions available for invocation) declared in the intelligent contract that is associated with execution logic for upfront liquidation of the certified asset.
It should be noted that the above-described intelligent contract for advance payment confirmation of the securitized asset and the intelligent contract for advance payment processing of the securitized asset may be integrated into one intelligent contract to be deployed on the blockchain, or may be deployed on the blockchain as two different intelligent contracts, which is not limited in this specification.
In one embodiment, the liquidation process can be performed on the securitized assets based on a preset rate, and then the accounts are transferred to investors of the securitized assets based on the liquidation result, so that the advance liquidation process of the securitized assets can be realized.
That is, the amount of money to be transferred to the investor by the manager may be calculated based on the rate agreed in advance with each investor of the securitized asset, and then transferred to the investor based on the amount of money.
Specifically, for a certain investor, the node device in the blockchain may calculate the remaining income of the investor according to a rate agreed in advance by a manager and the investor and the remaining expiration time of the securitized assets purchased by the investor, and may further calculate the sum of the remaining income and the amount of funds paid by the investor for purchasing the securitized assets. At this time, the sum of the calculated amounts is the amount of money which the manager needs to transfer to the investor.
For example, suppose that an investor purchases the securitized asset at 8/10/2019 for a period of 1 year (i.e., the securitized asset purchased by the investor will expire at 9/8/2020), and the amount of money paid by the investor for purchasing the securitized asset is 10000 yuan; further assume that the manager and an investor agree on a good rate for the securitized asset of 3.65% (annual rate of return). If it is determined that the securitized asset needs to be paid out in advance by 30/8 in 2019, the node device in the blockchain may determine that the remaining due time of the securitized asset purchased by the investor is 345 days, so that the amount of the remaining income of the investor may be calculated as 1 yuan/day × 345 yen or 345 yen, and further, the amount of the money that the manager needs to transfer to the investor may be calculated as 10000 yuan +345 yen or 10345 yen.
Subsequently, the node device in the blockchain may transfer money to the investor based on the calculated amount of money that the manager needs to transfer to the investor.
In an embodiment shown, the node device in the blockchain may issue the liquidation result to the blockchain for storage; the bank system can monitor the data of the deposit certificate in the block chain, so that the liquidation result can be monitored. When the bank system monitors the liquidation result, the bank system can transfer money from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the money amount in the liquidation result, namely, the bank system transfers money from the investment account of the manager to the investment account of the investor, wherein the money amount is required to be transferred from the manager to the investment account of the investor.
In practical applications, the investment account may be an escrow account that is opened by a manager or an investor at an escrow bank to which the bank system belongs.
In one embodiment, after completing the transfer from the investment account of the administrator to the investment account of the investor, the bank system may submit the transfer record corresponding to the investment account of the investor to the intelligent contract according to the address of the contract account corresponding to the intelligent contract in the block chain.
The intelligent contract may set the securitized asset to an invalid state in an account storage space of a contract account corresponding to the intelligent contract when the transfer record is received, i.e., the securitized asset cannot be subsequently circulated in the financial market.
Or when the intelligent contract receives the transfer record, a liquidation ending event corresponding to the securitized asset can be generated, and the liquidation ending event is issued to the block chain for deposit; the manager of the securitized asset may monitor the data deposited in the blockchain, and thus may monitor the clearing end event. When monitoring the liquidation ending event, the management party can set the securitized assets maintained by the management party to be in an invalid state, namely, the subsequent securitized assets cannot be circulated in the financial market any more.
In the technical scheme, a pre-liquidation transaction for a securitized asset issued on a blockchain by a manager can be periodically sent by a client, an intelligent contract deployed on the blockchain is called by a node device in the blockchain in response to the pre-liquidation transaction, when the asset default rate of a base asset in an asset pool supported by the value of the securitized asset is determined to reach a preset threshold value, the securitization asset is subjected to pre-liquidation processing, and after liquidation is finished, the securitized asset is set to be in an invalid state. By adopting the mode, the securitized assets issued by the management party on the block chain can be cleared up in advance, so that the management party can stop damage in time when the basic assets in the asset pool are in default.
Referring to fig. 6, fig. 6 is a flow chart illustrating another block chain based asset compensation method according to an exemplary embodiment of the present disclosure. The block chain-based asset liquidation method can be applied to the electronic equipment added to the block chain as the node equipment in the block chain-based asset securitization system shown in FIG. 4; the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a Personal Digital Assistants (PDAs), and the like, which is not limited in this specification. The asset compensation method based on the block chain can comprise the following steps:
step 602, receiving a pre-clearing transaction for securitized assets triggered by a client when determining that the asset default rate of the basic assets in the basic asset pool reaches a preset threshold; wherein the base asset pool is an asset pool created based on base assets stored in the blockchain; the securitized assets are assets issued supporting the base pool of assets as value on the blockchain;
step 604, responding to the advance compensation transaction, calling advance compensation logic deployed in the intelligent contract on the blockchain, performing advance compensation processing on the securitized assets, and setting the securitized assets to be in an invalid state after compensation is finished.
In this embodiment, the client may monitor in real time whether the asset default rate of the base assets in the base asset pool reaches a preset threshold.
If the asset default rate of the base assets in the base asset pool reaches the threshold, a pull-in transaction for the securitized assets can be constructed by the client and issued to the blockchain for deposit.
The client may be a client used by the administrator, that is, a client running on an electronic device used by the administrator; alternatively, the client may be a client used by other related parties such as an investor, and the description is not limited thereto.
Referring to the aforementioned process of persisting the evidence data in the blockchain, the node device in the blockchain may receive the advance settlement transaction and perform consensus processing on the advance settlement transaction. After consensus is reached, the node devices in the blockchain may package the early-clearing transaction into blocks in which persistent storage is performed.
For the upfront transaction packaged into a block, the node device in the block chain may execute the upfront transaction, that is, may invoke upfront payment logic in an intelligent contract deployed on the block chain in response to the upfront transaction, perform upfront payment processing on the securitized asset, and set the securitized asset to an invalid state after payment is completed.
Wherein the advance payment logic may be program code (e.g., program methods or functions available for invocation) declared in the intelligent contract that is associated with execution logic for advance payment of the certified asset; the process of creating and invoking the intelligent contract may refer to the process of creating and invoking the intelligent contract, which is not described herein again.
The specific implementation method of each step in this embodiment may refer to the embodiment shown in fig. 5, and this description is not repeated here.
In the technical scheme, when determining that the asset default rate of the base asset in the asset pool supported by the value of the securitized asset issued on the blockchain by the manager reaches a preset threshold, the client triggers the advance liquidation transaction for the securitized asset, and the node device in the blockchain responds to the advance liquidation transaction, calls the intelligent contract deployed on the blockchain to carry out advance liquidation processing on the securitization, and sets the securitized asset to be in an invalid state after the liquidation is finished. By adopting the mode, the securitized assets issued by the management party on the block chain can be cleared up in advance, so that the management party can stop damage in time when the basic assets in the asset pool are in default.
In correspondence with the foregoing embodiments of the block chain based asset compensation method, the present specification also provides embodiments of a block chain based asset compensation device.
The embodiment of the asset compensation device based on the block chain can be applied to the electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 7, a hardware structure diagram of an electronic device in which an asset compensation apparatus based on a block chain is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 7, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to an actual function of the asset compensation based on the block chain, which is not described again.
Referring to fig. 8, fig. 8 is a block diagram of a block chain-based asset compensation device according to an exemplary embodiment of the present disclosure. The block chain-based asset compensation device 80 can be applied to the electronic device shown in fig. 7, which can join the block chain as a node device; the block chain based asset compensation device 80 may comprise:
the receiving module 801 is used for receiving advance settlement trades which are periodically sent by a client in the storage period of the securitized assets and aim at the securitized assets; wherein the securitized asset is an asset issued on the blockchain that supports as value a pool of base assets created based on base assets that are credited in the blockchain;
a confirmation module 802, responsive to the early-clearing transaction, invoking early-clearing confirmation logic in the intelligent contract deployed on the blockchain to determine whether the asset default rate of the base assets in the base asset pool reaches a preset threshold;
the liquidation module 803 further invokes a liquidation-in-advance logic in the intelligent contract to liquidate the securitized assets in advance if the asset default rate reaches the threshold value, and sets the securitized assets to be in an invalid state after the liquidation is finished.
In this embodiment, the compensation module 803:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
In this embodiment, the compensation module 803:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
In this embodiment, the investment account is an escrow account opened at an escrow bank.
In this embodiment, the compensation module 803:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
In this embodiment, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
Referring to fig. 9, fig. 9 is a block diagram of another block chain-based asset compensation device according to an exemplary embodiment of the present disclosure. The block chain-based asset compensation device 90 can be applied to the electronic device shown in fig. 7, which can be added to the block chain as a node device; the block chain based asset compensation device 90 may comprise:
the receiving module 901 is used for receiving the advance settlement transaction aiming at the securitized assets triggered by the client when the asset default rate of the basic assets in the basic asset pool is determined to reach the preset threshold; wherein the base asset pool is an asset pool created based on base assets stored in the blockchain; the securitized assets are assets issued supporting the base pool of assets as value on the blockchain;
a liquidation module 902, responsive to the advance liquidation transaction, invokes advance liquidation logic deployed in the intelligent contract on the blockchain to liquidate the securitized asset in advance, and sets the securitized asset to an invalid state after liquidation is completed.
In this embodiment, the liquidation module 902:
performing liquidation processing on the securitized assets based on a preset rate;
transferring funds to investors of the securitized assets based on the liquidation results.
In this embodiment, the liquidation module 902:
and issuing the liquidation result to the block chain for evidence storage, so that a bank system transfers accounts from the investment account of the manager of the securitized assets to the investment account of the investor of the securitized assets based on the amount of money in the liquidation result when monitoring the liquidation result.
In this embodiment, the investment account is an escrow account opened at an escrow bank.
In this embodiment, the liquidation module 902:
determining whether a transfer record corresponding to an investment account of an investor of the securitized asset submitted by the banking system is received;
setting the securitized asset to an invalid state if the transfer record is received; or,
and if the transfer record is received, generating a liquidation ending event corresponding to the securitized asset, so that the manager of the securitized asset sets the securitized asset to be in an invalid state when monitoring the liquidation ending event.
In this embodiment, the securitized asset is a bond or fund; the underlying assets are underlying debt assets.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.