User Permission Management Method, Device, Blockchain Network Node, and Storage Medium

Abstract

The present invention provides a user authority management method, device, blockchain network node and storage medium. The technical solution provided by the present invention externalizes the authority judgment into the authority smart contract. When the user node initiates a first request and wants to execute the first smart contract, the authority smart contract is called to determine whether the user node has the authority to call the first smart contract. Therefore, the technical solution provided by the present invention can realize the function of distinguishing permissions and roles in a blockchain system with no permissions and role design, without making any changes to the blockchain itself or adding any functional requirements. In addition, since the authority judgment is externalized to the authority smart contract instead of in the first smart contract, it is avoided that the first smart contract corresponding to the user node role and authority is modified due to changes in the user node role and authority.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular, to a user permission management method, device, blockchain network node, and storage medium. Background Art

[0002] In a traditional blockchain, there is no concept of permission management. All nodes and users in the blockchain have completely equal permissions. Although there are various roles such as users and full nodes, their roles are not strictly defined, and any user can change their role at any time, which is only determined by the user's behavior.

[0003] In special blockchain branches such as "consortium blockchain", "permissioned blockchain", and "enterprise blockchain", considering the roles and permissions in practical applications, permissions and roles are defined during blockchain design. For example, whether there is the right to generate blocks, whether there is the permission to send transactions, etc. However, such blockchain permission and role designs are based on the chain and are difficult to flexibly set, manage, change, etc. according to real-world applications. Even the participation of the chain manager is required, which is not user-friendly for applications. Summary of the Invention

[0004] To overcome the problems in the related art, the present invention provides a user permission management method, device, blockchain network node, and storage medium. By externalizing permission judgment to a permission smart contract, the function of distinguishing permissions and roles can be realized in a blockchain system without permission and role design, without any modification to the blockchain itself and without adding any functional requirements.

[0005] According to a first aspect of an embodiment of the present invention, a user permission management method is provided, which is applied to a blockchain network node. The method includes:

[0006] Receiving a first request from a user node, and triggering a first smart contract according to the first request;

[0007] Executing the first smart contract to call a permission smart contract;

[0008] Executing the permission smart contract to determine whether the user node has the permission to call the first smart contract;

[0009] When receiving the determination result that the user node has the permission to call the first smart contract, continuing to execute the first smart contract.

[0010] Optionally, the continuing to execute the first smart contract includes:

[0011] Executing the first smart contract to call a first approval smart contract;

[0012] Execute the first approval smart contract to receive the first approval result of the first smart contract from the first approver, where the first approver is at least one first approval node associated with the first approval smart contract;

[0013] When the first approval result received is consent, continue to execute the first smart contract.

[0014] Optionally, the first approval smart contract is based on a multi-signature mechanism. The first approval smart contract stipulates that at least n of m signatures from the first approval nodes are required for the first approval result to be consent. The execution of the first approval smart contract to receive the first approval result of the first smart contract from the first approver includes:

[0015] Execute the first approval smart contract. If signatures from x of m first approval nodes are received, the first approval result of the first smart contract received from the first approver is disagreement, where x is less than n;

[0016] Execute the first approval smart contract. If signatures from N of m first approval nodes are received, the first approval result of the first smart contract received from the first approver is consent, where N is greater than or equal to n.

[0017] Optionally, the "when the first approval result received is consent, continue to execute the first smart contract" includes:

[0018] When the first approval result received is consent, call the second approval smart contract;

[0019] Execute the second approval smart contract to receive the second approval result of the first smart contract from the second approver, where the second approver is at least one second approval node associated with the second approval smart contract;

[0020] When the second approval result received is consent, execute and complete the transaction recorded in the first smart contract.

[0021] Optionally, the permission smart contract pre-stores multiple records, each record including a source, the destination contract that the source can call, and the destination contract method signature. The execution of the permission smart contract to determine whether the user node has the permission to call the first smart contract includes:

[0022] Execute the permission smart contract to search for a record in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature;

[0023] If the record is found, it is determined that the user node has the permission to invoke the first smart contract;

[0024] If the record is not found, it is determined that the user node does not have the permission to invoke the first smart contract.

[0025] According to a second aspect of an embodiment of the present invention, there is provided a user permission management device applied to a blockchain network node. The device includes:

[0026] A first request receiving module, configured to receive a first request from a user node and trigger a first smart contract according to the first request;

[0027] A permission smart contract invocation module, configured to execute the first smart contract to invoke a permission smart contract;

[0028] A permission smart contract execution module, configured to execute the permission smart contract to determine whether the user node has the permission to invoke the first smart contract;

[0029] A first smart contract callback module, configured to continue executing the first smart contract when it receives the determination result that the user node has the permission to invoke the first smart contract.

[0030] Optionally, the first smart contract callback module includes:

[0031] A first approval smart contract invocation sub-module, configured to execute the first smart contract to invoke a first approval smart contract;

[0032] A first approval smart contract execution sub-module, configured to execute the first approval smart contract to receive a first approval result of the first approval party for the first smart contract, where the first approval party is at least one first approval node associated with the first approval smart contract;

[0033] A first smart contract callback sub-module, configured to continue executing the first smart contract when it receives the first approval result as consent.

[0034] Optionally, the permission smart contract pre-stores multiple records, and each record includes a source, a destination contract that the source can invoke, and a destination contract method signature. The permission smart contract execution module is specifically configured to:

[0035] Execute the permission smart contract to search for a record in the multiple records where the source is the user node, the destination contract that the source can invoke is the first smart contract, and the destination contract method signature is the first smart contract method signature;

[0036] If the record is found, it is determined that the user node has the permission to invoke the first smart contract;

[0037] If the record is not found, it is determined that the user node does not have the authority to call the first smart contract.

[0038] According to a third aspect of an embodiment of the present invention, a computer program product is provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for executing any one of the methods described in the first aspect when executed by the programmable device.

[0039] According to a fourth aspect of an embodiment of the present invention, a blockchain network node is provided, including:

[0040] A memory for storing executable instructions;

[0041] The processor is used to implement any one of the methods described in the first aspect above when executing the executable instructions stored in the memory.

[0042] According to a fifth aspect of an embodiment of the present invention, there is provided a storage medium storing executable instructions for causing a processor to execute the method according to any one of the first aspects above.

[0043] The technical solution provided by the embodiments of the present invention may have the following beneficial effects:

[0044] In the embodiment of the present invention, by externalizing the authority judgment to the authority smart contract, when the user node initiates a request (first request) and wants to execute a certain smart contract (first smart contract), the authority smart contract is called to determine whether the user node has the authority to call the smart contract (first smart contract). Therefore, the technical solution provided by the present invention can realize the function of distinguishing permissions and roles in a blockchain system with no permissions and role design, without making any changes to the blockchain itself and adding any functional requirements. In addition, since the authority judgment is externalized to the authority smart contract, rather than in the functional smart contract (i.e., the first smart contract that the user node wants to implement a certain function / transaction call), it is avoided that the smart contract itself (the first smart contract) corresponding to the user node role and authority is modified due to changes in the user node role and authority; and since the authority is uniformly managed through the authority smart contract, the extra workload caused by the need to traverse the permissions on the blockchain is avoided, and it is easier to achieve unified function upgrades or defect repairs to save workload. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present invention but do not constitute a limitation of the present invention. In the accompanying drawings:

[0046] Figure 1 It is an exemplary structural diagram of a blockchain network node provided by an embodiment of the present invention;

[0047] Figure 2 It is a flowchart of a user permission management method provided by an embodiment of the present invention;

[0048] Figure 3 It is a simplified implementation process diagram of another user permission management method provided by an embodiment of the present invention;

[0049] Figure 4 It is a block diagram of a user permission management device provided by an embodiment of the present invention. Detailed implementation manners

[0050] The following further details the specific implementation manners of the present invention with reference to the accompanying drawings. It should be understood that the specific implementation manners described herein are only for the purpose of illustrating and explaining the present invention, and are not used to limit the present invention.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which the present invention belongs. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.

[0052] Before further elaborating on the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are applicable to the following explanations.

[0053] Blockchain technology is a distributed, decentralized network data consensus storage technology. Based on a unique block generation mechanism such as (PoW, Proof of Work or PoS, Proof of Stake), the synchronization problem of distributed computing, that is, the "Byzantine Generals Problem", is realized.

[0054] Generally speaking, in the process of forming a Blockchain, each node participating in the calculation has the same permissions (decentralized), including core functions such as transferring (Transaction) and calculating blocks. Among them, Transaction represents the data to be written into the block, and the block (Block) adopts a specific generation mechanism to ensure that the longest chain (the chain composed of blocks Block, that is, Chain, and the longest chain naturally contains the most blocks associated before and after) is the valid chain.

[0055] Generally speaking, a smart contract itself defines two roles: the publisher and the owner, and these two roles are usually accounts on the blockchain. A smart contract itself is also an account on the blockchain. It can be triggered and execute operations, and can have relatively complex logical processing capabilities internally.

[0056] The operation of triggering a smart contract is defined as a call, which is a type of transaction (TX, Transaction) on the blockchain; any account on the blockchain can call a smart contract, but a smart contract can be programmed to only respond to specific calls; a smart contract can also call other smart contracts.

[0057] As Figure 1 shown, it is an exemplary structure of a blockchain network node provided by an embodiment of the present invention. Understandably, the hardware structure of any type of node in the blockchain network can be implemented according to the hardware structure described below.

[0058] As Figure 1 shown, the blockchain network node provided by an embodiment of the present invention includes: at least one processor 1, a memory 3, and at least one network interface 2. Each component in the node is coupled together through a bus system 4. It can be understood that the bus system 4 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear description, in Figure 1 all kinds of buses are labeled as the bus system 4.

[0059] The processor 1 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0060] The memory 3 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memories, hard disk drives, optical disc drives, etc. The memory 3 optionally includes one or more storage devices that are physically located far from the processor 1.

[0061] The memory 3 includes volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. The non-volatile memory can be a read-only memory 3 (ROM, Read Only Memory), and the volatile memory can be a random access memory (RAM, Random Access Memory). The memory described in the embodiments of the present invention is intended to include any suitable type of memory 3.

[0062] In some embodiments, the memory 3 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which will be exemplarily described below.

[0063] The operating system 100 includes system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0064] The network communication module 30 is used to reach other computing devices via one or more (wired or wireless) network interfaces 2. Exemplary network interfaces 2 include: Bluetooth, Wi-Fi (Wireless Fidelity), and USB (Universal Serial Bus), etc.;

[0065] In some embodiments, the user privilege management device 10 provided by the embodiments of the present invention can be implemented in software. Figure 1 Shown is the user privilege management device 10 stored in the memory 3, which can be software in the form of programs and plugins, etc., including the following software modules: a first request receiving module 11, a permission smart contract calling module 12, a permission smart contract execution module 13, and a first smart contract callback module 14. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

[0066] Please refer to Figure 2 , Figure 2 which is a flowchart of a user privilege management method provided by the embodiments of the present invention. As Figure 2 shown, the method includes the following steps:

[0067] Step S11: Receive a first request from a user node and trigger a first smart contract according to the first request.

[0068] Among them, the user node is the node corresponding to the user in the blockchain network, and further can be a mobile phone, a desktop computer, a laptop computer, a digital broadcast terminal, an information transceiver device, a game console, a tablet device, a personal digital assistant, etc. The user can be a user in any role, such as a purchaser, a financial staff, a merchant, a buyer, etc. An office system or an App corresponding to the user role is installed in the user node, and the user node can initiate a first request corresponding to the user role according to the office system or the App. For example, if the user is a purchaser, an office system or an App capable of performing procurement work is installed in the user node, and the user node can initiate a procurement request (the first request) through the office system or the App. A client for accessing the blockchain network also runs in the user node.

[0069] A first smart contract is deployed in the blockchain network, and the first smart contract is triggered after the user node initiates a first request. The first smart contract is a functional smart contract corresponding to the first request. For example, when the first request is a purchase request, the first smart contract can be a purchase smart contract with a purchase function, and the purchase smart contract can record the processes related to the purchase, such as the amount of financial payment, payment method, approval process, etc.

[0070] Step S12: execute the first smart contract to call the permission smart contract.

[0071] The permission smart contract records the permissions of the user node, such as the smart contracts (operations) that the user node can execute. After the user node initiates the first request and triggers the first smart contract, the first smart contract will call the permission smart contract.

[0072] Step S13: execute the permission smart contract to determine whether the user node has the permission to call the first smart contract.

[0073] After the permission smart contract is called, the permission smart contract can determine whether the user node has the permission to call the first smart contract. For example, the permission smart contract determines whether the user node has the permission to call the first smart contract based on the unique identifier of the user node (such as the user account address) and the unique identifier of the first smart contract (such as the contract address).

[0074] Step S14: When receiving the determination result that the user node has the authority to call the first smart contract, continue to execute the first smart contract.

[0075] After determining whether the user node has the authority to call the first smart contract, the permission smart contract calls back the first smart contract. When the first smart contract receives the determination result that the user node has the authority to call the first smart contract, it continues to execute the first smart contract. When the first smart contract receives the determination result that the user node does not have the authority to call the first smart contract, it terminates the execution of the first smart contract and can return a prompt of insufficient authority to the user node through the first smart contract.

[0076] The technical solution provided by the present invention externalizes the authority judgment to the authority smart contract. When the user node initiates a request (first request) and wants to execute a certain smart contract (first smart contract), the authority smart contract is called to determine whether the user node has the authority to call the smart contract (first smart contract). Therefore, the technical solution provided by the present invention can realize the function of distinguishing permissions and roles in a blockchain system with no permissions and role design, without making any changes to the blockchain itself or adding any functional requirements. In addition, since the authority judgment is externalized to the authority smart contract, rather than in the function smart contract (i.e., the first smart contract that the user node wants to implement a certain function / transaction call), it avoids modifying the smart contract itself (first smart contract) corresponding to the user node role and authority due to changes in the user node role and authority; and since the authority is uniformly managed through the authority smart contract, the extra workload caused by the need to traverse the permissions on the blockchain is avoided, and it is easier to achieve unified function upgrades or defect repairs to save workload.

[0077] In actual application, whether the user's request can be passed (or whether the first smart contract can be executed) needs to go through the approval process. Therefore, optionally, step S14 includes:

[0078] Execute the first smart contract to call the first approval smart contract.

[0079] After the permission smart contract determines that the user node has the authority to call the first smart contract, it will continue to execute the first smart contract, and the first smart contract will call the first approval smart contract for approval.

[0080] The first approval smart contract is executed to receive a first approval result of the first smart contract by a first approval party, where the first approval party is at least one first approval node associated with the first approval smart contract.

[0081] Among them, the first approver can be a first approval node, or multiple first approval nodes based on a multi-signature mechanism, or a contract account including multiple first approval nodes based on a multi-signature mechanism.

[0082] When the first approver is a first approval node, the first approval smart contract is executed. If the (private key) signature of the first approval node is received, the first approval result is approval; otherwise, the first approval result is disapproval.

[0083] When the first approver is multiple first approval nodes based on a multi-signature mechanism or a contract account including multiple first approval nodes based on a multi-signature mechanism, execute the first approval smart contract. If signatures of the private keys of the first approval nodes greater than or equal to a preset number are received, the first approval result is consent; otherwise, the first approval result is dissent. The preset number is recorded in the first approval smart contract. Therefore, optionally, the first approval smart contract is based on a multi-signature mechanism. The first approval smart contract stipulates that at least n of m first approval nodes' signatures are required for the first approval result to be consent. The execution of the first approval smart contract to receive the first approval result of the first approver for the first smart contract includes: executing the first approval smart contract. If signatures of x of m first approval nodes are received, the first approval result of the first approver for the first smart contract received is dissent, where x is less than n; executing the first approval smart contract. If signatures of N of m first approval nodes are received, the first approval result of the first approver for the first smart contract received is consent, where N is greater than or equal to n.

[0084] When the first approval result is received as consent, continue to execute the first smart contract.

[0085] After the first approval smart contract determines the first approval result of the first approver for the first smart contract, it calls back the first smart contract. When the first approval result is received as consent, the first smart contract continues to execute the first smart contract. When the first approval result is received as dissent, the execution of the first smart contract is terminated, and a prompt that the first approval result is dissent can be returned to the user node through the first smart contract.

[0086] Through the above technical solution, the approval process is externalized to the first approval smart contract. When approval is required, the first approval smart contract is called by the first smart contract to achieve approval. Therefore, the technical solution provided by the present invention can implement the approval function in a blockchain system without an approval design without any modification to the blockchain itself and without adding any functional requirements. Moreover, since the approval process is externalized to the first approval smart contract rather than in the functional smart contract (i.e., the first smart contract called by the user node to implement a certain function / transaction), it avoids modifying the first smart contract itself corresponding to the approval definition due to a change in the approval definition (such as a change in the approver); and since the approval is uniformly managed through the first approval smart contract, it avoids the additional workload caused by traversing the approvals on the blockchain and can more easily achieve unified function upgrade or defect repair to save workload.

[0087] In actual applications, whether a user's request can pass (or whether the first smart contract can complete execution) may require going through two approval processes. That is, after the first smart contract calls the first approval smart contract (going through one approval process), it will then call another (second) approval smart contract to go through the second approval process, as Figure 3 shown. Therefore, optionally, when receiving that the first approval result is consent, continuing to execute the first smart contract includes:

[0088] When receiving that the first approval result is consent, call the second approval smart contract.

[0089] Execute the second approval smart contract to receive the second approval result of the first smart contract from the second approval party, where the second approval party is at least one second approval node associated with the second approval smart contract.

[0090] When receiving that the second approval result is consent, execute and complete the transaction recorded in the first smart contract.

[0091] Since the method of calling the second approval smart contract for approval is the same as the method of calling the first approval smart contract for approval, for the sake of saving space, it will not be elaborated here.

[0092] Similarly, through the above technical solution, the second approval process is externalized to the second approval smart contract. When a second approval is required, the first smart contract calls the second approval smart contract to implement the second approval. Therefore, the technical solution provided by the present invention can implement the secondary approval function in a blockchain system without an approval design, without making any changes to the blockchain itself and without adding any functional requirements. And, since the second approval process is externalized to the second approval smart contract rather than in the functional smart contract (i.e., the first smart contract called by the user node to implement a certain function / transaction), it avoids modifying the smart contract itself (the first smart contract) corresponding to the change in the second approval definition (such as a change in the approver); and because the second approval is uniformly managed through the second approval smart contract, it avoids the additional workload caused by traversing the second approval on the blockchain and can more easily achieve unified function upgrade or defect repair to save workload.

[0093] Optionally, multiple records are pre-stored in the permission smart contract, and each record includes a source, the destination contract that the source can call, and the destination contract method signature. For example, the core function of the permission smart contract can be: canCall(src, dst, sig). Where src represents the source, which can be the unique identifier of the user node, such as the account address / public key address of the user node, or the unique identifier of a certain smart contract (such as the first approval smart contract, the second approval smart contract, etc.), such as the contract address of a certain smart contract; dst represents the destination contract (operation); sig (permission) represents the destination contract method signature. And, src, dst, and sig can be represented by hash values. For example, src can be represented by the hash value of the public key address of the user node. Executing the permission smart contract to determine whether the user node has the permission to call the first smart contract includes:

[0094] Execute the permission smart contract to find a record in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature.

[0095] If the record is found, it is determined that the user node has the permission to call the first smart contract.

[0096] If the record is not found, it is determined that the user node does not have the permission to call the first smart contract.

[0097] Through the above technical solution, the design of the permission smart contract can clearly record which methods of which smart contracts each user node has the permission to call. During permission verification, find a record in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature. If the record is found, it is determined that the user node has the permission to call the first smart contract. If the record is not found, it is determined that the user node does not have the permission to call the first smart contract.

[0098] Please refer to Figure 4 , based on the same inventive concept, an embodiment of the present invention further provides a user permission management device 10, and the device includes:

[0099] A first request receiving module 11, configured to receive a first request from a user node and trigger a first smart contract according to the first request.

[0100] A permission smart contract calling module 12, configured to execute the first smart contract to call a permission smart contract.

[0101] The permission smart contract execution module 13 is used to execute the permission smart contract to determine whether the user node has the permission to call the first smart contract.

[0102] The first smart contract callback module 14 is used to continue executing the first smart contract when receiving the determination result that the user node has the authority to call the first smart contract.

[0103] The technical solution provided by the present invention externalizes the authority judgment to the authority smart contract. When the user node initiates a request (first request) and wants to execute a certain smart contract (first smart contract), the authority smart contract is called to determine whether the user node has the authority to call the smart contract (first smart contract). Therefore, the technical solution provided by the present invention can realize the function of distinguishing permissions and roles in a blockchain system with no permissions and role design, without making any changes to the blockchain itself or adding any functional requirements. In addition, since the authority judgment is externalized to the authority smart contract, rather than in the function smart contract (i.e., the first smart contract that the user node wants to implement a certain function / transaction call), it avoids modifying the smart contract itself (first smart contract) corresponding to the user node role and authority due to changes in the user node role and authority; and since the authority is uniformly managed through the authority smart contract, the extra workload caused by the need to traverse the permissions on the blockchain is avoided, and it is easier to achieve unified function upgrades or defect repairs to save workload.

[0104] In actual application, whether the user's request can be passed (or whether the first smart contract can be executed) needs to go through the approval process. Therefore, optionally, the first smart contract callback module 14 includes:

[0105] The first approval smart contract calling submodule is used to execute the first smart contract to call the first approval smart contract.

[0106] The first approval smart contract execution submodule is used to execute the first approval smart contract to receive a first approval result of the first approval party on the first smart contract, where the first approval party is at least one first approval node associated with the first approval smart contract.

[0107] Among them, the first approver can be a first approval node, or multiple first approval nodes based on a multi-signature mechanism, or a contract account including multiple first approval nodes based on a multi-signature mechanism.

[0108] When the first approver is a first approval node, the first approval smart contract is executed. If the (private key) signature of the first approval node is received, the first approval result is approval; otherwise, the first approval result is disapproval.

[0109] When the first approver is multiple first approval nodes based on a multi-signature mechanism or a contract account including multiple first approval nodes based on a multi-signature mechanism, execute the first approval smart contract. If signatures of the private keys of the first approval nodes greater than or equal to a preset number are received, the first approval result is consent; otherwise, the first approval result is dissent. The preset number is recorded in the first approval smart contract. Optionally, the first approval smart contract is based on a multi-signature mechanism. The first approval smart contract stipulates that at least n of m first approval node signatures are required for the first approval result to be consent. Specifically, it is used for: executing the first approval smart contract. If signatures of x of m first approval nodes are received, the first approval result of the first approver for the first smart contract is dissent, where x is less than n; executing the first approval smart contract. If signatures of N of m first approval nodes are received, the first approval result of the first approver for the first smart contract is consent, where N is greater than or equal to n.

[0110] The first smart contract callback sub-module is used to continue executing the first smart contract when the first approval result is received as consent.

[0111] Through the above technical solution, the approval process is externalized to the first approval smart contract. When approval is required, the first approval smart contract is called through the first smart contract to achieve approval. Therefore, the technical solution provided by the present invention can implement the approval function in a blockchain system without an approval design without any modification to the blockchain itself and without adding any functional requirements. Moreover, since the approval process is externalized to the first approval smart contract rather than in the functional smart contract (i.e., the first smart contract called by the user node to implement a certain function / transaction), it avoids modifying the smart contract itself (the first smart contract) corresponding to the approval definition due to changes in the approval definition (such as changes in the approver); and since the approval is uniformly managed through the first approval smart contract, it avoids the additional workload caused by traversing the approvals on the blockchain and can more easily achieve unified function upgrades or defect repairs to save workload.

[0112] In actual application, whether the user's request can pass (or whether the first smart contract can complete execution) may require going through two approval processes. That is, after the first smart contract calls the first approval smart contract (going through one approval process), it will also call a second approval smart contract to go through the second approval process, as Figure 3 shown. Therefore, optionally, the first smart contract callback sub-module is specifically used for:

[0113] calling the second approval smart contract when the first approval result is received as consent.

[0114] Execute the second approval smart contract to receive the second approval result of the first smart contract by at least one second approval node associated with the second approval smart contract.

[0115] When the second approval result is received as approval, execute and complete the transaction recorded in the first smart contract.

[0116] Similarly, through the above technical solution, the second approval process is externalized to the second approval smart contract. When the second approval is required, the second approval smart contract is called by the first smart contract to implement the second approval. Therefore, the technical solution provided by the present invention can implement the secondary approval function in a blockchain system without an approval design without any modification to the blockchain itself and without adding any functional requirements. Moreover, since the second approval process is externalized to the second approval smart contract instead of in the functional smart contract (i.e., the first smart contract called by the user node to implement a certain function / transaction), it avoids modifying the smart contract itself (the first smart contract) corresponding to the second approval definition due to a change in the second approval definition (such as a change in the approver); and since the second approval is uniformly managed through the second approval smart contract, it avoids the additional workload caused by traversing the second approval on the blockchain and can more easily achieve unified function upgrade or defect repair to save workload.

[0117] Optionally, the permission smart contract pre-stores multiple records, each record including a source, a destination contract that the source can call, and a destination contract method signature. The permission smart contract execution module 13 is specifically configured to:

[0118] Execute the permission smart contract to find a record in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature.

[0119] If the record is found, it is determined that the user node has the permission to call the first smart contract.

[0120] If the record is not found, it is determined that the user node does not have the permission to call the first smart contract.

[0121] Through the above technical solution, the design of the permission smart contract can clearly record which methods of which smart contracts each user node has the calling permission for. During permission verification, search for records in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the method signature of the destination contract is the method signature of the first smart contract. If the record is found, it is determined that the user node has the permission to call the first smart contract. If the record is not found, it is determined that the user node does not have the permission to call the first smart contract.

[0122] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment related to the method, and will not be elaborated here.

[0123] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program that can be executed by a programmable device, and the computer program has a code portion for executing the above user permission management method when executed by the programmable device.

[0124] In another exemplary embodiment, a blockchain network node is further provided, including: a memory for storing executable instructions; a processor for implementing the method according to any one of the above first aspects when executing the executable instructions stored in the memory.

[0125] In another exemplary embodiment, a storage medium is further provided, storing executable instructions for causing a processor to implement the method according to any one of the above first aspects when executed.

[0126] In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD - RON; or it may be various devices including one or any combination of the above memories.

[0127] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0128] As an example, the executable instructions may or may not correspond to files in a file system and may be stored as part of a file that holds other programs or data, for example, in one or more scripts stored in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program being discussed, or in multiple cooperating files (such as files that store one or more modules, subroutines, or code portions).

[0129] As an example, the executable instructions may be deployed to execute on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0130] As described above, the above embodiments are only used to introduce the technical solutions of the present invention in detail, but the descriptions of the above embodiments are only used to help understand the method and its core idea of the present invention, and should not be construed as a limitation of the present invention. Those skilled in the art of the present technology can easily think of changes or substitutions within the technical scope disclosed by the present invention, and all of them should be covered within the protection scope of the present invention.

Claims

1. A user privilege management method, characterized in that, Applied to a blockchain network node, the method comprises: receiving a first request from a user node, and triggering a first smart contract according to the first request; the first smart contract is a functional smart contract corresponding to the first request, and the first smart contract records a process related to the function; Execute the first smart contract, which calls the permission smart contract; Execute the permission smart contract to determine whether the user node has the permission to call the first smart contract; When receiving a determination result that the user node has the authority to call the first smart contract, continue to execute the first smart contract, and the first smart contract will call the first approval smart contract for approval; Execute the first approval smart contract to receive a first approval result of the first approval party on the first smart contract, where the first approval party is at least one first approval node associated with the first approval smart contract; When receiving that the first approval result is approval, calling the second approval smart contract through the first smart contract; Execute the second approval smart contract to receive a second approval result of the first smart contract by a second approver, where the second approver is at least one second approval node associated with the second approval smart contract; When the second approval result is received as approval, the transaction recorded in the first smart contract is executed and completed.

2. The method according to claim 1, wherein The first approval smart contract is based on a multi-signature mechanism. The first approval smart contract stipulates that at least n of m first approval nodes need to sign the first approval result to be approved. The execution of the first approval smart contract to receive the first approval result of the first approval party on the first smart contract includes: Execute the first approval smart contract. If the signature of the first approval node x of m is received, then the first approval result of the first approval party on the first smart contract is disagreement, where x is less than n; The first approval smart contract is executed. If a signature of N of m first approval nodes is received, then the first approval result of the first approval party on the first smart contract is received as approval, where N is greater than or equal to n.

3. The method according to any one of claims 1 or 2, characterized in that The permission smart contract pre-stores multiple records, each record includes a source, a destination contract that the source can call, and a destination contract method signature, and the execution of the permission smart contract to determine whether the user node has the authority to call the first smart contract includes: Execute the permission smart contract to find a record in which the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature among the multiple records; If the record is found, it is determined that the user node has the authority to call the first smart contract; If the record is not found, it is determined that the user node does not have the authority to call the first smart contract.

4. A user privilege management device, characterized in that, Applied to a blockchain network node, the device comprises: The first request receiving module is configured to receive a first request from a user node and trigger a first smart contract according to the first request; the first smart contract is a functional smart contract corresponding to the first request, and the first smart contract records a process related to the function. The permission smart contract calling module is configured to execute the first smart contract, and the first smart contract will call the permission smart contract. The permission smart contract execution module is configured to execute the permission smart contract to determine whether the user node has the permission to call the first smart contract. The first smart contract callback module is configured to continue to execute the first smart contract when receiving a determination result that the user node has the permission to call the first smart contract, and the first smart contract will call a first approval smart contract for approval. The first approval smart contract execution sub-module is configured to execute the first approval smart contract to receive a first approval result of the first approval party for the first smart contract, and the first approval party is at least one first approval node associated with the first approval smart contract. The first smart contract callback sub-module is configured to, when receiving the first approval result as consent, call a second approval smart contract through the first smart contract and execute the second approval smart contract to receive a second approval result of the second approval party for the first smart contract, and the second approval party is at least one second approval node associated with the second approval smart contract, and when receiving the second approval result as consent, execute and complete the transaction recorded in the first smart contract.

5. The device according to claim 4, characterized in that, The permission smart contract pre-stores multiple records, and each record includes a source, a destination contract that the source can call, and a destination contract method signature. The permission smart contract execution module is specifically configured to: Execute the permission smart contract to find a record in the multiple records where the source is the user node, the destination contract that the source can call is the first smart contract, and the destination contract method signature is the first smart contract method signature. If the record is found, it is determined that the user node has the permission to call the first smart contract. If the record is not found, it is determined that the user node does not have the permission to call the first smart contract.

6. A blockchain network node, characterized in that, Comprising: A memory for storing executable instructions. A processor, when executing the executable instructions stored in the memory, implements the method according to any one of claims 1-3.

7. A computer storage medium, characterized in that, Stored with executable instructions, which are used to cause the processor to implement the method according to any one of claims 1-3 when executed.

Images