Data access control method based on smart contract

Abstract

The invention provides a data access control method based on a smart contract. Constructing a hierarchical domain organization tree according to the cooperation relationship of partners under multi-party cooperation and the internal organization structure relationship of the partners; each block chain node establishes a client-role mapping table, an on-chain node-role mapping table, a role-permission mapping table, a permission-data-operation mapping table and a permission-contract mapping table to form an access control strategy library; the client carries client role information to a block chain node of a domain to which the client belongs for registration; the client role information is composed of an upstream path in the hierarchical domain organization tree and a position role; after a client carries an initiating transaction request, before a contract is executed and before the contract is executed and accesses data, a constraint condition checker is called to verify identity, authority and execution behaviors. According to the invention, support is provided for realizing access control requirements of traditional data management by using a block chain system in an enterprise organization.

Description

Technical Field

[0001] This invention relates to the field of computer data management technology, and more specifically to a data access control method based on smart contracts in data management. Background Technology

[0002] Distributed ledgers have garnered significant attention in the data management field due to their decentralized, tamper-proof, and traceable characteristics, making them highly promising for applications in manufacturing, service industries, the Internet of Things (IoT), and edge computing. However, in practical distributed data management applications, it is not only desirable to ensure data security and integrity, but also to protect data privacy during collection, storage, and use. More precisely, it is hoped that decentralized systems can implement a comprehensive access control mechanism similar to that of database systems.

[0003] Access control was proposed in the 1970s to restrict user access to resources, initially to solve data sharing problems on mainframes. With the development of information technology, numerous access control models have emerged, including Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Usage Control (UCON), each with different needs and objectives. By restricting subjects, objects, and control policies, access to data is ensured to meet the needs of the corresponding scenario. Most existing access control schemes introduce a central trusted entity for permission allocation and decision-making, which makes them susceptible to single points of failure and privacy leaks at the central node.

[0004] Smart contract technology, proposed in the era of Blockchain 2.0, has characteristics such as automatic execution and Turing completeness, which enriches the functions of blockchain and is therefore suitable for providing decentralized and distributed data access control on the blockchain.

[0005] Existing access control technologies for distributed ledger data often focus on public scenarios such as IoT and healthcare data sharing within public blockchains. They primarily address providing trusted access control policies for massive numbers of terminals and personal devices, characterized by large data volumes, numerous permission relationships, but low access frequency. Their solutions are typically based on single-chain and encryption, scenarios with low overall system performance requirements. However, access control solutions are lacking for large enterprise consortium blockchain data in complex workflows such as multi-party collaboration and supply chains.

[0006] Therefore, how to solve problems such as insufficient access control and low throughput in consortium blockchain systems through the application of smart contracts is a problem that researchers in the field of data management need to address. Summary of the Invention

[0007] In view of this, the present invention provides a data access control method based on smart contracts, which realizes the requirements of the role-based access control (RBAC) model for data access in blockchain systems, and provides support for enterprises and organizations to use blockchain systems to realize access control needs for traditional data management.

[0008] To solve the above-mentioned technical problems, the present invention is implemented as follows.

[0009] A data access control method based on smart contracts includes:

[0010] Step 1: Based on the collaborative relationships and internal organizational structures of the various partners in the multi-party collaboration, construct a hierarchical domain organization tree, where each tree node represents a domain; each domain has a corresponding blockchain node and client; the blockchain node stores the upstream path of its domain in the tree as the blockchain node's identity path;

[0011] Step 2: Each blockchain node establishes a client-role mapping table, an on-chain node-role mapping table, a role-permission mapping table, a permission-data-operation mapping table, and a permission-contract mapping table to form an access control policy library;

[0012] Step 3: The client registers with the blockchain node of its domain, carrying its client role information. The client role information consists of the domain's upstream path in the tree plus the job title. The blockchain node generates a certificate for the client and stores the client role information corresponding to the certificate.

[0013] Step 4: The client initiates a transaction request with its certificate; the blockchain node retrieves the corresponding client role information based on the certificate; first, it calls the built-in constraint checker to match the identity path in the client role information with the identity path of the blockchain node; if the match is successful, it uses the access control policy library to verify the legality of the contract call; and when the contract executor executes the smart contract, any access to data will call the constraint checker to verify the legality of the data access.

[0014] Preferably, in the hierarchical domain organization tree, the domains of parent and child tree nodes have an inclusion relationship. The domain of a tree node contains the blockchain nodes in the domains of all its descendant tree nodes, and also includes n blockchain nodes that belong exclusively to this domain, where n is 0 or a positive integer. A blockchain node belongs to one or more domains. The blockchain nodes in each domain reach consensus on the hierarchical domain organization tree.

[0015] Preferably, each domain in the hierarchical domain organization tree has a unique identifier;

[0016] The blockchain node identity path is constructed by combining all node identifiers on the path from the domain to the root node in reverse order to form the blockchain node identity path.

[0017] The client role information is constructed as follows: the identity path is formed by combining all node identifiers on the path from the client's domain to the root of the hierarchical domain organization tree in reverse order, and then adding the job title to form the client role information.

[0018] Preferably, step four includes:

[0019] Step a: The client initiates a transaction request with the certificate; the blockchain node retrieves the corresponding client role information based on the received certificate;

[0020] Step b: The blockchain node calls the constraint checker to match the identity path in the client role information with its own blockchain node identity path. If they match, the node checks whether the client has been authorized with the corresponding role based on the client-role mapping table. Then, based on the role-permission mapping table and the permission-contract mapping table, the node determines whether the role has the permission to call the corresponding contract resources. If the verification is successful, the constraint checker transfers the transaction to the contract executor to execute the smart contract code and additionally passes the client role information to the contract executor.

[0021] Step c: When the contract executor executes the smart contract code, any access to data will call the constraint checker. Based on the client role information, the role-permission mapping table, and the permission-data-operation mapping table, it will determine whether the data access operation of the currently executed smart contract to the state database complies with the permission requirements. Based on the judgment result, the corresponding operation of the smart contract will be executed.

[0022] Step d: After the transaction is completed, the data is uploaded to the blockchain, and the execution result is fed back to the client.

[0023] Preferably, the method further includes a dynamic strategy adjustment step:

[0024] The genesis block of the blockchain provides an access policy adjustment contract;

[0025] When a client requests to invoke the access policy adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; the blockchain node retrieves the corresponding client role information based on the certificate.

[0026] The constraint checker matches the identity path in the client role information with its own blockchain node identity path, and verifies the legality of the access policy adjustment contract call using the access control policy library. If the call is deemed legal, the contract executor is invoked to execute the access policy adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the access policy adjustment operation for data access based on the client role information and the access control policy library. After verification, the contract executor then adjusts the mapping table in the access control policy library.

[0027] Then, the adjusted mapping table in the access control policy library is used to generate transaction proposals and achieve consensus; each blockchain node in the domain collects blocks, executes them sequentially, and updates the access control policy library.

[0028] Preferably, the method further includes a dynamic role authorization adjustment step:

[0029] The genesis block of the blockchain provides role authorization and adjustment contracts;

[0030] When a client requests to invoke the role authorization adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; the blockchain node retrieves the corresponding client role information based on the certificate.

[0031] The constraint checker matches the identity path in the client's role information with its own blockchain node identity path, and uses the access control policy library to verify the legality of the access policy adjustment contract call. If the call is deemed legal, the contract executor is invoked to execute the role authorization adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the role authorization adjustment contract's access to data based on the client's role information and the access control policy library. If the verification is successful, the contract executor then executes the role authorization adjustment contract.

[0032] Preferably, in step one, after constructing the hierarchical domain organization tree and determining the identity path of the blockchain node, the blockchain node further determines the authorized nodes; the authorized nodes refer to the subtrees of the tree nodes corresponding to the domain to which the blockchain node belongs;

[0033] All blockchain nodes within each domain reach a consensus on the blockchain node identity path and authorized nodes;

[0034] When executing the role authorization adjustment contract, the constraint checker further determines whether each node on the identity path in the adjusted client role information is within the scope of the blockchain node identity path and authorized nodes in the blockchain node consensus. Only when the determination is yes, the client role information adjustment is allowed.

[0035] Preferably, the method further includes:

[0036] When a client initiates a transaction with a blockchain node using a certificate: if the client sends a transaction request to the blockchain node, the blockchain node adds the client's public key to the blockchain node's client-role mapping table; when the blockchain node sends a result back to the client, the client adds the blockchain node's public key to the client's on-chain node-role mapping table.

[0037] Subsequently, when a client initiates a transaction, it directly uses the client's public key to sign the transaction. The blockchain node executing the transaction then verifies the client's role based on the client's public key and the client's public key stored in the client-role mapping table.

[0038] Preferably, if the same client has positions in different domains, it should register on the blockchain node of the corresponding domain.

[0039] Compared with existing technologies, this invention discloses a data access control method based on smart contracts, which realizes the requirements of the role-based access control (RBAC) model for data access in blockchain systems, and provides support for enterprises and organizations to use blockchain systems to realize access control needs for traditional data management. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the overall system structure of the method provided by the present invention.

[0041] Figure 2 This is a schematic diagram illustrating the relationship between the hierarchical organization tree, blockchain nodes, and clients of this invention.

[0042] Figure 3 This is a schematic diagram of a collaborative relationship according to the present invention.

[0043] Figure 4 This is a schematic diagram of the mapping tables in the access control policy library of this invention.

[0044] Figure 5 This is a schematic diagram of the overall system structure for incorporating process steps into the present invention. Detailed Implementation

[0045] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0046] This invention provides a data access control method based on smart contracts, which fulfills the requirements of the role-based access control (RBAC) model and supports the access control needs of enterprises using distributed ledger systems to implement traditional data management.

[0047] This invention relates to two types of entities: clients and blockchain nodes, and proposes a novel hierarchical domain organization tree. The hierarchical domain organization tree is a virtual information system reflecting the relationships between collaborators and their internal organizational structures in a multi-party collaborative environment. Each node in the hierarchical domain organization tree represents a domain, and each domain corresponds to its respective blockchain node and client. Both the blockchain node and client determine their identity path based on the domain's position in the tree, used for identity matching during access control. Furthermore, a control policy library and constraint checker are added to the blockchain node, and an identity matching operation is added to the contract executor. This enables legality checks for contract calls and data access during contract execution, providing role-based data access control guarantees for blockchain systems. This supports the access control needs of enterprises using smart contract-based blockchain systems to implement traditional data management.

[0048] Figure 1 The components of the blockchain node of this invention are illustrated, including a network structure layer, an access control layer, and a data layer. The network structure layer, in addition to consensus and communication services, also includes a hierarchical domain organization tree. The access control layer provides access control services, including an access control policy library and a constraint checker. The data layer includes a state database, a contract executor, and a ledger. The hierarchical domain organization tree, access control policy library, access control services, state database, and ledger are described separately below.

[0049] (1) Hierarchical domain organization tree (enterprise organizational structure)

[0050] First, let me explain the structure of the hierarchical domain organization tree and its relationship with blockchain nodes and clients.

[0051] like Figure 2 As shown, the hierarchical domain organization tree corresponds to organizational relationships in a real-world environment, such as company-subsidiary, department-team, etc. This hierarchical domain organization tree is constructed based on the collaborative relationships between partners in a multi-party collaboration and the internal organizational structures of those partners. For example... Figure 3 The organizational relationships shown are as follows: A, B, C, and D are the first-level domains; appliance manufacturer C has four child nodes C1, C2, C3, and C4; C1 is subsidiary 1, which has two child nodes C11 and C12.

[0052] In a hierarchical domain organization tree, each tree node represents a domain, and each domain has a unique identifier, such as D1, D2, etc. The domains of parent and child tree nodes have an inclusion relationship; a tree node's domain contains the blockchain nodes within all its descendant tree node domains, and can also include n blockchain nodes unique to that domain, where n is 0 or a positive integer. A blockchain node belongs to one or more domains. Each domain has corresponding blockchain nodes and clients. For example, Figure 2The green domain, uniquely identified as D1, comprises three blockchain nodes (see the green box). Domain D1 has two child nodes, D3 and D4. Domain D3 has two blockchain nodes, and D4 has one blockchain node. Domain D1 is contained within domains D3 and D4; the blockchain nodes of domains D3 and D4 together form the blockchain nodes of D1.

[0053] Blockchain nodes store hierarchical domain organization tree information and blockchain node identity paths, where:

[0054] For storing hierarchical domain organization tree information: To ensure the confidentiality of the organizational structure, the hierarchical domain organization tree is implemented as a Merkle tree structure. Each node does not store the complete hierarchical domain organization tree, but only its related subtrees, compressed via hashing, as instances. Figure 2 As shown, the blockchain nodes in D4 only store complete information of D0-D1-D4 and related hashes of domain nodes D3 and D2. When the organizational structure is adjusted, the hashes need to be passed up through transactions to update the tree.

[0055] Regarding the storage of blockchain node identity paths: A blockchain node may correspond to one or more domains. For example, the blockchain node in D4 corresponds to two domains (D1 and D4). The blockchain node needs to store the blockchain node identity path when belonging to each domain.

[0056] Here, "blockchain node identity path" refers to the upstream path of a domain in the tree. Since each node has a unique identifier, the blockchain node identity path can be obtained by combining all the node identifiers along the path from the domain's node to the root node in reverse order. For example, if a node belongs to both domains D1 and D3, then its two stored blockchain node identity paths are D0-D1 and D0-D1-D3.

[0057] The hierarchical domain organization tree provides static initialization, dynamic node addition and deletion, and authentication methods.

[0058] Static initialization: During system initialization, the publicly available organizational structure is transmitted in plaintext as the original tree structure (such as public domain + cooperative company domains); preferably, the static initialization process is performed iteratively between domains, for example, first determine the on-chain nodes of D3 and D4, then determine the on-chain nodes corresponding to the upstream D1 domain, until each node has the hierarchical domain organizational tree path of its own domain.

[0059] Dynamic addition and deletion: After consensus is reached within the domain on the addition of a new node, the encrypted node set is updated. Nodes with the authority to update node information initiate transactions on the parent domain of this domain to update the hash on the Merkle tree with the new node information. This process can be performed periodically and lazily, adding multiple nodes in batches using a single transaction.

[0060] Authentication: To prove that a node belongs to a specific organization, a Merkel path on the Merkel tree can be provided. Without exposing any other organization or node information, the root of the path is matched with the Merkel root of the hierarchical domain organization tree exposed by the external domain to provide proof that the node belongs to a specific organization.

[0061] (2) Access Control Policy Library

[0062] like Figure 4 As shown, the access control policy library stores client-role mapping tables, on-chain node-role mapping tables, role-permission mapping tables, permission-data-operation mapping tables, and permission-contract mapping tables.

[0063] In practice, multiple tables can be used as special leaf nodes in a hierarchical domain organization tree for storage. Compared to traditional RBAC, multiple additional mapping tables are maintained to provide extra security guarantees when some data is highly confidential and not all nodes in the domain are trusted.

[0064] (3) Access control service

[0065] Access control is implemented for all resources in the system that require confidentiality, including node information (identity privacy), transaction and state data (transaction privacy), and smart contract code (contract privacy), to achieve end-to-end privacy protection. The access control service comprises four parts: an access control policy library, a constraint checker, a smart contract executor, and a state database. When a request to invoke a smart contract at a specific address is received, the constraint checker first verifies the caller's identity and uses the access control policy library to verify the call's legitimacy. If the call is legitimate, the contract executor is initiated, verifying the data access legitimacy based on the client's role information and the access control policy library. If verification passes, data access is granted. For each data access operation, the constraint checker determines whether the data access complies with permissions before accessing the state database.

[0066] Then, the node executing the transaction broadcasts the transaction's read / write set to a list of nodes with access to the data using the gossip protocol, while sending the encrypted address and transaction hash to the leader node.

[0067] After receiving a transaction, a node with corresponding write permissions temporarily stores the read / write set and the transaction hash. After detecting that the transaction is on the chain, it performs a delayed commit. Then, the node that has full access to the read / write set (at least one of them must exist) generates the previous block hash / id from the perspective of its current role based on the role determinism.

[0068] (4) State Database

[0069] The underlying storage for state data can be state data or relational data. Data of any form is stored in the form of virtual tables to provide consistent access permissions to multiple data elements.

[0070] (5) Graphical Distributed Ledger

[0071] The design of a blockchain ledger structure needs to balance the requirements of hierarchical access control and RBAC, while providing guarantees for blockchain traceability and tamper-proofing. Therefore, this invention adopts a graph-based distributed ledger, constructing a directed acyclic graph (DAG) structure based on a tree structure of a hierarchical domain organization tree. Graph nodes in the DAG structure correspond to tree nodes in the hierarchical domain organization tree. Each graph node stores a portion of the entire system's ledger. All blockchain nodes within a domain possess a consistent ledger. For a graph node, its stored ledger includes the ledgers of each node along the upstream path of the corresponding tree node, as well as the ledgers of its subtrees. For example, graph node d1 in the DAG structure corresponds to node D1 in the hierarchical domain organization tree; therefore, d1 stores the ledgers of D1, D0, D3, and D4. Thus, the three blockchain nodes within D1 all store the ledgers of D1, D0, D3, and D4.

[0072] The client can be any implementation of a client in any blockchain system, but it has the following characteristics: it stores a hierarchical domain organization tree path, representing the domain to which it belongs and the role it has.

[0073] Based on the above design, the data access control method based on smart contracts of the present invention includes the following steps, such as... Figure 5 As shown:

[0074] Step 1: Construct a hierarchical domain organization tree and blockchain nodes:

[0075] Based on the collaborative relationships and internal organizational structures of the partners in a multi-party collaboration, a hierarchical domain organization tree is constructed. Each tree node represents a domain, and each domain has a unique identifier. Domains within parent and child tree nodes have an inclusion relationship; a tree node's domain contains the blockchain nodes within all its descendant tree node domains, and may also include n blockchain nodes unique to that domain, where n can be 0 or a positive integer. A blockchain node belongs to one or more domains. Each domain has corresponding blockchain nodes and clients.

[0076] When a blockchain node corresponds to multiple domains, the blockchain node identity path for each domain is stored. The blockchain node identity path refers to the upstream path of the domain in the tree. Since each node has a unique identifier, the blockchain node identity path can be obtained by combining the identifiers of all nodes along the path from the node corresponding to the domain to the root node in reverse order. For example, if a node belongs to both domains D1 and D3, then its two stored blockchain node identity paths are D0-D1 and D0-D1-D3.

[0077] All blockchain nodes within each domain reach consensus on the hierarchical domain organization. Preferably, after constructing the hierarchical domain organization tree and determining the blockchain node identity path, the blockchain nodes further determine the authoritative nodes; the authoritative nodes refer to the subtrees of the tree nodes corresponding to the domain to which the blockchain node belongs. For example, for D1, its authoritative nodes are D3 and D4. Then, all blockchain nodes within each domain reach consensus on the blockchain node identity path and the authoritative nodes.

[0078] Step 2: Initialize the state database: Each blockchain node creates the genesis block and state database under its corresponding domain. This state database can be any form of underlying database, such as a Merkle state tree.

[0079] Step 3: Each blockchain node establishes a client-role mapping table, an on-chain node-role mapping table, a role-permission mapping table, a permission-data-operation mapping table, and a permission-contract mapping table to form an access control policy library. Figure 4 Five examples of mapping tables are shown, where roles can be department heads, D1 employees, etc.

[0080] Step 4: The client registers with the blockchain node of its domain, carrying its client role information. The client role information in this invention consists of the upstream path in the hierarchical domain organization tree plus the job title / role. The blockchain node generates a certificate for the client and stores the client role information corresponding to the certificate.

[0081] Here, the client role information is formed as follows: All node identifiers along the path from the client's domain to the root of the hierarchical domain organization tree are combined in reverse order to form an identity path, and then the job title is added to create the client role information. For example, D0-D1-D3-Finance Manager.

[0082] For example, the client's IP address is ipXXX; the client's role information is D0-D1-D3-Finance Manager; when the client registers with the blockchain node of its domain, the blockchain node generates a certificate key and stores the key, ipXXX, and D0-D1-D3-Finance Manager; it then sends the certificate key to the client. When the client initiates a request, it includes the key, the client's username, and the contract number.

[0083] If the same client has roles in different domains, it will register on the corresponding blockchain node for each domain. For example, a client may have two identity information: D0-D1-D3-Finance Manager and D0-D1-Employee.

[0084] Step 5: Execution of Smart Contracts with Access Control: The client initiates a transaction request with its certificate; the blockchain node retrieves the corresponding client role information based on the certificate; the blockchain node first calls the constraint checker to match the identity path in the client role information with its own blockchain node identity path. If the match is successful, the access control policy library is used to verify the legality of the contract call; and when the contract executor executes the smart contract, any access to data will call the constraint checker to verify the legality of the data access; if the verification is successful, data access is allowed.

[0085] This step specifically includes the following sub-steps:

[0086] Step a: The client initiates a transaction request with its certificate; the blockchain node retrieves the corresponding client role information from the stored relationship based on the certificate.

[0087] For example, based on the key, the client role information is found to be D0-D1-D3-Finance Manager. The identity information prefix is ​​the identity path: D0-D1-D3.

[0088] Step b: Call the constraint checker to match the identity path in the client role information with its own blockchain node identity path. If they match, check whether the client has been authorized with the corresponding role based on the client-role mapping table. Then, based on the role-permission mapping table and the permission-contract mapping table, determine whether the role has the permission to call the corresponding contract resources. If the verification passes, the constraint checker transfers the transaction to the contract executor to execute the smart contract code, passing in the smart contract parameters and additionally the client role information.

[0089] Step c: When the contract executor executes the smart contract code, any access to data invokes the constraint checker. Based on the client role information, the role-permission mapping table, and the permission-data-operation mapping table, the checker determines whether the data access operation of the currently executing smart contract to the state database complies with the permission requirements. Based on the determination result, the corresponding operation of the smart contract is executed. Access that does not meet the requirements will return failure.

[0090] Step d: After the transaction is completed, the data is uploaded to the blockchain, and the execution result is fed back to the client.

[0091] In step d, the transaction proposal with read-write set is returned to the client. After collecting the number of proposals that meet the contract requirements, the client sends the transaction hash to the consensus nodes within the domain. The transaction proposal is propagated to all nodes within the domain via the gossip protocol, but only the plaintext state data is sent to nodes with the corresponding data read permissions. After receiving the transaction, the node temporarily stores it in the pending transaction pool. After the block is added to the blockchain, the temporarily stored transaction is committed in the hash order of the block.

[0092] The above describes the initialization and execution steps of a smart contract with access control.

[0093] Preferably, the present invention further includes a dynamic strategy and role authorization adjustment stage, comprising the following steps:

[0094] Step A: Public smart contract methods provided in the genesis block of the blockchain, including access policy adjustment contracts and role authorization adjustment contracts.

[0095] Step B: When the client requests to invoke the access policy adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; the blockchain node retrieves the corresponding client role information based on the certificate.

[0096] At this point, the constraint checker matches the identity path in the client's role information with its own blockchain node identity path, and verifies the legality of the access policy adjustment contract call using the access control policy library. If the call is deemed legal, the contract executor is invoked to execute the access policy adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the access policy adjustment operation for data access based on the client's role information and the access control policy library. If the verification is successful, the contract executor then adjusts the mapping table in the access control policy library. The adjusted mapping table in the access control policy library is then used to generate a transaction proposal for consensus. Each blockchain node within the domain collects blocks, executes them sequentially, and updates the access control policy library.

[0097] Step C: When the client requests to invoke the role authorization adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; the blockchain node retrieves the corresponding client role information based on the certificate.

[0098] At this point, the constraint checker matches the identity path in the client's role information with its own blockchain node identity path, and uses the access control policy library to verify the legality of the access policy adjustment contract call. If the call is deemed legal, the contract executor is invoked to execute the role authorization adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the role authorization adjustment contract's access to data based on the client's role information and the access control policy library. If the verification is successful, the contract executor then executes the role authorization adjustment contract.

[0099] In a preferred embodiment, when executing the role authorization adjustment contract, it is further determined whether the identity path node in the adjusted client role information is within the scope of the blockchain node identity path and authorized nodes in the blockchain node consensus. Client role information adjustment is only permitted if the determination is yes. This is to avoid the client's permission scope exceeding the node's permission scope, resulting in transactions lacking node endorsement.

[0100] In a preferred embodiment, when a client initiates a transaction with a blockchain node using a certificate: if the client sends a transaction request to the blockchain node, the blockchain node adds the client's public key to its client-role mapping table; when the blockchain node sends a result back to the client, the client adds the blockchain node's public key to its on-chain node-role mapping table; thereafter, when the client initiates a transaction, it directly uses its public key to sign, and the blockchain node executing the transaction verifies the client's role based on the client's public key and the client's public key stored in the client-role mapping table.

[0101] In one preferred embodiment, the public smart contract methods provided by the genesis block are built into the ledger when the system starts up. The permissions are set to public by default, and any role within the domain can call them. However, this can be modified later according to the access control policy adjustment process so that they can only be called by specific roles.

[0102] In a preferred embodiment, the smart contract executor can be consistent with the smart contract execution environment of any blockchain system, such as the Golang-based chaincode in Fabric or the EVM in Ethereum. However, when accessing underlying data, it needs to do so through an interface provided by a constraint checker, rather than directly reading the database. That is, any data access request needs to be checked. Furthermore, the constraint checker can be placed in a Trusted Execution Environment (TEE) to further ensure that no violations occur during data access.

[0103] In summary, this invention addresses the problems of insufficient granularity in data access control, difficulty in dynamically adjusting permissions, and limited system performance in complex data management environments. It designs a data access control method based on smart contracts and employs a hierarchical domain organization tree to support secure and efficient data management and permission control using an enterprise-grade consortium blockchain. By constructing a hierarchical domain organization tree and combining it with a Role-Based Access Control (RBAC) model, this invention achieves dynamic role allocation for nodes and clients, permission policy adjustment, and real-time permission verification during smart contract execution. By introducing a collaborative mechanism between a constraint checker and a smart contract executor, it ensures that every data access requires permission verification. Furthermore, by utilizing dynamic policy transaction proposals and consensus mechanisms, it guarantees the credibility and state consistency of the permission adjustment process.

[0104] The method proposed in this invention maintains the decentralized nature of the data management environment while supporting high-concurrency transaction processing and low-latency permission updates, significantly improving the security and system throughput of data access control in a consortium blockchain environment. It can be extended to scenarios with stringent access control and privacy protection requirements, such as supply chain management and cross-organizational data sharing.

[0105] As can be seen from the above technical solutions, compared with the prior art, the present invention discloses a data access control method based on smart contracts, which realizes the requirements of the role-based access control (RBAC) model for data access in blockchain systems, and provides support for enterprises and organizations to use blockchain systems to realize access control needs for traditional data management.

[0106] The specific embodiments described above only illustrate the design principles of the present invention. The shapes and names of the components in this description may differ and are not limited. Therefore, those skilled in the art can modify or make equivalent substitutions to the technical solutions described in the foregoing embodiments; and these modifications and substitutions do not depart from the inventive spirit and technical solutions of the present invention, and should all fall within the protection scope of the present invention.

Claims

1. A data access control method based on smart contracts, characterized in that, include: Step 1: Based on the collaborative relationships and internal organizational structures of the various partners in a multi-party collaboration, construct a hierarchical domain organization tree, where each tree node represents a domain. Each domain has a corresponding blockchain node and client; The upstream path of the domain to which a blockchain node belongs in the tree is used as the blockchain node's identity path. Step 2: Each blockchain node establishes a client-role mapping table, an on-chain node-role mapping table, a role-permission mapping table, a permission-data-operation mapping table, and a permission-contract mapping table to form an access control policy library; Step 3: The client registers with the blockchain node of its domain, carrying the client role information. Client role information consists of the domain's upstream path in the tree plus its job title; blockchain nodes generate certificates for clients and store the client role information corresponding to the certificates; Step 4: The client initiates a transaction request with its certificate; The blockchain node retrieves the corresponding client role information based on the certificate; it first calls the built-in constraint checker to match the identity path in the client role information with the identity path of the blockchain node; if the match is successful, it uses the access control policy library to verify the legality of the contract call; Furthermore, when the contract executor executes the smart contract, any access to data will trigger a constraint checker to verify the legality of the data access.

2. The method as described in claim 1, characterized in that, In the hierarchical domain organization tree, the domains of parent and child tree nodes have an inclusion relationship. The domain of a tree node contains the blockchain nodes in the domains of all its descendant tree nodes, as well as n blockchain nodes that belong exclusively to this domain, where n can be 0 or a positive integer. A blockchain node belongs to one or more domains. The blockchain nodes in each domain reach consensus on the hierarchical domain organization tree.

3. The method as described in claim 2, characterized in that, Each domain in a hierarchical domain organization tree has a unique identifier; The blockchain node identity path is constructed by combining all node identifiers on the path from the domain to the root node in reverse order to form the blockchain node identity path. The client role information is constructed as follows: the identity path is formed by combining all node identifiers on the path from the client's domain to the root of the hierarchical domain organization tree in reverse order, and then adding the job title to form the client role information.

4. The method as described in claim 3, characterized in that, Step four includes: Step a: The client initiates a transaction request with the certificate; the blockchain node retrieves the corresponding client role information based on the received certificate; Step b: The blockchain node calls the constraint checker to match the identity path in the client role information with its own blockchain node identity path. If they match, the node checks whether the client has been authorized with the corresponding role based on the client-role mapping table. Then, based on the role-permission mapping table and the permission-contract mapping table, the node determines whether the role has the permission to call the corresponding contract resources. If the verification is successful, the constraint checker transfers the transaction to the contract executor to execute the smart contract code and additionally passes the client role information to the contract executor. Step c: When the contract executor executes the smart contract code, any access to data will call the constraint checker. Based on the client role information, the role-permission mapping table, and the permission-data-operation mapping table, it will determine whether the data access operation of the currently executed smart contract to the state database complies with the permission requirements. Based on the judgment result, the corresponding operation of the smart contract will be executed. Step d: After the transaction is completed, the data is uploaded to the blockchain, and the execution result is fed back to the client.

5. The method as described in claim 3, characterized in that, The method further includes a dynamic policy adjustment step: The genesis block of the blockchain provides an access policy adjustment contract; When a client requests to invoke the access policy adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; Blockchain nodes retrieve the corresponding client role information based on the certificate; The constraint checker matches the identity path in the client role information with its own blockchain node identity path, and verifies the legality of the access policy adjustment contract call using the access control policy library. If the call is deemed legal, the contract executor is invoked to execute the access policy adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the access policy adjustment operation for data access based on the client role information and the access control policy library. After verification, the contract executor then adjusts the mapping table in the access control policy library. Then, the mapping table adjusted in the access control policy library is used to generate a transaction proposal and reach a consensus. Each blockchain node within the domain collects blocks, executes them sequentially, and updates the access control policy library.

6. The method as described in claim 3, characterized in that, The method further includes a dynamic role authorization adjustment step: The genesis block of the blockchain provides role authorization and adjustment contracts; When a client requests to invoke the role authorization adjustment contract, it sends a transaction request carrying the certificate to the blockchain node; Blockchain nodes retrieve the corresponding client role information based on the certificate; The constraint checker matches the identity path in the client's role information with its own blockchain node identity path, and uses the access control policy library to verify the legality of the access policy adjustment contract call. If the call is deemed legal, the contract executor is invoked to execute the role authorization adjustment contract. When the contract executor executes the smart contract, it invokes the constraint checker to verify the legality of the role authorization adjustment contract's access to data based on the client's role information and the access control policy library. If the verification is successful, the contract executor then executes the role authorization adjustment contract.

7. The method as described in claim 6, characterized in that, In step one, after constructing the hierarchical domain organization tree and determining the identity path of the blockchain node, the blockchain node further determines the authorized nodes; the authorized nodes refer to the subtrees of the tree nodes corresponding to the domain to which the blockchain node belongs. All blockchain nodes within each domain reach a consensus on the blockchain node identity path and authorized nodes; When executing the role authorization adjustment contract, the constraint checker further determines whether each node on the identity path in the adjusted client role information is within the scope of the blockchain node identity path and authorized nodes in the blockchain node consensus. Only when the determination is yes, the client role information adjustment is allowed.

8. The method as described in claim 1, characterized in that, The method further includes: When a client initiates a transaction with a blockchain node using a certificate: if the client sends a transaction request to the blockchain node, the blockchain node adds the client's public key to the blockchain node's client-role mapping table; when the blockchain node sends a result back to the client, the client adds the blockchain node's public key to the client's on-chain node-role mapping table. Subsequently, when a client initiates a transaction, it directly uses the client's public key to sign the transaction. The blockchain node executing the transaction then verifies the client's role based on the client's public key and the client's public key stored in the client-role mapping table.

9. The method as described in claim 1, characterized in that, If a client has a job title in a different domain, it will register on the blockchain node of the corresponding domain.

Images