Authority management method and device based on block chain, equipment, medium and product

Abstract

The invention provides an authority management method based on a block chain. The authority management method can be applied to the technical field of block chains. The method comprises the steps of obtaining N block chain permission transactions associated with a preset permission from a block chain in response to a request for verifying the preset permission of a target business party; the N block chain permission transactions are used for representing an authorization relation chain from a permission source party of the preset permission to the target business party; n is a positive integer; and determining that the preset permission of the target business party passes the verification under the condition that the authorization relationship chain passes the verification based on the N block chain permission transactions. The invention further provides an authority management device and equipment based on the block chain, a storage medium and a program product.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a blockchain-based permission management method, device, equipment, medium, and product. Background Technology

[0002] With the widespread adoption of digitalization, many business operations can be conducted digitally. To facilitate management, access control can be implemented. For example, different access permissions can be assigned to external and internal users, making it easier to manage user access. Summary of the Invention

[0003] This application provides a blockchain-based permission management method, apparatus, device, medium, and product.

[0004] According to a first aspect of this application, a permission management method is provided, comprising: in response to a request to verify preset permissions for a target business party, obtaining N blockchain permission transactions associated with the preset permissions from a blockchain; the N blockchain permission transactions are used to represent: an authorization relationship chain from the permission source of the preset permissions to the target business party; the N is a positive integer; and if it is determined that the authorization relationship chain has passed verification based on the N blockchain permission transactions, determining that the preset permissions of the target business party have passed verification.

[0005] The second aspect of this application provides another blockchain-based permission management method applied to a first business party. The method includes: when it is determined that a preset permission will be granted to a second business party, constructing a blockchain permission transaction associated with the preset permission; the constructed blockchain permission transaction is used to represent: the first business party grants the preset permission to the second business party; storing the constructed blockchain permission transaction in a blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permission; the P blockchain permission transactions are used to represent: an authorization relationship chain from the permission source of the preset permission to the second business party; where P is a positive integer.

[0006] A third aspect of this application provides a blockchain-based permission management device, comprising: a transaction acquisition unit, configured to, in response to a request to verify preset permissions for a target business party, acquire N blockchain permission transactions associated with the preset permissions from the blockchain; the N blockchain permission transactions are used to represent: an authorization relationship chain from the permission source of the preset permissions to the target business party; the N being a positive integer; and a verification unit, configured to, if the authorization relationship chain is verified based on the N blockchain permission transactions, determine that the preset permissions of the target business party have passed verification.

[0007] A fourth aspect of this application provides another blockchain-based permission management device applied to a first business party. The device includes: a construction unit, configured to construct a blockchain permission transaction associated with the preset permission when it is determined that a preset permission will be granted to a second business party; the constructed blockchain permission transaction represents that the first business party grants the preset permission to the second business party; and an on-chain unit, configured to store the constructed blockchain permission transaction in a blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permission; the P blockchain permission transactions represent an authorization relationship chain from the permission source of the preset permission to the second business party; where P is a positive integer.

[0008] A fifth aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0009] A sixth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0010] A seventh aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0011] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0012] Figure 1 The illustration shows an application scenario diagram of a blockchain-based access control method according to an embodiment of this application;

[0013] Figure 2 The flowchart illustrating a blockchain-based access control method according to an embodiment of this application is shown in the illustration.

[0014] Figure 3 This illustration schematically shows a structural diagram of a blockchain permission transaction according to an embodiment of this application;

[0015] Figure 4 This illustration schematically depicts a reference relationship between blockchain permission transactions according to an embodiment of this application;

[0016] Figure 5 The flowchart illustrating another blockchain-based access control method according to an embodiment of this application is shown schematically.

[0017] Figure 6 The diagram illustrates a structural block diagram of a blockchain-based access control device according to an embodiment of this application.

[0018] Figure 7 The diagram schematically illustrates a structural block diagram of another blockchain-based access control device according to an embodiment of this application;

[0019] Figure 8 The diagram illustrates an electronic device suitable for implementing a blockchain-based access control method according to an embodiment of this application. Detailed Implementation

[0020] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0021] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0022] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0023] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0024] With the widespread adoption of digitalization, many businesses can be conducted digitally. To facilitate management, access control can be implemented. For example, different access permissions can be assigned to external and internal users, making it easier to manage user access. Embodiments of this application provide a blockchain-based access control method. In this method, the authorization relationship chain of permissions can be stored in the blockchain, which improves the security, trustworthiness, and verifiability of the authorization relationship chain.

[0025] The authorization relationship chain can include authorization relationships between different business parties for the same permissions. For example, business party A grants device access permissions to business party B, and business party B grants device access permissions to business party C. This authorization relationship information can be represented by the authorization relationship chain, also known as authorization flow information. A specific authorization relationship chain format is, for example, business party A - business party B - business party C.

[0026] When verifying the permissions of any business party, the authorization relationship chain corresponding to the permission can be retrieved from the blockchain for verification. Specifically, the authorization relationship chain can be the chain from the permission source to the business party requiring verification. This facilitates permission verification based on the source of the permission and the preceding authorization relationships throughout the entire chain, improving the security and comprehensiveness of permission verification. The form of the authorization relationship chain is not limited; it can be represented by one or more blockchain transactions, stored in a single blockchain transaction, or combined, with the information of preceding authorization relationship chains stored in each blockchain transaction representing the authorization relationship chain. Specifically, the authorization relationship chain is stored in the blockchain through blockchain transactions. For example, when a permission grantor A grants permissions to a permission recipient B, permission grantor A can store the relevant authorization information in a blockchain transaction. This storage facilitates subsequent retrieval of the blockchain transaction for permission verification. The relevant authorization information can include verifiable authorization credentials. This method can improve the security and reliability of authorization verification by storing the information of the authorization relationship chain in the blockchain, which facilitates subsequent authorization verification.

[0027] It should be noted that the methods and apparatus disclosed in the embodiments of this application can be used in the field of blockchain technology, and also in the field of fintech. For example, for financial-related permissions, permission management can be performed using the above methods; it can also be applied to any field other than fintech, for example, permission management can also be performed using the above methods for permissions of IoT devices or databases. The application fields of the methods and apparatus disclosed in the embodiments of this application are not limited.

[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in the embodiments of this application all provide users with corresponding operation entry points for users to choose to agree to or refuse the automated decision-making results; if the user chooses to refuse, the process proceeds to expert decision-making. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making decisions. Here, expert decision-making refers to the activity of making decisions by personnel who are specifically engaged in related work, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0029] Figure 1 The diagram illustrates an application scenario of a blockchain-based access control method according to an embodiment of this application. For example... Figure 1As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc. Users can use the first terminal device 101, the second terminal device 102, or the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications may be installed on the first terminal device 101, the second terminal device 102, or the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (only examples). The first terminal device 101, the second terminal device 102, or the third terminal device 103 can be various electronic devices with displays and supporting web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers. Server 105 can be a server providing various services, such as a backend management server (for example only) that supports websites browsed by users using the first terminal device 101, the second terminal device 102, or the third terminal device 103. The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. Server 105 can also be a node in a blockchain. For example, users can interact with server 105 through the first terminal device 101, the second terminal device 102, or the third terminal device 103 to upload or query blockchain transactions.

[0030] It should be noted that the blockchain-based permission management method provided in this application embodiment can generally be executed by server 105, first terminal device 101, second terminal device 102, or third terminal device 103. Correspondingly, the blockchain-based permission management device provided in this application embodiment can generally be located in server 105, first terminal device 101, second terminal device 102, or third terminal device 103. The blockchain-based permission management method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 but can communicate with first terminal device 101, second terminal device 102, third terminal device 103, and / or server 105. Correspondingly, the blockchain-based permission management device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 but can communicate with first terminal device 101, second terminal device 102, third terminal device 103, and / or server 105. It should be understood that... Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0031] The blockchain-based permission management method provided in this application can be divided into two stages: the on-chain stage of storing the permission granting process in the blockchain, and the verification stage of verifying permissions based on the permission granting process stored in the blockchain.

[0032] It is understandable that the above two stages can be considered as separate permission management methods. The on-chain stage involves storing the permission granting process on the blockchain, achieving trusted storage of the permission granting process and improving its security, trustworthiness, and verifiability. The verification stage, on the other hand, is not limited to the specific method of storing the permission granting process on the blockchain; it verifies the permission granting process stored on the blockchain, which can improve the security, trustworthiness, and verifiability of the permission granting process, and also enhance the security and trustworthiness of the permission verification process.

[0033] For ease of understanding, in a specific example, a permission source grants device permission to business party A, business party A grants that permission to business party B, and business party B can then grant that permission to business party C. During the on-chain phase, the permission source, business party A, and business party B can all store the corresponding permission granting information on the blockchain during the permission granting process, so that the blockchain can store the permission granting process.

[0034] In another specific example, during the verification phase, the permission granting process information of "permission source party - business party A - business party B - business party C" stored in the blockchain can be used to verify the permissions of business party A, business party B, or business party C. Specifically, the above permission granting process information stored in the blockchain can be obtained to verify whether there are any problems with the complete permission granting process, thereby determining whether the corresponding business party still has the permission.

[0035] The verification phase will be explained first. Figure 2 A flowchart illustrating a blockchain-based access control method according to an embodiment of this application is shown schematically. Figure 2 As shown, the method flow of this embodiment may include operations S210 to S220. This application embodiment does not limit the executing entity of the blockchain-based permission management method. Optionally, it can be applied to any electronic device or any software application, such as a terminal or server, and can also be applied to a permission verification party, a permission management party, etc.

[0036] In operation S210, in response to a request to verify the preset permissions of the target business party, N blockchain permission transactions associated with the preset permissions are obtained from the blockchain; the N blockchain permission transactions are used to represent the authorization relationship chain from the source of the preset permissions to the target business party; N is a positive integer.

[0037] In operation S220, if the authorization relationship chain is verified based on the obtained N blockchain permission transactions, the preset permissions of the target business party are verified.

[0038] This method can improve the security, trustworthiness, and verifiability of the authorization relationship chain by storing information about the authorization relationship chain with preset permissions in the blockchain.

[0039] This method can also perform permission verification by targeting the authorization relationship chain from the permission source to the target business party, which can improve the security, reliability and comprehensiveness of permission verification.

[0040] The embodiments of this application do not limit the target business party. The target business party can be any business party; for ease of description, any business party requiring verification of preset permissions will be referred to as the target business party. The embodiments of this application also do not limit the business party. Optionally, the business party can be an organization, a user, a device, a software application, a server, etc. In a specific example, the target business party can be a target user, thereby enabling verification of the target user's preset permissions.

[0041] The embodiments of this application do not limit the preset permissions. A preset permission can be any permission; for ease of description, any permission that needs to be verified will be referred to as a preset permission. Optionally, a preset permission can be a data access permission, a device management permission, a network communication permission, etc.

[0042] In a specific example, the target business entity can be a target user, and the preset permissions can be access permissions for IoT devices, thus enabling verification of the target user's IoT device access permissions. The executing entity can be the IoT device itself, which can verify the permissions of the target user who needs to access it. If the verification is successful, the IoT device can allow the target user to access its own data.

[0043] The embodiments of this application do not limit the executing entity. Optionally, the executing entity can be the target business party, specifically, the target business party can verify whether it has preset permissions. The executing entity can also be the source of the preset permissions, which can verify the preset permissions of the target business party. The preset permissions can specifically be permissions to access a certain device or a certain business party. Therefore, the executing entity can also be the object to which the preset permissions are used, such as the device or business party to which the preset permissions are used. By verifying the preset permissions of the target business party, and correspondingly, if the verification is successful, the target business party can be allowed to access itself.

[0044] The following sections will explain various aspects of this method and process.

[0045] 1. In operation S210, in response to a request to verify the preset permissions of the target business party, N blockchain permission transactions associated with the preset permissions are obtained from the blockchain; the N blockchain permission transactions are used to represent the authorization relationship chain from the source of the preset permissions to the target business party; N is a positive integer.

[0046] 1. A request to verify the preset permissions of the target business party. The embodiments of this application are not limited to a request to verify the preset permissions of the target business party. Optionally, the verification of the preset permissions of the target business party may be initiated upon receiving a request to verify the preset permissions. Alternatively, the verification of the preset permissions of the target business party may be triggered upon receiving a request from the target business party to use the preset permissions, and if the verification is successful, the target business party may be allowed to use the preset permissions.

[0047] The embodiments of this application are not limited to the initiator of the request to verify the preset permissions of the target business party. Optionally, the request to verify the preset permissions of the target business party may be initiated by the executing entity itself, the target business party may initiate the request to verify the preset permissions of the target business party, or other business parties or other devices may initiate the request to verify the preset permissions of the target business party. For example, if the target business party grants preset permissions to any other business party, that other business party may first verify the preset permissions of the target business party, and then initiate a request to verify the preset permissions of the target business party.

[0048] 2. Blockchain. The embodiments of this application are not limited to blockchain. Optionally, the blockchain may specifically be a public blockchain, a private blockchain, or a consortium blockchain, etc. The entity executing this method can access the blockchain and obtain the information stored in it.

[0049] The embodiments of this application do not limit the specific storage content of the blockchain. Optionally, the blockchain may at least store an authorization relationship chain from the source of the preset permission to the target business party, thereby facilitating the acquisition of information on the authorization relationship chain for permission verification. The blockchain may store information representing the authorization relationship chain, and the specific form is not limited. Optionally, the blockchain may store blockchain permission transactions, which may contain authorization relationship chains, and the information on the authorization relationship chain can be obtained from the blockchain permission transactions. Optionally, the blockchain may store blockchain permission transactions associated with the preset permission. This embodiment does not limit the blockchain permission transactions associated with the preset permission; specifically, it may be a blockchain transaction representing the authorization relationship of the preset permission, or a blockchain transaction representing the authorization process of the preset permission, etc., thereby facilitating the determination of the blockchain permission transaction representing the authorization relationship chain of the preset permission from the blockchain permission transactions associated with the preset permission, and further determining the authorization relationship chain of the preset permission. For a detailed explanation, please refer to other embodiments.

[0050] The embodiments of this application do not limit the specific method and process of storing the authorization relationship chain in the blockchain. Specifically, any business party can store the authorization relationship chain in the blockchain, or during the authorization process of preset permissions, the permission grantor can store the authorization process information in the blockchain to form an authorization relationship chain stored in the blockchain. For a more detailed explanation, please refer to other embodiments.

[0051] The embodiments of this application are not limited to the value of N. Optionally, it can be a single blockchain permission transaction or multiple blockchain permission transactions. Among them, N blockchain permission transactions can be used to represent the authorization relationship chain from the permission source of the preset permission to the target business party.

[0052] In one optional embodiment, a single blockchain permission transaction can store the entire authorization relationship chain, or multiple blockchain permission transactions can store different information of the authorization relationship chain respectively, so that the information of the authorization relationship chain can be obtained from multiple blockchain permission transactions. Alternatively, any one of the multiple blockchain permission transactions can be used to store relevant information of a single authorization process in the authorization relationship chain.

[0053] 3. Authorization Relationship Chain. Optionally, the blockchain can store information about the authorization relationship chain. By obtaining N blockchain permission transactions that represent the authorization relationship chain from the blockchain, the authorization relationship chain can be further obtained or determined from the obtained N blockchain permission transactions for subsequent steps.

[0054] The authorization relationship chain is explained below. The embodiments of this application do not limit the specific structure, form, or content of the authorization relationship chain. Specifically, the authorization relationship chain can be used to represent the authorization flow process of preset permissions; specifically, it can be used to represent the process of granting and transferring preset permissions between different business parties, starting from the source of the preset permissions. It is understood that the authorization relationship chain can be stored in the blockchain in the form of a chain structure, stored as an actual data structure, or stored as business information by comprehensively representing multiple data points.

[0055] For example, a source of preset permissions grants preset permissions to business party A, business party A grants preset permissions to business party B, and business party B can then grant preset permissions to business party C. For this authorization flow of preset permissions, the authorization relationship chain can specifically take the form of "permission source - business party A - business party B - business party C," and can be stored as a data structure. Alternatively, the authorization relationship chain can take the form of multiple authorization credentials for preset permissions, specifically including authorization credentials for "permission source granting preset permissions to business party A," "business party A granting preset permissions to business party B," and "business party B granting preset permissions to business party C." Based on these three authorization credentials, an authorization relationship chain can be determined, serving as a identifiable piece of business information. Of course, the form of the authorization credentials is merely illustrative; other information capable of representing the authorization process can also be used to represent the authorization relationship chain.

[0056] Accordingly, it can be understood that for the N blockchain permission transactions used to represent the authorization relationship chain, the blockchain permission transactions may optionally contain the authorization relationship chain data structure or the authorization certificate, thereby determining the authorization relationship chain.

[0057] In one optional embodiment, the complete authorization flow for preset permissions can be represented by a tree structure or a graph structure. For example, the permission source can grant preset permissions to one or more business parties, and each business party can further grant preset permissions to one or more other business parties. For the preset permissions of the target business party, a cascading relationship of the authorization flow from the permission source to the target business party can be traced and determined, which can be used for permission verification.

[0058] Therefore, optionally, the authorization relationship chain can specifically be a cascading relationship of authorization flow. The authorization relationship chain can include: authorization relationship flow information used to represent the i-th permission grantor granting the preset permission to the i-th permission receiver; i=1,…,M; M is a positive integer; where the 1st permission grantor is the permission source of the preset permission, and the M-th permission receiver is the target business party; when M is greater than 1, the j-th permission receiver is the (j+1)-th permission grantor; j=1,…,M-1.

[0059] This embodiment can easily determine the overall authorization flow in the authorization relationship chain, from the source of the preset permission to the target business party, directly or indirectly through the intermediary business party, by using specific authorization relationship flow information. This can improve the completeness of authorization information, facilitate verification, and enhance the security, reliability, and comprehensiveness of permission verification.

[0060] Where M can be equal to N, or M can be unequal to N. It is understood that, optionally, a single blockchain permission transaction associated with a preset permission can be used to represent a single authorization process of the preset permission. This blockchain permission transaction can contain authorization relationship flow information of the represented authorization process, and correspondingly, N can be equal to M. Optionally, a single blockchain permission transaction associated with a preset permission can be used to represent multiple authorization processes of the preset permission. This blockchain permission transaction can contain authorization relationship flow information of the represented authorization process, and correspondingly, N can be unequal to M, specifically, N can be less than M. Optionally, a single blockchain permission transaction associated with a preset permission can be used to represent a single authorization process of the preset permission. This blockchain permission transaction can contain authorization relationship flow information of the represented authorization process, and among the N blockchain permission transactions associated with the preset permission, there can be authorization flow relationships of the preset permission other than the "authorization relationship chain from the permission source to the target business party." Therefore, N can be unequal to M, specifically, N can be greater than M.

[0061] In this application's embodiments, the permission grantor and permission recipient can be roles played by a business entity during the authorization process. It is understood that the same business entity can act as either a permission grantor or a permission recipient in different authorization processes. The permission grantor can be used to grant permissions to the permission recipient, and the permission recipient can be used to obtain the permissions granted by the permission grantor.

[0062] The embodiments of this application do not limit the specific form and content of the authorization relationship flow information, but can be used to represent the process of granting a single permission. Optionally, the authorization relationship flow information can be used to represent at least one of the following: permission grantor information, permission recipient information, and preset permission information, etc.

[0063] 4. Source of Authority. The embodiments of this application do not limit the source of authority. Optionally, the source of preset authority may specifically be a business entity providing the preset authority. For example, for access permissions to IoT devices, the administrator of the IoT device can provide access permissions and grant them to other business entities. The source of preset authority may also be a business entity that registers the preset authority. Specifically, it may be a business entity that registers the preset authority in the blockchain. For example, a business entity can register its own access permissions, thus becoming the source of authority and granting its own access permissions to other business entities. This can be done by registering it in the blockchain for convenient access management based on the blockchain. The source of preset authority may also be the administrator of the preset authority. For example, for database access permissions, the administrator of the database can be the source of authority and grant database access permissions to other business entities.

[0064] It should be noted that the source of the permissions can act as the origin of the preset permissions, thus facilitating the tracing of complete information regarding the authorization flow of preset permissions according to the authorization relationship chain. Storing this information in the blockchain can improve the security and trustworthiness of the authorization relationship chain. Furthermore, it allows for verification of whether any business party still possesses preset permissions based on the authorization relationship chain, enhancing the security and comprehensiveness of permission verification. In an optional embodiment, the authorization relationship chain may also include the registration information of the preset permissions from the source of the permissions. The source of the permissions can register the preset permissions in the blockchain, thereby storing the corresponding registration information of the preset permissions in the blockchain. For example, a preset permission could be an access permission for a specific IoT device. The source of the permissions can then generate the registration information of the preset permissions based on the information of the IoT device and store it in the blockchain, specifically through blockchain transactions. The authorization relationship chain can also include the registration information of the preset permissions for subsequent permission verification.

[0065] 5. Blockchain Permission Transactions. The embodiments of this application do not limit the specific way in which blockchain permission transactions represent the authorization relationship chain. Optionally, the blockchain permission transaction may directly include information about the authorization relationship chain, or it may include information used to represent the authorization relationship chain.

[0066] Optionally, a single blockchain permission transaction can be used to represent a single permission granting process. Optionally, any one of the N blockchain permission transactions can be used to represent: the permission grantor grants a preset permission to the permission recipient; any one of the N blockchain permission transactions contains: authorization-related information used to represent the permission grantor granting the preset permission to the permission recipient.

[0067] In this embodiment, a single blockchain permission transaction can represent a single authorization process. This transaction can contain authorization-related information, thereby improving the security, reliability, verifiability, and traceability of this information, and facilitating the enhancement of the security and comprehensiveness of permission verification. Correspondingly, a single blockchain permission transaction associated with a preset permission can be used to represent the authorization-related information of a single authorization process for that preset permission.

[0068] The embodiments of this application do not limit the specific form and content of the authorization-related information. Optionally, the authorization-related information can be used to characterize a single authorization process, and may specifically include information on the authorization grantor, information on the authorization recipient, and preset authorization information. For a detailed explanation, please refer to the explanations of other embodiments.

[0069] The embodiments of this application do not limit the method of obtaining blockchain permission transactions, nor do they limit the specific method of obtaining blockchain permission transactions associated with preset permissions. Optionally, the blockchain permission transaction associated with the preset permission may contain information about the preset permission (e.g., the identifier information of the preset permission), so that blockchain transactions in the blockchain can be queried based on the preset permission information, and the blockchain transaction containing the preset permission information can be identified as the blockchain permission transaction associated with the preset permission. Of course, other query or acquisition methods can also be used.

[0070] The embodiments of this application do not limit the specific content of the blockchain permission transactions. Optionally, in addition to the authorization-related information representing the "authorization process of this preset permission", it may also include authorization-related information of the corresponding prior authorization process, which can facilitate permission verification. Optionally, blockchain permission transaction k in N blockchain permission transactions is used to represent the kth permission grantor granting the preset permission to the kth permission recipient; blockchain permission transaction k includes: authorization-related information representing the xth permission grantor granting the preset permission to the xth permission recipient; x=1,…,k; k is a positive integer less than or equal to M. It can be understood that the first permission grantor can be the permission source, and blockchain permission transaction 1 may include: authorization-related information representing the permission source granting the preset permission to the first permission recipient.

[0071] In this embodiment, by storing the authorization-related information of the current preset permission authorization process and the authorization-related information of the previous authorization process into the corresponding blockchain permission transaction, the comprehensiveness, security, credibility and verifiability of the authorization information in the blockchain permission transaction can be improved, which can facilitate the improvement of the security and comprehensiveness of permission verification.

[0072] It should be noted that the k authorization-related information items included in the blockchain permission transaction k in this embodiment can be used to represent the corresponding authorization relationship chain, and thus can also be used for permission verification, improving the comprehensiveness and accuracy of permission verification. Specifically, the k authorization-related information items can be used to represent the authorization relationship chain "from the permission source to the kth permission recipient," and thus can be used to verify the preset permissions of the kth permission recipient. For specific verification methods, please refer to the explanations of other method embodiments.

[0073] For ease of understanding, in a specific example, authorization-related information may include authorization credentials. For simplicity, authorization credentials may specifically be tokens. Token-x can represent that the xth permission grantor grants a preset permission to the xth permission recipient. Correspondingly, the blockchain permission transaction k may contain only token-k, or it may contain k tokens from token-1 to token-k. The k tokens can represent the authorization relationship chain "from the permission source to the kth permission recipient," facilitating verification of this authorization relationship chain. Specifically, verification can be performed on the k tokens. Successful verification confirms that the preset permission of the kth permission recipient has been verified, thus confirming that the kth permission recipient possesses the preset permission.

[0074] Optionally, in addition to the authorization-related information that represents the "authorization process of this preset permission", the blockchain permission transaction may also include other information, such as permission grantor information, permission recipient information, and verification information that can be used to verify that the permission grantor has made this authorization.

[0075] The embodiments of this application do not limit the specific content or form of the information to be verified, nor do they limit the verification method. Optionally, a digital signature can be used, whereby the private key of the authorization grantor is used to encrypt the digest of specified information in the blockchain authorization transaction to obtain a digital signature. This embodiment does not limit the content of the specified information to be digitally signed; it can specifically be authorization-related information. Based on the digital signature, it is convenient to verify the digital signature using the public key of the authorization grantor. For example, the integrity and correctness of authorization-related information can be verified based on the digital signature, and it can also be verified that the authorization-related information was provided by the authorization grantor.

[0076] In addition, optionally, the content in a blockchain permission transaction can be set to ciphertext to improve its security. The embodiments of this application do not limit the specific encryption protection method. Optionally, the information to be encrypted in the blockchain permission transaction can be encrypted using the permission recipient's public key, allowing the permission recipient to decrypt it using their private key. Alternatively, the information to be encrypted can be encrypted first, and then the corresponding decryption key can be encrypted using the permission recipient's public key, allowing the permission recipient to encrypt using their own private key to obtain the decryption key, and further decrypt the ciphertext of the information to be encrypted based on the decryption key.

[0077] Therefore, optionally, any of the N blockchain permission transactions may further include at least one of the following: permission grantor information, permission recipient information, a digital signature of the permission grantor on the plaintext of the authorization-related information, and a preset decryption key encrypted based on the permission recipient's public key. The authorization-related information is in ciphertext form, and the preset decryption key is used to decrypt the ciphertext authorization-related information.

[0078] In this embodiment, a digital signature of the permission grantor can be set in the blockchain permission transaction to improve the security, trustworthiness, and verifiability of the authorization-related information. The authorization-related information can also be set in encrypted form, and the corresponding preset decryption key can be encrypted using the permission recipient's public key to further enhance the security and trustworthiness of the authorization-related information. It is understood that the information content in the above-described blockchain permission transaction is merely illustrative. Optionally, the blockchain permission transaction may include at least one of the following: a digital signature of the permission grantor for other information, a digital signature of the permission grantor for authorization-related information (in encrypted form), etc. Furthermore, the permission recipient can obtain the plaintext authorization-related information through the blockchain permission transaction, thereby confirming that they have been granted preset permissions.

[0079] Optionally, the digital signature of the permission grantor for the plaintext of the authorization-related information can be a digital signature for the authorization-related information representing "the authorization process of this preset permission", or it can be the digital signature of each of the k authorization-related information contained in the above blockchain permission transaction k, that is, the digital signature of the permission grantor for the authorization-related information of "the authorization process of this preset permission", and the digital signature of the permission grantor for the prior authorization-related information in the corresponding prior authorization process.

[0080] Optionally, for N blockchain permission transactions associated with preset permissions, the blockchain permission transactions may contain association information with other blockchain permission transactions. For example, different blockchain permission transactions can be associated by combining authorization relationship chains. Specifically, blockchain permission transactions representing two adjacent authorization processes can be associated, which facilitates subsequent queries and makes it easier to determine the order of authorization processes in the authorization relationship chain.

[0081] The embodiments of this application do not limit the relationship between blockchain permission transactions. Optionally, blockchain permission transaction k in N blockchain permission transactions is used to represent that the k-th permission grantor grants the preset permission to the k-th permission receiver; k is a positive integer less than or equal to M. Wherein, when k is greater than 1, blockchain permission transaction k may also contain reference information for blockchain permission transaction k-1. This embodiment can store reference information of other blockchain permission transactions used to represent the pre-authorization process through blockchain permission transactions. It can store one or more reference information, which facilitates querying blockchain permission transactions associated with the preset permission in the blockchain and improves the query efficiency of blockchain permission transactions.

[0082] The embodiments of this application do not limit the specific content and form of the reference information for blockchain permission transactions. Optionally, the reference information may specifically include the identification information of the referenced blockchain permission transaction, or its location information in the blockchain, etc., which can facilitate the querying of the referenced blockchain permission transaction based on the reference information and improve query efficiency. For example, blockchain permission transaction k may include at least one of the following information of blockchain permission transaction k-1: transaction identification information and blockchain location information, etc., for querying the transaction.

[0083] The embodiments of this application do not limit the specific content of the authorization-related information. The authorization-related information can be used to characterize a single authorization process. Optionally, the authorization-related information may include information about the grantor of permissions, the recipient of permissions, and preset permission information during the single authorization process. The authorization-related information may also include authorization credentials for the single authorization process, which can serve as proof of the single authorization process for subsequent permission verification. Correspondingly, it may also include information to be verified regarding the information of the single authorization process, which can improve information security and verifiability.

[0084] Optionally, the authorization-related information may include: an authorization credential from the authorization grantor to grant preset permissions to the authorization recipient. The embodiments of this application do not limit the specific form and content of the authorization credential. Optionally, the authorization-related information may include: an authorization credential from the authorization grantor to grant preset permissions to the authorization recipient, and a digital signature from the authorization grantor regarding the authorization credential. Optionally, the authorization credential may include at least one of the following: information about the preset permissions, information about the authorization grantor, information about the authorization recipient, and information about the validity period of the preset permissions, used to characterize whether the authorization recipient can grant the preset permissions to other business parties. In this embodiment, the security and comprehensiveness of permission verification can be improved through information such as the digital signature in the authorization-related information and the validity period information in the authorization credential.

[0085] Optionally, based on the "digital signature of the grantor for the authorization credential" included in the authorization-related information, blockchain authorization transaction k in N blockchain authorization transactions can be used to represent that the k-th authorization grantor grants a preset permission to the k-th authorization recipient. Blockchain authorization transaction k can contain: authorization-related information representing that the x-th authorization grantor grants a preset permission to the x-th authorization recipient; x = 1, ..., k; k is a positive integer less than or equal to M. The k authorization-related information can contain the digital signature of the corresponding authorization grantor for the authorization credential. In other words, blockchain authorization transaction k can contain: the authorization credential representing that the x-th authorization grantor grants a preset permission to the x-th authorization recipient, and the digital signature of the x-th authorization grantor for that authorization credential; x = 1, ..., k. Through the digital signatures of each authorization grantor, the credibility and verifiability of the authorization granting process can be improved, as well as the comprehensiveness and accuracy of authorization verification.

[0086] Optionally, the validity period information of the preset permissions may include the validity period information of the preset permissions granted by the permission grantor to the permission recipient, or it may include the validity period information of the preset permissions of the permission grantor itself. It is understood that the valid time period represented by the validity period information of the preset permissions granted by the permission grantor to the permission recipient can be within the valid time period represented by the validity period information of the preset permissions of the permission grantor itself.

[0087] Optionally, the grantor needs to possess distribution permissions for the preset permissions in order to grant the preset permissions to other business parties. Distribution permissions for the preset permissions can be used to represent the ability to grant the preset permissions to other business parties. Therefore, the authorization credentials may include information indicating that the grantor possesses distribution permissions.

[0088] The embodiments of this application do not limit the specific content and form of the preset permission information, permission grantor information, and permission recipient information. Optionally, they can be permission identifier information of the preset permission, business party identifier information of the permission grantor, business party identifier information of the permission recipient, etc. The corresponding preset permission, permission grantor, and permission recipient can be determined according to the preset permission information, permission grantor information, and permission recipient information, respectively. In a specific example, the authorization-related information can specifically be information related to the authorization process of the preset permission in the blockchain permission transaction, which can include the authorization certificate representing the authorization process. The specific form of the authorization certificate can be a token. It is understood that the blockchain permission transaction can include the authorization certificate token of this authorization process, as well as the authorization certificate token of the corresponding previous authorization process. Specifically, it can include the authorization certificate token between the permission source of the preset permission and the permission recipient in the current authorization process.

[0089] For ease of understanding, Figure 3 The illustration shows a schematic diagram of a blockchain permission transaction according to an embodiment of this application. In this diagram, the blockchain permission transaction k represents the k-th permission grantor granting a preset permission to the k-th permission receiver. k is a positive integer less than or equal to M.

[0090] A blockchain permission transaction k can include an authorization plaintext segment, specifically including permission grantor information, permission recipient information, and referencing transaction information. Specifically, the permission grantor information can be the business entity identifier of the k-th permission grantor, the permission recipient information can be the business entity identifier of the k-th permission recipient, and the referencing transaction information can be used to represent blockchain permission transaction k-1 (representing that the (k-1)-th permission grantor grants a preset permission to the (k-1)-th permission recipient, where k is greater than 1).

[0091] A blockchain-based permission transaction k may include an authorization information segment, which specifically may include multiple authorization tokens and the digital signatures of the corresponding permission grantors. For example, the authorization information segment may include token-1, token-2, ..., token-k, and correspondingly, the digital signatures of the first permission grantor for token-1, the second permission grantor for token-2, ..., and the kth permission grantor for token-k. These digital signatures can be verified. To enhance the security of the authorization information segment, a preset symmetric key can be used to encrypt the information within it.

[0092] A blockchain permission transaction k may include a verification segment, which may include a digest of token-k and a digital signature of the token-k digest by the k-th permission grantor. The blockchain permission transaction k may also include a pre-set symmetric key used to decrypt the plaintext of the authorization segment; this pre-set symmetric key can be encrypted based on the public key of the k-th permission recipient.

[0093] For ease of understanding, Figure 4 This illustration schematically depicts a reference relationship between blockchain permission transactions according to an embodiment of this application. The authorization process for preset permissions can be as follows: The permission source grants preset permissions to business party A. The permission source constructs blockchain permission transaction 1, which may or may not reference other transactions, or may reference the registration transaction used to register the preset permissions. Business party A can then grant the preset permissions to business party B. Business party A can construct blockchain permission transaction 2 and apply blockchain permission transaction 1. Business party B can then grant the preset permissions to business party C. Business party B can construct blockchain permission transaction 3 and apply blockchain permission transaction 2. And so on.

[0094] 6. Methods for storing the authorization relationship chain in the blockchain. The embodiments of this application do not limit the specific method of storing the authorization relationship chain in the blockchain. Related explanations can be found in other embodiments. Optionally, the authorization relationship chain can be directly stored in the blockchain, or the corresponding authorization process can be stored in the blockchain as the authorization relationship flows, thus constructing the authorization relationship chain.

[0095] In one optional embodiment, for any authorization process, the corresponding authorization-related information can be stored in the blockchain. Optionally, if the first business party determines to grant a preset permission to the second business party, it can construct a blockchain permission transaction associated with the preset permission; the constructed blockchain permission transaction is used to represent that the first business party grants the preset permission to the second business party; wherein, the first business party and the second business party can be either business party. The first business party can store the constructed blockchain permission transaction in the blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permission; the P blockchain permission transactions are used to represent the authorization relationship chain from the permission source of the preset permission to the second business party; P is a positive integer. It is understood that as the authorization relationship flows, the corresponding business party can continue to construct blockchain permission transactions associated with the preset permission and store them in the blockchain, thereby updating the authorization relationship chain of the preset permission as the blockchain accumulates blockchain permission transactions associated with the preset permission.

[0096] The embodiments of this application do not limit the specific form of the authorization relationship chain. Optionally, the authorization relationship chain stored in the current blockchain may include: authorization relationship flow information representing that the i-th permission grantor grants a preset permission to the i-th permission receiver; i=1,…,P; wherein, the first permission grantor is the permission source of the preset permission, and the P-th permission receiver is the second business party; when P is greater than 1, the j-th permission receiver is the (j+1)-th permission grantor; j=1,…,P-1. For a detailed explanation, please refer to the explanations of other embodiments.

[0097] The embodiments of this application do not limit the specific method of constructing blockchain permission transactions, nor do they limit the specific form and content of blockchain permission transactions. For detailed explanations, please refer to the explanations in other embodiments. Optionally, the constructed blockchain permission transaction may include: authorization-related information representing that the i-th permission grantor grants preset permissions to the i-th permission receiver; i=1,…,P. The blockchain permission transaction may include authorization-related information from the pre-authorization process.

[0098] The embodiments of this application do not limit the specific verification method for blockchain permission transactions, nor do they limit the verification of blockchain permission transactions. Optionally, the authorization-related information contained in the blockchain permission transaction can be used for verification. For example, the authorization process represented by the authorization-related information itself can be used for permission verification, and the authorization credentials contained in the authorization-related information can also be used for permission verification. Optionally, the P authorization-related information contained in the constructed blockchain permission transaction is used to: determine that the second business party is granted a preset permission if the verification of the P authorization-related information is successful. This embodiment does not limit the specific device for verifying blockchain permission transactions, nor does it limit the device for determining whether the second business party is granted a preset permission. Optionally, the second business party itself can verify based on the blockchain permission transaction constructed by the first business party to determine whether it is granted a preset permission and to verify whether the authorization process is compliant and valid. For a detailed explanation, please refer to other embodiments. The first business party can be the target business party, and the second business party can also be the target business party.

[0099] Second, in operation S220, if the authorization relationship chain is verified based on the obtained N blockchain permission transactions, the preset permissions of the target business party are verified.

[0100] In one optional embodiment, if the authorization chain verification passes, it can be determined that the target business party's preset permissions have passed verification, the target business party possesses the preset permissions, and the target business party can use the preset permissions. If the authorization chain verification fails, it can be determined that the target business party's preset permissions have not passed verification, the target business party does not possess the preset permissions, and the target business party cannot use the preset permissions.

[0101] The embodiments of this application do not limit the specific method of verifying the authorization relationship chain. Optionally, it can specifically verify whether the authorization relationship chain meets preset authorization rules, or it can verify whether each authorization flow process in the authorization relationship chain meets the preset authorization rules. Optionally, the authorization relationship chain can be used to represent the authorization flow process from the authorization source to the target business party, and can verify whether each authorization flow process from the authorization source to the target business party is compliant or valid.

[0102] Optionally, it can be verified whether the granting process of preset permissions in each authorization flow within the authorization relationship chain is compliant and valid. This application embodiment does not limit the specific provisions for the compliance and validity of the authorization process. Optionally, at least one of the following can be verified: whether the permission grantor has the distribution permission to grant preset permissions to other business parties; whether the permission recipient meets the requirements of the preset permissions; and whether the authorization process complies with the regulations. Optionally, if it is determined that each authorization flow process from the permission source to the target business party in the authorization relationship chain complies with the regulations, the authorization relationship chain can be determined to have passed verification.

[0103] Optionally, the validity of the preset permissions of each permission grantor in the authorization relationship chain can be verified, which can be the current validity of the preset permissions. The embodiments of this application do not limit the specific provisions regarding the validity of preset permissions. Optionally, the granting of preset permissions can have an expiration date. For preset permissions that have exceeded their expiration date, it can be considered that the corresponding business party does not have the preset permission, and the preset permissions granted to other business parties have also exceeded their expiration date. Correspondingly, the distribution permission for preset permissions can also have an expiration date. Therefore, for each permission grantor, it can be verified whether the current validity period of the preset permission corresponding to the permission grantor has exceeded, whether the current validity period of the distribution permission has exceeded, etc. Optionally, if it is determined that the current preset permissions of each permission grantor in the authorization relationship chain from the permission source party to the target business party are valid, the authorization relationship chain can be verified as passed. Optionally, the permission grantor can revoke the granted preset permissions; for example, the permission grantor can revoke the preset permissions granted to the permission recipient. Therefore, it is possible to determine whether any preset permission has been revoked through the authorization relationship chain, thereby enabling verification. For example, after identifying each permission grantor through the authorization relationship chain, it is possible to determine whether the preset permissions granted to the permission recipients have been revoked, thereby enabling verification. The embodiments of this application do not limit the specific revocation method or the method for determining revocation. Optionally, permissions can be revoked by the permission source, or a blockchain revocation transaction can be constructed to represent the revocation of preset permissions, thereby enabling verification by querying the blockchain revocation transactions.

[0104] It is understood that different verification methods and verification success rules can be combined with each other, and the embodiments of this application do not limit the specific combination method. Optionally, the authorization relationship chain can be determined to be verified as successful if it is determined that each authorization flow process from the source of the permission to the target business party in the authorization relationship chain complies with the regulations and the current preset permissions of each permission grantor are valid.

[0105] Optionally, corresponding to the M authorization relationship flow information in the authorization relationship chain, for a specific explanation, please refer to other embodiments. When the authorization relationship chain is verified based on N blockchain permission transactions, the preset permissions of the target business party are verified. Specifically, it can be: when the M authorization relationship flow information in the authorization relationship chain is verified based on N blockchain permission transactions, the preset permissions of the target business party are verified.

[0106] This embodiment can verify the authorization relationship chain by verifying M authorization relationship flow information, thereby improving the security and comprehensiveness of permission verification. Verifying the M authorization relationship flow information can be a full verification of the authorization relationship chain, improving the comprehensiveness and accuracy of permission verification. In a specific example, verification can be performed on each authorization relationship flow information in the authorization relationship chain. If the authorization process for each corresponding preset permission is found to be compliant, the verification is considered successful. Alternatively, if the authorization process for each corresponding preset permission is found to be compliant and the preset permissions of each current permission grantor are valid, the verification is considered successful.

[0107] Optionally, corresponding to the authorization-related information contained in the blockchain permission transactions, the authorization-related information can be verified to realize the verification of the authorization relationship chain. For a detailed explanation, please refer to other embodiments. The authorization-related information can be used to characterize the corresponding authorization process. If the authorization relationship chain is verified based on N blockchain permission transactions, the preset permissions of the target business party are verified. Specifically, this can be done by determining that the preset permissions of the target business party are verified if the authorization-related information contained in the N blockchain permission transactions is verified.

[0108] This embodiment can verify the authorization relationship chain by verifying authorization-related information in N blockchain permission transactions, thereby improving the security and comprehensiveness of permission verification. Specifically, verifying the N blockchain permission transactions related to preset permissions can be a full verification of the authorization relationship chain, improving the comprehensiveness and accuracy of permission verification. This embodiment does not limit the specific method of verifying authorization-related information, nor does it limit the specific rules for passing the verification of authorization-related information. Optionally, the authorization relationship chain can be verified by verifying authorization-related information. For a detailed explanation, please refer to other embodiments. Optionally, based on the verification of authorization-related information, if it is determined that each authorization flow process in the authorization relationship chain from the permission source to the target business party complies with regulations, and the current preset permissions of each permission grantor are valid, the authorization relationship chain can be determined to have passed verification.

[0109] In one optional embodiment, the N blockchain permission transactions may include registration transactions for preset permissions. Specifically, this may include one registration transaction for preset permissions and M blockchain transactions representing different authorization processes, as explained in other embodiments. Accordingly, verifying the N blockchain permission transactions allows tracing back to the registration transaction for the preset permissions and verifying the entire authorization process, achieving comprehensive verification of the authorization relationship chain and improving the comprehensiveness and accuracy of permission verification. The registration transaction can be used to register preset permissions. This application embodiment does not limit the verification method and process for the registration transaction; specifically, it may verify whether the process of registering permissions is compliant and valid.

[0110] Among the N blockchain permission transactions related to the preset permissions, the authorization-related information contained in any blockchain permission transaction can include authorization-related information of the represented authorization process, as well as authorization-related information of the pre-authorization process. This allows for verification of the authorization-related information of the pre-authorization process in each blockchain permission transaction, thereby improving the security and comprehensiveness of permission verification.

[0111] In a specific example, blockchain permission transaction k in N blockchain permission transactions represents the k-th permission grantor granting a preset permission to the k-th permission recipient. Blockchain permission transaction k contains authorization-related information representing the x-th permission grantor granting the preset permission to the x-th permission recipient; x = 1, ..., k; k is a positive integer less than or equal to M. Of course, when M equals N, k can also be a positive integer less than or equal to N. The authorization-related information can specifically include authorization tokens. Blockchain permission transaction k can contain only token-k, or it can contain k tokens from token-1 to token-k. The k tokens can be used to represent the authorization relationship chain "from the permission source to the k-th permission recipient". Therefore, verification can be performed on the k tokens in blockchain permission transaction k, or it can be performed on all tokens of each of the N blockchain permission transactions.

[0112] The following explanation focuses on the on-chain phase. Figure 5 The flowchart illustrating another blockchain-based access control method according to an embodiment of this application is shown schematically. This application does not limit the specific executing entity; it can be any device or any application. Optionally, the method flow can be applied to a first business party, including steps S310 and S320.

[0113] S310: If it is determined that a preset permission will be granted to a second business party, a blockchain permission transaction associated with the preset permission is constructed; the constructed blockchain permission transaction is used to represent that: the first business party grants the preset permission to the second business party.

[0114] S320: Store the constructed blockchain permission transactions in the blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permissions; the P blockchain permission transactions are used to represent: the authorization relationship chain from the permission source of the preset permissions to the second business party; P is a positive integer.

[0115] This method can improve the security, trustworthiness, and verifiability of the authorization relationship chain by storing information about the pre-defined permissions in the blockchain. The first and second business parties can be either business parties. Specifically, the constructed blockchain permission transaction can be the P-th blockchain permission transaction. For a detailed explanation of this method, please refer to the explanations of other embodiments.

[0116] The embodiments of this application do not limit the specific form of the authorization relationship chain. Optionally, the authorization relationship chain includes: authorization relationship flow information representing that the i-th permission grantor grants the preset permission to the i-th permission receiver; i=1,…,P; wherein, the first permission grantor is the permission source of the preset permission, and the P-th permission receiver is the second business party; when P is greater than 1, the j-th permission receiver is the (j+1)-th permission grantor; j=1,…,P-1.

[0117] This embodiment can improve the security and comprehensiveness of permission verification by storing P authorization relationship flow information contained in the authorization relationship chain into the blockchain.

[0118] The embodiments of this application do not limit the specific method of constructing blockchain permission transactions, nor do they limit the specific form and content of blockchain permission transactions. For specific explanations, please refer to the explanations in other embodiments. Optionally, the constructed blockchain permission transaction includes: authorization-related information representing that the Pth permission grantor (first business party) grants a preset permission to the Pth permission recipient (second business party). Optionally, the constructed blockchain permission transaction includes: authorization-related information representing that the i-th permission grantor grants a preset permission to the i-th permission recipient; i=1,…,P. This embodiment can improve the comprehensiveness, security, credibility, and verifiability of authorization information in blockchain permission transactions by storing the authorization-related information of the current preset permission authorization process and the authorization-related information of the previous authorization process in the corresponding blockchain permission transaction, which can facilitate the improvement of the security and comprehensiveness of permission verification. The first permission grantor can be the permission source of the preset permission.

[0119] The embodiments of this application do not limit the specific verification method for blockchain permission transactions, nor do they limit the verification of blockchain permission transactions. Optionally, the P authorization-related information contained in the constructed blockchain permission transaction is used to: determine that the second business party is granted preset permissions if the verification of the P authorization-related information is successful. Optionally, the authorization-related information contained in the blockchain permission transaction can be used for verification. For example, the authorization process represented by the authorization-related information can be used for permission verification, and the authorization credentials contained in the authorization-related information can also be used for permission verification. This embodiment does not limit the specific device for verifying blockchain permission transactions, nor does it limit the device for determining whether the second business party has been granted preset permissions. Optionally, the second business party itself can verify the blockchain permission transaction constructed by the first business party to determine whether it has been granted preset permissions and to verify whether the authorization process is compliant and valid. For a detailed explanation, please refer to other embodiments. This embodiment provides a method for permission verification by verifying the authorization-related information in the blockchain permission transaction, which can improve the flexibility and comprehensiveness of permission verification.

[0120] The embodiments of this application are not limited to the verification method for the constructed blockchain permission transactions, nor are they limited to the verification method for preset permissions, nor are they limited to the verification method for the authorization relationship chain stored in the blockchain. For details, please refer to other embodiments. It can be understood that the blockchain permission transactions stored in S210 and S220 can be stored through S310 and S320, and the corresponding blockchain permission transactions can have the same interpretation. The blockchain permission transactions stored in S310 and S320 can be verified for permissions through S210 and S220. Therefore, different embodiments in this application can be combined with each other, and the specific combination method is not limited.

[0121] For ease of understanding, this application also provides an application embodiment. With the surge in the number of IoT devices, ensuring these devices are protected from unauthorized access attacks has become particularly important. Once these devices are attacked, it can lead to serious consequences such as data breaches, device damage, and service interruptions. Therefore, in the IoT field, access control mechanisms that ensure device security and user privacy are crucial. Specifically, access permissions for IoT devices can be controlled by assigning specific capability tokens to users. Capability tokens contain information such as the access rights and validity period of resources; users need to carry a valid capability token to access resources. IoT devices can verify these tokens. This embodiment provides a blockchain-based access control scheme, combined with a blockchain transaction model, to achieve privacy protection and flexible permission management.

[0122] First, let's explain the overall authorization process. Each entity (business entity) can have multiple permissions. A token is used to represent a permission, and the token stores the specific details of access permissions to a certain device. The token is the token passed during the authorization process. When the owner of the token wants to use the permission he / she has obtained, he / she only needs to send the token to the device, and execute the permission after verification. The token scheme realizes fine-grained management of permissions, allows entities to have multiple permissions for different devices, and can control the depth of permission transmission. This provides the system with a more flexible and secure access control mechanism, enabling the access control chain to cope with complex and ever-changing access needs. In order to achieve the above requirements, the designed token contains the following fields: (1) The resource entity that provides the service. This field identifies the specific device or resource authorized by the permission. Through the resource entity field, the specific resource that needs to be accessed can be accurately located. (2) The validity period of the specified permission. This field defines the lifecycle of the token to ensure that the permission is valid within the specified time range. (3) The authorization strategy represented by integers. This field determines the depth of permission transmission. When the delegation policy is 0, the entity holding the token can only use the permission and cannot pass it to other entities. When the delegation policy is greater than 0, it means that the entity holding the token can use the permission and can pass the permission to other entities, but the depth of the pass cannot exceed the value of the delegation policy. When the delegation policy is less than 0, it means that the entity holding the token cannot use the permission, but can pass the permission to other entities, and the depth of the pass is limited by the absolute value of the delegation policy. (4) Define the allowed operations. This field describes the specific operations or behaviors that the authorized entity can perform, such as reading, writing, and modifying. By defining the allowed operations field, the system can accurately determine whether the request complies with the access control policy and decide whether to grant access permissions.

[0123] Blockchain, as a transaction-driven distributed ledger, allows transactions to transmit authorization information. Leveraging the security and reliability of blockchain, its transaction model serves as the medium for transferring access permissions. To grant permissions to other entities, the sender constructs a transaction signed by the grantor, containing specific information about the permissions being transferred. The main structure of a transaction is as follows: the entity wishing to grant permissions to other entities; the entity receiving the permissions; a token representing the permissions; a reference transaction for the permissions; and the signature of the permission grantor.

[0124] Transactions in the delegation chain are of two types: TXregister for registration and TXdelegate for granting permissions. When a new IoT device wants to join the access control chain, it publishes an TXregister transaction using its address. The recipient of this transaction is the device owner. After the transaction is successfully published, the entity receiving the permissions registers as the owner of the device and gains all permissions for that device. All permissions for the device are granted directly or indirectly by the recipient of the registration transaction. When an entity with permissions wants to grant permissions to other entities, it needs to publish an TXdelegate transaction. To trace the source of permissions and form a delegation chain during permission verification, the publisher needs to specify the transaction that granted the relevant permissions, i.e., the referencing transaction. When verifying permissions, the legitimacy of all upstream authorization information needs to be recursively verified along this referencing transaction until the registration transaction is found.

[0125] It's important to note that when a permission holder creates a new token and publishes a transaction TX granting permissions to the entity accepting the permission, entities wishing to grant permissions to other entities will not lose their existing permissions. The publisher simply appends the transaction TXref, which grants the permission, as a reference to TX. When the recipient of transaction TX needs the resource entity providing the service, they must send an authorization transaction TX containing authorization information to the resource entity providing the service for verification. To avoid security issues during the authorization process, granted permissions must meet the following conditions: 1. The entity wishing to grant permissions to other entities must possess the corresponding permissions; 2. The entity accepting the permission must meet all restrictions in the authorization rules; 3. The authorization itself does not violate any general constraints. Specifically, each field in the token (to) authorized by the entity wishing to grant permissions to other entities within the authorization transaction must be a subset of the tokens (token-from) it possesses. To prevent permission escalation, when the resource entity providing the service receives a new request, it needs to trace upstream along the reference transaction fields and verify that each downstream token is a subset of its adjacent upstream tokens. If all tokens are valid and the transaction ultimately traces back to the TXregister transaction, the authorization information in the current transaction can be proven to be valid, and the device will accept the request and provide services.

[0126] In an authorization process, user A, as the device owner, registers the new device on the blockchain via transaction tx#1. Since this is a registration transaction, there are no upstream referencing transactions. User A then generates a token Token2 and grants it a sub-permission to user B via tx#2. Subsequently, user B publishes transaction tx#3, granting token Token3 to user C. tx#3 has a depth of 3 in the authorization chain, specifically the chain {tx#1 ← tx#2 ← tx#3}. When user C requests services from the device, the device determines whether to provide services by checking the validity of the authorization chain.

[0127] Because data on the blockchain is transparent and publicly available, any node joining the blockchain can view the data on the chain. TimeOptiRDE (Time-Optimized Reverse Discoverable Encryption) employs a hybrid encryption design, using a random AES key to encrypt the specific authorization information and an RSA algorithm to encrypt the AES key. Each authorization transaction contains information about all relevant upstream authorization chains and the specific permissions being transferred. These two parts combine to form a new authorization chain, stored in ciphertext. In this way, downstream recipients can easily obtain the specific information of the upstream authorization chains without decrypting all upstream authorization transactions.

[0128] In a blockchain transaction example, authorization information for an authorization chain of depth i is shown. Each authorization transaction consists of four parts: the authorization plaintext segment, the authorization information segment (i.e., the token list, including token-1 to token-i), the verification information segment, and the AES key. The authorization metadata includes the following elements: the authorizer, the blockchain address of the authorization recipient, and the referencing transaction. The token list is a collection of all upstream authorization information referenced by the current authorization transaction and the currently transmitted tokens, where token-1 represents the initial authorization, which is transmitted along with the registration transaction. The verification information segment includes the authorizer's signature used to verify the legitimacy of the authorization and the hash value of the authorization token (denoted as Hash(token-i)), i.e., the latest token in the token list. Finally, the AES key is a randomly generated key during the transaction generation process, encrypted with the recipient's public key to ensure transaction security.

[0129] The token list is a core concept in the TimeOptRDE algorithm design. TimeOptRDE aggregates all tokens from referenced upstream transactions into a single token set, which is then encrypted and stored using a random AES key. This AES key is encrypted using the authorization recipient's public key. Thus, only the authorization recipient can decrypt the authorization information in the current transaction. Due to the token list, authorization verification requires only a single decryption to retrieve all authorization information. For security and verification complexity considerations, each authorization transaction must include the hash value of the current authorization token; the hash result is appended as the token's fingerprint to the transaction verification information.

[0130] In a specific authorization example, user A grants user B two permissions: token1 for device obj1 and token2 for device obj2. Both authorizations reference two different authorization transactions, pre_tx#1 and pre_tx#2, from which user A previously obtained permissions. Next, user B grants token2 to user C, and user C grants token3 to user D. Both tokens grant permissions on device obj1. For users C and D, transaction tx#1, which authorizes user B, is an upstream authorization transaction of tx#2 and tx#3. tx#2 references tx#1, while tx#3 uses tx#2 as a reference transaction. However, for authorization transaction tx#4, where user A grants user B permissions on obj2, this transaction is unrelated to users C and D. The TimeOptiRDE algorithm allows user C and user D to obtain specific information about the token in tx#1, but cannot perceive the authorization information in the unrelated transaction tx#4.

[0131] Accordingly, when verifying permissions, because the data on the blockchain is constantly changing, even if an entity has previously passed device verification, the device still needs to re-check the authorization chain on the blockchain when a new request arrives. If a cascading revocation occurs in the authorization chain, the service is rejected; if a non-cascading revocation occurs in the authorization chain, the legitimacy of the remaining part of the entire authorization chain is checked.

[0132] Before requesting services from the device, any recipient of an authorized transaction must decrypt the plaintext form of the authorization information in the authorization transaction, send the transaction and authorization information to the device, and request services. Upon receiving the service request, the device can verify the legitimacy of the permissions. This is done by verifying each token in the token list and the relevant information of the corresponding authorized transaction to ensure the correctness and legitimacy of the authorization information contained in the current authorized transaction. During verification, the device can check the relationship between adjacent tokens, whether there is cascading reversal, and whether the token's hash value matches the token in the corresponding authorized transaction. If any non-compliance is found, a FALSE statement can be returned, indicating that the authorization information in the transaction is invalid. Permission verification scenarios can include any device receiving a service request or an entity that has granted permissions in a single authorization request wishing to verify the legitimacy of the obtained permissions.

[0133] Corresponding to the above method embodiments, this application also provides corresponding device embodiments. For an explanation of the device embodiments, please refer to other embodiments.

[0134] Figure 6 A schematic block diagram of a blockchain-based access control device according to an embodiment of this application is shown. The device 400 includes a transaction acquisition unit 410 and a verification unit 420.

[0135] The transaction acquisition unit 410 is used to respond to a request to verify the preset permissions of the target business party and acquire N blockchain permission transactions associated with the preset permissions from the blockchain; the N blockchain permission transactions are used to represent the authorization relationship chain from the source of the preset permissions to the target business party; N is a positive integer.

[0136] Verification unit 420 is used to determine whether the preset permissions of the target business party have been verified, provided that the authorization relationship chain based on N blockchain permission transactions has been verified.

[0137] Optionally, the authorization relationship chain includes: authorization relationship flow information representing the i-th permission grantor granting the preset permission to the i-th permission receiver; i=1,…,M; M is a positive integer; where the 1st permission grantor is the permission source of the preset permission, and the M-th permission receiver is the target business party; when M is greater than 1, the j-th permission receiver is the (j+1)-th permission grantor; j=1,…,M-1.

[0138] Optionally, the verification unit 420 is used to: determine that the preset permissions of the target business party have been verified if the M authorization relationship flow information in the authorization relationship chain determined based on N blockchain permission transactions has been verified.

[0139] Optionally, any one of the N blockchain permission transactions is used to represent: the permission grantor grants a preset permission to the permission recipient; any one of the N blockchain permission transactions contains: authorization-related information used to represent the permission grantor granting the preset permission to the permission recipient.

[0140] Optionally, blockchain permission transaction k in N blockchain permission transactions is used to represent that the kth permission grantor grants the preset permission to the kth permission receiver; blockchain permission transaction k contains: authorization-related information used to represent that the xth permission grantor grants the preset permission to the xth permission receiver; x=1,…,k; k is a positive integer less than or equal to M.

[0141] Optionally, the verification unit 420 is used to: determine that the preset permissions of the target business party have been verified if the authorization-related information contained in N blockchain permission transactions has been verified.

[0142] Optionally, any of the N blockchain permission transactions may further include at least one of the following: permission grantor information, permission recipient information, a digital signature of the permission grantor for the plaintext of the authorization-related information, and a preset decryption key encrypted based on the permission recipient's public key; wherein the authorization-related information is in ciphertext form, and the preset decryption key is used to decrypt the ciphertext authorization-related information.

[0143] Optionally, when k is greater than 1, the blockchain permission transaction k also includes reference information for the blockchain permission transaction k-1.

[0144] Optionally, the authorization-related information includes: an authorization credential from the authorization grantor to grant the preset permissions to the authorization recipient, and a digital signature of the authorization grantor on the authorization credential; the authorization credential includes at least one of the following: information on the preset permissions, information on the authorization grantor, information on the authorization recipient, information on the validity period of the preset permissions, and information used to characterize whether the authorization recipient can grant the preset permissions to other business parties.

[0145] Figure 7 The diagram schematically illustrates a structural block diagram of another blockchain-based access control device according to an embodiment of this application. The device 500 includes a construction unit 510 and an on-chain unit 520.

[0146] The construction unit 510 is used to construct a blockchain permission transaction associated with the preset permission when it is determined that the preset permission will be granted to the second business party; the constructed blockchain permission transaction is used to represent that the first business party grants the preset permission to the second business party.

[0147] On-chain unit 520 is used to store the constructed blockchain permission transactions into the blockchain; the blockchain currently stores P blockchain permission transactions associated with preset permissions; the P blockchain permission transactions are used to represent: the authorization relationship chain from the permission source of the preset permission to the second business party; P is a positive integer.

[0148] Optionally, the authorization relationship chain includes: authorization relationship flow information representing the i-th permission grantor granting the preset permission to the i-th permission receiver; i=1,…,P; where the 1st permission grantor is the permission source of the preset permission, and the P-th permission receiver is the second business party; when P is greater than 1, the j-th permission receiver is the (j+1)-th permission grantor; j=1,…,P-1. Optionally, the constructed blockchain permission transaction includes: authorization-related information representing the i-th permission grantor granting the preset permission to the i-th permission receiver; i=1,…,P. Optionally, the P authorization-related information included in the constructed blockchain permission transaction is used to: determine that the second business party is granted the preset permission if the verification of the P authorization-related information is successful.

[0149] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a blockchain-based access control method according to an embodiment of this application. For example... Figure 8As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application. Various programs and data required for the operation of the electronic device 900 are stored in the RAM 903. The processor 901, ROM 902, and RAM 903 are interconnected via a bus 904. The processor 901 performs various operations of the method flow according to an embodiment of this application by executing programs in the ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than the ROM 902 and RAM 903. The processor 901 can also execute various operations of the method flow according to embodiments of this application by executing programs stored in the one or more memories. According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A driver 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the driver 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0150] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application. According to embodiments of this application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0151] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product runs in a computer system, the program code enables the computer system to implement any of the method embodiments provided in the embodiments of this application. When the computer program is executed by processor 901, it performs the functions defined in the system / apparatus of the embodiments of this application. According to embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules. In one embodiment, the computer program can rely on tangible storage media such as optical storage devices or magnetic storage devices. In another embodiment, the computer program can also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via communication section 909, and / or installed from removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0152] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0153] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0154] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0155] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A blockchain-based access control method, characterized in that, The method includes: In response to a request to verify preset permissions for a target business party, N blockchain permission transactions associated with the preset permissions are retrieved from the blockchain; the N blockchain permission transactions are used to represent: the authorization relationship chain from the source of the preset permissions to the target business party; N is a positive integer; If the authorization relationship chain is verified based on the N blockchain permission transactions, the preset permission of the target business party is verified.

2. The method according to claim 1, characterized in that, The authorization relationship chain includes: authorization relationship flow information used to represent the i-th permission grantor granting the preset permission to the i-th permission receiver; i = 1, ..., M; M is a positive integer; Wherein, the first permission grantor is the permission source of the preset permission, and the Mth permission recipient is the target business party; when M is greater than 1, the jth permission recipient is the (j+1)th permission grantor; j=1,…,M-1.

3. The method according to claim 2, characterized in that, The step of determining that the preset permission of the target business party has passed verification when the authorization relationship chain is verified based on the N blockchain permission transactions includes: If the M authorization relationship flow information in the authorization relationship chain is verified based on the N blockchain authorization transactions, the preset permission of the target business party is verified.

4. The method according to claim 1 or 2, characterized in that, Any one of the N blockchain permission transactions is used to represent that: the permission grantor grants the preset permission to the permission receiver; Any of the N blockchain permission transactions includes: authorization-related information indicating that the permission grantor grants the preset permission to the permission recipient.

5. The method according to claim 2, characterized in that, Blockchain permission transaction k in the N blockchain permission transactions is used to represent that the kth permission grantor grants the preset permission to the kth permission receiver; the blockchain permission transaction k includes: authorization-related information used to represent that the xth permission grantor grants the preset permission to the xth permission receiver; x=1,…,k; k is a positive integer less than or equal to M.

6. The method according to claim 4, characterized in that, Any of the N blockchain permission transactions further includes at least one of the following: permission grantor information, permission recipient information, a digital signature of the permission grantor for the plaintext of the authorization-related information, and a preset decryption key encrypted based on the permission recipient's public key. The authorization-related information is in encrypted form, and the preset decryption key is used to decrypt the encrypted authorization-related information.

7. A blockchain-based access control method, characterized in that, Applied to the first business party, the method includes: If it is determined that a preset permission will be granted to a second business party, a blockchain permission transaction associated with the preset permission is constructed; the constructed blockchain permission transaction is used to represent that: the first business party grants the preset permission to the second business party; The constructed blockchain permission transactions are stored in the blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permission; the P blockchain permission transactions are used to represent: the authorization relationship chain from the permission source of the preset permission to the second business party; P is a positive integer.

8. The method according to claim 7, characterized in that, The authorization relationship chain includes: authorization relationship flow information used to represent the i-th permission grantor granting the preset permission to the i-th permission receiver; i = 1, ..., P; Wherein, the first permission grantor is the permission source of the preset permission, and the Pth permission receiver is the second business party; when P is greater than 1, the jth permission receiver is the (j+1)th permission grantor; j=1,…,P-1.

9. The method according to claim 8, characterized in that, The constructed blockchain permission transaction includes: authorization-related information representing that the i-th permission grantor grants the preset permission to the i-th permission receiver; i=1,…,P; The P authorization-related information items included in the constructed blockchain permission transaction are used to: determine that the second business party is granted the preset permission if the verification of the P authorization-related information items is successful.

10. A blockchain-based access control device, characterized in that, The device includes: The transaction acquisition unit is used to respond to a request to verify the preset permissions of the target business party, and to acquire N blockchain permission transactions associated with the preset permissions from the blockchain; the N blockchain permission transactions are used to represent: the authorization relationship chain from the source of the preset permissions to the target business party; N is a positive integer; The verification unit is used to determine that the preset permission of the target business party has been verified if the authorization relationship chain has been verified based on the N blockchain permission transactions.

11. A blockchain-based access control device, characterized in that, Applied to the first business party, the device includes: A construction unit is used to construct a blockchain permission transaction associated with the preset permission when it is determined that the preset permission will be granted to the second business party; the constructed blockchain permission transaction is used to represent that the first business party grants the preset permission to the second business party; The on-chain unit is used to store the constructed blockchain permission transactions into the blockchain; the blockchain currently stores P blockchain permission transactions associated with the preset permission; the P blockchain permission transactions are used to represent: the authorization relationship chain from the permission source of the preset permission to the second business party; P is a positive integer.

12. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 9.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.

Images