CN112419060A

CN112419060A - Asset hosting system, asset management method, node, and medium

Info

Publication number: CN112419060A
Application number: CN202011309942.XA
Authority: CN
Inventors: 杨光; 陈炤桦; 伍鸣; 龙凡; 李辰星
Original assignee: Shanghai Shutu Blockchain Research Institute
Current assignee: Shanghai Shutu Blockchain Research Institute
Priority date: 2020-11-20
Filing date: 2020-11-20
Publication date: 2021-02-26
Anticipated expiration: 2040-11-20
Also published as: CN112419060B

Abstract

The asset hosting system, the asset management method, the node, and the medium of the present application include: a plurality of custodian nodes forming a plurality of custodian groups in a manner of being capable of overlapping grouping, i.e., each custodian node can belong to a plurality of custodian groups at the same time; and the scheduling module is used for responding to a user request and scheduling at least one target custody group to host the assets to be hosted or operate the hosted assets. Compared with the existing decentralization escrow scheme based on deposit, the method can obviously reduce the demand on deposit amount, greatly improve the fund use efficiency, and the loss caused by the joint action of a few depositors cannot exceed the total deposit amount of the depositors, and the safety of the escrowed fund can be ensured by taking a small amount of deposit as guarantee; the asset hosting system can be realized in a decentralized system, and the defect that the security of the centralized system completely depends on a centralized entity is overcome.

Description

Asset hosting system, asset management method, node, and medium

Technical Field

The present application relates to the field of asset management technologies, and in particular, to an asset hosting system, an asset management method, a node, and a medium.

Background

Most of the existing asset hosting systems rely on credit endorsements of centralized hosting organizations, and have higher single-point failure risks; although there are also a few decentralized asset hosting schemes that can rely on a deposit (guaranty) to replace the trust of a hosting organization with a security endorsement for hosting services, these schemes all have their own problems: for example, the number of supported participants is very limited, the participants' deposit needs to be subject to secondary escrow, the value of the deposit needed is relatively high, and so on.

Existing asset hosting systems are largely divided into two broad categories, centralized and decentralized. The decentralized asset hosting system mainly adopts the following modes: hosting the asset with the intelligent contract code; establishing multiple signature or voting mechanisms among all custodians; or the custodian is divided into several groups, each group separately keeping a part of the assets.

Centralized asset hosting system: the most common hosting systems in real life are the solutions commonly adopted by banks and exchange offices, and the centralized hosting solutions of digital assets are wBTC (ERC-20 token supported by Bingson 1: 1 on Ethermen) and imBTC (ERC-777 (ERC-20 compatible) token supported by Bingson 1: 1 on Ethermen) and the like. In a centralized hosting scheme, the security of a hosted asset is guaranteed by the reputation of some centralized entity (e.g., the trusted execution environment on which imBTC depends is ultimately tied to the chip vendor's reputation endorsement).

However, a disadvantage of centralized asset hosting systems is that the security of the hosted asset depends on the reputation of the centralized entity. Once a centralized entity is breached or attempted to do malicious intent, the security of the entire system is breached, directly resulting in irreparable loss.

The decentralized asset hosting systems, such as an asset hosting system based on intelligent contracts on block chains, a multi-custodian hosting system based on a multi-signature mechanism, and some group hosting schemes all have defects, such as cross-chain asset hosting services of block chains, operation efficiency and participation number of multiple signatures, custodians in the group hosting schemes need to provide deposit corresponding to the hosted funds, and the like, which all limit implementation of the hosting schemes.

Therefore, how to provide an asset hosting solution to solve the above problems has become an urgent technical problem in the industry.

Disclosure of Invention

In view of the above-mentioned shortcomings of the prior art, a primary object of the present application is to provide an asset hosting system, an asset management method, a node and a medium, so as to solve the problems of the asset hosting scheme in the prior art.

To achieve the above and other related objects, the present application provides an asset hosting system comprising: a plurality of custodian nodes forming a plurality of custodian groups in a manner of being capable of overlapping grouping; wherein, the overlapping grouping mode means that each custodian node can belong to a plurality of custodian groups at the same time; and the scheduling module is used for responding to a user request and scheduling at least one target custody group to host the assets to be hosted or operate the hosted assets.

Optionally, the target custody group is determined by a consensus of each candidate custody group with which the scheduling module interacts.

Optionally, the scheduling module is implemented by an intelligent contract.

Optionally, the superimposable grouping manner includes: any one of symmetric grouping based, polynomial grouping over a prime field based, and random grouping.

Optionally, each custodian node in each custodian group performs intra-group authorization authentication through an authorization authentication module corresponding to the custodian group, and obtains an authority to operate a part of the custodian assets hosted by the custodian group when the intra-group authorization authentication passes.

Optionally, the group authorization authentication is implemented by consensus of each custodian node in a custodian group.

Optionally, the intra-group authorization and authentication method includes: electronic voting or multiple signatures.

Optionally, the authorization and authentication module is implemented by interactive cooperation between managed service programs run by each custodian node in the corresponding custodian group.

Optionally, the scheduling target reservation group reserves the asset to be managed, including at least one of:

1) the scheduling module feeds back the hosting account of the target maintaining group to the user for transferring to the assets to be hosted;

2) the scheduling module receives assets to be hosted of the user and transfers the assets to a hosting account of the target group of the reservation.

Optionally, the scheduling target custody group operates on a managed asset, including: each candidate custody group interacted with by the scheduling module determines at least one target custody group that processes the user's redemption request; each custodian node in the determined target custodian group authorizes the corresponding transaction according to the redemption request, and performs intra-group authorization and authentication on the authorized transaction through an authorization and authentication module of the target custodian group; and if the authorization authentication in the group is passed, transferring the managed assets corresponding to the redemption request into the designated account of the user.

Optionally, when a problem protection group corresponding to a task of asset hosting or operation is not completed, each custodian node judges whether the problem protection group violates according to a preset rule and according to an evidence for proving that the problem protection group violates and/or an evidence for proving that the problem protection group does not violate, which is submitted by the reporter node, and punishs the problem protection group when the violation is judged.

Optionally, each custodian node in a custodian group hosting an asset to be hosted provides a deposit for securing the asset to be hosted, the deposit being an asset that is custodian and/or homogeneous with the hosted asset.

Optionally, for the problem bank with violation, deducting part or all of deposit of the problem bank as penalty.

Optionally, the plurality of custodian nodes are further configured to implement packet updating, including: and forming one or more new custodian groups by part or all of the custodian nodes in an overlapping grouping mode, and transferring the assets managed by the original custodian groups to the new custodian groups.

To achieve the above and other related objects, the present application provides an asset management method applied to custodian nodes belonging to a plurality of custodian groups; the asset management method comprises the following steps: the custodian node accepting a task corresponding to a user request to host a to-be-hosted asset or to be assigned to a hosted asset; wherein the custodian node belongs to at least one custody group that is scheduled in response to the user request; the custodian node cooperates with other custodian nodes in a custodian group to accomplish the task.

Optionally, the collaboration includes at least one of: when the task is corresponding to the asset to be managed, the custodian node custodian the asset to be managed or part of the asset to be managed together with other custodian nodes in the same custodian group; alternatively, upon redemption of the task corresponding to the escrowed asset, the custodian node performs an intra-group authorization authentication with the other custodian node, and if the intra-group authorization authentication passes, obtains rights to operate the asset hosted by the custodian group.

To achieve the above and other related objects, the present application provides a custodian node comprising: one or more network communicators for communicating with an external network; one or more memories for storing at least one computer program; one or more processors coupled to the one or more network communicators and the one or more processors for executing the at least one computer program to perform the asset management method as described.

To achieve the above objects and other related objects, the present application provides a computer storage medium storing at least one computer program, which is executed to perform the asset management method.

As described above, the asset hosting system, the asset management method, the node, and the medium according to the present application include: a plurality of custodian nodes forming a plurality of custodian groups in a manner of being capable of overlapping grouping; wherein, the overlapping grouping mode means that each custodian node can belong to a plurality of custodian groups at the same time; and the scheduling module is used for responding to a user request and scheduling at least one target custody group to host the assets to be hosted or operate the hosted assets. Compared with the existing decentralization escrow scheme based on deposit, the method can obviously reduce the demand on deposit amount, greatly improve the fund use efficiency, ensure that the loss caused by combined action and badness of a few depositors does not exceed the total deposit amount of the depositors, and ensure the safety of the escrowed fund by taking a small amount of deposit as guarantee; the asset hosting system can be realized in a decentralized system, and the defect that the security of the centralized system completely depends on a centralized entity is overcome.

Drawings

Fig. 1 is a schematic structural diagram of an asset hosting system in an embodiment of the present application.

FIG. 2 is a schematic structural diagram of a custody group according to an embodiment of the present application.

Fig. 3 is a schematic diagram illustrating a relationship between custody groups and custody nodes formed based on an overlappable grouping manner according to an embodiment of the present application.

FIG. 4 shows a flow diagram for asset hosting in one embodiment of the present application.

FIG. 5 shows a schematic flow diagram for asset hosting in yet another embodiment of the present application.

FIG. 6 shows a schematic representation of the flow of asset redemption in an embodiment of the application.

Fig. 7 is a flowchart illustrating an asset management method according to an embodiment of the present application.

Fig. 8 is a schematic circuit diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application is provided for illustrative purposes, and other advantages and capabilities of the present application will become apparent to those skilled in the art from the present disclosure.

In the following description, reference is made to the accompanying drawings that describe several embodiments of the application. It is to be understood that other embodiments may be utilized and that changes in the module or unit composition, electrical, and operation may be made without departing from the spirit and scope of the present disclosure. The following detailed description is not to be taken in a limiting sense, and the scope of embodiments of the present application is defined only by the claims of the issued patent. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

Although the terms first, second, etc. may be used herein to describe various elements, information, or parameters in some instances, these elements or parameters should not be limited by these terms. These terms are only used to distinguish one element or parameter from another element or parameter. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the various described embodiments. Both the first and second elements are described as one element, but they are not the same element unless the context clearly dictates otherwise. Depending on context, for example, the word "if" as used herein may be interpreted as "at … …" or "at … …".

Also, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used in this specification, specify the presence of stated features, steps, operations, elements, components, items, species, and/or groups, but do not preclude the presence, or addition of at least one other feature, step, operation, element, component, item, species, and/or group. The terms "or" and/or "as used herein are to be construed as inclusive or meaning any one or any combination. Thus, "A, B or C" or "A, B and/or C" means "any of the following: a; b; c; a and B; a and C; b and C; A. b and C ". An exception to this definition will occur only when a combination of elements, functions, steps or operations are inherently mutually exclusive in some way.

Those of ordinary skill in the art will appreciate that the various illustrative modules and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the background, it has been mentioned that there is a dependence of the security of a centralized asset hosting system on the reputation of its hosted asset. Once a centralized entity is breached or attempted to do malicious intent, the security of the entire system is breached, directly resulting in irreparable loss.

Based on the consideration of improving safety, there are decentralized asset hosting systems in the prior art, including the following types:

1) asset hosting system based on intelligent contracts

Such as, for example, DAI at etherhouse, Synthesis, etc. Under this mechanism, all functions of the managed service are implemented by the code of the intelligent contract, and the security of the managed assets depends on the security and robustness of the intelligent contract code and the corresponding blockchain itself.

Accordingly, this type of solution suffers from the drawback that the functionality of the hosted service is limited by the intelligent contract itself. At present, the intelligent contracts can only run in a single blockchain system, and information is difficult to be exchanged between different blockchain systems trustinely, so all operations performed by the asset hosting scheme of the type are limited in the single blockchain system, and more complex services such as cross-chain asset hosting are difficult to realize.

To this end, the intelligent contract may be provided with out-of-chain information through an oracle mechanism (oracle mechanism) on the blockchain. Specifically, the block chain network cannot independently collect external information, and the prediction machine is an interface for interaction between the block chain intelligent contract and the external world, can search and verify data of the real world, and submits the information to the intelligent contract in an encrypted mode for use; it can be appreciated that the mechanism by which information outside the blockchain is written into the blockchain is generally referred to as a prediction machine.

It is clear that such a way of introducing out-of-chain information would significantly increase the risk of the asset hosting system being exposed to external malicious attacks.

2) Multiple signature mechanism with common participation of all custodians

This mechanism requires that all custodians custodian all assets together, and that each operation on a custodian asset requires a sufficient number of custodian signature authorizations to proceed. Custodians of assets endorse security of services by credit or paying a certain amount of deposit.

Due to the high cost of multiple signatures per signature run, current multiple signature schemes are often limited in practice by the efficiency of operation and the complexity of communication, and can only support a small number of participants (i.e., custodians). And if the number of participants is strictly limited, the significance of adopting decentralized hosting is largely lost.

3) A random packet hosting scheme.

Under this scheme, because the groupings are randomly selected and the size of the groupings is small, custodians within the groupings need to provide excess deposits to balance their potential damage to the assets being hosted. Taking tBTC as an example, assuming that there are 3 custodians in a group, only 2 of them need to agree to freely handle the custodian assets, so that the total value of the deposit of 2 individuals must exceed the custodian assets for security, called "excess mortgage", e.g., the total value of the deposit of 3 custodians in the group is at least 150% of the custodian assets. Therefore, on one hand, as the amount of the assets to be kept increases, the corresponding total deposit amount needs to be larger, so that a large amount of funds (deposit) is limited in the deposit amount, the fund use efficiency is low, and the cost is high; on the other hand, to ensure security in this scheme, the custody of the custodian and the hosted assets of the customer cannot be managed together, requiring secondary custody of the deposit, which in turn increases the complexity of the system and potential volatility risks.

4) A parallel packet hosting scheme.

Under this scheme, a small number of attackers concentrated in the same group have the ability to steal all assets hosted by the group, thus requiring excess mortgage and secondary escrow as with the previous grouping scheme. Taking renBTC as an example, to deposit an external fund, the corresponding escrow group needs to provide at least 300% of the total value of the deposit of the property being deposited.

Therefore, the scheme has the same problems of low fund use efficiency, increased system complexity and volatility risk due to secondary hosting and the like as the random grouping hosting scheme.

In order to solve the problems of the asset hosting schemes in the prior art, an asset hosting system is provided in the embodiments of the present application.

As shown in fig. 1, a schematic structural diagram of an asset hosting system 10 in the embodiment of the present application is shown.

The asset hosting system 10 includes a plurality of custodian nodes 11, the custodian nodes 11 being electronic systems representing interfaces for communicative interaction between custodians and other custodians. In some examples, a "node" is represented as a computer device used in custodian identity. For example, each custodian node 11 may be an electronic device, such as a server, a server group, a tablet, a cell phone, a desktop, a laptop, a smart watch, smart glasses, and the like; alternatively, a "node" may be a processing system formed by a plurality of connections in one or more of these electronic device communications.

In a specific implementation, the plurality of custodian nodes 11 may be communicatively connected via a network, such as a wired or wireless network, for example, a computer internet, or a mobile internet. The computer internet can be constructed by connecting computer devices (such as servers, desktops, laptops, tablet computers, smart phones, smart watches, smart glasses and the like) in a wired or wireless mode and communicating based on a TCP/IP protocol, for example; the mobile internet refers to a mobile communication network (such as 2G/3G/4G/5G) for communication interaction of mobile devices such as smart phones and tablet computers.

In one embodiment, the asset hosting system 10 may be implemented as a decentralized network system, such as a blockchain system, and further may be one of a federation chain, a public chain, or a private chain, where the decentralized system achieves higher security than the centralized system.

The plurality of custodian nodes 11 may form a plurality of custodian groups 13 in a superimposable grouping manner, such as shown by custodian groups 1, 2, 3 in fig. 1. The superimposable grouping method means that one custodian node 11 can belong to a plurality of custody groups. For example, custodian group X includes custodian node A, B, C, custodian group Y includes custodian node A, B, C, D, and custodian group Z includes custodian node B, C, D. That is, not only the custodian group may have a one-to-many relationship with the custodian node 11, but also the custodian node 11 may have a one-to-many relationship with the custodian group.

The asset hosting system 10 further includes a scheduling module 13 configured to schedule a corresponding at least one target custody group to host an asset to be hosted or to operate on a hosted asset in response to a user request. In particular implementations, user 14 may interact with scheduling module 13, submitting a user request regarding the asset hosting or operation to scheduling module 13; the scheduling module 13 interacts with the various candidate guaranteed pipe groups for determining and coordinating one or more guaranteed pipe groups specifically responsible for the hosting or operation. Alternatively, each of the candidate custodian groups 15 may be all custodian groups 15 or may be a partial custodian group 15 satisfying a condition. Optionally, the scheduling module 13 may also directly specify the protection group responsible for the hosting or operation according to the situation of each candidate protection group.

In some examples, the operations include: redeeming the asset; other dispositions of the hosted asset may also be included, such as transfers, and the like.

For example, user a sends a user request to a scheduling module that requires custody of its assets B to be custody, said scheduling module responding to the user request and then determining a target custody group C for custody of said assets B through interaction between the scheduling module and at least one candidate custody group; or, the user A sends a user request to the scheduling module to redeem the asset B stored in the scheduling module, and the scheduling module responds to the user request, determines that the storage B is a storage group C, and completes the redemption work of the asset B by the storage group C.

Alternatively, the scheduling module may be implemented in the form of an intelligent contract on a blockchain, so that no decision by any centralized node is required. Further, the intelligent contracts may be approved by each participant, and in the embodiment of the present application, the participant may be each of the custody groups and each of the custody owners.

Optionally, when the scheduling module interacts with a plurality of candidate storage groups, it is also necessary to determine which one or more candidate storage groups are used as the target storage group to execute the task corresponding to the user request. In a specific implementation, the custodian nodes 11 may form a blockchain system or other consensus system, and perform mutual communication interaction according to a preset consensus mechanism to determine the at least one target custody group for performing the asset hosting or operation task corresponding to the user request.

For example, user A sends a user request to the scheduling module that requires custody of their assets B to be custody, which in response to the user request, interacts with the candidate custody group C, D, E to determine a target custody group, C, D, E determines through consensus that custody of B is performed by both C and E, etc., or alternatively, may determine that, for example, C is one to perform custody of B.

Therefore, in actual practice, it is not always necessary that each of the protection groups 13 be responsible for the storage and redemption of the assets of one user 14, and a plurality of protection groups 13 may be responsible for the storage of some of the assets of the users 14. For example, user A sends a user request to the scheduling module that requires the custody of his assets B to be custody, and the scheduling module determines a target custody group among the candidate custody groups C, D, E to be responsible for the custody of B, after consensus C, D, E confirms that the target custody group C, D is responsible for the custody of B in the first part B1 and the second part B2, respectively.

Referring also to fig. 2, each custody group 20 may have an authorization module 21 implemented therein for performing intra-group authorization authentication for each custody node in order to obtain access to the assets 22 hosted by the custody group 20 if the intra-group authorization authentication passes.

It should be noted that, as exemplarily shown in fig. 2, each custodian node (not shown in fig. 2, but refer to fig. 1) in each custodian group 20 (i.e., the custodian 1 to the custodian group m in fig. 2) performs intra-group authorization authentication through the authorization authentication module 21 belonging to the custodian group 20, and if the intra-group authorization authentication passes, the node can have the operation right for the asset 22 hosted by the custodian group 20, and does not need to pass through authorization authentication of authorization authentication modules in other custodian groups.

That is, each of the teams of custody 20 independently manages the operational rights of the hosted asset 22. In some examples, for assets B of user a divided into B1, B2, C and D are managed separately, C internally manages the operating right to B1 through intra-group authorization authentication, D internally manages the operating right to B2 through intra-group authorization authentication, and the two may be independent of each other.

Optionally, in a system based on a consensus mechanism, for example, a blockchain system, the group authorization authentication of the authorization authentication module may be implemented by a consensus manner between the respective custodian nodes in each custodian group. That is, the intra-group authorization authentication may be determined by consensus among custodian nodes in the corresponding custodian group. For example, the ways of the intra-group authorization authentication include: electronic voting, multiple signatures.

Among these, electronic voting is also called electronic election, and is simple in that each custodian node in a group electronically votes for a certain transaction, for example, a transaction related to a task of asset custody or redemption, and agrees to execute when the number of votes agreeing to the action is equal to or greater than a certain threshold (e.g., 1/2 or 2/3).

Multiple signatures refer to multiple participants simultaneously signing a digital asset, also known as threshold signatures. For example, if an address can only be signed and paid by a private key, the representation is 1/1; the expression form of the multiple signature is m/n, m is smaller than n, namely an account address is associated with n private keys, and when no less than m private keys simultaneously sign a transaction sent by the account, the transaction is considered to be legally authorized. The principle also means that the transaction is executed when the m/n custodian nodes agree.

The implementation of the above-mentioned intra-group authorization authentication is explained from a practical physical level. In a specific implementation, each custodian node in each custodian group may be installed with a hosting service program to perform mutual communication interaction through the hosting service program to realize the mechanism of electronic voting or multiple signatures; correspondingly, the authorization and authentication module is realized by interactive cooperation among managed service programs operated by each custodian node in the corresponding custodian group.

In some examples, each custodian node in each custodian group can also be implemented by a running custodian service program to accept tasks distributed corresponding to asset hosting or operation, and when the distributed tasks need to cooperate with other members in the same custodian group, the tasks are mutually communicated and interacted to complete the authentication of the authorization in the group.

For a visual explanation of the relationship between the storage group and the storage node with the above-described structure, reference is made to fig. 3.

Each group of custody nodes 30 may include a plurality of custody nodes 31, and each custody node 30 may belong to a plurality of custody groups 30 simultaneously, such as, for example, the group of custody groups 1-3 versus the group of custody nodes 1-4 in FIG. 3, wherein the group of custody nodes 1-3 are in the group of custody 1, the group of custody nodes 3, 4 are in the group of custody 2, and the group of custody nodes 2, 4 are in the group of custody 3.

Since each custodian node may belong to a plurality of different custody groups 30 simultaneously, it is possible that members of one custody group 30 may actually have authority to operate assets held by a plurality of different custody groups 30, as long as they can pass the intra-group authorization authentication of the corresponding custody group 30.

Optionally, each custodian node 31 in a custodian group 30 hosting an asset to be hosted provides a deposit that secures the asset to be hosted. Each group of keeping pipes 30 is realized in an overlapping grouping mode, each group of keeping pipes 30 independently manages the operation authority of assets in the group, and a custodian cannot obtain income from practice and badness through the overlapping grouping mode, so that the safety of the hosting service is ensured from the perspective of game theory. By adopting overlapping grouping (one custodian node 31 can belong to a plurality of custody groups 30 at the same time) rather than the common parallel grouping (each custodian node 31 only belongs to one custody group 30), the total deposit amount required for ensuring the safety can be reduced under the condition that a potential attacker can only control a few custodians, the excessive mortgage in the prior art is not needed, and the use efficiency of funds is improved; because when the number of keeper nodes under the control of an attacker is below a certain proportion, the proportion of all the keeper packets that can be actually controlled by these keeper nodes is much lower than the proportion of all the keeper nodes occupied by the keeper nodes under the control. In addition, optionally, the deposit can be an asset which is kept and/or is homogeneous with the managed asset, so that secondary hosting in the prior art is eliminated, and hosting efficiency is improved.

Specific examples of practical implementations are combined below to demonstrate the advantages of the stackable approach. In some examples, the superimposable grouping manner includes, but is not limited to, any one implementation of symmetric grouping-based, polynomial grouping-based on prime field, random grouping, and the like.

The overlapping grouping manner is exemplified based on the principle of a symmetrical grouping implementation, which implements groups of custody for each k persons of the same number of persons, constituted from n custody persons. In such a grouping method, when the total number of custodians (i.e., the number of custodians nodes) n is 20 and the number of persons k per group is 6, the configuration can be made at most

And a pipe protecting group. And, if the in-group authorization authentication within each custody group is designed such that a minimum of 4 custodians agree to operate the custody assets, then no more than a malicious custodian can doWhen 5 people (i.e., the proportion of 1/4 is not more than n), the whole asset hosting system can safely host assets which are more than 16 times of the total value of the deposit.

In a specific example of the calculation, n is 20, k is 6, and assuming that the deposit number per custodian is 100 yuan, the total deposit number is 2000 yuan. Under the premise that a malicious custodian is 5 persons, the malicious custodian can steal the property of 540 custody groups at most, so that the value of the external assets which can be safely managed is not less than 5 × 100/540 × 38760-.

Wherein, regarding the property that can steal 540 groups of guaranties at most, calculate as follows: if the malicious custodian is 5, the property of 540 custody groups can be stolen at most, and the calculation method is as follows: in one case, if all 5 malicious custodians are in one group, each group of custodians includes the 5 malicious custodians and another normal custodians, and there are 15 normal custodians, so that 15 custodians can be controlled at most; in another case, if 4 malicious custodians are in a group, there will be

In each case, there are 15 x 14/2! Selecting another two normal custodians to form a holding group in 105 modes; thus, at most 15+5 × 105 to 540 packets may be formed and controlled by a malicious custodian to steal property. If the number of malicious custodians in a group is small (e.g., 3,2,1), the group cannot be controlled because it is not more than half.

Illustrating the principle that the described stackable grouping approach is implemented on the basis of a grouping approach based on polynomials over prime fields, also called prime numbers, which refers to fields without true subdomains, also called minimum fields. E.g. a rational number field, is encompassed by any number field, i.e. a rational number field is the smallest number field which no longer contains any true subdomains, it is a prime field.

For a certain prime number k, let

Is that

N is k²An element, wherein each element (a, b) corresponds to a keeper. The grouping scheme is as follows:

{A_p| p is defined in

The d-th first polynomial of (a) }

Wherein for each polynomial p, the custody group corresponding to p is defined as A_pThese are k custodians { (0, p (0)), (1, p (1)), …, (k-1, p (k-1)) }. According to the basic algebraic theorem, the size of the intersection of any two different holding groups in the grouping mode does not exceed d-1.

In the grouping mode, if the total number of custodians n is 121, the number of people k in each group is 11, and the minimum number of custodians required for operating the assets to be custodiand is 8; when the value of d is 5, the assets with the total value of the deposit which can be safely managed by the system can be calculated to be more than 9 times of the value of the sum of the deposits under the condition that the malicious custodian does not exceed 33 persons (the proportion does not exceed 3/11 of n).

A specific example of the calculation is as follows, where n is 121, k is 11, and assuming that the deposit number per custodian is 100 yuan, the total deposit number is 12100 yuan. On the premise that the malicious custodian is 33 persons, the property that no more than 4390 protection groups can be stolen at most can be calculated. Therefore, the value of the total safely-trusteeable foreign assets is not less than 33 × 100/4390 × 11⁵-12100>108900 yuan, more than 9 times the total deposit (12100 yuan).

On the premise that a malicious custodian is 33 persons, property of not more than 4390 custodians can be stolen at most, and the calculation is as follows: the total number of all storage groups is 11⁵So that 4390 tube-retaining groups only account for 4390/11⁵<2.726％<3/110, which is 1/10 of the number of malicious custodians among all custodians. So at this point even if (deposit + managed asset) reaches 10 times the amount of the deposit, the total amount of funds (3/110 for the 10-fold deposit amount) that 33 malicious custodians can control does not exceed their own amount of the deposit (3/11 for the total amount of the deposit).

Illustrating the principle that the overlappable grouping is based on a random grouping implementation. When a scheme capable of being grouped in an overlapping way is given, some custodians or custody groups can be uniformly and randomly extracted from all original custody groups divided by the scheme to form a new grouping scheme, so that the number of the custody groups can be greatly reduced, and meanwhile, a lower deposit rate is kept.

Therefore, the asset hosting is executed through all the guarantee groups which can be realized in an overlapping grouping mode, the deposit amount relative to the value of the asset to be hosted can be effectively reduced, and the utilization rate of the asset is improved.

As shown in fig. 4 and 5, the implementation process of the asset hosting system for hosting is described by embodiments.

As shown in fig. 4, the process specifically includes:

s401: a user initiates a hosting request to a scheduling module;

s402: when receiving a hosting request of a user, the scheduling module responds to the hosting request of the user, coordinates with each candidate custody group and determines a target custody group for specifically processing the hosting request, namely a corresponding custody group scheduled by the target custody group. In fig. 4, the target retention group is exemplarily shown as a retention group 1.

In a specific implementation, as in the foregoing embodiment, if the scheduling module is an intelligent contract, the scheduling module executes corresponding logic according to a preset trigger condition to schedule one or more candidate reservation groups to execute the task of the hosting request; if multiple candidate custody groups are available, the multiple candidate custody groups may perform the task by recognizing to determine one or more target custody groups therein.

In a specific example, the criteria for determining the target conservation group include, but are not limited to: the amount of value of the assets to be hosted, the value of the deposit that the custody group may provide, and the like.

S403: and feeding back the hosting account of the target maintaining group to the user for transferring the asset to be hosted.

In some examples, the escrow account is, for example, an address in a blockchain system, such as a collection address of each custodian node in a group of custodies; alternatively, a proxy address or the like may be used.

S404: the user may deposit the asset to be hosted to the checkout address.

In some examples, the property to be hosted may be split into portions for deposit at respective checkout addresses; or, alternatively, to a recipient address.

Optionally, after the target reserving group receives the transferred to-be-managed resource from the hosting account, the scheduling module is notified to correspondingly update the account balance of the user.

Or as shown in fig. 5, an implementation process of the asset hosting system in another embodiment is shown.

As shown in fig. 5, the process specifically includes:

step S501: a user initiates a hosting request to a scheduling module;

step S502: when receiving a hosting request of a user, the scheduling module responds to the hosting request of the user, coordinates with each of the preserved pipe groups and determines a target preserved pipe group for specifically processing the hosting request; in fig. 5, the target retention group is exemplarily shown as retention group 1.

Step S503: the user transfers the assets to be managed to the scheduling module;

step S504: the scheduling module stores assets to be managed to a managed account of the target protected group;

optionally, the scheduling module or custody group then issues a corresponding escrow credential to the user to prove escrow of the asset.

Optionally, the order of steps S502 and S503 is not limited, and S503 may precede S502.

In the FIG. 5 embodiment, the difference compared to the FIG. 4 embodiment is primarily that the user has hosted the asset to be hosted to the scheduling module first, e.g., to a designated account of the scheduling module. Where the example may be implemented where conditions allow, e.g., the scheduling module is extremely trusted, such as endorsed by an authority, trusted credential, etc.

Scheduling, by a scheduling module, one or more candidate custody groups to perform the task of the custody request; if multiple custody groups are scheduled, the multiple custody groups may determine one or more of the custody groups through consensus to perform the task, and the scheduling module forwards the assets to be custody groups to the custody accounts of the determined custody groups.

In the above example, the scheduling module, or a group of custody pipes involved in custody of the asset to be custody, may issue the user with corresponding custody credentials to indicate that custody is complete.

Alternatively, both the custodian node and the user in the custody group performing custody may monitor changes to the hosted asset at any time. For example, when user A deposits asset B in the account of custody group C, each custody node in custody group C, A, can view the change in asset B in the account.

Similar to the hosting example principle described above, taking the example of operating on a hosted asset as redemption, a flow of the asset hosting system processing redemption of the hosted asset is shown in fig. 6. The redemption process specifically comprises:

step S601: the user sends a redemption request to the scheduling module;

step S602: each custody group scheduled by the scheduling module determines at least one target custody group that processes the user's redemption request.

In particular implementations, the target custody group, not necessarily the one that previously received the user's asset, i.e., the user's request to deposit and redeem a hosted asset may be handled by a different custody group; in the blocks of the blockchain, the escrow transaction is recorded by all custodian nodes. In fig. 6, the target retention group is exemplarily shown as a retention group 1.

Step S603: each custodian node in the determined target custodian group authorizes the corresponding transaction according to the redemption request, and performs intra-group authorization and authentication on the authorized transaction through an authorization and authentication module of the target custodian group;

in a specific example, all custodians in the designated group of custodians generate a corresponding transaction (e.g., "transfer a x amount of assets to y account") upon redemption request, and sign the transaction to effect the authorization; the authorization and authentication module collects the signatures of the transactions in the group, and performs authorization and authentication in the group, for example, after enough signatures of custodians in the group (i.e. common authorization) are obtained, the authorization and authentication in the group are passed, the transaction party can take effect, and the managed assets are disposed according to the mode specified by the transaction.

Step S604: and if the authorization authentication in the group is passed, transferring the managed assets corresponding to the redemption request into the designated account of the user.

In the example of FIG. 6, the hosted asset may be deposited directly into the user's designated account by the determined custody group; or in other examples, the hosted assets may be sent by the determined custody group to a scheduling module, which credits the user's designated account.

In order to enhance the safety of the asset hosting system, the possibility of wrongdoing of custody is further reduced; so in some examples, a penalty mechanism may be devised.

For example, when a problem bank corresponding to a task of asset hosting or operation is not completed, each custodian node judges whether the problem bank violates according to a preset rule and evidence for proving that the problem bank violates and/or evidence for proving that the problem bank does not violate and submitted by a reporter node, and punishs when the violation is judged.

The reporter node can be a user node of a user who carries out asset hosting, and can also be each custodian node; optionally, for the problem bank with violation, deducting part or all of deposit of the problem bank as penalty.

By way of example, a secured group that is determined and assigned to handle a user's escrow/redemption request, but not completed within a reasonable time, such as not transferring on demand to a user-specified account when handling the redemption request, or not coordinating with other custodian nodes/secured groups to update the secured group as required by the asset hosting system, or failing to respond in time when selected as a candidate secured group, etc., may be determined to be a problematic secured group. For the group of the problem-occurring custody group, a participant (namely, a reporter node) in the intelligent custody system can provide evidence to instruct the group of the problem-occurring custody group and requires to punish the members in the group, and the members in the instructed custody group can also provide evidence proving that the members do not have violation in a specified time. The asset hosting system can judge whether the violation occurs according to a preset rule, if so, punishment is carried out by partially or totally deducting the deposit of the violation participant, and the violation participant can be removed when the group is updated next time. The deductive deposit may be used to offset losses due to violations, and may also reward other participants, such as reporter nodes.

Since there may be a change in the custodian node, such as a new custodian node being added, or a failure or change in the custodian node, the grouping structure of the custodian group is not constant and may change over time and custodian actions. In some examples, the plurality of custodian nodes are capable of implementing a group update, thereby forming a new custody group; correspondingly, the assets already managed in the original group of protection also need to be migrated corresponding to the new grouping result.

For example, some or all of the custodian nodes form one or more new custody groups in an overlapping grouping manner and transfer assets hosted by the original custody group to the new custody group. For example, in an example involving only a single custody group update, for 6 of the nodes A-F, the custody asset W is custody, A is retired, and G is taken over for A, then B-G may constitute a new custody group, G provides a deposit corresponding to A, the old custody group A-F transfers the custody asset W to the new custody group B-G, and G fulfills all the roles of A in the old custody group in the new custody group.

As shown in fig. 7, the asset management method in the embodiment of the present application is shown, and is applied to a custodian node, which may be, for example, a custodian node in the asset hosting system in the embodiment of fig. 1, but is not limited thereto. By means of the superimposable grouping, the custodian node can belong to a plurality of custody groups at the same time, such as illustrated in fig. 3. The technical features of the asset management method may refer to the previous embodiments, and are not repeated herein.

The asset management method comprises the following steps:

step S701: the custodian node accepting a task corresponding to a user request to host a to-be-hosted asset or to be assigned to a hosted asset; wherein the custodian node belongs to at least one custody group that is scheduled in response to the user request.

Optionally, the user request may be sent to a scheduling module, and the scheduling module interacts with each custodian node to select a candidate custodian node group, and further identifies and determines a custodian group that receives a task corresponding to the user request, where the custodian node inputs the custodian group.

Step S702: the custodian node cooperates with other custodian nodes in a custodian group to accomplish the task.

Optionally, the custodian node and other custodian nodes in the same custodian group perform intra-group authorization authentication.

Optionally, the group authorization authentication is implemented by consensus of each custodian node in a custodian group. Such as electronic voting, multiple signatures, etc.

Fig. 8 is a schematic circuit diagram of a keeper node according to an embodiment of the present application.

In a specific implementation, the custodian node may be implemented as a server/server group, a tablet computer, a smart phone, a desktop computer, a notebook computer, a smart watch, smart glasses, or the like, or a distributed system formed by a plurality of communication connections in one or more of them, so as to serve as the custodian node in any of the implementations of fig. 1 to 7.

The custodian node 800 in the present embodiment includes:

one or more network communicators 801 for communicating with a network. Illustratively, the network communicator 801 includes wired or wireless communication circuitry; the wired communication circuit includes: a wired network card, etc.; the wireless communication circuit comprises a WiFi, 2G/3G/4G/5G communication module and the like.

One or more memories 802 for storing at least one computer program. Illustratively, the one or more memories 802 can include high speed random access memory, and/or include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory may also include memory that is separate from but connected to the at least one processor in a different device, such as network-attached memory accessed via RF circuitry or external ports and a communications network, which may be the internet, at least one intranet, a local area network, a wide area network, a storage area network, etc., or a suitable combination thereof. The memory controller may control access to the memory by other components of the device, such as the CPU and peripheral interfaces.

One or more processors 803 coupled to the one or more network communicators 801 and the one or more memories 802 for executing the at least one computer program to implement the functions of, for example, the custodian node in fig. 1, and further, for example, the steps in the asset management method performed by the custodian node in fig. 7.

The various functions implemented in the foregoing embodiments (e.g., the embodiments of fig. 1-8) relate to computer software products; the computer software product is stored in a storage medium, and is used for enabling a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application when the computer software product is executed.

In the embodiments provided herein, the computer storage medium may include read-only memory, random access memory, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, U-disk, removable disk, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are intended to refer to non-transitory, tangible storage media. Disk and disc, as used in this application, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

In at least one exemplary aspect, the functions described in the computer programs referred to in the method flows of the present application may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as at least one instruction or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in processor-executable software modules, which may be located on tangible, non-transitory computer storage media. Tangible, non-transitory computer storage media may be any available media that can be accessed by a computer.

The flowcharts and block diagrams in the figures described above of the present application illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises at least one executable instruction for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

To sum up, the asset hosting system, the asset management method, the node, and the medium of the present application include: a plurality of custodian nodes forming a plurality of custodian groups in a manner of being capable of overlapping grouping; wherein, the overlapping grouping mode means that each custodian node can belong to a plurality of custodian groups at the same time; and the scheduling module is used for responding to a user request and scheduling at least one target custody group to host the assets to be hosted or operate the hosted assets. Compared with the existing decentralization escrow scheme based on deposit, the method can obviously reduce the demand on deposit amount, greatly improve the fund use efficiency, ensure that the loss caused by combined action and badness of a few depositors does not exceed the total deposit amount of the depositors, and ensure the safety of the escrowed fund by taking a small amount of deposit as guarantee; the asset hosting system can be realized in a decentralized system, and the defect that the security of the centralized system completely depends on a centralized entity is overcome.

The above embodiments are merely illustrative of the principles and utilities of the present application and are not intended to limit the application. Any person skilled in the art can modify or change the above-described embodiments without departing from the spirit and scope of the present application. Accordingly, it is intended that all equivalent modifications or changes which can be made by those skilled in the art without departing from the spirit and technical concepts disclosed in the present application shall be covered by the claims of the present application.

Claims

1. An asset hosting system, comprising:

a plurality of custodian nodes forming a plurality of custodian groups in a manner of being capable of overlapping grouping; wherein, the overlapping grouping mode means that each custodian node can belong to a plurality of custodian groups at the same time;

and the scheduling module is used for responding to a user request and scheduling at least one target custody group to host the assets to be hosted or operate the hosted assets.

2. The asset hosting system of claim 1, wherein the target custody group is determined by a consensus of each candidate custody group with which the scheduling module interacts.

3. The asset hosting system of claim 2, wherein the scheduling module is implemented by a smart contract.

4. The asset hosting system of claim 1, wherein the overlapping groupings comprise: any one of symmetric grouping based, polynomial grouping over a prime field based, and random grouping.

5. The asset hosting system according to claim 1, wherein each custodian node in each custodian group performs intra-group authorization authentication by an authorization authentication module of the corresponding custodian group, and obtains a right to operate a part of the hosted assets hosted by the custodian group in a case that the intra-group authorization authentication passes.

6. The asset hosting system of claim 5, wherein the intra-group authorization authentication is implemented by consensus of custodian nodes in a custodian group.

7. The asset hosting system of claim 6, wherein the means for intra-group authorization authentication comprises: electronic voting or multiple signatures.

8. The asset hosting system according to any one of claims 5 to 7, wherein the authorization authentication module is implemented by interactive cooperation between hosted services run by respective custodian nodes within a corresponding custodian group.

9. The asset hosting system of claim 1, wherein the schedule target reservation group hosts an asset to be hosted, comprising at least one of:

10. The asset hosting system of claim 1, wherein the schedule target custody group operates on hosted assets comprising:

each candidate custody group interacted with by the scheduling module determines at least one target custody group that processes the user's redemption request;

each custodian node in the determined target custodian group authorizes the corresponding transaction according to the redemption request, and performs intra-group authorization and authentication on the authorized transaction through an authorization and authentication module of the target custodian group;

and if the authorization authentication in the group is passed, transferring the managed assets corresponding to the redemption request into the designated account of the user.

11. The asset hosting system according to claim 1, wherein when a problem conservation group of tasks corresponding to asset hosting or operation is not completed, each custodian node judges whether the problem conservation group is violated according to a preset rule and according to evidence for proving that the problem conservation group is violated and/or evidence for proving that the problem conservation group is not violated, which is submitted by a reporter node, and punishments are given when the violation is judged.

12. The asset hosting system of claim 1 or 11, wherein each custodian node in a custodian group hosting an asset to be hosted provides a deposit that secures the asset to be hosted, the deposit being an asset that is custodian and/or homogeneous with the asset being hosted.

13. The asset hosting system of claim 12, wherein for a problem bank that has a violation, a deposit that deducts some or all of the problem bank is penalized.

14. The asset hosting system of claim 1, wherein the plurality of custodian nodes, further configured to implement a group update, comprises: and forming one or more new custodian groups by part or all of the custodian nodes in an overlapping grouping mode, and transferring the assets managed by the original custodian groups to the new custodian groups.

15. An asset management method, characterized by being applied to custodian nodes belonging to a plurality of custodian groups; the asset management method comprises the following steps:

the custodian node accepting a task corresponding to a user request to host a to-be-hosted asset or to be assigned to a hosted asset; wherein the custodian node belongs to at least one custody group that is scheduled in response to the user request;

the custodian node cooperates with other custodian nodes in a custodian group to accomplish the task.

16. The asset management method of claim 15, wherein said collaboration comprises at least one of: when the task is corresponding to the asset to be managed, the custodian node custodian the asset to be managed or part of the asset to be managed together with other custodian nodes in the same custodian group; alternatively, upon redemption of the task corresponding to the escrowed asset, the custodian node performs an intra-group authorization authentication with the other custodian node, and if the intra-group authorization authentication passes, obtains rights to operate the asset hosted by the custodian group.

17. The asset management method according to claim 16, wherein said group authorization authentication is performed by consensus of custodian nodes in a custodian group.

18. A custodian node, comprising:

one or more network communicators for communicating with an external network;

one or more memories for storing at least one computer program;

one or more processors coupled to the one or more network communicators and the one or more memories for executing the at least one computer program to perform the asset management method of any of claims 15-17.

19. A computer storage medium having stored thereon at least one computer program which, when executed, performs the asset management method of any of claims 15 to 17.