Method and related products for blockchain-based rights management

Abstract

The application relates to a blockchain-based permission management method and related products. The method comprises the following steps: in response to a transaction calling a smart contract on a blockchain, obtaining permission management information related to the smart contract, wherein the permission management information is stored on the blockchain; based on the permission management information, verifying the identity of the initiator of the transaction; and selectively sending the transaction to the smart contract according to the verification result of the identity of the initiator. Through the scheme of the application, the permission management of users can be realized based on the permission management information stored on the blockchain, the permission management process is effectively simplified, and the stability and security of the permission management process are improved.

Description

Technical Field

[0001] This invention generally relates to the field of blockchain technology. More specifically, this invention relates to a blockchain-based method for access control, and an apparatus and computer-readable storage medium for performing the aforementioned method. Background Technology

[0002] This section is intended to provide background or context for embodiments of the invention set forth in the claims. The description herein may include concepts that may be explored, but not necessarily concepts that have been previously conceived or explored. Therefore, unless otherwise stated, what is described in this section is not prior art for the purposes of this application's specification and claims, and is not acknowledged as prior art simply by virtue of its inclusion in this section.

[0003] As blockchain technology develops, the functionalities it needs to implement are becoming increasingly complex. In practical applications, it's necessary to differentiate user permissions for blockchain access based on individual user needs. Current technologies primarily control user access through permission contracts. This contract-based approach requires sending each transaction to the permission contract for permission checks, and these contracts are typically deployed later within the blockchain's virtual machine. Therefore, each transaction needs to undergo permission checks within the virtual machine, which not only introduces more restrictions but also compromises stability, making the entire process more cumbersome. Furthermore, later-deployed permission contracts are more vulnerable to modification and attacks, posing a certain risk to the entire permission management process. Currently, there is no effective solution to this problem. Summary of the Invention

[0004] To at least address the technical problems described in the background section, this invention proposes a blockchain-based access control scheme. Using this scheme, user access control can be implemented based on access control information stored on the blockchain, effectively simplifying the access control process while improving its stability and security.

[0005] In view of this, the present invention provides solutions in the following aspects.

[0006] A first aspect of the present invention provides a blockchain-based permission management method, comprising: in response to a transaction on the blockchain that invokes a smart contract, obtaining permission management information related to the smart contract, wherein the permission management information is stored on the blockchain; verifying the identity of the initiator of the transaction based on the permission management information; and selectively sending the transaction to the smart contract according to the verification result of the initiator's identity.

[0007] In one embodiment, verifying the identity of the initiator of the transaction based on the permission management information includes: obtaining the initiator's identity identification information on the blockchain; and verifying the identity identification information based on the permission management information to verify the identity of the initiator.

[0008] In one embodiment, the identity information includes the organization and role to which the initiator belongs, and the access management information includes a management mode of blacklist or whitelist and an access expression for representing the scope of access control. Verifying the identity information based on the access management information includes: determining whether the organization and role to which the initiator belongs satisfy the access expression; in response to satisfying the access expression and the management mode being whitelist, determining that the initiator's authentication is successful; or in response to not satisfying the access expression and the management mode being whitelist, determining that the initiator's authentication has failed; or in response to satisfying the access expression and the management mode being blacklist, determining that the initiator's authentication has failed; or in response to not satisfying the access expression and the management mode being blacklist, determining that the initiator's authentication is successful.

[0009] In one embodiment, the method further includes: obtaining a list of organizational expressions and a list of role IDs associated with the smart contract; and using the list of organizational expressions and the list of role IDs to determine the permission expression.

[0010] In one embodiment, the organization expression supports both exact and fuzzy matching. Determining whether the organization and role to which the initiator belongs satisfy the permission expression includes: determining whether the organization and role to which the initiator belongs satisfy the permission expression based on the Cartesian product of the list of organization expressions and the list of role IDs.

[0011] In one embodiment, the method further includes: in response to the deployment transaction of the smart contract, storing the permission management information on the blockchain and storing the smart contract in the virtual machine of the blockchain.

[0012] In one embodiment, the method further includes: in response to a permission update transaction of the smart contract, obtaining updated permission management information; determining whether the initiator of the permission update transaction is a designated initiator; and in response to the initiator of the permission update transaction being a designated initiator, binding the updated permission management information to the smart contract.

[0013] In one embodiment, selectively sending the transaction to the smart contract includes: in response to successful authentication of the initiator, sending the transaction to the smart contract to execute the transaction based on the smart contract; or

[0014] In response to the failure to authenticate the initiator, an error message is displayed.

[0015] A second aspect of the invention provides an apparatus comprising: a processor; and a memory storing computer instructions for blockchain-based access control, wherein when the computer instructions are executed by the processor, the apparatus causes the apparatus to perform the methods described in the first aspect above and in the various embodiments described below.

[0016] A third aspect of the present invention provides a computer-readable storage medium including blockchain-based access control program instructions that, when executed by a processor, cause the methods described in the first aspect above and in the various embodiments below to be implemented.

[0017] The solution provided by this invention allows for the authentication of transaction initiators through on-chain permission management information, and selectively sends the transaction to the smart contract based on the authentication result, thereby achieving permission management for the initiator. It can be seen that the solution of this invention does not rely on permission contracts and does not require permission management within the blockchain's virtual machine; instead, permission management is executed directly on the blockchain. This effectively simplifies the permission management process while improving its stability and security. Furthermore, only verified transactions are sent to the smart contract; failed transactions are not sent to the virtual machine, thus reducing resource consumption. Attached Figure Description

[0018] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the invention are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0019] Figure 1 This is an architecture diagram illustrating a blockchain-based access control system according to an embodiment of the present invention;

[0020] Figure 2 This is a flowchart illustrating a blockchain-based access control method according to an embodiment of the present invention;

[0021] Figure 3 This is a flowchart illustrating a blockchain-based access control method according to another embodiment of the present invention;

[0022] Figure 4This is a flowchart illustrating a method for verifying identity information based on access control information according to an embodiment of the present invention; and

[0023] Figure 5 This is a schematic diagram illustrating the structure of a device according to an embodiment of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It should be understood that the terms "first," "second," "third," and "fourth," etc., in the claims, specification, and drawings of this invention are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" used in the specification and claims of this invention indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0026] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this specification and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0027] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0028] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0029] The blockchain involved in this application can be understood as a chain-like data structure that links block data sequentially according to block number, or a decentralized distributed database. Regarding data security and reliability, blockchain ensures the immutability and traceability of data through cryptographic methods such as hash algorithms, and guarantees data consistency through consensus algorithms. Furthermore, in addition to transaction transfers, blockchain platforms supporting smart contracts can implement custom business logic to complete commercial applications through smart contract technology.

[0030] As blockchain technology develops, the functions it needs to implement become more complex. For example, it requires permission management to differentiate user permissions for using the blockchain. It is understood that the aforementioned permission categories can include transaction permissions, network connection permissions, and organizational management permissions. In some embodiments, transaction permissions can include application chain transaction permissions, smart contract permissions, and cross-chain transaction permissions, etc.

[0031] This application primarily concerns permission management based on the blockchain application layer, which can include setting smart contract permissions, verifying the initiator's permissions when executing transactions, and modifying smart contract permissions. In practical applications, permission design is closely related to accounts and organizational structures. Specifically, permission control can be achieved by binding permission control to accounts and organizations to control and manage the permissions of different levels and roles of accounts on blockchain system contracts. For example, global permission control can be achieved through parsing transaction messages and identifying the identity of the transaction initiator. From a practical operational perspective, permission design can also include the following operations:

[0032] Create permissions: You can generate permission identifiers, and permission attributes can include the correspondence between modules, transaction messages, and identities, etc.

[0033] Update permissions: Allows modification of permission attributes;

[0034] Delete permission: This can revoke the original operation permissions held by users, organizations, and roles;

[0035] Grant permissions: You can grant permissions to an account.

[0036] In some embodiments, permission design may specifically include policies, a list of permission expressions, and permission allocation. The policy can be a whitelist or blacklist management mode. The permission expression list may include one or more permission expressions. Each permission expression may consist of a list of organization expressions and a list of role IDs, and permission determination can be made by the Cartesian product of the organization expression list and the role ID list (where organization expressions and role IDs can be either yes or no). The aforementioned permission allocation provides a unified permission module interface and can utilize permission expressions to bind the relationships between organizations, roles, and transactions. During permission management, the appropriateness of permissions can be identified based on the return value of the permission expression and the aforementioned built-in permission judgment logic. Furthermore, the system's whitelist / blacklist settings can be used to determine whether the return value should be negated.

[0037] In some embodiments, permission management information can be submitted to the blockchain when deploying and upgrading smart contracts. This permission management information mainly includes policies and permission expressions. Policies can include whitelist or blacklist patterns, and permission expressions specify the scope of permission control. Policies and permission expressions can be bound to the deployed smart contracts. When a transaction is initiated, the blockchain application layer needs to verify the policies and permission expressions of the smart contract invoked by the transaction, based on the organization and role of the transaction initiator. If the verification passes, the transaction can be sent to the smart contract layer for execution.

[0038] In some embodiments, after the smart contract is deployed, a function to modify smart contract permissions can be designed to allow contract administrators more flexible control over smart contract permissions. Specifically, when modifying smart contract permissions, the modified policy and permission expression can be submitted to the blockchain. When the blockchain determines that the initiator is the smart contract administrator, it can bind the latest policy and permission expression to the target contract.

[0039] The following combination Figures 1 to 4 The specific implementation process of the above-mentioned access control is explained.

[0040] Figure 1 This is a feasible architecture diagram illustrating a permission management system that implements the above-described permission management. For example... Figure 1As shown, this permission management system can include a blockchain, blockchain users, and smart contracts. When a user initiates a transaction on the blockchain that calls a smart contract, the blockchain can verify the initiator's permissions on-chain. If the permission verification is successful, the transaction can be sent to the smart contract, or the user can be notified of a failed permission verification, thereby achieving effective management of user permissions. This permission management system has higher stability and is better able to resist the risk of attacks, possessing a higher security level. It should be noted that the number of users and smart contracts is not limited here; it is merely an illustrative example.

[0041] Figure 2 This is a flowchart illustrating a blockchain-based permission management method 200 according to an embodiment of the present invention. It is understood that the blockchain described here can possess the general properties of blockchains described above, and its performance can be further optimized and improved through the solution of the present invention.

[0042] like Figure 2 As shown, in step S201, in response to a transaction on the blockchain that invokes a smart contract, permission management information related to the aforementioned smart contract can be obtained. In some embodiments, when there is a need to invoke a smart contract according to an actual application scenario, a user of the blockchain can initiate a transaction to invoke the smart contract on the blockchain, and when the transaction is detected on the blockchain, permission management information related to the smart contract can be obtained. This permission management information can be stored on the blockchain so that it can be directly accessed from the chain, thereby effectively saving information retrieval time. It should be noted that the detailed description of the transaction here is merely illustrative, and the solution of the present invention is not limited thereto.

[0043] Next, in step S202, the initiator of the transaction can be authenticated based on the permission management information. Authentication of the initiator does not rely on a permission contract; it can be performed directly on-chain without sending the transaction to the permission contract located in the virtual machine, effectively simplifying the technical implementation process of authentication.

[0044] Next, in step S203, the transaction can be selectively sent to the smart contract based on the verification result of the initiator's identity. In some embodiments, the transaction can be sent to the smart contract when verification is successful, and not sent to the smart contract when verification fails, thereby reducing resource consumption. It can be seen that the solution of the present invention does not rely on permission contracts and does not need to enter the blockchain virtual machine for permission management, but performs permission management directly on the blockchain, thereby effectively simplifying the permission management process and improving the stability and security of the permission management process.

[0045] Furthermore, the initiator of the aforementioned transaction can be identified through various methods. In some embodiments, the initiator's identity information on the blockchain can be obtained. This identity information may include the initiator's organization, role, or other information identifying the initiator's identity within the blockchain. Then, the aforementioned identity information can be verified based on this permission management information to verify the initiator's identity. In some embodiments, the aforementioned permission management information may include a blacklist or whitelist management mode and a permission expression representing the scope of permission control. Verification of the identity information can be achieved by checking whether the specific management mode and the initiator's organization and role satisfy the permission expression. It should be noted that the detailed description of the identity verification process described here is merely illustrative, and the solution of this invention is not limited thereto.

[0046] Figure 3 This is a flowchart illustrating a blockchain-based access control method 300 according to another embodiment of the present invention. It should be noted that method 300 can be understood as a further explanation and extension of the steps in method 200. Therefore, the foregoing descriptions of blockchain and related aspects of method 200 also apply below.

[0047] like Figure 3 As shown, in step S301, in response to a smart contract deployment transaction, permission management information can be stored on the blockchain, and the smart contract can be stored in the blockchain's virtual machine. In some embodiments, a designated user of the blockchain (e.g., the smart contract administrator) can define the specific content of the smart contract and its permission management information (e.g., restricting the smart contract to be invoked by a specific organization or a group within that organization, and specifying the management mode, etc.). After defining the smart contract and its permission management information, a smart contract deployment transaction can be initiated to the blockchain to transmit the permission management information to the blockchain for storage and upload the smart contract to the blockchain's virtual machine. It should be noted that the detailed description of the smart contract deployment process here is merely illustrative, and the solution of the present invention is not limited thereto.

[0048] Next, in step S302, in response to a transaction on the blockchain that invokes the smart contract, permission management information related to the smart contract can be obtained. As mentioned above, permission management information may include a blacklist or whitelist management mode and a permission expression used to represent the scope of permission control, and this permission management information can be stored on the blockchain. Therefore, the permission management information can be directly accessed from the blockchain. It should be noted that the detailed description of permission management information here is only an illustrative example.

[0049] Next, in step S303, the initiator's identity information on the blockchain can be obtained. In some embodiments, the initiator's identity information may include the organization and role the initiator belongs to on the blockchain, or other information that can identify the initiator. In practical applications, the initiator's identity information can be recorded in a transaction, and the relevant information can be directly extracted from that transaction. Alternatively, identity information uploaded by the initiator in real time can also be obtained. It should be noted that the detailed description of identity information here is merely illustrative.

[0050] Next, in step S304, the identity information can be verified based on the aforementioned access control information to verify the initiator's identity. In practical applications, the initiator's identity can be verified in various ways. Figure 4 This illustrates one possible method for verifying identity information using access control information. For example... Figure 4 As shown, in step S401, a list of organization expressions and a list of role IDs related to the aforementioned smart contract can be obtained. Both the list of organization expressions and the list of role IDs can be OR-related. In some embodiments, the list of organization expressions supports exact matching and fuzzy matching. Exact matching takes the form org1.dep1.group1 (which represents a subgroup under a certain level of an organization). Fuzzy matching supports wildcards such as "*" and "**", where "*" represents any organization name at a certain level, and "**" matches organizations at any level. For example, fuzzy matching takes the form org1.dep1.*, org1.**, etc.

[0051] Next, in step S402, the permission expression can be determined using the aforementioned list of organization expressions and list of role IDs. Specifically, the present invention does not limit the number of permission expressions; one or more permission expressions can be set. Each permission expression can be composed of the list of organization expressions and the list of role IDs, and the permission expressions can also be related by an OR relationship.

[0052] Next, in step S403, the Cartesian product of the aforementioned list of organization expressions and the list of role IDs can be used to determine whether the organization and role to which the initiator belongs satisfy the permission expression. If the permission expression is satisfied, step S404 is executed. Alternatively, if the permission expression is not satisfied, step S405 is executed.

[0053] Then, at step S404, in response to the permission expression being satisfied and the management mode being whitelisted, it can be determined that the initiator's authentication has passed; or in response to the permission expression being satisfied and the management mode being blacklisted, it can be determined that the initiator's authentication has failed. Alternatively, at step S405, in response to the permission expression not being satisfied and the management mode being whitelisted, it can be determined that the initiator's authentication has failed; or in response to the permission expression not being satisfied and the management mode being blacklisted, it can be determined that the initiator's authentication has passed.

[0054] After verifying the identity information, return Figure 3 Next, in step S305, the transaction can be selectively sent to the smart contract based on the verification result of the initiator's identity. Specifically, in response to successful authentication of the initiator, the transaction can be sent to the smart contract for execution. Alternatively, in response to failed authentication of the initiator, error handling can be performed. For example, error information can be fed back to the initiator. It can be seen that the above embodiment no longer implements permission management through smart contracts, allowing transaction permission verification to be performed only at the application layer of the blockchain. Transactions that fail verification will not enter the smart contract virtual machine, thereby simplifying the transaction lifecycle and optimizing the technical implementation process.

[0055] Furthermore, in some embodiments, in response to a permission update transaction of a smart contract, the updated permission management information can be obtained, and it can be determined whether the initiator of the permission update transaction is a designated initiator. If the initiator of the permission update transaction is a designated initiator (e.g., the designated initiator is the manager of the smart contract or another user with control over the smart contract, which can be set and adjusted according to actual needs), the updated permission management information can be bound to the aforementioned smart contract to meet different user needs.

[0056] Figure 5 A schematic block diagram of a device 500 according to an embodiment of the present invention is shown. Figure 5 As shown, device 500 may include processor 501 and memory 502. Memory 502 stores computer instructions for blockchain-based access control. When these computer instructions are executed by processor 501, device 500 performs actions according to the preceding description. Figures 2-4The described method. For example, in some embodiments, device 500 can perform actions such as managing access information, authenticating the initiator of a transaction, and selectively sending transactions to smart contracts based on the authentication results. Based on this, device 500 can perform access management directly on the blockchain without relying on access contracts or entering the blockchain's virtual machine. This not only effectively simplifies the access management process but also improves its stability and security.

[0057] As can be seen from the above description of the modular design of this invention, the system of this invention can be flexibly arranged according to application scenarios or needs, and is not limited to the architecture shown in the accompanying drawings. Furthermore, it should be understood that any module, unit, component, server, computer, or device performing the operations of this invention may include or otherwise access computer-readable media, such as storage media, computer storage media, or data storage devices (removable) and / or non-removable) such as disks, optical discs, or magnetic tapes. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Based on this, this invention also discloses a computer-readable storage medium storing computer-readable instructions based on blockchain-based access control, which, when executed by one or more processors, implements the aforementioned... Figures 2-4 The methods and operations described.

[0058] While various embodiments of the invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Many modifications, alterations, and alternatives will occur to those skilled in the art without departing from the spirit and intent of the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in the practice of the invention. The appended claims are intended to define the scope of protection of the invention and therefore cover modular compositions, equivalents, or alternatives within the scope of these claims.

Claims

1. A blockchain-based access control method, characterized in that, include: In response to a transaction on the blockchain that invokes a smart contract, obtain permission management information related to the smart contract, wherein the permission management information is stored on the blockchain. The initiator of the transaction is identified based on the permission management information; the identification does not rely on the permission contract and is executed directly on the blockchain without entering the blockchain's virtual machine. as well as Based on the verification result of the initiator's identity, the transaction is selectively sent to the smart contract; Verifying the identity of the initiator of the transaction based on the aforementioned access control information includes: Obtain the initiator's identity information on the blockchain, wherein the identity information includes the organization and role to which they belong; and The identity information is verified based on the permission management information to verify the identity of the initiator. The permission management information includes a blacklist mode or a whitelist mode management mode and a permission expression used to represent the scope of permission control. The verification of the identity information based on the access control information includes: Determine whether the organization and role of the initiator satisfy the permission expression; In response to the fulfillment of the permission expression and the management mode being whitelisted, the authentication of the initiator is determined to be successful; or in response to the failure to fulfill the permission expression and the management mode being whitelisted, the authentication of the initiator is determined to be unsuccessful. In response to the satisfaction of the permission expression and the management mode being blacklist mode, it is determined that the authentication of the initiator has failed; or in response to the non-satisfaction of the permission expression and the management mode being blacklist mode, it is determined that the authentication of the initiator has passed. The method further includes: obtaining a list of organizational expressions and a list of role IDs related to the smart contract; and The permission expression is determined using the organization expression list and the role ID list; The organization expression supports both exact and fuzzy matching. Determining whether the organization and role of the initiator satisfy the permission expression includes: Based on the Cartesian product of the organization expression list and the role ID list, it is determined whether the organization and role to which the initiator belongs satisfy the permission expression.

2. The method according to claim 1, characterized in that, The method further includes: In response to the deployment transaction of the smart contract, the permission management information is stored on the blockchain and the smart contract is stored in the virtual machine of the blockchain.

3. The method according to claim 2, characterized in that, The method further includes: In response to the permission update transaction of the smart contract, obtain the updated permission management information; Determine whether the initiator of the permission update transaction is the designated initiator; and In response to the fact that the initiator of the permission update transaction is a designated initiator, the updated permission management information is bound to the smart contract.

4. The method according to claim 1, characterized in that, Selectively sending the transaction to the smart contract includes: In response to successful authentication of the initiator, the transaction is sent to the smart contract for execution based on the smart contract; or In response to the failure to authenticate the initiator, an error message is displayed.

5. A device, characterized in that, include: processor; as well as A memory storing computer instructions for blockchain-based access control, which, when executed by the processor, cause the device to perform the method according to any one of claims 1-4.

6. A computer program product, characterized in that, Includes blockchain-based access control program instructions, which, when executed by a processor, cause the implementation of the method according to any one of claims 1-4.

Images