A fine-grained access control method and system in a multi-chain environment

Abstract

The application belongs to the technical field of computer block chain, and particularly relates to a fine-grained access control method and system in a multi-chain environment. The method comprises a permission allocation stage, and the execution process is as follows: a client uses a permission group to allocate a transaction request to perform a new permission group creation transaction or a permission group node adjustment transaction; a proposal of the transaction is generated by an execution node jump, and is sent to a consensus node of a corresponding parent permission group; the consensus node is verified to be legal, and performs block output together with other transactions; after the consensus node generates a block on the chain, whether there is a permission group allocation transaction in the block is detected, if yes, it is indicated that the allocation of the new permission group has passed the consensus in the parent permission group; each consensus node in the new permission group generates a genesis block of a new chain in parallel, and is attached to a ledger, a previous block hash of which points to a block of the current parent permission group, and a node routing of the new permission group sub-chain is configured according to a specified node in the proposal, so that the creation of the new permission group is completed.

Description

Technical Field

[0001] The present invention belongs to the field of computer blockchain technology, and specifically relates to a fine-grained access control method and system in a multi-chain environment. Background Art

[0002] Fine-grained access control for data in multi-chain environments is a key factor in applying blockchain for data management in untrusted environments. Blockchain systems, characterized by decentralization, immutability, distributed consensus, traceability, and guaranteed consistency, are a key solution for data management in untrusted environments and are widely used in various fields, including manufacturing, finance, healthcare, and intellectual property protection. In practical applications, participants often only wish to share a portion of their data on-chain, making it visible to other participants while maintaining the privacy of some other data. A multi-chain architecture enables different participants in distributed applications to collaborate using blockchain while only sharing the data they need with other participants on the blockchain, thus ensuring the confidentiality of their private data.

[0003] In addition, the multi-chain architecture can solve the performance and storage problems in single-chain blockchain systems. Transactions that only involve internal enterprise data do not need to be agreed upon by all participants in the distributed application collaboration, and the complete data does not need to be stored on all nodes in the system. Therefore, it has stronger scalability than single-chain systems in the scenario of distributed application collaboration.

[0004] Currently popular multi-chain architectures can be categorized into three distinct types: multi-chain systems based on cross-chain transactions, multi-chain systems based on sharding, and multi-chain systems based on mainchain-sidechain interactions. Multi-chain systems based on cross-chain transactions maintain independent blockchains within different enterprises and exchange data between them through locks or specialized blockchain structures. This architecture can guarantee transaction atomicity within a multi-chain environment, but it carries a high performance overhead and requires additional network resources to ensure consistent concurrent transaction processing, limiting its widespread adoption. Multi-chain systems based on sharding divide the blockchain into multiple shards, with each shard maintaining its own sub-chain. This reduces node size and storage overhead, but the world state is typically visible to all sub-chains, lacking sufficient guarantees for data confidentiality. Multi-chain systems based on mainchain-sidechains similarly improve system performance and scalability by offloading some data processing to sidechains, but similarly lack guarantees for data confidentiality.

[0005] Currently popular multi-chain architectures fail to protect data confidentiality or only support coarse-grained access control, dividing data into private, internal data and public data visible to all other companies. Traditional data management systems, however, lack sufficient support for assigning permissions and controlling access to and using data across different departments, personnel, and subsidiaries within an enterprise. Furthermore, the need for some participants in a multi-chain environment to collaborate without the knowledge of others remains unmet. Therefore, there is an urgent need for fine-grained access control technology within a multi-chain environment to support scenarios where a single participant needs to control data access to different nodes, or where participants can dynamically and flexibly interact with data.

[0006] Therefore, how to use a multi-chain architecture to solve the problems of excessive data volume in a multi-chain environment, insufficient confidentiality guarantees, and coarse access control granularity in multi-chain data management, which only supports enterprise and global data access control; and to propose a more convenient and reliable data management solution for distributed application collaboration in a multi-chain environment is an issue that technical personnel in this field urgently need to solve. Summary of the Invention

[0007] In light of this, the present invention discloses a method and system for fine-grained access control in a multi-chain environment. While ensuring tamper-proof, decentralized, and traceable multi-chain architecture, this method supports fine-grained access control for multi-level permission groups. A corresponding method is designed to support the dynamic and flexible creation and allocation of permissions, providing support for refined data management in distributed application scenarios. Furthermore, this method leverages the execute-order-verify blockchain architecture and the trusted execution environment provided by Intel SGX to further ensure high system performance and low storage overhead.

[0008] In order to achieve the above object, the present invention adopts the following technical solutions:

[0009] In a first aspect, an embodiment of the present application provides a fine-grained access control method in a multi-chain environment. The distributed application to which the method is applicable includes a client, a consensus node, and an execution node. The method includes a permission allocation phase, a transaction execution phase, and a transaction submission phase.

[0010] The execution process of the permission allocation stage is as follows:

[0011] The client uses the permission group assignment transaction request to perform a new permission group creation transaction or permission group node adjustment transaction; the execution node jumps to generate a transaction proposal and sends it to the consensus node of the corresponding parent permission group; the consensus node verifies the legitimacy and generates a block together with other transactions; after the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group; each consensus node in the new permission group generates a genesis block for the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the node routing of the new permission group subchain according to the node specified in the proposal, completing the creation of the new permission group;

[0012] The transaction execution phase and the transaction submission phase are performed under the constraints of the permission group created or adjusted in the permission allocation phase.

[0013] Furthermore, the specific execution process of the authority allocation stage of the present invention is as follows:

[0014] S31. The client uses a permission group allocation transaction to request a new permission group creation transaction or a permission group node adjustment transaction.

[0015] S32. For the creation transaction, the consensus node determines its legitimacy, that is, whether the client initiating the request belongs to the same permission group as itself, and whether the current permission group is the parent permission group of the new permission group it created. For the node adjustment transaction, the permission group assignment transaction when the corresponding permission group was created is accessed, the permission group assignment rule is read, and its legitimacy is determined, that is, whether it matches the current permission group.

[0016] S33. After the legitimacy verification is passed, the consensus node sends the transaction request to the execution node of the same permission group to assemble the permission group allocation transaction proposal;

[0017] S34. Transaction proposals are assigned to permission groups. The execution node skips the execution of the smart contract and directly generates a transaction proposal, which is sent to the consensus node of the corresponding parent permission group.

[0018] S35. After receiving the transaction proposal, the consensus node in the parent authority group verifies its legitimacy and, if approved, produces a block together with other transactions.

[0019] S36. After the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the permission group assignment has been agreed upon by the corresponding permission group. For creation transactions, the corresponding permission group is the parent permission group. For node adjustment transactions, the corresponding permission group can be the parent permission group or the permission group performing the node adjustment.

[0020] S37. For the permission group creation transaction, each consensus node in the new permission group generates a genesis block for the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the network settings of the node routing of the new permission group's child chain according to the nodes specified in the proposal, completing the creation of the new permission group.

[0021] Furthermore, the transaction execution phase of the present invention is executed as follows:

[0022] S11. The client generates a corresponding transaction request based on demand, determines the permission group involved in the transaction, and sends the transaction to the on-chain consensus node in the corresponding permission group;

[0023] S12. The consensus node verifies the legitimacy of the transaction type and accessed data, determines which permission group it belongs to, and verifies whether the sender has the identity of the corresponding permission group;

[0024] S13. After verification, the consensus node sends the transaction to the execution node off-chain;

[0025] S14. After receiving the transaction, the execution node performs a validity check to determine which state data it can read;

[0026] S15. The execution node executes the transaction in the trusted execution environment (TEE). Based on the permission group identity to which the transaction belongs, the execution node reads the data belonging to the parent set identity of the permission group within the TEE, calls the smart contract, and generates a read-write set based on the execution logic of the smart contract.

[0027] S16. The execution node packages the read-write set, the permission group to which it belongs, and the execution proof generated by the TEE for its access data to form a transaction proposal and sends it to any consensus node in the corresponding permission group.

[0028] Furthermore, the transaction commit phase execution process of the present invention is as follows:

[0029] S21. The consensus node verifies the legitimacy of the transaction proposal based on the information in the proposal and determines the permission group to which it belongs, and initiates the consensus process in the corresponding permission group.

[0030] S22. Within the scope of the consensus nodes of the corresponding permission group, consensus is reached on the order of transactions in the ledger according to the general consensus protocol set when the permission group was assigned;

[0031] S23. After consensus is reached on the transaction proposal order, each consensus node in the permission group independently verifies the trusted execution environment signature and the transaction write set based on the partial Merkle-Patricia tree maintained by the consensus node or other data structure storing state data;

[0032] S24. After the legitimacy of the transaction proposal is verified, the consensus nodes within the permission group independently run a conflict detection algorithm. Based on the maintained permission group read and write detection index, they sequentially verify the data in different permission groups involved in the transaction and use a heuristic algorithm to prematurely terminate transactions that may cause the ledger to be non-serializable.

[0033] S25. After the transaction proposal passes the conflict detection, it is collected by the consensus node in the corresponding permission group. When the collected transaction proposals meet the conditions required for block generation, the transactions that pass the consensus in the permission group are packaged to form a new block.

[0034] S26. After a new block is generated, each consensus node in the permission group updates some of the state data storage structures on the chain, such as the Merkle-Patricia tree, based on the write set of its transaction, and maintains the permission group read and write detection index;

[0035] S27. After consensus is reached, the consensus nodes in the permission group will send the transaction to all off-chain execution nodes in the same permission group.

[0036] S28. After receiving the block, the execution node verifies its legitimacy, uses the transactions in it to update the off-chain state database, and appends the block to the ledger of the corresponding permission group for on-chain submission, completing the submission process.

[0037] Furthermore, the legitimacy of the blockchain transaction access data in step S12 of the present invention is determined by the permission group it accesses; any blockchain transaction must follow the workflow within the application, can read the internal data of its permission group and the data of all parent permission groups, and can only update the data of its permission group; the execution nodes and consensus nodes of the same application or other applications outside the permission group do not participate in the processing of the permission group transaction.

[0038] Furthermore, all types of transactions described in the present invention are executed in the trusted execution environment TEE in the execution node of the corresponding permission group. After the execution is completed, the TEE will generate a corresponding execution certificate for the execution result.

[0039] Furthermore, the consensus node of the present invention does not save the complete blockchain ledger and the state data, but only saves the partial Merkle-Patricia tree to verify the state data.

[0040] Furthermore, the consensus nodes and execution nodes described in the present invention do not save or process transactions and data in permission groups in which they do not participate. They only process transactions, generate blocks, and store data in permission groups at all levels to which they belong. Therefore, data in different permission groups is only stored on nodes with corresponding permissions.

[0041] Furthermore, the consensus node described in the present invention maintains a permission group read and write detection index for transactions in each permission group, independently performs conflict detection judgment and heuristically terminates transactions in advance within the permission group, and ensures the serializability of transactions within the permission group and between permission groups without the need for additional communication between nodes.

[0042] In a second aspect, an embodiment of the present application provides a fine-grained access control system in a multi-chain environment, including a client, a consensus node, and an execution node;

[0043] During the permission allocation phase:

[0044] The client uses the permission group assignment transaction request to perform a new permission group creation transaction or permission group node adjustment transaction;

[0045] The execution node jumps to generate a transaction proposal and sends it to the consensus node of the corresponding parent authority group;

[0046] After validating the transaction, the consensus node generates a block along with other transactions. After the consensus node on the chain generates a block, it checks whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group. Each consensus node in the new permission group generates the genesis block of the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the node routing of the new permission group's child chain according to the node specified in the proposal, completing the creation of the new permission group.

[0047] During the transaction execution and transaction submission phases: clients, consensus nodes, and execution nodes execute under the constraints of the permission groups created or adjusted in the permission allocation phase above.

[0048] Beneficial effects:

[0049] As can be seen from the above technical solution, compared with the existing technology, this invention provides a fine-grained access control method and system in a multi-chain environment. While ensuring the system's tamper-proof, decentralized, and traceable nature within the multi-chain architecture, it also supports fine-grained access control for multi-level permission groups. A corresponding method is designed to support the dynamic and flexible creation and allocation of permissions, providing support for refined data management in distributed application scenarios. Furthermore, this method leverages the execute-order-verify blockchain architecture and the trusted execution environment provided by Intel SGX to further ensure high system performance and low storage overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0051] Figure 1 The accompanying drawing is a schematic diagram of the overall flow structure of the method provided by the present invention.

[0052] Figure 2 The accompanying figure is a schematic diagram of the multi-chain ledger structure in the method provided by the present invention. DETAILED DESCRIPTION

[0053] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0054] It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments may be combined with each other; and, based on the embodiments in this disclosure, all other embodiments obtained by persons of ordinary skill in the art without creative work are within the scope of protection of this disclosure.

[0055] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this apparatus and / or practice this method.

[0056] In light of this, the present invention provides a fine-grained access control method in a multi-chain environment. While ensuring tamper-proof, decentralized, and traceable multi-chain architecture, this method supports fine-grained access control for multi-level permission groups. A corresponding method is designed to support the dynamic and flexible creation and allocation of permissions, providing support for refined data management in distributed application scenarios. Furthermore, this method leverages the execute-order-verify blockchain architecture and the trusted execution environment provided by Intel SGX to further ensure high system performance and low storage overhead.

[0057] The embodiment of the present application provides a fine-grained access control method in a multi-chain environment, including a permission allocation phase, a transaction execution phase, and a transaction submission phase;

[0058] Before executing the permission allocation phase, the following definitions are explained:

[0059] Permission Group: Permission groups identify the identities of consensus nodes, execution nodes, and clients, as well as their access rights to various types of data. An entity in the system can belong to multiple permission groups at the same time. For example, Figure 1 The enterprise A-department 1-1 consensus node belongs to the permission group Global, permission group A (representing enterprise A), and permission group A-1 (representing department 1 in enterprise A).

[0060] Parent Permission Group: When all consensus nodes in a permission group A-1 belong to another permission group A, that is, the set of consensus nodes in permission group A-1 is a subset of A, then permission group A is considered the parent permission group of permission group A-1. For example, an enterprise is a parent permission group relative to a single department within the enterprise, and a department is a parent permission group relative to a group within the enterprise. The establishment of a new permission group requires consensus within the parent permission group, that is, through the permission allocation stage, to ensure that the network structure, sub-chain location, routing configuration, and authentication mechanism of the newly established permission group are all agreed upon by all nodes in the new permission group.

[0061] Permission group elements: The permission group contains the following elements: 1. Node list (network structure), consensus nodes and execution nodes with identities corresponding to the permission group; 2. Routing configuration, the IP addresses of each consensus node and execution node corresponding to the node list; 3. Subchain pre-order hash, the position of the newly established subchain in the ledger, the pre-order block of its genesis block and its corresponding state data snapshot; 4. Permission group allocation rule, the permission group identity required for operations such as adding and adjusting nodes to the permission group (consensus can be specified within the permission group, or consensus needs to be reached in any parent permission group); 5. Authentication certificate, the public key in the digital certificate used for authentication; the node list, routing configuration and authentication certificate public key are stored as state data and can be updated according to the permission group allocation rule, while the subchain pre-order hash is stored on the genesis block of the subchain, and the permission group allocation rule is stored as immutable metadata in the permission group allocation transaction (creation transaction) of the parent permission group subchain.

[0062] In a multi-chain environment, each permission group corresponds to a sub-chain in the complete ledger, and points to the blocks in the parent permission groups at all levels on which it depends, indicating that its data depends on the snapshot of a parent permission group block.

[0063] The execution process of the permission allocation stage is as follows:

[0064] The client uses the permission group assignment transaction request to perform a new permission group creation transaction or permission group node adjustment transaction; the execution node jumps to generate a transaction proposal and sends it to the consensus node of the corresponding parent permission group; the consensus node verifies the legitimacy and generates a block together with other transactions; after the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group; each consensus node in the new permission group generates a genesis block for the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the node routing of the new permission group subchain according to the node specified in the proposal, completing the creation of the new permission group;

[0065] The transaction execution phase and the transaction submission phase are performed under the constraints of the permission group created or adjusted in the permission allocation phase.

[0066] In this embodiment of the application, the specific execution process of the permission allocation stage is as follows:

[0067] S31. The client uses a special permission group allocation transaction to request the creation or adjustment of a new permission group. This transaction includes two types: permission group creation transaction and permission group node adjustment transaction.

[0068] S32. After receiving the permission group assignment transaction request from the client, the consensus node determines the request type (creation or node adjustment). For the creation transaction, the consensus node determines its legitimacy (whether it belongs to the same permission group as itself, and whether the current permission group is the parent permission group of the new permission group it creates). For the node adjustment transaction, the consensus node accesses the permission group assignment transaction when the corresponding permission group was created, reads the permission group assignment rules, and determines whether it matches the current permission group.

[0069] S33. After the legitimacy verification is passed, the consensus node sends the transaction to the execution node of the same permission group to assemble the permission group allocation transaction proposal.

[0070] S34. Transaction proposals are assigned to permission groups. The execution node skips the execution of the smart contract and directly generates a transaction proposal, which is sent to the consensus node of the corresponding parent permission group.

[0071] S35. After receiving the transaction proposal, the consensus node in the parent authority group verifies its legitimacy and, if approved, produces a block together with other transactions.

[0072] S36. After the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the permission group assignment has been agreed upon by the corresponding permission group. For creation transactions, the corresponding permission group is the parent permission group. For node adjustment transactions, the corresponding permission group can be the parent permission group or the permission group performing the node adjustment.

[0073] S37. For the permission group creation transaction, each consensus node in the new permission group generates a new chain's genesis block in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the node routing and other network settings of the new permission group's child chain according to the nodes specified in the proposal, completing the creation of the new permission group.

[0074] In the embodiment of the present application, the execution process of the transaction execution phase is as follows:

[0075] S11. The client generates a corresponding transaction request based on demand, determines the permission group involved in the transaction, and sends the transaction to the on-chain consensus node in the corresponding permission group;

[0076] S12. The consensus node verifies the legitimacy of the transaction type and accessed data, determines which permission group it belongs to, and verifies whether the sender has the identity of the corresponding permission group;

[0077] S13. After verification, the consensus node sends the transaction to the execution node off-chain;

[0078] S14. After receiving the transaction, the execution node performs a validity check to determine which state data it can read;

[0079] S15. The execution node executes the transaction in the Trusted Execution Environment (TEE). Based on the permission group identity to which the transaction belongs, the execution node reads the data belonging to the parent set identity of the permission group in the TEE, calls the smart contract, and generates a read-write set according to the execution logic of the smart contract.

[0080] S16. The execution node packages the read-write set, the permission group to which it belongs, and the execution proof generated by the TEE for its access data to form a transaction proposal and sends it to any consensus node in the corresponding permission group.

[0081] In the embodiment of the present application, the transaction commit phase execution process is as follows:

[0082] S21. The consensus node verifies the legitimacy of the transaction proposal based on the information in the proposal and determines the permission group to which it belongs, and initiates the consensus process in the corresponding permission group.

[0083] S22. Within the scope of the consensus nodes of the corresponding permission group, consensus is reached on the order of transactions in the ledger according to the general consensus protocol set when the permission group was assigned;

[0084] S23. After consensus is reached on the transaction proposal order, each consensus node in the permission group independently verifies the trusted execution environment signature and the transaction write set based on the partial Merkle-Patricia tree maintained by the consensus node or other data structure storing state data;

[0085] S24. After the legitimacy of the transaction proposal is verified, the consensus nodes within the permission group independently run a conflict detection algorithm. Based on the maintained permission group read and write detection index, they sequentially verify the data in different permission groups involved in the transaction and use a heuristic algorithm to prematurely terminate transactions that may cause the ledger to be non-serializable.

[0086] S25. After the transaction proposal passes the conflict detection, it is collected by the consensus node in the corresponding permission group. When the collected transaction proposals meet the conditions required for block generation, the transactions that pass the consensus in the permission group are packaged to form a new block.

[0087] S26. After a new block is generated, each consensus node in the permission group updates some of the state data storage structures on the chain, such as the Merkle-Patricia tree, based on the write set of its transaction, and maintains the permission group read and write detection index;

[0088] S27. After consensus is reached, the consensus nodes in the permission group will send the transaction to all off-chain execution nodes in the same permission group.

[0089] S28. After receiving the block, the execution node verifies its legitimacy, uses the transactions in it to update the off-chain state database, and appends the block to the ledger of the corresponding permission group for on-chain submission, completing the submission process;

[0090] Preferably, the legitimacy of the blockchain transaction accessing data in step S12 is determined by the permission group it accesses; any blockchain transaction must follow the workflow within the application, can read the internal data of its permission group and the data of all parent permission groups, and can only update the data of its permission group; execution nodes and consensus nodes of the same application or other applications outside the permission group do not participate in the processing of the permission group transaction;

[0091] Preferably, all of the aforementioned transactions are executed in a trusted execution environment (TEE) in the execution node of the corresponding permission group. After the execution is completed, the TEE will generate a corresponding execution certificate for the execution result.

[0092] The consensus node does not save the complete blockchain ledger and the state data, but only saves the partial Merkle-Patricia tree to verify the state data;

[0093] Preferably, consensus and execution nodes do not save or process transactions and data in permission groups they do not participate in. They only process transactions, generate blocks, and store data in permission groups at all levels they belong to. Therefore, data in different permission groups is only stored on nodes with corresponding permissions.

[0094] Preferably, the consensus node maintains a permission group read and write detection index for transactions in each permission group, independently performs conflict detection and heuristically aborts transactions within the permission group, and ensures the serializability of transactions within and between permission groups without requiring additional communication between nodes.

[0095] This embodiment is a fine-grained access control method in a multi-chain environment, and the embodiment includes four entities: distributed applications, client nodes, consensus nodes, and execution nodes.

[0096] The distributed applications in this embodiment are applications deployed in a distributed environment and collaborate through data exchange. Typically, distributed applications belong to a specific enterprise or organization. In this embodiment, each distributed application includes at least one client, one consensus node, and maintains at least one global chain. It may also have at least one execution node with a trusted execution environment (TEE), an off-chain ledger, and a state database, and is internally divided into one or more levels of permission groups.

[0097] The client in this embodiment is no different from the client of a common blockchain in terms of implementation. Both can be implemented through the command line or SDK. However, the following operations of the client need to be modified:

[0098] (1) The client has a specific permission group and can only initiate transactions within the corresponding permission group. Therefore, it can only connect and communicate with consensus nodes in the same permission group, and cannot send transaction requests to consensus nodes belonging to other permission groups. For example, in distributed application (enterprise) A, the client of department 1 cannot initiate transactions to access data in the permission group of distributed application (enterprise) B, nor can it initiate transactions to access data in the permission group of department 2.

[0099] (2) When initiating a transaction, the data range to be accessed by the transaction must be specified and sent to the consensus node of the corresponding permission group. Specifically, transactions in a permission group can only read data within it and all parent permission groups, and can only modify data within its permission group.

[0100] The consensus nodes in this example are similar in function to the ordering nodes in the blockchain under the EOV architecture, but with the following differences:

[0101] (1) A consensus node has one or more permission group identities, and therefore simultaneously reaches consensus on multiple sub-chains (i.e., multiple networks) under a multi-chain architecture. Each sub-chain it is responsible for can adopt any common consensus protocol and can be different from other sub-chains.

[0102] (2)Consensus nodes concurrently perform consensus on transactions in multiple permission groups in which they participate, use only part of the Merkel-Patricia tree on the chain, and read-write indexes for conflict detection to check the involved transaction state, without storing complete state data and blockchain ledgers, and do not process transactions in permission groups that do not belong to them.

[0103] The execution node in the embodiment is similar in function to the Peer of the blockchain under the EOV architecture, such as Fabric, which saves the blockchain ledger and state data and executes transactions, but has the following differences:

[0104] (1) The execution node has one or more permission group identities and executes transactions in different permission groups while storing and updating state data and ledgers in each permission group. The execution node does not save all ledger data under the multi-chain architecture, but only stores the sub-chain corresponding to the permission group it participates in, i.e., a view of the complete ledger.

[0105] (2) The execution node executes transactions in a trusted execution environment (TEE), generates an execution proof of the transaction and signs it, and sends the execution result with the proof and signature to the consensus node, which verifies the correctness and legality of the result in combination with the data structure of the partial Merkel-Patricia tree on the chain.

[0106] The relationship between the above entities and data exchange is shown in Figure 1 The overall system flow details will be described in the following according to the transaction execution phase, result submission phase, and permission allocation phase when adjusting the permission group under the multi-chain architecture.

[0107] After the initialization of each entity is completed, the transaction execution phase and the transaction submission phase are entered in turn, and when a permission group needs to be created and allocated, the permission allocation phase is entered through a permission allocation transaction. The specific implementation method will be described in detail according to the embodiment.

[0108] After the initialization of each entity is completed, the transaction execution phase and the transaction submission phase are entered in turn, and when a permission group needs to be created and allocated, the permission allocation phase is entered through a permission allocation transaction. The specific implementation method will be described in detail according to the embodiment.

[0109] 1. First, the off-chain execution node is connected to the trusted execution environment (TEE, taking Intel SGX as an example) and loads the data of the sub-chain corresponding to different permission groups, the complete state data, and the blockchain ledger of each sub-chain is stored outside the TEE, but the execution is performed inside the TEE and the proof of the execution process is generated.

[0110] 2. The client sends a smart contract deployment transaction to the consensus node, deploys the smart contract on the blockchain, and specifies the permission group corresponding to the contract and the data range it can legally access. After the smart contract deployment transaction is chained, the execution node of the corresponding permission group loads its logic into the TEE.

[0111] 3. The user uses the client to interact with the multi-chain system, constructs transactions according to the methods provided by the client, and sends the transactions to the consensus nodes of the corresponding permission group using the routing table in the network configuration of the corresponding permission group, the transaction request including the address of the smart contract called by the transaction, the parameters, the permission group involved in accessing the data, and the signature of the client on the transaction.

[0112] 4. After the transaction is forwarded to the execution node, the execution node determines the corresponding permission group, accesses the internal state database of the permission group or the database of the parent permission group according to the logic of the smart contract, executes the smart contract in the TEE, generates a transaction proposal containing the execution read-write set and the execution proof, signs the proposal using the identity of the corresponding permission group, and sends the proposal to the consensus nodes of the corresponding permission group.

[0113] After the transaction execution phase ends, the result submission phase begins, and the process is as follows:

[0114] 1. After receiving the transaction proposal sent by the execution node, the consensus node first verifies the legality of the transaction proposal, determines whether it belongs to the corresponding permission group, and verifies whether the signature belongs to the signature of the execution node in the permission group.

[0115] 2. After passing the legality verification, the consensus node calls the general consensus protocol specified in advance in the permission group network configuration to reach consensus on the order of the transaction among the consensus nodes of the permission group.

[0116] 3. After the consensus on the order of the transaction on the corresponding sub-chain of the permission group is completed, each node independently verifies the accuracy of the transaction execution result according to its own partial Merkle-Patricia tree and read-write index in the permission group, and detects whether there is a potential read-write conflict, and aborts the transaction that may cause concurrent read-write conflict in advance. During this detection and verification phase, transactions belonging to different permission groups on the same node can be verified in parallel.

[0117] 4. The verified transaction will be packaged into the next block, and the block header contains the previous block hash of the same permission group accessed by the transaction in the block, as well as the block hash of all parent permission groups that access the data.

[0118] 5. After the block is formed, the on-chain consensus node updates the partial Merkle-Patricia tree and read-write index of the corresponding permission group, and the complete block is stored in the off-chain execution node, updating the ledger and state database of the permission group corresponding sub-chain.

[0119] Thus, the complete life cycle of the transaction belonging to any permission group ends.

[0120] When a permission group needs to be created or assigned in the network, a permission group assignment transaction is initiated, entering the permission assignment phase. Its lifecycle is similar to other transactions, but with the following differences:

[0121] 1. The read-write set does not contain status data, but contains the node information in the newly created permission group.

[0122] 2. During the result submission phase, when a consensus node records a block containing a valid permission group assignment transaction, if it is a member of the new permission group, it will create a genesis block for a new subchain after the block is generated. The previous block will be the block containing the permission group assignment transaction, corresponding to the new permission group subchain. If it is not a member of the new permission group, the transaction will be skipped.

[0123] 3. After the genesis block is generated, each node in the new permission group synchronizes the network configuration of the permission group and creates a new Merkle-Patricia tree and read-write index within the corresponding permission group.

[0124] 4. When the execution node of the parent permission group receives a block containing a permission group assignment transaction, the processing flow is similar to that of the consensus node, and a new state database and ledger are created for the new permission group.

[0125] 5. After the client successfully connects to the consensus node of the corresponding permission group in the network configuration, it can initiate transactions within the permission group and form a sub-chain corresponding to the permission group after the new genesis block.

[0126] This completes the process of creating and assigning a new permission group.

[0127] The embodiment of the present application provides a fine-grained access control system in a multi-chain environment, including a client, a consensus node, and an execution node;

[0128] During the permission allocation phase:

[0129] The client uses the permission group assignment transaction request to perform a new permission group creation transaction or permission group node adjustment transaction;

[0130] The execution node jumps to generate a transaction proposal and sends it to the consensus node of the corresponding parent authority group;

[0131] After validating the transaction, the consensus node generates a block along with other transactions. After the consensus node on the chain generates a block, it checks whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group. Each consensus node in the new permission group generates the genesis block of the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the node routing of the new permission group's child chain according to the node specified in the proposal, completing the creation of the new permission group.

[0132] In the transaction execution phase and the transaction commit phase: the client, the consensus node and the execution node execute under the permission group constraint created or adjusted in the above permission allocation phase.

[0133] The present application aims at the needs of data storage, access control and high-performance transaction processing in the distributed application cooperation scenario, designs fine-grained access control based on the multi-chain environment of the blockchain, supports the distributed application to securely and reliably store and use data when cooperating in the multi-chain environment of the blockchain, and guarantees the high performance, low overhead and high scalability of the process. The present application realizes the highly concurrent execution, consensus and verification among transactions at all levels in the multi-chain environment by applying a new directed acyclic graph ledger structure and flexibly allocating the storage, read-write permissions of data in the multi-chain environment to each node, and supports adjusting the access permissions of the nodes dynamically while guaranteeing the consistency of the world state and the ledger content. The fine-grained access control technology in the multi-chain environment designed in the present application can provide a basis for data management, transaction processing and other tasks in the multi-chain architecture of the blockchain, guarantee the high availability of the data on the chain, and can be further migrated to other application scenarios in the blockchain that have needs for access control, data confidentiality and consistency.

[0134] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be mutually referred to. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the related parts can be referred to the method part.

[0135] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A fine-grained access control method in a multi-chain environment, wherein the distributed application to which the method is applicable includes clients, consensus nodes, and execution nodes, and is characterized in that: The method includes a permission allocation phase, a transaction execution phase, and a transaction submission phase; The execution process of the permission allocation stage is as follows: The client uses the permission group assignment transaction request to create a new permission group or adjust the permission group node. The execution node jumps to the generated transaction proposal and sends it to the consensus node of the corresponding parent permission group. After the consensus node verifies the legitimacy, it generates a block together with other transactions. After the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group. Each consensus node in the new permission group will generate the genesis block of the new chain in parallel, append it to the ledger, and point its previous block hash to the block of the current parent permission group. It will also configure the node routing of the new permission group's child chain according to the nodes specified in the proposal, completing the creation of the new permission group. The transaction execution phase and the transaction submission phase are performed under the constraints of the permission group created or adjusted in the permission allocation phase; The execution process of the transaction execution phase is as follows: S11. The client generates a corresponding transaction request based on demand, determines the permission group involved in the transaction, and sends the transaction to the on-chain consensus node in the corresponding permission group; S12. The consensus node verifies the legitimacy of the transaction type and accessed data, determines which permission group it belongs to, and verifies whether the sender has the identity of the corresponding permission group; S13. After verification, the consensus node sends the transaction to the execution node off-chain; S14. After receiving the transaction, the execution node performs a validity check to determine which state data it can read; S15. The execution node executes the transaction in the trusted execution environment (TEE). Based on the permission group identity to which the transaction belongs, the execution node reads the data belonging to the parent set identity of the permission group within the TEE, calls the smart contract, and generates a read-write set based on the execution logic of the smart contract. S16. The execution node packages the read-write set, the permission group to which it belongs, and the execution proof generated by the TEE for its access data to form a transaction proposal and sends it to any consensus node in the corresponding permission group; The transaction commit phase execution process is as follows: S21. The consensus node verifies the legitimacy of the transaction proposal based on the information in the proposal and determines the permission group to which it belongs, and initiates the consensus process in the corresponding permission group. S22. Within the scope of the consensus nodes of the corresponding permission group, consensus is reached on the order of transactions in the ledger according to the general consensus protocol set when the permission group was assigned; S23. After consensus is reached on the transaction proposal order, each consensus node in the permission group independently verifies the trusted execution environment signature and the transaction write set based on the partial Merkle-Patricia tree maintained by the consensus node or other data structure storing state data; S24. After the legitimacy of the transaction proposal is verified, the consensus nodes within the permission group independently run a conflict detection algorithm. Based on the maintained permission group read and write detection index, they sequentially verify the data in different permission groups involved in the transaction and use a heuristic algorithm to prematurely terminate transactions that may cause the ledger to be non-serializable. S25. After the transaction proposal passes the conflict detection, it is collected by the consensus node in the corresponding permission group. When the collected transaction proposals meet the conditions required for block generation, the transactions that pass the consensus in the permission group are packaged to form a new block. S26. After a new block is generated, each consensus node in the permission group updates some of the state data storage structures on the chain, such as the Merkle-Patricia tree, based on the write set of its transaction, and maintains the permission group read and write detection index; S27. After consensus is reached, the consensus nodes in the permission group will send the transaction to all off-chain execution nodes in the same permission group. S28. After receiving the block, the execution node verifies its legitimacy, uses the transactions in it to update the off-chain state database, and appends the block to the ledger of the corresponding permission group for on-chain submission, completing the submission process.

2. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: The specific execution process of the authority allocation stage is as follows: S31. The client uses a permission group allocation transaction to request a new permission group creation transaction or a permission group node adjustment transaction. S32. For the creation transaction, the consensus node determines its legitimacy, that is, whether the client initiating the request belongs to the same permission group as itself, and whether the current permission group is the parent permission group of the new permission group it created. For the node adjustment transaction, the permission group assignment transaction when the corresponding permission group was created is accessed, the permission group assignment rule is read, and its legitimacy is determined, that is, whether it matches the current permission group. S33. After the legitimacy verification is passed, the consensus node sends the transaction request to the execution node of the same permission group to assemble the permission group allocation transaction proposal; S34. Transaction proposals are assigned to permission groups. The execution node skips the execution of the smart contract and directly generates a transaction proposal, which is sent to the consensus node of the corresponding parent permission group. S35. After receiving the transaction proposal, the consensus node in the parent authority group verifies its legitimacy and, if approved, produces a block together with other transactions. S36. After the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the permission group assignment has been agreed upon by the corresponding permission group. For creation transactions, the corresponding permission group is the parent permission group. For node adjustment transactions, the corresponding permission group can be the parent permission group or the permission group performing the node adjustment. S37. For the permission group creation transaction, each consensus node in the new permission group generates a genesis block for the new chain in parallel, appends it to the ledger, points its previous block hash to the block of the current parent permission group, and configures the network settings of the node routing of the new permission group's child chain according to the nodes specified in the proposal, completing the creation of the new permission group.

3. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: The legitimacy of the blockchain transaction accessing data in step S12 is determined by the permission group it accesses; any blockchain transaction must follow the workflow within the application, can read the internal data of its permission group and the data of all parent permission groups, and can only update the data of its permission group; execution nodes and consensus nodes of the same application or other applications outside the permission group do not participate in the processing of the permission group transaction.

4. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: All types of transactions are executed in the trusted execution environment TEE in the execution node of the corresponding permission group. After the execution is completed, TEE will generate a corresponding execution certificate for the execution result.

5. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: The consensus node does not save the complete blockchain ledger and the state data, but only saves the partial Merkle-Patricia tree to verify the state data.

6. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: The consensus nodes and execution nodes do not save or process transactions and data in the permission groups they do not participate in. They only process transactions, generate blocks, and store data in the permission groups at all levels to which they belong.

7. The fine-grained access control method in a multi-chain environment according to claim 1 is characterized in that: The consensus node maintains a permission group read and write detection index for transactions in each permission group, independently performs conflict detection and heuristically terminates transactions in advance within the permission group, and ensures the serializability of transactions within and between permission groups without the need for additional communication between nodes.

8. A fine-grained access control system in a multi-chain environment, comprising a client, a consensus node, and an execution node; characterized in that: During the permission allocation phase: The client uses the permission group assignment transaction request to perform a new permission group creation transaction or permission group node adjustment transaction; The execution node jumps to generate a transaction proposal and sends it to the consensus node of the corresponding parent authority group; After the consensus node verifies the legitimacy, it will be generated into a block together with other transactions; After the consensus node on the chain generates a block, it will check whether there is a permission group assignment transaction in the block. If there is, it means that the assignment of the new permission group has been agreed upon by the parent permission group. Each consensus node in the new permission group will generate the genesis block of the new chain in parallel, append it to the ledger, and point its previous block hash to the block of the current parent permission group. It will also configure the node routing of the new permission group's child chain according to the nodes specified in the proposal, completing the creation of the new permission group. During the transaction execution and transaction submission phases: clients, consensus nodes, and execution nodes execute under the constraints of the permission groups created or adjusted in the permission allocation phase above; The execution process of the transaction execution phase is as follows: S11. The client generates a corresponding transaction request based on demand, determines the permission group involved in the transaction, and sends the transaction to the on-chain consensus node in the corresponding permission group; S12. The consensus node verifies the legitimacy of the transaction type and accessed data, determines which permission group it belongs to, and verifies whether the sender has the identity of the corresponding permission group; S13. After verification, the consensus node sends the transaction to the execution node off-chain; S14. After receiving the transaction, the execution node performs a validity check to determine which state data it can read; S15. The execution node executes the transaction in the trusted execution environment (TEE). Based on the permission group identity to which the transaction belongs, the execution node reads the data belonging to the parent set identity of the permission group within the TEE, calls the smart contract, and generates a read-write set based on the execution logic of the smart contract. S16. The execution node packages the read-write set, the permission group to which it belongs, and the execution proof generated by the TEE for its access data to form a transaction proposal and sends it to any consensus node in the corresponding permission group; The transaction commit phase execution process is as follows: S21. The consensus node verifies the legitimacy of the transaction proposal based on the information in the proposal and determines the permission group to which it belongs, and initiates the consensus process in the corresponding permission group. S22. Within the scope of the consensus nodes of the corresponding permission group, consensus is reached on the order of transactions in the ledger according to the general consensus protocol set when the permission group was assigned; S23. After consensus is reached on the transaction proposal order, each consensus node in the permission group independently verifies the trusted execution environment signature and the transaction write set based on the partial Merkle-Patricia tree maintained by the consensus node or other data structure storing state data; S24. After the legitimacy of the transaction proposal is verified, the consensus nodes within the permission group independently run a conflict detection algorithm. Based on the maintained permission group read and write detection index, they sequentially verify the data in different permission groups involved in the transaction and use a heuristic algorithm to prematurely terminate transactions that may cause the ledger to be non-serializable. S25. After the transaction proposal passes the conflict detection, it is collected by the consensus node in the corresponding permission group. When the collected transaction proposals meet the conditions required for block generation, the transactions that pass the consensus in the permission group are packaged to form a new block. S26. After a new block is generated, each consensus node in the permission group updates some of the state data storage structures on the chain, such as the Merkle-Patricia tree, based on the write set of its transaction, and maintains the permission group read and write detection index; S27. After consensus is reached, the consensus nodes in the permission group will send the transaction to all off-chain execution nodes in the same permission group. S28. After receiving the block, the execution node verifies its legitimacy, uses the transactions in it to update the off-chain state database, and appends the block to the ledger of the corresponding permission group for on-chain submission, completing the submission process.

Images