CN112419060B - Asset hosting system, asset management method, node and medium - Google Patents
Asset hosting system, asset management method, node and medium Download PDFInfo
- Publication number
- CN112419060B CN112419060B CN202011309942.XA CN202011309942A CN112419060B CN 112419060 B CN112419060 B CN 112419060B CN 202011309942 A CN202011309942 A CN 202011309942A CN 112419060 B CN112419060 B CN 112419060B
- Authority
- CN
- China
- Prior art keywords
- custodian
- asset
- group
- hosted
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000007726 management method Methods 0.000 title claims abstract description 23
- 238000000034 method Methods 0.000 claims abstract description 22
- 230000004044 response Effects 0.000 claims abstract description 12
- 238000013475 authorization Methods 0.000 claims description 55
- 230000015654 memory Effects 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 11
- 230000008569 process Effects 0.000 claims description 9
- 238000012546 transfer Methods 0.000 claims description 5
- 230000002452 interceptive effect Effects 0.000 claims 1
- 230000001419 dependent effect Effects 0.000 abstract description 4
- 230000007547 defect Effects 0.000 abstract description 3
- 238000004891 communication Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 12
- 230000006870 function Effects 0.000 description 10
- 230000014759 maintenance of location Effects 0.000 description 8
- 230000003993 interaction Effects 0.000 description 7
- 238000004364 calculation method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 239000004984 smart glass Substances 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 206010063659 Aversion Diseases 0.000 description 1
- 206010061619 Deformity Diseases 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 125000006239 protecting group Chemical group 0.000 description 1
- 239000011814 protection agent Substances 0.000 description 1
- 230000001012 protector Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The asset hosting system, asset management method, node and medium of the present application, the asset hosting system includes: a plurality of custodian nodes forming a plurality of custodian groups in an overlapped grouping mode, namely each custodian node can belong to the plurality of custodian groups at the same time; and the scheduling module is used for scheduling at least one target group of conservation to host the asset to be hosted or operating the hosted asset in response to the user request. Compared with the existing deposit-based decentralization escrow scheme, the method can remarkably reduce the demand for deposit amount, greatly improve the fund use efficiency, prevent the loss caused by combined disuse of a small number of custodians from exceeding the total amount of the deposit, and ensure the safety of the escrowed funds by taking a small amount of deposit as a guarantee; the asset hosting system can be implemented in an decentralized system, and the defect that the safety of the centralized system is completely dependent on a centralized entity is overcome.
Description
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 reputation endorsements of centralized hosting institutions, and have relatively high single-point fault risks; although there are also a few decentralised asset hosting schemes that can rely on deposit (guaranty) instead of the trust authority's security endorsement of the hosting service, these schemes all suffer from respective problems: for example, the number of participants supported is very limited, the deposit of the participants needs to be escrowed twice, the value of the deposit needed is relatively high, etc.
Existing asset hosting systems fall largely into two broad categories, centered and de-centered. Wherein, the decentralised asset hosting system mainly adopts the following modes: hosting the asset with the smart contract code; establishing a multiple signature or voting mechanism among all custodians; or the custodian is divided into groups, each of which independently custodies a portion of the asset.
Centralized asset hosting system: the most common hosting system in real life is also a solution commonly adopted by banks and exchanges. In a centralized hosting scheme, the security of the hosted asset is guaranteed by the reputation of some centralized entity.
However, a disadvantage of the centralized asset hosting system is that the security of the hosted asset depends on the reputation of the centralized entity. Once the centralized entity is breached or attempted to be averted, the security of the entire system is compromised, directly resulting in an irreparable loss.
However, the decentralised asset hosting systems, such as the asset hosting system based on intelligent contracts on blockchains, the multi-custodian hosting system based on multiple signature mechanisms, and some grouping hosting schemes, such as the inter-chain asset hosting service of blockchains, the running efficiency of multiple signatures, and the number of participants, all have drawbacks, and custodian in the grouping hosting scheme needs to provide deposit corresponding to the hosting funds, and the implementation of the hosting scheme is limited.
Therefore, how to provide an asset hosting scheme to solve the above-mentioned problems has become a technical problem to be solved in the industry.
Disclosure of Invention
In view of the above-described drawbacks 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 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 by means of an stackable grouping; wherein, the overlapped 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 scheduling at least one target group of conservation to host the asset to be hosted or operating the hosted asset in response to the user request.
Optionally, the target custody group is determined by a consensus of each candidate custody group interacted with by the scheduling module.
Optionally, the scheduling module is implemented by an intelligent contract.
Optionally, the overlapping grouping manner includes: any one of symmetric grouping, polynomial grouping over a prime field, and random grouping.
Optionally, each custodian node in each custodian group performs intra-group authorization authentication through the authorization authentication module of the corresponding custodian group, and obtains the authority to operate the part of the hosted asset hosted by the custodian group if the intra-group authorization authentication passes.
Optionally, the intra-group authorization authentication is realized through consensus among all custodian nodes in the custodian group.
Optionally, the method for authorizing authentication in the group includes: electronic voting or multiple signatures.
Optionally, the authorization authentication module is implemented by interaction cooperation between hosted services operated by respective custodian nodes in the corresponding set of custodian nodes.
Optionally, the scheduling target group of conservation tubes hosts the asset to be hosted, including at least one of:
1) The scheduling module feeds back the escrow account of the target group of conservation to the user for transferring to the asset to be escrow;
2) The scheduling module receives the user's assets to be hosted and transfers to a hosted account of the target group of healthcare facilities.
Optionally, the scheduling target group of protection agents operates on the hosted asset, including: each candidate escrow group interacted by the dispatch module determines at least one target escrow group that processes the redemption request of the user; authorizing corresponding transactions by each custodian node in the determined target custodian group according to the redemption request, and carrying out intra-group authorization authentication on the authorized transactions through an authorization authentication module of the target custodian group; if the in-group authorization authentication is passed, the escrow asset corresponding to the redemption request is transferred to the user's designated account.
Optionally, when a problem protection group that does not complete a task corresponding to the asset hosting or operation occurs, each of the custodian nodes judges whether the problem protection group is illegal or not according to a preset rule and according to evidence proving that the problem protection group is illegal submitted by the presenter node and/or evidence proving that the problem protection group is not illegal submitted by the problem protection group, and punishs when judging the violation.
Optionally, each custodian node in a set of custodian assets hosting the asset to be custoded provides a deposit that is safe for the asset to be custoded, the deposit being an asset that is custody and/or homogeneous with the asset being custoded.
Optionally, for the problem protection group with violations, a part or all of the deposit of the problem protection group is deducted as a penalty.
Optionally, the plurality of custodian nodes are further configured to implement packet updating, including: and forming one or more new storage groups by some or all of the storage nodes in an overlapped grouping mode, and transferring the assets hosted by the original storage groups to the new storage groups.
To achieve the above and other related objects, the present application provides an asset management method applied to a custodian node, the custodian node belonging to a plurality of custodian groups; the asset management method comprises the following steps: the custodian node accepting tasks corresponding to user requests to host or assign to hosted assets; wherein the custodian node belongs to at least one custodian group that is scheduled in response to the user request; the custodian node cooperates with other custodian nodes in the custodian group to accomplish the task.
Optionally, the collaboration includes at least one of: when the task corresponds to the asset to be hosted, the custodian node and other custodian nodes in the same custodian group jointly custodian the asset to be hosted or part thereof; alternatively, when the task corresponds to redemption of a hosted asset, the custodian node performs an intra-group authorization authentication with the other custodian, and obtains permission to operate the asset hosted by the custodian group if the intra-group authorization authentication passes.
Optionally, the intra-group authorization authentication is realized through consensus among all custodian nodes in 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 and other related objects, the present application provides a computer storage medium storing at least one computer program which when executed performs the asset management method.
As described above, the asset hosting system, asset management method, node, and medium of the present application, the asset hosting system includes: a plurality of custodian nodes forming a plurality of custodian groups by means of an stackable grouping; wherein, the overlapped 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 scheduling at least one target group of conservation to host the asset to be hosted or operating the hosted asset in response to the user request. Compared with the existing deposit-based decentralization escrow scheme, the method can remarkably reduce the demand for deposit amount, greatly improve the fund use efficiency, prevent the loss caused by combined disuse of a small number of custodians from exceeding the total amount of deposit, and ensure the safety of the escrowed funds by taking a small amount of deposit as a guarantee; the asset hosting system can be implemented in an decentralized system, and the defect that the safety of the centralized system is completely dependent on a centralized entity is overcome.
Drawings
Fig. 1 is a schematic diagram of an asset hosting system according to an embodiment of the present application.
Fig. 2 is a schematic structural diagram of a tube set in an embodiment of the present application.
Fig. 3 is a schematic diagram illustrating a relationship between a custodian node and a custodian group formed based on an overlapping grouping method in an embodiment of the present application.
FIG. 4 shows a flow diagram of asset hosting in one embodiment of the present application.
Fig. 5 shows a flow diagram for asset hosting in yet another embodiment of the present application.
FIG. 6 shows a schematic diagram of a process for asset redemption in an embodiment of the present application.
FIG. 7 is a flow chart of 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
Further advantages and effects of the present application will be readily apparent to those skilled in the art from the present disclosure, by describing the embodiments of the present application with specific examples.
In the following description, reference is made to the accompanying drawings, which describe several embodiments of the present application. It is to be understood that other embodiments may be utilized and that structural, electrical, and operational changes 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 examples, 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. The first element and the second element are each described as one element, but not the same element, unless the context clearly indicates otherwise. The word "if" as used herein may be interpreted as "at … …" or "when … …", depending on the context, for example.
Furthermore, 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" specify the presence of stated features, steps, operations, elements, components, species, and/or groups, but do not preclude the presence, 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, A is as follows; b, a step of preparing a composite material; c, performing operation; 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 in some way inherently mutually exclusive.
Those of ordinary skill in the art will appreciate that the modules and method steps of the examples described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or as a combination 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 solution. 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 centralized asset hosting systems exist whose hosted asset security is dependent on the reputation of the centralized entity. Once the centralized entity is breached or attempted to be averted, the security of the entire system is compromised, directly resulting in an irreparable loss.
There are also decentralized asset hosting systems in the prior art based on safety-promoting considerations, including the following types:
1) Asset hosting system based on intelligent contracts
Under this mechanism, all functions of the hosted service are implemented through the code of the smart contract, and the security of the hosted asset depends on the security and robustness of the smart contract code and the corresponding blockchain itself.
Accordingly, this type of solution has the drawback that the functionality of the hosted service is limited by the smart contract itself. The intelligent contracts in the present stage can only run in a single blockchain system, and information is difficult to exchange between different blockchain systems in a trusted way, so all operations which can be performed by the asset hosting scheme of the type are limited to the inside of the single blockchain system, and more complex services such as cross-chain asset hosting and the like are difficult to realize.
To this end, the out-of-chain information may be provided to the smart contract through an oracle mechanism (oracle mechanism) on the blockchain. Specifically, the blockchain network cannot independently collect external information, and the prophetic machine is an interface for interaction between the blockchain intelligent contract and the external world, can search and verify real world data, and submits the information to the intelligent contract for use in an encrypted manner; it will be appreciated that the mechanism by which information outside the blockchain is written into the blockchain is commonly referred to as a predictor.
It is apparent that such a way of introducing out-of-chain information would significantly increase the risk of an asset hosting system being subject to external malicious attacks.
2) Multiple signature mechanism with all custodian participation
This mechanism requires that all custodians commonly custody all the custoded assets, each operation on the custoded assets requiring a sufficient number of custodian signature authorizations. The custodian of the asset endorses the security of the service by reputation or paying a certain amount of deposit.
Because of the high cost per multiple signature, current multiple signature schemes are often limited in practice by operating efficiency and communication complexity, supporting a smaller number of participants (i.e., custodians). The meaning of employing decentralised hosting is largely lost if the number of participants is severely limited.
3) 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 deposit to balance their possible loss of hosted assets. Assuming that a group has 3 custodians, only any 2 of them agree to be free to handle the custoded asset, the total deposit value of 2 persons must exceed the custoded asset, called "overstock", for security purposes, e.g., the total deposit value of 3 custodians within the group is at least 150% of the custoded asset, etc. As can be seen, on the one hand, as the amount of the stored assets increases, the corresponding total deposit amount needs to be larger, resulting in a large amount of funds (deposit) being limited therein, which results in low funds usage efficiency and high cost; on the other hand, in order to guarantee security in this solution, the deposit of the custodian and the managed asset of the customer cannot be managed together, requiring a secondary escrow of the deposit, which in turn increases the complexity and potential volatility risks of the system.
4) Parallel packet hosting scheme.
Under this scheme, a small number of attackers, who are concentrated in the same group, have the ability to steal all of the assets kept by the group, thus requiring excessive mortgages and secondary escrow as in the previous group scheme. In order to store an extraneous fund, the total value of deposit required to be provided by the corresponding escrow group is at least 300% of the value of the stored property.
Therefore, the scheme has the same problems of low fund use efficiency, increased system complexity and fluctuation risk due to secondary hosting as the random grouping hosting scheme.
To solve the problems of the asset hosting schemes in the prior art described above, an asset hosting system is provided in an embodiment of the present application.
As shown in fig. 1, a schematic diagram of an asset hosting system 10 in an 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 that represent interfaces for communication interactions between custodian and other custodian. In some examples, a "node" is represented as a computer device that is used in custodian identity. For example, each custodian node 11 may be an electronic device, such as a server, server bank, tablet, cell phone, desktop, notebook, smart watch, smart glasses, etc. device; alternatively, a "node" may be a processing system that is made up of multiple 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, etc. The computer internet can be formed by connecting computer devices (such as a server, a desktop computer, a notebook computer, a tablet computer, a smart phone, a smart watch, smart glasses and the like) in a wired or wireless mode and communicating based on a TCP/IP protocol; the mobile internet refers to a mobile communication network (such as 2G/3G/4G/5G) and is used for communication interaction of mobile devices such as smart phones, tablet computers and the like.
In an implementation, the asset hosting system 10 may be preferably implemented as a decentralised network system, such as a blockchain system, etc., and may further be one of a federated chain, a public chain, or a private chain, where the decentralised system achieves higher security than the decentralised system.
The plurality of custodian nodes 11 may form a plurality of custodian groups 13 in an overlapping grouping, such as those illustrated by custodian groups 1, 2, 3 in fig. 1. Wherein, the overlapping grouping mode refers to that one custodian node 11 may belong to a plurality of custodian 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 be a one-to-many relationship with the custodian node 11, but also the custodian node 11 may be a one-to-many relationship with the custodian group.
The asset hosting system 10 further includes a scheduling module for scheduling the corresponding at least one target group of conservation to host or operate on the hosted asset in response to a user request. In particular implementations, the user 14 may interact with a scheduling module, submitting user requests to the scheduling module regarding the asset hosting or operation; the scheduling module interacts with each candidate set of healthcare items for determining and coordinating one or more sets of healthcare items specifically responsible for the hosting or operation. Alternatively, each candidate custodian group 15 may be all custodian groups 15, or may be a partial custodian group 15 that meets the condition. Alternatively, the scheduling module may directly designate the group of conservation tubes responsible for the hosting or operation according to the situation of each candidate group of conservation tubes.
In some examples, the operations include: redemption of the asset; other ways of disposing of the hosted asset, such as transferring, etc., may also be included.
For example, user A sends a user request to a scheduling module to need to store its asset B to be stored, the scheduling module responds to the user request, and then determines a target storage group C to store the B through interaction between the scheduling module and at least one candidate storage group; alternatively, user A sends a user request to a dispatch module to redeem asset B for which custody is required, and the dispatch module determines that custody B is custody C in response to the user request, and the custody C completes the redemption of asset B.
Alternatively, the scheduling module may be implemented in the form of a smart contract on the blockchain, thereby eliminating the need to rely on any centralized node decisions. Further, the smart contract may be endorsed by each participant, which in the present embodiment may be each of the group of custodians, each of the custodians.
Optionally, if the scheduling module interacts with multiple candidate banks, it is also required to determine which one or more candidate banks are used as the target banks to execute the task corresponding to the user request. In a specific implementation, the plurality of custodian nodes 11 may form a blockchain system or other consensus system, and perform mutual communication interaction according to a preset consensus mechanism, so as to determine at least one target custodian group for performing an asset hosting or operation task corresponding to the user request in a consensus manner.
For example, user A sends a user request to a scheduling module that, in response to the user request, interacts with candidate group of safeguards C, D, E to determine the target group of safeguards, C, D, E determines that safeguarding of B is performed by both C and E, or the like, by consensus, or may also determine that, for example, C is one to perform safeguarding of B.
Therefore, in actual practice, each storage group 13 is not necessarily responsible for storing and redeeming the assets of one user 14, and a plurality of storage groups 13 may be responsible for storing a part of the assets of the user 14. For example, user A sends a user request to a scheduling module that, in response to the user request, determines a target group of savers among candidate group of savers C, D, E to be responsible for the keeping of B, C, D, E, after consensus, confirms that target group of savers C, D are responsible for keeping the first and second portions B1 and B2, respectively, of B.
Referring also to fig. 2, an authorization and authentication module 21 may be implemented in each custody group 20 for each custodian node to perform intra-group authorization and authentication in order to obtain rights to operate an asset 22 hosted by the custody group 20 if the intra-group authorization and authentication passes.
It is to be noted that, as exemplarily shown in fig. 2, each of the custodian nodes (not shown in fig. 2, refer to fig. 1) in each of the custodian groups 20 (i.e., custodian groups 1 to m in fig. 2) performs intra-group authorization authentication by the authorization authentication module 21 belonging to the own custodian group 20, and if the user passes the authorization authentication, the user can have the operation authority for the asset 22 hosted by the own custodian group 20 without performing the authorization authentication by the authorization authentication module in the other custodian group.
That is, each custody group 20 independently manages the operational rights of the hosted asset 22. In some examples, the asset B of the user a is divided into B1 and B2, C and D are managed separately, the operation authority of B1 is managed by the intra-group authorization authentication in the C, and the operation authority of B2 is managed by the intra-group authorization authentication in the D, which may be independent from each other.
Alternatively, in a system based on a consensus mechanism, such as a blockchain system, intra-group authorization authentication of the authorization authentication module may be implemented in a consensus manner between individual custodian nodes within each custodian group. That is, the intra-group authorization authentication may be determined by consensus among the respective custodian nodes in the corresponding set of custodian nodes. For example, the manner of authorization authentication in the group includes: electronic voting, multiple signatures.
Among them, electronic voting is also called electronic voting, and it is simpler that each custodian node in the set performs electronic voting on a certain transaction, for example, a transaction related to a task of asset storage or redemption, and agrees to execute when the number of votes agreeing on the action reaches a certain threshold (for example, 1/2 or 2/3 or the like).
Multiple signatures refer to multiple parties 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 manifestation is 1/1; the expression form of the multiple signature is m/n, m is smaller than n, that is, an account address is associated with a total of n private keys, and when not less than m private keys simultaneously sign a transaction sent out by the account, the transaction is considered to be legally authorized. The principle is also in fact to indicate that the transaction is to be performed when the m/n custodian node agrees.
The implementation of the above-described intra-group authorization authentication is explained from an actual physical level. In a specific implementation, each custodian node within each custodian group may be installed with a escrow service program to interact with each other in communication through the escrow service program to implement the mechanism of electronic voting or multiple signatures; correspondingly, the authorization authentication module is realized by interaction cooperation among managed service programs operated by all custodian nodes in the corresponding custodian group.
In some examples, the respective custodian nodes within each set of custodian nodes may also be implemented by a hosted service program running to receive tasks assigned corresponding to asset hosting or operation, and communicate with each other to complete the in-set authorization authentication when the assigned tasks need to cooperate with other members of the same set of custodian nodes.
For an illustrative description of the relationship between the above-described set of structured safeguards and the safekeeper node, reference is made to FIG. 3.
Each of the storage groups 30 may include a plurality of storage nodes 31, and each of the storage nodes 30 may belong to a plurality of storage groups 30 at the same time, for example, storage groups 1 to 3 are shown as pairs of storage nodes 1 to 4 in fig. 3, wherein storage nodes 1 to 3 are shown in storage group 1, storage nodes 1, 3 and 4 are shown in storage group 2, and storage nodes 2 and 4 are shown in storage group 3.
Since each custodian node may belong to multiple different custody groups 30 at the same time, it is possible that members of one custody group 30 may actually have authority to operate assets stored by multiple different custody groups 30, only by requiring them to pass intra-group authorization authentication of the corresponding custody group 30.
Optionally, each custodian node 31 in the custody group 30 hosting an asset to be hosted provides a deposit that vouches for the security of the asset to be hosted. Each of the plurality of security groups 30 implemented in an overlapping grouping manner is adopted, and each of the plurality of security groups 30 independently manages the operation authority of the property in the plurality of security groups, and the overlapping grouping manner makes the custodian unable to obtain benefits from disfigurement, thereby ensuring the security of the hosting service from the perspective of game theory. By adopting overlapped groups (one custodian node 31 can belong to a plurality of custodian groups 30 at the same time) instead of common parallel groups (each custodian node 31 only belongs to one custodian group 30), the total deposit amount required for ensuring safety can be reduced under the condition that potential attackers can only control a few custodians, excessive mortgages in the prior art are not required, and the use efficiency of funds is improved; because when the number of custodian nodes controlled by an attacker is below a certain proportion, the proportion of packets that these custodian nodes can actually control in all custodian packets will be much lower than the proportion of custodian nodes that are controlled in all custodian nodes. Further optionally, the deposit may be an asset that is kept and/or homogenous with the hosted asset to eliminate secondary hosting in the prior art and improve hosting efficiency.
The following is a specific example of an actual implementation to demonstrate the advantages of the stackable grouping approach. In some examples, the stackable grouping includes, but is not limited to, any one of symmetrical grouping, polynomial-over-prime grouping, random grouping, and the like.
The overlapping grouping scheme is illustrated based on the principle of a symmetrical grouping implementation that implements groups of k persons each based on the same number of n custodians. In this grouping method, the total number of custodian (also the number of custodian nodes) n is 20, and the number of persons k in each group is 6, at most, the constitution can be madeA plurality of storage tubes. And, if the group authorization certification within each group of safeguards is designed such that a minimum of 4 safeguards agree to operate the safeguarded asset, the entire asset hosting system can safely host up to 16 times the value of the deposit total if no more than 5 people are malicious safeguards (i.e., no more than 1/4 of n are occupied).
In a specific example of calculation, n=20, k=6, assuming that the deposit number per custodian is 100 yuan, the total deposit number is 2000 yuan. On the premise that the malicious custodian is 5 persons, the malicious custodian can steal the property of 540 custody groups at most, so that the total safe custody foreign asset value is not less than 5 x 100/540 x 38760-2000>35800 yuan and exceeds 16 times of the total deposit (2000 yuan).
Wherein, about property that can steal 540 guarantor groups at most, calculate as follows: if the malicious custodian is 5 people, the property of 540 custodian groups can be stolen at most, and the calculation mode is as follows: in one case, if all 5 malicious custodians are in one group, each custodian includes the 5 malicious custodians and another normal custodian, and 15 normal custodians exist, so that 15 custodians can be controlled at most; in another case, if 4 malicious custodians areOne group will haveThe cases are 15 x 14/2-! The other two normal custodians are selected in 105 ways to form a set of custody; thus, a maximum of 15+5 x 105 = 540 packets will be controlled by malicious custodians to steal property. If the number of malicious custodians in one set is smaller (e.g., 3,2, 1), then no more than half of the set may be controlled.
Illustrating the principle that the stackable grouping is implemented on the basis of a grouping based on polynomials over prime fields, also called prime numbers, which refer to fields that do not contain true subfields, also called minimum fields. For example, a rational number field, is encompassed by any number field, i.e., the rational number field is the smallest number field, which no longer contains any true sub-fields, then it is the prime field.
For a certain prime number k, setIs->N=k in (b) 2 Each element (a, b) corresponds to a custodian. The grouping scheme is as follows:
wherein for each polynomial p, the custody group corresponding to p is defined as A p = { (0, p (0)), (1, p (1)), …, (k-1, p (k-1)) } for a total of k custodians. It is apparent from the algebraic basic theorem that the size of the intersection of any two different groups of memory in the grouping is not more than d-1.
In this grouping method, the total custodian number n is set to 121, the number k of persons in each group is set to 11, and the minimum custodian number required for operating the stored asset is set to 8; when d is 5, the system can obtain the assets with the deposit total value more than 9 times of the value safely managed by the system through calculation under the condition that the malicious custodian does not exceed 33 persons (the proportion does not exceed 3/11 of n).
A specific calculation example is as follows, n=121, k=11, assuming that the deposit number of each custodian is 100 yuan, the total deposit number is 12100 yuan. On the premise that the malicious custodian is 33 persons, the property that can steal not more than 4390 custodian groups can be calculated. So the total safe escrowed foreign asset value is not less than 33 x 100/4390 x 11 5 -12100>108900 elements, more than 9 times the total deposit (12100 elements).
On the premise that the malicious custodian is 33 persons, the method can steal the property of not more than 4390 custodian groups at most, and is calculated as follows: total number of all custody packets is 11 5 So 4390 groups of tubes only occupy 4390/11 5 <2.726％<3/110, about 1/10 of the ratio of malicious custodians to the total custodian population. So at this point, even if (deposit + hosted asset) reaches 10 times the deposit amount, the total amount of funds that 33 malicious hosts can control (3/110 of 10 times the deposit amount) does not exceed their own deposit amount (3/11 of the total deposit amount).
The principle that the stackable grouping is based on a random grouping implementation is illustrated. When a scheme capable of overlapping grouping is given, some custodians or custody groups can be uniformly and randomly extracted from the original custody groups divided by the scheme to form a new grouping scheme, and the number of the custody groups can be greatly reduced while the lower deposit rate is maintained.
Therefore, the asset hosting is performed through each group of the protecting groups realized in an overlapped 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 specifically hosting is described by way of example.
As shown in fig. 4, the process specifically includes:
s401: a user initiates a hosting request to a scheduling module;
S402: the scheduling module, when receiving a hosting request of a user, responds to the hosting request of the user, coordinates with each candidate custody group and determines a target custody group which specifically processes the hosting request, namely a corresponding custodian group scheduled by the target custody group. In fig. 4, the target custody group is exemplarily shown as custody group 1.
In a specific implementation, 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 group of protection pipes to execute the task of the hosting request; if multiple candidate retention nest, the multiple candidate retention nest may perform the task by consensus to determine one or more target retention nest therein.
In a specific example, the basis for determining the set of target retention tubes includes, but is not limited to: the value size of the asset to be hosted, the deposit value that the group of guaranties can provide, etc.
S403: the escrow account of the target group of escrow is fed back to the user for transfer into the asset to be escrow.
In some examples, the escrow account is, for example, an address in a blockchain system, such as a cash register address of each custodian node in a custody group; alternatively, the address may be a proxy address or the like.
S404: the user may deposit the asset to be hosted to the checkout address.
In some examples, the asset to be hosted may be stored in multiple portions separately at respective checkout addresses; alternatively, a cash register is deposited.
Optionally, after the escrow account receives the transferred money to be escrow, the target escrow group informs the scheduling module of correspondingly updating the account balance of the user.
Or as shown in fig. 5, an implementation process in which the asset hosting system specifically hosts 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, a scheduling module responds to the hosting request of the user, coordinates with each of the hosting groups and determines a target hosting group for specifically processing the hosting request; in fig. 5, the target custody group is exemplarily shown as custody group 1.
Step S503: transferring the asset to be hosted to a scheduling module by a user;
step S504: the scheduling module stores the assets to be hosted into the hosting accounts of the target group of the conservation tubes;
optionally, the scheduling module or custody group then presents the corresponding escrow credential to the user to prove escrow of the asset.
Alternatively, 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 first hosts the asset to be hosted to the scheduling module, e.g., to a designated account of the scheduling module. Where this example may be implemented where conditions allow, for example, the scheduling module is highly trusted, such as by an authority, trusted credentials endorsement, or the like.
Scheduling, by a scheduling module, one or more candidate groups of savers to perform the task of the escrow request; if multiple groups of retention tubes are scheduled, the multiple groups of retention tubes may determine one or more of the groups of retention tubes through consensus to perform the task, and the scheduling module forwards the asset to be hosted to a hosted account of the determined group of retention tubes.
In the above examples, the scheduling module, or a group of escrow that participates in escrow of the asset to be escrow, may present the user with corresponding escrow credentials to indicate that escrow is complete.
Alternatively, both the custodian node and the user in the custodian group performing custody may monitor changes in the hosted asset over time. For example, when user A has deposited asset B in the account of bank C, each of the custodian nodes in A, bank C may view the change in asset B in the account.
Similar to the escrow example principles described above, taking the example of operating on escrow assets as redemption, as shown in FIG. 6, a flow of the asset escrow system processing escrow asset redemption is presented. The redemption process specifically includes:
step S601: the user sends a redemption request to the dispatch module;
step S602: each escrow group dispatched by the dispatch module determines at least one target escrow group that handles the redemption request of the user.
In implementations, the target set of custody is not necessarily the set of custody that previously received the user's asset, i.e., the user's requests to deposit and redeem the escrow asset may be handled by a different custody set; in the blockchain block, the hosted transaction is recorded by all custodian nodes. In fig. 6, the target custody group is exemplarily shown as custody group 1.
Step S603: authorizing corresponding transactions by each safeguarder node in the determined target safeguarded group according to the redemption request, and carrying out intra-group authorization authentication on the authorized transactions by an authorization authentication module of the target safeguarded group;
in a specific example, all custodians in the designated set of custody generate corresponding transactions (e.g. "transfer a asset of amount x to y account") based on the redemption request, and effect the authorization in a signed manner for the transaction; the authorization authentication module gathers individual transaction signatures within the group for intra-group authorization authentication, e.g., upon receiving enough of the custodian signatures within the group (i.e., common authorization), indicates that the intra-group authorization authentication passed, the transaction party may take effect and the hosted asset is disposed of in a transaction-specific manner.
Step S604: if the in-group authorization authentication is passed, the escrow asset corresponding to the redemption request is transferred to the user's designated account.
In the example of FIG. 6, the hosted assets may be directly credited to 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 may then deposit the hosted assets into the user's designated account.
To enhance the security of the asset hosting system, further reducing the likelihood of custodians aversion; so in some examples, a penalty mechanism may be designed.
For example, when a problem protection group that does not complete a task corresponding to asset hosting or operation occurs, each of the custodian nodes determines whether the problem protection group is illegal and penalizes when determining the violation according to a preset rule and according to evidence proving that the problem protection group is illegal submitted by the presenter node and/or evidence proving that the problem protection group is not illegal submitted by the problem protection group.
The reporter node may be a user node of a user who carries out asset hosting, or may be each custodian node; optionally, for the problem protection group with violations, a part or all of the deposit of the problem protection group is deducted as a penalty.
For example, assuming that a particular set of safeguards is determined and assigned to handle a user's escrow/redemption request, but not completed within a reasonable time, such as not being transferred to the user's designated account as required when handling the redemption request, or not cooperating with other custodian nodes/sets of safeguards to update the set of safeguards as required by the asset escrow system, or failing to respond in time when selected as a candidate set of safeguards, etc., a set of safeguards may be determined to be problematic. For a problematic group of guaranties, participants (i.e., reporter nodes) in the intelligent hosting system may present evidence to govern the problematic group of guaranties and require punishment of members thereof, and the members of the controlled group of guaranties may also present evidence that they have not violated within a specified time. The asset hosting system can judge whether the violations occur according to the preset rules, if yes, punishment is carried out by partially or completely deducting the deposit of the offending participants, and the offending participants can be moved out when the grouping is updated next time. The deducted deposit may be used to make up for losses due to violations, and may also reward other participants, such as the reporter node, etc.
Since there may be changes in the custodian nodes, such as new custodian nodes being added, or the custodian nodes failing or changing, the grouping structure of the custodian group is not constant, but may change over time and custodian actions. In some examples, the plurality of custodian nodes are capable of implementing packet updates, thereby forming a new custody group; accordingly, the assets hosted in the original set of storage are also migrated in response to the new grouping result.
For example, some or all of the custodian nodes form one or more new sets of custody by way of an stackable grouping and transfer assets hosted by the original set of custody to the new set of custody. For example, in an example involving only a single storage group update, a 6-node storage group of nodes A-F stores assets W, A to be retired, and G to take over A, B-G may constitute a new storage group, G providing deposit corresponding to A, and old storage groups A-F transferring stored assets W to new storage groups B-G and fulfilling all functions of A in the old storage group by G in the new storage group.
As shown in fig. 7, the asset management method in the embodiment of the present application is shown as applied to a custodian node, which may be, for example, the custodian node in the asset hosting system in the embodiment of fig. 1, but is not limited thereto. By means of an overlapping grouping, the custodian node may belong to a plurality of custodian groups at the same time, as exemplified in fig. 3. The technical features of the implementation of the asset management method may refer to the previous embodiments, and will not be repeated here.
The asset management method comprises the following steps:
step S701: the custodian node accepting tasks corresponding to user requests to host or assign to hosted assets; wherein the custodian node belongs to at least one custodian group that is scheduled in response to the user request.
Alternatively, 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 commonly determines a custodian group for accepting the 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 the custodian group to accomplish the task.
Optionally, the custodian node performs intra-group authorization authentication with other custodian nodes in the same custodian group.
Optionally, the collaboration includes at least one of: when the task corresponds to the asset to be hosted, the custodian node and other custodian nodes in the same custodian group jointly custodian the asset to be hosted or part thereof; alternatively, when the task corresponds to redemption of a hosted asset, the custodian node performs an intra-group authorization authentication with the other custodian, and obtains permission to operate the asset hosted by the custodian group if the intra-group authorization authentication passes.
Optionally, the intra-group authorization authentication is realized through consensus among all custodian nodes in the custodian group. Such as electronic voting, multiple signatures, etc.
As shown in fig. 8, a schematic circuit structure of a protector node in an embodiment of the present application is shown.
In an implementation, the custodian node may be implemented in a server/server group, a tablet, a smart phone, a desktop, a notebook, a smart watch, a smart glasses, or a distributed system formed by a plurality of communication connections in one or more of them, for use as the custodian node in any of the implementations of fig. 1-7.
The custodian node 800 in this embodiment includes:
one or more network communicators 801 for use in connection with the present invention. 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 includes, for example, wiFi, 2G/3G/4G/5G communication modules, and the like.
One or more memories 802 for storing at least one computer program. Illustratively, the one or more memories 802 may 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 separate from but connected to the at least one processor, such as network-attached memory accessed via RF circuitry or external ports and a communication network, which may be the internet, at least one intranet, a local area network, a wide area network, a storage area network, etc., or suitable combinations thereof. The memory controller may control access to 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 are configured to execute the at least one computer program to perform functions of, for example, the custodian node of fig. 1, and to perform steps in an asset management method performed by, for example, the custodian node of 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 for, when executed, causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of a method as described in various embodiments of the present application.
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 hard 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. In addition, 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 be directed to non-transitory, tangible storage media. Disk and disc, as used herein, 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 by the computer program 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, these 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 a processor-executable software module, which may be located on a tangible, non-transitory computer storage medium. Tangible, non-transitory computer storage media can be any available media that can be accessed by a computer.
The flowcharts and block diagrams in the figures described above 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.
In summary, the asset hosting system, the asset management method, the node and the medium of the present application, the asset hosting system, includes: a plurality of custodian nodes forming a plurality of custodian groups by means of an stackable grouping; wherein, the overlapped 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 scheduling at least one target group of conservation to host the asset to be hosted or operating the hosted asset in response to the user request. Compared with the existing deposit-based decentralization escrow scheme, the method can remarkably reduce the demand for deposit amount, greatly improve the fund use efficiency, prevent the loss caused by combined disuse of a small number of custodians from exceeding the total amount of deposit, and ensure the safety of the escrowed funds by taking a small amount of deposit as a guarantee; the asset hosting system can be implemented in an decentralized system, and the defect that the safety of the centralized system is completely dependent on a centralized entity is overcome.
The foregoing embodiments are merely illustrative of the principles of the present application and their effectiveness, and are not intended to limit the application. Modifications and variations may be made to the above-described embodiments by those of ordinary skill in the art without departing from the spirit and scope of the present application. Accordingly, it is intended that all equivalent modifications and variations which may be accomplished by persons skilled in the art without departing from the spirit and technical spirit of the disclosure be covered by the claims of this application.
Claims (16)
1. An asset hosting system, comprising:
a plurality of custodian nodes forming a plurality of custodian groups by means of an stackable grouping; wherein, the overlapped grouping mode means that each custodian node can belong to a plurality of custodian groups at the same time;
the scheduling module is used for responding to the user request and scheduling at least one target group of conservation to host the asset to be hosted or operate the hosted asset; the target storage group is determined by the consensus of each candidate storage group interacted by the scheduling module; each custodian node in each custodian group performs intra-group authorization authentication through an authorization authentication module of the corresponding custodian group, and obtains the authority to operate the part of the hosted asset hosted by the custodian group under the condition that the intra-group authorization authentication passes; the schedule target group of savers operates on hosted assets, including:
each candidate escrow group interacted by the dispatch module determines at least one target escrow group that processes the redemption request of the user;
authorizing corresponding transactions by each custodian node in the determined target custodian group according to the redemption request, and carrying out intra-group authorization authentication on the authorized transactions through an authorization authentication module of the target custodian group;
If the in-group authorization authentication is passed, the escrow asset corresponding to the redemption request is transferred to the user's designated account.
2. The asset hosting system of claim 1, wherein the scheduling module is implemented by a smart contract.
3. The asset hosting system of claim 1, wherein the stackable grouping comprises: any one of symmetric grouping, polynomial grouping over a prime field, and random grouping.
4. The asset hosting system of claim 1, wherein the intra-group authorization authentication is achieved through a consensus among the custodian nodes in the custodian group.
5. The asset hosting system of claim 4, wherein the means for intra-group authorization authentication comprises: electronic voting or multiple signatures.
6. The asset hosting system of any of claims 3-5, wherein the authorization authentication module is implemented by interactive collaboration between hosted services run by respective custodian nodes within a corresponding set of custodian.
7. The asset hosting system of claim 1, wherein the scheduling target set of retailers hosts assets to be hosted, comprising at least one of:
1) The scheduling module feeds back the escrow account of the target group of conservation to the user for transferring to the asset to be escrow;
2) The scheduling module receives the user's assets to be hosted and transfers to a hosted account of the target group of healthcare facilities.
8. The asset hosting system of claim 1, wherein when a problem bank that does not complete a task corresponding to asset hosting or operation occurs, each of the custodian nodes determines whether the problem bank is offending and penalizes in determining the offending according to a preset rule and based on evidence that the problem bank is offending submitted by the presenter node and/or evidence that the problem bank is not offending submitted by the problem bank.
9. An asset hosting system as claimed in claim 1 or claim 8, wherein each custodian node in a set of custodian assets hosting an asset to be hosted provides a deposit that is safe for the asset to be hosted, the deposit being an asset that is stored and/or homogenous with the asset being hosted.
10. The asset hosting system of claim 9, wherein for a problem bank where a violation occurs, a deposit of part or all of the problem bank is deducted as a penalty.
11. The asset hosting system of claim 1, wherein the plurality of custodian nodes are further configured to implement a group update, comprising: and forming one or more new storage groups by some or all of the storage nodes in an overlapped grouping mode, and transferring the assets hosted by the original storage groups to the new storage groups.
12. An asset management method for the asset hosting system of claim 1, characterized by being applied to a custodian node, the custodian node belonging to a plurality of custodian groups; the asset management method comprises the following steps:
the custodian node accepting tasks corresponding to user requests to host or assign to hosted assets; wherein the custodian node belongs to at least one custodian group that is scheduled in response to the user request;
the custodian node cooperates with other custodian nodes in the custodian group to accomplish the task.
13. The asset management method of claim 12, wherein the collaboration comprises at least one of: when the task corresponds to the asset to be hosted, the custodian node and other custodian nodes in the same custodian group jointly custodian the asset to be hosted or part thereof; alternatively, when the task corresponds to redemption of a hosted asset, the custodian node performs an intra-group authorization authentication with the other custodian, and obtains permission to operate the asset hosted by the custodian group if the intra-group authorization authentication passes.
14. The asset management method of claim 13, wherein the intra-group authorization authentication is achieved by a respective custodian node consensus in a set of custodian nodes.
15. 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 12-14.
16. A computer storage medium, characterized in that at least one computer program is stored, which computer program, when run, performs the asset management method according to any of claims 12 to 14.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011309942.XA CN112419060B (en) | 2020-11-20 | 2020-11-20 | Asset hosting system, asset management method, node and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011309942.XA CN112419060B (en) | 2020-11-20 | 2020-11-20 | Asset hosting system, asset management method, node and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112419060A CN112419060A (en) | 2021-02-26 |
| CN112419060B true CN112419060B (en) | 2024-03-22 |
Family
ID=74774484
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011309942.XA Active CN112419060B (en) | 2020-11-20 | 2020-11-20 | Asset hosting system, asset management method, node and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112419060B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114172661B (en) * | 2021-12-03 | 2023-12-08 | 杭州链网科技有限公司 | Bidirectional cross-link method, system and device for digital asset |
Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109308658A (en) * | 2018-09-11 | 2019-02-05 | 北京永恒纪元科技有限公司 | A kind of decentralization assets trustship clearance plateform system of highly effective and safe |
| CN109919771A (en) * | 2019-03-18 | 2019-06-21 | 徐雪松 | A kind of hierarchical block chain network and method of commerce applied to industry internet |
| CN109995850A (en) * | 2019-03-05 | 2019-07-09 | 深圳前海微众银行股份有限公司 | A kind of transaction processing method of block catenary system and block catenary system |
| CN110035059A (en) * | 2019-03-05 | 2019-07-19 | 深圳前海微众银行股份有限公司 | A kind of building of block chain and group partition method and device |
| CN110084597A (en) * | 2019-04-22 | 2019-08-02 | 北京永恒纪元科技有限公司 | A kind of account safety system and its operation method of novel decentralization hosted platform |
| TW201935299A (en) * | 2018-02-12 | 2019-09-01 | 林俊良 | Blockchain system, node server and method for processing strategy model scripts of financial assets |
| CN110494875A (en) * | 2017-04-11 | 2019-11-22 | 区块链控股有限公司 | The safety of private key for dynamic node group reuses |
| CN110517027A (en) * | 2019-08-22 | 2019-11-29 | 华东师范大学 | A kind of trustship of digital cash assets and transfer method based on intelligent contract |
| CN110706114A (en) * | 2019-09-05 | 2020-01-17 | 阿里巴巴集团控股有限公司 | Block chain-based default asset processing method and device and electronic equipment |
| WO2020056601A1 (en) * | 2018-09-18 | 2020-03-26 | 王健 | Asset custody method, storage medium, blockchain system, and blockchain node |
| CN111639998A (en) * | 2020-04-09 | 2020-09-08 | 山东浪潮质量链科技有限公司 | Method, device and medium for guaranteeing user deposit rights and interests based on block chain |
| CN111738844A (en) * | 2020-07-17 | 2020-10-02 | 浙江网商银行股份有限公司 | Resource allocation system, method and device based on block chain |
| CN111798234A (en) * | 2020-06-03 | 2020-10-20 | 中国科学院信息工程研究所 | Lightweight block chain system and construction method |
-
2020
- 2020-11-20 CN CN202011309942.XA patent/CN112419060B/en active Active
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110494875A (en) * | 2017-04-11 | 2019-11-22 | 区块链控股有限公司 | The safety of private key for dynamic node group reuses |
| TW201935299A (en) * | 2018-02-12 | 2019-09-01 | 林俊良 | Blockchain system, node server and method for processing strategy model scripts of financial assets |
| CN109308658A (en) * | 2018-09-11 | 2019-02-05 | 北京永恒纪元科技有限公司 | A kind of decentralization assets trustship clearance plateform system of highly effective and safe |
| WO2020056601A1 (en) * | 2018-09-18 | 2020-03-26 | 王健 | Asset custody method, storage medium, blockchain system, and blockchain node |
| CN111213170A (en) * | 2018-09-18 | 2020-05-29 | 王健 | Asset hosting method, storage medium, blockchain system, and blockchain node |
| CN110035059A (en) * | 2019-03-05 | 2019-07-19 | 深圳前海微众银行股份有限公司 | A kind of building of block chain and group partition method and device |
| CN109995850A (en) * | 2019-03-05 | 2019-07-09 | 深圳前海微众银行股份有限公司 | A kind of transaction processing method of block catenary system and block catenary system |
| CN109919771A (en) * | 2019-03-18 | 2019-06-21 | 徐雪松 | A kind of hierarchical block chain network and method of commerce applied to industry internet |
| CN110084597A (en) * | 2019-04-22 | 2019-08-02 | 北京永恒纪元科技有限公司 | A kind of account safety system and its operation method of novel decentralization hosted platform |
| CN110517027A (en) * | 2019-08-22 | 2019-11-29 | 华东师范大学 | A kind of trustship of digital cash assets and transfer method based on intelligent contract |
| CN110706114A (en) * | 2019-09-05 | 2020-01-17 | 阿里巴巴集团控股有限公司 | Block chain-based default asset processing method and device and electronic equipment |
| CN111639998A (en) * | 2020-04-09 | 2020-09-08 | 山东浪潮质量链科技有限公司 | Method, device and medium for guaranteeing user deposit rights and interests based on block chain |
| CN111798234A (en) * | 2020-06-03 | 2020-10-20 | 中国科学院信息工程研究所 | Lightweight block chain system and construction method |
| CN111738844A (en) * | 2020-07-17 | 2020-10-02 | 浙江网商银行股份有限公司 | Resource allocation system, method and device based on block chain |
Non-Patent Citations (1)
| Title |
|---|
| 区块链技术下托管结算业务的应用探析;查海峰;;黑龙江工业学院学报(综合版);20200520(第05期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112419060A (en) | 2021-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11250518B2 (en) | Method for secure ledger distribution and computer system using secure distributed ledger technology | |
| US20220277307A1 (en) | Systems and methods for personal identification and verification | |
| Niranjanamurthy et al. | Analysis of Blockchain technology: pros, cons and SWOT | |
| Zamani et al. | On the security risks of the blockchain | |
| CN109089428B (en) | Zero custody transfer of digital assets | |
| CN110383311A (en) | Supervise the transaction of block chain secret | |
| CN101652793A (en) | Electronic money system and electronic money trading method | |
| KR20220093198A (en) | Execution of transactions using dedicated and open blockchains | |
| WO2019170814A1 (en) | Data transaction system and method | |
| US20210398112A1 (en) | Computer-Implemented Method and System for Digital Signing of Transactions | |
| JP2022525551A (en) | Preventing erroneous transmission of copies of data records to distributed ledger systems | |
| Yu et al. | Technology and security analysis of cryptocurrency based on blockchain | |
| Pawar et al. | ParallelChain: a scalable healthcare framework with low‐energy consumption using blockchain | |
| CN112419060B (en) | Asset hosting system, asset management method, node and medium | |
| Al-Zubaidie et al. | Transaction Security and Management of Blockchain-Based Smart Contracts in E-Banking-Employing Microsegmentation and Yellow Saddle Goatfish | |
| Huang et al. | zkChain: A privacy‐preserving model based on zk‐SNARKs and hash chain for efficient transfer of assets | |
| Suga et al. | Securing cryptocurrency exchange: building up standard from huge failures | |
| Kabiri et al. | Blockchain and smart contracts | |
| JP2020046975A (en) | Fund transfer system and method for virtual currency | |
| Haga et al. | IoT‐Based Autonomous Pay‐As‐You‐Go Payment System with the Contract Wallet | |
| Kuebler | Application of Blockchain for Authentication, Verification of Identity and Cloud Computing | |
| US20240257085A1 (en) | Token Account Payment Computing System | |
| Savchenko et al. | Decision Support Systems’ Security Model Based on Decentralized Data Platforms | |
| US20240185228A1 (en) | Multilayer system and method for securing a blockchain-based token using random temporal windowing | |
| US20240257243A1 (en) | A system and method for trading cryptocurrencies, tokenized assets and/or fiat currencies on a single distributed ledger system with multiple issuing institutions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |