Block chain contract-based account level-to-level management system and method, and terminal

Abstract

The invention provides an account level-to-level management system and method based on a block chain contract, and a terminal. The level-to-level management system comprises an account level-to-level model building module which is used for building an account level-to-level model corresponding to a target block chain; wherein the account grading model is composed of nodes bound with accounts on a target block chain; the private key distribution module is connected with the account grading model construction module and is used for distributing a corresponding hierarchical private key for the account grading model; the decision module is connected with the account grading model construction module and is used for performing account management on the account grading model; and a contract execution module connected with the account grading model construction module and used for executing an intelligent contract pre-deployed on the target block chain based on the account grading model and the hierarchical private key. According to the system, while the advantages of the block chain are maintained, hierarchical management of accounts on the block chain is realized, and hierarchical management requirements in a specific scene are met.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to an account hierarchical management system, method and terminal based on blockchain contracts. Background Art

[0002] The account structure in blockchain technology is different from traditional hierarchical or graded account management systems. In blockchain, accounts are parallel, meaning that each account is equal in terms of permissions and access levels, and there is no inherent hierarchical structure. In addition, blockchain accounts are usually identified by public key addresses, which are anonymous and not directly associated with the user's real identity, so they cannot directly represent the membership of a group or circle. The consensus mechanism in the blockchain network ensures the consistency and immutability of all transactions, but these mechanisms do not support differentiated processing based on groups or circles.

[0003] However, in some specific business scenarios, accounts need to be managed in a hierarchical manner to meet specific business needs, security requirements or compliance standards. Summary of the invention

[0004] In view of the shortcomings of the prior art described above, the purpose of the present application is to provide an account hierarchical management system, method and terminal based on blockchain contracts, so as to solve the problem that blockchain accounts in the prior art do not support hierarchical management.

[0005] To achieve the above-mentioned purpose and other related purposes, the first aspect of the present application provides an account hierarchical management system based on blockchain contracts, including: an account hierarchical model construction module, used to establish an account hierarchical model corresponding to a target blockchain; wherein the account hierarchical model is composed of nodes bound to each account on the target blockchain; a private key allocation module, connected to the account hierarchical model construction module, used to allocate corresponding hierarchical private keys to the account hierarchical model; a decision module, connected to the account hierarchical model construction module, used to perform account management on the account hierarchical model; a contract execution module, connected to the account hierarchical model construction module, used to execute smart contracts pre-deployed on the target blockchain based on the account hierarchical model and the hierarchical private keys.

[0006] In some embodiments of the first aspect of the present application, the account hierarchical model adopts a tree structure; wherein the tree structure is composed of multiple tree nodes each bound to an account; the types of tree nodes include root nodes, branch nodes, and leaf nodes; and wherein the parent node of all branch nodes is the root node, and the parent node of one or more leaf nodes is a branch node; each tree node has node information, including: node status and parent node index.

[0007] In some embodiments of the first aspect of the present application, the hierarchical private keys include: a root private key assigned to a root node, a branch private key assigned to a branch node, and a leaf private key assigned to a leaf node.

[0008] In some embodiments of the first aspect of the present application, according to the smart contract on the target blockchain, one or more corresponding groups are formed by the root node or branch node of the corresponding account hierarchical model.

[0009] In some embodiments of the first aspect of the present application, the root node is also used to manage the node status, life cycle and corresponding groups of all branch nodes; the branch node is also used to manage the node status, life cycle and corresponding groups of its child nodes.

[0010] In some embodiments of the first aspect of the present application, the contract execution module includes: a contract authentication submodule, which is used to respond to the verification request of the smart contract of the target blockchain, perform permission verification on the account hierarchical model of the target blockchain according to the permission rule contract in the smart contract, and obtain the permission verification result; an execution submodule, which is used to execute the smart contract according to the permission verification result and based on the hierarchical private key.

[0011] In some embodiments of the first aspect of the present application, the specific process of performing account management on the account grading model includes: upon receiving an account management decision request, performing a consensus vote on the account management decision request; when the result of the consensus vote meets the decision passing condition, performing account management corresponding to the account management decision request on the account grading model.

[0012] In some embodiments of the first aspect of the present application, the system allows the contract account to become a branch node to perform new node derivation, dynamic modification of permission rule contracts, and child node management.

[0013] To achieve the above-mentioned purpose and other related purposes, the second aspect of the present application provides an account hierarchical management method based on blockchain contracts, including: establishing a hierarchical management model corresponding to the target blockchain; wherein the hierarchical management model is composed of nodes bound to each contract account on the target blockchain; assigning a corresponding hierarchical private key to the hierarchical management model; and executing the smart contract on the target blockchain based on the hierarchical management model and the hierarchical private key.

[0014] To achieve the above-mentioned purpose and other related purposes, the third aspect of the present application provides an electronic terminal, including a memory, a processor and a computer program stored in the memory; the processor executes the computer program to implement the account hierarchical management method based on the blockchain contract.

[0015] As described above, the account hierarchical management system, method and terminal based on blockchain contracts of the present application have the following beneficial effects:

[0016] The system of the present application realizes hierarchical management of accounts on the blockchain while maintaining the advantages of the blockchain, meeting the hierarchical management needs in specific scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Shown is a schematic block diagram of an account hierarchical management system based on blockchain contracts in one embodiment of the present application.

[0018] Figure 2 Shown is a structural diagram of an account grading model in one embodiment of the present application.

[0019] Figure 3 Shown is a schematic diagram of the process of contract execution in a specific embodiment of the present application.

[0020] Figure 4 Shown is a schematic diagram of a contract account module in a specific embodiment of the present application.

[0021] Figure 5 Shown is a schematic diagram of a method for distributing private keys for multiple blockchains in one embodiment of the present application.

[0022] Figure 6 Shown is a schematic diagram of a method for distributing private keys for multiple blockchains in another embodiment of the present application.

[0023] Figure 7 Shown is a flowchart of an account hierarchical management method based on blockchain contracts in one embodiment of the present application.

[0024] Figure 8 Shown is a schematic diagram of the structure of an electronic terminal in one embodiment of the present application. DETAILED DESCRIPTION

[0025] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0026] In the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit the difference.

[0027] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" represent examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0028] In the embodiments of the present application, "at least one" refers to one or more, and "plurality" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can represent: a, b, c, ab, ac, bc or abc, where a, b, c can be single or multiple.

[0029] To facilitate understanding of the embodiments of the present application, first Figure 1 Detailed description. Figure 1 A schematic block diagram of an account hierarchical management system based on blockchain contracts in an embodiment of the present invention is shown. The hierarchical management system 1 based on blockchain contract accounts in this embodiment includes:

[0030] An account grading model building module 11 is used to establish an account grading model corresponding to the target blockchain; wherein the account grading model is composed of nodes bound to each account on the target blockchain;

[0031] The private key distribution module 12 is connected to the account grading model construction module 11 and is used to distribute the corresponding hierarchical private keys to the account grading model;

[0032] The decision module 13 is connected to the account grading model building module 11 and is used to perform account management on the account grading model;

[0033] The contract execution module 14 is connected to the account hierarchical model construction module 11, and is used to execute the smart contract pre-deployed on the target blockchain based on the account hierarchical model and the hierarchical private key.

[0034] It should be understood that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional module in each embodiment of the present application may be integrated into a processor, or may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0035] In one embodiment, the account hierarchical model adopts a tree structure; wherein the tree structure is composed of a plurality of tree nodes each bound to an account; the types of tree nodes include root nodes, branch nodes, and leaf nodes; and wherein the parent node of all branch nodes is the root node, and the parent node of one or more leaf nodes is a branch node; each tree node has node information, including: node status and parent node index. It should be noted that the child node of the root node is a branch node, and the child node of the branch node is a leaf node.

[0036] In one embodiment, the index of each tree node is set to the account address of the corresponding account on the target blockchain to achieve the binding of the tree node with the account.

[0037] In one embodiment, the node state of each tree node is an available state or an unavailable state; the parent node index of each tree node is the account address of the account bound to the parent node of the tree node.

[0038] In one embodiment, the private key distribution module is a HIBE tool. It should be understood that the HIBE tool is an off-chain cryptographic tool based on the Hierarchical Identity-Based Encryption (HIBE) algorithm. According to the initial private key, it is derived layer by layer through a given path to form a series of child private keys. Since the path naturally contains a tree-like hierarchical structure, it is suitable for some hierarchical identity authority management scenarios.

[0039] In a preferred embodiment, both the target blockchain and the HIBE module can adopt a lattice-based encryption algorithm, such as the NTRU algorithm, to ensure quantum resistance.

[0040] In one embodiment, the hierarchical private key includes: a root private key for assigning to a root node, a branch private key for assigning to a branch node, and a leaf private key for assigning to a leaf node. It should be noted that when restoring identity information from a private key, the user of the account is completely anonymous and will not disclose identity information. When the private key of an account is derived through the HIBE tool, the derivation path can be directly restored through the tool. The derivation path contains hierarchical identity information, thereby realizing off-chain encrypted identity authentication. And the on-chain account corresponding to the private key can directly query the node type to realize on-chain encrypted identity authentication. Both of the above methods are encapsulated into an API form. The former requires the user to provide a private key, which is suitable for personal identity verification scenarios; the latter uses the user's private key to sign transactions, without the user directly providing a private key, which is suitable for three-party identity authentication login scenarios. In addition, the hierarchical management system only uses private keys, which greatly reduces the risk of privacy data leakage.

[0041] In one embodiment, if Figure 2 As shown, the decision module can control the HIBE tool to generate a root private key.

[0042] The following will be combined with the attached Figure 2 The process of building the account hierarchical model and the process of allocating hierarchical private keys are described in detail:

[0043] There are multiple accounts registered on the target blockchain. The decision module controls the HIBE tool to randomly generate a root private key and use the root private key to sign transactions. Create a root node in the account hierarchical model, bind the root node to the corresponding account on the target blockchain, and assign the generated root private key to the root node.

[0044] Furthermore, one or more branch nodes under the root node are created in the account hierarchical model, and each created branch node is bound to the corresponding account on the target blockchain one by one. The decision module controls the HIBE tool to derive one or more branch private keys from the root private key and assign them to one or more branch nodes under the root node. It should be noted that one branch node is assigned one branch private key.

[0045] Furthermore, for each branch node, one or more leaf nodes under the branch node are created in the account grading module, and each created leaf node is bound to the corresponding account on the target blockchain one by one, and then one or more leaf private keys derived from the branch private key assigned to the branch node are correspondingly assigned to one or more leaf nodes under the branch node. It should be noted that one leaf node is assigned one leaf private key. The created tree node can create its own subordinate nodes and assign the derived private keys to these subordinate nodes, and so on, forming a tree structure that expands downward layer by layer.

[0046] It should be noted that in the account hierarchy structure, the leaf node is located at the very end of the tree structure and is the last level of the tree structure. The specification parameters of the account grading model can be set by consensus voting of the decision module. The specification parameters include tree depth (number of layers), tree width (number of child nodes) and maximum node validity. The number of layers of branch nodes can be multiple layers, which is not limited by the present invention, but it is recommended not to exceed 10 layers. The account grading model maps the account address index to the tree node, and the tree node information contains the node type, which can support multi-role access control, and because of the implied hierarchical semantics, multi-level access control can be implemented. This model simplifies permission management and improves the security and maintainability of the system.

[0047] In one embodiment, the derivation path of the hierarchical private key may be encrypted to improve data security.

[0048] In one embodiment, if Figures 2 to 6 As shown, according to the smart contract on the target blockchain, one or more corresponding groups are formed by the root node or branch node of the corresponding account hierarchical model.

[0049] Specifically, a branch node or a root node can form one or more corresponding groups as an initiator according to the specific business implemented by the smart contract on the target blockchain. The group can carry out some of the business in the smart contract. When a branch node forms a group as an initiator, the group contains one or more leaf nodes under the branch node; when the root node forms a group as an initiator, the group contains one or more tree nodes under the root node.

[0050] In one embodiment, the root node is also used to manage the node status, life cycle and corresponding groups of all branch nodes; the branch node is also used to manage the node status, life cycle and corresponding groups of its child nodes.

[0051] Specifically, Figures 2 to 6As shown, when a tree node is a leaf node, the parent node of the tree node is the parent node (branch node) of the tree node; when a tree node is a branch node, the parent node of the tree node is the parent node (root node) of the tree node. Node state management is to set the node state of the tree node to an available state or an unavailable state. Life cycle management includes node validity period management and life cycle number management. Validity period management includes: setting of validity period and renewal of period. The validity period is used to limit the validity of the tree node. When a tree node exceeds the validity period, the tree node is deemed expired and the tree node cannot be used normally. When the tree node is renewed by the parent node, the tree node can be used normally. The life cycle number of the tree node is a value set by the parent node to facilitate the parent node to manage and maintain the version of the tree node. Group management mainly includes cross-group communication management. For example, two tree nodes are respectively formed as initiators to form two groups. When the child nodes of these two tree nodes need to complete a task together, after the two tree nodes agree, the child nodes of these two tree nodes can jointly process the task.

[0052] In one embodiment, when creating a child node of a tree node, the tree node pre-sets the validity period and life cycle number of the child node, and then the tree node can update the validity period and life cycle number of the child node.

[0053] In one embodiment, the contract execution module includes: a contract authentication submodule, which is used to respond to the verification request of the smart contract of the target blockchain, perform permission verification on the account hierarchical model of the target blockchain according to the permission rule contract in the smart contract, and obtain the permission verification result; an execution submodule, which is used to execute the smart contract according to the permission verification result and based on the hierarchical private key.

[0054] Specifically, the smart contract of the target blockchain defines a permission rule contract, in which multiple permission rules are defined, and each permission rule is assigned a unique rule ID. For example, Figure 3As shown, the rule "User 1 must be a leaf node" is defined in smart contract A, and the ID of this rule is 0x1234. For another example, the school members are abstracted into an account hierarchical model, the root node is the principal, the branch node is the teacher, and the leaf node is the student. The smart contract is a teacher-student mutual evaluation and scoring contract, which contains two sub-contracts. Sub-contract A is for students to score teachers, and the defined rules require that users are leaf nodes. Sub-contract B is for teachers to evaluate each other, and the defined rules require that two users are in the same group. The contract authentication sub-module should pass the rule ID and corresponding parameters of the rule specified by the smart contract to the permission rule contract in response to the verification request of the smart contract of the target blockchain. The permission rule contract will automatically initiate a corresponding query to the account hierarchical model of the target blockchain to obtain the corresponding permission verification result. The permission verification result is to meet the rules specified by the smart contract or not to meet the rules specified by the smart contract. When the rules specified by the smart contract are met, the execution sub-module executes the smart contract based on the hierarchical private key.

[0055] It should be noted that in the prior art, permission control based on smart contracts is implemented by maintaining a blacklist or a whitelist, for example, setting an administrator role for a contract. In this way, each business contract, or even each contract method, must maintain a chain account table, and permissions need to be configured frequently by manually updating the blacklist and whitelist, which has poor flexibility. In addition, this method only supports single-role semantics and can only deal with relatively simple permission control logic. With the increase in the scale of contracts and blacklists, the scale of the permission configuration matrix will also grow quadratically, and the complexity is relatively large. The present invention separates the role identity of the account from the contract permissions, reduces the complexity caused by the coupling of the two, and can also define more complex permissions more flexibly. When there is a new smart contract, a new permission rule contract can be configured, or an existing permission rule contract can be reused, reducing the configuration cost.

[0056] In one embodiment, the specific process of performing account management on the account grading model includes: when receiving an account management decision request, performing consensus voting on the account management decision request; when the result of the consensus voting meets the decision passing condition, performing account management corresponding to the account management decision request on the account grading model. Specifically, the account management decision request generally comes from the account grading model.

[0057] In one embodiment, the consensus voting of the decision-making module can be achieved in any of the following ways: the first one (applicable to consortium chains): forming governance decisions through the consensus algorithm between blockchain nodes; the second one (applicable to public chains): forming governance decisions through the rules of the on-chain governance committee contract (decentralized autonomous organization, DAO, distributed autonomous organization) (for example, implementing the logic of 2 / 3 approval through contract code).

[0058] In one embodiment, the types of account management decision requests include, but are not limited to: node deletion request (the account management corresponding to the account deletion request is to delete the corresponding node in the account hierarchical model), account hierarchical model specification parameter setting request (the account management corresponding to the account hierarchical model specification parameter setting request is to set the specification parameters of the account hierarchical model), node availability setting request (the account management corresponding to the node availability setting request is to set the availability of the corresponding node), node life cycle setting request (the account management corresponding to the node life cycle setting request is to set the life cycle of the corresponding node), node upgrade / downgrade request (the account management corresponding to the node upgrade / downgrade request is to upgrade / downgrade the corresponding node).

[0059] Specifically, the decision module is as follows: Figures 2 to 6 As shown, there are multiple decision accounts (12 are taken as an example in the figure, and each circle represents a decision account). When the decision module receives an account management decision request, each decision account in the decision module judges the account management decision request respectively, and then conducts consensus voting respectively, and the voting content is pass or fail. When the number of votes passed (i.e., the result of the consensus vote) meets the decision passing condition, the account management corresponding to the account management decision request is performed on the account grading model. For example, the decision passing condition can be set to obtain the voting results of two-thirds of the number of decision accounts.

[0060] In one embodiment, the decision module is further used to perform consensus voting on the decision account management request when receiving the decision account management request, and perform decision account management corresponding to the decision account management request when the result of the consensus voting meets the decision passing condition;

[0061] Specifically, the decision account management request can come from the decision account in the decision module or from the account hierarchical model. The decision account management request includes: a decision account addition request and a decision account deletion request; the decision account management corresponding to the decision account addition request is to add a decision account in the decision module. For example, a node in the account hierarchical model is added to the decision module to become a decision account in the decision module. The decision account management corresponding to the decision account deletion request is to delete the decision account in the decision module. It should be noted that the consensus voting in this embodiment is similar to the consensus voting in the above embodiment, and will not be repeated here.

[0062] In one embodiment, the decision module is also used to deploy smart contracts, mount contract accounts on non-leaf nodes, and upgrade contracts (update contract rules).

[0063] In one embodiment, if Figure 4As shown, the hierarchical management system allows contract accounts to become branch nodes to perform new node derivation, dynamic modification of permission rule contracts, and child node management. Specifically, in this embodiment, the smart contract has a node management contract, which is used for new node derivation, dynamic modification of permission rule contracts, and child node management. When the decision is made by the decision module, the node management contract can be deployed on the blockchain as a contract account (Contract Account, CA) mounted on a non-leaf node of the account hierarchical model to become a branch node. Figure 4 As shown, the node management contract can act as a parent node, create one or more child nodes (leaf nodes) and form one or more corresponding groups. The node management contract can manage the node status, life cycle and corresponding groups of the created child nodes. It should be noted that the node status, life cycle and group management have been described in the above embodiments and will not be repeated here. The node management contract can also modify the content of the permission rule contract in the smart contract of the target blockchain, so that some of the permission rule contracts that use the same permission rule id and input parameters return authentication failure. For example, Figure 4 As shown, the node management contract will Figure 3 The content of rule 0x1234 "User 1 must be a leaf node" shown in the example is changed to "User 1 must be a branch node". It should also be noted that since smart contracts can be automatically executed, automatic management of child nodes can be achieved. It should also be noted that the node management contract itself has logic rules that can be changed. When the decision is made through the decision module, the logic rules of the node management contract can be changed and upgraded.

[0064] For another example, the node management contract maintains a mapping table from blockchain account addresses to account points, calculates the corresponding contribution based on the on-chain and off-chain behaviors of the account, and updates the points to the table. When the points of the account meet the set points conditions, the business logic of the node management contract is triggered, specifically adding the account to the group managed by the node management contract to become a leaf node. When a node expires, the node management contract renews the account. When a dishonest behavior occurs off-chain in an account, points will be deducted. When the points are insufficient, the node management contract sets the node to an unavailable state, or the decision module deletes the node.

[0065] In one embodiment, there may be multiple target blockchains, and each blockchain corresponds to an account hierarchical management model. Each account hierarchical management model is managed by a decision module. This structure realizes account interaction and authority management on blockchains in different scenarios.

[0066] In one embodiment, when there are multiple target blockchains, the method of allocating hierarchical private keys may be any of the following:

[0067] The first type: Figure 5 As shown, the HIBE tool derives the same hierarchical private key, which is then distributed to each account hierarchical model, that is, one private key can map account addresses on multiple blockchains. The hierarchical private key distribution method has been described in the above embodiment and will not be repeated here.

[0068] The second type: Figure 6 As shown, the hierarchical private key generated by the HIBE tool is assigned to an account hierarchical model, and then a group of private keys is generated by the parallel KMS tool and assigned to an account hierarchical model, and the decision module binds the group of private keys to the hierarchical private keys one by one according to the hierarchical relationship. KMS (Key Management Service) usually refers to key management service, which is mainly used to generate, store, use and manage encryption keys to ensure the security and integrity of data.

[0069] In one embodiment, accounts on the target blockchain need to undergo real-name authentication based on KYC and AML risk control due diligence, such as personal real-name authentication, corporate real-name authentication, and CA authentication, and only accounts that have passed real-name authentication can perform on-chain operations.

[0070] In one embodiment, the hierarchical management system further includes a log module for recording the behavior of each account on and off the chain.

[0071] In one embodiment, the hierarchical management system based on blockchain contract accounts is also provided with a special query interface. The types of special query interfaces include but are not limited to HIBE supervision interface, decision module authority interface, KMS supervision interface, log query interface, chain query interface, etc.

[0072] In one embodiment, the decision module can also be used to specify incentive mechanisms based on governance needs. For example, the governance points smart contract can be deployed to incentivize each tree node in the hierarchical management model to exchange for certain rights and interests. For another example, it is stipulated that each round of decision-making is jointly participated by a fixed number of decision-making accounts and nodes in the hierarchical management model.

[0073] In one embodiment, the hierarchical management model can be combined with multi-signature technology to achieve more complex permission management scenarios. Specifically, multi-signature technology is usually completed off-chain, and signatures are aggregated through cryptographic algorithms, and multiple private keys are used offline to jointly sign a transaction. The hierarchical management model is used for on-chain governance, and multi-party participation in governance on the chain is achieved based on smart contracts.

[0074] For example, taking the neighborhood committee voting as an example, the neighborhood committee of a community can be regarded as a decision-making module. Every year, all owners of the community (owners are leaf nodes) are required to recommend an owner of the building as a candidate for the neighborhood committee by building (building group leader is a branch node), and then the neighborhood committee members vote together to select one of the candidates as a new member of the neighborhood committee. In the owner recommendation stage, off-chain multi-signature is used, that is, multiple owners’ signatures are aggregated, and then the signatures are parsed and judged on the chain to ensure that the signature subject comes from the same building; in the neighborhood committee voting stage, on-chain co-governance is adopted, that is, after collecting enough votes from neighborhood committee members, the smart contract triggers the logic to add the new member to the neighborhood committee member list.

[0075] In one embodiment, the hierarchical management system can be applied to specific financial scenarios, such as AML and KYC, where accounts need to be graded to ensure that only verified and authorized users can perform certain operations; it can also be applied to scenarios where multiple signatures are required to execute transactions, such as corporate accounts or joint accounts, and the hierarchical management system is used to determine which accounts have the right to initiate multi-signature transactions; it can also be applied to systems involving sensitive operations or assets, such as fund management or key data access, to grade accounts through the hierarchical management system to limit access to these resources; it can also be applied to systems that need to assign different access rights according to user roles, such as enterprise resource planning (ERP) or supply chain management, to grade accounts through the hierarchical management system to implement role-based access control; it can also be applied to blockchain platforms with limited resources, to grade accounts through the hierarchical management system to allocate different levels of resource usage quotas, such as computing power, storage space or network bandwidth; it can also be applied to scenarios that require additional security measures, such as cold storage accounts or high-value accounts, to grade accounts through the hierarchical management system to implement stricter security protection.

[0076] Figure 7 This is a schematic diagram of the process of the account hierarchical management method based on blockchain contracts provided in the embodiment of this application. Figure 7 As shown, the account hierarchical management method based on blockchain contract includes:

[0077] Step S71: Establish a hierarchical management model corresponding to the target blockchain; wherein the hierarchical management model is composed of nodes bound to each account on the target blockchain.

[0078] Step S72: assigning corresponding hierarchical private keys to the hierarchical management model.

[0079] Step S73: Execute the smart contract on the target blockchain based on the hierarchical management model and the hierarchical private key.

[0080] It should be understood that the specific implementation process of each step of the method has been described in detail in the above system embodiment, and for the sake of brevity, it will not be repeated here.

[0081] In one embodiment, a hierarchical management method based on blockchain contract accounts is applied to a hierarchical management system based on blockchain contract accounts. The hierarchical management system based on blockchain contract accounts includes: a decision module for performing account management on an account grading model.

[0082] In one embodiment, the account hierarchical model adopts a tree structure; wherein the tree structure is composed of multiple tree nodes each bound to an account; the types of tree nodes include root nodes, branch nodes, and leaf nodes; and wherein the parent node of all branch nodes is the root node, and the parent node of one or more leaf nodes is a branch node; each tree node has node information, including: node status and parent node index.

[0083] In one embodiment, the hierarchical private keys include: a root private key assigned to a root node, a branch private key assigned to a branch node, and a leaf private key assigned to a leaf node.

[0084] In one embodiment, according to the smart contract on the target blockchain, one or more corresponding groups are formed by the root node or branch node of the corresponding account hierarchical model.

[0085] In one embodiment, the root node is also used to manage the node status, life cycle and corresponding groups of all branch nodes; the branch node is also used to manage the node status, life cycle and corresponding groups of its child nodes.

[0086] In one embodiment, the contract execution module includes: a contract authentication submodule, which is used to respond to the verification request of the smart contract of the target blockchain, perform permission verification on the account hierarchical model of the target blockchain according to the permission rule contract in the smart contract, and obtain the permission verification result; an execution submodule, which is used to execute the smart contract according to the permission verification result and based on the hierarchical private key.

[0087] In one embodiment, the specific process of performing account management on the account grading model includes: upon receiving an account management decision request, performing consensus voting on the account management decision request; when the result of the consensus voting meets the decision passing condition, performing account management corresponding to the account management decision request on the account grading model.

[0088] Figure 8 is a schematic block diagram of an electronic terminal provided in an embodiment of the present application. Figure 8As shown, the electronic terminal includes: at least one processor 801, a memory 802, at least one network interface 803 and a user interface 805. The various components in the device are coupled together through a bus system 804. It can be understood that the bus system 804 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 804 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 8 In the specification, various buses are labeled as bus systems.

[0089] The user interface 805 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0090] It is understood that the memory 802 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM). The memory described in the embodiments of the present invention is intended to include but is not limited to these and any other suitable categories of memory.

[0091] The memory 802 in the embodiment of the present invention is used to store various categories of data to support the operation of the electronic terminal 800. Examples of these data include: any executable program for operating on the electronic terminal 800, such as an operating system 8021 and an application 8022; the operating system 8021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 8022 may include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The hierarchical management method based on blockchain contract accounts provided in the embodiment of the present invention may be included in the application 8022.

[0092] The method disclosed in the above embodiment of the present invention can be applied to the processor 801, or implemented by the processor 801. The processor 8401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 801 or the instruction in the form of software. The above processor 801 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 801 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present invention. The general processor 801 can be a microprocessor or any conventional processor, etc. In combination with the steps of the accessory optimization method provided in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0093] In an exemplary embodiment, the electronic terminal 800 may be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD) to execute the aforementioned method.

[0094] According to the method provided in the embodiment of the present application, the present application also provides a computer program product, which includes: a computer program code, when the computer program code is run on a computer, the computer executes Figure 7 The account hierarchical management method based on blockchain contracts in the illustrated embodiment.

[0095] According to the method provided in the embodiment of the present application, the present application also provides a computer-readable storage medium, which stores a program code, and when the program code is run on a computer, the computer executes Figure 7 The account hierarchical management method based on blockchain contracts in the illustrated embodiment.

[0096] The terms "component", "module", "system", etc. used in this specification are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program and / or a computer running on a processor. By way of illustration, both applications and computing devices running on a computing device can be components. One or more components may reside in a process and / or an execution thread, and a component may be located on a computer and / or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may, for example, communicate through local and / or remote processes according to signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system and / or a network, such as the Internet interacting with other systems through signals).

[0097] Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0098] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0099] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0100] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0101] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0102] In the above embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated. Available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., high-density digital video discs (DVDs), or semiconductor media (e.g., solid state disks (SSDs)).

[0103] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0104] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0105] In summary, the present application provides an account hierarchical management system, method and terminal based on blockchain contracts. The hierarchical management system includes an account hierarchical model construction module, which is used to establish an account hierarchical model corresponding to the target blockchain; wherein the account hierarchical model is composed of nodes bound to each account on the target blockchain; a private key allocation module, which is connected to the account hierarchical model construction module, is used to allocate corresponding hierarchical private keys to the account hierarchical model; a decision module, which is connected to the account hierarchical model construction module, is used to perform account management on the account hierarchical model; a contract execution module, which is connected to the account hierarchical model construction module, is used to execute smart contracts pre-deployed on the target blockchain based on the account hierarchical model and the hierarchical private key. The system of the present application realizes hierarchical management of accounts on the blockchain while maintaining the advantages of the blockchain, and meets the hierarchical management needs in specific scenarios. Therefore, the present application effectively overcomes the various shortcomings in the prior art and has a high industrial utilization value.

[0106] The above embodiments are merely illustrative of the principles and effects of the present application and are not intended to limit the present application. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present application shall still be covered by the claims of the present application.

Claims

1. An account hierarchical management system based on blockchain contracts, characterized in that: include: An account grading model building module is used to establish an account grading model corresponding to the target blockchain; wherein the account grading model is composed of nodes bound to each account on the target blockchain; A private key allocation module, connected to the account grading model construction module, for allocating corresponding hierarchical private keys to the account grading model; A decision module, connected to the account grading model building module, for performing account management on the account grading model; The contract execution module is connected to the account hierarchical model construction module and is used to execute the smart contract pre-deployed on the target blockchain based on the account hierarchical model and the hierarchical private key.

2. According to the blockchain contract-based account hierarchical management system according to claim 1, it is characterized in that: The account hierarchical model adopts a tree structure; wherein the tree structure is composed of multiple tree nodes each bound to an account; the types of tree nodes include root nodes, branch nodes, and leaf nodes; and wherein the parent node of all branch nodes is the root node, and the parent node of one or more leaf nodes is a branch node; each tree node has node information, including: node status and parent node index.

3. The account hierarchical management system based on blockchain contracts according to claim 2 is characterized in that: The hierarchical private keys include: a root private key assigned to a root node, a branch private key assigned to a branch node, and a leaf private key assigned to a leaf node.

4. The account hierarchical management system based on blockchain contracts according to claim 3 is characterized in that: According to the smart contract on the target blockchain, one or more corresponding groups are formed by the root node or branch node of the corresponding account hierarchical model.

5. According to claim 4, the account hierarchical management system based on blockchain contracts is characterized in that: The root node is also used to manage the node status, life cycle and corresponding groups of all branch nodes; the branch node is also used to manage the node status, life cycle and corresponding groups of its child nodes.

6. The account hierarchical management system based on blockchain contracts according to claim 5 is characterized in that: The contract execution module includes: The contract authentication submodule is used to respond to the verification request of the smart contract of the target blockchain, perform permission verification on the account classification model of the target blockchain according to the permission rule contract in the smart contract, and obtain the permission verification result; The execution submodule is used to execute the smart contract based on the permission verification result and the hierarchical private key.

7. The account hierarchical management system based on blockchain contracts according to claim 1 is characterized in that: The specific process of performing account management on the account grading model includes: upon receiving an account management decision request, performing consensus voting on the account management decision request; when the result of the consensus voting meets the decision passing condition, performing account management corresponding to the account management decision request on the account grading model.

8. The account hierarchical management system based on blockchain contracts according to claim 2 is characterized in that: The system allows contract accounts to become branch nodes to derive new nodes, dynamically modify permission rule contracts, and manage sub-nodes.

9. A method for hierarchical account management based on blockchain contracts, characterized in that: include: Establishing a hierarchical management model corresponding to the target blockchain; wherein the hierarchical management model is composed of nodes bound to each account on the target blockchain; Allocating corresponding hierarchical private keys to the hierarchical management model; Based on the hierarchical management model and the hierarchical private keys, the smart contract on the target blockchain is executed.

10. An electronic terminal comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the method according to any one of claims 1 to 8.

Images